On Mon, Nov 12, 2018 at 10:41 PM Mark Millard <mark...@yahoo.com> wrote: > > 11.x: > o 11.2-STABLE armv6 BANANAPI > o 11.2-STABLE armv6 BEAGLEBONE > o 11.2-STABLE armv6 CUBIEBOARD > o 11.2-STABLE armv6 CUBIEBOARD2 > o 11.2-STABLE armv6 CUBOX-HUMMINGBOARD > o 11.2-STABLE armv6 RPI-B > o 11.2-STABLE armv6 RPI2 > o 11.2-STABLE armv6 PANDABOARD > o 11.2-STABLE armv6 WANDBOARD > > 12.x+ (I got the list from a 13.0 snapshot announcement): > o 13.0-CURRENT armv6 RPI-B > o 13.0-CURRENT armv7 BANANAPI > o 13.0-CURRENT armv7 BEAGLEBONE > o 13.0-CURRENT armv7 CUBIEBOARD > o 13.0-CURRENT armv7 CUBIEBOARD2 > o 13.0-CURRENT armv7 CUBOX-HUMMINGBOARD > o 13.0-CURRENT armv7 RPI2 > o 13.0-CURRENT armv7 PANDABOARD > o 13.0-CURRENT armv7 WANDBOARD > o 13.0-CURRENT armv7 GENERICSD > > So as of 12.x+ most are armv7 --as are most new ones > expected to be. > > As stands, in my amd64 -> armv7 13.0 cross-build activity, > uname -p and the like under the chroot context are > returning armv6 instead of armv7 unless I override via > a UNAME_p definition. > > This appears to trace back to: bsd-user/arm/target_syscall.h > and its: > > #define TARGET_HW_MACHINE "arm" > #define TARGET_HW_MACHINE_ARCH "armv6" > > and lack context sensitivity, such as to the FreeBSD version > that it is in use under. >
Indeed, I opened this a couple of hours ago: https://github.com/seanbruno/qemu-bsd-user/pull/70 -- It turns out this is basically wrong, though I'm not sure immediately how to rectify. I don't think we can reasonably decide at compile-time what this should look like since all 32-bit ARM are shoved into this one target, so perhaps the right answer is that armv6 and armv7 need to split off from arm.arm and we use a check like the one in the above PR. CC'ing imp for a wisdom drop. _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"