[U-Boot-Users] minimum bdi config to read flash on 85xx
robert lazarski
robertlazarski at gmail.com
Wed Sep 5 21:53:01 CEST 2007
On 9/5/07, David Hawkins <dwh at ovro.caltech.edu> wrote:
> Hi Robert,
>
> >> 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
>
> http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
>
> 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.
Bingo! Excellent notes as it seems to describe our exact problem. The
way you describe it must be done - using pins LA[27:30] in our case -
is _not_ how our board is. It was that way in the prototype phase but
had a spurious signal on the bus so the hardware guys say. So it was
changed to the way you say it can't be done - via LAD[27:30]
multiplexed address/data bus.
>
> 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.
>
We don't have an I2C EEPROM , so its jumper wire time.
>
> > 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.
>
> 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
> link above.
>
This is really a side issue now, but since I asked it I might as well
finish up on it. The two 8548 boards I've looked at - EP8548 and CDS -
both have 8MB of flash starting at FF800000. What relation does that
have to the 8548 boot rom location of FF800000 ? Since I have 128MB of
flash starting at F8000000 in my or0 / br0 registers and LAW's in my
u-boot code, do I not need to change the boot rom location? Does this
effect the location to load the u-boot.bin file, 0xFFF80000 in the two
8548 examples?
Thanks a bunch!
Robert
More information about the U-Boot
mailing list