[ECOS] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[ECOS] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Dirk Sigurdson]

I'm working with a big endian arm chip and am having problems with the
HAL_WRITE_UINT8 macro.

If I do something like:

#define HW_REG_ADDRESS \
    ((volatile cyg_uint8*) (0x0400c71f))


HAL_WRITE_UINT8(HW_REG_ADDRESS, 0xff);


It ends up writing to address 0x0400c71c and not 0x0400c71f.  I could just
take the ^3 out of the macro, but am concerned that it might cause problems.
Does anyone have any suggestions?

Thanks,

Dirk


-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Gary Thomas]

On Wed, 2002-07-10 at 15:43, Dirk Sigurdson wrote:
> I'm working with a big endian arm chip and am having problems with the
> HAL_WRITE_UINT8 macro.
> 
> If I do something like:
> 
> #define HW_REG_ADDRESS \
>     ((volatile cyg_uint8*) (0x0400c71f))
> 
> 
> HAL_WRITE_UINT8(HW_REG_ADDRESS, 0xff);
> 
> 
> It ends up writing to address 0x0400c71c and not 0x0400c71f.  I could just
> take the ^3 out of the macro, but am concerned that it might cause problems.
> Does anyone have any suggestions?

The macros are designed so that the same addresses should work for
both big and little endian systems.  We've used this successfully on
a number of ARM platforms which can operate in either endian mode.

Instead of using 0x0400c71f, try using the address as it would be in
little endian form 0x0400c71c.



-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Grant Edwards]

On Wed, Jul 10, 2002 at 03:50:29PM -0600, Gary Thomas wrote:


> The macros are designed so that the same addresses should work for
> both big and little endian systems.  We've used this successfully on
> a number of ARM platforms which can operate in either endian mode.
> 
> Instead of using 0x0400c71f, try using the address as it would be in
> little endian form 0x0400c71c.

If you want to write to address 0x71f, you specify address
0x71c?  Doesn't anybody else thing that sounds a bit wierd? I
guess I understand what's going on, but it seems a bit silly to
make users of big-endian hardware munge up their register
addresses.

If I need to write to the byte at address 0x71f, then I want to
write 0x71f in my source code: that's why I don't use those
macros -- they don't work with pre-existing include files
containing my register definitions.

-- 
Grant Edwards
grante@visi.com

-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Dirk Sigurdson]

On 7/10/02 3:18 PM, "Grant Edwards" <grante@visi.com> wrote:

> On Wed, Jul 10, 2002 at 03:50:29PM -0600, Gary Thomas wrote:
> 
> 
>> The macros are designed so that the same addresses should work for
>> both big and little endian systems.  We've used this successfully on
>> a number of ARM platforms which can operate in either endian mode.
>> 
>> Instead of using 0x0400c71f, try using the address as it would be in
>> little endian form 0x0400c71c.
> 
> If you want to write to address 0x71f, you specify address
> 0x71c?  Doesn't anybody else thing that sounds a bit wierd? I
> guess I understand what's going on, but it seems a bit silly to
> make users of big-endian hardware munge up their register
> addresses.
> 
> If I need to write to the byte at address 0x71f, then I want to
> write 0x71f in my source code: that's why I don't use those
> macros -- they don't work with pre-existing include files
> containing my register definitions.

I'm in the same boat.  I've already got pre-existing headers that I'm using.
Sounds like I should by-pass using the macros.

I've always worked with big endian chips so I might be a bit confused.  But
shouldn't an address of a single byte in memory be the same no matter if
your big endian or little endian?

Further, I pass data back and forth between my big endian device and a
little endian pc.  On one or the other sides I have to do an endian
conversion.  So if I had a 32 bit word on the device of 0x0000071f (1823d),
passed it to the little endian host, did an endian conversion, the value
would be 0x0000c71f (1823d) and not 0x0400c71c (1820d).

Please help me with my confusion.


-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Jesper Skov]

On Thu, 2002-07-11 at 00:18, Grant Edwards wrote:
> > Instead of using 0x0400c71f, try using the address as it would be in
> > little endian form 0x0400c71c.
> 
> If you want to write to address 0x71f, you specify address
> 0x71c?  Doesn't anybody else thing that sounds a bit wierd? I
> guess I understand what's going on, but it seems a bit silly to
> make users of big-endian hardware munge up their register
> addresses.
> 
> If I need to write to the byte at address 0x71f, then I want to
> write 0x71f in my source code: that's why I don't use those
> macros -- they don't work with pre-existing include files
> containing my register definitions.

You are using register definitions that are munged for big-endian
hardware and clearly expected to be used by non-portable (big/little
endian) software.

If you want to use them with eCos macros, it will clearly fail since the
eCos macros are endian safe.

How's that? Well, the device you are writing to is activated (chip
select) by matching of address lines A31-A2. I.e. addresses 0x71c,
0x71d, 0x71e and 0x71f all match and enable your device for access. It
doesn't care about anything else.

So when the chip select is right, you need to get the data bits right.
Depending on the endianess of the CPU, you need to put the data in
either D0-7 or D24-D31 for 8bit access. You do that by changing A1-A0.

So A1-A0 should be depending on the CPU endian mode, and *nothing else*.

If you don't care about portability, and want to use definitions that
are not suitable for porting, by all means don't use the eCos macros.

But don't blame the macros for bothing it when fed bad definitions. The
macros do exactly what they were designed to; making the software
portable. Changing one endian definition flag is easier than changing
umpteen register definitions.

Jesper


-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Grant Edwards]

On Thu, Jul 11, 2002 at 06:15:42PM -0700, Dirk Sigurdson wrote:

> It's sounding like those macros should be platform specific and not
> architecture specific.

Could be.  Once I figured out why they didn't work, I just
stopped using them.

-- 
Grant Edwards
grante@visi.com

-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Dirk Sigurdson]

It's sounding like those macros should be platform specific and not
architecture specific.

On 7/11/02 8:05 AM, "Grant Edwards" <grante@visi.com> wrote:

> On Thu, Jul 11, 2002 at 10:17:31AM -0400, Mark Salter wrote:
> 
>>> You are using register definitions that are munged for
>>> big-endian hardware and clearly expected to be used by
>>> non-portable (big/little endian) software.
> 
> I'm using register definitions that are correct for my
> hardware.  I'm using a big-endian bus-controller, and if I want
> to access the byte at address X, why should I be expected to
> use some other address?
> 
>>> If you want to use them with eCos macros, it will clearly fail
>>> since the eCos macros are endian safe.
> 
> But the macros don't access the byte I specify.
> 
>>> How's that? Well, the device you are writing to is activated
>>> (chip select) by matching of address lines A31-A2. I.e.
>>> addresses 0x71c, 0x71d, 0x71e and 0x71f all match and enable
>>> your device for access. It doesn't care about anything else.
> 
> It most certainly does.  My bus controller has four byte-select
> lines, and if you futz with the lower two address lines, then
> the wrong byte select line goes active.
> 
>>> So when the chip select is right, you need to get the data bits
>>> right. Depending on the endianess of the CPU, you need to put
>>> the data in either D0-7 or D24-D31 for 8bit access. You do that
>>> by changing A1-A0.
> 
> The byte select logic in the bus controller handles that.
> 
>>> So A1-A0 should be depending on the CPU endian mode, and
>>> *nothing else*.
> 
> Well, I don't think so. If I'm running a big-endian,
> byte-addressable system and when I want the high order byte of
> the word at 0x1000, then I read byte address 0x1000.  That's
> the definition of big-endian.  It sounds to me like you've
> decided that little-endian is "right", big-endian is "wrong",
> and those of us with big-endian hardware should use macros to
> make it look like we've got little-endian hardware.
> 
>>> If you don't care about portability, and want to use
>>> definitions that are not suitable for porting, by all means
>>> don't use the eCos macros.
>>> 
>>> But don't blame the macros for bothing it when fed bad
>>> definitions. 
> 
> Using an address of 0x1000 to read the byte at addresss 0x1000
> is a "bad definition"?
> 
>>> The macros do exactly what they were designed to; making the
>>> software portable. Changing one endian definition flag is
>>> easier than changing umpteen register definitions.
> 
> Yes, I realize that the macro definition allows you to use
> address definitions that are wrong for the hardware
> configuration.  I prefer using address definitions that are
> right.
> 
>> Maybe its me, but it seems you are describing broken hardware.
>> The bus subsystem (external to the CPU) should be responsible
>> for handling the byte lanes correctly. On bi-endian boards,
>> this usually means adding a jumper/switch so that the bus
>> controller knows what endianness to use. If a bi-endian board
>> requires different addresses for byte registers depending on
>> endianess, then it is broken IMO. Some XScale boards that I am
>> familiar with do not require address gymnastics based on
>> endianess. A byte address is the same with both endianesses.


-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Grant Edwards]

On Thu, Jul 11, 2002 at 11:32:14AM -0400, Mark Salter wrote:
> 
> > On Thu, Jul 11, 2002 at 10:17:31AM -0400, Mark Salter wrote:
> 
> >> > You are using register definitions that are munged for
> >> > big-endian hardware and clearly expected to be used by
> >> > non-portable (big/little endian) software.
> 
> Careful with attributions. I didn't write that.

You can tell that from the quoting levels.

-- 
Grant Edwards
grante@visi.com

-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Mark Salter]

> On Thu, Jul 11, 2002 at 10:17:31AM -0400, Mark Salter wrote:

>> > You are using register definitions that are munged for
>> > big-endian hardware and clearly expected to be used by
>> > non-portable (big/little endian) software.

Careful with attributions. I didn't write that.

--Mark

-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Grant Edwards]

On Thu, Jul 11, 2002 at 10:17:31AM -0400, Mark Salter wrote:

> > You are using register definitions that are munged for
> > big-endian hardware and clearly expected to be used by
> > non-portable (big/little endian) software.

I'm using register definitions that are correct for my
hardware.  I'm using a big-endian bus-controller, and if I want
to access the byte at address X, why should I be expected to
use some other address?

> > If you want to use them with eCos macros, it will clearly fail
> > since the eCos macros are endian safe.

But the macros don't access the byte I specify.

> > How's that? Well, the device you are writing to is activated
> > (chip select) by matching of address lines A31-A2. I.e.
> > addresses 0x71c, 0x71d, 0x71e and 0x71f all match and enable
> > your device for access. It doesn't care about anything else.

It most certainly does.  My bus controller has four byte-select
lines, and if you futz with the lower two address lines, then
the wrong byte select line goes active.

> > So when the chip select is right, you need to get the data bits
> > right. Depending on the endianess of the CPU, you need to put
> > the data in either D0-7 or D24-D31 for 8bit access. You do that
> > by changing A1-A0.

The byte select logic in the bus controller handles that.

> > So A1-A0 should be depending on the CPU endian mode, and
> > *nothing else*.

Well, I don't think so. If I'm running a big-endian,
byte-addressable system and when I want the high order byte of
the word at 0x1000, then I read byte address 0x1000.  That's
the definition of big-endian.  It sounds to me like you've
decided that little-endian is "right", big-endian is "wrong",
and those of us with big-endian hardware should use macros to
make it look like we've got little-endian hardware.

> > If you don't care about portability, and want to use
> > definitions that are not suitable for porting, by all means
> > don't use the eCos macros.
> >
> > But don't blame the macros for bothing it when fed bad
> > definitions. 

Using an address of 0x1000 to read the byte at addresss 0x1000
is a "bad definition"?

> > The macros do exactly what they were designed to; making the
> > software portable. Changing one endian definition flag is
> > easier than changing umpteen register definitions.

Yes, I realize that the macro definition allows you to use
address definitions that are wrong for the hardware
configuration.  I prefer using address definitions that are
right.

> Maybe its me, but it seems you are describing broken hardware.
> The bus subsystem (external to the CPU) should be responsible
> for handling the byte lanes correctly. On bi-endian boards,
> this usually means adding a jumper/switch so that the bus
> controller knows what endianness to use. If a bi-endian board
> requires different addresses for byte registers depending on
> endianess, then it is broken IMO. Some XScale boards that I am
> familiar with do not require address gymnastics based on
> endianess. A byte address is the same with both endianesses.

-- 
Grant Edwards
grante@visi.com

-- 
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] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1)

[Mark Salter]

> You are using register definitions that are munged for big-endian
> hardware and clearly expected to be used by non-portable (big/little
> endian) software.

> If you want to use them with eCos macros, it will clearly fail since the
> eCos macros are endian safe.

> How's that? Well, the device you are writing to is activated (chip
> select) by matching of address lines A31-A2. I.e. addresses 0x71c,
> 0x71d, 0x71e and 0x71f all match and enable your device for access. It
> doesn't care about anything else.

> So when the chip select is right, you need to get the data bits right.
> Depending on the endianess of the CPU, you need to put the data in
> either D0-7 or D24-D31 for 8bit access. You do that by changing A1-A0.

> So A1-A0 should be depending on the CPU endian mode, and *nothing else*.

> If you don't care about portability, and want to use definitions that
> are not suitable for porting, by all means don't use the eCos macros.

> But don't blame the macros for bothing it when fed bad definitions. The
> macros do exactly what they were designed to; making the software
> portable. Changing one endian definition flag is easier than changing
> umpteen register definitions.

Maybe its me, but it seems you are describing broken hardware. The
bus subsystem (external to the CPU) should be responsible for 
handling the byte lanes correctly. On bi-endian boards, this usually
means adding a jumper/switch so that the bus controller knows what
endianness to use. If a bi-endian board requires different addresses
for byte registers depending on endianess, then it is broken IMO. Some
XScale boards that I am familiar with do not require address gymnastics
based on endianess. A byte address is the same with both endianesses.

--Mark

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