We have converted all makefiles needed to build $(LIBS).
Until this commit we used to grep switch so that U-Boot style
and Kbuild style makefiles coexist.
But we do not need any more.
Goint forward, use always Kbuild style Makefile when adding
a new Makefile
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
A large number of boards incorrectly used getenv() in their board init
code running before relocation. In some cases this caused U-Boot to
hang when certain environment variables grew too long.
Fix the code to use getenv_r().
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: The LEOX team <team@leox.org>
Cc: Michael Schwingen <michael@schwingen.org>
Cc: Georg Schardt <schardt@team-ctech.de>
Cc: Werner Pfister <Pfister_Werner@intercontrol.de>
Cc: Dirk Eibach <eibach@gdsys.de>
Cc: Peter De Schrijver <p2@mind.be>
Cc: John Zhan <zhanz@sinovee.com>
Cc: Rishi Bhattacharya <rishi@ti.com>
Cc: Peter Tyser <ptyser@xes-inc.com>
Currently, some linker scripts are found by common code in config.mk.
Some are found using CONFIG_SYS_LDSCRIPT, but the code for that is
sometimes in arch config.mk and sometimes in board config.mk. Some
are found using an arch-specific rule for looking in CPUDIR, etc.
Further, the powerpc config.mk rule relied on CONFIG_NAND_SPL
when it really wanted CONFIG_NAND_U_BOOT -- which covered up the fact
that not all NAND_U_BOOT builds actually wanted CPUDIR/u-boot-nand.lds.
Replace all of this -- except for a handful of boards that are actually
selecting a linker script in a unique way -- with centralized ldscript
finding.
If board code specifies LDSCRIPT, that will be used.
Otherwise, if CONFIG_SYS_LDSCRIPT is specified, that will be used.
If neither of these are specified, then the central config.mk will
check for the existence of the following, in order:
$(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds (only if CONFIG_NAND_U_BOOT)
$(TOPDIR)/$(CPUDIR)/u-boot-nand.lds (only if CONFIG_NAND_U_BOOT)
$(TOPDIR)/board/$(BOARDDIR)/u-boot.lds
$(TOPDIR)/$(CPUDIR)/u-boot.lds
Some boards (sc3, cm5200, munices) provided their own u-boot.lds that
were dead code, because they were overridden by a CPUDIR u-boot.lds under
the old powerpc rules. These boards' own u-boot.lds have bitrotted and
no longer work -- these lds files have been removed.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Tested-by: Graeme Russ <graeme.russ@gmail.com>
Clean up Makefile, and drop a lot of the config.mk files on the way.
We now also automatically pick all boards that are listed in
boards.cfg (and with all configurations), so we can drop the redundant
entries from MAKEALL to avoid building these twice.
Signed-off-by: Wolfgang Denk <wd@denx.de>
While running from flash, i. e. before relocation, we have only a
limited C runtime environment without writable data segment. In this
phase, some configurations (for example with environment in EEPROM)
must not use the normal getenv(), but a special function. This
function had been called getenv_r(), with the idea that the "_r"
suffix would mean the same as in the _r_eentrant versions of some of
the C library functions (for example getdate vs. getdate_r, getgrent
vs. getgrent_r, etc.).
Unfortunately this was a misleading name, as in U-Boot the "_r"
generally means "running from RAM", i. e. _after_ relocation.
To avoid confusion, rename into getenv_f() [as "running from flash"]
Signed-off-by: Wolfgang Denk <wd@denx.de>
Acked-by: Detlev Zundel <dzu@denx.de>
Xilinx ppc440 and ppc405 have many similarities. This patch merge the
config files of both infrastuctures
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@uam.es>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch adds support for the avnet fx12 minimodul.
It needs the "ppc4xx: Generic architecture for xilinx ppc405"
patch from Ricardo.
Signed-off-by: Georg Schardt <schardt@team-ctech.de>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@uam.es>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch solves the problems compiling ml507, v5fx30teval and
ppc440-generic out of tree.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@uam.es>
This patch provides an unificated way of handling xilinx v5 ppc440 boards.
It unificates 3 different things:
1) Source code
A new board called ppc440-generic has been created. This board includes
a generic tlb initialization (Maps the whole memory into virtual) and
defines board_pre_init, checkboard, initdram and get_sys_info weakly,
so, they can be replaced by specific functions.
If a new board needs to redefine any of the previous functions
(specific initialization) it can create a new directory with the
specific initializations needed. (see the example ml507 board).
2) Configuration file
Common configurations are located under configs/xilinx-ppc440.h, this
header file interpretes the xparameters file generated by EDK and
configurates u-boot in correspondence. Example: if there is a Temac,
allows CMD_CONFIG_NET
Specific configuration are located under specific configuration file.
(see the example ml507 board)
3) Makefile
Some work has been done in order to not duplicate work in the Main
Makefile. Please see the attached code.
In order to support new boards they can be implemented in the next way:
a) Simple Generic Board (90% of the time)
Using EDK generates a new xparameters.h file, replace
ppc440-generic/xparameters.h and run make xilinx-ppc440-generic_config
&& make
b) Simple Boards with special u-boot parameters (9 % of the time)
Create a new file under configs for it (use ml507.h as example) and
change your paramaters. Create a new Makefile paragraph and compile
c) Complex boards (1% of the time)
Create a new folder for the board, like the ml507
Finally, it adds support for the Avnet FX30T Evaluation board, following
the new generic structure:
Cheap board by Avnet for evaluating the Virtex5 FX technology.
This patch adds support for:
- UartLite
- 16MB Flash
- 64MB RAM
Prior using U-boot in this board, read carefully the ERRATA by Avnet
to solve some memory initialization issues.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@uam.es>
Signed-off-by: Stefan Roese <sr@denx.de>
