Re: Running armv7 on aarch64
Kristof Provost <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 18 Oct 2022, at 20:18, Kristof Provost wrote: > On 18 Oct 2022, at 19:38, Mark Millard wrote: >> On 2022-Oct-18, at 09:53, Kristof Provost <[email protected]> wrote: >>> It’s not quite clear to me how this is supposed to work (now). On amd64 there’s a separate /libexec/ld-elf32.so.1, which we don’t have on aarch64. Is it supposed to be built? >>> >>> It’s broken on ab9293239c7d and e03b7883e97c at the very least. >> >> [I'm ignoring qemu, which I do not use. The below is from >> a Cortex-A72 aarch64 context that can execute Cortex-A7 >> armv7 code as well. Have you been using qemu?] >> >> Historically I've only been able to execute armv7 FreeBSD >> code on aarch64 FreeBSD via using the likes of, say, >> chroot'ing into an installed armv7 world in a directory >> tree that I created for such. (I manually split some >> liong-lineouptut for readabilty.) >> > Thanks for that! > > That’s at least part of what I was missing. Long story short, I’m trying to build an armv7 image on an aarch64 machine, and having issues with poudriere. I figured I was going to simplify things by executing the armv7 binary directly (to debug), but that’s missing a few steps and had me chasing down the wrong track. > > I can’t chroot into that armv7 jail, I still see errors like this: > > (kp@freebsd_current) /usr/local/poudriere/data/.m/main-pfSense_factory_ports_plus_devel/ref % sudo chroot . > ELF binary type "9" not known. > ELF binary type "9" not known. > chroot: /bin/sh: Exec format error > > But at least I think I’m looking in the correct direction now. > For those playing along at home, I believe I now understand why the above doesn’t work. This is a VMWare Fusion VM (preview of 09/22), and it appears to no longer support 32-bit arm. FreeBSD refuses to start a 32-bit arm binary due to the check in elf32_arm_abi_supported(). It reads the id_aa64pfr0_el1 special register, which doesn’t indicate 32-bit support. It lists 0x1101000011111111 as a value now. Simply removing the check allows the 32-bit binary to execute, but that crashes the VM, so isn’t very useful. Best regards, Kristof