Turrix mox boot process

I got my mox in the mail yesterday, yay! I had forgotten that it needed an sdcard to boot, so after installing the sdcard image via the mox recovery mode, I was ready to explore.

I’m interested in using the pps-gpio kernel module, which requires a device tree change. So I investigated the boot process to see where the device tree was coming from. I wanted to write all this down as I don’t think it’s documented anywhere.

I see an 8MB SPI flash stores the bootloader/uboot:

root@mox:~# dmesg | grep m25
[    3.712172] m25p80 spi0.0: w25q64dw (8192 Kbytes)
root@mox:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "secure-firmware"
mtd1: 00160000 00010000 "u-boot"
mtd2: 00010000 00010000 "u-boot-env"
mtd3: 00660000 00010000 "Rescue system"
mtd4: 00010000 00010000 "dtb"

I’m guessing mtd0 contains the first bootloader, which then loads uboot. The u-boot-env can be examined with the command fw_printenv. I assume u-boot starts with the command bootcmd:

root@mox:~# fw_printenv bootcmd
bootcmd=run mox_boot

mox_boot then decides to run through the rescue process or the normal process.

The rescue process runs the script rescue_bootcmd, which loads the kernel and initramfs from mtd3 and boots that. The initramfs file /init is a shell script that decides which type of recovery to do. It does not need an sdcard to work.

The regular boot process starts at mox_distro_bootcmd, and has a few options for how things are booted. When booting from the sdcard, the order of scripts currently in use is: distro_bootcmd > bootcmd_mmc0 > mmc_boot > scan_dev_for_boot_part > scan_dev_for_boot > scan_dev_for_scripts > boot_a_script

This loads /boot/boot.scr from the sdcard and runs it as an uboot script. boot.scr loads /boot/armada-3720-turris-mox.dtb as the device tree, /boot/Image as the kernel, sets the boot arguments, and then boots the kernel.

So if I want to change the device tree, it should just be a change to /boot/armada-3720-turris-mox.dtb. I assume that file will be overwritten with OS updates, but that’s good enough to start with.

Hopefully this is helpful to someone. Please let me know if I got any details wrong.

1 Like

Almost correct! Awesome work! :slight_smile: Few more details to add, rightfully spotted dtb in NOR is a copy of DTB just in case you don’t have the correct one anywhere and is used as backup in case u-Boot doesn’t find any. Apart from that for your purpose, u-Boot runs /boot.scr which is in fact symlink pointing to @/booot/boot.scr where @ is a btrfs subvolume that is used as rootfs. Symlink is not modified by updates. So in theory, you could replace the symlink with file that will point to differently named dtb and you are safe as long as we wouldn’t need to alter boot parameters.

2 Likes