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

[Grant Edwards <grante at visi dot com>]

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