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
