All of
 help / color / mirror / Atom feed
From: "Stefano Babic" <>
To: Mike Looijmans <>,
	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 15:58:35 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Mike,

On 15.03.21 15:46, Mike Looijmans wrote:
> 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:
> W:
> 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.

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.

>>> 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.

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

Absolutely true.

Best regards,
Stefano Babic

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email:

  reply	other threads:[~2021-03-15 14:58 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 [this message]
2021-03-15 15:17           ` Mike Looijmans
     [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.