efi_loader: Fix disk dp's for pre-DM/legacy devices
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
--- lib/efi_loader/efi_disk.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
lib/efi_loader/efi_disk.c +11 -0
@@ -340,6 +340,8 @@ int efi_disk_register(void)for (i =0 ; i <4 ; i++) {struct blk_desc *desc;char devname[32 ] = {0 };/* dp->str is u16[32] long */ +disk_partition_t info; +int part =1 ; desc =blk_get_devnum_by_type (if_type, i);if (!desc)
@@ -349,6 +351,15 @@ int efi_disk_register(void)snprintf (devname,sizeof (devname),"%s%d" , if_typename, i); + +/* add devices for each partition: */ +while (!part_get_info (desc, part, &info)) { +efi_disk_add_dev (devname, if_typename, desc, + i,0 , part); + part++; + } + +/* ... and add block device: */ efi_disk_add_dev (devname, if_typename, desc, i,0 ,0 ); disks++;
Signature · 1 line
2.13.6
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 7 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>
Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
U-Boot 2017.11-rc1-00112-g936028a089 (Oct 09 2017 - 13:39:34 +1100)
DRAM: 948 MiB
RPI 3 Model B (0xa02082)
MMC: sdhci at 7e300000: 0
reading uboot.env
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
U-Boot> printenv boot_targets
boot_targets=usb0 mmc0 pxe dhcp
U-Boot> boot
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 reading efi/boot/bootaa64.efi
78287 bytes read in 86 ms (888.7 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disks
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
boot> ls sd0a:/
stat(sd0a:/): Device not configured
boot> ls sd1a:/
stat(sd1a:/): Device not configured
boot>
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
BR,
-R
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 17 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
Quoted 8 lines
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
BR,
-R
With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?
efi_bootdp obtained from the loaded image protocol
2017.09
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi
78959 bytes read in 76 ms (1013.7 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depth looking for type 4 i=0 type 4 depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk i=1
efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330
git + patch
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depth looking for type 4 i=0 type 1 efi_device_path_depth looking for type 4 i=1 type 3 efi_device_path_depth looking for type 4 i=2 type 3 efi_device_path_depth looking for type 4 i=3 type 3 efi_device_path_depth no match for type 4 depth=-1
i=0
i=1
i=2
i=3
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?
There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 19 lines
efi_bootdpobtained from the loaded image protocol2017.09
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi
78959 bytes read in 76 ms (1013.7 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 4 depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk i=1
efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
Quoted 5 lines
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330git + patch
I assume you are referring to this patch? It should only add additional per-partion "disk" objects. (In UEFI terminology each partition is a "disk" object.)
BR,
-R
Quoted 23 lines
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthno match for type 4 depth=-1
i=0
i=1
i=2
i=3Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
I only see MEDIA_DEVICE with U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).
It is DM in this case:
U-Boot> dm tree
Class Probed Driver Name
----------------------------------------
root [ + ] root_drive root_driver simple_bus [ + ] generic_si |-- soc gpio [ + ] gpio_bcm28 | |-- gpio at 7e200000 serial [ + ] serial_bcm | |-- serial at 7e215040 mmc [ + ] sdhci-bcm2 | |-- sdhci at 7e300000 blk [ + ] mmc_blk | | `-- sdhci at 7e300000.blk video [ + ] bcm2835_vi | |-- hdmi at 7e902000 vidconsole [ + ] vidconsole | | `-- hdmi at 7e902000.vidconsole0 usb [ + ] dwc2_usb | `-- usb at 7e980000 usb_hub [ + ] usb_hub | `-- usb_hub usb_hub [ + ] usb_hub | `-- usb_hub eth [ + ] smsc95xx_e | |-- smsc95xx_eth usb_mass_s [ + ] usb_mass_s | `-- usb_mass_storage blk [ ] usb_storag | `-- usb_mass_storage.lun0 simple_bus [ ] generic_si `-- clocks
Quoted 24 lines
Quoted 24 lines
efi_bootdpobtained from the loaded image protocol2017.09
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi
78959 bytes read in 76 ms (1013.7 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 4 depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk i=1
efi_bootdp=Dusbmassstoragelun dp=DusbmassstoragelunQuoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330
Quoted 6 lines
Quoted 1 line
git + patch
I assume you are referring to this patch? It should only add additional per-partion "disk" objects. (In UEFI terminology each partition is a "disk" object.)
Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices". The problem seems to be elsewhere as dropping that I still see:
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disksefi_diskprobeefi_device_path_depth looking for type 4 i=0 type 1 efi_device_path_depth looking for type 4 i=1 type 3 efi_device_path_depth looking for type 4 i=2 type 3 efi_device_path_depth looking for type 4 i=3 type 3 efi_device_path_depth no match for type 4 depth=-1
i=0
i=1
i=2
i=3
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
od1000 (edk2) booting off sata:
INFO: PSCI Power Domain Map:
INFO: Domain Node : Level 1, parent_node -1, State ON (0x0) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: CPU Node : MPID 0x0, parent_node 0, State ON (0x0) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
NOTICE: BL3-1:
NOTICE: BL3-1: Built : 14:04:15, Apr 9 2016
INFO: BL3-1: Initializing runtime services
INFO: BL3-1: Preparing for EL3 exit to normal world
INFO: BL3-1: Next image address = 0x8000e80000
INFO: BL3-1: Next image spsr = 0x3c9
Press ESCAPE for boot options .....efi_diskprobe efi_device_path_depth looking for type 4 i=0 type 2 efi_device_path_depth looking for type 4 i=1 type 1 efi_device_path_depth looking for type 4 i=2 type 3 efi_device_path_depth looking for type 4 i=3 type 4 depth=3
i=0
efi_bootdp=A dp=A
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In efi_disk_register() it should create objects for the disk itself (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
If part_get_info() fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.
BR,
-R
Quoted 106 lines
U-Boot> dm tree
Class Probed Driver Name
----------------------------------------root [ + ] root_drive root_driver simple_bus [ + ] generic_si |-- soc gpio [ + ] gpio_bcm28 | |-- gpio at 7e200000 serial [ + ] serial_bcm | |-- serial at 7e215040 mmc [ + ] sdhci-bcm2 | |-- sdhci at 7e300000 blk [ + ] mmc_blk | | `-- sdhci at 7e300000.blk video [ + ] bcm2835_vi | |-- hdmi at 7e902000 vidconsole [ + ] vidconsole | | `-- hdmi at 7e902000.vidconsole0 usb [ + ] dwc2_usb | `-- usb at 7e980000 usb_hub [ + ] usb_hub | `-- usb_hub usb_hub [ + ] usb_hub | `-- usb_hub eth [ + ] smsc95xx_e | |-- smsc95xx_eth usb_mass_s [ + ] usb_mass_s | `-- usb_mass_storage blk [ ] usb_storag | `-- usb_mass_storage.lun0 simple_bus [ ] generic_si `-- clocksQuoted 24 lines
Quoted 24 lines
efi_bootdpobtained from the loaded image protocol2017.09
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi
78959 bytes read in 76 ms (1013.7 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 4 depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk i=1
efi_bootdp=Dusbmassstoragelun dp=DusbmassstoragelunQuoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330Quoted 6 lines
Quoted 1 line
git + patch
I assume you are referring to this patch? It should only add additional per-partion "disk" objects. (In UEFI terminology each partition is a "disk" object.)
Yes, "
efi_loader: Fix disk dp's for pre-DM/legacy devices". The problem seems to be elsewhere as dropping that I still see:## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
efi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthno match for type 4 depth=-1
i=0
i=1
i=2
i=3Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsdod1000 (edk2) booting off sata:
INFO: PSCI Power Domain Map: INFO: Domain Node : Level 1, parent_node -1, State ON (0x0) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: CPU Node : MPID 0x0, parent_node 0, State ON (0x0) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2) NOTICE: BL3-1: NOTICE: BL3-1: Built : 14:04:15, Apr 9 2016 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x8000e80000 INFO: BL3-1: Next image spsr = 0x3c9Press ESCAPE for boot options .....efi_diskprobe
efi_device_path_depthlooking for type 4 i=0 type 2efi_device_path_depthlooking for type 4 i=1 type 1efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 4 depth=3
i=0
efi_bootdp=A dp=AQuoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 56 lines · Rob Clark
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In
efi_disk_register()it should create objects for the disk itself (part==0, noMEDIA_DEVICEnodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
Quoted 116 lines
If
part_get_info()fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.BR,
-RQuoted 106 lines
U-Boot> dm tree
Class Probed Driver Name
----------------------------------------root [ + ] root_drive root_driver simple_bus [ + ] generic_si |-- soc gpio [ + ] gpio_bcm28 | |-- gpio at 7e200000 serial [ + ] serial_bcm | |-- serial at 7e215040 mmc [ + ] sdhci-bcm2 | |-- sdhci at 7e300000 blk [ + ] mmc_blk | | `-- sdhci at 7e300000.blk video [ + ] bcm2835_vi | |-- hdmi at 7e902000 vidconsole [ + ] vidconsole | | `-- hdmi at 7e902000.vidconsole0 usb [ + ] dwc2_usb | `-- usb at 7e980000 usb_hub [ + ] usb_hub | `-- usb_hub usb_hub [ + ] usb_hub | `-- usb_hub eth [ + ] smsc95xx_e | |-- smsc95xx_eth usb_mass_s [ + ] usb_mass_s | `-- usb_mass_storage blk [ ] usb_storag | `-- usb_mass_storage.lun0 simple_bus [ ] generic_si `-- clocksQuoted 24 lines
Quoted 24 lines
efi_bootdpobtained from the loaded image protocol2017.09
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi
78959 bytes read in 76 ms (1013.7 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 4 depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk i=1
efi_bootdp=Dusbmassstoragelun dp=DusbmassstoragelunQuoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330Quoted 6 lines
Quoted 1 line
git + patch
I assume you are referring to this patch? It should only add additional per-partion "disk" objects. (In UEFI terminology each partition is a "disk" object.)
Yes, "
efi_loader: Fix disk dp's for pre-DM/legacy devices". The problem seems to be elsewhere as dropping that I still see:## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
efi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthno match for type 4 depth=-1
i=0
i=1
i=2
i=3Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsdod1000 (edk2) booting off sata:
INFO: PSCI Power Domain Map: INFO: Domain Node : Level 1, parent_node -1, State ON (0x0) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: CPU Node : MPID 0x0, parent_node 0, State ON (0x0) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2) NOTICE: BL3-1: NOTICE: BL3-1: Built : 14:04:15, Apr 9 2016 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x8000e80000 INFO: BL3-1: Next image spsr = 0x3c9Press ESCAPE for boot options .....efi_diskprobe
efi_device_path_depthlooking for type 4 i=0 type 2efi_device_path_depthlooking for type 4 i=1 type 1efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 4 depth=3
i=0
efi_bootdp=A dp=AQuoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
Hello Rob,
does you patch create the partitions handles as children of the disk?
This means do you append the partition name as node to the device path of the drive to produce the partition device path?
Best regards
Heinrich
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 173 lines · Heinrich Schuchardt
Quoted 56 lines · Rob Clark
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In
efi_disk_register()it should create objects for the disk itself (part==0, noMEDIA_DEVICEnodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).Quoted 116 lines
If
part_get_info()fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.BR,
-RQuoted 106 lines
U-Boot> dm tree
Class Probed Driver Name
----------------------------------------root [ + ] root_drive root_driver simple_bus [ + ] generic_si |-- soc gpio [ + ] gpio_bcm28 | |-- gpio at 7e200000 serial [ + ] serial_bcm | |-- serial at 7e215040 mmc [ + ] sdhci-bcm2 | |-- sdhci at 7e300000 blk [ + ] mmc_blk | | `-- sdhci at 7e300000.blk video [ + ] bcm2835_vi | |-- hdmi at 7e902000 vidconsole [ + ] vidconsole | | `-- hdmi at 7e902000.vidconsole0 usb [ + ] dwc2_usb | `-- usb at 7e980000 usb_hub [ + ] usb_hub | `-- usb_hub usb_hub [ + ] usb_hub | `-- usb_hub eth [ + ] smsc95xx_e | |-- smsc95xx_eth usb_mass_s [ + ] usb_mass_s | `-- usb_mass_storage blk [ ] usb_storag | `-- usb_mass_storage.lun0 simple_bus [ ] generic_si `-- clocksQuoted 24 lines
Quoted 24 lines
efi_bootdpobtained from the loaded image protocol2017.09
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi
78959 bytes read in 76 ms (1013.7 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 4 depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk i=1
efi_bootdp=Dusbmassstoragelun dp=DusbmassstoragelunQuoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330Quoted 6 lines
Quoted 1 line
git + patch
I assume you are referring to this patch? It should only add additional per-partion "disk" objects. (In UEFI terminology each partition is a "disk" object.)
Yes, "
efi_loader: Fix disk dp's for pre-DM/legacy devices". The problem seems to be elsewhere as dropping that I still see:## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0... Found 2 disks
efi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthno match for type 4 depth=-1
i=0
i=1
i=2
i=3Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsdod1000 (edk2) booting off sata:
INFO: PSCI Power Domain Map: INFO: Domain Node : Level 1, parent_node -1, State ON (0x0) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: Domain Node : Level 1, parent_node -1, State OFF (0x2) INFO: CPU Node : MPID 0x0, parent_node 0, State ON (0x0) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2) INFO: CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2) NOTICE: BL3-1: NOTICE: BL3-1: Built : 14:04:15, Apr 9 2016 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x8000e80000 INFO: BL3-1: Next image spsr = 0x3c9Press ESCAPE for boot options .....efi_diskprobe
efi_device_path_depthlooking for type 4 i=0 type 2efi_device_path_depthlooking for type 4 i=1 type 1efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 4 depth=3
i=0
efi_bootdp=A dp=AQuoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
Quoted 7 lines
Hello Rob,
does you patch create the partitions handles as children of the disk?
This means do you append the partition name as node to the device path of the drive to produce the partition device path?
We create diskobj's for both the entire disk, and for each partition. (The per-partition diskobj was previously missing in the !DM case, which this patch fixes.)
The devicepath for the per-partition diskobj's matches the devicepath of the parent whole-disk diskobj with MEDIA_DEVICE:HARD_DRIVE (or :CDROM) node appended. So in this sense, they are children of the parent disk[1].
BR,
-R
[1] UEFI's terminology is designed to confuse here, since it calls the per-partition diskobj's as "disk objects" rather than something like "partition objects"..
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
In reply to Rob ClarkQuoted 56 lines · Rob Clark
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In
efi_disk_register()it should create objects for the disk itself (part==0, noMEDIA_DEVICEnodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
Quoted 7 lines
If
part_get_info()fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.BR,
-R
It is partitioned mbr style.
U-Boot> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 8192 00000000-01 0c Boot 4 16384 26624 00000000-04 a6
U-Boot> part list usb 0
Partition Map for USB device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 32768 00000000-01 0c Boot 4 40960 60021540 00000000-04 a6
I changed the part_get_info() debug messages to normal printfs and no error paths trigger:
U-Boot 2017.11-rc1-00111-g97b86e3342-dirty (Oct 10 2017 - 03:28:40 +1100)
DRAM: 948 MiB
RPI 3 Model B (0xa02082)
MMC: sdhci at 7e300000: 0
## Valid DOS partition found ##
reading uboot.env
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
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning usb 0:1...
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Found EFI removable media binary efi/boot/bootaa64.efi ## Valid DOS partition found ##
## Valid DOS partition found ##
reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##
## Valid DOS partition found ##
Found 2 disksefi_diskprobeefi_device_path_depth looking for type 4 i=0 type 1 efi_device_path_depth looking for type 4 i=1 type 3 efi_device_path_depth looking for type 4 i=2 type 3 efi_device_path_depth looking for type 4 i=3 type 3 efi_device_path_depth no match for type 4
depth=-1
i=0
i=1
i=2
i=3
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 67 lines · Jonathan Gray
Quoted 56 lines · Rob Clark
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In
efi_disk_register()it should create objects for the disk itself (part==0, noMEDIA_DEVICEnodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).Quoted 7 lines
If
part_get_info()fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.BR,
-RIt is partitioned mbr style.
Quoted 8 lines
U-Boot> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 8192 00000000-01 0c Boot 4 16384 26624 00000000-04 a6U-Boot> part list usb 0
perhaps jumping from partition #1 to #4 is what is confusing things here? It's possible you end up with a partition "diskobj" for partition #1 but not #4?
Try adding a print in efi_disk_register() and see how many times we go thru the while(!part_get_info()) loop.
BR,
-R
Quoted 73 lines
Partition Map for USB device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 32768 00000000-01 0c Boot 4 40960 60021540 00000000-04 a6I changed the
part_get_info()debug messages to normal printfs and no error paths trigger:U-Boot 2017.11-rc1-00111-g97b86e3342-dirty (Oct 10 2017 - 03:28:40 +1100)
DRAM: 948 MiB
RPI 3 Model B (0xa02082)
MMC: sdhci at7e300000: 0
## Valid DOS partition found ##
reading uboot.envIn: 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: 0Device 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
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning usb 0:1...
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Found EFI removable media binary efi/boot/bootaa64.efi ## Valid DOS partition found ##
## Valid DOS partition found ##
reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##
## Valid DOS partition found ##
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthno match for type 4
depth=-1
i=0
i=1
i=2
i=3Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 77 lines · Rob Clark
Quoted 67 lines · Jonathan Gray
Quoted 56 lines · Rob Clark
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In
efi_disk_register()it should create objects for the disk itself (part==0, noMEDIA_DEVICEnodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).Quoted 7 lines
If
part_get_info()fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.BR,
-RIt is partitioned mbr style.
Quoted 8 lines
U-Boot> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 8192 00000000-01 0c Boot 4 16384 26624 00000000-04 a6U-Boot> part list usb 0
Quoted 6 lines
perhaps jumping from partition #1 to #4 is what is confusing things here? It's possible you end up with a partition "diskobj" for partition #1 but not #4?
Try adding a print in
efi_disk_register()and see how many times we go thru the while(!part_get_info()) loop.
Indeed, it seems to only end up calling efi_disk_add_dev() for part 1 in that loop:
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ## efi_disk_register calling efi_disk_add_dev for part 1 ## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ## efi_disk_register calling efi_disk_add_dev for part 1 ## Valid DOS partition found ##
Found 2 disks
If I change the code there to match other callers of part_get_info() I get a MEDIA_DEVICE type and can boot.
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ## efi_disk_register calling efi_disk_add_dev for part 1 ## Valid DOS partition found ##
## Valid DOS partition found ## efi_disk_register calling efi_disk_add_dev for part 4 ## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ## efi_disk_register calling efi_disk_add_dev for part 1 ## Valid DOS partition found ##
## Valid DOS partition found ## efi_disk_register calling efi_disk_add_dev for part 4 ## Valid DOS partition found ##
Found 2 disksefi_diskprobeefi_device_path_depth looking for type 4 i=0 type 1 efi_device_path_depth looking for type 4 i=1 type 3 efi_device_path_depth looking for type 4 i=2 type 3 efi_device_path_depth looking for type 4 i=3 type 3 efi_device_path_depth looking for type 4 i=4 type 4 depth=4
i=0
lib/efi_loader/efi_disk.c +11 -6
@@ -254,18 +254,20 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,#if CONFIG_IS_ENABLED (ISO_PARTITION )char devname[32 ] = {0 };/* dp->str is u16[32] long */ disk_partition_t info; -int part =1 ; +int part, ret;if (desc->part_type !=PART_TYPE_ISO )return 0 ;/* and devices for each partition: */ -while (!part_get_info (desc, part, &info)) { +for (part =1 ; part <=MAX_SEARCH_PARTITIONS ; part++) { + ret =part_get_info (desc, part, &info); +if (ret) +continue ;snprintf (devname,sizeof (devname),"%s:%d" , pdevname, part);efi_disk_add_dev (devname, if_typename, desc, diskid, info.start, part); - part++; disks++; }
@@ -299,15 +301,18 @@ int efi_disk_register(void)struct blk_desc *desc =dev_get_uclass_platdata (dev);const char *if_typename = dev->driver->name;disk_partition_t info; -int part =1 ; +int part, ret;printf ("Scanning disk %s...\n" , dev->name);/* add devices for each partition: */ -while (!part_get_info (desc, part, &info)) { +for (part =1 ; part <=MAX_SEARCH_PARTITIONS ; part++) { + ret =part_get_info (desc, part, &info); +if (ret) +continue ; +printf ("%s calling efi_disk_add_dev for part %d\n" , __func__, part);efi_disk_add_dev (dev->name, if_typename, desc, desc->devnum,0 , part); - part++; }/* ... and add block device: */
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 99 lines · Jonathan Gray
Quoted 77 lines · Rob Clark
Quoted 67 lines · Jonathan Gray
Quoted 56 lines · Rob Clark
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In
efi_disk_register()it should create objects for the disk itself (part==0, noMEDIA_DEVICEnodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).Quoted 7 lines
If
part_get_info()fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.BR,
-RIt is partitioned mbr style.
Quoted 8 lines
U-Boot> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 8192 00000000-01 0c Boot 4 16384 26624 00000000-04 a6U-Boot> part list usb 0
Quoted 6 lines
perhaps jumping from partition #1 to #4 is what is confusing things here? It's possible you end up with a partition "diskobj" for partition #1 but not #4?
Try adding a print in
efi_disk_register()and see how many times we go thru the while(!part_get_info()) loop.Indeed, it seems to only end up calling
efi_disk_add_dev()for part 1 in that loop:## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
Found 2 disks
Quoted 2 lines
If I change the code there to match other callers of
part_get_info()I get aMEDIA_DEVICEtype and can boot.
Ok, this makes sense now. There is one more loop to fix in the non-DM/BLK case (well, the one added by this patch, which I think agraf has already applied).
Care to send a patch?
BR,
-R
Quoted 75 lines
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 4 ## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 4 ## Valid DOS partition found ##
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthlooking for type 4 i=4 type 4 depth=4
i=0lib/efi_loader/efi_disk.c +11
-6@@ -254,18 +254,20 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,#if CONFIG_IS_ENABLED (ISO_PARTITION )char devname[32 ] = {0 };/* dp->str is u16[32] long */ disk_partition_t info; -int part =1 ; +int part, ret;if (desc->part_type !=PART_TYPE_ISO )return 0 ;/* and devices for each partition: */ -while (!part_get_info (desc, part, &info)) { +for (part =1 ; part <=MAX_SEARCH_PARTITIONS ; part++) { + ret =part_get_info (desc, part, &info); +if (ret) +continue ;snprintf (devname,sizeof (devname),"%s:%d" , pdevname, part);efi_disk_add_dev (devname, if_typename, desc, diskid, info.start, part); - part++; disks++; }@@ -299,15 +301,18 @@ int efi_disk_register(void)struct blk_desc *desc =dev_get_uclass_platdata (dev);const char *if_typename = dev->driver->name;disk_partition_t info; -int part =1 ; +int part, ret;printf ("Scanning disk %s...\n" , dev->name);/* add devices for each partition: */ -while (!part_get_info (desc, part, &info)) { +for (part =1 ; part <=MAX_SEARCH_PARTITIONS ; part++) { + ret =part_get_info (desc, part, &info); +if (ret) +continue ; +printf ("%s calling efi_disk_add_dev for part %d\n" , __func__, part);efi_disk_add_dev (dev->name, if_typename, desc, desc->devnum,0 , part); - part++; }/* ... and add block device: */
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 100 lines · Rob Clark
Quoted 99 lines · Jonathan Gray
Quoted 77 lines · Rob Clark
Quoted 67 lines · Jonathan Gray
Quoted 56 lines · Rob Clark
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In
efi_disk_register()it should create objects for the disk itself (part==0, noMEDIA_DEVICEnodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).Quoted 7 lines
If
part_get_info()fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.BR,
-RIt is partitioned mbr style.
Quoted 8 lines
U-Boot> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 8192 00000000-01 0c Boot 4 16384 26624 00000000-04 a6U-Boot> part list usb 0
Quoted 6 lines
perhaps jumping from partition #1 to #4 is what is confusing things here? It's possible you end up with a partition "diskobj" for partition #1 but not #4?
Try adding a print in
efi_disk_register()and see how many times we go thru the while(!part_get_info()) loop.Indeed, it seems to only end up calling
efi_disk_add_dev()for part 1 in that loop:## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
Found 2 disks
Quoted 6 lines
Quoted 2 lines
If I change the code there to match other callers of
part_get_info()I get aMEDIA_DEVICEtype and can boot.Ok, this makes sense now. There is one more loop to fix in the non-DM/BLK case (well, the one added by this patch, which I think agraf has already applied).
I think that also explains why I've seen issues on the Pine64 as we currently have a extended partition.
Quoted 84 lines
Care to send a patch?
BR,
-RQuoted 65 lines
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 4 ## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 4 ## Valid DOS partition found ##
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthlooking for type 4 i=4 type 4 depth=4
i=0lib/efi_loader/efi_disk.c +7
-5@@ -254,18 +254,20 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,#if CONFIG_IS_ENABLED (ISO_PARTITION )char devname[32 ] = {0 };/* dp->str is u16[32] long */ disk_partition_t info; -int part =1 ; +int part, ret;if (desc->part_type !=PART_TYPE_ISO )return 0 ;/* and devices for each partition: */ -while (!part_get_info (desc, part, &info)) { +for (part =1 ; part <=MAX_SEARCH_PARTITIONS ; part++) { + ret =part_get_info (desc, part, &info); +if (ret) +continue ;snprintf (devname,sizeof (devname),"%s:%d" , pdevname, part);efi_disk_add_dev (devname, if_typename, desc, diskid, info.start, part); - part++; disks++; }@@ -299,15 +301,18 @@ int efi_disk_register(void)struct blk_desc *desc =dev_get_uclass_platdata (dev);const char *if_typename = dev->driver->name;disk_partition_t info; -int part =1 ; +int part, ret;printf ("Scanning disk %s...\n" , dev->name);/* add devices for each partition: */ -while (!part_get_info (desc, part, &info)) { +for (part =1 ; part <=MAX_SEARCH_PARTITIONS ; part++) {lib/efi_loader/efi_disk.c int efi_disk_register(void) · line 318
Quoted 10 lines
lib/efi_loader/efi_disk.c +4
-1+ ret =part_get_info (desc, part, &info); +if (ret) +continue ; +printf ("%s calling efi_disk_add_dev for part %d\n" , __func__, part);efi_disk_add_dev (dev->name, if_typename, desc, desc->devnum,0 , part); - part++; }/* ... and add block device: */ _______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
In reply to Jonathan GrayQuoted 118 lines · Jonathan Gray
Quoted 77 lines · Rob Clark
Quoted 67 lines · Jonathan Gray
Quoted 56 lines · Rob Clark
Quoted 43 lines · Jonathan Gray
Quoted 37 lines · Rob Clark
Quoted 24 lines · Jonathan Gray
Quoted 23 lines · Rob Clark
Quoted 6 lines · Jonathan Gray
Quoted 5 lines · Rob Clark
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Quoted 9 lines
Quoted 2 lines
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>Thanks for looking into this. While this lets armv7/bootarm.efi boot again on cubox-i and bbb it doesn't help rpi3.
What is the easiest way to get U-Boot to display these paths to be able to compare the current behaviour to 2017.09?
in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar?
u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not.
Quoted 6 lines
Quoted 2 lines
BR,
-RWith git + your patch a node with type 4 (
DEVICE_PATH_TYPE_MEDIA_DEVICE) is no longer seen. Is it possible having U-Boot on mmc but directing it to load off usb is somehow involved here?There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one.
Quoted 4 lines
The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care.
Quoted 5 lines
I only see
MEDIA_DEVICEwith U-Boot 2017.09. The latest code in master only gives types of 1 (Hardware Device Path) and 3 (Messaging Device Path).It is DM in this case:
Possibly something weird with your partition table? In
efi_disk_register()it should create objects for the disk itself (part==0, noMEDIA_DEVICEnodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).Quoted 7 lines
If
part_get_info()fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver.BR,
-RIt is partitioned mbr style.
Quoted 8 lines
U-Boot> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 8192 00000000-01 0c Boot 4 16384 26624 00000000-04 a6U-Boot> part list usb 0
Quoted 6 lines
perhaps jumping from partition #1 to #4 is what is confusing things here? It's possible you end up with a partition "diskobj" for partition #1 but not #4?
Try adding a print in
efi_disk_register()and see how many times we go thru the while(!part_get_info()) loop.Indeed, it seems to only end up calling
efi_disk_add_dev()for part 1 in that loop:## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
Found 2 disksIf I change the code there to match other callers of
part_get_info()I get aMEDIA_DEVICEtype and can boot.## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 4 ## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 1 ## Valid DOS partition found ##
## Valid DOS partition found ##efi_disk_registercallingefi_disk_add_devfor part 4 ## Valid DOS partition found ##
Found 2 disks
Quoted 8 lines
efi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthlooking for type 4 i=4 type 4 depth=4
i=0
While U-Boot 2017.11 release works with vexpress/qemu with the efi loader it is broken on at least rpi_3 and tinker-rk3288. MEDIA_DEVICE is not found again.
U-Boot 2017.09 (Nov 16 2017 - 04:05:33 -0700)
DRAM: 948 MiB
RPI 3 Model B (0xa02082)
MMC: sdhci at 7e300000: 0
reading uboot.env
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 reading efi/boot/bootaa64.efi
78959 bytes read in 75 ms (1 MiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depth looking for type 4 i=0 type 4 depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
i=1
efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330
U-Boot 2017.11 (Nov 15 2017 - 13:14:19 +1100)
DRAM: 948 MiB
RPI 3 Model B (0xa02082)
MMC: sdhci at 7e300000: 0
reading uboot.env
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 reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depth looking for type 4 i=0 type 1 efi_device_path_depth looking for type 4 i=1 type 3 efi_device_path_depth looking for type 4 i=2 type 3 efi_device_path_depth looking for type 4 i=3 type 3 efi_device_path_depth no match for type 4 depth=-1
i=0
i=1
i=2
i=3
i=4
i=5
Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
Turning timeout off.
boot>
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 4 lines · Jonathan Gray
While U-Boot 2017.11 release works with vexpress/qemu with the efi loader it is broken on at least
rpi_3and tinker-rk3288.MEDIA_DEVICEis not found again.
The loaded image paths look like the below.
vexpress and qemu_arm (virt) have a MEDIA_DEVICE, rpi_3 and tinkerboard do not.
Having boot_targets load bootarm.efi from mmc on rpi_3 works but having it load from usb does not.
vexpress
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on mmc...efi_disk_add_dev: name: mmc0 if_typename: mmc part: 1efi_disk_add_dev: name: mmc0 if_typename: mmc part: 4efi_disk_add_dev: name: mmc0 if_typename: mmc part: 0
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 1 disks
reading efi/boot/bootarm.efi
67436 bytes read in 45 ms (1.4 MiB/s)
## Starting EFI application at a0008000 ...efi_setup_loaded_image: device_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Usb(0x6,0x0)/HD(Part0,MBRType=01,SigType=00)efi_setup_loaded_image: file_path /\efi\boot\bootarm.efi
=> dm tree
Unknown command 'dm' - try 'help'
=> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 2048 4096 00000000-01 0c Boot 4 6144 30720 00000000-04 a6
qemu_arm
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disk ahci_scsi.id0lun0...efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 1efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 4efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 0
Found 1 disks
reading efi/boot/bootarm.efi
67436 bytes read in 9 ms (7.1 MiB/s)
## Starting EFI application at 40400000 ...efi_setup_loaded_image: device_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/HD(Part0,MBRType=01,SigType=00)efi_setup_loaded_image: file_path /\efi\boot\bootarm.efi
=> dm tree
Class Probed Driver Name
----------------------------------------
root [ + ] root_drive root_driver simple_bus [ ] generic_si |-- platform at c000000 pci [ + ] pci_generi |-- pcie at 10000000 pci_generi [ ] pci_generi | |-- pci_0:0.0 pci_generi [ ] pci_generi | |-- pci_0:1.0 ahci [ ] ahci_pci | `-- ahci_pci scsi [ ] ahci_scsi | `-- ahci_scsi serial [ + ] serial_pl0 |-- pl011 at 9000000 firmware [ ] psci `-- psci sysreset [ ] psci-sysre `-- psci-sysreset
=> part list scsi 0
Partition Map for SCSI device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 2048 4096 00000000-01 0c Boot 4 6144 30720 00000000-04 a6
rpi3
U-Boot> printenv boot_targets
boot_targets=usb0 mmc0 pxe dhcp
## Starting EFI application at 01000000 ...
Scanning disk sdhci at 7e300000.blk...efi_disk_add_dev: name: sdhci at 7e300000.blk if_typename: mmc_blk part: 1efi_disk_add_dev: name: sdhci at 7e300000.blk if_typename: mmc_blk part: 4efi_disk_add_dev: name: sdhci at 7e300000.blk if_typename: mmc_blk part: 0
Scanning disk usb_mass_storage.lun0...efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 1efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 4efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 0
Found 2 disksefi_setup_loaded_image: device_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00)efi_setup_loaded_image: file_path /\efi\boot\bootaa64.efi
U-Boot> printenv boot_targets
boot_targets=mmc0 usb0 pxe dhcp
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
78623 bytes read in 31 ms (2.4 MiB/s)
## Starting EFI application at 01000000 ...
Scanning disk sdhci at 7e300000.blk...efi_disk_add_dev: name: sdhci at 7e300000.blk if_typename: mmc_blk part: 1efi_disk_add_dev: name: sdhci at 7e300000.blk if_typename: mmc_blk part: 4efi_disk_add_dev: name: sdhci at 7e300000.blk if_typename: mmc_blk part: 0
Scanning disk usb_mass_storage.lun0...efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 1efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 4efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 0
Found 2 disksefi_setup_loaded_image: device_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot0)/HD(Part0,MBRType=01,SigType=00)efi_setup_loaded_image: file_path /\efi\boot\bootaa64.efi
U-Boot> dm tree
Class Probed Driver Name
----------------------------------------
root [ + ] root_drive root_driver simple_bus [ + ] generic_si |-- soc gpio [ + ] gpio_bcm28 | |-- gpio at 7e200000 serial [ + ] serial_bcm | |-- serial at 7e215040 mmc [ + ] sdhci-bcm2 | |-- sdhci at 7e300000 blk [ + ] mmc_blk | | `-- sdhci at 7e300000.blk video [ + ] bcm2835_vi | |-- hdmi at 7e902000 vidconsole [ + ] vidconsole | | `-- hdmi at 7e902000.vidconsole0 usb [ + ] dwc2_usb | `-- usb at 7e980000 usb_hub [ + ] usb_hub | `-- usb_hub usb_hub [ + ] usb_hub | `-- usb_hub eth [ + ] smsc95xx_e | |-- smsc95xx_eth usb_mass_s [ + ] usb_mass_s | `-- usb_mass_storage blk [ ] usb_storag | `-- usb_mass_storage.lun0 simple_bus [ ] generic_si `-- clocks
U-Boot> part list usb 0
Partition Map for USB device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 32768 00000000-01 0c Boot 4 40960 60021540 00000000-04 a6
U-Boot> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 8192 00000000-01 0c Boot 4 16384 26624 00000000-04 a6
tinkerboard
Scanning mmc 1:1...
Found EFI removable media binary efi/boot/bootarm.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk dwmmc at ff0c0000.blk...efi_disk_add_dev: name: dwmmc at ff0c0000.blk if_typename: mmc_blk part: 1efi_disk_add_dev: name: dwmmc at ff0c0000.blk if_typename: mmc_blk part: 4efi_disk_add_dev: name: dwmmc at ff0c0000.blk if_typename: mmc_blk part: 0
Found 1 disks
reading efi/boot/bootarm.efi
67356 bytes read in 10 ms (6.4 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
## Starting EFI application at 02000000 ...efi_setup_loaded_image: device_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot1)/HD(Part0,MBRType=01,SigType=00)efi_setup_loaded_image: file_path /\efi\boot\bootarm.efi
=> part list mmc 1
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 2048 32768 00000000-01 0c Boot 4 34816 62299136 00000000-04 a6
=> dm tree
Class Probed Driver Name
----------------------------------------
root [ + ] root_drive root_driver
clk [ ] fixed_rate |-- oscillator mmc [ + ] rockchip_r |-- dwmmc at ff0c0000 blk [ + ] mmc_blk | `-- dwmmc at ff0c0000.blk adc [ ] rockchip_s |-- saradc at ff100000 i2c [ ] i2c_rockch |-- i2c at ff170000 serial [ ] ns16550_se |-- serial at ff180000 serial [ ] ns16550_se |-- serial at ff190000 serial [ + ] ns16550_se |-- serial at ff690000 serial [ ] ns16550_se |-- serial at ff1b0000 serial [ ] ns16550_se |-- serial at ff1c0000 eth [ + ] gmac_rockc |-- ethernet at ff290000 usb [ ] dwc2_usb |-- usb at ff540000 usb [ ] dwc2_usb |-- usb at ff580000 ram [ ] rockchip_r |-- dmc at ff610000 i2c [ + ] i2c_rockch |-- i2c at ff650000 pmic [ + ] rk8xx pmic | `-- pmic at 1b regulator [ ] rk8xx_buck | |-- DCDC_REG1 regulator [ ] rk8xx_buck | |-- DCDC_REG2 regulator [ ] rk8xx_buck | |-- DCDC_REG3 regulator [ ] rk8xx_buck | |-- DCDC_REG4 regulator [ ] rk8xx_ldo | |-- LDO_REG1 regulator [ ] rk8xx_ldo | |-- LDO_REG2 regulator [ ] rk8xx_ldo | |-- LDO_REG3 regulator [ ] rk8xx_ldo | |-- LDO_REG4 regulator [ ] rk8xx_ldo | |-- LDO_REG5 regulator [ ] rk8xx_ldo | |-- LDO_REG6 regulator [ ] rk8xx_ldo | |-- LDO_REG7 regulator [ ] rk8xx_ldo | |-- LDO_REG8 regulator [ ] rk8xx_swit | |-- SWITCH_REG1 regulator [ + ] rk8xx_swit | `-- SWITCH_REG2 i2c [ + ] i2c_rockch |-- i2c at ff660000 i2c_eeprom [ + ] i2c_eeprom | `-- m24c08 at 50 pwm [ ] rk_pwm |-- pwm at ff680000 pwm [ ] rk_pwm |-- pwm at ff680010 syscon [ + ] rk3288_sys |-- power-management at ff730000 syscon [ ] rk3288_sys |-- syscon at ff740000 clk [ + ] rockchip_r |-- clock-controller at ff760000 sysreset [ ] rk3288_sys |-- reset syscon [ + ] rk3288_sys |-- syscon at ff770000 syscon [ ] rk3288_sys |-- syscon at ffac0000 pinctrl [ + ] rockchip_r |-- pinctrl gpio [ ] gpio_rockc | |-- gpio0 at ff750000 gpio [ ] gpio_rockc | |-- gpio1 at ff780000 gpio [ ] gpio_rockc | |-- gpio2 at ff790000 gpio [ ] gpio_rockc | |-- gpio3 at ff7a0000 gpio [ + ] gpio_rockc | |-- gpio4 at ff7b0000 gpio [ ] gpio_rockc | |-- gpio5 at ff7c0000 gpio [ ] gpio_rockc | |-- gpio6 at ff7d0000 gpio [ + ] gpio_rockc | |-- gpio7 at ff7e0000 gpio [ ] gpio_rockc | |-- gpio8 at ff7f0000 pinconfig [ ] pinconfig | |-- pcfg-pull-up pinconfig [ ] pinconfig | |-- pcfg-pull-down pinconfig [ ] pinconfig | |-- pcfg-pull-none pinconfig [ ] pinconfig | |-- pcfg-pull-none-12ma pinconfig [ + ] pinconfig | |-- sleep pinconfig [ + ] pinconfig | | |-- global-pwroff pinconfig [ ] pinconfig | | |-- ddrio-pwroff pinconfig [ ] pinconfig | | |-- ddr0-retention pinconfig [ ] pinconfig | | `-- ddr1-retention pinconfig [ + ] pinconfig | |-- i2c0 pinconfig [ + ] pinconfig | | `-- i2c0-xfer pinconfig [ ] pinconfig | |-- i2c1 pinconfig [ ] pinconfig | | `-- i2c1-xfer pinconfig [ + ] pinconfig | |-- i2c2 pinconfig [ + ] pinconfig | | `-- i2c2-xfer pinconfig [ ] pinconfig | |-- i2c3 pinconfig [ ] pinconfig | | `-- i2c3-xfer pinconfig [ ] pinconfig | |-- i2c4 pinconfig [ ] pinconfig | | `-- i2c4-xfer pinconfig [ ] pinconfig | |-- i2c5 pinconfig [ ] pinconfig | | `-- i2c5-xfer pinconfig [ ] pinconfig | |-- i2s0 pinconfig [ ] pinconfig | | `-- i2s0-bus pinconfig [ ] pinconfig | |-- lcdc0 pinconfig [ ] pinconfig | | `-- lcdc0-ctl pinconfig [ + ] pinconfig | |-- sdmmc pinconfig [ + ] pinconfig | | |-- sdmmc-clk pinconfig [ + ] pinconfig | | |-- sdmmc-cmd pinconfig [ + ] pinconfig | | |-- sdmcc-cd pinconfig [ ] pinconfig | | |-- sdmmc-bus1 pinconfig [ + ] pinconfig | | |-- sdmmc-bus4 pinconfig [ + ] pinconfig | | `-- sdmmc-pwr pinconfig [ ] pinconfig | |-- sdio0 pinconfig [ ] pinconfig | | |-- sdio0-bus1 pinconfig [ ] pinconfig | | |-- sdio0-bus4 pinconfig [ ] pinconfig | | |-- sdio0-cmd pinconfig [ ] pinconfig | | |-- sdio0-clk pinconfig [ ] pinconfig | | |-- sdio0-cd pinconfig [ ] pinconfig | | |-- sdio0-wp pinconfig [ ] pinconfig | | |-- sdio0-pwr pinconfig [ ] pinconfig | | |-- sdio0-bkpwr pinconfig [ ] pinconfig | | `-- sdio0-int pinconfig [ ] pinconfig | |-- sdio1 pinconfig [ ] pinconfig | | |-- sdio1-bus1 pinconfig [ ] pinconfig | | |-- sdio1-bus4 pinconfig [ ] pinconfig | | |-- sdio1-cd pinconfig [ ] pinconfig | | |-- sdio1-wp pinconfig [ ] pinconfig | | |-- sdio1-bkpwr pinconfig [ ] pinconfig | | |-- sdio1-int pinconfig [ ] pinconfig | | |-- sdio1-cmd pinconfig [ ] pinconfig | | |-- sdio1-clk pinconfig [ ] pinconfig | | `-- sdio1-pwr pinconfig [ ] pinconfig | |-- emmc pinconfig [ ] pinconfig | | |-- emmc-clk pinconfig [ ] pinconfig | | |-- emmc-cmd pinconfig [ ] pinconfig | | |-- emmc-pwr pinconfig [ ] pinconfig | | |-- emmc-bus1 pinconfig [ ] pinconfig | | |-- emmc-bus4 pinconfig [ ] pinconfig | | `-- emmc-bus8 pinconfig [ ] pinconfig | |-- spi0 pinconfig [ ] pinconfig | | |-- spi0-clk pinconfig [ ] pinconfig | | |-- spi0-cs0 pinconfig [ ] pinconfig | | |-- spi0-tx pinconfig [ ] pinconfig | | |-- spi0-rx pinconfig [ ] pinconfig | | `-- spi0-cs1 pinconfig [ ] pinconfig | |-- spi1 pinconfig [ ] pinconfig | | |-- spi1-clk pinconfig [ ] pinconfig | | |-- spi1-cs0 pinconfig [ ] pinconfig | | |-- spi1-rx pinconfig [ ] pinconfig | | `-- spi1-tx pinconfig [ ] pinconfig | |-- spi2 pinconfig [ ] pinconfig | | |-- spi2-cs1 pinconfig [ ] pinconfig | | |-- spi2-clk pinconfig [ ] pinconfig | | |-- spi2-cs0 pinconfig [ ] pinconfig | | |-- spi2-rx pinconfig [ ] pinconfig | | `-- spi2-tx pinconfig [ ] pinconfig | |-- uart0 pinconfig [ ] pinconfig | | |-- uart0-xfer pinconfig [ ] pinconfig | | |-- uart0-cts pinconfig [ ] pinconfig | | `-- uart0-rts pinconfig [ ] pinconfig | |-- uart1 pinconfig [ ] pinconfig | | |-- uart1-xfer pinconfig [ ] pinconfig | | |-- uart1-cts pinconfig [ ] pinconfig | | `-- uart1-rts pinconfig [ + ] pinconfig | |-- uart2 pinconfig [ + ] pinconfig | | `-- uart2-xfer pinconfig [ ] pinconfig | |-- uart3 pinconfig [ ] pinconfig | | |-- uart3-xfer pinconfig [ ] pinconfig | | |-- uart3-cts pinconfig [ ] pinconfig | | `-- uart3-rts pinconfig [ ] pinconfig | |-- uart4 pinconfig [ ] pinconfig | | |-- uart4-xfer pinconfig [ ] pinconfig | | |-- uart4-cts pinconfig [ ] pinconfig | | `-- uart4-rts pinconfig [ ] pinconfig | |-- tsadc pinconfig [ ] pinconfig | | `-- otp-out pinconfig [ ] pinconfig | |-- pwm0 pinconfig [ ] pinconfig | | `-- pwm0-pin pinconfig [ ] pinconfig | |-- pwm1 pinconfig [ ] pinconfig | | `-- pwm1-pin pinconfig [ ] pinconfig | |-- pwm2 pinconfig [ ] pinconfig | | `-- pwm2-pin pinconfig [ ] pinconfig | |-- pwm3 pinconfig [ ] pinconfig | | `-- pwm3-pin pinconfig [ + ] pinconfig | |-- gmac pinconfig [ + ] pinconfig | | |-- rgmii-pins pinconfig [ ] pinconfig | | `-- rmii-pins pinconfig [ ] pinconfig | |-- spdif pinconfig [ ] pinconfig | | `-- spdif-tx pinconfig [ ] pinconfig | |-- pcfg-pull-none-drv-8ma pinconfig [ ] pinconfig | |-- pcfg-pull-up-drv-8ma pinconfig [ ] pinconfig | |-- backlight pinconfig [ ] pinconfig | | `-- bl-en pinconfig [ ] pinconfig | |-- buttons pinconfig [ ] pinconfig | | `-- pwrbtn pinconfig [ ] pinconfig | |-- eth_phy pinconfig [ ] pinconfig | | `-- eth-phy-pwr pinconfig [ + ] pinconfig | |-- pmic pinconfig [ + ] pinconfig | | `-- pmic-int pinconfig [ ] pinconfig | `-- usb pinconfig [ ] pinconfig | |-- host-vbus-drv pinconfig [ ] pinconfig | `-- pwr-3g clk [ ] fixed_rate |-- external-gmac-clock regulator [ ] fixed regu |-- vsys-regulator regulator [ + ] fixed regu |-- sdmmc-regulator regulator [ ] fixed regu `-- usb-host-regulator
=>
Quoted 96 lines
U-Boot 2017.09 (Nov 16 2017 - 04:05:33 -0700)
DRAM: 948 MiB
RPI 3 Model B (0xa02082)
MMC: sdhci at7e300000: 0
reading uboot.envIn: 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: 0Device 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 reading efi/boot/bootaa64.efi
78959 bytes read in 75 ms (1 MiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk...
Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 4 depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
i=1
efi_bootdp=Dusbmassstoragelun dp=DusbmassstoragelunQuoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330U-Boot 2017.11 (Nov 15 2017 - 13:14:19 +1100)
DRAM: 948 MiB
RPI 3 Model B (0xa02082)
MMC: sdhci at7e300000: 0
reading uboot.envIn: 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: 0Device 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 reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 01000000 ... Scanning disk sdhci at 7e300000.blk... Scanning disk usb_mass_storage.lun0...
Found 2 disksefi_diskprobeefi_device_path_depthlooking for type 4 i=0 type 1efi_device_path_depthlooking for type 4 i=1 type 3efi_device_path_depthlooking for type 4 i=2 type 3efi_device_path_depthlooking for type 4 i=3 type 3efi_device_path_depthno match for type 4 depth=-1
i=0
i=1
i=2
i=3
i=4
i=5Quoted 1 line
Quoted 1 line
OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
boot>
cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
Turning timeout off.
boot>
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot
PATCH 1/1 efi_loader: Fix disk dp's for pre-DM/legacy devices
Quoted 6 lines · Jonathan Gray
Quoted 4 lines · Jonathan Gray
While U-Boot 2017.11 release works with vexpress/qemu with the efi loader it is broken on at least
rpi_3and tinker-rk3288.MEDIA_DEVICEis not found again.
Quoted 7 lines
The loaded image paths look like the below.
vexpress and
qemu_arm(virt) have aMEDIA_DEVICE,rpi_3and tinkerboard do not.Having
boot_targetsload bootarm.efi from mmc onrpi_3works but having it load from usb does not.
The following efi_dp_match call should match but doesn't as two bytes in the dp path nodes differ.
Forcing this to match returns the correct dp with a MEDIA_DEVICE and allows the system to boot.
This turns out to be the partition_signature. It is uninitialised memory. The diff below to zero that part of the device path node fixes the comparison.
find_obj efi_dp_match /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00) /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00) efi_dp_match depth 0 alen 20 blen 20efi_dp_match A
01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8
28 f3 62 8befi_dp_match B
01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8
28 f3 62 8befi_dp_match depth 1 alen 11 blen 11efi_dp_match A
03 0f 0b 00 00 00 00 00 09 00 00efi_dp_match B
03 0f 0b 00 00 00 00 00 09 00 00efi_dp_match depth 2 alen 11 blen 11efi_dp_match A
03 0f 0b 00 24 04 14 95 09 00 02efi_dp_match B
03 0f 0b 00 24 04 14 95 09 00 02efi_dp_match depth 3 alen 11 blen 11efi_dp_match A
03 0f 0b 00 81 07 81 55 00 00 00efi_dp_match B
03 0f 0b 00 81 07 81 55 00 00 00efi_dp_match depth 4 alen 42 blen 42efi_dp_match A
04 01 2a 00 00 00 00 00 00 20 00 00 00 00 00 00
00 80 00 00 00 00 00 00 15 55 55 55 55 55 d5 c1
55 55 51 55 55 45 51 55 01 00efi_dp_match B
04 01 2a 00 00 00 00 00 00 20 00 00 00 00 00 00
00 80 00 00 00 00 00 00 57 15 05 15 55 55 55 50
d5 55 55 55 55 55 50 75 01 00
lib/efi_loader/efi_device_path.c +3 -0
@@ -431,6 +431,9 @@ static void *dp_part_fill(void *buf, struct blk_desc *desc, int part)if (hddp->signature_type !=0 )memcpy (hddp->partition_signature, &desc->guid_sig,sizeof (hddp->partition_signature)); +else +memset (hddp->partition_signature,0 , +sizeof (hddp->partition_signature)); buf = &hddp[1 ]; }
Alexander Graf
AppliedQuoted 7 lines
This fixes an issue with OpenBSD's bootloader, and I think should also fix a similar issue with grub2 on legacy devices. In the legacy case we were creating disk objects for the partitions, but not also the parent device.
Reported-by Jonathan Gray <[email protected]>Signed-off-by Rob Clark <[email protected]>
Thanks, applied to efi-next
Alex