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
Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000800 0x001007fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x0000000000000000 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
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 0x00000800 0x001007fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x0000000000000000 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/3dca77b1dc1b6dbf9c8b51572fe4b0...
Block devices are enumerated in efi_disk_register(). Please, try to add debug output there to elucidate the problem.
Best regards
Heinrich
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 0x00000800 0x001007fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x0000000000000000 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/3dca77b1dc1b6dbf9c8b51572fe4b0...
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
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 0x00000800 0x001007fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x0000000000000000 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/3dca77b1dc1b6dbf9c8b51572fe4b0...
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
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 0x00000800 0x001007fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x0000000000000000 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/3dca77b1dc1b6dbf9c8b51572fe4b0...
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
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 0x00000800 0x001007fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x0000000000000000 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/3dca77b1dc1b6dbf9c8b51572fe4b0...
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://lists.denx.de/pipermail/u-boot/2019-February/357923.html
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
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 0x00000800 0x001007fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x0000000000000000 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/3dca77b1dc1b6dbf9c8b51572fe4b0...
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://lists.denx.de/pipermail/u-boot/2019-February/357923.html
I want to continue on this thread. I have disabled EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that usb/scsi detection by simply calling usb reset and scsi reset as the part of PREBOOT. Then all disks are recorded and visible by grub.
But I found another issue which is kind of weird. We are using distroboot with soft of fixed sequence. Important part of sequence is sd, usb, scsi.
I have added grub on scsi and when I boot directly via run bootcmd_scsi0 everything is working fine. When I let distroboot to do the job it or run printenv -e before bootcmd_scsi0 I am getting exception.
From debug it is visible that it is exception called from
efi_disk_read_blocks.
0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S, line 141 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, line 102
Logs are below and there is different place where disks are registered. Do you have any idea what could go wrong? Or something to check?
Thanks, Michal
U-Boot 2021.10-rc1-00014-g81168a994f90 (Jul 29 2021 - 15:37:11 +0200)
Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SOFT Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000
Reset SCSI scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) resetting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> run bootcmd_scsi0 scanning bus for devices... Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 23 ms (26.8 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
GNU GRUB version 2.11
all good here.
...
U-Boot 2021.10-rc1-00014-g81168a994f90 (Jul 29 2021 - 15:37:11 +0200)
Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SOFT Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000
Reset SCSI scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) resetting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> print -e Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done SecureBoot: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 00 . SetupMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 01 . AuditMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 00 . DeployedMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 00 . VendorKeys: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 00 . PlatformLangCodes: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x6 00000000: 65 6e 2d 55 53 00 en-US. PlatformLang: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID NV|BS|RT, DataSize = 0x6 00000000: 65 6e 2d 55 53 00 en-US. OsIndicationsSupported: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x8 00000000: 1c 00 00 00 00 00 00 00 ........ SignatureSupport: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x20 00000000: 26 16 c4 c1 4c 50 92 40 ac a9 41 f9 36 93 43 28 &...LP.@..A.6.C( 00000010: a1 59 c0 a5 e4 94 a7 4a 87 b5 ab 15 5c 2b f0 72 .Y.....J....+.r OsIndications: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID NV|BS|RT, DataSize = 0x8 00000000: 00 00 00 00 00 00 00 00 ........ ZynqMP> run bootcmd_scsi0 scanning bus for devices... Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 24 ms (25.7 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
"Synchronous Abort" handler, esr 0x02000000 elr: ffffffffa816c5b0 lr : 000000000805e218 (reloc) elr: 00000000200005b0 lr : 000000007fef2218 x0 : 0000000000000020 x1 : 0000000000000000 x2 : 0000000000000040 x3 : 000000004ff49400 x4 : 00000000200005b0 x5 : 000000007be4abb0 x6 : 000000007ffa5230 x7 : 000000007ffa5230 x8 : 0000000000000006 x9 : fffffffffffffff0 x10: 0000000000000001 x11: 000000007be4abb0 x12: 0000000000000040 x13: 0000000000000200 x14: 000000007fe95208 x15: 0000000000000000 x16: 0000000077d4f8d0 x17: 0000000000000000 x18: 000000007be13da0 x19: 000000007be22340 x20: 0000000000000020 x21: 0000000000000040 x22: 0000000000000000 x23: 000000004ff49400 x24: 0000000000000000 x25: 0000000000000100 x26: 000000000000000f x27: 00000000000001ff x28: 000000007be4cb40 x29: 000000007be06ec0
Code: 000165fa 0b2d05de 0000ffff 00000000 (20000590) UEFI image [0x0000000077d48000:0x0000000077de5fff] '/efi\boot\bootaa64.efi' Resetting CPU ...
### ERROR ### Please RESET the board ###
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 0x00000800 0x001007fe "Microsoft basic data" > attrs: 0x0000000000000000 > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > 2 0x00100800 0x001197fe "Microsoft basic data" > attrs: 0x0000000000000000 > 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/3dca77b1dc1b6dbf9c8b51572fe4b0...
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://lists.denx.de/pipermail/u-boot/2019-February/357923.html
I want to continue on this thread. I have disabled EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that usb/scsi detection by simply calling usb reset and scsi reset as the part of PREBOOT. Then all disks are recorded and visible by grub.
But I found another issue which is kind of weird. We are using distroboot with soft of fixed sequence. Important part of sequence is sd, usb, scsi.
I have added grub on scsi and when I boot directly via run bootcmd_scsi0 everything is working fine. When I let distroboot to do the job it or run printenv -e before bootcmd_scsi0 I am getting exception. From debug it is visible that it is exception called from efi_disk_read_blocks.
0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S,line 141 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, line 102
How and when did you get this stack trace?
-Takahiro Akashi
Logs are below and there is different place where disks are registered. Do you have any idea what could go wrong? Or something to check?
Thanks, Michal
U-Boot 2021.10-rc1-00014-g81168a994f90 (Jul 29 2021 - 15:37:11 +0200)
Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SOFT Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000
Reset SCSI scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) resetting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> run bootcmd_scsi0 scanning bus for devices... Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 23 ms (26.8 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
GNU GRUB version 2.11all good here.
...
U-Boot 2021.10-rc1-00014-g81168a994f90 (Jul 29 2021 - 15:37:11 +0200)
Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SOFT Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000
Reset SCSI scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) resetting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> print -e Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done SecureBoot: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 00 . SetupMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 01 . AuditMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 00 . DeployedMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 00 . VendorKeys: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x1 00000000: 00 . PlatformLangCodes: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x6 00000000: 65 6e 2d 55 53 00 en-US. PlatformLang: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID NV|BS|RT, DataSize = 0x6 00000000: 65 6e 2d 55 53 00 en-US. OsIndicationsSupported: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x8 00000000: 1c 00 00 00 00 00 00 00 ........ SignatureSupport: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID BS|RT|RO, DataSize = 0x20 00000000: 26 16 c4 c1 4c 50 92 40 ac a9 41 f9 36 93 43 28 &...LP.@..A.6.C( 00000010: a1 59 c0 a5 e4 94 a7 4a 87 b5 ab 15 5c 2b f0 72 .Y.....J....+.r OsIndications: 8be4df61-93ca-11d2-aa0d-00e098032b8c EFI_GLOBAL_VARIABLE_GUID NV|BS|RT, DataSize = 0x8 00000000: 00 00 00 00 00 00 00 00 ........ ZynqMP> run bootcmd_scsi0 scanning bus for devices... Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 24 ms (25.7 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
"Synchronous Abort" handler, esr 0x02000000 elr: ffffffffa816c5b0 lr : 000000000805e218 (reloc) elr: 00000000200005b0 lr : 000000007fef2218 x0 : 0000000000000020 x1 : 0000000000000000 x2 : 0000000000000040 x3 : 000000004ff49400 x4 : 00000000200005b0 x5 : 000000007be4abb0 x6 : 000000007ffa5230 x7 : 000000007ffa5230 x8 : 0000000000000006 x9 : fffffffffffffff0 x10: 0000000000000001 x11: 000000007be4abb0 x12: 0000000000000040 x13: 0000000000000200 x14: 000000007fe95208 x15: 0000000000000000 x16: 0000000077d4f8d0 x17: 0000000000000000 x18: 000000007be13da0 x19: 000000007be22340 x20: 0000000000000020 x21: 0000000000000040 x22: 0000000000000000 x23: 000000004ff49400 x24: 0000000000000000 x25: 0000000000000100 x26: 000000000000000f x27: 00000000000001ff x28: 000000007be4cb40 x29: 000000007be06ec0
Code: 000165fa 0b2d05de 0000ffff 00000000 (20000590) UEFI image [0x0000000077d48000:0x0000000077de5fff] '/efi\boot\bootaa64.efi' Resetting CPU ...
### ERROR ### Please RESET the board ###
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 0x00000800 0x001007fe "Microsoft basic data" >> attrs: 0x0000000000000000 >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >> 2 0x00100800 0x001197fe "Microsoft basic data" >> attrs: 0x0000000000000000 >> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... > > > > 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html
I want to continue on this thread. I have disabled EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that usb/scsi detection by simply calling usb reset and scsi reset as the part of PREBOOT. Then all disks are recorded and visible by grub.
But I found another issue which is kind of weird. We are using distroboot with soft of fixed sequence. Important part of sequence is sd, usb, scsi.
I have added grub on scsi and when I boot directly via run bootcmd_scsi0 everything is working fine. When I let distroboot to do the job it or run printenv -e before bootcmd_scsi0 I am getting exception. From debug it is visible that it is exception called from efi_disk_read_blocks.
0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S,line 141 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, line 102
How and when did you get this stack trace?
When Abort happened I connected Xilinx debugger via jtag and look at cpu backtrace.
Thanks, Michal
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 0x00000800 0x001007fe "Microsoft basic data" >>> attrs: 0x0000000000000000 >>> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >>> type: data >>> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >>> 2 0x00100800 0x001197fe "Microsoft basic data" >>> attrs: 0x0000000000000000 >>> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... >> >> >> >> 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html
I want to continue on this thread. I have disabled EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that usb/scsi detection by simply calling usb reset and scsi reset as the part of PREBOOT. Then all disks are recorded and visible by grub.
But I found another issue which is kind of weird. We are using distroboot with soft of fixed sequence. Important part of sequence is sd, usb, scsi.
I have added grub on scsi and when I boot directly via run bootcmd_scsi0 everything is working fine. When I let distroboot to do the job it or run printenv -e before bootcmd_scsi0 I am getting exception. From debug it is visible that it is exception called from efi_disk_read_blocks.
0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S,line 141 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, line 102
How and when did you get this stack trace?
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?
-Takahiro Akashi
Thanks, Michal
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 0x00000800 0x001007fe "Microsoft basic data" >>>> attrs: 0x0000000000000000 >>>> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >>>> type: data >>>> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >>>> 2 0x00100800 0x001197fe "Microsoft basic data" >>>> attrs: 0x0000000000000000 >>>> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... >>> >>> >>> >>> 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html
I want to continue on this thread. I have disabled EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that usb/scsi detection by simply calling usb reset and scsi reset as the part of PREBOOT. Then all disks are recorded and visible by grub.
But I found another issue which is kind of weird. We are using distroboot with soft of fixed sequence. Important part of sequence is sd, usb, scsi.
I have added grub on scsi and when I boot directly via run bootcmd_scsi0 everything is working fine. When I let distroboot to do the job it or run printenv -e before bootcmd_scsi0 I am getting exception. From debug it is visible that it is exception called from efi_disk_read_blocks.
0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S,line 141 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, line 102
How and when did you get this stack trace?
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.
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?
Thanks, Michal
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
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
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 0x00000800 0x001007fe "Microsoft basic data" >>>>> attrs: 0x0000000000000000 >>>>> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >>>>> type: data >>>>> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >>>>> 2 0x00100800 0x001197fe "Microsoft basic data" >>>>> attrs: 0x0000000000000000 >>>>> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... >>>> >>>> >>>> >>>> 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html
I want to continue on this thread. I have disabled EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that usb/scsi detection by simply calling usb reset and scsi reset as the part of PREBOOT. Then all disks are recorded and visible by grub.
But I found another issue which is kind of weird. We are using distroboot with soft of fixed sequence. Important part of sequence is sd, usb, scsi.
I have added grub on scsi and when I boot directly via run bootcmd_scsi0 everything is working fine. When I let distroboot to do the job it or run printenv -e before bootcmd_scsi0 I am getting exception. From debug it is visible that it is exception called from efi_disk_read_blocks.
0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S,line 141 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, line 102
How and when did you get this stack trace?
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.
Yeah, but what I didn't understand was:
!"Synchronous Abort" handler, esr 0x02000000 !elr: ffffffffa816c5b0 lr : 000000000805e218 (reloc) !elr: 00000000200005b0 lr : 000000007fef2218 (snip) !Code: 000165fa 0b2d05de 0000ffff 00000000 (20000590) !UEFI image [0x0000000077d48000:0x0000000077de5fff] '/efi\boot\bootaa64.efi'
"Code:" at the exception doesn't seem to be sane assembler, and "elr" is not within the code of neither U-Boot nor shim/grub(bootaa64.efi). ("esr" doesn't tell us anything.) So I wondered where the backtrace came from.
BTW, can you please confirm which function sits at the address of "lr" (=0x7fe2218)?
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.
What do you mean by "when disks are scanned just before the command"? The case when you ran "run bootcmd_scsi" without "printenv -e"?
Do you reproduce the problem even if you revert the patch, "xilinx: zynqmp: Initialize usb and scsi via preboot", and run the commands, "run scsi_init; [printenv -e;] run bootcmd_scsi?
Can you also try other EFI commands, like "efidebug devices"?
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;
No. EFI subsystem is not implemented in that way. efi_obj_list_initialized() should be called only once, and it will be called at the first invocation of any EFI-related commands, bootefi or printenv -e (or efidebug).
-Takahiro Akashi
Or based on this thread to try your series pointed above?
Thanks, Michal
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 0x00000800 0x001007fe "Microsoft basic data" >>>>>> attrs: 0x0000000000000000 >>>>>> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >>>>>> type: data >>>>>> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >>>>>> 2 0x00100800 0x001197fe "Microsoft basic data" >>>>>> attrs: 0x0000000000000000 >>>>>> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... >>>>> >>>>> >>>>> >>>>> 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html
I want to continue on this thread. I have disabled EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that usb/scsi detection by simply calling usb reset and scsi reset as the part of PREBOOT. Then all disks are recorded and visible by grub.
But I found another issue which is kind of weird. We are using distroboot with soft of fixed sequence. Important part of sequence is sd, usb, scsi.
I have added grub on scsi and when I boot directly via run bootcmd_scsi0 everything is working fine. When I let distroboot to do the job it or run printenv -e before bootcmd_scsi0 I am getting exception. From debug it is visible that it is exception called from efi_disk_read_blocks.
0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S,line 141 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, line 102
How and when did you get this stack trace?
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.
Yeah, but what I didn't understand was:
!"Synchronous Abort" handler, esr 0x02000000 !elr: ffffffffa816c5b0 lr : 000000000805e218 (reloc) !elr: 00000000200005b0 lr : 000000007fef2218 (snip) !Code: 000165fa 0b2d05de 0000ffff 00000000 (20000590) !UEFI image [0x0000000077d48000:0x0000000077de5fff] '/efi\boot\bootaa64.efi'
"Code:" at the exception doesn't seem to be sane assembler, and "elr" is not within the code of neither U-Boot nor shim/grub(bootaa64.efi). ("esr" doesn't tell us anything.) So I wondered where the backtrace came from.
BTW, can you please confirm which function sits at the address of "lr" (=0x7fe2218)?
I don't have that images anymore.
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.
What do you mean by "when disks are scanned just before the command"? The case when you ran "run bootcmd_scsi" without "printenv -e"?
Do you reproduce the problem even if you revert the patch, "xilinx: zynqmp: Initialize usb and scsi via preboot", and run the commands, "run scsi_init; [printenv -e;] run bootcmd_scsi?
Can you also try other EFI commands, like "efidebug devices"?
I found that there is a difference if you run scsi reset or run scsi_init. When scsi_init is used I can't see any issue.
Variable looks like this scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
And when you run scsi scan (last log) you see that problem again. It means when scsi reset/scan is called twice issue is observed. In all cases efidebug devices are showing disk properly.
Thanks, Michal
U-Boot SPL 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200) PMUFW: v1.1 Loading new PMUFW cfg obj (2024 bytes) Silicon version: 3 EL Level: EL3 Chip ID: zu9eg Multiboot: 0 Trying to boot from MMC2 spl: could not initialize mmc. error: -19 Trying to boot from MMC1 spl_load_image_fat_os: error reading image u-boot.bin, err - -2 NOTICE: BL31: Secure code at 0x7e000000 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v2.4(release):v2.4-592-gb5a757e853be NOTICE: BL31: Built : 07:08:43, Aug 12 2021
U-Boot 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200)
CPU: ZynqMP Silicon: v3 Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SRST Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000 starting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> scsi reset
Reset SCSI scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP> efidebug devices Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done Device Device Path ================ ==================== 000000007be20810 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007be25800 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0) 000000007be259d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x2000,0x1cd2000) 000000007be25e30 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007be350d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,GPT,85b731b6-a4b2-47f4-b1c6-aef6e0f2ce81,0x800,0xfffff) 000000007be35520 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,GPT,ac600dc7-3160-4f3c-a824-496d00e3d007,0x100800,0x18fff) 000000007be26210 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(000a350370f6,1) ZynqMP> boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image JTAG: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command JTAG: SCRIPT FAILED: continuing... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image MMC Device 1 not found no mmc device at slot 1 SF: Detected n25q512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB device 0 offset 0x3e80000, size 0x80000 SF: 524288 bytes @ 0x3e80000 Read: OK QSPI: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command QSPI: SCRIPT FAILED: continuing...
no devices available NAND: SCRIPT FAILED: continuing...
Device 0: unknown device
Device 1: unknown device scanning bus for devices... Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 15 ms (41.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
"Synchronous Abort" handler, esr 0x02000000 elr: ffffffffa816d690 lr : 000000000805f08c (reloc) elr: 0000000020000690 lr : 000000007fef208c x0 : 0000000000000020 x1 : 0000000000000000 x2 : 00000000000003e0 x3 : 0000000077c88400 x4 : 0000000020000690 x5 : 000000007be178f0 x6 : 000000007ffa5038 x7 : 000000007ffa5038 x8 : 0000000000000006 x9 : fffffffffffffff0 x10: 000000007473696c x11: 000000007be178f0 x12: 00000000000003e0 x13: 0000000000000200 x14: 000000007fe94208 x15: 0000000000000000 x16: 000000007fecdcbc x17: 0000000000000000 x18: 000000007be12da0 x19: 000000007be253e0 x20: 0000000000000020 x21: 00000000000003e0 x22: 0000000000000000 x23: 0000000077c88400 x24: 0000000000000000 x25: 0000000000000100 x26: 000000000000000f x27: 00000000000001ff x28: 000000007be4bed0 x29: 000000007be04920
Code: ffffffff ffffffff ffffffff ffffffff (ffffffff) UEFI image [0x0000000077d46000:0x0000000077de3fff] '/efi\boot\bootaa64.efi' Resetting CPU ...
### ERROR ### Please RESET the board ###
U-Boot SPL 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200) PMUFW: v1.1 Loading new PMUFW cfg obj (2024 bytes) Silicon version: 3 EL Level: EL3 Chip ID: zu9eg Multiboot: 0 Trying to boot from MMC2 spl: could not initialize mmc. error: -19 Trying to boot from MMC1 spl_load_image_fat_os: error reading image u-boot.bin, err - -2 NOTICE: BL31: Secure code at 0x7e000000 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v2.4(release):v2.4-592-gb5a757e853be NOTICE: BL31: Built : 07:08:43, Aug 12 2021
U-Boot 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200)
CPU: ZynqMP Silicon: v3 Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SRST Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000 starting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> run scsi_init scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP> efidebug devices Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done Device Device Path ================ ==================== 000000007be20790 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007be257e0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0) 000000007be259b0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x2000,0x1cd2000) 000000007be25e10 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007be350d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,GPT,85b731b6-a4b2-47f4-b1c6-aef6e0f2ce81,0x800,0xfffff) 000000007be354f0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,GPT,ac600dc7-3160-4f3c-a824-496d00e3d007,0x100800,0x18fff) 000000007be261f0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(000a350370f6,1) ZynqMP> boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image JTAG: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command JTAG: SCRIPT FAILED: continuing... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image MMC Device 1 not found no mmc device at slot 1 SF: Detected n25q512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB device 0 offset 0x3e80000, size 0x80000 SF: 524288 bytes @ 0x3e80000 Read: OK QSPI: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command QSPI: SCRIPT FAILED: continuing...
no devices available NAND: SCRIPT FAILED: continuing...
Device 0: unknown device
Device 1: unknown device
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 15 ms (41.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
GNU GRUB version 2.11
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │*Linux BusyBox │
U-Boot SPL 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200) PMUFW: v1.1 Loading new PMUFW cfg obj (2024 bytes) Silicon version: 3 EL Level: EL3 Chip ID: zu9eg Multiboot: 0 Trying to boot from MMC2 spl: could not initialize mmc. error: -19 Trying to boot from MMC1 spl_load_image_fat_os: error reading image u-boot.bin, err - -2 NOTICE: BL31: Secure code at 0x7e000000 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v2.4(release):v2.4-592-gb5a757e853be NOTICE: BL31: Built : 07:08:43, Aug 12 2021
U-Boot 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200)
CPU: ZynqMP Silicon: v3 Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SRST Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000 starting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> scsi scan scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP> efidebug devices Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done Device Device Path ================ ==================== 000000007be20810 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007be25800 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0) 000000007be259d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x2000,0x1cd2000) 000000007be25e30 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007be350d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,GPT,85b731b6-a4b2-47f4-b1c6-aef6e0f2ce81,0x800,0xfffff) 000000007be35520 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,GPT,ac600dc7-3160-4f3c-a824-496d00e3d007,0x100800,0x18fff) 000000007be26210 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(000a350370f6,1) ZynqMP> boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image JTAG: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command JTAG: SCRIPT FAILED: continuing... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image MMC Device 1 not found no mmc device at slot 1 SF: Detected n25q512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB device 0 offset 0x3e80000, size 0x80000 SF: 524288 bytes @ 0x3e80000 Read: OK QSPI: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command QSPI: SCRIPT FAILED: continuing...
no devices available NAND: SCRIPT FAILED: continuing...
Device 0: unknown device
Device 1: unknown device scanning bus for devices... Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 14 ms (44.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
"Synchronous Abort" handler, esr 0x02000000 elr: ffffffffa816d690 lr : 000000000805f08c (reloc) elr: 0000000020000690 lr : 000000007fef208c x0 : 0000000000000020 x1 : 0000000000000000 x2 : 00000000000003e0 x3 : 0000000077c88400 x4 : 0000000020000690 x5 : 000000007be178f0 x6 : 000000007ffa5038 x7 : 000000007ffa5038 x8 : 0000000000000006 x9 : fffffffffffffff0 x10: 000000007473696c x11: 000000007be178f0 x12: 00000000000003e0 x13: 0000000000000200 x14: 000000007fe94208 x15: 0000000000000000 x16: 000000007fecdcbc x17: 0000000000000000 x18: 000000007be12da0 x19: 000000007be253e0 x20: 0000000000000020 x21: 00000000000003e0 x22: 0000000000000000 x23: 0000000077c88400 x24: 0000000000000000 x25: 0000000000000100 x26: 000000000000000f x27: 00000000000001ff x28: 000000007be4bed0 x29: 000000007be04920
Code: ffffffff ffffffff ffffffff ffffffff (ffffffff) UEFI image [0x0000000077d46000:0x0000000077de3fff] '/efi\boot\bootaa64.efi' Resetting CPU ...
### ERROR ### Please RESET the board ###
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 0x00000800 0x001007fe "Microsoft basic data" >>>>>>> attrs: 0x0000000000000000 >>>>>>> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >>>>>>> type: data >>>>>>> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >>>>>>> 2 0x00100800 0x001197fe "Microsoft basic data" >>>>>>> attrs: 0x0000000000000000 >>>>>>> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... >>>>>> >>>>>> >>>>>> >>>>>> 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html > > I want to continue on this thread. I have disabled > EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that > usb/scsi detection by simply calling usb reset and scsi reset as the > part of PREBOOT. Then all disks are recorded and visible by grub. > > But I found another issue which is kind of weird. We are using > distroboot with soft of fixed sequence. Important part of sequence is > sd, usb, scsi. > > I have added grub on scsi and when I boot directly via run bootcmd_scsi0 > everything is working fine. When I let distroboot to do the job it or > run printenv -e before bootcmd_scsi0 I am getting exception. > From debug it is visible that it is exception called from > efi_disk_read_blocks. > > 0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 > 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 > 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 > 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S, > line 141 > 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, > line 102
How and when did you get this stack trace?
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.
Yeah, but what I didn't understand was:
!"Synchronous Abort" handler, esr 0x02000000 !elr: ffffffffa816c5b0 lr : 000000000805e218 (reloc) !elr: 00000000200005b0 lr : 000000007fef2218 (snip) !Code: 000165fa 0b2d05de 0000ffff 00000000 (20000590) !UEFI image [0x0000000077d48000:0x0000000077de5fff] '/efi\boot\bootaa64.efi'
"Code:" at the exception doesn't seem to be sane assembler, and "elr" is not within the code of neither U-Boot nor shim/grub(bootaa64.efi). ("esr" doesn't tell us anything.) So I wondered where the backtrace came from.
BTW, can you please confirm which function sits at the address of "lr" (=0x7fe2218)?
I don't have that images anymore.
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.
What do you mean by "when disks are scanned just before the command"? The case when you ran "run bootcmd_scsi" without "printenv -e"?
Do you reproduce the problem even if you revert the patch, "xilinx: zynqmp: Initialize usb and scsi via preboot", and run the commands, "run scsi_init; [printenv -e;] run bootcmd_scsi?
Can you also try other EFI commands, like "efidebug devices"?
I found that there is a difference if you run scsi reset or run scsi_init. When scsi_init is used I can't see any issue.
Here you have tried three cases: (1) scsi reset; efidebug devices; boot (hence distro_bootcmd) (2) run scsi_init; efidebug devices; boot (3) scsi rescan; efidebug devices; boot
Only case(2) succeeded to boot the system. Right?
Please double-check that you don't see this problem in all those cases if you don't execute "efidebug devices" (or "printenv -e"). # make sure that no efi command will be executed before # booting from scsi.
Variable looks like this scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
And when you run scsi scan (last log) you see that problem again. It means when scsi reset/scan is called twice issue is observed. In all
If this is true, my guess is:
* In the scenarios above, all the block devices are enumerated by scsi_scan() in the first "run reset" or "run rescan" and new blk_desc's are created. * efidebug is expected to execute efi_init_obj_list(). Please note: EFI subsystem uses U-Boot's blk_desc internally to access block devices. Mapping between U-Boot's blk_desc and UEFI's efi_disk_obj (aka handle) is created only once and statically at the initialization in efi_init_obj_list().
* Now that scsi_scan() is executed again in the scond scsi command, all the block devices, hence blk_desc structures, will be freed by blk_unbind_all() and blk_desc's will be *re-created* by scsi probing. * Nevertheless, the binding between blk_desc and efi_disk_obj is maintained even at this point, so any succeeding r/w operations via UEFI interfaces can point to bogus data of old blk_desc and therefore block accesses will get corrupted.
My guess above seems to be likely, but it doesn't explain well that loading/starting "grub" binary succeeds any way.
-Takahiro Akashi
cases efidebug devices are showing disk properly.
Thanks, Michal
U-Boot SPL 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200) PMUFW: v1.1 Loading new PMUFW cfg obj (2024 bytes) Silicon version: 3 EL Level: EL3 Chip ID: zu9eg Multiboot: 0 Trying to boot from MMC2 spl: could not initialize mmc. error: -19 Trying to boot from MMC1 spl_load_image_fat_os: error reading image u-boot.bin, err - -2 NOTICE: BL31: Secure code at 0x7e000000 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v2.4(release):v2.4-592-gb5a757e853be NOTICE: BL31: Built : 07:08:43, Aug 12 2021
U-Boot 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200)
CPU: ZynqMP Silicon: v3 Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SRST Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000 starting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> scsi reset
Reset SCSI scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP> efidebug devices Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done Device Device Path ================ ==================== 000000007be20810 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007be25800 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0) 000000007be259d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x2000,0x1cd2000) 000000007be25e30 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007be350d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,GPT,85b731b6-a4b2-47f4-b1c6-aef6e0f2ce81,0x800,0xfffff) 000000007be35520 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,GPT,ac600dc7-3160-4f3c-a824-496d00e3d007,0x100800,0x18fff) 000000007be26210 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(000a350370f6,1) ZynqMP> boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image JTAG: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command JTAG: SCRIPT FAILED: continuing... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image MMC Device 1 not found no mmc device at slot 1 SF: Detected n25q512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB device 0 offset 0x3e80000, size 0x80000 SF: 524288 bytes @ 0x3e80000 Read: OK QSPI: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command QSPI: SCRIPT FAILED: continuing...
no devices available NAND: SCRIPT FAILED: continuing...
Device 0: unknown device
Device 1: unknown device scanning bus for devices... Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 15 ms (41.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
"Synchronous Abort" handler, esr 0x02000000 elr: ffffffffa816d690 lr : 000000000805f08c (reloc) elr: 0000000020000690 lr : 000000007fef208c x0 : 0000000000000020 x1 : 0000000000000000 x2 : 00000000000003e0 x3 : 0000000077c88400 x4 : 0000000020000690 x5 : 000000007be178f0 x6 : 000000007ffa5038 x7 : 000000007ffa5038 x8 : 0000000000000006 x9 : fffffffffffffff0 x10: 000000007473696c x11: 000000007be178f0 x12: 00000000000003e0 x13: 0000000000000200 x14: 000000007fe94208 x15: 0000000000000000 x16: 000000007fecdcbc x17: 0000000000000000 x18: 000000007be12da0 x19: 000000007be253e0 x20: 0000000000000020 x21: 00000000000003e0 x22: 0000000000000000 x23: 0000000077c88400 x24: 0000000000000000 x25: 0000000000000100 x26: 000000000000000f x27: 00000000000001ff x28: 000000007be4bed0 x29: 000000007be04920
Code: ffffffff ffffffff ffffffff ffffffff (ffffffff) UEFI image [0x0000000077d46000:0x0000000077de3fff] '/efi\boot\bootaa64.efi' Resetting CPU ...
### ERROR ### Please RESET the board ###
U-Boot SPL 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200) PMUFW: v1.1 Loading new PMUFW cfg obj (2024 bytes) Silicon version: 3 EL Level: EL3 Chip ID: zu9eg Multiboot: 0 Trying to boot from MMC2 spl: could not initialize mmc. error: -19 Trying to boot from MMC1 spl_load_image_fat_os: error reading image u-boot.bin, err - -2 NOTICE: BL31: Secure code at 0x7e000000 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v2.4(release):v2.4-592-gb5a757e853be NOTICE: BL31: Built : 07:08:43, Aug 12 2021
U-Boot 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200)
CPU: ZynqMP Silicon: v3 Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SRST Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000 starting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> run scsi_init scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP> efidebug devices Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done Device Device Path ================ ==================== 000000007be20790 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007be257e0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0) 000000007be259b0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x2000,0x1cd2000) 000000007be25e10 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007be350d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,GPT,85b731b6-a4b2-47f4-b1c6-aef6e0f2ce81,0x800,0xfffff) 000000007be354f0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,GPT,ac600dc7-3160-4f3c-a824-496d00e3d007,0x100800,0x18fff) 000000007be261f0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(000a350370f6,1) ZynqMP> boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image JTAG: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command JTAG: SCRIPT FAILED: continuing... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image MMC Device 1 not found no mmc device at slot 1 SF: Detected n25q512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB device 0 offset 0x3e80000, size 0x80000 SF: 524288 bytes @ 0x3e80000 Read: OK QSPI: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command QSPI: SCRIPT FAILED: continuing...
no devices available NAND: SCRIPT FAILED: continuing...
Device 0: unknown device
Device 1: unknown device
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 15 ms (41.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
GNU GRUB version 2.11┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │*Linux BusyBox │
U-Boot SPL 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200) PMUFW: v1.1 Loading new PMUFW cfg obj (2024 bytes) Silicon version: 3 EL Level: EL3 Chip ID: zu9eg Multiboot: 0 Trying to boot from MMC2 spl: could not initialize mmc. error: -19 Trying to boot from MMC1 spl_load_image_fat_os: error reading image u-boot.bin, err - -2 NOTICE: BL31: Secure code at 0x7e000000 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v2.4(release):v2.4-592-gb5a757e853be NOTICE: BL31: Built : 07:08:43, Aug 12 2021
U-Boot 2021.10-rc1-00278-gf17a954b24ad (Aug 17 2021 - 09:14:08 +0200)
CPU: ZynqMP Silicon: v3 Model: ZynqMP ZCU102 Rev1.0 Board: Xilinx ZynqMP DRAM: 4 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name: zcu102 Board rev: 1.0 Board SN: 847316301727-67998 Ethernet mac: 00:0a:35:03:70:f6 EL Level: EL2 Chip ID: zu9eg WDT: Not found! NAND: 0 MiB MMC: mmc@ff170000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment
In: serial Out: serial Err: serial Bootmode: LVL_SHFT_SD_MODE1 Reset reason: SRST Net: ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e0000 starting USB... Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ZynqMP> ZynqMP> ZynqMP> scsi scan scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP> efidebug devices Scanning disk mmc@ff170000.blk... Scanning disk ahci_scsi.id1lun0... Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done Device Device Path ================ ==================== 000000007be20810 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007be25800 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0) 000000007be259d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x2000,0x1cd2000) 000000007be25e30 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007be350d0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,GPT,85b731b6-a4b2-47f4-b1c6-aef6e0f2ce81,0x800,0xfffff) 000000007be35520 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,GPT,ac600dc7-3160-4f3c-a824-496d00e3d007,0x100800,0x18fff) 000000007be26210 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(000a350370f6,1) ZynqMP> boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image JTAG: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command JTAG: SCRIPT FAILED: continuing... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image MMC Device 1 not found no mmc device at slot 1 SF: Detected n25q512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB device 0 offset 0x3e80000, size 0x80000 SF: 524288 bytes @ 0x3e80000 Read: OK QSPI: Trying to boot script at 20000000 ## Executing script at 20000000 Wrong image format for "source" command QSPI: SCRIPT FAILED: continuing...
no devices available NAND: SCRIPT FAILED: continuing...
Device 0: unknown device
Device 1: unknown device scanning bus for devices... Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ... is now current device Scanning scsi 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 647168 bytes read in 14 ms (44.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi PE image measurement failed Welcome to GRUB!
"Synchronous Abort" handler, esr 0x02000000 elr: ffffffffa816d690 lr : 000000000805f08c (reloc) elr: 0000000020000690 lr : 000000007fef208c x0 : 0000000000000020 x1 : 0000000000000000 x2 : 00000000000003e0 x3 : 0000000077c88400 x4 : 0000000020000690 x5 : 000000007be178f0 x6 : 000000007ffa5038 x7 : 000000007ffa5038 x8 : 0000000000000006 x9 : fffffffffffffff0 x10: 000000007473696c x11: 000000007be178f0 x12: 00000000000003e0 x13: 0000000000000200 x14: 000000007fe94208 x15: 0000000000000000 x16: 000000007fecdcbc x17: 0000000000000000 x18: 000000007be12da0 x19: 000000007be253e0 x20: 0000000000000020 x21: 00000000000003e0 x22: 0000000000000000 x23: 0000000077c88400 x24: 0000000000000000 x25: 0000000000000100 x26: 000000000000000f x27: 00000000000001ff x28: 000000007be4bed0 x29: 000000007be04920
Code: ffffffff ffffffff ffffffff ffffffff (ffffffff) UEFI image [0x0000000077d46000:0x0000000077de3fff] '/efi\boot\bootaa64.efi' Resetting CPU ...
### ERROR ### Please RESET the board ###
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 0x00000800 0x001007fe "Microsoft basic data" >>>>>>>> attrs: 0x0000000000000000 >>>>>>>> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >>>>>>>> type: data >>>>>>>> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >>>>>>>> 2 0x00100800 0x001197fe "Microsoft basic data" >>>>>>>> attrs: 0x0000000000000000 >>>>>>>> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html >> >> I want to continue on this thread. I have disabled >> EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that >> usb/scsi detection by simply calling usb reset and scsi reset as the >> part of PREBOOT. Then all disks are recorded and visible by grub. >> >> But I found another issue which is kind of weird. We are using >> distroboot with soft of fixed sequence. Important part of sequence is >> sd, usb, scsi. >> >> I have added grub on scsi and when I boot directly via run bootcmd_scsi0 >> everything is working fine. When I let distroboot to do the job it or >> run printenv -e before bootcmd_scsi0 I am getting exception. >> From debug it is visible that it is exception called from >> efi_disk_read_blocks. >> >> 0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 >> 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 >> 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 >> 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S, >> line 141 >> 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, >> line 102 > > How and when did you get this stack trace?
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.
Yeah, but what I didn't understand was:
!"Synchronous Abort" handler, esr 0x02000000 !elr: ffffffffa816c5b0 lr : 000000000805e218 (reloc) !elr: 00000000200005b0 lr : 000000007fef2218 (snip) !Code: 000165fa 0b2d05de 0000ffff 00000000 (20000590) !UEFI image [0x0000000077d48000:0x0000000077de5fff] '/efi\boot\bootaa64.efi'
"Code:" at the exception doesn't seem to be sane assembler, and "elr" is not within the code of neither U-Boot nor shim/grub(bootaa64.efi). ("esr" doesn't tell us anything.) So I wondered where the backtrace came from.
BTW, can you please confirm which function sits at the address of "lr" (=0x7fe2218)?
I don't have that images anymore.
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.
What do you mean by "when disks are scanned just before the command"? The case when you ran "run bootcmd_scsi" without "printenv -e"?
Do you reproduce the problem even if you revert the patch, "xilinx: zynqmp: Initialize usb and scsi via preboot", and run the commands, "run scsi_init; [printenv -e;] run bootcmd_scsi?
Can you also try other EFI commands, like "efidebug devices"?
I found that there is a difference if you run scsi reset or run scsi_init. When scsi_init is used I can't see any issue.
Here you have tried three cases: (1) scsi reset; efidebug devices; boot (hence distro_bootcmd) (2) run scsi_init; efidebug devices; boot (3) scsi rescan; efidebug devices; boot
Only case(2) succeeded to boot the system. Right?
Please double-check that you don't see this problem in all those cases if you don't execute "efidebug devices" (or "printenv -e"). # make sure that no efi command will be executed before # booting from scsi.
I tested these 3 cases and all of them works fine.
scsi reset devtype=scsi run scan_dev_for_boot_part
run scsi_init devtype=scsi run scan_dev_for_boot_part
scsi rescan devtype=scsi run scan_dev_for_boot_part
Variable looks like this scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
And when you run scsi scan (last log) you see that problem again. It means when scsi reset/scan is called twice issue is observed. In all
If this is true, my guess is:
In the scenarios above, all the block devices are enumerated by scsi_scan() in the first "run reset" or "run rescan" and new blk_desc's are created.
efidebug is expected to execute efi_init_obj_list(). Please note: EFI subsystem uses U-Boot's blk_desc internally to access block devices. Mapping between U-Boot's blk_desc and UEFI's efi_disk_obj (aka handle) is created only once and statically at the initialization in efi_init_obj_list().
Now that scsi_scan() is executed again in the scond scsi command, all the block devices, hence blk_desc structures, will be freed by blk_unbind_all() and blk_desc's will be *re-created* by scsi probing.
Nevertheless, the binding between blk_desc and efi_disk_obj is maintained even at this point, so any succeeding r/w operations via UEFI interfaces can point to bogus data of old blk_desc and therefore block accesses will get corrupted.
My guess above seems to be likely, but it doesn't explain well that loading/starting "grub" binary succeeds any way.
That make sense what you described. I print desc and by reset there is new desc created at different address. And origin location is freed in device_unbind. Log is below. The question is how to fix this behavior.
Thanks, Michal
ZynqMP> scsi reset
Reset SCSI scanning bus for devices... blk_unbind_all: if_type 2 SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst blk_create_device: devnum -1 blk_create_device: name ahci_scsi.id1lun0, desc 000000007be21340 Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP> efidebug devices Scanning disk mmc@ff170000.blk... efi_disk_add_dev: desc 000000007be15b30 efi_disk_add_dev: desc 000000007be15b30 Scanning disk ahci_scsi.id1lun0... efi_disk_add_dev: desc 000000007be21340 efi_disk_add_dev: desc 000000007be21340 efi_disk_add_dev: desc 000000007be21340 Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done Device Device Path ================ ==================== 000000007be21590 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007be218a0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0) 000000007be21a70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x2000,0x1cd2000) 000000007be21f00 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007be222e0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,GPT,85b731b6-a4b2-47f4-b1c6-aef6e0f2ce81,0x800,0xfffff) 000000007be22730 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,GPT,ac600dc7-3160-4f3c-a824-496d00e3d007,0x100800,0x18fff) 000000007be22c80 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(000a350370f6,1) ZynqMP> scsi reset
Reset SCSI scanning bus for devices... blk_unbind_all: if_type 2 Removing/unbinding device ahci_scsi.id1lun0 device_unbind: free desc 000000007be21340 blk_create_device: devnum -1 blk_create_device: name ahci_scsi.id1lun0, desc 000000007be3e070 Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP>
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 0x00000800 0x001007fe "Microsoft basic data" >>>>>>>>> attrs: 0x0000000000000000 >>>>>>>>> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >>>>>>>>> type: data >>>>>>>>> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >>>>>>>>> 2 0x00100800 0x001197fe "Microsoft basic data" >>>>>>>>> attrs: 0x0000000000000000 >>>>>>>>> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html >>> >>> I want to continue on this thread. I have disabled >>> EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that >>> usb/scsi detection by simply calling usb reset and scsi reset as the >>> part of PREBOOT. Then all disks are recorded and visible by grub. >>> >>> But I found another issue which is kind of weird. We are using >>> distroboot with soft of fixed sequence. Important part of sequence is >>> sd, usb, scsi. >>> >>> I have added grub on scsi and when I boot directly via run bootcmd_scsi0 >>> everything is working fine. When I let distroboot to do the job it or >>> run printenv -e before bootcmd_scsi0 I am getting exception. >>> From debug it is visible that it is exception called from >>> efi_disk_read_blocks. >>> >>> 0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 >>> 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 >>> 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 >>> 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S, >>> line 141 >>> 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, >>> line 102 >> >> How and when did you get this stack trace? > > 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.
Yeah, but what I didn't understand was:
!"Synchronous Abort" handler, esr 0x02000000 !elr: ffffffffa816c5b0 lr : 000000000805e218 (reloc) !elr: 00000000200005b0 lr : 000000007fef2218 (snip) !Code: 000165fa 0b2d05de 0000ffff 00000000 (20000590) !UEFI image [0x0000000077d48000:0x0000000077de5fff] '/efi\boot\bootaa64.efi'
"Code:" at the exception doesn't seem to be sane assembler, and "elr" is not within the code of neither U-Boot nor shim/grub(bootaa64.efi). ("esr" doesn't tell us anything.) So I wondered where the backtrace came from.
BTW, can you please confirm which function sits at the address of "lr" (=0x7fe2218)?
I don't have that images anymore.
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.
What do you mean by "when disks are scanned just before the command"? The case when you ran "run bootcmd_scsi" without "printenv -e"?
Do you reproduce the problem even if you revert the patch, "xilinx: zynqmp: Initialize usb and scsi via preboot", and run the commands, "run scsi_init; [printenv -e;] run bootcmd_scsi?
Can you also try other EFI commands, like "efidebug devices"?
I found that there is a difference if you run scsi reset or run scsi_init. When scsi_init is used I can't see any issue.
Here you have tried three cases: (1) scsi reset; efidebug devices; boot (hence distro_bootcmd) (2) run scsi_init; efidebug devices; boot (3) scsi rescan; efidebug devices; boot
Only case(2) succeeded to boot the system. Right?
Please double-check that you don't see this problem in all those cases if you don't execute "efidebug devices" (or "printenv -e"). # make sure that no efi command will be executed before # booting from scsi.
I tested these 3 cases and all of them works fine.
Thank you for the confirmation.
scsi reset devtype=scsi run scan_dev_for_boot_part
run scsi_init devtype=scsi run scan_dev_for_boot_part
scsi rescan devtype=scsi run scan_dev_for_boot_part
Variable looks like this scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
And when you run scsi scan (last log) you see that problem again. It means when scsi reset/scan is called twice issue is observed. In all
If this is true, my guess is:
In the scenarios above, all the block devices are enumerated by scsi_scan() in the first "run reset" or "run rescan" and new blk_desc's are created.
efidebug is expected to execute efi_init_obj_list(). Please note: EFI subsystem uses U-Boot's blk_desc internally to access block devices. Mapping between U-Boot's blk_desc and UEFI's efi_disk_obj (aka handle) is created only once and statically at the initialization in efi_init_obj_list().
Now that scsi_scan() is executed again in the scond scsi command, all the block devices, hence blk_desc structures, will be freed by blk_unbind_all() and blk_desc's will be *re-created* by scsi probing.
Nevertheless, the binding between blk_desc and efi_disk_obj is maintained even at this point, so any succeeding r/w operations via UEFI interfaces can point to bogus data of old blk_desc and therefore block accesses will get corrupted.
My guess above seems to be likely, but it doesn't explain well that loading/starting "grub" binary succeeds any way.
# The implementation of LoadImage interface doesn't use block_io_protocol, # and so we won't see this problem when 'grub' is started.
That make sense what you described. I print desc and by reset there is new desc created at different address. And origin location is freed in device_unbind. Log is below. The question is how to fix this behavior.
It is a matter of *integration* of U-Boot's DM and UEFI implementation. It can be, however, a bit difficult/complicated task to achieve this goal in such a way that Simon has expected (for example, see [1]).
-Takahiro Akashi
[1] https://lists.denx.de/pipermail/u-boot/2021-June/452847.html
Thanks, Michal
ZynqMP> scsi reset
Reset SCSI scanning bus for devices... blk_unbind_all: if_type 2 SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst blk_create_device: devnum -1 blk_create_device: name ahci_scsi.id1lun0, desc 000000007be21340 Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP> efidebug devices Scanning disk mmc@ff170000.blk... efi_disk_add_dev: desc 000000007be15b30 efi_disk_add_dev: desc 000000007be15b30 Scanning disk ahci_scsi.id1lun0... efi_disk_add_dev: desc 000000007be21340 efi_disk_add_dev: desc 000000007be21340 efi_disk_add_dev: desc 000000007be21340 Found 5 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables Unable to find TPMv2 device DFU alt info setting: done Device Device Path ================ ==================== 000000007be21590 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007be218a0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0) 000000007be21a70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x2000,0x1cd2000) 000000007be21f00 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007be222e0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,GPT,85b731b6-a4b2-47f4-b1c6-aef6e0f2ce81,0x800,0xfffff) 000000007be22730 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,GPT,ac600dc7-3160-4f3c-a824-496d00e3d007,0x100800,0x18fff) 000000007be22c80 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(000a350370f6,1) ZynqMP> scsi reset
Reset SCSI scanning bus for devices... blk_unbind_all: if_type 2 Removing/unbinding device ahci_scsi.id1lun0 device_unbind: free desc 000000007be21340 blk_create_device: devnum -1 blk_create_device: name ahci_scsi.id1lun0, desc 000000007be3e070 Device 0: (1:0) Vendor: ATA Prod.: Maxtor 7V300F0 Rev: VA11 Type: Hard Disk Capacity: 286188.8 MB = 279.4 GB (586114704 x 512) ZynqMP>
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 0x00000800 0x001007fe "Microsoft basic data" >>>>>>>>>> attrs: 0x0000000000000000 >>>>>>>>>> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >>>>>>>>>> type: data >>>>>>>>>> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >>>>>>>>>> 2 0x00100800 0x001197fe "Microsoft basic data" >>>>>>>>>> attrs: 0x0000000000000000 >>>>>>>>>> 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/3dca77b1dc1b6dbf9c8b51572fe4b0... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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://lists.denx.de/pipermail/u-boot/2019-February/357923.html >>>> >>>> I want to continue on this thread. I have disabled >>>> EFI_CAPSULE_ON_DISK_EARLY some time ago and trying to workaround that >>>> usb/scsi detection by simply calling usb reset and scsi reset as the >>>> part of PREBOOT. Then all disks are recorded and visible by grub. >>>> >>>> But I found another issue which is kind of weird. We are using >>>> distroboot with soft of fixed sequence. Important part of sequence is >>>> sd, usb, scsi. >>>> >>>> I have added grub on scsi and when I boot directly via run bootcmd_scsi0 >>>> everything is working fine. When I let distroboot to do the job it or >>>> run printenv -e before bootcmd_scsi0 I am getting exception. >>>> From debug it is visible that it is exception called from >>>> efi_disk_read_blocks. >>>> >>>> 0 0x7ff5d188 hang()+20: include/bootstage.h, line 389 >>>> 1 0x7ff5f908 __assert_fail(): lib/panic.c, line 25 >>>> 2 0x7fe976a8 do_irq(): arch/arm/lib/interrupts_64.c, line 123 >>>> 3 0x7fe96a0c _restore_regs()+124: arch/arm/cpu/armv8/exceptions.S, >>>> line 141 >>>> 4 0x7ff43740 efi_disk_read_blocks()+160: lib/efi_loader/efi_disk.c, >>>> line 102 >>> >>> How and when did you get this stack trace? >> >> 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.
Yeah, but what I didn't understand was:
!"Synchronous Abort" handler, esr 0x02000000 !elr: ffffffffa816c5b0 lr : 000000000805e218 (reloc) !elr: 00000000200005b0 lr : 000000007fef2218 (snip) !Code: 000165fa 0b2d05de 0000ffff 00000000 (20000590) !UEFI image [0x0000000077d48000:0x0000000077de5fff] '/efi\boot\bootaa64.efi'
"Code:" at the exception doesn't seem to be sane assembler, and "elr" is not within the code of neither U-Boot nor shim/grub(bootaa64.efi). ("esr" doesn't tell us anything.) So I wondered where the backtrace came from.
BTW, can you please confirm which function sits at the address of "lr" (=0x7fe2218)?
I don't have that images anymore.
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.
What do you mean by "when disks are scanned just before the command"? The case when you ran "run bootcmd_scsi" without "printenv -e"?
Do you reproduce the problem even if you revert the patch, "xilinx: zynqmp: Initialize usb and scsi via preboot", and run the commands, "run scsi_init; [printenv -e;] run bootcmd_scsi?
Can you also try other EFI commands, like "efidebug devices"?
I found that there is a difference if you run scsi reset or run scsi_init. When scsi_init is used I can't see any issue.
Here you have tried three cases: (1) scsi reset; efidebug devices; boot (hence distro_bootcmd) (2) run scsi_init; efidebug devices; boot (3) scsi rescan; efidebug devices; boot
Only case(2) succeeded to boot the system. Right?
Please double-check that you don't see this problem in all those cases if you don't execute "efidebug devices" (or "printenv -e"). # make sure that no efi command will be executed before # booting from scsi.
I tested these 3 cases and all of them works fine.
Thank you for the confirmation.
scsi reset devtype=scsi run scan_dev_for_boot_part
run scsi_init devtype=scsi run scan_dev_for_boot_part
scsi rescan devtype=scsi run scan_dev_for_boot_part
Variable looks like this scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
And when you run scsi scan (last log) you see that problem again. It means when scsi reset/scan is called twice issue is observed. In all
If this is true, my guess is:
In the scenarios above, all the block devices are enumerated by scsi_scan() in the first "run reset" or "run rescan" and new blk_desc's are created.
efidebug is expected to execute efi_init_obj_list(). Please note: EFI subsystem uses U-Boot's blk_desc internally to access block devices. Mapping between U-Boot's blk_desc and UEFI's efi_disk_obj (aka handle) is created only once and statically at the initialization in efi_init_obj_list().
Now that scsi_scan() is executed again in the scond scsi command, all the block devices, hence blk_desc structures, will be freed by blk_unbind_all() and blk_desc's will be *re-created* by scsi probing.
Nevertheless, the binding between blk_desc and efi_disk_obj is maintained even at this point, so any succeeding r/w operations via UEFI interfaces can point to bogus data of old blk_desc and therefore block accesses will get corrupted.
My guess above seems to be likely, but it doesn't explain well that loading/starting "grub" binary succeeds any way.
# The implementation of LoadImage interface doesn't use block_io_protocol, # and so we won't see this problem when 'grub' is started.
That make sense what you described. I print desc and by reset there is new desc created at different address. And origin location is freed in device_unbind. Log is below. The question is how to fix this behavior.
It is a matter of *integration* of U-Boot's DM and UEFI implementation. It can be, however, a bit difficult/complicated task to achieve this goal in such a way that Simon has expected (for example, see [1]).
-Takahiro Akashi
[1] https://lists.denx.de/pipermail/u-boot/2021-June/452847.html
Ok. Then for me the only reasonable solution which is available now is to call scsi_init via preboot to get block device before any efi initialization. And likely usb_boot should be updated in the same way as scsi to use variable and not call usb start/reset twice.
Thanks, Michal
participants (4)
-
AKASHI Takahiro -
Heinrich Schuchardt -
Ilias Apalodimas -
Michal Simek