On 02/08/2018 10:49 AM, Jonathan Gray wrote:
On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
Am 08.02.2018 um 06:49 schrieb Jonathan Gray jsg@jsg.id.au:
On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
Date: Mon, 5 Feb 2018 21:06:59 +1100 From: Jonathan Gray jsg@jsg.id.au
>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured >> failed(6). will try /bsd > > How do you find out that it's sd0a instead of sd1a?
The loaded image protocol I believe.
Actually the OpenBSD bootloader currently only supports loading the bsd kernel from the same device as the bootloader. It will always call that device sd0. It invokes the device path protocol on the loaded image handle and then matches that path to a device that supports the block io protocol.
Perhaps the problem is elsewhere as U-Boot master also broke vexpress_ca15_tc2 and mx6cuboxi targets:
Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?
On cubox a bisect points to
commit 64e4db0f119151a1345e1da19d152eda550394e7 Author: Heinrich Schuchardt xypron.glpk@gmx.de Date: Fri Jan 19 20:24:47 2018 +0100
efi_loader: make efi_disk_create_partitions a global symbol Up to now we have been using efi_disk_create_partitions() to create partitions for block devices that existed before starting an EFI application. We need to call it for block devices created by EFI applications at run time. The EFI application will define the handle for the block device and install a device path protocol on it. We have to use this device path as stem for the partition device paths. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>include/efi_loader.h | 4 +++ lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++---------------- 2 files changed, 64 insertions(+), 24 deletions(-)
If I revert this commit a image built from master works.
Actually master doesn't build with just that reverted, seems I had stale object files.
When bisecting running 'make mrproper && make foo_defconfig && make' in each round is recommendable.
Do you still assume a problem that requires a change in U-Boot? Or can we close the topic?
Best regards
Heinrich
rpi3 with the commit just before boots
98d48bdf415e318a11f9f9a44dff2b70aef3fb10 efi_loader: provide a function to create a partition node
U-Boot 2018.01-00408-gb7b3517a7f (Feb 08 2018 - 22:35:55 +1300)
DRAM: 948 MiB RPI 3 Model B (0xa02082) MMC: sdhci@7e300000: 0 In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0
Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Type: Removable Hard Disk Capacity: 29327.3 MB = 28.6 GB (60062500 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi unhandled parent class: usb_mass_storage.lun0 (13) 82748 bytes read in 89 ms (907.2 KiB/s) ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... unhandled parent class: sdhci@7e300000.blk (13) unhandled parent class: sdhci@7e300000.blk (13) unhandled parent class: sdhci@7e300000.blk (13) Scanning disk usb_mass_storage.lun0... unhandled parent class: usb_mass_storage.lun0 (13) unhandled parent class: usb_mass_storage.lun0 (13) unhandled parent class: usb_mass_storage.lun0 (13) Found 6 disks
OpenBSD/arm64 BOOTAA64 0.11
boot> booting sd0a:/bsd: 3917796+579072+585220+806860-[280094+96+459168+244083]=0x8442a8