[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

booting with linux



Hi,

I managed to boot my odroid-hc1 with linux as boot loader.

i.e. no need to have u-boot or grub any more. The code that replaces the driver and hardware side is the linux kernel, with a small patch set: https://lkml.org/lkml/2020/1/30/221

patch 3 of that series contains the hsinit process. I don't use it, you can skip the patch.

The user facing side, e.g. a boot menu or a dhcp client, tftp client or other stuff, is implemented using u-root, a busybox like environment, but written in go.

The boot process works by running kexec on the new kernel+dtb+initrd+commandline. There is also a patch to boot windows, not sure if it ended in mainline. But I found a slide deck telling me: that would work too (if anyone needs such compatibility).

One small issue comes from the hardware: with odroid-hc1 I need to use 3 firmware blobs signed by hardkernel/samsung (bl1, bl2, trustzone), and they limit the boot loader to 1mb in size.

Here is how I work around it:
1.) compile a tiny kernel. It has kexec and vfat support, but little else. This one needs to patch to work as bootloader.
2.) compile kexec as a static linked binary with libmusl.
3.) compile a tiny init that runs kexec with the right parameters. As an alternative I could patch above - both would work.
4.) compile u-root, bb setup. Also add above static kexec binary to this cpio.
5.) compile a normal sized kernel with many filesystems and network support (or whatever capability I would want to see in a bootloader environment). Link in above cpio.
6.) have  vfat partition (starting at 2mb), copy all those binaries except the tiny kernel on it.
7.) standard script with dd commands from samsung/hardkernel to install the blobs bl1, bl2 and trustzone as well as the tiny kernel into the first 2mb of the sd card.

So far so good. I will post instructions or add them to the wiki once things are a bit more polished and tested, but it already works so far for me.

So here are a few questions:

Debian has infrastructure built around tools like grub and u-boot and supporting packages like flash-kernel. How can I tap into this, but provide an alternative implementation based on the linux kernel? e.g. it would still be helpful to generate a grub.conf (as u-root localboot can read that and provide a menu etc.). But I wouldn't want grub installed, and I wouldn't want any grub-install command to be run (which would either fail or overwrite data from linux as bootloader). Any idea how I can tie into the existing stuff?

So I think technically this is great, if anyone writing support for a new hardware doesn't have to work on a bios or firmware, and a boot loader and a kernel - but instead only on the kernel, as nearly all code is shared.

But then special situations that end up with 3 binaries all build from linux kernel source sound like a maintenance hell (a tiny kernel to fit into the 1MB limit, a larger kernel without modules based on a config focused on booting (local or network), and the regular modular debian kernel).

I wouldn't want to make the work of the kernel team more difficult and wouldn't want to throw it on them. But then I'm not sure if additional packages that are based on the linux kernel source are great either. What is a good direction for this?

A statically linked kexec binary sounds simple enough. A tiny init to run it (or a modification of kexec to act as a specialized init), both seems like simple code that could be packaged. Also u-root is a simple go source code producing a single binary (cpio file), could be easy to package. Any thoughts?

Thanks, Andreas

Reply to: