[U-Boot-Users] 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...
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.
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
In message 4284CC63.8080405@web.de 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
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)
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
In message 428A1B82.7050302@web.de you wrote:
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.]
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
On May 17, 2005, at 9:43 AM, Wolfgang Denk wrote:
...
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.
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
participants (5)
-
Andrew Dyer -
Mark Rakes -
Peter Asemann -
richard＠uclinux.net -
Wolfgang Denk