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 <j...@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 <j...@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.g...@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.g...@gmx.de>
>     Signed-off-by: Alexander Graf <ag...@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.

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 sd...@7e300000.blk...
unhandled parent class: sd...@7e300000.blk (13)
unhandled parent class: sd...@7e300000.blk (13)
unhandled parent class: sd...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to