* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices @ 2017-10-08 15:33 Rob Clark 2017-10-09 3:33 ` Jonathan Gray 2017-10-09 4:43 ` [U-Boot] " Alexander Graf 0 siblings, 2 replies; 18+ messages in thread From: Rob Clark @ 2017-10-08 15:33 UTC (permalink / raw) To: u-boot 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 <jsg@jsg.id.au> Signed-off-by: Rob Clark <robdclark@gmail.com> --- lib/efi_loader/efi_disk.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index eb9ce772d1..47b487aa30 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -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++; -- 2.13.6 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-08 15:33 [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices Rob Clark @ 2017-10-09 3:33 ` Jonathan Gray 2017-10-09 10:52 ` Rob Clark 2017-10-09 4:43 ` [U-Boot] " Alexander Graf 1 sibling, 1 reply; 18+ messages in thread From: Jonathan Gray @ 2017-10-09 3:33 UTC (permalink / raw) To: u-boot On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: > 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 <jsg@jsg.id.au> > Signed-off-by: Rob Clark <robdclark@gmail.com> 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 >> 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> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 3:33 ` Jonathan Gray @ 2017-10-09 10:52 ` Rob Clark 2017-10-09 12:25 ` Jonathan Gray 0 siblings, 1 reply; 18+ messages in thread From: Rob Clark @ 2017-10-09 10:52 UTC (permalink / raw) To: u-boot On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> 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 <jsg@jsg.id.au> >> Signed-off-by: Rob Clark <robdclark@gmail.com> > > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 10:52 ` Rob Clark @ 2017-10-09 12:25 ` Jonathan Gray 2017-10-09 14:17 ` Rob Clark 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Gray @ 2017-10-09 12:25 UTC (permalink / raw) To: u-boot On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: > On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: > >> 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 <jsg@jsg.id.au> > >> Signed-off-by: Rob Clark <robdclark@gmail.com> > > > > 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 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 disks efi_diskprobe efi_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 >> 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 disks efi_diskprobe efi_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 >> OpenBSD/arm64 BOOTAA64 0.8 boot> cannot open sd0a:/etc/random.seed: Device not configured booting sd0a:/bsd: open sd0a:/bsd: Device not configured ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 12:25 ` Jonathan Gray @ 2017-10-09 14:17 ` Rob Clark 2017-10-09 15:35 ` Jonathan Gray 0 siblings, 1 reply; 18+ messages in thread From: Rob Clark @ 2017-10-09 14:17 UTC (permalink / raw) To: u-boot On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> 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 <jsg@jsg.id.au> >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> >> > >> > 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 > > 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? 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. > 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 disks > efi_diskprobe > efi_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 >>> OpenBSD/arm64 BOOTAA64 0.8 > boot> > booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330 > > 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.) BR, -R > 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 disks > efi_diskprobe > efi_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 >>> OpenBSD/arm64 BOOTAA64 0.8 > boot> > cannot open sd0a:/etc/random.seed: Device not configured > booting sd0a:/bsd: open sd0a:/bsd: Device not configured ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 14:17 ` Rob Clark @ 2017-10-09 15:35 ` Jonathan Gray 2017-10-09 16:06 ` Rob Clark 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Gray @ 2017-10-09 15:35 UTC (permalink / raw) To: u-boot On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: > On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: > >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: > >> >> 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 <jsg@jsg.id.au> > >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> > >> > > >> > 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 > > > > 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? > > 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. 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 > > > 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 disks > > efi_diskprobe > > efi_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 > >>> OpenBSD/arm64 BOOTAA64 0.8 > > boot> > > booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330 > > > > 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_diskprobe efi_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 >> 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 >> OpenBSD/arm64 BOOTAA64 0.8 boot> booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 15:35 ` Jonathan Gray @ 2017-10-09 16:06 ` Rob Clark 2017-10-09 16:22 ` Heinrich Schuchardt 2017-10-09 16:41 ` Jonathan Gray 0 siblings, 2 replies; 18+ messages in thread From: Rob Clark @ 2017-10-09 16:06 UTC (permalink / raw) To: u-boot On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> >> 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 <jsg@jsg.id.au> >> >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> >> >> > >> >> > 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 >> > >> > 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? >> >> 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. > > 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: 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 > 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 > >> >> > 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 disks >> > efi_diskprobe >> > efi_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 >> >>> OpenBSD/arm64 BOOTAA64 0.8 >> > boot> >> > booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330 >> > >> > 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_diskprobe > efi_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 >>> 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 >>> OpenBSD/arm64 BOOTAA64 0.8 > boot> > booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 16:06 ` Rob Clark @ 2017-10-09 16:22 ` Heinrich Schuchardt 2017-10-09 17:02 ` Rob Clark 2017-10-09 16:41 ` Jonathan Gray 1 sibling, 1 reply; 18+ messages in thread From: Heinrich Schuchardt @ 2017-10-09 16:22 UTC (permalink / raw) To: u-boot On 10/09/2017 06:06 PM, Rob Clark wrote: > On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >>>> On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >>>>> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >>>>>> On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >>>>>>> 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 <jsg@jsg.id.au> >>>>>>> Signed-off-by: Rob Clark <robdclark@gmail.com> >>>>>> >>>>>> 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 >>>> >>>> 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? >>> >>> 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. >> >> 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: > > 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 > > >> 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 >> >>> >>>> 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 disks >>>> efi_diskprobe >>>> efi_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 >>>>>> OpenBSD/arm64 BOOTAA64 0.8 >>>> boot> >>>> booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330 >>>> >>>> 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_diskprobe >> efi_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 >>>> 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 >>>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 16:22 ` Heinrich Schuchardt @ 2017-10-09 17:02 ` Rob Clark 0 siblings, 0 replies; 18+ messages in thread From: Rob Clark @ 2017-10-09 17:02 UTC (permalink / raw) To: u-boot On Mon, Oct 9, 2017 at 12:22 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > On 10/09/2017 06:06 PM, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >>> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >>>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >>>>> On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >>>>>> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >>>>>>> On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >>>>>>>> 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 <jsg@jsg.id.au> >>>>>>>> Signed-off-by: Rob Clark <robdclark@gmail.com> >>>>>>> >>>>>>> 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 >>>>> >>>>> 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? >>>> >>>> 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. >>> >>> 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: >> >> 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 >> >> >>> 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 >>> >>>> >>>>> 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 disks >>>>> efi_diskprobe >>>>> efi_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 >>>>>>> OpenBSD/arm64 BOOTAA64 0.8 >>>>> boot> >>>>> booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330 >>>>> >>>>> 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_diskprobe >>> efi_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 >>>>> 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 >>>>> 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? > 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".. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 16:06 ` Rob Clark 2017-10-09 16:22 ` Heinrich Schuchardt @ 2017-10-09 16:41 ` Jonathan Gray 2017-10-09 17:06 ` Rob Clark 1 sibling, 1 reply; 18+ messages in thread From: Jonathan Gray @ 2017-10-09 16:41 UTC (permalink / raw) To: u-boot On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote: > On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: > >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: > >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: > >> >> >> 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 <jsg@jsg.id.au> > >> >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> > >> >> > > >> >> > 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 > >> > > >> > 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? > >> > >> 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. > > > > 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: > > 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 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 disks efi_diskprobe efi_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 >> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 16:41 ` Jonathan Gray @ 2017-10-09 17:06 ` Rob Clark 2017-10-09 17:48 ` Jonathan Gray 0 siblings, 1 reply; 18+ messages in thread From: Rob Clark @ 2017-10-09 17:06 UTC (permalink / raw) To: u-boot On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> >> >> 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 <jsg@jsg.id.au> >> >> >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> >> >> >> > >> >> >> > 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 >> >> > >> >> > 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? >> >> >> >> 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. >> > >> > 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: >> >> 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 > > 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 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 > 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 disks > efi_diskprobe > efi_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 >>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 17:06 ` Rob Clark @ 2017-10-09 17:48 ` Jonathan Gray 2017-10-09 18:20 ` Rob Clark 2017-11-18 4:25 ` Jonathan Gray 0 siblings, 2 replies; 18+ messages in thread From: Jonathan Gray @ 2017-10-09 17:48 UTC (permalink / raw) To: u-boot On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote: > On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote: > >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: > >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: > >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: > >> >> >> >> 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 <jsg@jsg.id.au> > >> >> >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> > >> >> >> > > >> >> >> > 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 > >> >> > > >> >> > 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? > >> >> > >> >> 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. > >> > > >> > 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: > >> > >> 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 > > > > 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 > > 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 disks efi_diskprobe efi_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 diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index eb9ce772d1..d34a5b3e5e 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -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: */ ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 17:48 ` Jonathan Gray @ 2017-10-09 18:20 ` Rob Clark 2017-10-09 18:36 ` Peter Robinson 2017-11-18 4:25 ` Jonathan Gray 1 sibling, 1 reply; 18+ messages in thread From: Rob Clark @ 2017-10-09 18:20 UTC (permalink / raw) To: u-boot On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote: >> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >> >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >> >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> >> >> >> 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 <jsg@jsg.id.au> >> >> >> >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> >> >> >> >> > >> >> >> >> > 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 >> >> >> > >> >> >> > 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? >> >> >> >> >> >> 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. >> >> > >> >> > 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: >> >> >> >> 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 >> > >> > 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 >> >> 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. 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 > ## 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 disks > efi_diskprobe > efi_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 > > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c > index eb9ce772d1..d34a5b3e5e 100644 > --- a/lib/efi_loader/efi_disk.c > +++ b/lib/efi_loader/efi_disk.c > @@ -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: */ ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 18:20 ` Rob Clark @ 2017-10-09 18:36 ` Peter Robinson 0 siblings, 0 replies; 18+ messages in thread From: Peter Robinson @ 2017-10-09 18:36 UTC (permalink / raw) To: u-boot On Mon, Oct 9, 2017 at 7:20 PM, Rob Clark <robdclark@gmail.com> wrote: > On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >> On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote: >>> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >>> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote: >>> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >>> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >>> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: >>> >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >>> >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: >>> >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >>> >> >> >> >> 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 <jsg@jsg.id.au> >>> >> >> >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> >>> >> >> >> > >>> >> >> >> > 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 >>> >> >> > >>> >> >> > 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? >>> >> >> >>> >> >> 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. >>> >> > >>> >> > 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: >>> >> >>> >> 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 >>> > >>> > 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 >>> >>> 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. > > 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. > Care to send a patch? > > BR, > -R > >> ## 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 disks >> efi_diskprobe >> efi_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 >> >> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c >> index eb9ce772d1..d34a5b3e5e 100644 >> --- a/lib/efi_loader/efi_disk.c >> +++ b/lib/efi_loader/efi_disk.c >> @@ -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: */ > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-09 17:48 ` Jonathan Gray 2017-10-09 18:20 ` Rob Clark @ 2017-11-18 4:25 ` Jonathan Gray 2017-11-21 5:59 ` Jonathan Gray 1 sibling, 1 reply; 18+ messages in thread From: Jonathan Gray @ 2017-11-18 4:25 UTC (permalink / raw) To: u-boot On Tue, Oct 10, 2017 at 04:48:01AM +1100, Jonathan Gray wrote: > On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote: > > On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > > > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote: > > >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > > >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: > > >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@jsg.id.au> wrote: > > >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: > > >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@jsg.id.au> wrote: > > >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: > > >> >> >> >> 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 <jsg@jsg.id.au> > > >> >> >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> > > >> >> >> > > > >> >> >> > 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 > > >> >> > > > >> >> > 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? > > >> >> > > >> >> 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. > > >> > > > >> > 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: > > >> > > >> 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 > > > > > > 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 > > > > 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 disks > efi_diskprobe > efi_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 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 disks efi_diskprobe efi_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 >> 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 disks efi_diskprobe efi_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 >> 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> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-11-18 4:25 ` Jonathan Gray @ 2017-11-21 5:59 ` Jonathan Gray 2017-11-21 12:01 ` Jonathan Gray 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Gray @ 2017-11-21 5:59 UTC (permalink / raw) To: u-boot On Sat, Nov 18, 2017 at 03:25:29PM +1100, Jonathan Gray wrote: > > 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. 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: 1 efi_disk_add_dev: name: mmc0 if_typename: mmc part: 4 efi_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: 1 efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 4 efi_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: 1 efi_disk_add_dev: name: sdhci at 7e300000.blk if_typename: mmc_blk part: 4 efi_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: 1 efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 4 efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 0 Found 2 disks efi_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: 1 efi_disk_add_dev: name: sdhci at 7e300000.blk if_typename: mmc_blk part: 4 efi_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: 1 efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 4 efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk part: 0 Found 2 disks efi_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: 1 efi_disk_add_dev: name: dwmmc at ff0c0000.blk if_typename: mmc_blk part: 4 efi_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 => > > 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 disks > efi_diskprobe > efi_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 > >> 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 disks > efi_diskprobe > efi_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 > >> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-11-21 5:59 ` Jonathan Gray @ 2017-11-21 12:01 ` Jonathan Gray 0 siblings, 0 replies; 18+ messages in thread From: Jonathan Gray @ 2017-11-21 12:01 UTC (permalink / raw) To: u-boot On Tue, Nov 21, 2017 at 04:59:33PM +1100, Jonathan Gray wrote: > On Sat, Nov 18, 2017 at 03:25:29PM +1100, Jonathan Gray wrote: > > > > 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. > > 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. 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 20 efi_dp_match A 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8 28 f3 62 8b efi_dp_match B 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8 28 f3 62 8b efi_dp_match depth 1 alen 11 blen 11 efi_dp_match A 03 0f 0b 00 00 00 00 00 09 00 00 efi_dp_match B 03 0f 0b 00 00 00 00 00 09 00 00 efi_dp_match depth 2 alen 11 blen 11 efi_dp_match A 03 0f 0b 00 24 04 14 95 09 00 02 efi_dp_match B 03 0f 0b 00 24 04 14 95 09 00 02 efi_dp_match depth 3 alen 11 blen 11 efi_dp_match A 03 0f 0b 00 81 07 81 55 00 00 00 efi_dp_match B 03 0f 0b 00 81 07 81 55 00 00 00 efi_dp_match depth 4 alen 42 blen 42 efi_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 00 efi_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 diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c index f6e368e029..8045532a29 100644 --- a/lib/efi_loader/efi_device_path.c +++ b/lib/efi_loader/efi_device_path.c @@ -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]; } ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] efi_loader: Fix disk dp's for pre-DM/legacy devices 2017-10-08 15:33 [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices Rob Clark 2017-10-09 3:33 ` Jonathan Gray @ 2017-10-09 4:43 ` Alexander Graf 1 sibling, 0 replies; 18+ messages in thread From: Alexander Graf @ 2017-10-09 4:43 UTC (permalink / raw) To: u-boot > 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 <jsg@jsg.id.au> > Signed-off-by: Rob Clark <robdclark@gmail.com> Thanks, applied to efi-next Alex ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-11-21 12:01 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-10-08 15:33 [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices Rob Clark 2017-10-09 3:33 ` Jonathan Gray 2017-10-09 10:52 ` Rob Clark 2017-10-09 12:25 ` Jonathan Gray 2017-10-09 14:17 ` Rob Clark 2017-10-09 15:35 ` Jonathan Gray 2017-10-09 16:06 ` Rob Clark 2017-10-09 16:22 ` Heinrich Schuchardt 2017-10-09 17:02 ` Rob Clark 2017-10-09 16:41 ` Jonathan Gray 2017-10-09 17:06 ` Rob Clark 2017-10-09 17:48 ` Jonathan Gray 2017-10-09 18:20 ` Rob Clark 2017-10-09 18:36 ` Peter Robinson 2017-11-18 4:25 ` Jonathan Gray 2017-11-21 5:59 ` Jonathan Gray 2017-11-21 12:01 ` Jonathan Gray 2017-10-09 4:43 ` [U-Boot] " Alexander Graf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox