Re: [PATCH v2] PCI: Avoid putting some root ports into D3 on some Ryzen chips

[Werner Sembach]

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.

>   
> > 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.