[PATCH v2 2/5] m68k: Fix writew(), writel(), readw(), readl() endianness

Daniel Palmer daniel at thingy.jp
Wed Apr 8 15:40:15 CEST 2026


Hi Angelo,

On Wed, 8 Apr 2026 at 22:26, Angelo Dureghello <angelo at kernel-space.org> wrote:
> yes, thanks, please try to find a solution protecting coldfire for now.

So for now I have put #ifdefs in so coldfire retains its current behaviour.

> I will try to understand better why Linux operates differently from u-boot,
> i think pci was involved here but actually i don't remember, need to
> study this deeper.

I thought maybe this change in m68k might be recent but in Linux it
seems to have been there since the import into git 22 years ago.

In the linux docs (https://docs.kernel.org/driver-api/device-io.html)
it says this:

Note: On some architectures, the normal readl()/writel() functions
traditionally assume that devices are the same endianness as the CPU,
while using a hardware byte-reverse on the PCI bus when running a
big-endian kernel. Drivers that use readl()/writel() this way are
generally not portable, but tend to be limited to a particular SoC.

So I think maybe coldfire got a "reads native endian, no swap"
readl()/writel() and then when PCI support was added a hack was
needed. But somehow normal m68k got it the other way around. <shrug>

Anyhow, sorry again for breaking your board.

Cheers,

Daniel


More information about the U-Boot mailing list