* 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.