[PATCH] fix root cause of NAND trouble

Andy Green andy at openmoko.com
Sat Nov 1 14:09:42 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Sat, Nov 01, 2008 at 03:19:03AM -0200, Werner Almesberger wrote:
|> Andy Green wrote:
|>> I never used big-endian ARM, but it seems neither of us are quite sure
|>> what it'd do.
|> I haven't even found how you're supposed to switch to big-endian mode.
|> They mention that there's a BIGEND signal to the core, but there's no
|> indication of how you'd set it. Perhaps yet another feature that didn't
|> work, so it was dropped halfway through the design.
|> Hmm, I wonder if it might be BWSCON[0] :-)
|>> It's the kind of thing you'll get jumped on for by the Lictors of
|> Heh, at least for 2440, we should be safe - if you look at the register
|> map, there's a lot of registers that change address if going big-endian.
|> And of course, there's no provision in the kernel for easily switching
|> those addresses.
| As a note, is it really important to you to go big endian? I'm sure that
| things like readb can be changed to correctly swap the lower bits of the
| address, but we currently do not have any 'endianness' stuff for the
| 16 or 32bit registers. I've not tried any of the S3C series in anything
| other than little endian.

No we will never run big-endian AFAIK.  But the chips can do it... in
normal drivers and specifically in mac80211 code I wrote before it was a
big consideration at upstream to be clean for it.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list