[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c5eb555-4642-42ef-8e4d-9c0c61292ba8@tuxedocomputers.com>
Date: Tue, 17 Dec 2024 12:58:18 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Richard Hughes <richard@...hsie.com>
Cc: Mario Limonciello <mario.limonciello@....com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Richard Hughes <hughsient@...il.com>, ggo@...edocomputers.com,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] PCI: Avoid putting some root ports into D3 on some
Ryzen chips
Am 17.12.24 um 11:10 schrieb Richard Hughes:
> On Monday, 16 December 2024 at 23:37, Werner Sembach <wse@...edocomputers.com> 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.
>
Powered by blists - more mailing lists