Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com; dmarc=pass header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qkk49+XF6+Jn7RUjFU/ZFP7/ho5kdUEUNpSrCpqy9yw=; b=knLDTd1vrl7R3BnRReKrxUD1UxYSIahqh5VTND3PEt1cLHtskGRiDc280ADRTm6ffV izImBjr6hq94Qu/Jnbd6kn7+jSDuhDva9FU1/ZndFaNkTUhsatlgtvrK5RzJ38FpwvLa 0X7Y8NuVm99K+ijWdKI34YruaZfz47t863L40UYJhjdaj3/TLdIWrC/NzEBiQ/fXemHU 8mN1HM9JBD7STB64mMlDSttSTC2vJOPyX81CCbDnXLI/puqcyXewaJ+kW8Km+VDra2xs PIWVzyA0PoV7nIihMbkrv95K7GQgpSOUUL7nlEmAreQoEbCCb8Iw2inSe6LqhN6IbJ4u Js9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qkk49+XF6+Jn7RUjFU/ZFP7/ho5kdUEUNpSrCpqy9yw=; b=kiBq9lLF93IqOIhjRAbghuqi5rcOJ7mf7OvAvgo8T4qg72k9iEBX84R7yIY7KVyDpX DxV+JJDPePbOtIN3qxpmIZF6vqT/HJ0w+z8RnsUiUGJxGCxTA9R97e+tcB1Ovh7zRIJe JPSP/6/TqRmFgrlIsZdoPZAsypVgTx/AHfdMA/z3l4EOOdSOcd3AOd+sDdGnhCAm2G0+ QyAXxkxleKeB3t2AvXKiXpJknXzSb9FxM+0ug0gAPlTTT7d2JFEOZ43gzgLCTTsCVDdL lWiJepjIeynmIuGKwcZJpFdV6C8nx2RMztWLpbhPMrbbR+eLkQcaJnJJrgv859lzbUrM 9XhQ== X-Gm-Message-State: AHYfb5hmb8q9IgSaZxMt3OsQOUjxd0l+fyjrLiox4JEB/7NaaHlf1K9h HiWJc8WMqU156stR2hj9qS4oZRxkCuHp0xg= X-Received: by 10.25.59.29 with SMTP id i29mr1058615lfa.224.1501880271850; Fri, 04 Aug 2017 13:57:51 -0700 (PDT) From: Rob Clark robdclark@gmail.com Date: Fri, 4 Aug 2017 16:57:50 -0400 Cc: U-Boot Mailing List u-boot@lists.denx.de, Heinrich Schuchardt xypron.glpk@gmx.de, Peter Jones pjones@redhat.com X-CNFS-Analysis: v=2.2 cv=eoad9chX c=1 sm=0 tr=0 a=bdpqe3ZLSLbgpdprsY8WZA==:117 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=D2htVsi0J-IA:10 a=KeKAF7QvOSUA:10 a=pGLkceISAAAA:8 a=NEAV23lmAAAA:8 a=YyEjxAJ5dRpCWmjka9UA:9 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 X-Virus-Scanned: by XS4ALL Virus Scanner X-XS4ALL-Spam-Score: -0.1 () DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, SPF_PASS X-XS4ALL-Spam: NO Envelope-To: mark.kettenis@xs4all.nl
On Fri, Aug 4, 2017 at 4:41 PM, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Rob Clark robdclark@gmail.com Date: Fri, 4 Aug 2017 15:31:55 -0400
Hi Rob,
OpenBSD has been an early adopter of efi_loader and pretty much completely relies on it for booting OpenBSD/armv7 and OpenBSD/arm64. We use our own bootloader which is fairly lightweight. Obviously we'd like to keep it working if this patchset gets adopted. We don't make use of EFI variables and don't really plan to make use of them on our ARM platforms. But obviously we have to deal with device paths...
Also, create disk objects for the disk itself, in addition to the partitions. (UEFI terminology is a bit confusing, a "disk" object is really a partition.) This helps grub properly identify the boot device since it is trying to match up partition "disk" object with it's parent device.
Now instead of seeing devices like:
/File(sdhci@07864000.blk)/EndEntire /File(usb_mass_storage.lun0)/EndEntire
You see:
/ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c00000000,1,1)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,200000,dd904a8c00000000,1,1)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c00000000,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,60000,38ca680200000000,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca680200000000,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca680200000000,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca680200000000,1,1)/EndEntire
This is on a board with single USB disk and single sd-card. The UnknownMessaging(1d) node in the device-path is the MMC device, but grub_efi_print_device_path() hasn't been updated yet for some of the newer device-path sub-types.
..and what you're sketching out here should work with recent enough versions of our bootloader.
However, to me having an ACPI Device Path component in there doesn't make much sense on a board without ACPI. It certainly doesn't help mapping a boot path back to an actual hardware device. Wouldn't it be more logical to a Hardware Device Path there instead? In particular a Memory Mapped Device Path would make a lot of sense as the start address would make it fairly easy to do the mapping.
It was pretty much an arbitrary choice, and it wouldn't be hard to change. From my reading of the grub code, all it really cares about is that there is *some* parent of the "partition" HD device. I'm not really sure what maps best in a UEFI world to the "soc" node in a device tree world. I'm certainly open to changing this.
It would be cool if you have a chance to give this a try w/ OpenBSD and let me know if you run into issues. I want this to be something that works across-distro so I'll try to help as much as I can. (Not sure if there is an OpenBSD port for db410c, but I guess there is always qemu..). Fwiw, if git pull/cherry-pick is easier than grabbing patches from list, then [1].
OpenBSD doesn't run on the db410c. However, our EFI bootloader should just run. You can download it from:
http://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/BOOTAA64.EFI
for the 64-bit (AArch64) and
http://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/BOOTARM.EFI
for the 32-bit version (AArch32).
Unfortunately something in this patch series breaks things for me on a Banana Pi:
U-Boot SPL 2017.09-rc1-00020-g2ad6933c64-dirty (Aug 05 2017 - 15:26:15) DRAM: 1024 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1
U-Boot 2017.09-rc1-00020-g2ad6933c64-dirty (Aug 05 2017 - 15:26:15 +0200) Allwinner Technology
CPU: Allwinner A20 (SUN7I) Model: LeMaker Banana Pi I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment
Setting up a 720x576i composite-pal console (overscan 32x20) In: serial Out: vga Err: vga SCSI: Target spinup took 0 ms. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c50000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootarm.efi Scanning disks on scsi... Scanning disks on usb... Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 6 disks data abort pc : [<7ef8d878>] lr : [<7ef8d874>] reloc pc : [<4a039878>] lr : [<4a039874>] sp : 7af29660 ip : 00000000 fp : 7af29774 r10: 7efec230 r9 : 7af33ee0 r8 : 00000000 r7 : 00000009 r6 : 7ef9e8b8 r5 : 7af296a0 r4 : 7efa4495 r3 : 7af296a0 r2 : 0000008c r1 : 7af29658 r0 : 00000004 Flags: nzCV IRQs off FIQs off Mode SVC_32 Resetting CPU ...
resetting ...
Normally it would print something like:
OpenBSD/armv7 BOOTARM 0.8
boot>
at that stage.