public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Michal Simek <michal.simek@xilinx.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Sughosh Ganu <sughosh.ganu@linaro.org>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Simon Glass <sjg@chromium.org>
Subject: Re: EFI from usb HDD
Date: Thu, 10 Jun 2021 21:59:15 +0900	[thread overview]
Message-ID: <20210610125915.GA96492@laputa> (raw)
In-Reply-To: <e0bbf987-2ebe-df83-0f53-9c5d7b0a255e@xilinx.com>

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

  reply	other threads:[~2021-06-10 12:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210610125915.GA96492@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=michal.simek@xilinx.com \
    --cc=sjg@chromium.org \
    --cc=sughosh.ganu@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox