OpenBSD: AMD processor microcode support added to -current
1–10 of 23 posts
Re: OpenBSD: AMD processor microcode support added to -current
#2An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it.
But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader.
We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u-boot spl to opensbi to u-boot flow, with UEFI on the works on the latter chip.
Re: OpenBSD: AMD processor microcode support added to -current
#3An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader. We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u…
RISC V will end at the same fate when implemented by the same vendors
Re: OpenBSD: AMD processor microcode support added to -current
#4An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader. We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u…
If boot firmware implemented it, I wouldn't count on it being updated very often.
Every OS these days has a pretty good update process that patches things frequently. Doing it there means most users actually have a chance of seeing the patches.
Re: OpenBSD: AMD processor microcode support added to -current
#5An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader. We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u…
If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently. Doing it there means most users actually have a chance of seeing the patches.
>If boot firmware implemented it, I wouldn't count on it being updated very often.
That's precisely the problem when it's not possible to upgrade that boot firmware without the vendor's help.
Or why x86 firmware contains microcode, yet we still have to update it later.
Re: OpenBSD: AMD processor microcode support added to -current
#6An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader. We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u…
No thanks. Early boot software should only do the bare minimum required to hand over control to the real operating system.
If this means some code duplication between operating systems, that’s OK.
Re: OpenBSD: AMD processor microcode support added to -current
#7This is an area where AMD has typically been better than Intel. With the longevity of the AMD4 platform, even ancient motherboards have had recent BIOS updates to bring in newer AGESA versions, so most motherboards have gotten lots of updates for very long periods of time. I wonder how many Kaby Lake motherboards are still getting updates.
OTOH, no matter the history of updates, it's better to have this under the OS's control, particularly when running OSes more suitable for servers. The thought of sending someone to update a BIOS in a colo facility is just... frightening.
Re: OpenBSD: AMD processor microcode support added to -current
#8An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader. We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u…
If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently. Doing it there means most users actually have a chance of seeing the patches.
AGESA is updated every few months and a number of motherboard vendors track those changes with BIOS updates. The updates can often contain pretty substantial changes, like resizable BAR support.
Further: I'm typing this on a Macbook Pro which is running right now only because I was able to pull the bootrom (which is UEFI), add a NVME driver from a newer Macbook Pro, package it back up, and flash it back to the older Macbook Pro.
This let me use an NVME drive in a machine released before they added NVME support to that system's bootrom. The only side effect was that the OS didn't fully support NVME standby modes so power consumption was slightly higher, but even that was fixed in a later OS update which was released after NVME drives were in several models.
Re: OpenBSD: AMD processor microcode support added to -current
#9An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader. We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u…
I haven’t checked the changes here, but even if your FW carries a recent ucode at boot, you may find yourself wanting to update the ucode at runtime without a reboot. This is certainly possible on Linux.
Re: OpenBSD: AMD processor microcode support added to -current
#10An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader. We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u…
If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently. Doing it there means most users actually have a chance of seeing the patches.
> If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently.
Not only that, but updating firmware is always riskier than updating the OS. If an OS update is broken, you can easily use the firmware to recover (booting from the OS install media and working from there); recovering from a failed firmware update can be much harder and/or obscure.