[ECOS] Flash Driver Read/Write Alignment Question

[ECOS] Flash Driver Read/Write Alignment Question

[Jay Foster]

I am puzzling over how the eCos flash drivers are supposed to work when
using 16-bit wide flash devices.  I'm using an ARM architecture (ARM7TDMI,
ARM940T), and the AMD AM29LV160 flash device connected in the 16-bit wide
mode (CYGNUM_FLASH_WIDTH=16).

Looking at the flash driver code, this defines the flash_data_t as a 16-bit
type.  This results in all accesses to the flash device to be performed as
16-bit reads/writes.

The flash driver defines some special addresses (FLASH_Setup_Addr1,
FLASH_Setup_Addr2, etc.).  At least one of these will be defined as an odd
address.  This will result in an unaligned transfer, causing a DATA ABORT
exception.  What am I missing here?

Jay


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

Re: [ECOS] Flash Driver Read/Write Alignment Question

[Gary Thomas]

On Fri, 2006-06-09 at 10:06 -0700, Jay Foster wrote:
> I am puzzling over how the eCos flash drivers are supposed to work when
> using 16-bit wide flash devices.  I'm using an ARM architecture (ARM7TDMI,
> ARM940T), and the AMD AM29LV160 flash device connected in the 16-bit wide
> mode (CYGNUM_FLASH_WIDTH=16).
> 
> Looking at the flash driver code, this defines the flash_data_t as a 16-bit
> type.  This results in all accesses to the flash device to be performed as
> 16-bit reads/writes.
> 
> The flash driver defines some special addresses (FLASH_Setup_Addr1,
> FLASH_Setup_Addr2, etc.).  At least one of these will be defined as an odd
> address.  This will result in an unaligned transfer, causing a DATA ABORT
> exception.  What am I missing here?

They should not end up at odd addresses since they are cast to the
FLASH element type.  If this is 16 bit, Addr(0xA55) == 0x14AA, etc.

If you're ending up with alignment issues, then you've configured
your FLASH driver incorrectly (check the defines).  There are lots
of examples of 16 and 32 bit device setups, as well as some parallel
and banked layouts.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

RE: [ECOS] Flash Driver Read/Write Alignment Question

[Jay Foster]

Ahh, thanks.  I see it now.  My omission of the flash base address in my
example is where I missed the magic.

	volatile flash_data_t *ROM = flash base address
	f_s1 = (volatile flash_data_t *)((CYG_ADDRWORD)(ROM + 0x555));

Jay

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Friday, June 09, 2006 12:06 PM
To: Jay Foster
Cc: 'ecos-discuss@ecos.sourceware.org'
Subject: RE: [ECOS] Flash Driver Read/Write Alignment Question


On Fri, 2006-06-09 at 11:43 -0700, Jay Foster wrote:
> I have not encountered an alignment issue (yet), as I haven't gotten that
> far.  I am studying the source code (flash_am29xxxxx.inl).  I still don't
> see how this is supposed to work.  Effectively, I would have:
> 
> 	typedef cyg_uint16 flash_data_t; // flash_io.h
> 	volatile flash_data_t *f_s1, *f_s2;
> 	f_s1 = (volatile flash_data_t *)0xAAA; // flash base address omitted
> 	f_s2 = (volatile flash_data_t *)0x555;
> 
> 	*f_s1 = FLASH_Reset;
> 	*f_s1 = FLASH_Setup_Code1;
> 	*f_s2 = FLASH_Setup_Code2;
> 
> Where does the 0x555 and 0xAAA get shifted left by 1?  The value of f_s2
is
> odd.  Dereferencing it will result in an unaligned transfer.

That's not what my version of the code looks like :-)  There are macros 
that do the casting and get the addressing/alignment correct.

Try running your version of the code through the C-Preprocessor (use -E)
and see what the real C code looks like.  You'll see that it's a bit 
more than just a cast offset.

> Jay
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Friday, June 09, 2006 11:02 AM
> To: Jay Foster
> Cc: 'ecos-discuss@ecos.sourceware.org'
> Subject: Re: [ECOS] Flash Driver Read/Write Alignment Question
> 
> 
> On Fri, 2006-06-09 at 10:06 -0700, Jay Foster wrote:
> > I am puzzling over how the eCos flash drivers are supposed to work when
> > using 16-bit wide flash devices.  I'm using an ARM architecture
(ARM7TDMI,
> > ARM940T), and the AMD AM29LV160 flash device connected in the 16-bit
wide
> > mode (CYGNUM_FLASH_WIDTH=16).
> > 
> > Looking at the flash driver code, this defines the flash_data_t as a
> 16-bit
> > type.  This results in all accesses to the flash device to be performed
as
> > 16-bit reads/writes.
> > 
> > The flash driver defines some special addresses (FLASH_Setup_Addr1,
> > FLASH_Setup_Addr2, etc.).  At least one of these will be defined as an
odd
> > address.  This will result in an unaligned transfer, causing a DATA
ABORT
> > exception.  What am I missing here?
> 
> They should not end up at odd addresses since they are cast to the
> FLASH element type.  If this is 16 bit, Addr(0xA55) == 0x14AA, etc.
> 
> If you're ending up with alignment issues, then you've configured
> your FLASH driver incorrectly (check the defines).  There are lots
> of examples of 16 and 32 bit device setups, as well as some parallel
> and banked layouts.
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 
> 
-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

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

RE: [ECOS] Flash Driver Read/Write Alignment Question

[Gary Thomas]

On Fri, 2006-06-09 at 11:43 -0700, Jay Foster wrote:
> I have not encountered an alignment issue (yet), as I haven't gotten that
> far.  I am studying the source code (flash_am29xxxxx.inl).  I still don't
> see how this is supposed to work.  Effectively, I would have:
> 
> 	typedef cyg_uint16 flash_data_t; // flash_io.h
> 	volatile flash_data_t *f_s1, *f_s2;
> 	f_s1 = (volatile flash_data_t *)0xAAA; // flash base address omitted
> 	f_s2 = (volatile flash_data_t *)0x555;
> 
> 	*f_s1 = FLASH_Reset;
> 	*f_s1 = FLASH_Setup_Code1;
> 	*f_s2 = FLASH_Setup_Code2;
> 
> Where does the 0x555 and 0xAAA get shifted left by 1?  The value of f_s2 is
> odd.  Dereferencing it will result in an unaligned transfer.

That's not what my version of the code looks like :-)  There are macros 
that do the casting and get the addressing/alignment correct.

Try running your version of the code through the C-Preprocessor (use -E)
and see what the real C code looks like.  You'll see that it's a bit 
more than just a cast offset.

> Jay
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Friday, June 09, 2006 11:02 AM
> To: Jay Foster
> Cc: 'ecos-discuss@ecos.sourceware.org'
> Subject: Re: [ECOS] Flash Driver Read/Write Alignment Question
> 
> 
> On Fri, 2006-06-09 at 10:06 -0700, Jay Foster wrote:
> > I am puzzling over how the eCos flash drivers are supposed to work when
> > using 16-bit wide flash devices.  I'm using an ARM architecture (ARM7TDMI,
> > ARM940T), and the AMD AM29LV160 flash device connected in the 16-bit wide
> > mode (CYGNUM_FLASH_WIDTH=16).
> > 
> > Looking at the flash driver code, this defines the flash_data_t as a
> 16-bit
> > type.  This results in all accesses to the flash device to be performed as
> > 16-bit reads/writes.
> > 
> > The flash driver defines some special addresses (FLASH_Setup_Addr1,
> > FLASH_Setup_Addr2, etc.).  At least one of these will be defined as an odd
> > address.  This will result in an unaligned transfer, causing a DATA ABORT
> > exception.  What am I missing here?
> 
> They should not end up at odd addresses since they are cast to the
> FLASH element type.  If this is 16 bit, Addr(0xA55) == 0x14AA, etc.
> 
> If you're ending up with alignment issues, then you've configured
> your FLASH driver incorrectly (check the defines).  There are lots
> of examples of 16 and 32 bit device setups, as well as some parallel
> and banked layouts.
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 
> 
-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

RE: [ECOS] Flash Driver Read/Write Alignment Question

[Jay Foster]

I have not encountered an alignment issue (yet), as I haven't gotten that
far.  I am studying the source code (flash_am29xxxxx.inl).  I still don't
see how this is supposed to work.  Effectively, I would have:

	typedef cyg_uint16 flash_data_t; // flash_io.h
	volatile flash_data_t *f_s1, *f_s2;
	f_s1 = (volatile flash_data_t *)0xAAA; // flash base address omitted
	f_s2 = (volatile flash_data_t *)0x555;

	*f_s1 = FLASH_Reset;
	*f_s1 = FLASH_Setup_Code1;
	*f_s2 = FLASH_Setup_Code2;

Where does the 0x555 and 0xAAA get shifted left by 1?  The value of f_s2 is
odd.  Dereferencing it will result in an unaligned transfer.
Jay

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Friday, June 09, 2006 11:02 AM
To: Jay Foster
Cc: 'ecos-discuss@ecos.sourceware.org'
Subject: Re: [ECOS] Flash Driver Read/Write Alignment Question


On Fri, 2006-06-09 at 10:06 -0700, Jay Foster wrote:
> I am puzzling over how the eCos flash drivers are supposed to work when
> using 16-bit wide flash devices.  I'm using an ARM architecture (ARM7TDMI,
> ARM940T), and the AMD AM29LV160 flash device connected in the 16-bit wide
> mode (CYGNUM_FLASH_WIDTH=16).
> 
> Looking at the flash driver code, this defines the flash_data_t as a
16-bit
> type.  This results in all accesses to the flash device to be performed as
> 16-bit reads/writes.
> 
> The flash driver defines some special addresses (FLASH_Setup_Addr1,
> FLASH_Setup_Addr2, etc.).  At least one of these will be defined as an odd
> address.  This will result in an unaligned transfer, causing a DATA ABORT
> exception.  What am I missing here?

They should not end up at odd addresses since they are cast to the
FLASH element type.  If this is 16 bit, Addr(0xA55) == 0x14AA, etc.

If you're ending up with alignment issues, then you've configured
your FLASH driver incorrectly (check the defines).  There are lots
of examples of 16 and 32 bit device setups, as well as some parallel
and banked layouts.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

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