Hi Ludwig, On Wed, 26 Nov 2025 at 03:08, Nussel, Ludwig <ludwig.nussel@siemens.com> wrote:
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?
(sorry I missed this at the time) Yes, that is an option, although raw partitions are less flexible. I had a go at bringing Linux ext4 into U-Boot. It is extremely large, but it does support all the features.This is in Concept now, with a recent series to try to reduce the impact at least for the read-only case.
- 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.
Yes and at least in theory it should be faster to use a C program rather than a lot of shell scripts. But of course things get more complicated with time.
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.
OK well I have never made it to Berlin. If you are able to ping me once the date is fixed I should be able to attend. Regards, Simon