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 46666C4167B for ; Mon, 19 Dec 2022 10:52:42 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D2C0884FBF; Mon, 19 Dec 2022 11:52:39 +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="GzgQOizA"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5941985016; Mon, 19 Dec 2022 11:52:37 +0100 (CET) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 17C5A84913 for ; Mon, 19 Dec 2022 11:52:33 +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=ilias.apalodimas@linaro.org Received: by mail-ej1-x635.google.com with SMTP id qk9so20508338ejc.3 for ; Mon, 19 Dec 2022 02:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GQEC1BS5i+tcaHS3KiTTA2u5Jb1XkJb/FP1ZPocvfRo=; b=GzgQOizAGEa95jeWuBEh4Gtnh0ixmaEP6jfMnVa+6OQbOwyYizkXAJ+Tdh9XlnY5Ej w7ERI2iMrjcTxlMwqD84C2VENLD2z64vJJCn74YxQf0RO3+sWCRonBPv0bShPQNy2Zzn 9r3v8A0C8sSnT97Ml50zrzvWEZ2iYaUAS0RrpbImFbTpiUpHXlNSIKMmuFUWlZfghSFC UIKaFjl2GDIucR6Fgtkx0eLOo6qonsDto2Xy4Xv6Hqv3gL4O3B/5uDoF2mepg/p+9X9O x/1oN0uP7AuEDaJ/M9cNhTGoaN4cTtzd7Fh7NdNQVs2xNx+86Ndd1mlak/VYsl4ZyuDZ lfmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GQEC1BS5i+tcaHS3KiTTA2u5Jb1XkJb/FP1ZPocvfRo=; b=sAh3Oa7V/iAEek3VYHxUr8zXGElfUWYgsGALGEwaMegFNGYJ4ZQF51ZOdGqe+RRLi9 y/P7YImJFTxlrfqS1BBSXVeoz2akhn3rI4EQn7iJaImWxz5jOOK+XR/PEWjBiSFBnReC 27a/+KP7XmmIDYTX/ot/J4gdFpunEaAqdxV06ZAPt5nPXwcQsLEKqouqRyg4nciLXi5Z Wu7R/fVDEu4IQ9CQ5tFPR1qUBL/bv9hmwku4RuIcqFQqsE6yG2mW9IKBtuGAuwXzmlBL km9nuTqD6zpglfKsH8wKheWrtJjtA9606gadXHTrdEtJRb1SG6ES0BTHDy9+dPMH93iP LMKQ== X-Gm-Message-State: ANoB5plxGv7YA1e1mF1vAQ/fjN7mf+zRT5zPZW16pwSy/JLKS/fcLNm8 1RQCijCg/ZZbxg7k1loG0tVMyA== X-Google-Smtp-Source: AA0mqf425ynRI5vBPUsI9ly323mvxPz9yrY+oAtZsEkmY6NTMPbBSvvgKEe8AgGULW8Sze/VfxvDCw== X-Received: by 2002:a17:906:f1cb:b0:7c1:2529:b25e with SMTP id gx11-20020a170906f1cb00b007c12529b25emr38155991ejb.43.1671447152662; Mon, 19 Dec 2022 02:52:32 -0800 (PST) Received: from hades (ppp078087234022.access.hol.gr. [78.87.234.22]) by smtp.gmail.com with ESMTPSA id i4-20020a170906250400b0078d22b0bcf2sm4182180ejb.168.2022.12.19.02.52.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Dec 2022 02:52:32 -0800 (PST) Date: Mon, 19 Dec 2022 12:52:30 +0200 From: Ilias Apalodimas To: Janne Grunau Cc: Heinrich Schuchardt , Mark Kettenis , u-boot@lists.denx.de, sjg@chromium.org, marcan@marcan.st Subject: Re: RFC: Handling of multiple EFI System Partitions Message-ID: References: <878rj44wtp.fsf@bloch.sibelius.xs4all.nl> <7FDA0F19-CF1D-4897-A338-DE043E980622@gmx.de> <20221219094817.GA4629@jannau.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221219094817.GA4629@jannau.net> 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.6 at phobos.denx.de X-Virus-Status: Clean Hi Janne, [...] > > >function that can be called from board-specific code that sets the > > >UUID. > > > > > >Thoughts? Would such a feature be useful on other hardware > > >platforms? > > > > efi/boot/bootaarch64.efi is only a fallback if load options are not > > set up. Once the operating system has generated a load option it is > > not used anymore. > > Setting load options from operation systems is currently not > implemented. The only readily available method to store variables is a > file in the ESP. This obviously can not be supported as UEFI runtime > service while the operation system is using the same disk. Yes, but I'd skip the 'currently not implemented' part. If you store your EFI variables in a file on the ESP, we will *never* be able to (sanely) support SetVariable at runtime. > It might be possible to use NOR flash as UEFI variable store. This could > cause issues with the primary boot loader iboot which we can not avoid > or with macOS in dual boot configurations. It is possible. In fact we already have code in U-Boot that stores the EFI variables in an RPMB partition of the eMMC. We also have (unfortunately not yet upstreamed) code that stores the in an i2c eeprom in the secure world. This is again situational though and none of these applies to MBPs. SetVariable at runtime in an RPMB comes with it's own set of problems. You basically need to replace the runtime services with OS provided ones... The I2C one works fine. But letting the implementation details aside, what we need to keep in mind, is that being able to support SetVariable-RT primarily depends on the *hardware* and there's gonna be hardware we'll never be able to support this. > > > The MacBooks only have one drive. Why would you want two ESPs on one > > drive? > > The lack of support for setting boot variable form the operating system > makes it hard to support multiple OS with a single ESP. The systems > comes with an accessible graphical boot picker which should be preferred > over an u-boot based boot manager. Accessibility and the ability to boot > macOS are the most important advantages. > > At the current stage an u-boot based boot manager is not a viable option > since the devicetree can not be guaranteed to be backwards compatible. > The most recent breaking change was the addition of a phy phandle > reference for USB controller nodes for USB3 support. Older kernel will > obviously miss a driver for the phy and at least on Linux the USB > controller will not be initialized. This breaks USB completely. > > The devicetree is transformed by the loader before u-boot in a > non-trivial way. If u-boot were to use kernel version specific DTB > templates from the ESP it would require a non-trivial amount of code to > update the template by the information added by the loader. > > > Why can't the Asahi team use the current UEFI bootflow? We should > > avoid unneeded deviations. Can the current deviations be removed in > > Asahi Linux? > > See above, the main reason is the lack of support for setting UEFI > variables at runtime from operating systems. Even if that those were > supported it's impossible to upgrade all installed operating systems > when the devicetree changes in a non backward compatible way due to > additional hardware support. > Ok fair enough, I'll talk to Heinrich and see if The current idea from Mark can be wired up without causing too much of a mess. > At the current stage it is not possible to support UEFI bootflow. > > Best regards > > Janne Cheers /Ilias