[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[Peter Asemann]

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

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[richard at uclinux.net]

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

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[Wolfgang Denk]

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

-- 
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

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[Andrew Dyer]

> 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)


-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[Peter Asemann]

> 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

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[Wolfgang Denk]

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

-- 
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.

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[Mark Rakes]

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

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM

[Peter Asemann]

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