[U-Boot-Users] Big endian-ness - Config option?
Wolfgang Denk
wd at denx.de
Wed Sep 1 15:26:10 CEST 2004
In message <637EA992-FC18-11D8-9008-000393C7979E at student.unsw.edu.au> you wrote:
>
> I've had two problems. The first has been that that the code uses the
> get_timer(x) function, which is not implemented properly on ARM. (It
Indeed, it seems to be broken.
> just returns the value of the OS counter, ignoring the value passed to
> it. I had to replace the get_timer stuff with get_timer_masked and
> reset_timer_masked. I could try fixing the arm implementation of
> get_timer, but figured you guys wouldn't want me touching that bit of
> code since other bits and pieces now depend on it. Is there some way of
> doing this nicely?
There should be no software depending on the broken behaviour. If
there was any, it must be fixed, too.
> The second was that one part of the code munges some bytes into a word
> to get them ready for writing. This is broken with respect to
> endian-ness, and breaks on my XScale running in little-endian mode. Is
> it possible (or appropriate?) to add a CFG_LITTLE_ENDIAN (or something
> similar)? Is there a better way of switching between the two? It would
> be nice if this code could be re-used without these sorts of problems.
If you use code from a board directory, no such endianess support is
needed, as the board will normally not change endianness (at least I
don't know of any of the supported boards which can be configured
both for BE or LE).
Endianess is considered an issue only in case you're using a generic
driver (like drivers/cfi_flash.*); but AFAIK the cfi_flash code
already deals properly with the target byteorder.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
- Fred Brooks, Jr., _The Mythical Man Month_
More information about the U-Boot
mailing list