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

[Dirk Sigurdson <dsigurds at pacbell dot net>]

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