[...]
Yes. We may have different *firmware* for different software components and different devices. For example, You have firmare like U-Boot binary and default variable storage in different partitions. On the other hand, you have an extra firmware for a particular peripheral, like PCI device or anything else, which comes from a 3rd party vendor of the device. The former may and can be packed into a single binary in FIT format. The latter can be used in a separate RAW format as the timing of updating those firmware is likely to be different.
Sure that's a use case. But that's not a specific one, nor something you cant do without both of them being installed. You can arguably just create a RAW image for the second firmware and put the info into dfu_alt_info.
Why do you stick to a single format?
I think it's the other way around. Why wouldn't you? It's the easiest and sanest thing to do when generating capsules.
I don't know why you think it's the easiest. "mkeficapsule" can create any format of capsule file. (This is not true in the current form. but it's quite easy to enhance this command for this purpose.)
Because it's easier from a system maintenance perspective to have to deal with a single capsule format instead of two.
We can reasonably assume that each FMP may have a different format. I think it's a very natural thing.
The FMPs logic in the EFI spec is not tied to 'format', it's tied to 'device' and currently both FMPs target the same device.
the same device? What do you mean by 'same device'? I probably won't agree.
This depends on the dfu_alt_info. See below
So my understanding is, that in order to use it you need to:
- Create 2 capsules, 1 raw, 1 fmp.
- Set dfu_alt_info -> process RAW capsule.
What do you mean by "process"?
- Set dfu_alt_info to something different -> process FIT capsule.
No. What you need to do is to *add* definition for firmware in FIT. We can have a single definition of dfu_alt_info even if we use both FIT and RAW FMPs.
Ok that's what I've been asking all along. Do you have an *working* example for that? Set the dfu_alt_info once and be able to update 2 different flash devices on the same system, using 1 capsule as RAW and 1 capsule as FIT. While at the same time populate those 2 different flash devices correctly in the ESRT.
and by doing so the ESRTs will use one of the information found in dfu_alt_info.
So what?
If they both refer to the same flash, the spec says you shouldn't do that and you have no way of knowing this right now. But if you can define a dfu_alt_info, that exposes 1 flash device handled by the RAW capsule and 1 flash device handled by the FIT capsule, I guess that would be fine. But looking at the dfu entities code, we can add mmc, mtd, nand, ram, sf or virt and the it handles things like 'raw' of a filesystem. How do you point out "this dfu entry is a fit"?
So unless we have an example of a device that says "This firmware file can only be updated by a FIT image, while the rest of the firmware is on a FAT filesystem", I don't see any reason why we need to support that. The changes are not set in stone anyway. The code was fine before the ESRT got involved. So all my patch really does is make the current code useful when an ESRT is installed. We can then break the spec on purpose (yes break it :>) ignore the OsIndications bit and have fwupd working with U-Boot. This will have an actual impact on devices and the code usability, since people will start using it. I prefer this over adding a very cumbersome corner case, that's arguably no one will ever need. We can always go back and make them a config option in the future. But unless we get a use case for it, I'd still prefer having them mutually exclusive, rather than adding code for an imaginary device (which I really doubt anyone will ever design).
I don't think that the example I gave is a imaginary device.
All of the devices I've tested and seen up to now are working fine with just RAW capsules installed and I can't understand why a specific *format* should play a role in the capsule creation.
I don't get your point. I never said, "a specific format should play a role."
FITs are a nice way to get authentication and bundle things without having the EFI capsule authentication code, but really apart from that those 2 are doing the same thing.
Yes, but why do we have to have the restriction? Different capsule files for different firmware/device may come from different owners of the firmware.
No that's a completely moot point imho. If any vendor has a very special firmware he needs to treat in a very special way, he needs to install his own FMP. If we are talking about different firmwares on *different* flash devices, then the final board re-seller should say "all of you individual people send me RAW capsules, or FIT capsules". There still hasn't been a single argument on what you can achieve with a FIT specific image, which you can't with a RAW. So I'll ask again. The fact that you *can* do it doesn't mean it the sane thing to do.
[...]
The ESRT code right now uses get_image_info from the FMP code and the FMP code uses the dfu_alt_info to derive whatever information it needs. Both of these concepts are trying to provide information about the running firmware. So if we change that imho both of them should get that info from an abstracted object (file/c struct in u-boot/whatever). But really I think using FMP to fill ESRT entries is fine (at least for me).
Well, dfu_alt_info can already be seen as abstracted object in terms of FMP.
Yes but it can't handle the ESRT generation properly. So if you change that, why leave the FMPs get_image_info, read the information differently?
Again, I don't get your point.
I've tried to explain this a couple of times. If we manage to answer the dfu_alt_info question above sufficiently, then maybe you will
Thanks /Ilias