[U-Boot] [PATCH 00/14] EFI payload / application support v2

[Alexander Graf]

Hi Simon,

On 02/01/2016 03:52 AM, Simon Glass wrote:
> Hi Alexander,
>
> On 31 January 2016 at 14:43, Alexander Graf <agraf at suse.de> wrote:
>>
>> On 01/31/2016 04:17 PM, Simon Glass wrote:
>>> Hi Alexander,
>>>
>>> On 14 January 2016 at 22:06, Alexander Graf <agraf at suse.de> wrote:
>>>> This is my Christmas present for my openSUSE friends :).
>>>>
>>>> U-Boot is a great project for embedded devices. However, convincing
>>>> everyone involved that only for "a few oddball ARM devices" we need to
>>>> support different configuration formats from grub2 when all other
>>>> platforms
>>>> (PPC, System Z, x86) are standardized on a single format is a nightmare.
>>> Well some might argue that grub2 and UEFI are their own nightmares :-)
>>
>> They are, but they are the same nightmare everyone else is dreaming ;).
>>
>>
>>>> So we started to explore alternatives. At first, people tried to get
>>>> grub2 running using the u-boot api interface. However, FWIW that one
>>>> doesn't support relocations, so you need to know where to link grub2 to
>>>> at compile time. It also seems to be broken more often than not. And on
>>>> top of it all, it's a one-off interface, so yet another thing to
>>>> maintain.
>>> The API interface is mostly for closed-source work I think.
>>>
>>>> That led to a nifty idea. What if we can just implement the EFI
>>>> application
>>>> protocol on top of U-Boot? Then we could compile a single grub2 binary
>>>> for
>>>> uEFI based systems and U-Boot based systems and as soon as that one's
>>>> loaded,
>>>> everything looks and feels (almost) the same.
>>>>
>>>> This patch set is the result of pursuing this endeavor.
>>>>
>>>>     - I am successfully able to run grub2 and Linux EFI binaries with this
>>>> code.
>>>>     - When enabled, the resulting U-Boot binary only grows by ~10kb,
>>>>       so it's very light weight.
>>>>     - It works on 32bit ARM and AArch64.
>>>>     - All storage devices are directly accessible
>>>>     - No EFI variables
>>>>     - Removable media booting (search for /efi/boot/boota{a64,arm}.efi)
>>>>
>>>> Of course, there are still a few things one could do on top:
>>>>
>>>>     - Improve disk media detection (don't scan, use what information we
>>>> have)
>>>>     - Add EFI variable support using NVRAM
>>>>     - Add GFX support
>>>>     - Make EFI Shell work ;)
>>>>     - Network device support
>>>>     - Support for payload exit
>>>>
>>>> But so far, I'm very happy with the state of the patches. They completely
>>>> eliminate potential arguments against U-Boot internally and give users
>>>> the
>>>> chance to run with the same level of comfort on all firmware types.
>>> I'd suggest creating a README with the above info. The cover letter
>>> will vanish pretty fast. Perhaps also update README.efi with this new
>>> option.
>>
>> Good idea.
>>
>>> Another thing you could list is efi_set_watchdog_timer().
>>
>> What about it exactly? That it's not supported atm?
> Yes.
>
>>>> Version 2 was successfully tested to boot grub2 and Linux from there on a
>>>> HiKey (AArch64, dcache disabled) and on a BeagleBone Black.
>>> Do you have a UEFI image for BBB that I can put on an SD card or otherwise
>>> boot?
>>
>> Phew, I hand-crafted one to play around with. You can use the hip04d01 image
>> from
>>
>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/HIP04D01/images/openSUSE-Tumbleweed-ARM-JeOS-hip04d01.armv7l.install.tar.xz
>>
>> Just extract the tar.xz, to get to the actual image .xz file.
>>
>> That image obviously has an incorrect kernel for the BBB, but everything up
>> to grub2 should work with it.
> I'm not sure what file to use. I found a file with a .12.1 extension
> which I tried to dd to a uSD card but it did not boot.

Yeah, BBB is difficult. You need to have a working MLO (SPL) binary that 
chain-loads into a u-boot binary. The MLO can be either on a FAT 
partition or at hard coded offsets on the card. The same applies to the 
u-boot binary.

Some genius changed the way SPL works to only restrict you to either one 
path or the other - so if you started SPL from a raw offset, you need to 
have u-boot at a raw offset. If you started from FAT, u-boot needs to be 
in FAT.

So you'd have to take the hip04d01 image and manually try to dd MLO and 
u-boot binaries into it. I'd love to just give you the image I have, but 
I'm not sure bandwidth is great enough for that here :).

Alternatively you could use a working BBB image and copy grub from the 
hip04d01 image. Or use the rpm from here:

http://download.opensuse.org/ports/armv7hl/tumbleweed/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-54.1.armv7hl.rpm

>
> Do you have an ARM grub binary (in EFI format)? II could test with
> just that piece.  tried building grub but it says cross-compiling
> isn't recommended, and I got an error about a missing
> ../include/grub/machine/kernel.h.
>
>> My plan was to slowly move all openSUSE arm targets that use our own u-boot
>> binaries to EFI once this patch set goes in ;).
> BTW out of interest how come SUSE doesn't use the same distro boot
> thing as other distributions?

Imagine you had a team full of people who constantly try to fight off 
additional work because their support matrix is already insanely big 
(Yast in our case). And now try to convince those guys to maintain 
additional code just for this one random architecture that doesn't even 
pay bills for anyone (32bit arm) :).

We went through great pain with SLE12 to move all targets to grub2. On 
s390x for example, we even chain load a small Linux kernel that runs 
grub2 as user space payload on top just to ensure that configuration is 
*always* the same.

The nice thing that gives you is feature parity across architectures. 
For example, we can easily boot from btrfs snapshots with this approach. 
I'm not sure how you'd do that otherwise.


>
>>> For now I've had a play with Minnowboard, which is x86. The main thing
>>> I noticed is that the API function implements should have EFIAPI on
>>> them also.
>>
>> Yes :). I didn't expect anyone to actually care about running this on x86
>> which is the only architecture that has different calling conventions for
>> EFI. I'm very pleasantly surprised that you are interested and since you
>> already have a patch to add them, I guess you can as well just post that
>> once the base support is in :).
> OK. I suppose because EFIAPI is empty on ARM it doesn't matter. But
> strictly speaking the declaration should match the implementation.

Yeah, I just didn't want to implement something I wouldn't test :).

> U-Boot mostly uses FIT which provides secure boot and it can boot both
> 32- and 64-bit kernels directly. But there is still the odd setup.bin
> thing Linux uses.

I haven't looked at FIT at all so far - and I have no idea what 
setup.bin is :).

> Perhaps my main interest is fiddling with UEFI without having to use
> its code base. :-)

That's a great goal! To be quite honest, the more I work with the EFI 
API, the more I think it's actually a pretty reasonable API for what 
it's trying to do.

The problem is just that every time I try to look at TianoCore code, my 
eyes get sore.


Alex