On Sat, Aug 5, 2017 at 10:01 AM, Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>> On Fri, Aug 4, 2017 at 4:41 PM, Mark Kettenis <mark.kette...@xs4all.nl>
>> >> From: Rob Clark <robdcl...@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(sd...@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 .
> OpenBSD doesn't run on the db410c. However, our EFI bootloader should
> just run. You can download it from:
> for the 64-bit (AArch64) and
> for the 32-bit version (AArch32).
oh, good point.. I can try that
> 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
> at that stage.
hmm, well I'll give a quick try w/ your bootaa64.efi, but I guess this
is probably something board specific.
$(CROSS_COMPILE)-addr2line -e u-boot 7ef8d878
while you still have the build handy?
U-Boot mailing list