On 12/17/2024 05:58, Werner Sembach wrote:
Am 17.12.24 um 11:10 schrieb Richard Hughes:
On Monday, 16 December 2024 at 23:37, Werner Sembach
<wse@xxxxxxxxxxxxxxxxxxx> wrote:
- AfuEfix64.efi <bios>.bin /p /r /capsule -> overwrites nothing
I tried to explain fwupd and the requirements to our contact at the
ODM, but
just got the unhelpful reply to use the command above.
Can you name the ODM? I think essentially all the ODMs are uploading
[valid] capsules to the LVFS now. If it helps, it's the same capsule
needed for the LVFS as for the Microsoft WU (Windows Update) process
and all ODMs should be intimately familiar with those requirements.
In this case it was a Tonfang/Uniwill barebone and I talked to a
Tongfang representative.
Want to point out again that I could determine that /k did do nothing in
the /capsule mode while /p and /r did effect the flash (iirc /p was
required for /capsule or the flash didn't start). I could not determine
if /b /n and /l did something (and probably can't without proper
documentation, which I don't have access to). I guess /x is irrelevant
as long as the flash works.
Do you have a Microsoft help page for OEMs about BIOS and EC upgrades
via Windows Update? Having some Windows requirements to point to often
helps when talking with ODMs in my experience.
https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/windows-uefi-firmware-update-platform
Do you know how these AfuEfix64.efi flags are passed over to the
capsule flash
process? Then it might be possible to implement them in fwupd too.
The capsule, as expected by LVFS and WU, is actually a single *signed*
binary that contains the flasher binary and the payload all wrapped up
into one. The only time I've seen AfuEfix64.efi in use is for the
system preload, as done in the factory.
Yeah but since at least the /r flag influences the flash process there
must be some way the efi shell can pass on options to the flasher
included in the capsule ... EFI variables? Some bits appended to the
capsule?
Richard.
