Re: [PATCH] arm64: Disable big endian builds with clang
From: Mark Brown <broonie@kernel.org>
Date: 2019-08-07 15:29:47
On Wed, Aug 07, 2019 at 02:56:19PM +0100, Mark Rutland wrote:
On Wed, Aug 07, 2019 at 02:05:27PM +0100, Mark Brown wrote:
quoted
As far as I know this has been broken for as long as we tried building and booting big endian kernels in clang. The compile works fine, it's just that the resulting binary doesn't seem to be working so well.
I've just had a go, and it works for me. Log below from a BE busybox, but I also have a BE buildroot filesystem working.
Copying Matt who can actually look at the jobs getting submitted. The rootfs we're using should be: https://storage.kernelci.org/images/rootfs/buildroot/arm64be/
From your log, it looks like the kernel is trying to launch init via binfmt_misc, using binfmt-464c. It could be that the file is corrupted somehow, or something's going wrong with binfmt. I haven't delved into that.
You can see the exact image being used in the reports I linked: https://storage.kernelci.org/next/master/next-20190730/arm64/defconfig+CONFIG_CPU_BIG_ENDIAN=y/clang-8/Image
Are you using the right filesystem (and is the kernel definitely identifying itself as BE in the Image header flags)?
I'm assured that we're using the same rootfs as the GCC BE builds, sadly neither of the labs that has boards configured to allow BE boots gives enough access for me to verify that personally.
This could be a dynamic loader issue -- my busybox is statically linked, and I'm not sure about my buildroot filesystem.
This could be platform-specific; I'm booting under a KVM/QEMU VM on ThunderX2, using virtio-block for storage.
It's failing on every single platform we're trying, that's not as many as it should be but it's still a bunch of physical platforms and like I say the variable is the compiler. A platform issue that only manifests in the handover to userspace on multiple boards doesn't seem like the most likely avenue.