On Tue, 2025-11-25 at 15:14 -0700, Simon Glass wrote:
On Mon, 24 Nov 2025 at 02:21, Nussel, Ludwig <ludwig.nussel@siemens.com> wrote:
On Tue, 2025-11-18 at 11:55 -0700, Simon Glass wrote:
[...] Yes and I'm not too keen on that approach: - we cannot have a system relying on FAT since it can become corrupted if the media is yanked out (power failure, etc.)
Certainly (V)FAT isn't the most beautiful nor most simple FS for the purpose. But then which one would you choose?
ext4 as it can survive power failure and is relatively simple (compared to some).
Hmm, that means the bootloader has to deal with the complexity of also handling the journal though.
Yes, that's right. We discussed this a bit in the U-Boot call today. Tom suggested pulling in ext4 from Linux somehow.
Uh, are you sure that's a good idea? ext4 is almost eight times as big as FAT in terms of lines in the Linux kernel. There has to be some fs more suitable for this very special and limited use case of the boot volume. But then if FAT is not robust enough for some really sensitive use cases I'd guess that one would just dump the the fit image raw into some a/b boot partitions instead?
- Type 1 is actually based on extlinux and has some benefits, but we cannot use that spec unless it supports FIT - Type 2 requires EFI so is a non-starter for systems that want to boot without it
I had a brief chat with Luca on all-systems-go, his concern with adding FIT to the official document was mostly that no other bootloader supports FIT. I found that at least barebox also supports it. So probably just a matter of coordination for broader support. Anyway U- Boot could just support FIT as extension from the standard while still following the general architecture and naming scheme.
Well, also Tianocore[1] and coreboot (for many years) at least. What other bootloaders are there, actually?
Ok, cool. I didn't know that.
Universal Payload Specification uses FIT as the file format and device tree (with some schema additions) as the handoff format.
Good arguments IMO. Esp when the intention is to allow for really fast boots hat EFI may not be able to provide. Booting fast was one of systemd's original motivations.
The response I received on FIT was unfortunate, to say the least. To me it actually came across more as ignorance than anything else. I would love to see that issue reopened for some discussion. Please see if Luca might be open to that.
I do have the impression that the embedded, potentially non-EFI use case is a separate world that is not really that visible on the radar on systemd side indeed. The next chance to meet the group in person might be at FOSDEM. Unfortunately no dedicated devroom this year. Are you going there?
We definitely have two separate worlds, but I would like to bring them together. At present I'm in NZ at the end of January, so FOSDEM is unlikely. What else is on the calendar next year?
That's certainly a more pleasant place to be at that time of the year :-) I'm probably not aware of all events, a very good one is all- systems-go for sure. It's usually end of September in Berlin.
cu Ludwig
-- (o_ Ludwig Nussel //\ Siemens AG / SI E R&D V_/_ www.siemens.com