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