Cleanup tx25.h by removing unnecessary defines and by removing unneeded "1"'s. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Make use of GPIO framework and avoid the following build error: tx25.c: In function 'tx25_fec_init': tx25.c:73: error: dereferencing pointer to incomplete type tx25.c:74: error: dereferencing pointer to incomplete type tx25.c:75: error: dereferencing pointer to incomplete type tx25.c:76: error: dereferencing pointer to incomplete type tx25.c:83: error: dereferencing pointer to incomplete type tx25.c:84: error: dereferencing pointer to incomplete type tx25.c:114: error: dereferencing pointer to incomplete type tx25.c:115: error: dereferencing pointer to incomplete type tx25.c:116: error: dereferencing pointer to incomplete type tx25.c:117: error: dereferencing pointer to incomplete type tx25.c:124: error: dereferencing pointer to incomplete type tx25.c:125: error: dereferencing pointer to incomplete type tx25.c:126: error: dereferencing pointer to incomplete type Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Stefano Babic <sbabic@denx.de>
commit 25ddd1fb0a2281b182529afbc8fda5de2dc16d96 left remnants of many comments about CONFIG_SYS_GBL_DATA_SIZE. Signed-off-by: Michael Jones <michael.jones@matrix-vision.de>
CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not being able to use "sizeof(struct global_data)" in assembler files. Recent experience has shown that manual synchronization is not reliable enough. This patch renames CONFIG_SYS_GBL_DATA_SIZE into GENERATED_GBL_DATA_SIZE which gets automatically generated by the asm-offsets tool. In the result, all definitions of this value can be deleted from the board config files. We have to make sure that all files that reference such data include the new <asm-offsets.h> file. No other changes have been done yet, but it is obvious that similar changes / simplifications can be done for other, related macro definitions as well. Signed-off-by: Wolfgang Denk <wd@denx.de> Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Heiko Schocher <hs@denx.de>
There were some #undef's of CONFIG_SYS_ARM_WITHOUT_RELOC added to a few board configs as part of the arm relocation series; but these are not needed now as we do not #undef what is not #defined in the first place. Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca> CC: Heiko Schocher <hs@denx.de>
Signed-off-by: Heiko Schocher <hs@denx.de>
Change the implementation for arm926 to relocate the code to an arbitrary address in RAM. Adapt the TX25 (i.MX25), magnesium board to test the changes. On the tx25 board TEXT_BASE is set to the final relocation address to prevent one more copying of u-boot code when relocating. More info see: doc/README.arm-relocation da850 board: Tested-by: Ben Gardiner <bengardiner@nanometrics.ca> Portions of this work were supported by funding from the CE Linux Forum. Signed-off-by: Heiko Schocher <hs@denx.de> Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Enable "cache" command on tx25 and magnesium board and test performance.
Test 1: Loading 127 MB of data from NAND flash into RAM:
Instr. Cache off on on
Data Cache off off on
--------------------------------------------------
magnesium 32,6s 22,5s 30s = x 1,09
tx25 (29MB only) 9,69s 5,05s 8,16s = x 1,19
Test 2: uncompressing a gzipped image from RAM to RAM
(size compressed: 6.5 MiB, uncompressed: 35 MiB):
Instr. Cache off on on
Data Cache off off on
--------------------------------------------------
magnesium 4,25s 2,08s 1,72s = x 2,47
tx25 4,82s 2,04s 1,84s = x 2,62
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Alessandro Rubini <rubini@gnudd.com>
This is an i.MX25 base board with only NAND so it uses nand_spl to boot. Signed-off-by: John Rigby <jcrigby@gmail.com> Tune configuration, add support for (redundant) environment in NAND. Signed-off-by: Wolfgang Denk <wd@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> CC: Fred Fan <fanyefeng@gmail.com> CC: Tom <Tom.Rix@windriver.com>