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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 8C1E7C433F5 for ; Sat, 19 Feb 2022 01:51:25 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7D81783A8E; Sat, 19 Feb 2022 02:51:22 +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="ppOT2dzB"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3ADF683B93; Sat, 19 Feb 2022 02:51:20 +0100 (CET) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 A3C7883A2B for ; Sat, 19 Feb 2022 02:51:16 +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-x102f.google.com with SMTP id n19-20020a17090ade9300b001b9892a7bf9so13838430pjv.5 for ; Fri, 18 Feb 2022 17:51:16 -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:in-reply-to; bh=QzWtV2SZLCLu2T0yHQO//TC2cXAkGCzkg8Yf5Bxv6uM=; b=ppOT2dzBFe0mLtOqwFHEijysMzxYy+I/kamLz5rgZ82fLV5OJHCk1l+e+Fg9hgfS5R fKa234hwt0c8OE7jaPNtcZpaJD8HXyUdsISoVzFi/gTki8NagdmsyM4zTZMQUZva4yII W9aHYeRT7Eazg1HFfqSDAc+kVW/LI95Nf9CVZIMarZ9o4CS2ie2ZdHEYNSeTIQHyemip 0QfbMd5hRCxTlq5wZf3BCeg1VLPeew2FoC134D2cHIUb1Mk3HA53RO6r1IzdFvBzi758 RHINNYmlCmcJ0NL9JDQa1+8syRTmnWtR+CuB2x56RhZtqAjQjiNyRruaUsYyficvGtLZ 631g== 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 :in-reply-to; bh=QzWtV2SZLCLu2T0yHQO//TC2cXAkGCzkg8Yf5Bxv6uM=; b=3/xh1yqWk1UN8MU0Uf4UTSC9EFJms7ZWXc0ygEUQrCQBCr/vsOqbEl27iVdvEzoae5 G03z4WY1fUT9+5I3qQQyxAK1JT56RKiTao/uB3WE4Fj2a8JQ7AMAULms6EjTmJ1lEmkO g8MXThsFf0Xx7AjVBhYRc5m3J4Ip69NRFW7O+n7HbSnHWEzo/PIUd72BTnH6XuDsX4gQ 4xbq0vAlAFsGwvZBhmeKIejXte4JmFHE/HWvJLkOIoEpisIeZqfpD8hBxht1s7zwxwxx 80moH2dUJLYFtdKfXyDjGFSlC/YUu6Jib4V45zs58F2OCmrjO2D1ksxn2SMw35rXXFQ8 PoFA== X-Gm-Message-State: AOAM530VDg39Hcm1j4pHAvkOyEpvT/0De0Hj09rPLhLYhLMbZcAHMRKj uKCWFgHgjVJwlX7tWNQaXKQXFwkLP83jbrfp X-Google-Smtp-Source: ABdhPJwHXNMB5ZtqsqXTr7COiDkYpSooGTUFJP4F0qYbLkpKEgsEDcC/VjgMUYx3vC3+FXtiC+GgGg== X-Received: by 2002:a17:902:f687:b0:14d:6bde:d192 with SMTP id l7-20020a170902f68700b0014d6bded192mr9755037plg.133.1645235474962; Fri, 18 Feb 2022 17:51:14 -0800 (PST) Received: from laputa ([2400:4050:c3e1:100:ac97:9e25:a038:e389]) by smtp.gmail.com with ESMTPSA id s29sm4681247pfg.146.2022.02.18.17.51.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Feb 2022 17:51:14 -0800 (PST) Date: Sat, 19 Feb 2022 10:51:10 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: Tom Hale , u-boot@lists.denx.de, Ilias Apalodimas , Tom Rini Subject: Re: Boot from specified partition (or FS) UUID without knowing Device ID Message-ID: <20220219015110.GC6672@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , Tom Hale , u-boot@lists.denx.de, Ilias Apalodimas , Tom Rini References: <6587586c-a873-4023-f29d-ec84bcac5ddc@hale.ee> <20220218170731.GD1576803@bill-the-cat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean On Fri, Feb 18, 2022 at 06:41:18PM +0100, Heinrich Schuchardt wrote: > On 2/18/22 18:07, Tom Rini wrote: > > On Fri, Feb 18, 2022 at 02:01:41PM +0700, Tom Hale wrote: > > > > > I want to have a fallback boot situation where boot is first tried from one > > > partition, and then from another partition (on a different device) if the > > > first partition isn't available (eg, if the first device fails). > > > > > > Can I boot from a specific FS UUID or a partition UUID without knowing a > > > particular device ID? (I'm not sure if my devices will always be detected > > > in a repeatable order). > > > > > > Can fatload be used with only a partition UUID? Or can I somehow get the > > > dev number from the UUID? > > The UEFI boot manager uses device paths which comprise the partition > GUIDs. Currently we use the full device path. > > Windows and efibootmgr just store the partition and the file path in > boot options and non-U-Boot UEFI implementation will work fine with What do you mean by "efibootmgr"? It sounds to be the name of U-Boot's implementation of UEFI Boot Manager. > this. E.g. > > HD(2,GPT,12345678-1234-5678-ABCD-123456789ABC,0x109000,0x32000)/File(\EFI\debian\shimx64.efi) This is called a short path and already supported in U-Boot UEFI implementation. See efi_dp_find_obj(). > I think this approach should also be adopted for U-Boot when the file is > on a GPT partition. To be clear, setting a device path in a boot option is not boot manager's responsibility, but efidebug's, at least for now. So even now, if efidebug is modified to allow for a short path, it should work with current "efibootmgr" (although I have never tried it before). # FYI, the current implementation of creating a "full" device path from # U-Boot's probe mechanism/DM has a fatal problem of uniqueness. I have # mentioned the issue partially in my "removable media" support RFC but # will have to address it fully in the future. -Takahiro Akashi > Would this solve your problem? > > Best regards > > Heinrich > > > > > As UUIDs are unique per device but our device probe order is (nominally, > > there's counter examples) static, this would be a more board specific > > way of going than knowing which media is which device. > > >