unexpected little endian read and write implementations on PPC platform
Simon Faas
Hi,
I am involved in a pilot project to port Vxworks applications to
embedded linux (Monta Vista kernel).
This linux kernel needs to be adapted to run on a custom made PPC
based platform. This also involves adapting or developing linux device
drivers to fit our specific hardware and requirements.
When we use the functions readw and writew (io.h) to perform memory
mapped IO (as advised in O'Reilly's Linux Device drivers 2nd ed) or to
approach the PPC registers we see the bytes come out
in the 'wrong' order. This can be explained by looking at the
implementation of the read and write calls. They use the out_le16 and
in_le16 functions. Looking at the assembly instructions (e.g. lhbrx)
one can see that the bytes are indeed switched.
This is not what we expected. Does this mean we have some sort of
kernel configuration problem? Why does the kernel use little endian
functions on a big endian platform (there are also functions available
like out_be16)?
Simon
Steven Rostedt
> When we use the functions readw and writew (io.h) to perform memory
> mapped IO (as advised in O'Reilly's Linux Device drivers 2nd ed) or to
> approach the PPC registers we see the bytes come out
> in the 'wrong' order. This can be explained by looking at the
> implementation of the read and write calls. They use the out_le16 and
> in_le16 functions. Looking at the assembly instructions (e.g. lhbrx)
> one can see that the bytes are indeed switched.
>
This is because the most common IO is PCI, which is handled in little
endian. Now some PPC allow for the bridge to do byteswapping so the
reads and writes look like big endian. Yours may be doing this, or you
may not be using PCI. Or, the memory space of the device is bigendian.
> This is not what we expected. Does this mean we have some sort of
> kernel configuration problem? Why does the kernel use little endian
> functions on a big endian platform (there are also functions available
> like out_be16)?
>
Yes, look in include/asm-ppc/io.h. You will also see the in_be and
out_be functions. To solve your problem, either change io.h to include
your board in using straight reads (like the CONFIG_APUS) or us the
__raw_read __raw_write macros.
-- Steve