[U-Boot] ALERT! >90% of all board configurations BROKEN

[Reinhard Meyer <u-boot@emk-elektronik.de>]

Dear Albert ARIBAUD,

>> That is #ifdef-ed away in case of ARM-relocation. Perhaps we should remove
>> all code that pertains to "WITHOUT_RELOC"... Would make the rest of the code
>> less obscure...
> 
>> I changed my board.config like this:
>> ...
>> /*#define CONFIG_SYS_GBL_DATA_SIZE 128*/	/* 128 bytes for initial data */
>> ...
>> #define	CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_SDRAM_BASE + 0x1000 /*- CONFIG_SYS_GBL_DATA_SIZE*/)

I must confess I copied that #define from other boards without much reasoning about it:)

>> ...
>> and it still compiles. The second line is the only use of GBL_DATA_SIZE,
>> since that is often set to somewhere in SRAM, it is still ok - even if
>> set to the end of SRAM it will most likely wrap into the repeated SRAM
>> image on most SoCs.
> 
> Not all SoCs have SRAM. While the kirkwood family always has it, as does 
> the Marvell 5182, the 5281 doesn't, for instance.

Point is, that probably there is enough space above CONFIG_SYS_INIT_SP_ADDR
to hold the global data before relocation without overwriting essential values
and without hitting an access fault, so the mistake did not hurt.

And as Heiko points out, the global data is well below 128 bytes in the usual
ARM cases.

With ELF relocation (on AT91) boards the single use of CONFIG_SYS_GBL_DATA_SIZE is to
reserve space above CONFIG_SYS_INIT_SP_ADDR.

To really document that relationship, I will reorder the defines in my <board>.h:

#define CONFIG_SYS_GBL_DATA_SIZE 256	/* 256 bytes for initial data */
#define	CONFIG_SYS_INIT_SP_ADDR	(CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE)


Reinhard