Separate partition for the kernel and initramfs

[Icosa-Consulting]

Hello,

First off I'd like to thank you for this project! All other ones I tried for building boot images and rootfs are overly complex or poorly worded/instructed.

After a couple times making successful images I ran into a scenario on the R5S with an NVME disk installed and used in overlayfs mode, so I don't burn out the emmc. When I do an apt upgrade or apt full upgrade the kernel and initramfs files are saved in the /boot folder as expected, except that since the rootfs is in overlay mode the U-boot can only load the kernel and initramfs that was burned on it. I'm suspecting that the SPL can't use overlayfs and doesn't know about the new files.

That said, I propose having the /boot folder in a separate partition with a fat32 filesystem. This is the method that FirendlyElec uses so u-boot and SPL can access the /boot early on to load the kernel. The reason I suggest this instead of booting directly from the NVME disk is so I can use the NVME for data only and have a "factory default" image on the emmc, while still maintaining kernel updates.

I was thinking of a similar structure:

Sector: 0     8192    32768     524288
| IDBLOADER | UBOOT | KERNELFS | ROOTFS |

I tried to disect the partitioning in make_debian.sh, but was unsure how adding the KERNELFS would work.

Thoughts?

[inindev]

I ran into a scenario on the R5S with an NVME disk installed

This is how I run it: with a Samsung 500MB NVMe. A Samsung NVMe has built-in wear-leveling, so you will not need to worry about data loss. The eMMC is used to hold the u-boot bootloader and is not written to, so you will not have to worry about wear. You do not even need to partition the eMMC as the Rockchip bootloader sits before the first partition.

RELIABILITY (MTBF) 1.5 Million Hours Reliability https://semiconductor.samsung.com/us/consumer-storage/internal-ssd/970evoplus/

[Icosa-Consulting]

My issue is I want to be able to erase the NVME (during testing/debugging/factory resets) but still have a working boot on the eMMC, and by using overlayfs any changes are on the NVME drive. I didn't want the users to have to deal with imaging the NVME should it fail. I have it setup this way now, no wear on the eMMC just the NVME. I want to be able to maintain a separation of concerns and having the boot folder it's own partition works in this scenario. I can dig more into the script and see if I can make it work.

[inindev]

The visionfive v2 image I wrote uses three partitions:

    # partition table sector offsets
    local sec_spl=4096
    local sec_itb=8192
    local sec_rfs=16384

https://github.com/inindev/visionfive2/blob/main/debian/make_debian_img.sh

note how I extended the functionality of parition_media, format_media, and mount_media

also, the types of 2e54b353-1271-4842-806f-e436d6af6985 and 5b193300-fc78-40cd-8002-e86c45580b47 are specific to the visionfive and you wont use those. https://en.wikipedia.org/wiki/GUID_Partition_Table

[inindev]

That said, I propose having the /boot folder in a separate partition with a fat32 filesystem.

fwiw: modifying u-boot to look in a different place is not a difficult thing to do

[Icosa-Consulting]

Thanks John.

I’ve tried to customize Uboot a few times with make menuconfig. Every time I go to recompile it I always get some missing CONFIG_ variables, even though the choices are available in the menu, when using the nanopi-r5s_defconfig. So suffice to say I haven’t had much success with a custom uboot yet. I’ll keep trying though.

Thanks, Cliff.

[inindev]

I am probably over-simplifying the u-boot approach, but wouldn't it be just look for a file in /overlay/upper/boot/ first and if it does not exist, then go look in /boot/?

I do not use overlayfs much, so there are probably better resources out there on getting the two to work and the separate boot partition approach you are considering is a well known pattern.

[Icosa-Consulting]

The overlayfs is a kernel module so there’s no access to it prior to loading the kernel afaik.

Even though the overlay on the NVME is just ext4 I tried to load NMVE PCIe in the bootloader and it sadly failed. So for simplicity sake I though it just easier to use stock uboot and have the kernel in its own partition. There are mixed opinions I’ve read about what Uboot should and shouldn’t be doing, and I surmised that keeping it simple would save future headaches.