Re: [ECOS] x86 and flash

Re: [ECOS] x86 and flash

[davide_ciminaghi]

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

Re: [ECOS] x86 and flash

[Jonathan Larmour]

"davide ciminaghi@libero.it" wrote:
> 
> 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).

0x01AD by the looks of it.

> Interestingly, if I dump the flash chip from its start address, the
> first byte I see is 0xaa 

Hm... 0xAA is one of the flash set up codes. This smells a bit like a CPU
cache or write buffer issue. I could imagine this since there isn't a flash
driver for x86 in the public sources. The x86 is meant to have full cache
snooping, but there's probably some particular issue with flash bus cycles.

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

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] x86 and flash

[Davide]

Hi,

I can see the flash chip with the correct id now. I can also erase it.
The problem was that I had the MEMW signal disabled within the flash address
range (just one wrong bit in a configuration
register).
I still have to check whether I can correctly program the flash.

Anyway, Jonathan thank you very much for your help !

Davide




-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] x86 and flash

[davide_ciminaghi]

> "davide ciminaghi@libero.it" wrote:
> > 
> > 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).
> 
> 0x01AD by the looks of it.
> 
> > Interestingly, if I dump the flash chip from its start address, the
> > first byte I see is 0xaa 
> 
> Hm... 0xAA is one of the flash set up codes. This smells a bit like a 
CPU
> cache or write buffer issue. I could imagine this since there isn't a 
flash
> driver for x86 in the public sources. The x86 is meant to have full ca
che
> snooping, but there's probably some particular issue with flash bus cy
cles.
> 

The CPU of my microcontroller is a 386 and I haven't any external 
cache, so I don't think I have any cache at all.

Yesterday evening I did some tests again and found out that what I told 
you yesterday was not completely true (sorry!): in fact MANUFACTURER id 
is 0xaa, while DEVICE id is 0x00, which is exactly what I find at 
addresses 0x00 and 0x01 of the flash chip if I do a dump with gdb or 
redboot. So it seems that the cpu is correctly addressing those two 
bytes.

Concerning "flash bus cycles": my flash is directly connected to a 
dedicated chip select generated by the SC300 microcontroller. It's 
called DOSCS because you're supposed to put some kind of dos filesystem 
on the device connected to it. You can program the uc to activate the 
DOS chip select whenever some physical address range is hit. You can 
also tell the uc that the DOSCS area is read/write or read only. In the 
latter case, the DOS chip will always be "hardware" write protected (so 
whether you're running in protected mode or not the bus MEMW signal 
will never be activated on that physical range of addresses). 
Since the SC300 has a LOT of configuration registers (and unfortunately 
memory config. bits are spread over many regs), I think I'll give 
another look at the manual to see if there's something wrong or missing 
in the uc initialization.

Thank you very much for your help.

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
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/eco
s
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> 
> 

Re: [ECOS] x86 and flash

[Jonathan Larmour]

"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 platform
> 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 have
> well understood, this means that the flash_query() function returns an
> unexpected id. Just for debugging purposes, I've temporarily disabled
> 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 flash
> 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 difficult to
tell. I would suggest starting at the beginning and working out why the 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 think is
on this board). At the very least you should see what the ID it returns is!

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

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] x86 and flash

[davide_ciminaghi]

Hi,

as I told the list some months ago, I'm working with a board based on 
the AMD elan sc300 microcontroller (it's an old embedded 386).
I'm trying to get ecos to work on that board. I've got no floppy 
interface, and unfortunately no bios at all. Nothing.
I just have two flash chips:

- 1 AMD29F010 => this is for redboot (ROM startup, of course).
- 1 AMD29F016D => this is a 2MB additional flash chip, which should 
host the redboot flash filesystem.

I also have a 91C96 ethernet controller, but decided to get the serial 
port to work first.

Current status is:
- redboot (compiled for ROM startup) seems to work via the serial port 
at 38400baud. I can also download the ecos test programs to RAM and 
run/debug them. Of course I just tried 2 or 3 programs, so I'm not 
sure that everything works properly.
- 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 platform 
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 have 
well understood, this means that the flash_query() function returns an 
unexpected id. Just for debugging purposes, I've temporarily disabled 
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 flash 
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. 

As a conclusion: I can read the flash, but cannot write it (as a matter 
of fact the autoselect procedure includes some write cycles !).

Any ideas / suggestions on what to do ?

Thanks and regards
Davide Ciminaghi