An alternative to Linaro’s HWPacks

For the past couple of weeks I’ve been playing with a variety of boards, and a single problem kept raising its head over and over again, I needed to build test images quickly in order to be able to checkout whether or not these boards had the features that I wanted.

This lead me to investigating tools around building images for these boards. And the tools I came across for each of these boards were absymal to say the least. All of them were either very board specific or were not versatile enough for my needs. Linaro’s HWPack’s came very very close to what I needed, but still had some of the following limitations :

• HWPack’s are inflexible in terms of partitioning layout, the entire partitioning layout is internal to the tool, and you could only specify one of three variations of the partition layout, and not control anything else, such as start sectors of the partitions.
• HWPack’s are inflexible in terms of bootloader flashing, as far as I can tell, there was no way to specify the start sector, the byte size and other options that some of these boards were passing dd to flash the bootloader to the image.
• HWPacks, as far as I could tell, could not generate config files that would be used by u-boot at boot.
• HWPack’s only support Apt.

So with those 4 problems to solve, I set out writing my own replacement for Linaro’s HWPack’s , and lo and behold, you can find it here. ( I’m quite terrible at coming up with awesome names for my projects, so I chose the most simple and descriptive name I could think of 😉

Here’s a sample config for the ODROID C1, a neat little board from HardKernel.

The rootfs section

You can specify a rootfs for your board in this section, it will take a url to the rootfs tar and optionally a md5sum for the tar.

The firmware section

We currently have 2 firmware backends for installing the firmware ( things like the kernel, and other board specific packages ). One is the tar backend which, like the rootfs section, takes a url to the firmware tar and optionally a md5sum and the Apt backend. I only have time to maintain these 2 backends, so I’d absolutely love it if someone could write more backends such as yum or pacman and send me a pull request.

The tar backend will copy everything from the boot/* folder inside the tar onto the first partition, and anything inside the firmware/* and modules/* folder into the rootfs’s /lib folder. This is a bit implicit and I’m trying to figure out a way to make this better.

The apt backend can take multiple apt repos to be added to the rootfs and a list of packages to install afterwards.

The bootloader section

The bootloader has a :config section which will take a ERB file to be rendered and installed into both the rootfs and the bootfs ( if you have one ).

Here’s a quote of the sample ERB file for the ODROID C1:

	# Boot Arguments
	setenv bootargs "root=UUID=<%= rootfs_blkid %> rootwait ro ${condev} no_console_suspend vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout_mode} ${disableuhs} ${hdmi_hpd} ${hdmi_cec} ${enabledac}"
	# Booting
	fatload mmc 0:1 0x21000000 <%= uImage %>
	fatload mmc 0:1 0x22000000 <%= uInitrd %>
	fatload mmc 0:1 0x21800000 boot/meson8b_odroidc.dtb
	fdt addr 21800000

view raw

boot.ini.erb

hosted with ❤ by GitHub

This allows me to dynamically render boot files depending on what kernel was installed on the image and what the UUID of the rootfs is. You can in fact access more variables as described here.

Moving on to the :uboot section of the bootloader, you can specify as many stages as you want to flash onto the image. Each stage will take a :file to flash and optionally :dd_opts, which are options that you might want to pass to dd when writing the bootloader. The stages are flashed in the sequence that is declared in config.yml and the files are searched for in the rootfs first, failing which they’re searched for in the bootfs partition, if you have one.

The login section

The login section is quite self-explanatory and takes a user, a password for the user and a list of groups the user should be added to on the target image.

The login section is optional and can be skipped if your rootfs already has a pre-configured user.

At the moment I have configs for the ODROID C1, Cubox-I ( thanks to Solid Run for sending me a free-extra board! 🙂 and the Raspberry Pi 2.

If you have questions send me an email or leave them in the comments below, and I’ll try to answer them ASAP :).

If you end up writing a config for your board, please send me a PR with the config, that’d be most awesome.

PS: Some of the most awesome people I know are meeting up at Randa next month to work on bringing Touch to KDE. It’d be supremely generous of you if you could donate towards the effort.