Home > Allwinner H-Series, Operating Systems > NetBSD is Now Running on Allwinner H3 Boards

NetBSD is Now Running on Allwinner H3 Boards

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-C2, BegleBone Black. Allwinner A20/A31, 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.

  1. tkaiser
    July 11th, 2017 at 16:33 | #1

    ‘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).

  2. July 11th, 2017 at 16:37 | #2

    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.

  3. Jerry
    July 12th, 2017 at 03:56 | #3

    I’m guessing few questions about the Mali support will appear any time soon.

  4. jqpabc123
    July 12th, 2017 at 19:14 | #4

    “…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?

  5. July 12th, 2017 at 19:21 | #5

    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.

  6. tkaiser
    July 12th, 2017 at 20:38 | #6

    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.

  7. cortex-a72
    July 13th, 2017 at 02:06 | #7

    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

  1. No trackbacks yet.