On Monday, 12 February 2024 19:38:12 CET Henrique de Moraes Holschuh wrote: > On Fri, Feb 2, 2024, at 13:50, Diederik de Haas wrote: > > This is about "AMD Platform Management Framework TA", which seems to be > > about AMD CPU features. The first (and only) commit message has this: > > > > ``` > > amd_pmf: Add initial PMF TA for Smart PC Solution Builder > > > > AMD PMF driver loads the PMF TA (Trusted Application) into the AMD > > ASP's (AMD Security Processor) TEE (Trusted Execution Environment). > > ``` > > > > Firmware for AMD graphics belongs in firmware-nonfree, but the > > ``amdtee`` directory seems to fit better in amd64-microcode? > > Could be, yes. It isn't needed at early boot at all, but then neither is > AMD-SEV, and it is in amd64-microcode. > > So yeah, I could carry it on amd64-microcode, but we need to coordinate it > re. linux-firmware packages, since it has to move from one package to the > other. Unless it has never made it to any linux-firmware packages ?
It has never made it into any firmware-nonfree package, so nothing needs to move. I'm working on a 20230804 update where I have added AMD-SEV to the Files- Excluded section. I then came across the 'amdtee' dir and was wondering what (best) to do with that, hence this bug. > And I need to know what I should do about it on the backport branches and > security update branches. I don't know/understand what you mean by this. Can you clarify? On Wed, 7 Feb 2024 18:38:30 -0600 Mario Limonciello <mario.limoncie...@amd.com> wrote: > The firmware is only used on mobile APUs (which contain graphics). So > if needing to pick an existing binary package instead of a new one I can > see a stronger argument to bundle it with the graphics package. My logic was that this is about AMD TEE (Trusted Execution Environment), which I *assumed* is part of/tied to the CPU. This thought is based on that on ARM platforms, you also have a TEE and that is part of the CPU (and implemented in TF-A IIUC). I can be wrong here ofc. That it *currently* is only used on mobile APUs is something I consider to be an implementation detail. I can be wrong on this too. There's no need to pick an existing binary package. I could add it to amd- graphics, but I consider that a poor choice. I could create a new binary package `amdtee` in firmware-nonfree (source package). That would be fine afaic. But as I assumed AMD TEE is a CPU feature, adding it to a package which already deals with AMD CPU features seems the most logical. And if AMD TEE becomes available in the future in 'normal' desktop CPUs (without graphics) it would be 'weird' to have to install firmware-amd-graphics to make use of it (and then a move probably would be needed). So I have no strong feelings about it, just trying to find the best place for the `amdtee` dir. Cheers, Diederik
signature.asc
Description: This is a digitally signed message part.
