Just some random input. QEMU supports emulating a few ARM boards. One of those is the cubieboard which OpenBSD already supports. Unfortunately it looks like that even though it does emulate its ethernet controller, it does not emulate any storage.
Qemu also supports emulating a „virt“ machine. This is essentially a basic machine that only provides virtio devices. This means that if you use the virtio mmio interface you can get access to peripherals like storage, ethernet, random number generator, and some more. Now this platform is very simple to support if you have FDT, but even without it, it’s easily doable. As far as I know that platform is supported by Bitrig and recently also FreeBSD. The people who work on the ARM subtree already have enough on their plates to worry about another platform. If you want this to happen, feel free to step up and have a look. It’s not that hard and I bet it’s a chance for people to get into hacking OpenBSD. \Patrick > Am 24.05.2015 um 01:41 schrieb Edwin Amsler <edwin...@gmail.com>: > > >> On May 23, 2015, at 5:26 PM, Scarlett <scarlett@entering.space> wrote: >> >>> On 23/05/2015 22:19, Douglas Beattie wrote: >>> I think there is a difference between building OpenBSD "on real hardware" >>> and building port binaries for ARMv7 which are intended to run across all >>> of the ARMv7 target ports. >>> >>> And I think the concern should be less about “OS bugs and emulator bugs” >>> since (1.) you’re not building the OS, and (2.) ARM emulation is quite >>> mature >>> with several standard platform configurations which may be targeted >>> (including >>> ARMv7). >>> >>> A dual-Xeon-quad-core server (8 cores, 16 threads) with 48G of RAM can >>> easily host 10 or more VMs, and do a distributed build across QEMU/ARM >>> running on each of the VMs. The resulting compiled code for a port ‘binary’ >>> distribution should be no different regardless of where it was actually >>> built. >>> >>> So, what then is the reason (other than philosophical) that an OpenBSD port >>> does not yet exist for QEMU/ARM ? If you can no longer blame the hardware >>> to such a degree, then either your port builds should become more reliable, >>> or >>> there is still a problem with the OS arch. >>> >>> The behavior of emulated hardware is repeatable and fairly predictable, >>> especially >>> if it’s a mature emulation platform (i.e. having been pounded on and >>> considered >>> stable already for multiple OS). Taking the hardware (excuse) out of the >>> equation, >>> you could move forward with efforts to continuously build and validate >>> ARMv7 ports >>> with every iteration of OpenBSD. >>> >>> And yes, the native building of the OS itself is still a great stress test >>> for these up-and- >>> coming ARMv7 hardware platforms. But the building of port packages -- or >>> the choice >>> of making excuses to not build or provide them -- is really a very separate >>> issue. >>> >>> >>>> On 2015-05-23, Stuart Henderson wrote: >>>> Not particularly. If the machines and/or OS arch are reliable in the >>>> first place it's not a problem to spread builds across more machines. >>>> But in reality, it's not very reliable, so 1) adding machines just >>>> means babysitting additional crashes, and 2) if emulation is used >>>> instead of real machines, then you're dealing with both OS bugs and >>>> emulator bugs. >> >> Why are OS bugs not a concern when doing ports builds? The OS must be >> suitably stable to complete the build, unless you're advocating for >> cross-compilation. I could point to NetBSD's history with toolchain bugs and >> cross-built executables not actually running on the target platform as being >> valid reasons for avoiding it. It's probably unfair to single out NetBSD >> here, plenty of other projects have had these headaches. >> >> I think the reason for there being no arm-on-qemu support is the usual >> supect: it's not a priority for any developer. >> >> Maybe it's easy to accuse others of making excuses when you aren't >> responsible for making sure the builds work and aren't hacking on the port. >> >> (whoops, I forgot to CC the list). >> > > Building virtual is a solid idea. It's just not fun, so it's not going to > happen. Hell, Qemu support is likely going to be easier than real hardware. >
