> IIRC both UEFI and ACPI define only little-endian data structures.
> The code does not attempt to convert these into CPU endianness
> at the moment. In theory it could be changed to support either, but
> this seems non-practical for the UEFI runtime services that require
> calling into firmware code in little-endian mode.
Hi Arnd
Thanks for the info. So we can assume the CPU is little endian. That
helps narrow down the problem.
> > If this is the bus controller endianness, are all the SoCs you plan to
> > support via ACPI the same endianness? If they are all the same, you
> > can hard code it.
>
> NXP has a bunch of SoCs that reuse the same on-chip devices but
> change the endianness between them based on what the chip
> designers guessed the OS would want, which is why the drivers
> usually support both register layouts and switch at runtime.
> Worse, depending on which SoC was the first to get a DT binding
> for a particular NXP on-chip device, the default endianness is
> different, and there is either a "big-endian" or "little-endian"
> override in the binding.
>
> I would guess that for modern NXP chips that you might boot with
> ACPI the endianness is always wired the same way, but I
> understand the caution when they have been burned by this
> problem before.
So it might depend on if NXP is worried it might flip the endianness
of the synthesis of the MDIO controller at some point for devices it
wants to support using ACPI?
Does ACPI have a standard way of declaring the endianness of a device?
We don't really want to put the DT parameter in ACPI, we want to use
the ACPI way of doing it.
Thanks
Andrew
