On 10/20/10 15:50, Wolfgang Denk wrote:
> Dear Richard Retanubun,
>
> In message<4cbdc153.30...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
