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

[Simon Glass]

Hi Alex,

On 1 February 2016 at 14:38, Alexander Graf <agraf at suse.de> wrote:
> 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

OK will try.

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

Me neither, but then I turned that off a year or so ago after I had problems.

>
>
>>
>>>> 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 :).

OK. You could add a regparm(0) or something like that to be sure it is
working. Or just bring in that part of my patch. But I'm OK if you'd
rather I send a follow-up.

>
>> 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
> :).

FIT is probably what everyone should be using. It always amazes me the
lengths to which people go to do get a kernel and a selected device
tree. All those hacks at the start of the kernel for decompression,
early serial, device tree appending, etc. What a mess.

Anyway I commend FIT to your attention :-)

setup.bin is created on x86 only - I believe it is a few boot sectors
so it contains executable code as well as settings. Really ugly.

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

Agreed. I'm quite happy with the EFI API too, and particularly since
we can write code that uses it in our own style (e.g. linux kernel
style). But I have quite limited experience with it so far (just the
U-Boot feature to run as a payload and an application).

It must cost a lot more to write code in TianoCore than in U-Boot. I'm
surprised that companies have that much money to waste :-)

Regards,
Simon