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 A444DC0032E for ; Wed, 25 Oct 2023 20:28:11 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C6F1C87503; Wed, 25 Oct 2023 22:28:09 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=xs4all.nl 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; secure) header.d=xs4all.nl header.i=@xs4all.nl header.b="e1E7hT9F"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 18932879E7; Wed, 25 Oct 2023 22:28:09 +0200 (CEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id F23948721C for ; Wed, 25 Oct 2023 22:28:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mark.kettenis@xs4all.nl X-KPN-MessageId: f975bd3d-7374-11ee-90ec-00505699b430 Received: from smtp.kpnmail.nl (unknown [10.31.155.5]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id f975bd3d-7374-11ee-90ec-00505699b430; Wed, 25 Oct 2023 22:27:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=xs4all01; h=subject:to:from:message-id:date; bh=VhboRP5DNGBGEc9JJWis7/dpZ/1SqRVhblHA8Csox6c=; b=e1E7hT9FDYHaFvGFQrDS6VpWFg1RsXEpY5iuX8e/TkWgWLzG6mrs56OevLSGNN8RZpQaq8IcuiGQl K51ivoWRdSMY1Qye608H7SluwirIi+YgH34KXl0xWx5DL0L2I4uBRJjOm+FPpf5vzggAwJGsqoC7DQ TvVg8s64/M8y8raxlxXRrwwj70oOSn+MeVDYHuLNjp858kOLRaAw/FBKZWhdpZ4JnPjq1lkpqiH/rm NGOwNN86HCvFTjQPXa0elbDsmib9mJpZeHMk65xDXxcbGeNjrv2p27MRm7Lkdau3anPRTRZFwARPYR FJQQsW2j4q4m99qp/RK+6Nh065KRsgQ== X-KPN-MID: 33|3Tt8Md3i5y90gIqT/ghW59UnxruDF8YBtubViH+X0I6LYD6XsoGuvkJ/zbsrWsV 4EuGeCSo+oQIndLqxtxGhd8TAUT24fasJc3QEKi9HVFA= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|MNe6RoBB8vEgejZOQZPj0MFZO190uUCXbnmJu7bmgPfHWQdSromk1Pv76qb929s 0cxLdUh5/J0N/9vNLI7dNfQ== X-Originating-IP: 80.61.163.207 Received: from bloch.sibelius.xs4all.nl (80-61-163-207.fixed.kpn.net [80.61.163.207]) by smtp.xs4all.nl (Halon) with ESMTPSA id 00842601-7375-11ee-ac7a-00505699b758; Wed, 25 Oct 2023 22:28:06 +0200 (CEST) Date: Wed, 25 Oct 2023 22:28:05 +0200 Message-Id: <87a5s6qwfe.fsf@bloch.sibelius.xs4all.nl> From: Mark Kettenis To: Heinrich Schuchardt Cc: sjg@google.com, ilias.apalodimas@linaro.org, u-boot@lists.denx.de, trini@konsulko.com In-Reply-To: <1ac5013d-8991-4abd-baad-94776801c58c@canonical.com> (message from Heinrich Schuchardt on Wed, 25 Oct 2023 21:57:44 +0200) Subject: Re: [PATCH v4 1/1] efi_loader: expose the device-tree file name References: <20231024062032.8543-1-heinrich.schuchardt@canonical.com> <1ac5013d-8991-4abd-baad-94776801c58c@canonical.com> 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.8 at phobos.denx.de X-Virus-Status: Clean > Date: Wed, 25 Oct 2023 21:57:44 +0200 > From: Heinrich Schuchardt > > On 10/25/23 20:23, Simon Glass wrote: > > Hi Heinrich, > > > > On Tue, 24 Oct 2023 at 18:02, Simon Glass wrote: > >> > >> Hi Heinrich, > >> > >> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt > >> wrote: > >>> > >>> Forward and backward compatibility of Linux kernel device-trees is > >>> sometimes missing. One solution approach is to load a kernel specific > >>> device-tree. This can either be done via a U-Boot scripts (like the one > >>> generated by Debian package flash-kernel or by a boot loader like GRUB. > >>> The boot loader approach currently requires to know the device-tree name > >>> before first boot which makes it unusable for generic images. > >>> > >>> Expose the device-tree file name as EFI variable FdtFile. > >>> This will allow bootloaders to load a kernel specific device-tree. > >> > >> kernel-specific > >> > >>> > >>> The variable will not be exposed on ACPI based systems or if the > >>> environment variable fdtfile is not defined. > >>> > >>> Signed-off-by: Heinrich Schuchardt > >>> --- > >>> v4: > >>> Generalize the description of the content of $fdtfile. > >>> v3: > >>> Add documentation > >>> v2: > >>> Use a unique GUID to enable future U-Boot independent > >>> standardization. > >>> Do not try to add the variable on ACPI based systems. > >>> --- > >>> doc/develop/uefi/uefi.rst | 14 ++++++++++++++ > >>> include/efi_loader.h | 5 +++++ > >>> lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++ > >>> 3 files changed, 49 insertions(+) > >>> > >>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > >>> index fb16ac743a..702c490831 100644 > >>> --- a/doc/develop/uefi/uefi.rst > >>> +++ b/doc/develop/uefi/uefi.rst > >>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is:: > >>> > >>> Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff) > >>> > >>> +EFI variable FdtFile > >>> +~~~~~~~~~~~~~~~~~~~~ > >>> + > >>> +Ideally U-Boot would always expose a device-tree that can be used for booting > >>> +any operating systems. Unfortunately operating systems like Linux sometimes > >>> +break forward and backward compatibility. In this case there is a need to load > >>> +an operating system version specific device-tree. > >> > >> This seems to be a strong statement. Given the effort that goes into > >> the DT, changes are supposed to be backwards-compatible. Is this > >> generally true, or is it just that we want an up-to-date DT for the > >> kernel to enable new features? > > > > Did you see this comment? > > It would have been nice to put the person which made that comment on copy. > > The truth lies in the world "supposed": > > The idea of a device-tree that never needs to change is quite old and > never became true on ARM devices. > > We all know Linux tends to break both forward and backward compatibility > of device-trees. Here is a nice example: > > d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode > rgmii-id") > > Driver changes broke forward and backwards compatibility of a lot of > Allwinner boards. Well, that happened in 2020. Things have gotten better over time. > Distros will continue to load the device-tree that matches the kernel to > get the best possible board support and need to do this efficiently. Right. Even if there is full backward/forward compatibility, you probably want the latest device-tree to make sure you get the most complete hardware support. But this shouldn't be used as an argument to not care about backward/forward compatibility.