Most people will run Linux kernel on development boards because it does the job, and that’s usually the only option. But others have been working on NetBSD kernel for Allwinner H3 boards, and it’s now running on various H3 boards with serial console, USB, Ethernet, SD card, and eMMC flash working.
Jared McNeill explains they first had to deal with low-level code to initialize the CPU and MMU, before using a U-boot layer to disguise NetBSD as the Linux kernel in order to load kernel and device tree file. The code then jumps to the generic ARM FDT implementation of initarm to relocate DTB data and perform other steps, and finally they can enumerated devices. This is explained in greater details in the aforelinked blog post on NetBSD website.
Jared tested the implementation on NanoPi NEO and Orange Pi Plus 2E, but others have reported success on various hardware based on Allwinner H3 processor. Other ARM development boards have been supported since 2015 by NetBSD 7.0 and greater with Raspberry Pi 2, ODROID-C1, BeagleBone Black, Allwinner A20/A31 boards, and others, but the work done on Allwinner H3 is different, as it’s the first implementation to use device tree, and eventually it should be possible to ship a single GENERIC evbarm kernel for all boards.
Thanks to Geokon for the tip.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
@cnxsoft:
‘Another person also leveraged Jared’s work to run FreeBSD to NanoPi NEO board instead of NetBSD’. This is not directly related to the new NetBSD approach above since Jared and other FreeBSD folks already work for a very long time on Allwinner boards. And FreeBSD in some areas set and still sets the pace (eg cpufreq/DVFS working way earlier on A64/A83T there compared to mainline Linux).
@tkaiser
Hmm OK. I saw that blog was posted on July 1st, so after the announcement of the device tree method, and he mentioned Jared’s work. But that’s indeed based on last year’s work.
I’m guessing few questions about the Mali support will appear any time soon.
“…disguise NetBSD as the Linux kernel in order to load…”
So some unique Linux features or operational modes have somehow been built into the hardware?
@jqpabc123
Not into the hardware. I think they are using an unmodified U-boot bootloader which is normally looking for Linux, so they made sure NetBSD looks like Linux from a U-boot perspective in order to load it the same way as a Linux kernel.
@cnxsoft
The real news got totally lost. Jared introduced a new NetBSD kernel that makes use of u-boot passing the DTB (device tree blob) over to the kernel (that’s the only reason they pretend to be a Linux). He was able to boot with a single kernel binary (using the same kernel config!) different sunxi architectures (sun8i-h3, sun8i-a83t and sun6i-a31). That’s the real news: one kernel for different SoCs and all the differentiation happening solely based on device tree definitions handed over by u-boot. Situation with Linux is still different here (we need to build one kernel per SoC family).
Now talking about hardware. If board vendors would all follow and put some small amount of SPI NOR flash on their boards pre-populated with an u-boot and the device specific DTB then all you need is a single generic NetBSD image on SD card, an USB thumb drive, an USB connected HDD or somewhere on the network and it would just boot. No more users struggling with downloading the wrong OS images (of course that would require that Linux can do the same in the future: boot one generic kernel on different SoC families without different kernel config).
We’re not already there (especially since majority of board makers is pretty ignorant) but once we’re there so much support problems are solved automagically.
@jqpabc123
it’s a very strange conclusion. it’s called not “unique features”, it’s just uboot is not exactly “universal” bootloader, it’s a mess for loading linux only. so others have to pretend they are linux. anyway, ideally, all those SoC vendors and board vendors should take care of supplying a really standard boot firmware. considering what a mess uboot code is, I don’t get it why all these, not direct their efforts at porting Tianocore to their SoCs/boards. and ACPI as well instead of pulled of from an absolutely different standard device tree. this way, the situation would be no worse than on PC. Imagine a blog post where a NetBSD developer happily reports he was successful on booting NetBSD on some PC! xD
NetBSD doesn’t support the Odroid C2, it supports the Odroid C1/C1+.