[...] > > > > > 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: > > 1. Create 2 capsules, 1 raw, 1 fmp. > > 2. Set dfu_alt_info -> process RAW capsule. > > What do you mean by "process"? > > > 3. 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
