[U-Boot-Users] minimum bdi config to read flash on 85xx
dwh at ovro.caltech.edu
Wed Sep 5 18:35:12 CEST 2007
>>> however, we cannot see any activity whatsoever on the Ax
>>> pins on the spansion flash chip when trying read via the bdi and mdh.
>> What about when the processor boots?
>> > http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf
>> p233 of the PDF:
>> When the e500 core comes out of reset, its MMU has one 4-Kbyte
>> page defined at 0x0_FFFF_Fnnn. The core begins execution with
>> the instruction at effective address 0x0_FFFF_FFFC. To get this
>> instruction, the core's first instruction fetch is a burst read
>> of boot code from effective address 0x0_FFFF_FFE0.
>> So the address bus LSBs should be changing during this burst,
>> whereas the MSBs would be high.
> Excellent idea - can I please clarify it? On the spansion flash chip
> we have LBA5 to LBA30 - where LBA30 is the LSB. On reset, should we be
> seeing changes on these LSB's while the MSB's remain high?
Here's some notes I wrote a while back
Figure 5, p33, shows LA[27:31] toggling during boot from Flash.
Note that the asynchronous memory interface (GPCM) changes
address pins LA[27:31] during byte-wise access *not* the
LAD[27:31] multiplexed address/data bus that. So if the
board design connects up the wrong pins to the Flash,
it won't work. In your case, since you talk about LBA30
as being your LSB, it sound like you have 16-bit Flash.
The same comment applies though; LA[27:30] are the bits
that should be connected to the Flash for booting.
From the block diagram in Ch 13 of the 8548 reference manual,
it looks like the local bus controller setup is the same.
Note: if your Flash is connected to the wrong address pins,
it might be possible using the boot sequencer to change the
boot address to a UPM controlled area, and then use the
UPM to read the flash. But of course that requires having
the I2C EEPROM on the board to enable the boot sequencer.
>> I'm pretty sure that you should be able to power up the processor,
>> and the BDI-2000 can play in this default address-space, i.e.,
>> accesses between 0xFF800000 and the end of 4GB space should
>> decode to the Flash.
> We tried doing an mdh on 0xff800000 but still see bad data, even after setting:
But the Flash chip-select asserts, OE# asserts, and data is driven
out of the Flash? How about the address pins?
> WM32 0xe0005000 0xff801001 ;BR0
> WM32 0xe0005004 0xff806e65 ;OR0
Yeah, I wouldn't both changing registers until you get the
default state working.
> One more question please, since 83xx is the same here. What's the
> register that needs to be changed to move the boot location from
> FF800000 to F8000000 ? I've been getting deep into the boot sequencer
> and PORBMSR, but I'm having a hard time determining what and where to
> change the boot location address. We don't have an I2C eeprom, but the
> hardware guys tell me we can strap the pins to set the register once
> we know which one it is.
If your hardware guy knows of the pin strapping, then he should
know the register setting :)
p233 says that it is the boot sequencer that can be used to
change the boot address.
However, I wouldn't bother with trying to change the boot address
until you've got the flash working.
Any particular reason you want to change the address range?
It really isn't that important what the memory map is during
boot versus running u-boot. For example, the 83xx u-boot
code first used the high-boot address, and then switched to
low-boot (which is nice as it puts the boot code at the
start of Flash). The Flash itself can be viewed after boot
at a user-defined address. See the document notes at the
More information about the U-Boot