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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC49DC433F5 for ; Fri, 10 Sep 2021 10:28:48 +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 F2539610C8 for ; Fri, 10 Sep 2021 10:28:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F2539610C8 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 AD37D83633; Fri, 10 Sep 2021 12:28:44 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (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=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="NBk6d2xQ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3E2AF83634; Fri, 10 Sep 2021 12:28:42 +0200 (CEST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 BB3F183629 for ; Fri, 10 Sep 2021 12:28:36 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francois.ozog@linaro.org Received: by mail-ej1-x62a.google.com with SMTP id kt8so3208564ejb.13 for ; Fri, 10 Sep 2021 03:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kjPm2C893mkUgyt14fCPKVddEKZ00ToBrqdyVPq5O9U=; b=NBk6d2xQsz7f+ST8aykys8qaQUB9BSrySaVbnQhBYaZ1lo1JbeT0KQlExiYvsrXivn O8txIzZE+xP15lAuJItJkcmF/3s1TywRvoP+U+HnKkqyrv/vqEITHFlJGFEitkaZsGIX IcPI14S1OnJpyzd+61H/BzE/APSoDKl0bYvyLvZDEDxtveyTvDPECVM4lURfaXK+5LYw op2GqZNsC8fLj7njhNqLGpLCBdhqlBClHY9E/Pas5Qw/9Ek0Hx/ROScqFqG6+sJMxgQD s3kD6hiSzvt7DyRAqan1O1r2GMk0bDUGyEsxgexCFgFonzYYERD2ySdd7gj5KYenD+xE SbAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kjPm2C893mkUgyt14fCPKVddEKZ00ToBrqdyVPq5O9U=; b=fjy2OswVUW2+gag2kl6wlTM49GKcYv9SeVCYC6UdSrXJu3Y9PS2GQOzflfx2dNfOOW EcE979wZrOddLJKP1sDlhuUUEkz2ENl/LeyFkyXxZ+uUYaeHzE8dbvjFg9wBO3WRbcSk dE6zhgncCsUnpo0QCf3L5FXM/oM6FZQuZMAq1JEa7dA/Dhh7JRtUys/+76ACfTB63J1e 4Ml1QE7bpopP+FYWviCtiofkeB49ILBCEhnsJwmgqIrxGcxm7KsWlrEoxOPXTOoBMbr7 tOFD8FOsaO1FxDv98DQ2Y/PdKEBsax/wvwB3ivKNh0S4ztlGx+7JUGqDktKsluNb/7PQ Z4bg== X-Gm-Message-State: AOAM531D3EBCt2yv0CvUdIy/X+VglVxC5lD2H7aWDVm5SntDY/xR7iZU wCStoRMoq9/BoR5VwCwEjRApbyWuY/65BlTyese4LQ== X-Google-Smtp-Source: ABdhPJyohTtpHzjgXhwiDpLz9hlvLoR38N+R9XxtzJi1qvYxFQG/e+FVTJbF6hd+e+O5U1fXlFAsyJZCWdb36DKW/7A= X-Received: by 2002:a17:906:adb:: with SMTP id z27mr8759391ejf.235.1631269716185; Fri, 10 Sep 2021 03:28:36 -0700 (PDT) MIME-Version: 1.0 References: <61e2e1cc-b474-84dd-eceb-bb86a59972be@gmx.de> <20210904130111.GA12964@bill-the-cat> <20210904143722.GD12964@bill-the-cat> <46CAD3CD-41FA-43B9-9099-225711B754E1@gmx.de> <20210904173949.GI12964@bill-the-cat> <8FD4F99B-E1A5-4842-8BB8-EA2749E4761B@gmx.de> <146342ea-08a3-ec4a-535c-5bcecd54675a@gmx.de> <20210909120808.GY12964@bill-the-cat> <56144ce05709c110@bloch.sibelius.xs4all.nl> In-Reply-To: <56144ce05709c110@bloch.sibelius.xs4all.nl> From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Fri, 10 Sep 2021 12:28:25 +0200 Message-ID: Subject: Re: Pull request for efi-2021-10-rc4 To: Mark Kettenis Cc: Simon Glass , Tom Rini , Heinrich Schuchardt , U-Boot Mailing List , Alexander Graf , Masahisa Kojima , Ilias Apalodimas , Takahiro Akashi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 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 Thu, 9 Sept 2021 at 23:22, Mark Kettenis wrote= : > > From: Simon Glass > > Date: Thu, 9 Sep 2021 14:08:24 -0600 > > Hi Simon, > > > Hi Tom, > > > > On Thu, 9 Sept 2021 at 06:08, Tom Rini wrote: > > > > > > On Thu, Sep 09, 2021 at 12:52:52PM +0200, Heinrich Schuchardt wrote: > > > > > > > > > > > > On 9/9/21 10:56 AM, Simon Glass wrote: > > > > > Hi Heinrich, > > > > > > > > > > On Sat, 4 Sept 2021 at 12:08, Heinrich Schuchardt < > xypron.glpk@gmx.de> wrote: > > > > > > > > > > > > It is Simon's concept of blobs in devicetrees that is borked in > that it ignores QEMU and any board that gets the DT from a prior boot sta= ge. > > > > > > > > > > That's because I was completely unaware of this strange back-door > > > > > approach. It would have helped a lot if someone had bothered to > create > > > > > > > > CONFIG_OF_PRIOR_STAGE is not a backdoor. And you are the DM > maintainer. > > > > > > > > > some documentation for the design. Then I would have seen the > problem > > > > > immediately. > > > > > > > > > > Anyway, it is now covered by the above series. The use of > devicetree > > > > > in U-Boot is very clear, I think. > > > > > > > > I see neither a design by you nor a series that covers > > > > CONFIG_OF_PRIOR_STAGE. I have suggested that if you really want to > move > > > > this blob to a devicetree you could apply an overlay tree including > > > > U-Boot specific fields to the devicetree of the prior stage. Did yo= u > yet > > > > respond to this? > > > > > > Given that I feel like "u-boot,dm-spl" and "u-boot,dm-pre-reloc" are > > > unlikely to survive upstream review, I would like to hear what you > think > > > about applying overlays, at least in general, Simon. > > > > I would be pretty disappointed if vendor,propname could not survive > > upstream review, given that it is in the DT spec explicitly, and that > > linux, is used in Linux. > > Well, the Linux DT maintainers tend to be pretty thorough in their > review and will resist crappy ideas ;). I think there is merit in the > way we currently do things by augmenting the standard Linux device > tree with these properties. At least on platforms where U-Boot is the > first bit of firmware that runs (apart from ROM code). But I suspect > there would be some resistence if we proposed to add these properties > directly to the upstream Linux DTs instead. > > On the other hand I don't see why maintainers of firmware that runs > before U-Boot that provides a DT to U-Boot through a > CONFIG_OF_PRIOR_STAGE mechanism would never add "u-boot," properties > to their device trees if they use U-Boot as a 2nd stage loader. I'm > sure the device trees providied by m1n1 for the Apple M1 could contain > additional nodes and "u-boot," properties if necessary. > > > To answer your question, I think it is a terrible idea and would lead > > to much pain and misery and eventually the failure of U-Boot to > > function as a useful and efficient bootloader . It moves something > > that I think can be easily accomplished (from a technical POV anyway) > > at built-time into the run-time domain. Leaving aside that devicetree > > overlays are arguably not supported/implemented so far as the DT spec > > is concerned, it adds overhead to SPL and U-Boot (particularly > > pre-reloc) that is likely to make the whole thing infeasible. > > I still think that U-Boot TPL/SPL isn't an issue for platforms that > use CONFIG_OF_PRIOR_STAGE. The QEMU example that was given is a bit > artificial in that it is a configuration specifically designed for > testing U-Boot SPL. Folks using a QEMU-based virtualization solution > don't care about that configuration and will only use U-Boot proper. > > > Also, somewhat off-topic, this is the first I have ever heard of the > > idea of U-Boot needing to put its properties in a separate place. I > > tried to cover this in 'Why not have two devicetrees?' here: > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210828164630.81050-4-s= jg@chromium.org/ > > > > How hard do we really want to make this? If a DT is provided to > > U-Boot, it needs to be suitable for U-Boot. > > But U-Boot must not make unreasonable demands. > > > The whole idea is driven from a misconception that U-Boot is just > > borrowing a devicetree from Linux or qemu or TF-A. > > I diasagree that's a misconception. I've already explained why it > isn't practical for U-Boot to have hardwired device trees for things > like QEMU, Raspberry Pi or Apple M1. I also don't see what specific > U-Boot cofiguration is needed for those platforms. Currently U-Boot > functions just fine with on these platforms without having any > "u-boot," properties in the DT they provide to U-Boot. Granted, I'm > not trying to do any sort of verified/secure boot on those platforms. > But any meaningful verified/secure boot implementation needs a high > degree of agreement between the integrated firmware components anyway. > +1 Let's also take the example of PSCI interface. This may be offered by SCP firmware sitting on an external micro-controller or by OP-TEE Trusted Application or intercepted by Qemu. Let's assume the piece of code offering the PSCI interface change and offer a new version of API. Current situation in most boards: you have to sync up all projects (TFA, OP-TEE, U-Boot, Linux) with that new information. The forward and backward compatibilities are a problem. Desired situation: a single authoritative entity (TFA? U-Boot?) is using a platform specific way to sense the offered API and conduit and injects it in the DT. > > > So to the extent that this implies that U-Boot cannot have its own > > properties and nodes in the devicetree; > > > > No. > > > > No. > > > > No. > > > > U-Boot uses the devicetree for its configuration and it must be > > supplied based on U-Boot's requirements. I will try to send another > > version of the devicetree doc series. > > I really think this needs to be judged on a case-by-case basis. Using > this as a leading principle is fine, but ruling out binary data linked > into the u-boot binary itself out of principle if embedding that data > into the device tree isn't practical seems counterproductive to me. > > Cheers, > > Mark > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog