Hi Simon,
On 02/01/2016 03:52 AM, Simon Glass wrote:
Hi Alexander,
On 31 January 2016 at 14:43, Alexander Graf <ag...@suse.de> wrote:
On 01/31/2016 04:17 PM, Simon Glass wrote:
Hi Alexander,
On 14 January 2016 at 22:06, Alexander Graf <ag...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
