[U-Boot-Users] minimum bdi config to read flash on 85xx

Thu Sep 6 23:03:22 CEST 2007

Hi David,

This is Luiz and I'm working with Robert in this project. Actually, I'm a
hardware guy. I read your messages and it seems you're right. However,
before introducing these changes on the board, we decided to verify all
flash circuitry and we noticed the following:

CE# is OK!
WE# is OK!
OE# is OK!

We verified it using a scope and triggering CE# pin. After that, we tried to
write to flash through BDI2000 using "mm" command. Again with a scope we
checked each address line and apparently everything is fine with the
address. We also checked the data being written, and it's ok too. After
that, in order to validate the written, we read the same address we had just
written. But we got a different value. Therefore we are not writing
correctly to flash.

Ok, after all, we fixed our board following your tips. We connected
LA[27:30] to A[3:0] and A[4:25] to LBA[26:5]. But we got the same bad
result. I mean we read a wrong data.

After, we changed flash access time, decreasing it. And the problem
persisted. We changed flash chip and nothing happened.

Actually I'm afraid because I can't see what else we can verify on hardware.

My opinion is we have mistakes on configuration file. I'm not sure if we are
configuring all registers correctly.

Do you think it would be helpful if I send you our flash schematic and our
configuration file?

Thanks in advance!
Luiz.

2007/9/5, David Hawkins <dwh at ovro.caltech.edu>:
>
> Hi Robert,
>
> >> 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.
>
> I'm glad we've found your problem, but I'm sorry to hear
> the cause. Life now becomes more difficult for you :(
>
> >> 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.
>
> Its worth trying. My assumption would be that if you use
> the I2C boot sequencer to setup the boot address (however that
> is done), and then setup the memory controller that decodes
> that address to trigger the use of a UPM, where the UPM is
> setup correctly to read the Flash, then it will boot
> correctly. Of course I've never done this, or heard of a
> board that does it, so let us know how you go :)
>
> > 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 ?
>
> Read the explanation on p31 for the 83xx
> http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
>
> The thing to get your head around is that (for an 83xx);
>
> On reset the processor setups up a basic memory map
> where the processor boots from either 0xFFF00100 or
> 0x00000100, i.e., it boots from 1MB lower than the
> highest 32-bit address or it boots from address 0.
>
> The processor sets up an 8MB memory window that decodes to
> that Flash, eg. 0xFF800000 is the default base address
> of that Flash, or 0x0000000 is the default.
> (Assuming of course the config words say to boot from
> local bus flash).
>
> When you have an 8MB flash, either boot base-address works
> fine. However, when you have a larger flash, high-boot
> requires the boot code reside about 8MB into your Flash.
> Thats a bummer, as it splits your useable Flash in two,
> so using low-boot works nicer.
>
> Regardless of which boot method is used, once u-boot code
> runs, it sets up the decode region for the flash to be
> whereever it wants to be. In some boards, I am sure the
> Flash just gets left where it is, with perhaps the memory
> window being opened wider if there was a larger flash.
> In that case, the u-boot code for a high-boot image would
> still be found about 8MB into that decode region (for
> high-boot).
>
> Basically, shortly after the processor boots you setup the
> memory map as you'd like to see it.
>
> > 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?
>
> It depends :)
>
> If your processor boot sequence depended on the default FF800000
> window, and high-booted, then u-boot would live about 8MB into
> your 128MB Flash, and without changing the or0/br0, you'd only
> see the lower 8MB of the Flash. U-Boot would be linked with the
> FF800000 base address (or whatever U-boot needs regarding addresses).
> Once U-boot executes, and I think has setup the DDR and moved
> over to run from DDR, its no longer executing from Flash, so the
> location of the Flash can be moved. In that case, you'd change
> the base address to be F8000000 and viola, you can access all
> 128MB.
>
> If however you use the I2C boot sequencer to setup the 128MB
> flash as 128MB starting at F8000000, and boot that way, the
> u-boot image will sit about 1MB from the end of the 128MB
> Flash, not 8MB from the start of the flash. However, the processor
> reset vector, and hence u-boot code, will execute from FFFF0100
> in either case.
>
> I haven't looked at the 85xx manual in enough detail to see if
> all this applies, but thats the basics :)
>
> If you can get the 85xx to boot from 00000000, then it won't
> matter if you setup an 8MB window or 128MB window, just so long
> as the window starts at address 00000000 after reset. Then you
> can move it to F8000000 after boot. Then you'll only have code
> at the start of Flash, not starting 8MB into it (or 1MB from
> the end).
>
> Cheers,
> Dave
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070906/d300d4bf/attachment.htm 