Intro In my previous posts I have shared

my first experience with debos and how to run debos in a container. In today’s post, I’d like to present how can we use all of that to generate base Debian image for an ARM board. My board of choice for this particular example will be the HummingBoard Edge. The post is inspired by the feedback from the new users (such as this one) that there are no end-to-end examples how to quickly start using this tool.

HummingBoard Edge upstream support The

Hummingboard Edge is described in the Linux by the hummingboard2 devicetree. It is supported since the 4.16 Linux release. I have decided to use the sid flavor of Debian in order to get quite recent kernel version (4.18+98 at the moment of writing).

debos recipe

The full recipe and all other files are available in the 3mdeb/debos-recipes repository on github. I wanted to create a really base system image, just to try out that it boots properly. I took the existing RPI3 recipe as a starting point. As stated in the previous paragraph, the sid flavor of Debian will be used, hence following action in the recipe file appears: – action: debootstrap suite: “sid” components: – main mirror: https://deb.debian.org/debian variant: minbase Some of the following actions are:

  • setting the hostname with a run action:

    • action: run description: Set hostname chroot: true command: echo HummingBoard2 > /etc/hostname

note that we can decide with the chroot flag whether the command shall be executed on the host or in the chrooted environment * copying over extlinux config files with an overlay action:

The extlinux config I came up with could have been definitely improved (e.g. to be autogenerated, to use UUID for root partition etc.), but is perfectly enough for the purpose of this demonstration. * installation of the Linux and U-Boot packages:

image-partition. We can specify there the final image size, partitions to be created as well as their mount points. Note that the /etc/fstab entries will be automatically added for created partitions. # leave 4MB offset at the image start for U-Boot installation – action: image-partition description: Create partitioned image imagename: {{ $image }} imagesize: 1GB partitiontype: msdos mountpoints: – mountpoint: / partition: root partitions: – name: root fs: ext4 start: 4MB end: 100% flags: [ boot ] The substantial difference from the

RPI3 recipe is the bootloader. Unlike many other ARM boards, RPI3 does not use the U-Boot installed directly (into not partitioned area) at the start of the image file (or block device). As shown in the mx6cuboxi README, SPL U-Boot shall be installed into the device as follows: sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1; sync sudo dd if=u-boot.img of=/dev/mmcblk0 bs=1k seek=69; sync In

debos, we can use the raw action and use build-in sector keyword to install binaries at required offsets: # ‘filesystem’ origin points to the target root filesystem # 2 sectors = 1K # bs=1K seek=1 – action: raw description: Install SPL to the image origin: filesystem source: /usr/lib/u-boot/mx6cuboxi/SPL offset: {{ sector 2 }}

filesystem as an argument for the origin in order to gain access to files located in the filesystem we have generated in the previous steps. This feature does not seem to be documented somewhere, but I found such map in the code. Other useful arguments might be: artifacts or recipe. The final actions include deploying filesystem to image and compressing the final image. Optionally, the bmap file can be generated. – action: filesystem-deploy description: Deploy filesystem to the image

Image building I’ve used our

debos docker container to perform debos build. I chose to save the run script in my PATH for easy execution: debos-docker debimage-hb2.yaml The end result looks like:

Image flashing

The usual way No explanation needed for the

dd command: gzip -cdk debian-hb2.img.gz | sudo dd of=/dev/mmcblk0 bs=16M status=progress

The fancy way Thanks to the

bmap file we created, we can use bmaptools to flash the image. Explanation of this tool could be itself a story for another post. More details can be found in the bmaptool documentation. We might need to install the tool first: sudo apt install bmap-tools Image can be flashed with following command:

Comparison It is a good opportunity to show a quick comparison between those two:

  • dd – 1 minute 18 seconds

    time sh -c ‘gzip -cdk debian-hb2.img.gz | sudo dd of=/dev/mmcblk0 bs=16M status=progress && sync’ 1000000000 bytes (1,0 GB, 954 MiB) copied, 32 s, 31,2 MB/s 0+27202 records in 0+27202 records out 1000000000 bytes (1,0 GB, 954 MiB) copied, 78,7137 s, 12,7 MB/s sh -c 6,62s user 1,27s system 10% cpu 1:18,73 total

  • bmaptool – 38 seconds

    time sudo sh -c ‘bmaptool copy –bmap debian-hb2.img.img.bmap debian-hb2.img.gz /dev/mmcblk0 && sync’ bmaptool: info: block map format version 2.0 bmaptool: info: 244141 blocks of size 4096 (953.7 MiB), mapped 110274 blocks (430.8 MiB or 45.2%) bmaptool: info: copying image ‘debian-hb2.img.gz’ to block device ‘/dev/mmcblk0’ using bmap file ‘debian-hb2.img.img.bmap’ bmaptool: info: 100% copied bmaptool: info: synchronizing ‘/dev/mmcblk0’ bmaptool: info: copying time: 38.0s, copying speed 11.3 MiB/sec sudo sh -c 8,48s user 1,26s system 25% cpu 38,209 total

Image running The boot log:

Conclusion As I have shown in this post,

debos can be quite easily used for building Debian image for an ARM platform. This is especially true if such board has good mainline support and the Linux and U-Boot packages for it are already available in the Debian package feed. I hope that my post can be helpful for new debos users and that my recipe gets merged into the debos-recipes, so it can be easily accessible.