Announcement

Collapse
No announcement yet.

Linux 3.13 To Support EFI On ARM

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

  • Linux 3.13 To Support EFI On ARM

    Phoronix: Linux 3.13 To Support EFI On ARM

    Beyond the NVIDIA Tegra 4 support and improved 64-bit ARM code, the in-development Linux 3.13 kernel will also support EFI on ARM...

    http://www.phoronix.com/vr.php?view=MTUxMDg

  • #2
    Before someone makes a snide comment about UEFI, consider the current arm situation.

    Comment


    • #3
      Originally posted by agd5f View Post
      Before someone makes a snide comment about UEFI, consider the current arm situation.
      Actually I'm kinda curious. Alex do you know what the current Android "Recovery" options are designed around? Clockwork and TeamWin seem much more fully featured than a traditional BIOS, so I just assumed they were (U)EFI, but now im like "Okay... guess not"

      Comment


      • #4
        Originally posted by Ericg View Post
        Actually I'm kinda curious. Alex do you know what the current Android "Recovery" options are designed around? Clockwork and TeamWin seem much more fully featured than a traditional BIOS, so I just assumed they were (U)EFI, but now im like "Okay... guess not"
        "Android "Recovery" is just Linux kernel + Recovery binary, it isn't BIOS/EFI, you can't boot Linux kernel from it (only way use kexec/kexec-hardboot).

        Comment


        • #5
          I afraid EFI implementations by ARM vendors will be very buggy.

          Comment


          • #6
            Originally posted by Ericg View Post
            Actually I'm kinda curious. Alex do you know what the current Android "Recovery" options are designed around? Clockwork and TeamWin seem much more fully featured than a traditional BIOS, so I just assumed they were (U)EFI, but now im like "Okay... guess not"
            "Android "Recovery" is just Linux kernel + Recovery binary, it isn't BIOS/EFI, you can't boot Linux kernel from it (only way use kexec/kexec-hardboot).

            Comment


            • #7
              The lack of a standard firmware and mechanism for device discovery is one of the reasons there aren't generic kernel images that will load on a variety arm systems.

              Comment


              • #8
                Originally posted by dragonn View Post
                "Android "Recovery" is just Linux kernel + Recovery binary, it isn't BIOS/EFI, you can't boot Linux kernel from it (only way use kexec/kexec-hardboot).
                So whats the mechanism on android for initial hardware bring up?

                Comment


                • #9
                  Originally posted by agd5f View Post
                  Before someone makes a snide comment about UEFI, consider the current arm situation.
                  Originally posted by agd5f View Post
                  The lack of a standard firmware and mechanism for device discovery is one of the reasons there aren't generic kernel images that will load on a variety arm systems.
                  I have an OLPC XO-1.75 on my desk which boots using Open Firmware. I understand that the Linux Device Tree is derived from the method that OFW uses to allow the operating system to enumerate devices.
                  So in other words, a 2000 page specification implemented to no other gain than doing what is already possible in a more complex way.

                  Comment


                  • #10
                    Originally posted by Ericg View Post
                    So whats the mechanism on android for initial hardware bring up?
                    Err, I guess a devel board from the SoC vendor? Then later a series of prototypes for the phone/tablet.

                    If you meant to ask about the bootloader, I think each vendor has their own. They do seem to have similarities though, so I wouldn't be surprised if they are derived from something originally written by Google and/or ARM.

                    ("hardware bring-up" is a specific term, Google it)

                    Comment


                    • #11
                      Originally posted by Imroy View Post
                      Err, I guess a devel board from the SoC vendor? Then later a series of prototypes for the phone/tablet.

                      If you meant to ask about the bootloader, I think each vendor has their own. They do seem to have similarities though, so I wouldn't be surprised if they are derived from something originally written by Google and/or ARM.

                      ("hardware bring-up" is a specific term, Google it)
                      Yeah I wasn't referring to the hardware devel stages :P I was more asking what is the typical android phone's version of BIOS/(U)EFI, if it even had one at all?

                      Comment


                      • #12
                        Originally posted by Ericg View Post
                        Yeah I wasn't referring to the hardware devel stages :P I was more asking what is the typical android phone's version of BIOS/(U)EFI, if it even had one at all?
                        This stuff differs by the specific SoC vendor. In all cases, they're proprietary. In many cases, the stupid things are signed, staged bootloaders, that check every subsequent stage for correct signature. Let me tell you, it is a TOTAL MESS.

                        Now there is at least one piece of good news; that one of the later stages of the bootloader chain is, indeed, open source. This part is actually part of AOSP and can be found here; https://android.googlesource.com/kernel/lk/ --- "lk" is for "Little Kernel", also known as "aboot".

                        I am mostly familiar with qualcomm SoC's, and the bootloader stages before lk are basically a nightmare. You have a small prom on the board with the PBL, then 4 partitions on the eMMC called SBL1, SBL2, SBL3, and TZ. PBL is the first thing that runs when the CPU powers on, and is just enough to get the eMMC going and have it start running SBL1. Every stage of this bootloader chain signature checks the next stage. TZ is basically "bad-DRM", known as "trust zone".

                        The initialization path goes like this; PBL --> SBL1 --> SBL2 --> TZ --> SBL2 --> SBL3 --> LK.

                        The SoC itself has a bank of fuses that tell SBL3 whether or not to signature check LK. If it is *not* blown, then you could replace LK with one built from source. If it is blown, then LK probably also signature checks the boot and recovery partitions.... i.e., those two partitions where you can find kernel+initrd. There are two differences between boot and recovery partitions; 1 is the payload of the initrd. 2 is the load priority. Boot is the default selected option for starting up Android, the recovery choice is tied to a gpio, typically volume up. This distinction is made by LK.

                        So LK is basically a triple boot loader. It defaults to loading boot, volup to load recovery, voldown to load *fastboot*, which is a super-recovery payload within LK itself. It basically lets you write filesystem images to the eMMC within a specified list of partitions.

                        So good news is that LK is open source, bad news is that it is prone to being locked down and possibly even butchered. If you've messed with Samsung phones, for example, you'll be aware of their "loader" mode, which is basically a butchered version of fastboot. It does about the same thing, but only responds to their proprietary software, rather than standard fastboot protocols. Not particularly complex though, and has been reverse engineered.

                        LK is basically the Android equivalent of GRUB. The crap before it, is a nightmare.

                        Comment


                        • #13
                          Isn't EFI already used on Windows Surface tables witch are ARM based? I thought that was why they had a locked down SecureBoot?

                          Comment


                          • #14
                            Originally posted by droidhacker View Post
                            Things and stuff.
                            Thank you for that. Now I have a bit more context about why I had to go to one of the nearby cubes and ask one of the guys a few cubes over to re-flash my bricked pre-tizen device Agee years ago when I had remounted the root partition as RW and made a few changes to it before rebooting.

                            I had always assumed that the thing refused to boot due to a signed boot loading issue (on a prototype no less), but now I've got something approaching an explanation.

                            Comment


                            • #15
                              Originally posted by RussianNeuroMancer View Post
                              I afraid EFI implementations by ARM vendors will be very buggy.
                              No kidding, since its sole reason for existing is Windows RT. "If it boots windows -> ship it" still applies today

                              Comment

                              Working...
                              X