All of
 help / color / mirror / Atom feed
From: "Mike Looijmans" <>
To: Stefano Babic <>,
	Patches and discussions about the oe-core layer
Subject: Re: [OE-core] Build the "boot" partition image (just like the rootfs)
Date: Mon, 15 Mar 2021 16:17:03 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Stefano,

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

Please consider the environment before printing this e-mail
On 15-03-2021 15:58, Stefano Babic wrote:
> Hi Mike,
> On 15.03.21 15:46, Mike Looijmans wrote:
>> 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.
> rpi-bootfiles inherit nopackage, so you should write a recipe that 
> instead of simply deploying the files as this recipe does, install 
> them. You should then install it into /, as this is where they are put 
> on the VFAT partition. If they are in the package, you can write an 
> image recipe to install it via IMAGE_INSTALL, and via post process 
> command you drop what is not necessary (/etc,...).
> Anyway, as far as I know, an IMAGE_FSTYPES += "vfat" is not supported, 
> you have also to add support for it.

rpi-bootfiles provides only part of the file set. The issue is that 
IMAGE_BOOT_FILES, which lists much more than what rpi-bootfiles 
provides, can be modified in the image recipe itself. It contains the 
kernel, devicetrees and configuration files as well.

>>>> 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.
> True, that is. So simply the hardware does not allow a safe update, 
> point. Fully agree. Or use a very expensive industrial grade SD, but 
> any board with eMMC is then cheaper.

I actually tried a few industrial grade SDs (usually SLC type). I had 
issues with those on other boards and the Pi is no exception. If I put 
one of those expensive SLC cards into the SD slot of the RPi4, there's 
about 30% chance that the board won't boot at all.

>> Against that SD failure there's nothing I can do...
> Absolutely true.


I'm going to let this thing rest for a while, maybe I'll come up with 
something completely different or maybe someone in this group has some 
brilliant idea...

Mike Looijmans

  reply	other threads:[~2021-03-15 15:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
2021-03-15 13:13   ` Build the "boot" partition image (just like the rootfs) Mike Looijmans
2021-03-15 13:47     ` [OE-core] " Stefano Babic
2021-03-15 14:46       ` Mike Looijmans
2021-03-15 14:58         ` Stefano Babic
2021-03-15 15:17           ` Mike Looijmans [this message]
     [not found]           ` <>
2021-03-18 13:48             ` Mike Looijmans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.