From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C35B3C433F5 for ; Fri, 12 Nov 2021 01:51:39 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D622F60F4A for ; Fri, 12 Nov 2021 01:51:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D622F60F4A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6C9BF835B9; Fri, 12 Nov 2021 02:51:36 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="fnfYx7Tx"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8206D83780; Fri, 12 Nov 2021 02:51:34 +0100 (CET) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 55E30835B9 for ; Fri, 12 Nov 2021 02:51:28 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pj1-x102a.google.com with SMTP id gf14-20020a17090ac7ce00b001a7a2a0b5c3so5854375pjb.5 for ; Thu, 11 Nov 2021 17:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=4crd+PmCiPkZfSOMjBOkb2Q8DKCVtqdbZ5U1VdkPiiM=; b=fnfYx7TxEJWyxKtE2TckSat0R1s3r3kEo3ID6dkIlth6iIe34KU8B/b8cC9cQPbBEA oaKsQauLPA8rZ9g27HaERG4uZyaA4/7O93V7apTrRKxupTRVeDqNuadKJtDAfHFIr+j0 CVdkA2TJgtHKm9oh91m1/iyfRPP+KJVK0qkjQ/ckTel3cpDTcTdc3t3rnGIhpJihYHXe /Cvj2ooCGqSIBzqzuNuR0MaXCreNFLWSEc0r/o75GwHrgpnPZ/YNMhdNShcTzg07WOwF QotvoFNCRFx+5T9kxd1MJgKVqD/ZjZqCKRbtZDRZsEl1QdGGDBuzRyPIzJGTNi4hM1RZ 5UiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=4crd+PmCiPkZfSOMjBOkb2Q8DKCVtqdbZ5U1VdkPiiM=; b=ogNzy0qGOgwvQMPI7oQs0KEW1YU+B9nX0lZKWpGVUuNqESo4RjOA7HJlCQyf4LsI/K 8ulZBRK3Yb3HBk7tQ698Jvckk9rr0c6QfdGYzj0B1n0ThuIevg3gGZFjNWgY2HOJ0n8O KoWPKWxnSOHK9SVxklHZO+LtIzQkPFOyvvMv1U7V+cxyWQHvFUsZQ+Bk3K6XaV2wXTe8 E7zJejRcB7VqOqY9CIhbTGdF6hGEhSvt+okFMz7870kKqQTxXrthMeKfoCep7AYaBlPO G3WRyHxp+lIGwb0VldkWAox3XGB517QKJSNneu3E/Vl7nSd3EhNhaRUk3/bwc2IsD7eA xxkA== X-Gm-Message-State: AOAM531RdIqkZfzbD8OUl0TJJWQB/umcLkvHKLd8bQ3BxAygCCpedY5k 6Y1GpBh+KI2RQ+dWYszp4h90zQ== X-Google-Smtp-Source: ABdhPJze10cgdII51643yJ4Vr7kp5f2u4Vce75gNoFbTfWohDozoz7vwysAni55RoHhuf98QPi3/+A== X-Received: by 2002:a17:90b:4c4d:: with SMTP id np13mr13808091pjb.233.1636681886271; Thu, 11 Nov 2021 17:51:26 -0800 (PST) Received: from laputa ([2400:4050:c3e1:100:85c8:7d71:e414:974a]) by smtp.gmail.com with ESMTPSA id z71sm4527260pfc.19.2021.11.11.17.51.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Nov 2021 17:51:25 -0800 (PST) Date: Fri, 12 Nov 2021 10:51:22 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: Marek Vasut , agraf@csgraf.de, sjg@chromium.org, ilias.apalodimas@linaro.org, u-boot@lists.denx.de Subject: Re: [RFC 3/3] cmd: efidebug: handle booting from removable media Message-ID: <20211112015122.GA10814@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , Marek Vasut , agraf@csgraf.de, sjg@chromium.org, ilias.apalodimas@linaro.org, u-boot@lists.denx.de References: <20211109013233.72902-1-takahiro.akashi@linaro.org> <20211109013233.72902-4-takahiro.akashi@linaro.org> <20211110062433.GC54635@laputa> <66353088-caad-7953-6a12-eded28576c3d@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Wed, Nov 10, 2021 at 10:17:50AM +0100, Heinrich Schuchardt wrote: > On 11/10/21 09:11, Heinrich Schuchardt wrote: > > > > > > On 11/10/21 07:24, AKASHI Takahiro wrote: > > > On Tue, Nov 09, 2021 at 10:50:37AM +0100, Heinrich Schuchardt wrote: > > > > On 11/9/21 02:32, AKASHI Takahiro wrote: > > > > > Support for booting from removable media is now added to UEFI boot > > > > > manager. Here we should modify efidebug command in order to define > > > > > a proper "BootXXXX" variable. > > > > > > > > > > With this patch applied, you will be able to specify the boot order, > > > > > usb and scsi: > > > > > > > > I guess for a removable device this should work even if the > > > > device is not > > > > present. But currently: > > > > > > > > => efidebug boot add -b 1000 USB_present usb 0:1 EFI/BOOT/BOOTARM.EFI > > > > => efidebug boot add -b 1000 USB_not_present usb 1:1 > > > > EFI/BOOT/BOOTARM.EFI > > > > Cannot create device path for "usb 1:1" > > > > > > # In the second, I don't expect you to specify the file path, > > > # "EFI/BOOT/BOOTARM.EFI", for removable media support. > > > > > > Yes, I have been aware of this issue but it is not this-patch specific > > > but an existing issue as you clearly mentioned above. > > > > > > > A media device path like: > > > > > > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0x0c449046,0x800,0x800) > > > > > > > > > > > > is not very helpful because the next device that you insert may have a > > > > different location of the ESP partition. > > > > > > > > I think you should store > > > > > > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0) > > > > > > > > > > Apparently it is promising but actually not because > > > "UsbClass(0x781,0x5571,0x0,0x0,0x0)" contains Vendor ID and > > > Product ID which can only be retrieved from a real device attached > > > to the board. > > > > 0x781,0x5571 relates to > > Vendor: SanDisk Corp. > > Device: Cruzer Fit > > > > This is how Linux sees my OrangePi PC: > > > > $ lsusb > > Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Bus 006 Device 002: ID 0781:5571 SanDisk Corp. Cruzer Fit > > Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > > > The bus numbering seems not to be stable: > > > > $ lsusb > > Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Bus 005 Device 002: ID 0781:5571 SanDisk Corp. Cruzer Fit > > Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > > > > > And this is in U-Boot: > > > > usb           0  [ + ]   ehci_generic          |   |-- usb@1c1a000 > > usb_hub       0  [ + ]   usb_hub               |   |   `-- usb_hub > > usb           1  [ + ]   ohci_generic          |   |-- usb@1c1a400 > > usb_hub       1  [ + ]   usb_hub               |   |   `-- usb_hub > > usb           2  [ + ]   ehci_generic          |   |-- usb@1c1b000 > > usb_hub       2  [ + ]   usb_hub               |   |   `-- usb_hub > > usb           3  [ + ]   ohci_generic          |   |-- usb@1c1b400 > > usb_hub       3  [ + ]   usb_hub               |   |   `-- usb_hub > > usb           4  [ + ]   ehci_generic          |   |-- usb@1c1c000 > > usb_hub       4  [ + ]   usb_hub               |   |   `-- usb_hub > > usb_mass_s    0  [ + ]   usb_mass_storage      |   > > |       `-- usb_mass_storage > > blk           1  [   ]   usb_storage_blk       > > |   |           `-- usb_mass_storage.lun0 > > usb           5  [ + ]   ohci_generic          |   |-- usb@1c1c400 > > usb_hub       5  [ + ]   usb_hub               |   |   `-- usb_hub > > usb           6  [ + ]   ehci_generic          |   |-- usb@1c1d000 > > usb_hub       6  [ + ]   usb_hub               |   |   `-- usb_hub > > usb           7  [ + ]   ohci_generic          |   |-- usb@1c1d400 > > usb_hub       7  [ + ]   usb_hub               |   |   `-- usb_hub > > > > The location where a USB is plugged is identified by the port of the USB > > hub it is connected to. > > > > I think before we can properly support removable media we will have to > > get the UEFI device path right. We need a node on all of the levels of > > the DM tree of which more than one instance can exist. > > Here is an example of device path created by an AMI BIOS for an ESP > partition on a USB stick: > > PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x1)/USB(0x2,0x0)/USB(0x3,0x0)/HD(1,GPT,1AD3DE75-504A-47DF-A5CE-81D9EF0252A2,0x40,0x55D824) > > The two number in PCI(foo, bar) are: > PCI device > PCI function > > The two numbers in USB(foo, bar) are: > USB Parent Port Number > USB Interface Number > > By using USB() instead of USBClass() the device path becomes generic. If you > plug in a device from a different vendor into the same USB port, you will > get the same device path for the device. Only the partition information may > change. I agree here as it is what I have mentioned in my reply. My concern is that we may not be able to create such a detailed device path from DM representation. For example, "usb 0:1" doesn't contain any information on usb ports or interfaces. -Takahiro Akashi > Best regards > > Heinrich > > > > > > > > > I'm not yet sure where "UsbClass(0x0,0x0,0x9,0x0,0x1)" comes from. > > > > > > "USB(X, Y)", where X is a parent_port_number and Y is a usb_interface, > > > would be a more appropriate candidate for this kind of device path, > > > but we don't utilise this form in the current implementation. > > > > > > > and find the ESP on it at runtime. > > > > > > I don't think the specification requires that the disk is an ESP > > > (at least explicitly). > > > > > > > > > > > => efidebug -b 1 SCSI scsi 0:1 > > > > > => efidebug boot dump > > > > > Boot0001: > > > > > attributes: A-- (0x00000001) > > > > >     label: SCSI > > > > >     file_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/ > > > > > > Contrary to USB, we use Scsi(0,0) for scsi devices but it is NOT > > > identical > > > to U-Boot's scsi0 (in boot_targets). > > > > > > > >     HD(1,GPT,0ed48d12-1b4c-4e08-b3ee-decf20428036,0x800,0xa000) > > > > >     data: > > > > >       00000000: 00 00 > > > > > => efideubg -b 2 USB usb 0:1 > > > > > > > > efidebug > > > > > > OK > > > > > > -Takahiro Akashi > > > > > > > Best regards > > > > > > > > Heinrich > > > > > > > > > => efidebug boot order 2 1 > > > > > => bootefi bootmgr > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > --- > > > > >    cmd/efidebug.c | 46 ++++++++++++++++++++++++++++++++++++++++------ > > > > >    1 file changed, 40 insertions(+), 6 deletions(-) > > > > > > > > > > diff --git a/cmd/efidebug.c b/cmd/efidebug.c > > > > > index a977ca9c72f5..aaf269cdf47d 100644 > > > > > --- a/cmd/efidebug.c > > > > > +++ b/cmd/efidebug.c > > > > > @@ -933,6 +933,29 @@ out: > > > > >        return initrd_dp; > > > > >    } > > > > > +/** > > > > > + * count_arguments - count the number of arguments > > > > > + * @argc:    Total number of arguments > > > > > + * @argv:    Argument array > > > > > + * Return:    Number of arguments > > > > > + * > > > > > + * Count the number of arguments for a given option, "-?" > > > > > + * Specifically if the first argument is not "-?", return 0; > > > > > + */ > > > > > +static int count_arguments(int argc, char *const argv[]) > > > > > +{ > > > > > +    int i; > > > > > + > > > > > +    if (argv[0][0] != '-') > > > > > +        return 0; > > > > > + > > > > > +    for (i = 1; i < argc; i++) > > > > > +        if (argv[i][0] == '-') > > > > > +            break; > > > > > + > > > > > +    return i; > > > > > +} > > > > > + > > > > >    /** > > > > >     * do_efi_boot_add() - set UEFI load option > > > > >     * > > > > > @@ -945,7 +968,7 @@ out: > > > > >     * > > > > >     * Implement efidebug "boot add" sub-command. Create > > > > > or change UEFI load option. > > > > >     * > > > > > - * efidebug boot add -b