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 27EAAC433FE for ; Fri, 15 Oct 2021 16:19:29 +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 0FAE061053 for ; Fri, 15 Oct 2021 16:19:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0FAE061053 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 455D3836E9; Fri, 15 Oct 2021 18:19:26 +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="zRlmf85H"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B6830837DD; Fri, 15 Oct 2021 18:19:24 +0200 (CEST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 5C9BA83695 for ; Fri, 15 Oct 2021 18:19:20 +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-x72c.google.com with SMTP id t63so8984651qkf.1 for ; Fri, 15 Oct 2021 09:19:20 -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=AnjbjZmrEuy5Uc3eN23twqhaHCwajPbMi2z9DXgXU2I=; b=zRlmf85Hg0uLLm8Cgizj2JG5t8xE1SiEDrQIjsjikg/xP8MFqnWwlX8O/woT+3Wfo3 /55Um0A+rwbwdAnQy6sT+V9nwReV55t7td+wP3/wVPSRPcge7KKU8hgDiGC5B8E8+aeP zYmoUCe9f3NHessWR7RIaDiGjsUo2sWB7d+Tf6bVKKklrFvdYgU9qSuG70u+3NMrzd28 nO1OrugCQefDFfslfyddlGGj8QZMjiPHYaVEtTexxaqLZ/VjJ+cv2PoQgIUS/pxwFv2b V1wrACb4DHYqULPkDs4ODoYgYBmdOL3+8/h/UGtSOHzdUGCyT/tyxDzavkehZ9ulaMnP oidg== 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=AnjbjZmrEuy5Uc3eN23twqhaHCwajPbMi2z9DXgXU2I=; b=WROjhWCkrcH3earIBsCHf2BQ3WeO6Oj0eufTmutqgewhLANuj9b+iAg31qKRlnZkav Om6boMc5j8xh9CQpl9Iee4/xpDgjr3L4mtO3F0XnNxhADCaRpQLsOm/cgNp/03432XUx s/A+1RrYs3Vnl4sO9FB6yQKa4oQ+56RVsyaeRCTci/ar1NZkxb/7kDFHp9UwjqESbwQi QiWksGWggrNhC/yr5/evBhENpYGJH26VjIIgCQLZentzXAHz1yk8X6KLOjsQffl4wvyD NMyE1lX/5h3sKoLIOALheZfC7J5xOI6EpUmZMONatlhmDKck3+z3yyYwWjN3ad/vij2g ZfPQ== X-Gm-Message-State: AOAM532Z7uAVwdh48qeeGd8kYXpJaALePZbZHyklchgcjpQrF3M3RZJO FaMNT6nX+gSlR5DWQbrBsSewxQ== X-Google-Smtp-Source: ABdhPJw/YfCTlbCQf7+9XRcayB1SBKgnJoPijz7VoA4hAn3RkzkJZtgweT2AxUTIkJTR6RcRFIJ+WQ== X-Received: by 2002:ae9:dd84:: with SMTP id r126mr10945115qkf.247.1634314758972; Fri, 15 Oct 2021 09:19:18 -0700 (PDT) Received: from localhost.localdomain (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by smtp.gmail.com with ESMTPSA id o5sm2622678qkl.50.2021.10.15.09.19.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Oct 2021 09:19:18 -0700 (PDT) From: Thomas Fitzsimmons To: Tom Rini Cc: Simon Glass , Ilias Apalodimas , Rick Chen , Leo , 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 , Mark Kettenis Subject: Re: [PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE References: <20210924131021.814662-1-ilias.apalodimas@linaro.org> <20211013175807.GY7964@bill-the-cat> Date: Fri, 15 Oct 2021 12:19:16 -0400 In-Reply-To: <20211013175807.GY7964@bill-the-cat> (Tom Rini's message of "Wed, 13 Oct 2021 13:58:07 -0400") 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 Tom, Tom Rini writes: > On Wed, Oct 13, 2021 at 01:36:00PM -0400, Thomas Fitzsimmons wrote: >> Simon Glass writes: >> >> [...] >> >> > On Wed, 13 Oct 2021 at 10:26, Thomas Fitzsimmons wrote: >> >> >> >> Simon Glass writes: >> >> >> >> [...] >> >> >> >> >> > 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. >> >> >> >> >> >> For now it's easier getting rid of OF_PRIOR_STAGE than OF_BOARD. >> >> >> Once we unify OF_PRIOR_STAGE/OF_BOARD and OF_HOSTFILE, then >> >> >> I can send a patch on top of that, which removes the board_fdt_blob_setup() >> >> >> and just stores the address in a similar fashion to the removed >> >> >> 'prior_stage_fdt_address'. That way we can get rid of architecture >> >> >> specific constructs wrt to DT in gd. The callback is a bit more of a pain to >> >> >> maintain for multiple boards but is more flexible than an address in a >> >> >> register. In any case we can do something along the lines of: >> >> >> >> >> >> Check register (or blob list or whatever) >> >> >> if (valid dtb) >> >> >> fixup/amend/use (depending on what we decide) >> >> >> else >> >> >> arch specific callback >> >> >> >> >> >> That should give us enough flexibility to deal with future boards (famous >> >> >> last words). >> >> > >> >> > SGTM >> >> >> >> This sounds like a good generalization that would still work for the >> >> bcm7445 and bcm7260 boards. I'll test this approach on the evaluation >> >> boards I have. >> >> >> >> For the BCM7445 I may be able to import the evaluation board device tree >> >> that Broadcom publishes as part of stblinux. At runtime I may need to >> >> merge some of the in-memory items generated by BOLT, but I'll try to >> >> make this work. >> > >> > That would be good. >> > >> >> The BCM7260 DTS is not publicly available though, as far as I know. >> > >> > Presumably it can be dumped from U-Boot? >> >> Technically, yes, but I wouldn't want to publish the result for various >> reasons; e.g., it would be specific to the evaluation boards I have, and >> it may contain vendor-specific fields. I'd much rather this one remain >> a stub, until/unless Broadcom publishes a generic BCM7260 DTS under a >> free license. > > Also note that the notion that the U-Boot source tree _must_ contain a > dts for a given board is something we're very much debating still, in > another thread, if you're inclined to read and chime in there as well > with more details about the broadcom use case and technical/legal > limitations. Thanks! Sure. I read through [1]; here are my thoughts from the BCM7445/BCM7260 perspective. First of all, for background, BCM7445 and BCM7260 are partial ports of U-Boot. They're meant to allow using nice U-Boot features like hush and FIT image loading on these platforms. But they do not handle low-level initialization -- that's done by BOLT, the proprietary first-and-second-stage bootloader -- and they don't support configuring all of the hardware on these boards. Instead these ports include a small set of drivers (e.g., SPI, eMMC, serial) and configuration that is needed to make use of the higher level features. At the time I contributed the BCM7445 support, README called OF_CONTROL an experimental feature, and device driver configuration was alternatively allowed to live in board-specific header files. My initial local implementation did that, but then I switched to OF_CONTROL before submitting the patches, since then I could get some of U-Boot's driver configuration from the prior stage (BOLT) dynamically, instead of hard-coding addresses in U-Boot source code. The proposed new policy would require me to (re-)add these hard-coded values, albeit in a DTS, not a header file. IMO that's probably a good/fair requirement for the non-technical reasons in [1]. The second section of [1] says: "Every board in U-Boot must include a devicetree sufficient to build and boot that board on suitable hardware (or emulation)." I initially read that as "boot to Linux", and so I was thinking the device tree checked into the U-Boot tree had to be sufficient to boot Linux and configure every device that Linux supports. One of Simon's responses [2] clarified for me that the policy proposal was about the control DTB for U-Boot. Now I believe the intent of the proposed policy (stated in the "Devicetree source" section of [1]) is something like "each port in U-Boot must have an in-tree device tree that is sufficient to boot/run *U-Boot itself* on at least one representative board designed around that SoC". That would make sense to me; it would permit not-full-Linux device trees that configure only the device drivers that the port needs to support a subset of U-Boot features. This would allow boards like BCM7260, which have no publicly available Linux DTS, to have a small, generic device tree just for configuring reused, GPL'd U-Boot drivers. This is in contrast to the policy mandating or encouraging dumping to DTS binary-only proprietary Linux DTBs from prior stage bootloaders or ROMs, as a precondition to the port being included in U-Boot. The policy proposal (assuming I'm understanding it correctly now) would have been clearer if one of the first two sections in devicetree.rst explicitly mentioned "control DTB for U-Boot", i.e., the fact that the policy is about U-Boot's own much simpler DTB usage, not Linux's, even though the two projects largely share the same DTSs. Thomas 1. http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ 2. https://lists.denx.de/pipermail/u-boot/2021-October/463675.html