Not primarily u-boot related problem with Flash-RAM
Hi there!
I've a problem that is not really u-boot specific; in fact it rather stands in my way to be able to use the U-Boot at all. I'm sorry for the off-topic post, but as this list's topic is the one most close to "bringing up boards" I hope you can help me a bit though:
I have a prototype board which has an MPC875 with 4 AM29LV320DB flash chips on the bus (there also are 2 SDRAMs and an FPGA on the bus).
The board had a design flaw which made some buffers/level converters which should convert the bus signal level to the signal level of a PCMCIA adapter kind of burn out or at least disturb bus operations on the data- as well as address-bus.
We've therefore removed the buffers/level converters, and now the busses
work, as we can see with a test program running on the FPGA (which
monitors the busses and draws block graphics of the last non-identical 32 bus states on a VGA display). That means, the MPC and the FPGA seem to have survived what ever was wrong with the busses.
But though the busses seem to be okay now, the flash doesn't react to the ident command sequence as it should, though I tried very defensive clocking and stuff.
So the question is if you know typical mistakes which can cause accessing flash to fail, or if you know that flash chips are well known to go into pieces if there is something wrong with the busses connected to them. Any hint will be appreciated.
Thanks for reading,
Peter Asemann
Hi over there...
Quoted 21 lines
Hi there!
I've a problem that is not really u-boot specific; in fact it rather stands in my way to be able to use the U-Boot at all. I'm sorry for the off-topic post, but as this list's topic is the one most close to "bringing up boards" I hope you can help me a bit though:
I have a prototype board which has an MPC875 with 4 AM29LV320DB flash chips on the bus (there also are 2 SDRAMs and an FPGA on the bus).
The board had a design flaw which made some buffers/level converters which should convert the bus signal level to the signal level of a PCMCIA adapter kind of burn out or at least disturb bus operations on the data- as well as address-bus.
We've therefore removed the buffers/level converters, and now the busses
work, as we can see with a test program running on the FPGA (which
monitors the busses and draws block graphics of the last non-identical 32 bus states on a VGA display). That means, the MPC and the FPGA seem to have survived what ever was wrong with the busses.
Quoted 7 lines
But though the busses seem to be okay now, the flash doesn't react to the ident command sequence as it should, though I tried very defensive clocking and stuff.
So the question is if you know typical mistakes which can cause accessing flash to fail, or if you know that flash chips are well known to go into pieces if there is something wrong with the busses connected to them. Any hint will be appreciated.
So you say that all 4 flash chips don't work anymore? Can you access the flash through FPGA?
I would just do:
- grab jtag tools from openwince project
- add busdriver for mpc875 according to bsdl file and your hardware
- try to access flash manually...
Good thing about jtag tools is that you can also set individual pins or see individual pin states...
rick
Quoted 5 lines · In message <[email protected]> you wrote:
So the question is if you know typical mistakes which can cause accessing flash to fail, or if you know that flash chips are well known to go into pieces if there is something wrong with the busses connected to them. Any hint will be appreciated.
Are you sure that the flashes ever worked? One typical problem is that it seems quite natural to connect the D0 pin of the flash chip to the D0 pin of the data bus, etc. - which is wrong, since for the flash chip D0 is the LSB, but on PowerPC bit 0 is the MSB...
Can you access (read, erase, program) the flashes through a BDM debugger?
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra
Quoted 8 lines
Are you sure that the flashes ever worked? One typical problem is that it seems quite natural to connect the D0 pin of the flash chip to the D0 pin of the data bus, etc. - which is wrong, since for the flash chip D0 is the LSB, but on PowerPC bit 0 is the MSB...
Can you access (read, erase, program) the flashes through a BDM debugger?
I don't know the particular CPU, but along the same lines (learn from my mistakes!):
1) did you hook the flash up in the correct mode (8 vs. 16 bit)
2) did you hook CPU addresses to flash addresses correctly? This will depend on the flash mode setting and the CPU. At least one part I've used (Toshiba TX4925) changes the
connections between internal and external address busses based on the programmed width of the chip select - i.e for a 32-bit wide select it will connect the A2 out of the MMU to
the external A0, for a 16-bit wide it connects A1 out of the MMU to external A0, etc.
3) In s/w when doing the ID cycle are you writing to the correct address in CPU space to generate the right pattern on the physical lines hooked to the flash to make it recognize the ID commands?
and as a reminder of things one ought to be doing, these are a good set of rules:
http://www.debuggingrules.com/debuggingrules.pdf (for more explanation on these check out the book "Debugging" by Dave Agans - no affiliation, yada, yada)
Signature · 2 lines
Hardware, n.:
The parts of a computer system that can be kicked.Quoted 4 lines
Are you sure that the flashes ever worked? One typical problem is that it seems quite natural to connect the D0 pin of the flash chip to the D0 pin of the data bus, etc. - which is wrong, since for the flash chip D0 is the LSB, but on PowerPC bit 0 is the MSB...
Argh... in fact, if I mirror the command sequence, the flash works (reacts to auto select command sequence).
Is there a "mirrored command sequences software package" to use mis-layouted hardware of that kind?
Best regards,
Peter Asemann
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 4 lines
Are you sure that the flashes ever worked? One typical problem is that it seems quite natural to connect the D0 pin of the flash chip to the D0 pin of the data bus, etc. - which is wrong, since for the flash chip D0 is the LSB, but on PowerPC bit 0 is the MSB...
Argh... in fact, if I mirror the command sequence, the flash works (reacts to auto select command sequence).
Condolences. [I must have smelled this.]
Quoted 2 lines
Is there a "mirrored command sequences software package" to use mis-layouted hardware of that kind?
None that I know of - except that Abatron provided special firmware versions for their BDI2000's to deal with such problems before.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Landing: a controlled mid-air collision with a planet.
Quoted 6 lines · Wolfgang Denk
...
Quoted 3 lines
Is there a "mirrored command sequences software package" to use mis-layouted hardware of that kind?
None that I know of - except that Abatron provided special firmware versions for their BDI2000's to deal with such problems before.
does .../board/musenki/flash.c do what you mean?
-mark
Congrats, Wolfgang, you're a seer.
Quoted 2 lines
None that I know of - except that Abatron provided special firmware versions for their BDI2000's to deal with such problems before.
I'll probably provide some Flash.dev for the mpcbdm for "normal" AM29LV320DB chips as well as for accessing "mirrored" flash soon.
And... if I manage to boot the board... I'll probably faciliate a queer mutation of the cfi_flash u-boot driver.
Peter Asemann