Hi Alexander, On 31 January 2016 at 19:52, Simon Glass <s...@chromium.org> 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. > > 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.
Sorry, scratch that. I moved it to a different directory which must have made the build system unhappy. I re-ran autogen.sh and it worked. > >> >> 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? > >> >>> 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. > > 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. > > Perhaps my main interest is fiddling with UEFI without having to use > its code base. :-) > >> >>> I'll make a few other comments on the patches. But overall >>> it seems to function and I think your implementation is nice. >> >> >> Thanks :) >> >>> >>> I was able to get grub to boot but it just says 'Welcome to GRUB!' >>> and then 'error: disk ',gpt4' not found'. I'm not sure what that >>> means. >> >> >> It might mean memory corruption. I'm not sure where from though :). It could >> also mean register clobbering. >> >> >>> >>> >>> U-Boot 2016.01-00860-geb4b602-dirty (Jan 31 2016 - 08:02:54 -0700) >>> >>> CPU: x86_64, vendor Intel, device 30673h >>> DRAM: 2 GiB >>> efi_runtime_relocate: Relocating to offset=7ba5d000 >>> MMC: ValleyView SDHCI: 0, ValleyView SDHCI: 1 >>> SF: Detected W25Q64DW with page size 256 Bytes, erase size 4 KiB, total 8 >>> MiB >>> *** Warning - bad CRC, using default environment >>> >>> Video: 1280x1024x16 >>> Model: Intel Minnowboard Max >>> SF: Detected W25Q64DW with page size 256 Bytes, erase size 4 KiB, total 8 >>> MiB >>> SCSI: SATA link 0 timeout. >>> Target spinup took 0 ms. >>> AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode >>> flags: 64bit ncq stag pm led clo pio slum part sxs >>> scanning bus for devices... >>> Device 0: (1:0) Vendor: ATA Prod.: ADATA SP310 Rev: 5.2 >>> Type: Hard Disk >>> Capacity: 30533.8 MB = 29.8 GB (62533296 x 512) >>> Found 1 device(s). >>> Net: >>> Warning: eth_rtl8169 using MAC address from ROM >>> eth0: eth_rtl8169 >>> Hit any key to stop autoboot: 0 >>> reading grubia32.efi >>> 85504 bytes read in 16 ms (5.1 MiB/s) >>> ## Starting EFI application at 0x00010000 ... >>> WARNING: No device tree loaded, expect boot to fail >>> Scanning disks on scsi... >>> Scanning disks on usb... >>> Scanning disks on mmc... >>> Card did not respond to voltage select! >>> MMC Device 2 not found >>> MMC Device 3 not found >>> Found 2 disks >>> do_bootefi_exec:134 Jumping to 0x72857400 >>> EFI: Entry efi_open_protocol(7bab8c18, 728609a0, 7b857ab8, 7bab8c18, >>> 00000000, 0x2) >>> efi_open_protocol: Found protocol handler loaded_image0 >>> EFI: Exit 0 >>> EFI: Entry efi_locate_protocol(72860990, 00000000, 7b857ac8) >>> EFI: Exit 0 >>> EFI: Entry efi_cin_get_mode(7baa79cc, 7b857af8, 00000000, 00000000) >>> EFI: Exit 0 >>> EFI: Entry efi_locate_protocol(72860990, 00000000, 7b857aa8) >>> EFI: Exit 0 >>> EFI: Entry efi_cin_get_mode(7baa79cc, 7b857ad8, 00000000, 00000000) >>> EFI: Exit 0 >>> EFI: Entry efi_cout_enable_cursor(7baa79d8, 1) >>> EFI: Exit 80000003 >>> EFI: Entry efi_allocate_pages(1, 2, 0x6, 7b857a74) >>> EFI: Exit 0 >>> EFI: Entry efi_get_memory_map(7b857b04, 7286c000, 7b857a64, 7b857b08, >>> 7b857a68) >>> EFI: Exit 0 >>> EFI: Entry efi_allocate_pages(2, 2, 0x1ca15, 7b857a74) >>> EFI: Exit 0 >>> EFI: Entry efi_free_pages(7286c000, 0x6) >>> EFI: Exit 0 >>> EFI: Entry efi_set_watchdog_timer(0, 0x0, 0, 00000000) >>> EFI: App called into unimplemented function efi_set_watchdog_timer >>> EFI: Exit 80000003 >>> EFI: Exit 80000003 >>> EFI: App called into unimplemented function efi_set_watchdog_timer >>> EFI: Exit 80000003 >>> EFI: Entry efi_locate_handle(2, 72860980, 00000000, 7b857a88, 72856fe0) >>> EFI: Exit 0 >>> EFI: Entry efi_open_protocol(7b863108, 728609b0, 7b857a78, 7bab8c18, >>> 00000000, 0x2) >>> efi_open_protocol: Found protocol handler open_dp >>> efi_disk_open_dp >>> EFI: Exit 0 >>> EFI: Entry efi_open_protocol(7b863108, 72860980, 7b857a98, 7bab8c18, >>> 00000000, 0x2) >>> efi_open_protocol: Found protocol handler open_block >>> efi_disk_open_block >>> EFI: Exit 0 >>> EFI: Entry efi_open_protocol(7b8631d8, 728609b0, 7b857a78, 7bab8c18, >>> 00000000, 0x2) >>> efi_open_protocol: Found protocol handler open_dp >>> efi_disk_open_dp >>> EFI: Exit 0 >>> EFI: Entry efi_open_protocol(7b8631d8, 72860980, 7b857a98, 7bab8c18, >>> 00000000, 0x2) >>> efi_open_protocol: Found protocol handler open_block >>> efi_disk_open_block >>> EFI: Exit 0 >>> EFI: Entry efi_cout_set_attribute(7baa79d8, 70) >>> EFI: Exit 80000003 >>> Welcome to GRUB! >>> >>> EFI: Entry efi_cout_set_attribute(7baa79d8, 7) >>> EFI: Exit 80000003 >>> EFI: Entry efi_open_protocol(7bab8c18, 728609a0, 7b857ad8, 7bab8c18, >>> 00000000, 0x2) >>> efi_open_protocol: Found protocol handler loaded_image0 >>> EFI: Exit 0 >>> EFI: Entry efi_open_protocol(7bab8bd0, 728609b0, 7b857a78, 7bab8c18, >>> 00000000, 0x2) >>> efi_open_protocol: Found protocol handler bootefi0 >>> EFI: Exit 0 >>> error: disk `,gpt4' not found. >>> Entering rescue mode... >>> grub rescue> >> >> >> Does grub see the hard disks? What happens when you do ls (hd,<TAB>? Also, >> try the ls command but first do set debug=all to get grub internal debugging >> enabled too. >> >>> >>> >>> I suppose my grub could be wrong. If you can point me to one that I >>> should use I could try again. I pushed your tree (rebased to mainline) >>> plus my messing-around patch to u-boot-x86/efi-working. >>> >>> It would be good to get this series applied soon. >> >> >> Awesome. >> >> I'm currently rewriting the memory map code, making it more robust, easy to >> understand and extensible for modules that may want to register runtime >> service mmio regions. >> >> Once that works and I have all of Leif's comments sorted out, I'll post v3. > > Sounds good. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot