Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On 15-03-2021 14:47, Stefano Babic wrote:
Hi Mike,
On 15.03.21 14:13, Mike Looijmans wrote:
For software updates, I want to have what would have gone into the
boot partition of the WIC image as a separate file.
If I want to have the contents of the rootfs as an ext4 image, I can
just specify IMAGE_TYPES="ext4" in my image recipe.
> This image I can feed to SWUdate and write to the rootfs storage.
But I also want to be able to update the boot partition (for example,
the raspberrypi has the annoying property that devicetree and kernel
reside here).
This is very annoying, but you could also get rid of it. You can
install kernel and device tree in your rootfs (then they are located
in /boot as usual), and you switch to U-Boot ( RPI_USE_U_BOOT = "1").
The proprietary bootloader will start U-Boot instead of kernel, and in
u-boot you can load kernel and device tree from your rootfs.
That's what I did on other boards, but for the RPi that's not enough.
There's also firmware there, which interacts with the kernel, and the
firmware is altering the devicetree too. It's pretty likely that the
firmware needs an update too when the kernel gets a big update.
If I create a WIC image, the boot partition is in there with the
proper files (from IMAGE_BOOT_FILES) so I would really like to re-use
that code. I could create the wic image and then cut out the part I
want, but that doesn't seem particularly nice.
You can add vfat support for IMAGE_FSTYPES, and then you can build an
image (you can just take the files you have in IMAGE_BOOT_FILES).
But that's *exactly* my problem: How do I get these IMAGE_BOOT_FILES
into an image of sorts? Just setting IMAGE_FSTYPE="vfat" will put the
rootfs contents in there, not the bootfiles I'm after.
What I want to do at update time is to write the new boot partition
to another location on disk, and then adjust the partition table to
make the first partition entry point to the new copy. That way, in
case of unexpected failure (power loss for example), the device
remains bootable.
This does not seem to be atomic. It remains the risk that partition
table gets corrupted and then even the first bootloader cannot run. If
you want to have a power-cut safe way to update is not enough.
It's not perfect but it's close enough. The partition table resides in a
single sector, so chances of power-out at exactly this moment are small
enough that I'm willing to take my chances here.
My experience is that there's more chance of the SD card completely
dying because of power-out during some internal mumbojumbo than
corrupting that partition table. Against that SD failure there's nothing
I can do...
--
Mike Looijmans
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149465):
https://lists.openembedded.org/g/openembedded-core/message/149465
Mute This Topic: https://lists.openembedded.org/mt/81348440/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
