Announcement

Collapse
No announcement yet.

Linux 3.13 To Support EFI On ARM

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

  • #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?
    All opinions are my own not those of my employer if you know who they are.

    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