Re: [ECOS] x86 and flash

["=?utf-8?Q?davide=5Fciminaghi at libero dot it?=" <davide_ciminaghi at libero dot it>]

> "davide ciminaghi@libero.it" wrote:
> > 
> > -
 I'm now trying to add flash support: I added the 29F016D chip to the
> > AM29XXXXX family (file am29xxxxx_parts.inl) and told the driver that
 my
> > board has just one AM29f016d mapped at address 0xe00000. To do this 
I
> > just added a .c file under
> > ecos/packages/devs/flash/i386/sc300/current/src (sc300 being a platf
orm
> > under the i386 hal) containing
> > the following definitions:
> > 
> > #define CYGNUM_FLASH_INTERLEAVE (1)
> > #define CYGNUM_FLASH_SERIES     (1)
> > #define CYGNUM_FLASH_WIDTH      (8)
> > #define CYGNUM_FLASH_BASE       (0xe00000)
> > #define CYGHWR_DEVS_FLASH_AMD_AM29F016D 1
> > 
> > I also did the changes needed in the .cdl, .db, ... files.
> > 
> > Everything compiles, but I have some runtime problems:
> > 
> > 1) At boot, the driver tells me that the device is unknown. If I hav
e
> > well understood, this means that the flash_query
() function returns an
> > unexpected id. Just for debugging purposes, I've temporarily disable
d
> > the startup check and now the monitor boots with no error (of course
).
> > Anyway, the flash chip autoselect procedure doesn't seem to work.
> > 2) If I try erasing the flash chip I have a mix of timeout errors
> > and "write-protected region/device" errors.
> > 3) Nevertheless, when I dump the memory area corresponding to the fl
ash
> > chip I can see some meaningful ASCII strings which were probably
> > written during the board's factory test. Since those strings do NOT
> > come from redboot (there's a reference to the "Tornado TNT" OS) I'm
> > almost sure that I'm able to read at least a part of the flash chip.
> 
> It could be the dimensions of the device maybe, but it's very difficul
t to
> tell. I would suggest starting at the beginning and working out why th
e id
> is wrong. There's various reasons why that could be the case, mostly
> related to the dimensions (i.e. check your assumptions on what you thi
nk is
> on this board). At the very least you should see what the ID it return
s is!

Thanks Jonathan, 

I had already done that. The returned device id is 0xaa (I don't 
remember exactly now what the id should be for the amd29f016). 
Interestingly, if I dump the flash chip from its start address, the 
first byte I see is 0xaa (then I have a zeroed area, then some 0xff and 
finally what seems to be a binary image including some meaningful ASCII 
strings). As a matter of fact, the autoselect procedure just sends 
an "unlock sequence" to the device and then reads bytes 0 and 1, which 
should correspond to the manufacturer and device ids respectively. 
So it seems the driver thinks it's reading byte 1, while it's actually 
reading byte 0. Obviously, if the device isn't correctly addressed, 
then the unlock sequence will not work either.
Anyway, I'm a little bit confused now.
So I think I'll check everything again and try to find out why the id 
is wrong. 

Thanks again and regards
Davide


> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 27
1062
> Maybe this world is another planet's Hell -
Aldous Huxley || Opinions==mine
>