Announcement

Collapse
No announcement yet.

AMD Zen CPU Microcode Added To Linux-Firmware Tree, Bulldozer Updated

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD Zen CPU Microcode Added To Linux-Firmware Tree, Bulldozer Updated

    Phoronix: AMD Zen CPU Microcode Added To Linux-Firmware Tree, Bulldozer Updated

    Ensuring your CPU microcode is kept up-to-date for Zen processors is now a little bit easier with the microcode files being added to the linux-firmware.git collection...

    http://www.phoronix.com/scan.php?pag...x-Firmware-Add

  • #2
    I'm confused. This has been previously applied using the BIOS? Now we're not dependent on the BIOS for these updates? That would be good because motherboard vendors don't always push new updates for very long. That's even more true for laptop vendors.

    Comment


    • #3
      CPU microcode has always been able to be updated via software, either by your BIOS/UEFI firmware or by the OS (I know Arch uses the intel-ucode package for Intel CPUs and linux-firmware for AMD). This is the first time that Zen microcode updates have been made available outside of motherboard firmware though.

      An update to your motherboard firmware may or may not contain CPU microcode updates, as well as non CPU specific updates/fixes as well.
      Last edited by Slithery; 20 May 2018, 05:34 AM.

      Comment


      • #4
        Originally posted by Chewi View Post
        I'm confused. This has been previously applied using the BIOS? Now we're not dependent on the BIOS for these updates? That would be good because motherboard vendors don't always push new updates for very long. That's even more true for laptop vendors.
        BIOS update has always been preferred method, this is just exception rater than rule... for AMD this is just 4th update in last 5 years, see a log

        https://git.kernel.org/pub/scm/linux.../log/amd-ucode

        Microcode updates happens mostly because of security issues, i say mostly rather than only since there is one "fix a bug from previous update" , here we have exposing IBPB so that mitigation could work that way too... basically these are all about security
        Last edited by dungeon; 20 May 2018, 06:39 AM.

        Comment


        • #5
          I thought as well this worked for Zen already before. Good that it is now in place though.

          Comment


          • #6
            Originally posted by debianxfce View Post
            Those microcode files are in the amd64-microcode package of Debian sid. https://packages.debian.org/sid/amd64-microcode
            This microcode does not apply on my 1700 at all, before installation the patch_level was 0x08001129 and after installation and reboot it's still 0x08001129.

            Comment


            • #7
              Originally posted by debianxfce View Post
              Those microcode files are in the amd64-microcode package of Debian sid. https://packages.debian.org/sid/amd64-microcode
              This microcode does not apply on my 1700 at all. Before and after installation the patch_level is 0x08001129.

              Comment


              • #8
                Originally posted by TuxTuxTux View Post

                This microcode does not apply on my 1700 at all. Before and after installation the patch_level is 0x08001129.
                The Linux efi systems load the microcode updates via an initrd cpio image (I don't know if Debian has a standard way to create this). This procedure is documented in the Kernel documentation.

                In my case:

                This is just a snippet of the code I use to create the amd_ucode_fam17h.img:

                cp /lib/firmware/amd-ucode/microcode_amd_fam17h.bin kernel/x86/microcode/AuthenticAMD.bin
                find . | cpio -o -H newc > ../amd_ucode_fam17h.img


                The loader entry is:

                /efi/loader/entries % cat xilka-64.conf
                title Xilka64
                linux /EFI/xilka/bzImage.efi
                initrd /EFI/amd/amd_ucode_fam17h.img
                options root=PARTUUID=dba40a33-dc83-4328-9736-63b08afa4a3f rootfstype=btrfs ro vga=0 nmi_watchdog=1 rcu_nocbs=0-15 systemd.setenv=XDG_DATA_DIRS=/usr/share:/opt/kde5/share:/opt/kde5/share/akonadi/agents:/opt/kde5/lib/kde4

                Comment


                • #9
                  I'm not using EFI to boot, shouldn't that work with legacy boot as well?

                  Comment


                  • #10
                    Originally posted by TuxTuxTux View Post
                    I'm not using EFI to boot, shouldn't that work with legacy boot as well?
                    Yeah, the initrd method works with non-efi systems as well.

                    Comment

                    Working...
                    X