[U-Boot] ICACHE in core initialization to improve u-boot boot time: Breaks booting with i2c code while executing in flash.

[Richard Retanubun]

On 10/20/10 15:50, Wolfgang Denk wrote:
> Dear Richard Retanubun,
>
> In message<4CBDC153.30008 at RuggedCom.com>  you wrote:
>>
>> It does not work on our platform (similar to MPC8360EMDS). I think this is specific to our platform because
>> we need to initialize i2c and use i2c while still executing from flash in checkboard()) to read and parse a board-id i2c-eeprom
>> to support a unified uboot binary for multiple board flavors.
>
> Many boards do that. Some keep the environment in I2C EEPROM as well.
> This should not collide With instruction caches on.
>
>> Just an FYI mostly, I am okay with not having ICACHE for our board while in uboot.
>> Just curious if you know of a reason from the limited explanation I've provided.
>
> Check how your boot device (NOR flash) is mapped - make sure it has
> the BI (burst inhibit) bit set (or whatever it may be called on that CPU).

Thanks for taking the time Wolfgang, now you got me curious, so I did a little reading.
For MPC8360MDS reference board access the NOR flash in GPCM (General Purpose Control Machine) mode
which does not have a "burst inhibit" bit, only the UPM mode of the local bus controller have this.

The only other place 'inhibit' is mentioned that would make sense is the Block Address Translation (BAT)
my settings are identical to MPC8360MDS with one exception, MDS maps flash to BAT3 (considered low-BAT)
mine is on BAT6 (considered high-BAT), and yes my HID1 register setting enables the high-BATs.

Not sure how any of these matters, though.

Another observation I've made is by turning on CONFIG_DISPLAY_AER_FULL or CONFIG_DISPLAY_AER_BRIEF
and printing it from cpu_init.c:prt_83xx_rsr() causes the same checkboard() function to fail accessing the i2c-eeprom,
even though the contents are correct. However, if I move the printf of:

printf("AEATR=0x%08lX, AEADR=0x%08lX\n", gd->arbiter_event_attributes, gd->arbiter_event_address);
Into checkboard() (before i2c early init, all works okay)

So there seems to be a sensitivity in fsl-i2c drive while running from flash during early init
although I am too ignorant to suspect anything right now.

Thanks for everyone's time...

- Richard