Re: EFI from usb HDD
On 8/19/21 6:14 AM, AKASHI Takahiro wrote: > On Wed, Aug 18, 2021 at 11:07:09AM +0200, Michal Simek wrote: >> >> >> On 8/18/21 7:13 AM, AKASHI Takahiro wrote: >>> On Tue, Aug 17, 2021 at 09:20:31AM +0200, Michal Simek wrote: On 8/12/21 11:43 AM, AKASHI Takahiro wrote: > On Fri, Jul 30, 2021 at 08:22:18AM +0200, Michal Simek wrote: >> >> >> On 7/30/21 7:33 AM, AKASHI Takahiro wrote: >>> On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: >> Hi, >> >> On 6/10/21 2:59 PM, AKASHI Takahiro wrote: >>> On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > On 6/10/21 12:04 PM, Michal Simek wrote: >> Hi, >> >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: >>> On 6/10/21 10:44 AM, Michal Simek wrote: Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) >>> >>> Hello Michal, >>> >>> thanks for sharing your observations. >>> >>> What devices do hd0 and hd1 relate to? >>> On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >>> >>> GPT and MBR partitioning are independent of the device type. >>> On zcu104 I see one more error message "PE image measurement failed" >>> >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a >>> TPMv2? This >>> will not stop disk enumeration. >>> But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0800 0x001007fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal >>> >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, >>> it could >>> be that the USB sub-system is simply not
Re: EFI from usb HDD
On Wed, Aug 18, 2021 at 11:07:09AM +0200, Michal Simek wrote: > > > On 8/18/21 7:13 AM, AKASHI Takahiro wrote: > > On Tue, Aug 17, 2021 at 09:20:31AM +0200, Michal Simek wrote: > >> > >> > >> On 8/12/21 11:43 AM, AKASHI Takahiro wrote: > >>> On Fri, Jul 30, 2021 at 08:22:18AM +0200, Michal Simek wrote: > > > On 7/30/21 7:33 AM, AKASHI Takahiro wrote: > > On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: > >> > >> > >> On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > >>> On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: > Hi, > > On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: > >> > >> > >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > >>> On 6/10/21 12:04 PM, Michal Simek wrote: > Hi, > > On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > > On 6/10/21 10:44 AM, Michal Simek wrote: > >> Hi, > >> > >> I am playing with booting from USB via EFI. And I see very > >> weird > >> behavior. I have burnt image with grub to USB flashdisk and I > >> have > >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria > >> board. > >> On zcu102 grub is going to boot menu and everything is working > >> fine as > >> expected. > >> On zcu104 and SOM Kria I am able to get grub not to menu. When > >> I list > >> partitions in grub I see that only SDs are listed: > >> grub> ls > >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > > > Hello Michal, > > > > thanks for sharing your observations. > > > > What devices do hd0 and hd1 relate to? > > > >> > >> On zcu102(working board) I also see usb(gpt) partitions and SD. > >> grub> ls > >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) > >> > > > > GPT and MBR partitioning are independent of the device type. > > > >> > >> On zcu104 I see one more error message > >> "PE image measurement failed" > > > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a > > TPMv2? This > > will not stop disk enumeration. > > > >> But I can't see it on SOM. > >> > >> U-Boot image is just the same for all boards. I am using > >> generic > >> xilinx_zynqmp_virt_defconfig. > >> > >> When I compare DT description for USB between zcu102 and > >> zcu104 they > >> are > >> the same. SOM doesn't have usb enabled by default (but I > >> enabled it) > >> but > >> grub starts which means that communication with USB is fine. > >> > >> It is based on my latest patches available here. > >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) > >> > >> Also when I list usb I see all partitions just fine. > >> ZynqMP> part list usb 0 > >> > >> Partition Map for USB device 0 -- Partition Type: EFI > >> > >> Part Start LBA End LBA Name > >> Attributes > >> Type GUID > >> Partition GUID > >> 1 0x0800 0x001007fe "Microsoft basic > >> data" > >> attrs: 0x > >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > >> type: data > >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > >> 2 0x00100800 0x001197fe "Microsoft basic > >> data" > >> attrs: 0x > >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > >> type: data > >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 > >> > >> > >> Do you have any idea why on one system is working fine to get > >> to menu > >> and on others there is an issue to get all partitions even > >> u-boot is > >> able to see them and can work with them. > >> > >> Thanks, > >> Michal > >> > > > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, > > it could > > be that the USB sub-system is simply not initialized yet when > > the boot >
Re: EFI from usb HDD
On 8/18/21 7:13 AM, AKASHI Takahiro wrote: > On Tue, Aug 17, 2021 at 09:20:31AM +0200, Michal Simek wrote: >> >> >> On 8/12/21 11:43 AM, AKASHI Takahiro wrote: >>> On Fri, Jul 30, 2021 at 08:22:18AM +0200, Michal Simek wrote: On 7/30/21 7:33 AM, AKASHI Takahiro wrote: > On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: >> >> >> On 7/30/21 4:35 AM, AKASHI Takahiro wrote: >>> On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: Hi, On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: >> >> >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: >>> On 6/10/21 12:04 PM, Michal Simek wrote: Hi, On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > On 6/10/21 10:44 AM, Michal Simek wrote: >> Hi, >> >> I am playing with booting from USB via EFI. And I see very weird >> behavior. I have burnt image with grub to USB flashdisk and I >> have >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. >> On zcu102 grub is going to boot menu and everything is working >> fine as >> expected. >> On zcu104 and SOM Kria I am able to get grub not to menu. When I >> list >> partitions in grub I see that only SDs are listed: >> grub> ls >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > Hello Michal, > > thanks for sharing your observations. > > What devices do hd0 and hd1 relate to? > >> >> On zcu102(working board) I also see usb(gpt) partitions and SD. >> grub> ls >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >> > > GPT and MBR partitioning are independent of the device type. > >> >> On zcu104 I see one more error message >> "PE image measurement failed" > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a > TPMv2? This > will not stop disk enumeration. > >> But I can't see it on SOM. >> >> U-Boot image is just the same for all boards. I am using generic >> xilinx_zynqmp_virt_defconfig. >> >> When I compare DT description for USB between zcu102 and zcu104 >> they >> are >> the same. SOM doesn't have usb enabled by default (but I enabled >> it) >> but >> grub starts which means that communication with USB is fine. >> >> It is based on my latest patches available here. >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) >> >> Also when I list usb I see all partitions just fine. >> ZynqMP> part list usb 0 >> >> Partition Map for USB device 0 -- Partition Type: EFI >> >> Part Start LBA End LBA Name >> Attributes >> Type GUID >> Partition GUID >> 1 0x0800 0x001007fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >> 2 0x00100800 0x001197fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 >> >> >> Do you have any idea why on one system is working fine to get to >> menu >> and on others there is an issue to get all partitions even >> u-boot is >> able to see them and can work with them. >> >> Thanks, >> Michal >> > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it > could > be that the USB sub-system is simply not initialized yet when the > boot > manager is called by distroboot. > > For testing partition detection in the UEFI sub-system it is > enough > to run > > efidebug devices > > Until yesterday we had a problem with partition numbers >= 10, cf. > > efi_loader: partition numbers ar
Re: EFI from usb HDD
On Tue, Aug 17, 2021 at 09:20:31AM +0200, Michal Simek wrote: > > > On 8/12/21 11:43 AM, AKASHI Takahiro wrote: > > On Fri, Jul 30, 2021 at 08:22:18AM +0200, Michal Simek wrote: > >> > >> > >> On 7/30/21 7:33 AM, AKASHI Takahiro wrote: > >>> On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: > > > On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > > On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: > >> Hi, > >> > >> On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > >>> On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: > > > On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > > On 6/10/21 12:04 PM, Michal Simek wrote: > >> Hi, > >> > >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > >>> On 6/10/21 10:44 AM, Michal Simek wrote: > Hi, > > I am playing with booting from USB via EFI. And I see very weird > behavior. I have burnt image with grub to USB flashdisk and I > have > tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. > On zcu102 grub is going to boot menu and everything is working > fine as > expected. > On zcu104 and SOM Kria I am able to get grub not to menu. When I > list > partitions in grub I see that only SDs are listed: > grub> ls > (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > >>> > >>> Hello Michal, > >>> > >>> thanks for sharing your observations. > >>> > >>> What devices do hd0 and hd1 relate to? > >>> > > On zcu102(working board) I also see usb(gpt) partitions and SD. > grub> ls > (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) > > >>> > >>> GPT and MBR partitioning are independent of the device type. > >>> > > On zcu104 I see one more error message > "PE image measurement failed" > >>> > >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a > >>> TPMv2? This > >>> will not stop disk enumeration. > >>> > But I can't see it on SOM. > > U-Boot image is just the same for all boards. I am using generic > xilinx_zynqmp_virt_defconfig. > > When I compare DT description for USB between zcu102 and zcu104 > they > are > the same. SOM doesn't have usb enabled by default (but I enabled > it) > but > grub starts which means that communication with USB is fine. > > It is based on my latest patches available here. > u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) > > Also when I list usb I see all partitions just fine. > ZynqMP> part list usb 0 > > Partition Map for USB device 0 -- Partition Type: EFI > > Part Start LBA End LBA Name > Attributes > Type GUID > Partition GUID > 1 0x0800 0x001007fe "Microsoft basic data" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > 2 0x00100800 0x001197fe "Microsoft basic data" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 > > > Do you have any idea why on one system is working fine to get to > menu > and on others there is an issue to get all partitions even > u-boot is > able to see them and can work with them. > > Thanks, > Michal > > >>> > >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it > >>> could > >>> be that the USB sub-system is simply not initialized yet when the > >>> boot > >>> manager is called by distroboot. > >>> > >>> For testing partition detection in the UEFI sub-system it is > >>> enough > >>> to run > >>> > >>> efidebug devices > >>> > >>> Until yesterday we had a problem with partition numbers >= 10, cf. > >>> > >>> efi_loader: partition numbers are hexadecimal > >>> https://source.denx.d
Re: EFI from usb HDD
On 8/12/21 11:43 AM, AKASHI Takahiro wrote: > On Fri, Jul 30, 2021 at 08:22:18AM +0200, Michal Simek wrote: >> >> >> On 7/30/21 7:33 AM, AKASHI Takahiro wrote: >>> On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: >> Hi, >> >> On 6/10/21 2:59 PM, AKASHI Takahiro wrote: >>> On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > On 6/10/21 12:04 PM, Michal Simek wrote: >> Hi, >> >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: >>> On 6/10/21 10:44 AM, Michal Simek wrote: Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) >>> >>> Hello Michal, >>> >>> thanks for sharing your observations. >>> >>> What devices do hd0 and hd1 relate to? >>> On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >>> >>> GPT and MBR partitioning are independent of the device type. >>> On zcu104 I see one more error message "PE image measurement failed" >>> >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? >>> This >>> will not stop disk enumeration. >>> But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0800 0x001007fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal >>> >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it >>> could >>> be that the USB sub-system is simply not initialized yet when the >>> boot >>> manager is called by distroboot. >>> >>> For testing partition detection in the UEFI sub-system it is enough >>> to run >>> >>> efidebug devices >>> >>> Until yesterday we had a problem with partition numbers >= 10, cf. >>> >>> efi_loader: partition numbers are hexadecimal >>> https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>> >>> >>> >>> Block devices are enumerated in efi_disk_register(). Please, try to >>> add >>> debug output there to elucidate the problem. >> >> I found where the problem is. First of all zcu102 didn't u
Re: EFI from usb HDD
On Fri, Jul 30, 2021 at 08:22:18AM +0200, Michal Simek wrote: > > > On 7/30/21 7:33 AM, AKASHI Takahiro wrote: > > On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: > >> > >> > >> On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > >>> On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: > Hi, > > On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: > >> > >> > >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > >>> On 6/10/21 12:04 PM, Michal Simek wrote: > Hi, > > On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > > On 6/10/21 10:44 AM, Michal Simek wrote: > >> Hi, > >> > >> I am playing with booting from USB via EFI. And I see very weird > >> behavior. I have burnt image with grub to USB flashdisk and I have > >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. > >> On zcu102 grub is going to boot menu and everything is working > >> fine as > >> expected. > >> On zcu104 and SOM Kria I am able to get grub not to menu. When I > >> list > >> partitions in grub I see that only SDs are listed: > >> grub> ls > >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > > > Hello Michal, > > > > thanks for sharing your observations. > > > > What devices do hd0 and hd1 relate to? > > > >> > >> On zcu102(working board) I also see usb(gpt) partitions and SD. > >> grub> ls > >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) > >> > > > > GPT and MBR partitioning are independent of the device type. > > > >> > >> On zcu104 I see one more error message > >> "PE image measurement failed" > > > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? > > This > > will not stop disk enumeration. > > > >> But I can't see it on SOM. > >> > >> U-Boot image is just the same for all boards. I am using generic > >> xilinx_zynqmp_virt_defconfig. > >> > >> When I compare DT description for USB between zcu102 and zcu104 > >> they > >> are > >> the same. SOM doesn't have usb enabled by default (but I enabled > >> it) > >> but > >> grub starts which means that communication with USB is fine. > >> > >> It is based on my latest patches available here. > >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) > >> > >> Also when I list usb I see all partitions just fine. > >> ZynqMP> part list usb 0 > >> > >> Partition Map for USB device 0 -- Partition Type: EFI > >> > >> Part Start LBA End LBA Name > >> Attributes > >> Type GUID > >> Partition GUID > >> 1 0x0800 0x001007fe "Microsoft basic data" > >> attrs: 0x > >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > >> type: data > >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > >> 2 0x00100800 0x001197fe "Microsoft basic data" > >> attrs: 0x > >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > >> type: data > >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 > >> > >> > >> Do you have any idea why on one system is working fine to get to > >> menu > >> and on others there is an issue to get all partitions even u-boot > >> is > >> able to see them and can work with them. > >> > >> Thanks, > >> Michal > >> > > > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it > > could > > be that the USB sub-system is simply not initialized yet when the > > boot > > manager is called by distroboot. > > > > For testing partition detection in the UEFI sub-system it is enough > > to run > > > > efidebug devices > > > > Until yesterday we had a problem with partition numbers >= 10, cf. > > > > efi_loader: partition numbers are hexadecimal > > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > > > > > > Block devices are enumerated in efi_disk_register(). Please, try to > > add > > debug output there to elucidate the problem. > > I found where the problem is. First of all zcu102 didn't use the same > image as others (it wasn't
Re: EFI from usb HDD
Hi Ilias, On 8/4/21 12:50 PM, Ilias Apalodimas wrote: > Hi Michal > Apologies for my late reply, I was on vacation! no problem at all. > > [...] > When Abort happened I connected Xilinx debugger via jtag and look at cpu backtrace. >>> >>> OK, but we are already in grub here and such a trace (in U-Boot) >>> doesn't make sense. Right? >> >> Correct grub already started. But I expect it is still using U-Boot >> drivers and all exception handlers are still in place from u-boot. > > Yes, U-Boot is still alive and GRUB is accessing some of the > functionality via Boottime services. > >> >> Maybe it is just sata/scsi related issue in EFI but weird is that when >> disks are scan just before command everything is working fine. >> >> Should I try to initialize and populate EFI object list all the time? >> (Remove this code for testing) >> /* Initialize once only */ >> if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) >> return efi_obj_list_initialized; >> >> Or based on this thread to try your series pointed above? > > This smells like a different init sequence when a command is issued first. > I'll try having a closer look. Let me know if you find anything else Did you have a time to look at it? Thanks, Michal
Re: EFI from usb HDD
Hi Michal Apologies for my late reply, I was on vacation! [...] > >> > >> When Abort happened I connected Xilinx debugger via jtag and look at cpu > >> backtrace. > > > > OK, but we are already in grub here and such a trace (in U-Boot) > > doesn't make sense. Right? > > Correct grub already started. But I expect it is still using U-Boot > drivers and all exception handlers are still in place from u-boot. Yes, U-Boot is still alive and GRUB is accessing some of the functionality via Boottime services. > > Maybe it is just sata/scsi related issue in EFI but weird is that when > disks are scan just before command everything is working fine. > > Should I try to initialize and populate EFI object list all the time? > (Remove this code for testing) > /* Initialize once only */ > if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) > return efi_obj_list_initialized; > > Or based on this thread to try your series pointed above? This smells like a different init sequence when a command is issued first. I'll try having a closer look. Let me know if you find anything else Cheers /Ilias > > Thanks, > Michal >
Re: EFI from usb HDD
On 7/30/21 7:33 AM, AKASHI Takahiro wrote: > On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: >> >> >> On 7/30/21 4:35 AM, AKASHI Takahiro wrote: >>> On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: Hi, On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: >> >> >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: >>> On 6/10/21 12:04 PM, Michal Simek wrote: Hi, On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > On 6/10/21 10:44 AM, Michal Simek wrote: >> Hi, >> >> I am playing with booting from USB via EFI. And I see very weird >> behavior. I have burnt image with grub to USB flashdisk and I have >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. >> On zcu102 grub is going to boot menu and everything is working fine >> as >> expected. >> On zcu104 and SOM Kria I am able to get grub not to menu. When I list >> partitions in grub I see that only SDs are listed: >> grub> ls >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > Hello Michal, > > thanks for sharing your observations. > > What devices do hd0 and hd1 relate to? > >> >> On zcu102(working board) I also see usb(gpt) partitions and SD. >> grub> ls >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >> > > GPT and MBR partitioning are independent of the device type. > >> >> On zcu104 I see one more error message >> "PE image measurement failed" > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? > This > will not stop disk enumeration. > >> But I can't see it on SOM. >> >> U-Boot image is just the same for all boards. I am using generic >> xilinx_zynqmp_virt_defconfig. >> >> When I compare DT description for USB between zcu102 and zcu104 they >> are >> the same. SOM doesn't have usb enabled by default (but I enabled it) >> but >> grub starts which means that communication with USB is fine. >> >> It is based on my latest patches available here. >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) >> >> Also when I list usb I see all partitions just fine. >> ZynqMP> part list usb 0 >> >> Partition Map for USB device 0 -- Partition Type: EFI >> >> Part Start LBA End LBA Name >> Attributes >> Type GUID >> Partition GUID >> 1 0x0800 0x001007fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >> 2 0x00100800 0x001197fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 >> >> >> Do you have any idea why on one system is working fine to get to menu >> and on others there is an issue to get all partitions even u-boot is >> able to see them and can work with them. >> >> Thanks, >> Michal >> > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it > could > be that the USB sub-system is simply not initialized yet when the boot > manager is called by distroboot. > > For testing partition detection in the UEFI sub-system it is enough > to run > > efidebug devices > > Until yesterday we had a problem with partition numbers >= 10, cf. > > efi_loader: partition numbers are hexadecimal > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > > Block devices are enumerated in efi_disk_register(). Please, try to > add > debug output there to elucidate the problem. I found where the problem is. First of all zcu102 didn't use the same image as others (it wasn't updated properly). When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() is called before usb block devices are detected and registered that's why grub doesn't see them. >>> >>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>> >>> Why is USB initialized later then MMC? >>
Re: EFI from usb HDD
On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: > > > On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > > On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: > >> Hi, > >> > >> On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > >>> On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: > > > On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > > On 6/10/21 12:04 PM, Michal Simek wrote: > >> Hi, > >> > >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > >>> On 6/10/21 10:44 AM, Michal Simek wrote: > Hi, > > I am playing with booting from USB via EFI. And I see very weird > behavior. I have burnt image with grub to USB flashdisk and I have > tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. > On zcu102 grub is going to boot menu and everything is working fine > as > expected. > On zcu104 and SOM Kria I am able to get grub not to menu. When I list > partitions in grub I see that only SDs are listed: > grub> ls > (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > >>> > >>> Hello Michal, > >>> > >>> thanks for sharing your observations. > >>> > >>> What devices do hd0 and hd1 relate to? > >>> > > On zcu102(working board) I also see usb(gpt) partitions and SD. > grub> ls > (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) > > >>> > >>> GPT and MBR partitioning are independent of the device type. > >>> > > On zcu104 I see one more error message > "PE image measurement failed" > >>> > >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? > >>> This > >>> will not stop disk enumeration. > >>> > But I can't see it on SOM. > > U-Boot image is just the same for all boards. I am using generic > xilinx_zynqmp_virt_defconfig. > > When I compare DT description for USB between zcu102 and zcu104 they > are > the same. SOM doesn't have usb enabled by default (but I enabled it) > but > grub starts which means that communication with USB is fine. > > It is based on my latest patches available here. > u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) > > Also when I list usb I see all partitions just fine. > ZynqMP> part list usb 0 > > Partition Map for USB device 0 -- Partition Type: EFI > > Part Start LBA End LBA Name > Attributes > Type GUID > Partition GUID > 1 0x0800 0x001007fe "Microsoft basic data" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > 2 0x00100800 0x001197fe "Microsoft basic data" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 > > > Do you have any idea why on one system is working fine to get to menu > and on others there is an issue to get all partitions even u-boot is > able to see them and can work with them. > > Thanks, > Michal > > >>> > >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it > >>> could > >>> be that the USB sub-system is simply not initialized yet when the boot > >>> manager is called by distroboot. > >>> > >>> For testing partition detection in the UEFI sub-system it is enough > >>> to run > >>> > >>> efidebug devices > >>> > >>> Until yesterday we had a problem with partition numbers >= 10, cf. > >>> > >>> efi_loader: partition numbers are hexadecimal > >>> https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>> > >>> > >>> > >>> Block devices are enumerated in efi_disk_register(). Please, try to > >>> add > >>> debug output there to elucidate the problem. > >> > >> I found where the problem is. First of all zcu102 didn't use the same > >> image as others (it wasn't updated properly). > >> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >> is called before usb block devices are detected and registered that's > >> why grub doesn't see them. > > > > The problem is CONFIG_EFI_SETUP_EARLY=y required by > > CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > > > > Why is USB initialized later then MMC? > > It is not just usb. SCSI/sata are behavin
Re: EFI from usb HDD
On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: >> Hi, >> >> On 6/10/21 2:59 PM, AKASHI Takahiro wrote: >>> On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > On 6/10/21 12:04 PM, Michal Simek wrote: >> Hi, >> >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: >>> On 6/10/21 10:44 AM, Michal Simek wrote: Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) >>> >>> Hello Michal, >>> >>> thanks for sharing your observations. >>> >>> What devices do hd0 and hd1 relate to? >>> On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >>> >>> GPT and MBR partitioning are independent of the device type. >>> On zcu104 I see one more error message "PE image measurement failed" >>> >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This >>> will not stop disk enumeration. >>> But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0800 0x001007fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal >>> >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could >>> be that the USB sub-system is simply not initialized yet when the boot >>> manager is called by distroboot. >>> >>> For testing partition detection in the UEFI sub-system it is enough >>> to run >>> >>> efidebug devices >>> >>> Until yesterday we had a problem with partition numbers >= 10, cf. >>> >>> efi_loader: partition numbers are hexadecimal >>> https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>> >>> >>> >>> Block devices are enumerated in efi_disk_register(). Please, try to add >>> debug output there to elucidate the problem. >> >> I found where the problem is. First of all zcu102 didn't use the same >> image as others (it wasn't updated properly). >> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >> is called before usb block devices are detected and registered that's >> why grub doesn't see them. > > The problem is CONFIG_EFI_SETUP_EARLY=y required by > CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > > Why is USB initialized later then MMC? It is not just usb. SCSI/sata are behaving in the same way too. > > Overall we have a deficiency in the UEFI implementation in that we > cannot deal with block devices added or removed after initialization. > > Here integration with the driver model is missing. Right. And also there are commands which can create MBR partitions and I expect when you wr
Re: EFI from usb HDD
On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: > Hi, > > On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: > >> > >> > >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > >>> On 6/10/21 12:04 PM, Michal Simek wrote: > Hi, > > On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > > On 6/10/21 10:44 AM, Michal Simek wrote: > >> Hi, > >> > >> I am playing with booting from USB via EFI. And I see very weird > >> behavior. I have burnt image with grub to USB flashdisk and I have > >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. > >> On zcu102 grub is going to boot menu and everything is working fine as > >> expected. > >> On zcu104 and SOM Kria I am able to get grub not to menu. When I list > >> partitions in grub I see that only SDs are listed: > >> grub> ls > >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > > > Hello Michal, > > > > thanks for sharing your observations. > > > > What devices do hd0 and hd1 relate to? > > > >> > >> On zcu102(working board) I also see usb(gpt) partitions and SD. > >> grub> ls > >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) > >> > > > > GPT and MBR partitioning are independent of the device type. > > > >> > >> On zcu104 I see one more error message > >> "PE image measurement failed" > > > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This > > will not stop disk enumeration. > > > >> But I can't see it on SOM. > >> > >> U-Boot image is just the same for all boards. I am using generic > >> xilinx_zynqmp_virt_defconfig. > >> > >> When I compare DT description for USB between zcu102 and zcu104 they > >> are > >> the same. SOM doesn't have usb enabled by default (but I enabled it) > >> but > >> grub starts which means that communication with USB is fine. > >> > >> It is based on my latest patches available here. > >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) > >> > >> Also when I list usb I see all partitions just fine. > >> ZynqMP> part list usb 0 > >> > >> Partition Map for USB device 0 -- Partition Type: EFI > >> > >> Part Start LBA End LBA Name > >> Attributes > >> Type GUID > >> Partition GUID > >> 1 0x0800 0x001007fe "Microsoft basic data" > >> attrs: 0x > >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > >> type: data > >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > >> 2 0x00100800 0x001197fe "Microsoft basic data" > >> attrs: 0x > >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > >> type: data > >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 > >> > >> > >> Do you have any idea why on one system is working fine to get to menu > >> and on others there is an issue to get all partitions even u-boot is > >> able to see them and can work with them. > >> > >> Thanks, > >> Michal > >> > > > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could > > be that the USB sub-system is simply not initialized yet when the boot > > manager is called by distroboot. > > > > For testing partition detection in the UEFI sub-system it is enough > > to run > > > > efidebug devices > > > > Until yesterday we had a problem with partition numbers >= 10, cf. > > > > efi_loader: partition numbers are hexadecimal > > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > > > > > > Block devices are enumerated in efi_disk_register(). Please, try to add > > debug output there to elucidate the problem. > > I found where the problem is. First of all zcu102 didn't use the same > image as others (it wasn't updated properly). > When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > is called before usb block devices are detected and registered that's > why grub doesn't see them. > >>> > >>> The problem is CONFIG_EFI_SETUP_EARLY=y required by > >>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > >>> > >>> Why is USB initialized later then MMC? > >> > >> It is not just usb. SCSI/sata are behaving in the same way too. > >> > >>> > >>> Overall we have a deficiency in the UEFI implementation in that we > >>> cannot deal with block devices added or removed after initialization. > >>> > >>> Here integration with the driver model is missing. > >> > >> Right. And also there are commands which can create MBR partitions and I > >> expect when you write image to SD and then run rescan or so you coul
Re: EFI from usb HDD
Hi, On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: >> >> >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: >>> On 6/10/21 12:04 PM, Michal Simek wrote: Hi, On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > On 6/10/21 10:44 AM, Michal Simek wrote: >> Hi, >> >> I am playing with booting from USB via EFI. And I see very weird >> behavior. I have burnt image with grub to USB flashdisk and I have >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. >> On zcu102 grub is going to boot menu and everything is working fine as >> expected. >> On zcu104 and SOM Kria I am able to get grub not to menu. When I list >> partitions in grub I see that only SDs are listed: >> grub> ls >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > Hello Michal, > > thanks for sharing your observations. > > What devices do hd0 and hd1 relate to? > >> >> On zcu102(working board) I also see usb(gpt) partitions and SD. >> grub> ls >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >> > > GPT and MBR partitioning are independent of the device type. > >> >> On zcu104 I see one more error message >> "PE image measurement failed" > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This > will not stop disk enumeration. > >> But I can't see it on SOM. >> >> U-Boot image is just the same for all boards. I am using generic >> xilinx_zynqmp_virt_defconfig. >> >> When I compare DT description for USB between zcu102 and zcu104 they >> are >> the same. SOM doesn't have usb enabled by default (but I enabled it) >> but >> grub starts which means that communication with USB is fine. >> >> It is based on my latest patches available here. >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) >> >> Also when I list usb I see all partitions just fine. >> ZynqMP> part list usb 0 >> >> Partition Map for USB device 0 -- Partition Type: EFI >> >> Part Start LBA End LBA Name >> Attributes >> Type GUID >> Partition GUID >> 1 0x0800 0x001007fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >> 2 0x00100800 0x001197fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 >> >> >> Do you have any idea why on one system is working fine to get to menu >> and on others there is an issue to get all partitions even u-boot is >> able to see them and can work with them. >> >> Thanks, >> Michal >> > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could > be that the USB sub-system is simply not initialized yet when the boot > manager is called by distroboot. > > For testing partition detection in the UEFI sub-system it is enough > to run > > efidebug devices > > Until yesterday we had a problem with partition numbers >= 10, cf. > > efi_loader: partition numbers are hexadecimal > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > > Block devices are enumerated in efi_disk_register(). Please, try to add > debug output there to elucidate the problem. I found where the problem is. First of all zcu102 didn't use the same image as others (it wasn't updated properly). When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() is called before usb block devices are detected and registered that's why grub doesn't see them. >>> >>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>> >>> Why is USB initialized later then MMC? >> >> It is not just usb. SCSI/sata are behaving in the same way too. >> >>> >>> Overall we have a deficiency in the UEFI implementation in that we >>> cannot deal with block devices added or removed after initialization. >>> >>> Here integration with the driver model is missing. >> >> Right. And also there are commands which can create MBR partitions and I >> expect when you write image to SD and then run rescan or so you could >> get other partitions too. >> Maybe hook via part_init()? with removing efi_disk_register. > > For the record, I have proposed my ideas several times[1], [2]. > I'm, however, no longer working on this issue as I have shifted > my focus to UEFI secure boot and capsule update. > > -Takahiro Akashi > > [1] https:
Re: EFI from usb HDD
On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: > > > On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > > On 6/10/21 12:04 PM, Michal Simek wrote: > >> Hi, > >> > >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > >>> On 6/10/21 10:44 AM, Michal Simek wrote: > Hi, > > I am playing with booting from USB via EFI. And I see very weird > behavior. I have burnt image with grub to USB flashdisk and I have > tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. > On zcu102 grub is going to boot menu and everything is working fine as > expected. > On zcu104 and SOM Kria I am able to get grub not to menu. When I list > partitions in grub I see that only SDs are listed: > grub> ls > (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > >>> > >>> Hello Michal, > >>> > >>> thanks for sharing your observations. > >>> > >>> What devices do hd0 and hd1 relate to? > >>> > > On zcu102(working board) I also see usb(gpt) partitions and SD. > grub> ls > (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) > > >>> > >>> GPT and MBR partitioning are independent of the device type. > >>> > > On zcu104 I see one more error message > "PE image measurement failed" > >>> > >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This > >>> will not stop disk enumeration. > >>> > But I can't see it on SOM. > > U-Boot image is just the same for all boards. I am using generic > xilinx_zynqmp_virt_defconfig. > > When I compare DT description for USB between zcu102 and zcu104 they > are > the same. SOM doesn't have usb enabled by default (but I enabled it) > but > grub starts which means that communication with USB is fine. > > It is based on my latest patches available here. > u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) > > Also when I list usb I see all partitions just fine. > ZynqMP> part list usb 0 > > Partition Map for USB device 0 -- Partition Type: EFI > > Part Start LBA End LBA Name > Attributes > Type GUID > Partition GUID > 1 0x0800 0x001007fe "Microsoft basic data" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > 2 0x00100800 0x001197fe "Microsoft basic data" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 > > > Do you have any idea why on one system is working fine to get to menu > and on others there is an issue to get all partitions even u-boot is > able to see them and can work with them. > > Thanks, > Michal > > >>> > >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could > >>> be that the USB sub-system is simply not initialized yet when the boot > >>> manager is called by distroboot. > >>> > >>> For testing partition detection in the UEFI sub-system it is enough > >>> to run > >>> > >>> efidebug devices > >>> > >>> Until yesterday we had a problem with partition numbers >= 10, cf. > >>> > >>> efi_loader: partition numbers are hexadecimal > >>> https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>> > >>> > >>> > >>> Block devices are enumerated in efi_disk_register(). Please, try to add > >>> debug output there to elucidate the problem. > >> > >> I found where the problem is. First of all zcu102 didn't use the same > >> image as others (it wasn't updated properly). > >> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >> is called before usb block devices are detected and registered that's > >> why grub doesn't see them. > > > > The problem is CONFIG_EFI_SETUP_EARLY=y required by > > CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > > > > Why is USB initialized later then MMC? > > It is not just usb. SCSI/sata are behaving in the same way too. > > > > > Overall we have a deficiency in the UEFI implementation in that we > > cannot deal with block devices added or removed after initialization. > > > > Here integration with the driver model is missing. > > Right. And also there are commands which can create MBR partitions and I > expect when you write image to SD and then run rescan or so you could > get other partitions too. > Maybe hook via part_init()? with removing efi_disk_register. For the record, I have proposed my ideas several times[1], [2]. I'm, however, no longer working on this issue as I have shifted my focus to UEFI secure boot and capsule update. -Takahiro Akashi [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html [2] https
Re: EFI from usb HDD
On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > On 6/10/21 12:04 PM, Michal Simek wrote: >> Hi, >> >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: >>> On 6/10/21 10:44 AM, Michal Simek wrote: Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) >>> >>> Hello Michal, >>> >>> thanks for sharing your observations. >>> >>> What devices do hd0 and hd1 relate to? >>> On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >>> >>> GPT and MBR partitioning are independent of the device type. >>> On zcu104 I see one more error message "PE image measurement failed" >>> >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This >>> will not stop disk enumeration. >>> But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0800 0x001007fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal >>> >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could >>> be that the USB sub-system is simply not initialized yet when the boot >>> manager is called by distroboot. >>> >>> For testing partition detection in the UEFI sub-system it is enough >>> to run >>> >>> efidebug devices >>> >>> Until yesterday we had a problem with partition numbers >= 10, cf. >>> >>> efi_loader: partition numbers are hexadecimal >>> https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>> >>> >>> >>> Block devices are enumerated in efi_disk_register(). Please, try to add >>> debug output there to elucidate the problem. >> >> I found where the problem is. First of all zcu102 didn't use the same >> image as others (it wasn't updated properly). >> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >> is called before usb block devices are detected and registered that's >> why grub doesn't see them. > > The problem is CONFIG_EFI_SETUP_EARLY=y required by > CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > > Why is USB initialized later then MMC? It is not just usb. SCSI/sata are behaving in the same way too. > > Overall we have a deficiency in the UEFI implementation in that we > cannot deal with block devices added or removed after initialization. > > Here integration with the driver model is missing. Right. And also there are commands which can create MBR partitions and I expect when you write image to SD and then run rescan or so you could get other partitions too. Maybe hook via part_init()? with removing efi_disk_register. > >> I was looking at adding usb start in preboot but preboot is called later. >> How this should be solved? Any idea? >> >> Thanks, >> Michal >> >> > +cc Sughosh, Takahiro (who have developed the capsule code) Thanks, Michal
Re: EFI from usb HDD
On 6/10/21 12:04 PM, Michal Simek wrote: Hi, On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: On 6/10/21 10:44 AM, Michal Simek wrote: Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) Hello Michal, thanks for sharing your observations. What devices do hd0 and hd1 relate to? On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) GPT and MBR partitioning are independent of the device type. On zcu104 I see one more error message "PE image measurement failed" This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This will not stop disk enumeration. But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0800 0x001007fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could be that the USB sub-system is simply not initialized yet when the boot manager is called by distroboot. For testing partition detection in the UEFI sub-system it is enough to run efidebug devices Until yesterday we had a problem with partition numbers >= 10, cf. efi_loader: partition numbers are hexadecimal https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f Block devices are enumerated in efi_disk_register(). Please, try to add debug output there to elucidate the problem. I found where the problem is. First of all zcu102 didn't use the same image as others (it wasn't updated properly). When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() is called before usb block devices are detected and registered that's why grub doesn't see them. The problem is CONFIG_EFI_SETUP_EARLY=y required by CONFIG_EFI_CAPSULE_ON_DISK_EARLY. Why is USB initialized later then MMC? Overall we have a deficiency in the UEFI implementation in that we cannot deal with block devices added or removed after initialization. Here integration with the driver model is missing. I was looking at adding usb start in preboot but preboot is called later. How this should be solved? Any idea? Thanks, Michal +cc Sughosh, Takahiro (who have developed the capsule code) Best regards Heinrich
Re: EFI from usb HDD
Hi, On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > On 6/10/21 10:44 AM, Michal Simek wrote: >> Hi, >> >> I am playing with booting from USB via EFI. And I see very weird >> behavior. I have burnt image with grub to USB flashdisk and I have >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. >> On zcu102 grub is going to boot menu and everything is working fine as >> expected. >> On zcu104 and SOM Kria I am able to get grub not to menu. When I list >> partitions in grub I see that only SDs are listed: >> grub> ls >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > Hello Michal, > > thanks for sharing your observations. > > What devices do hd0 and hd1 relate to? > >> >> On zcu102(working board) I also see usb(gpt) partitions and SD. >> grub> ls >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >> > > GPT and MBR partitioning are independent of the device type. > >> >> On zcu104 I see one more error message >> "PE image measurement failed" > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This > will not stop disk enumeration. > >> But I can't see it on SOM. >> >> U-Boot image is just the same for all boards. I am using generic >> xilinx_zynqmp_virt_defconfig. >> >> When I compare DT description for USB between zcu102 and zcu104 they are >> the same. SOM doesn't have usb enabled by default (but I enabled it) but >> grub starts which means that communication with USB is fine. >> >> It is based on my latest patches available here. >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) >> >> Also when I list usb I see all partitions just fine. >> ZynqMP> part list usb 0 >> >> Partition Map for USB device 0 -- Partition Type: EFI >> >> Part Start LBA End LBA Name >> Attributes >> Type GUID >> Partition GUID >> 1 0x0800 0x001007fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >> 2 0x00100800 0x001197fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 >> >> >> Do you have any idea why on one system is working fine to get to menu >> and on others there is an issue to get all partitions even u-boot is >> able to see them and can work with them. >> >> Thanks, >> Michal >> > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could > be that the USB sub-system is simply not initialized yet when the boot > manager is called by distroboot. > > For testing partition detection in the UEFI sub-system it is enough to run > > efidebug devices > > Until yesterday we had a problem with partition numbers >= 10, cf. > > efi_loader: partition numbers are hexadecimal > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > Block devices are enumerated in efi_disk_register(). Please, try to add > debug output there to elucidate the problem. I found where the problem is. First of all zcu102 didn't use the same image as others (it wasn't updated properly). When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() is called before usb block devices are detected and registered that's why grub doesn't see them. I was looking at adding usb start in preboot but preboot is called later. How this should be solved? Any idea? Thanks, Michal
Re: EFI from usb HDD
On 6/10/21 10:44 AM, Michal Simek wrote: Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) Hello Michal, thanks for sharing your observations. What devices do hd0 and hd1 relate to? On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) GPT and MBR partitioning are independent of the device type. On zcu104 I see one more error message "PE image measurement failed" This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This will not stop disk enumeration. But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI PartStart LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0800 0x001007fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could be that the USB sub-system is simply not initialized yet when the boot manager is called by distroboot. For testing partition detection in the UEFI sub-system it is enough to run efidebug devices Until yesterday we had a problem with partition numbers >= 10, cf. efi_loader: partition numbers are hexadecimal https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f Block devices are enumerated in efi_disk_register(). Please, try to add debug output there to elucidate the problem. Best regards Heinrich
EFI from usb HDD
Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) On zcu104 I see one more error message "PE image measurement failed" But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI PartStart LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0800 0x001007fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal
