Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Linux 3.13 To Support EFI On ARM

  1. #11
    Join Date
    Aug 2012
    Pennsylvania, United States


    Quote 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?

  2. #12
    Join Date
    Oct 2009


    Quote 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; --- "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.

  3. #13
    Join Date
    Sep 2011


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

  4. #14
    Join Date
    Nov 2008
    Madison, WI, USA


    Quote 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.

  5. #15
    Join Date
    Sep 2006


    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts