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 6C3D4C433F5 for ; Wed, 13 Oct 2021 16:22:50 +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 D29FA60551 for ; Wed, 13 Oct 2021 16:22:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D29FA60551 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fitzsim.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 26727820E3; Wed, 13 Oct 2021 18:22:48 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=fitzsim.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=fitzsim-org.20210112.gappssmtp.com header.i=@fitzsim-org.20210112.gappssmtp.com header.b="QJZxSHCw"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0FA6C8314C; Wed, 13 Oct 2021 18:22:46 +0200 (CEST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 B3BF28187B for ; Wed, 13 Oct 2021 18:22:41 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=fitzsim.org Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=fitzsim@fitzsim.org Received: by mail-qk1-x72f.google.com with SMTP id bk7so2705185qkb.13 for ; Wed, 13 Oct 2021 09:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fitzsim-org.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Ast88VsNuEe1gV8qbXmKtNvBmAq0C3PQkjsIK7K8irs=; b=QJZxSHCwBgLLFnv2Wd+A2Y8KYdUSBc8tPvewdsARTbbCJ1jX635c6uYtP6d6tI7ApQ OQS5t55ma4iV54vEhnRX7VMydWosoUaCAPLfvESEuB5ymQhEIZ0gsvawy+0E2b3wb7Qg FIeyEe0SXTOj0eDo3TaOFDwnK4VlFIt4U8HrmQSwY/WvgJhBLqi5r0vg5c8si18eQjrc 6i7nuwqBlBdumcn95I7rffOGuUiD/sDZkHm4Yhr9R8mUt09hBgHe80d9wMhlVhiYqPCC 06pW3A/2Q4ICOW/adStEh/Rt6jnsaQvvT9CA023c1xO0hwOcwdIkexmxOlvEEPNdouh5 s7ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Ast88VsNuEe1gV8qbXmKtNvBmAq0C3PQkjsIK7K8irs=; b=C56RhAKjKncqPM6X77A2pOLCkTbjjk8hSMK6SM+Wqmq18JslYuAvpieJ8Tpx7WAtt4 Sh7Ka2MhY9kfW+/UmTjpRuGBO+bfFII2Tu5s8AvsUsG99LXSIfB5Q1lwZ78Tt06AEQ6Z Gv7T+JM3Lhcm0L3ZPhAael9DdUIZwEu5Qc4IkO9CpPhF+2WpsiAJ4EDIIVMe78jvIVt3 sssiB4rtgyPCGnTKCbihvTrarGZ/lLkVoWv1WzkUsUmIAbUwk/HnikfSOGcDogQbtZ8q z91wJxctQH0OzK2WR/kG2l/Ty39JXP6wY0xYQ0VodQdU0ADZwUEVyGnWhb/Q6LEXQFz2 XTJA== X-Gm-Message-State: AOAM530p5fACQ5nU4AdxmqsDwe+mNqRPBst4xEI3DAeMvxXETmfDbxZ/ 2yyXhVPCJrA7hQpbV/ZRHa9vaP7zwlghW4K7e7M= X-Google-Smtp-Source: ABdhPJyIoss9buWI0C+PqnAg0CQXzSvnTb3VdXB+9KCovUHgh1ANcDLkqBOl6I/ncq832Xsh4kSO+Q== X-Received: by 2002:a05:620a:5ab:: with SMTP id q11mr161451qkq.269.1634142160350; Wed, 13 Oct 2021 09:22:40 -0700 (PDT) Received: from localhost.localdomain (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by smtp.gmail.com with ESMTPSA id h125sm1575qkc.29.2021.10.13.09.22.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Oct 2021 09:22:39 -0700 (PDT) From: Thomas Fitzsimmons To: Simon Glass Cc: Mark Kettenis , Ilias Apalodimas , Tom Rini , rick , Leo Liang , Bin Meng , Marek =?utf-8?Q?Beh=C3=BAn?= , Green Wan , Sean Anderson , Lukas Auer , Brad Kim , Zong Li , Heinrich Schuchardt , David Abdurachmanov , Dimitri John Ledkov , U-Boot Mailing List Subject: Re: [PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE References: <20210924131021.814662-1-ilias.apalodimas@linaro.org> <561485a22ef0a3ce@bloch.sibelius.xs4all.nl> Date: Wed, 13 Oct 2021 12:22:38 -0400 In-Reply-To: (Simon Glass's message of "Sun, 26 Sep 2021 09:53:55 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 Hi Simon, Simon Glass writes: > Hi Mark, > > On Sat, 25 Sept 2021 at 11:27, Mark Kettenis wrote: >> >> > From: Simon Glass >> > Date: Fri, 24 Sep 2021 07:57:00 -0600 >> > >> > Hi Ilias, >> > >> > On Fri, 24 Sept 2021 at 07:10, Ilias Apalodimas >> > wrote: >> > > >> > > At some point back in 2018 prior_stage_fdt_address and OF_PRIOR_STAGE got >> > > introduced, in order to support a DTB handed over by an earlier stage boot >> > > loader. However we have another option in the Kconfig (OF_BOARD) which has >> > > identical semantics. >> > > >> > > A good example of this is RISC-V boards which during their startup, >> > > pick up the DTB from a1 and copy it in their private gd_t. Apart from that >> > > they also copy it to prior_stage_fdt_address, if the Kconfig option is >> > > selected, which seems unnecessary(??). >> > > >> > > This is mostly an RFC, trying to figure out if I am missing some subtle >> > > functionality, which would justify having 2 Kconfig options doing similar >> > > things present. >> > > >> > > - Should we do this? >> > >> > I think one option is better than two. I have a slight preference for >> > OF_PRIOR_STAGE because it is board-agnostic, but I'm not sure it >> > matters, since some of these boards are doing strange things anyway >> > and cannot use OF_PRIOR_STAGE. So let's go with this. >> > >> > > - Doesn't OF_BOARD and OF_PRIOR_STAGE practically mean "Someone else is >> > > going to pass me my DTB". Why should we care if that someone is a prior >> > > bootloader or runtime memory generated on the fly by U-Boot? It all >> > > boils down to having a *board* specific callback for that. >> > >> > More generally, I think OF_BOARD is basically 'opt out of the normal >> > flow and do something special'. >> > >> > So at some point I would like to define what 'normal' is. At present, >> > normal is OF_SEPARATE which means that the devicetree is packed with >> > U-Boot. >> > >> > Really we want to add a second 'normal', to permit a devicetree (and >> > perhaps other stuff) to be passed in. I think this should be that a >> > bloblist is passed in, which can contain a devicetree. If it does, >> > then the one in U-Boot is ignored. >> > >> > There should be a standard way to do this with U-Boot. Apart from the >> > arch-specific selection of machine registers, the standard way should >> > work for all boards, at some indeterminate point in the future. >> >> There are well-established ABIs here that you can't really change. >> One of those ABIs is how the Linux kernel expects to be called. On >> both riscv and arm64 Linux expects to find a pointer to the DTB in a >> register. >> >> Several U-Boot platforms take advantage of this by pretending to be a >> Linux kernel. This way they can be loaded by prior stage firmware >> that was designed to directly load a Linux kernel. This is what I do >> for the Apple M1, but this is also how chainloading works on some >> chromebooks, and there are a few platforms where a proprietary closed >> source first stage bootloader is used. >> >> So once again, U-Boot should be flexible here. We can certainly >> recommend a certain approach to folks that are building a firmware >> stack for new platforms, but we can't really enforce it. > > Indeed. > > We can nudge people along by providing useful features. Private > firmware does not seem to be going away. The situation Mark described is the same as the one I was addressing by introducing CONFIG_OF_PRIOR_STAGE for these BOLT-using Broadcom boards. BOLT is a Broadcom proprietary first- and second-stage bootloader. On these boards, the DTB that BOLT generates in-memory and provides to the Linux kernel is meant to be authoritative. I would much prefer if Broadcom provided native U-Boot support as an alternative to BOLT, including maintaining free software device trees. But in the absence of that, given that I wanted U-Boot features on these boards, I made U-Boot an intermediate (third) stage and used the BOLT-provided DTB. One reason I had for contributing the changes is that I was faintly hoping to nudge Broadcom to support these and future boards in U-Boot. My understanding is that the DTB design intent does allow things like loading a DTB from ROM, so I'm sort of treating the BOLT-provided DTB that way. But I also understand that not having U-Boot and Linux in full control of device trees for boards they support is annoying. That said, I'm glad the consensus here seems to be that it's preferable to have U-Boot accommodate/still be usable on no-DTS boards. Thomas