Announcement

Collapse
No announcement yet.

Many EFI Updates Prepped For Linux 4.7 Kernel

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

  • Many EFI Updates Prepped For Linux 4.7 Kernel

    Phoronix: Many EFI Updates Prepped For Linux 4.7 Kernel

    Matt Fleming at Intel sent out the set of patches he intends to submit as the queue of EFI changes for what will become the Linux 4.7 kernel. He noted of this queue, "this is probably the biggest EFI pull ever sent, and there quite a few different topics covered."..

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Will it turn UEFI off?????

    Comment


    • #3
      Why would anyone want EFI on their devices?

      Comment


      • #4
        Originally posted by caligula View Post
        Why would anyone want EFI on their devices?
        Secure boot. Better support for larger harddrives. Faster hardware initialisation. Fancy GUIs.

        Comment


        • #5
          Secure Boot is somehow boring until you see it as one of many steps to secure your system. Alone it is pretty much useless. But you can even boot without any additional bootloader and in best case it POSTs much faster - with one SSD you can partly enable fastboot and skip some more things. GUI is not always fancy... can be as basic as 20y old BIOS ;-)

          Comment


          • #6
            Interesting that much of this UEFI code relates to ARM, which interesting coming from a Intel guy since they do x86 not ARM.

            I wish Intel would put more resources into open source UEFI implementations, such as their TianoCore.

            Comment


            • #7
              Originally posted by Kano View Post
              Secure Boot is somehow boring until you see it as one of many steps to secure your system. Alone it is pretty much useless. But you can even boot without any additional bootloader and in best case it POSTs much faster - with one SSD you can partly enable fastboot and skip some more things. GUI is not always fancy... can be as basic as 20y old BIOS ;-)
              What BIOS? Wasn't this article talking about ARM & EFI? My ARM boards boot in few seconds (kernel and busybox) from eMMC.

              Comment


              • #8
                Originally posted by unixfan2001 View Post

                Secure boot. Better support for larger harddrives. Faster hardware initialisation. Fancy GUIs.
                On ARM? Why couldn't they support booting from large (um, > 2 TB?) drives without EFI? I'm perfectly happy with old style partition tables and < 2 TB on ARM. The biggest eMMCs are like 512 GB and they're huge for anything embedded. You can still plug in 8 TB drives just fine.

                Comment


                • #9
                  Originally posted by caligula View Post
                  why would anyone want efi on their devices?
                  efistub <3

                  Comment


                  • #10
                    Originally posted by caligula View Post
                    Why couldn't they support booting from large (um, > 2 TB?) drives without EFI?
                    EFI natively supports GPT partition scheme, and natively supports loading an executable file (in EFI format, usually a boot-loader like GRUB or ELILO, but could be a straight Linux kernel with efistub) from a special FAT partition (the EFI System Partition) and provides some minimal APIs (like filesystem access and graphical console to output graphics, error messages, boot menus, etc.)

                    It's got quite some features.

                    At the opposite range (though luckily only confined to x86 world, not on ARM) you have the BIOS which basically just able to load the first sector of a boot drive into RAM and run it. It doesn't provide anything beyond a few API to display text and/or load sectors from disk.

                    This MBR, in only 512 bytes (minus partition table) must be able to load anything necessary so the boot loader can start.
                    (Or load a partition's boot sector which will do this job).
                    This small piece of code receives no API beyond "read random sectors through BIOS INTerrupt calls" and must be able to fends its way all the way up to "Grub is up and running". (This includes find a way to load some driver code that in turn will be able to read actual partitions - e.g.: grub's "stage 1.5". Its usually done by using some reserved space at a fixed position after the boot sector - GPT introduced a special "BIOS BOOT" type of partition of that purpose).

                    Most ARM firmware fall somewhere inbetween these two extremes.

                    Luckily most ARM board tend to be very specific and allow very few customisation. Firmware usually need to do something like "stream ${N} MiB from flash memory connected to a very specific port of the SoC" (which contain either a more complete boot environment, or contains a directly executable Linux kernel + initrd).
                    So event while not as feature complete as a EFI firmware (or as Coreboot with a good high quality payload, for that matter) they are good enough for most cases.

                    Originally posted by caligula View Post
                    On ARM? {...} I'm perfectly happy with old style partition tables and < 2 TB on ARM. The biggest eMMCs are like 512 GB and they're huge for anything embedded. You can still plug in 8 TB drives just fine.
                    When you read "ARM" you probably think about your Raspberry PI. And indeed a GiB-range microSD card is well enough for that use case.
                    The classical "stream a few MiB from MMC port 0" approach is good enough for you.

                    But, the thing is, there are other possible usage for ARM, specially since ARM64 took off: use case which were traditionally served by low power Intel chipset until now.

                    Things like low-power file servers. Or laptops.
                    i.e.: things that have a lot more connection possibilities than a raspberry pi (the file server is going to have a couple of SATA drives and should be able to load an OS from one of them. the laptop is going to need to be able to boot either from its SSD or a rescue system from an USB Boot Disk. Or maybe a bootable CD-R, if optical drives still exist then).

                    For these use case, an EFI firmware (or Coreboot) start to make sense.
                    Because it covers all the more advanced boot scenarios beyond "loading the kernel from the SD card" pretty well and provides a lot of flexibility thanks to all its advanced features and APIs (again, same could by said for Coreboot).
                    And in the specific case of server and laptop, it will also help with familiarity if the firmware is similar to what other servers and laptops come with. So using EFI on ARM64 like on Intel based hardware makes sense from a user experience (or Coreboot if that your favorite firmware in your server farm. But definitely not something simpler like uboot which will look alien to anyone else)


                    Comment

                    Working...
                    X