* EFI from usb HDD @ 2021-06-10 8:44 Michal Simek 2021-06-10 9:47 ` Heinrich Schuchardt 0 siblings, 1 reply; 19+ messages in thread From: Michal Simek @ 2021-06-10 8:44 UTC (permalink / raw) To: Heinrich Schuchardt, Ilias Apalodimas; +Cc: U-Boot Mailing List 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-06-10 8:44 EFI from usb HDD Michal Simek @ 2021-06-10 9:47 ` Heinrich Schuchardt 2021-06-10 10:04 ` Michal Simek 0 siblings, 1 reply; 19+ messages in thread From: Heinrich Schuchardt @ 2021-06-10 9:47 UTC (permalink / raw) To: Michal Simek; +Cc: U-Boot Mailing List, Ilias Apalodimas 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f Block devices are enumerated in efi_disk_register(). Please, try to add debug output there to elucidate the problem. Best regards Heinrich ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-06-10 9:47 ` Heinrich Schuchardt @ 2021-06-10 10:04 ` Michal Simek 2021-06-10 10:51 ` Heinrich Schuchardt 0 siblings, 1 reply; 19+ messages in thread From: Michal Simek @ 2021-06-10 10:04 UTC (permalink / raw) To: Heinrich Schuchardt, Michal Simek; +Cc: U-Boot Mailing List, Ilias Apalodimas 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > Block devices are enumerated in efi_disk_register(). Please, try to add > debug output there to elucidate the problem. I found where the problem is. First of all zcu102 didn't use the same image as others (it wasn't updated properly). When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() is called before usb block devices are detected and registered that's why grub doesn't see them. I was looking at adding usb start in preboot but preboot is called later. How this should be solved? Any idea? Thanks, Michal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-06-10 10:04 ` Michal Simek @ 2021-06-10 10:51 ` Heinrich Schuchardt 2021-06-10 12:31 ` Michal Simek 0 siblings, 1 reply; 19+ messages in thread From: Heinrich Schuchardt @ 2021-06-10 10:51 UTC (permalink / raw) To: Sughosh Ganu, AKASHI Takahiro Cc: U-Boot Mailing List, Ilias Apalodimas, Michal Simek, Simon Glass 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >> >> >> Block devices are enumerated in efi_disk_register(). Please, try to add >> debug output there to elucidate the problem. > > I found where the problem is. First of all zcu102 didn't use the same > image as others (it wasn't updated properly). > When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > is called before usb block devices are detected and registered that's > why grub doesn't see them. The problem is CONFIG_EFI_SETUP_EARLY=y required by CONFIG_EFI_CAPSULE_ON_DISK_EARLY. Why is USB initialized later then MMC? Overall we have a deficiency in the UEFI implementation in that we cannot deal with block devices added or removed after initialization. Here integration with the driver model is missing. > I was looking at adding usb start in preboot but preboot is called later. > How this should be solved? Any idea? > > Thanks, > Michal > > +cc Sughosh, Takahiro (who have developed the capsule code) Best regards Heinrich ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-06-10 10:51 ` Heinrich Schuchardt @ 2021-06-10 12:31 ` Michal Simek 2021-06-10 12:59 ` AKASHI Takahiro 0 siblings, 1 reply; 19+ messages in thread From: Michal Simek @ 2021-06-10 12:31 UTC (permalink / raw) To: Heinrich Schuchardt, Sughosh Ganu, AKASHI Takahiro Cc: U-Boot Mailing List, Ilias Apalodimas, Michal Simek, Simon Glass 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>> >>> >>> >>> Block devices are enumerated in efi_disk_register(). Please, try to add >>> debug output there to elucidate the problem. >> >> I found where the problem is. First of all zcu102 didn't use the same >> image as others (it wasn't updated properly). >> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >> is called before usb block devices are detected and registered that's >> why grub doesn't see them. > > The problem is CONFIG_EFI_SETUP_EARLY=y required by > CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > > Why is USB initialized later then MMC? It is not just usb. SCSI/sata are behaving in the same way too. > > Overall we have a deficiency in the UEFI implementation in that we > cannot deal with block devices added or removed after initialization. > > Here integration with the driver model is missing. Right. And also there are commands which can create MBR partitions and I expect when you write image to SD and then run rescan or so you could get other partitions too. Maybe hook via part_init()? with removing efi_disk_register. > >> I was looking at adding usb start in preboot but preboot is called later. >> How this should be solved? Any idea? >> >> Thanks, >> Michal >> >> > +cc Sughosh, Takahiro (who have developed the capsule code) Thanks, Michal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-06-10 12:31 ` Michal Simek @ 2021-06-10 12:59 ` AKASHI Takahiro 2021-07-29 14:09 ` Michal Simek 0 siblings, 1 reply; 19+ messages in thread From: AKASHI Takahiro @ 2021-06-10 12:59 UTC (permalink / raw) To: Michal Simek Cc: Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>> > >>> > >>> > >>> Block devices are enumerated in efi_disk_register(). Please, try to add > >>> debug output there to elucidate the problem. > >> > >> I found where the problem is. First of all zcu102 didn't use the same > >> image as others (it wasn't updated properly). > >> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >> is called before usb block devices are detected and registered that's > >> why grub doesn't see them. > > > > The problem is CONFIG_EFI_SETUP_EARLY=y required by > > CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > > > > Why is USB initialized later then MMC? > > It is not just usb. SCSI/sata are behaving in the same way too. > > > > > Overall we have a deficiency in the UEFI implementation in that we > > cannot deal with block devices added or removed after initialization. > > > > Here integration with the driver model is missing. > > Right. And also there are commands which can create MBR partitions and I > expect when you write image to SD and then run rescan or so you could > get other partitions too. > Maybe hook via part_init()? with removing efi_disk_register. For the record, I have proposed my ideas several times[1], [2]. I'm, however, no longer working on this issue as I have shifted my focus to UEFI secure boot and capsule update. -Takahiro Akashi [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html [2] https://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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-06-10 12:59 ` AKASHI Takahiro @ 2021-07-29 14:09 ` Michal Simek 2021-07-30 2:35 ` AKASHI Takahiro 0 siblings, 1 reply; 19+ messages in thread From: Michal Simek @ 2021-07-29 14:09 UTC (permalink / raw) To: AKASHI Takahiro, Michal Simek, Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass Cc: Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>>>> >>>>> >>>>> >>>>> Block devices are enumerated in efi_disk_register(). Please, try to add >>>>> debug output there to elucidate the problem. >>>> >>>> I found where the problem is. First of all zcu102 didn't use the same >>>> image as others (it wasn't updated properly). >>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >>>> is called before usb block devices are detected and registered that's >>>> why grub doesn't see them. >>> >>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>> >>> Why is USB initialized later then MMC? >> >> It is not just usb. SCSI/sata are behaving in the same way too. >> >>> >>> Overall we have a deficiency in the UEFI implementation in that we >>> cannot deal with block devices added or removed after initialization. >>> >>> Here integration with the driver model is missing. >> >> Right. And also there are commands which can create MBR partitions and I >> expect when you write image to SD and then run rescan or so you could >> get other partitions too. >> Maybe hook via part_init()? with removing efi_disk_register. > > For the record, I have proposed my ideas several times[1], [2]. > I'm, however, no longer working on this issue as I have shifted > my focus to UEFI secure boot and capsule update. > > -Takahiro Akashi > > [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html > [2] https://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 ### ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-07-29 14:09 ` Michal Simek @ 2021-07-30 2:35 ` AKASHI Takahiro 2021-07-30 4:41 ` Michal Simek 0 siblings, 1 reply; 19+ messages in thread From: AKASHI Takahiro @ 2021-07-30 2:35 UTC (permalink / raw) To: Michal Simek Cc: Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>>>> > >>>>> > >>>>> > >>>>> Block devices are enumerated in efi_disk_register(). Please, try to add > >>>>> debug output there to elucidate the problem. > >>>> > >>>> I found where the problem is. First of all zcu102 didn't use the same > >>>> image as others (it wasn't updated properly). > >>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >>>> is called before usb block devices are detected and registered that's > >>>> why grub doesn't see them. > >>> > >>> The problem is CONFIG_EFI_SETUP_EARLY=y required by > >>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > >>> > >>> Why is USB initialized later then MMC? > >> > >> It is not just usb. SCSI/sata are behaving in the same way too. > >> > >>> > >>> Overall we have a deficiency in the UEFI implementation in that we > >>> cannot deal with block devices added or removed after initialization. > >>> > >>> Here integration with the driver model is missing. > >> > >> Right. And also there are commands which can create MBR partitions and I > >> expect when you write image to SD and then run rescan or so you could > >> get other partitions too. > >> Maybe hook via part_init()? with removing efi_disk_register. > > > > For the record, I have proposed my ideas several times[1], [2]. > > I'm, however, no longer working on this issue as I have shifted > > my focus to UEFI secure boot and capsule update. > > > > -Takahiro Akashi > > > > [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html > > [2] https://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.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 ### > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-07-30 2:35 ` AKASHI Takahiro @ 2021-07-30 4:41 ` Michal Simek 2021-07-30 5:33 ` AKASHI Takahiro 0 siblings, 1 reply; 19+ messages in thread From: Michal Simek @ 2021-07-30 4:41 UTC (permalink / raw) To: AKASHI Takahiro, Michal Simek, Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>>>>>> >>>>>>> >>>>>>> >>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add >>>>>>> debug output there to elucidate the problem. >>>>>> >>>>>> I found where the problem is. First of all zcu102 didn't use the same >>>>>> image as others (it wasn't updated properly). >>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >>>>>> is called before usb block devices are detected and registered that's >>>>>> why grub doesn't see them. >>>>> >>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>>>> >>>>> Why is USB initialized later then MMC? >>>> >>>> It is not just usb. SCSI/sata are behaving in the same way too. >>>> >>>>> >>>>> Overall we have a deficiency in the UEFI implementation in that we >>>>> cannot deal with block devices added or removed after initialization. >>>>> >>>>> Here integration with the driver model is missing. >>>> >>>> Right. And also there are commands which can create MBR partitions and I >>>> expect when you write image to SD and then run rescan or so you could >>>> get other partitions too. >>>> Maybe hook via part_init()? with removing efi_disk_register. >>> >>> For the record, I have proposed my ideas several times[1], [2]. >>> I'm, however, no longer working on this issue as I have shifted >>> my focus to UEFI secure boot and capsule update. >>> >>> -Takahiro Akashi >>> >>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html >>> [2] https://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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-07-30 4:41 ` Michal Simek @ 2021-07-30 5:33 ` AKASHI Takahiro 2021-07-30 6:22 ` Michal Simek 0 siblings, 1 reply; 19+ messages in thread From: AKASHI Takahiro @ 2021-07-30 5:33 UTC (permalink / raw) To: Michal Simek Cc: Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add > >>>>>>> debug output there to elucidate the problem. > >>>>>> > >>>>>> I found where the problem is. First of all zcu102 didn't use the same > >>>>>> image as others (it wasn't updated properly). > >>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >>>>>> is called before usb block devices are detected and registered that's > >>>>>> why grub doesn't see them. > >>>>> > >>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by > >>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > >>>>> > >>>>> Why is USB initialized later then MMC? > >>>> > >>>> It is not just usb. SCSI/sata are behaving in the same way too. > >>>> > >>>>> > >>>>> Overall we have a deficiency in the UEFI implementation in that we > >>>>> cannot deal with block devices added or removed after initialization. > >>>>> > >>>>> Here integration with the driver model is missing. > >>>> > >>>> Right. And also there are commands which can create MBR partitions and I > >>>> expect when you write image to SD and then run rescan or so you could > >>>> get other partitions too. > >>>> Maybe hook via part_init()? with removing efi_disk_register. > >>> > >>> For the record, I have proposed my ideas several times[1], [2]. > >>> I'm, however, no longer working on this issue as I have shifted > >>> my focus to UEFI secure boot and capsule update. > >>> > >>> -Takahiro Akashi > >>> > >>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html > >>> [2] https://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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-07-30 5:33 ` AKASHI Takahiro @ 2021-07-30 6:22 ` Michal Simek 2021-08-04 10:50 ` Ilias Apalodimas 2021-08-12 9:43 ` AKASHI Takahiro 0 siblings, 2 replies; 19+ messages in thread From: Michal Simek @ 2021-07-30 6:22 UTC (permalink / raw) To: AKASHI Takahiro, Michal Simek, Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add >>>>>>>>> debug output there to elucidate the problem. >>>>>>>> >>>>>>>> I found where the problem is. First of all zcu102 didn't use the same >>>>>>>> image as others (it wasn't updated properly). >>>>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >>>>>>>> is called before usb block devices are detected and registered that's >>>>>>>> why grub doesn't see them. >>>>>>> >>>>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>>>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>>>>>> >>>>>>> Why is USB initialized later then MMC? >>>>>> >>>>>> It is not just usb. SCSI/sata are behaving in the same way too. >>>>>> >>>>>>> >>>>>>> Overall we have a deficiency in the UEFI implementation in that we >>>>>>> cannot deal with block devices added or removed after initialization. >>>>>>> >>>>>>> Here integration with the driver model is missing. >>>>>> >>>>>> Right. And also there are commands which can create MBR partitions and I >>>>>> expect when you write image to SD and then run rescan or so you could >>>>>> get other partitions too. >>>>>> Maybe hook via part_init()? with removing efi_disk_register. >>>>> >>>>> For the record, I have proposed my ideas several times[1], [2]. >>>>> I'm, however, no longer working on this issue as I have shifted >>>>> my focus to UEFI secure boot and capsule update. >>>>> >>>>> -Takahiro Akashi >>>>> >>>>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html >>>>> [2] https://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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-07-30 6:22 ` Michal Simek @ 2021-08-04 10:50 ` Ilias Apalodimas 2021-08-11 12:28 ` Michal Simek 2021-08-12 9:43 ` AKASHI Takahiro 1 sibling, 1 reply; 19+ messages in thread From: Ilias Apalodimas @ 2021-08-04 10:50 UTC (permalink / raw) To: Michal Simek Cc: AKASHI Takahiro, Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Simon Glass, Vincent Stehle 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-08-04 10:50 ` Ilias Apalodimas @ 2021-08-11 12:28 ` Michal Simek 0 siblings, 0 replies; 19+ messages in thread From: Michal Simek @ 2021-08-11 12:28 UTC (permalink / raw) To: Ilias Apalodimas, Michal Simek Cc: AKASHI Takahiro, Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Simon Glass, Vincent Stehle 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-07-30 6:22 ` Michal Simek 2021-08-04 10:50 ` Ilias Apalodimas @ 2021-08-12 9:43 ` AKASHI Takahiro 2021-08-17 7:20 ` Michal Simek 1 sibling, 1 reply; 19+ messages in thread From: AKASHI Takahiro @ 2021-08-12 9:43 UTC (permalink / raw) To: Michal Simek Cc: Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add > >>>>>>>>> debug output there to elucidate the problem. > >>>>>>>> > >>>>>>>> I found where the problem is. First of all zcu102 didn't use the same > >>>>>>>> image as others (it wasn't updated properly). > >>>>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >>>>>>>> is called before usb block devices are detected and registered that's > >>>>>>>> why grub doesn't see them. > >>>>>>> > >>>>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by > >>>>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > >>>>>>> > >>>>>>> Why is USB initialized later then MMC? > >>>>>> > >>>>>> It is not just usb. SCSI/sata are behaving in the same way too. > >>>>>> > >>>>>>> > >>>>>>> Overall we have a deficiency in the UEFI implementation in that we > >>>>>>> cannot deal with block devices added or removed after initialization. > >>>>>>> > >>>>>>> Here integration with the driver model is missing. > >>>>>> > >>>>>> Right. And also there are commands which can create MBR partitions and I > >>>>>> expect when you write image to SD and then run rescan or so you could > >>>>>> get other partitions too. > >>>>>> Maybe hook via part_init()? with removing efi_disk_register. > >>>>> > >>>>> For the record, I have proposed my ideas several times[1], [2]. > >>>>> I'm, however, no longer working on this issue as I have shifted > >>>>> my focus to UEFI secure boot and capsule update. > >>>>> > >>>>> -Takahiro Akashi > >>>>> > >>>>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html > >>>>> [2] https://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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-08-12 9:43 ` AKASHI Takahiro @ 2021-08-17 7:20 ` Michal Simek 2021-08-18 5:13 ` AKASHI Takahiro 0 siblings, 1 reply; 19+ messages in thread From: Michal Simek @ 2021-08-17 7:20 UTC (permalink / raw) To: AKASHI Takahiro, Michal Simek, Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add >>>>>>>>>>> debug output there to elucidate the problem. >>>>>>>>>> >>>>>>>>>> I found where the problem is. First of all zcu102 didn't use the same >>>>>>>>>> image as others (it wasn't updated properly). >>>>>>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >>>>>>>>>> is called before usb block devices are detected and registered that's >>>>>>>>>> why grub doesn't see them. >>>>>>>>> >>>>>>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>>>>>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>>>>>>>> >>>>>>>>> Why is USB initialized later then MMC? >>>>>>>> >>>>>>>> It is not just usb. SCSI/sata are behaving in the same way too. >>>>>>>> >>>>>>>>> >>>>>>>>> Overall we have a deficiency in the UEFI implementation in that we >>>>>>>>> cannot deal with block devices added or removed after initialization. >>>>>>>>> >>>>>>>>> Here integration with the driver model is missing. >>>>>>>> >>>>>>>> Right. And also there are commands which can create MBR partitions and I >>>>>>>> expect when you write image to SD and then run rescan or so you could >>>>>>>> get other partitions too. >>>>>>>> Maybe hook via part_init()? with removing efi_disk_register. >>>>>>> >>>>>>> For the record, I have proposed my ideas several times[1], [2]. >>>>>>> I'm, however, no longer working on this issue as I have shifted >>>>>>> my focus to UEFI secure boot and capsule update. >>>>>>> >>>>>>> -Takahiro Akashi >>>>>>> >>>>>>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html >>>>>>> [2] https://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 ### ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-08-17 7:20 ` Michal Simek @ 2021-08-18 5:13 ` AKASHI Takahiro 2021-08-18 9:07 ` Michal Simek 0 siblings, 1 reply; 19+ messages in thread From: AKASHI Takahiro @ 2021-08-18 5:13 UTC (permalink / raw) To: Michal Simek Cc: Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add > >>>>>>>>>>> debug output there to elucidate the problem. > >>>>>>>>>> > >>>>>>>>>> I found where the problem is. First of all zcu102 didn't use the same > >>>>>>>>>> image as others (it wasn't updated properly). > >>>>>>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >>>>>>>>>> is called before usb block devices are detected and registered that's > >>>>>>>>>> why grub doesn't see them. > >>>>>>>>> > >>>>>>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by > >>>>>>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > >>>>>>>>> > >>>>>>>>> Why is USB initialized later then MMC? > >>>>>>>> > >>>>>>>> It is not just usb. SCSI/sata are behaving in the same way too. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Overall we have a deficiency in the UEFI implementation in that we > >>>>>>>>> cannot deal with block devices added or removed after initialization. > >>>>>>>>> > >>>>>>>>> Here integration with the driver model is missing. > >>>>>>>> > >>>>>>>> Right. And also there are commands which can create MBR partitions and I > >>>>>>>> expect when you write image to SD and then run rescan or so you could > >>>>>>>> get other partitions too. > >>>>>>>> Maybe hook via part_init()? with removing efi_disk_register. > >>>>>>> > >>>>>>> For the record, I have proposed my ideas several times[1], [2]. > >>>>>>> I'm, however, no longer working on this issue as I have shifted > >>>>>>> my focus to UEFI secure boot and capsule update. > >>>>>>> > >>>>>>> -Takahiro Akashi > >>>>>>> > >>>>>>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html > >>>>>>> [2] https://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 ### > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-08-18 5:13 ` AKASHI Takahiro @ 2021-08-18 9:07 ` Michal Simek 2021-08-19 4:14 ` AKASHI Takahiro 0 siblings, 1 reply; 19+ messages in thread From: Michal Simek @ 2021-08-18 9:07 UTC (permalink / raw) To: AKASHI Takahiro, Michal Simek, Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add >>>>>>>>>>>>> debug output there to elucidate the problem. >>>>>>>>>>>> >>>>>>>>>>>> I found where the problem is. First of all zcu102 didn't use the same >>>>>>>>>>>> image as others (it wasn't updated properly). >>>>>>>>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >>>>>>>>>>>> is called before usb block devices are detected and registered that's >>>>>>>>>>>> why grub doesn't see them. >>>>>>>>>>> >>>>>>>>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>>>>>>>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>>>>>>>>>> >>>>>>>>>>> Why is USB initialized later then MMC? >>>>>>>>>> >>>>>>>>>> It is not just usb. SCSI/sata are behaving in the same way too. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Overall we have a deficiency in the UEFI implementation in that we >>>>>>>>>>> cannot deal with block devices added or removed after initialization. >>>>>>>>>>> >>>>>>>>>>> Here integration with the driver model is missing. >>>>>>>>>> >>>>>>>>>> Right. And also there are commands which can create MBR partitions and I >>>>>>>>>> expect when you write image to SD and then run rescan or so you could >>>>>>>>>> get other partitions too. >>>>>>>>>> Maybe hook via part_init()? with removing efi_disk_register. >>>>>>>>> >>>>>>>>> For the record, I have proposed my ideas several times[1], [2]. >>>>>>>>> I'm, however, no longer working on this issue as I have shifted >>>>>>>>> my focus to UEFI secure boot and capsule update. >>>>>>>>> >>>>>>>>> -Takahiro Akashi >>>>>>>>> >>>>>>>>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html >>>>>>>>> [2] https://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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-08-18 9:07 ` Michal Simek @ 2021-08-19 4:14 ` AKASHI Takahiro 2021-08-19 5:38 ` Michal Simek 0 siblings, 1 reply; 19+ messages in thread From: AKASHI Takahiro @ 2021-08-19 4:14 UTC (permalink / raw) To: Michal Simek Cc: Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add > >>>>>>>>>>>>> debug output there to elucidate the problem. > >>>>>>>>>>>> > >>>>>>>>>>>> I found where the problem is. First of all zcu102 didn't use the same > >>>>>>>>>>>> image as others (it wasn't updated properly). > >>>>>>>>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >>>>>>>>>>>> is called before usb block devices are detected and registered that's > >>>>>>>>>>>> why grub doesn't see them. > >>>>>>>>>>> > >>>>>>>>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by > >>>>>>>>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > >>>>>>>>>>> > >>>>>>>>>>> Why is USB initialized later then MMC? > >>>>>>>>>> > >>>>>>>>>> It is not just usb. SCSI/sata are behaving in the same way too. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Overall we have a deficiency in the UEFI implementation in that we > >>>>>>>>>>> cannot deal with block devices added or removed after initialization. > >>>>>>>>>>> > >>>>>>>>>>> Here integration with the driver model is missing. > >>>>>>>>>> > >>>>>>>>>> Right. And also there are commands which can create MBR partitions and I > >>>>>>>>>> expect when you write image to SD and then run rescan or so you could > >>>>>>>>>> get other partitions too. > >>>>>>>>>> Maybe hook via part_init()? with removing efi_disk_register. > >>>>>>>>> > >>>>>>>>> For the record, I have proposed my ideas several times[1], [2]. > >>>>>>>>> I'm, however, no longer working on this issue as I have shifted > >>>>>>>>> my focus to UEFI secure boot and capsule update. > >>>>>>>>> > >>>>>>>>> -Takahiro Akashi > >>>>>>>>> > >>>>>>>>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html > >>>>>>>>> [2] https://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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: EFI from usb HDD 2021-08-19 4:14 ` AKASHI Takahiro @ 2021-08-19 5:38 ` Michal Simek 0 siblings, 0 replies; 19+ messages in thread From: Michal Simek @ 2021-08-19 5:38 UTC (permalink / raw) To: AKASHI Takahiro, Michal Simek, Heinrich Schuchardt, Sughosh Ganu, U-Boot Mailing List, Ilias Apalodimas, Simon Glass, Vincent Stehle 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/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Block devices are enumerated in efi_disk_register(). Please, try to add >>>>>>>>>>>>>>> debug output there to elucidate the problem. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I found where the problem is. First of all zcu102 didn't use the same >>>>>>>>>>>>>> image as others (it wasn't updated properly). >>>>>>>>>>>>>> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >>>>>>>>>>>>>> is called before usb block devices are detected and registered that's >>>>>>>>>>>>>> why grub doesn't see them. >>>>>>>>>>>>> >>>>>>>>>>>>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>>>>>>>>>>>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>>>>>>>>>>>> >>>>>>>>>>>>> Why is USB initialized later then MMC? >>>>>>>>>>>> >>>>>>>>>>>> It is not just usb. SCSI/sata are behaving in the same way too. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Overall we have a deficiency in the UEFI implementation in that we >>>>>>>>>>>>> cannot deal with block devices added or removed after initialization. >>>>>>>>>>>>> >>>>>>>>>>>>> Here integration with the driver model is missing. >>>>>>>>>>>> >>>>>>>>>>>> Right. And also there are commands which can create MBR partitions and I >>>>>>>>>>>> expect when you write image to SD and then run rescan or so you could >>>>>>>>>>>> get other partitions too. >>>>>>>>>>>> Maybe hook via part_init()? with removing efi_disk_register. >>>>>>>>>>> >>>>>>>>>>> For the record, I have proposed my ideas several times[1], [2]. >>>>>>>>>>> I'm, however, no longer working on this issue as I have shifted >>>>>>>>>>> my focus to UEFI secure boot and capsule update. >>>>>>>>>>> >>>>>>>>>>> -Takahiro Akashi >>>>>>>>>>> >>>>>>>>>>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/347491.html >>>>>>>>>>> [2] https://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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-08-19 5:38 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-10 8:44 EFI from usb HDD Michal Simek 2021-06-10 9:47 ` Heinrich Schuchardt 2021-06-10 10:04 ` Michal Simek 2021-06-10 10:51 ` Heinrich Schuchardt 2021-06-10 12:31 ` Michal Simek 2021-06-10 12:59 ` AKASHI Takahiro 2021-07-29 14:09 ` Michal Simek 2021-07-30 2:35 ` AKASHI Takahiro 2021-07-30 4:41 ` Michal Simek 2021-07-30 5:33 ` AKASHI Takahiro 2021-07-30 6:22 ` Michal Simek 2021-08-04 10:50 ` Ilias Apalodimas 2021-08-11 12:28 ` Michal Simek 2021-08-12 9:43 ` AKASHI Takahiro 2021-08-17 7:20 ` Michal Simek 2021-08-18 5:13 ` AKASHI Takahiro 2021-08-18 9:07 ` Michal Simek 2021-08-19 4:14 ` AKASHI Takahiro 2021-08-19 5:38 ` Michal Simek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.