[U-Boot-Users] minimum bdi config to read flash on 85xx
dwh at ovro.caltech.edu
Wed Sep 12 21:41:54 CEST 2007
> OK guys I have a sense of humour
Its a pre-requisite; that, and tough skin ;)
> In the meantime we'll be spending quality with our
> manuals. We have OE and CE toggling on our erase, mm,
> and prog commands
Thats definitely a good start.
> but we cannot read the values we write with mm.
Were you able to connect a logic analyzer to the bus
to confirm bus values versus processor values?
> We cannot read the manufactorer id on 0xfc000000.
0xFC00_0000 is 64MB from the end of memory.
If accesses to this address generate Flash CE# and OE#,
then next I would check the timing.
Don't move onto anything until you can read the
manufacturer ID, you've found a problem, so you
need to figure it out here first.
> Beyond that the magic numbers are for the first and second
> unlock cycles and for autoselect, we cannot understand why
> bdi configs use 0x0600 and 0x00d0 for their magic
> numbers - which are not the same magic numbers in the
> manuals best as we can tell.
It depends on how the Flash is wired. As far as data
wires go, Flash[15:0] can connect to Processor[15:0]
or Processor[0:15]. Whatever the processor writes,
it'll read back.
However, the Flash command codes expect the bit pattern
as defined in the command codes table on Flash[15:0].
So you've got lots of board specific cases;
* bits reversed
* bytes swapped
* bits in bytes reversed
and so on ...
If the command code was 0x0006, and the BDI config you
copied shows 0x0600, then they've got bytes swapped.
If the code was 0x0060, and the bus is reversed
then you'll get 0x0600.
When you copy someone elses design without understanding
it, you can end up copying their mistakes.
In your case, you hooked up your Flash correctly, but
you're trying to interpret someone else's design in
the context of your design.
Rather than that, just look at the data sheets and
your specific design. You've gained an understanding
of what the BDI configuration file should contain,
now toss away anyone elses configs ... or look at them
with a 'grain of salt'.
> We tried writing the
> same magic numbers in the manuals directly via the bdi to seemingly no
> That all being said, our knowledge is slowly getting there - and it
> would have exponentially slower without the help so far.
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
More information about the U-Boot