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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 9768FC4320A for ; Fri, 27 Aug 2021 03:57:52 +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 1F37060F45 for ; Fri, 27 Aug 2021 03:57:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1F37060F45 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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 6110483259; Fri, 27 Aug 2021 05:57:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="QkaJGgWV"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 40C138324F; Fri, 27 Aug 2021 05:57:46 +0200 (CEST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 E424183249 for ; Fri, 27 Aug 2021 05:57:39 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-wr1-x42d.google.com with SMTP id z4so8269960wrr.6 for ; Thu, 26 Aug 2021 20:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Adku05elYXfeu5Tg6ll/nh1cNvXmdkYnYkz7q/z2SuE=; b=QkaJGgWVFbsvr/QZVyr5a7KoSdnFbelSsQ45cboXbCP7myZaxjKihPuzs3tx04FsFR smtltXxABLcGeEh8W2UDSpsppnruw8iLoQ0RKSnCRsVh2botwjK/PlH2uKeG7rFr/pgU 4lZkStVKcVgD1a0ZWsu/0RqqlzgIN7lOeeMWs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Adku05elYXfeu5Tg6ll/nh1cNvXmdkYnYkz7q/z2SuE=; b=S+c143yb1Y3pD/Hl1zJqbODwgQ6Tv17bx0Sy1bFSNsOyy1Pmw7zASej614dhIN0NfZ D4TY5fUPZaFiGCBJJ5wVgS2MX6NeHJk19xz/uHDB6Py9fRUTK5b3EdRukayjwRD2FFBr yKbcZfiRtGga+sgFAlrRw5ynUiq0HsKPWN7FDvYfVB5gCkIL7EQ44cUAEFJfVYl1U9GR VwSNQQk50yTmJJL9IsB+JmBKtNniESq+evFTyzAkrqlWxtvW9ij4iHmNzl4uy1zI5GcC q9FlqlefCXTYD39wSI3qqax2CiMWU6NT4ppMm2kkONru5ddS7YZIuHU/bSxrDgm06nku teGQ== X-Gm-Message-State: AOAM533zXWrVr55xIrgbBb9rqmfy7NcL5q+tSB/WMWUkoXEGFx5D5oU4 v+D1GIDDZU69mQaHVC+RYgBBSJAtN7jNBmAKHxNuSWswBKs= X-Google-Smtp-Source: ABdhPJxJBnShtO7YqOTPA5BXM9rUnJRiWoA9MMFCp2q73IdPTy/e26WZfTzBUbA3xXaUKIQHOc7BU6qfNP+RZAdKkkg= X-Received: by 2002:adf:eb89:: with SMTP id t9mr8044207wrn.66.1630036659141; Thu, 26 Aug 2021 20:57:39 -0700 (PDT) MIME-Version: 1.0 References: <56141c27c4f936c8@bloch.sibelius.xs4all.nl> <56141d7472460ef1@bloch.sibelius.xs4all.nl> In-Reply-To: <56141d7472460ef1@bloch.sibelius.xs4all.nl> From: Simon Glass Date: Thu, 26 Aug 2021 21:57:27 -0600 Message-ID: Subject: Re: Usage of device-tree for blobs To: Mark Kettenis Cc: Heinrich Schuchardt , Ilias Apalodimas , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" 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 Mark, On Thu, 26 Aug 2021 at 14:27, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 26 Aug 2021 14:00:12 -0600 > > > > Hi Mark, > > > > On Thu, 26 Aug 2021 at 06:55, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Wed, 25 Aug 2021 21:15:00 -0600 > > > > > > > > Hi Heinrich, > > > > > > > > On Wed, 25 Aug 2021 at 02:05, Heinrich Schuchardt wrote: > > > > > > > > > > Hello Simon, > > > > > > > > > > some boards like qemu-riscv64_defconfig do not use any device-tree at > > > > > build time. A device-tree is only supplied at runtime by the prior boot > > > > > stage (CONFIG_OF_PRIOR_STAGE=y). > > > > > > > > > > In doc/develop/devicetree/intro.rst you suggest to put binary blobs into > > > > > the device-tree. > > > > > > > > > > Could you, please, update the documentation to explain how adding blobs > > > > > to the device-tree works in the different scenarios depending on the > > > > > values of: > > > > > > > > > > CONFIG_OF_EMBED > > > > > CONFIG_OF_SEPARATE > > > > > CONFIG_OF_BOARD > > > > > CONFIG_OF_HOSTFILE > > > > > CONFIG_OF_PRIOR_STAGE > > > > > > > > > > It would be especially important to understand how one can develop a > > > > > board independent feature which works for all of these settings. > > > > > > > > OK I will take a crack at this tomorrow. > > > > > > > > But I think there is a disconnect here, since the only options that > > > > matter within U-Boot are OF_SEPARATE and OF_HOSTFILE, which both use a > > > > u-boot.dtb file. There is nothing tricky here. > > > > > > > > The OF_BOARD business is for when the board does special things. > > > > Presumably signing will do special things too. We cannot really know > > > > what those things are because the board as 'opted out' of the standard > > > > options. > > > > > > > > > > > > > > Please, describe CONFIG_OF_PRIOR_STAGE in > > > > > doc/develop/devicetree/control.rst. > > > > > > > > So I'm not allowed to delete that option? :-) It seems to me to be > > > > extremely sparse on documentation. We need an explanation of what it > > > > means and what effect it has on the build system, U-Boot and some > > > > discussion of how qemu works. It seems to have been added as part of > > > > an unrelated broadcom commit. The tags were incorrect so I doubt > > > > anyone noticed it. Since then it has apparently proved useful > > > > elsewhere, but no one has added more docs. > > > > > > > > So perhaps you can help me with my doc by explaining how > > > > OF_PRIOR_STAGE works in qmeu, why the DT in U-Boot cannot be used, and > > > > which project actually hosts the DT that qemu provides? Armed with > > > > that information, I might be able to make sense of it all. > > > > > > Well, QEMU allows configuration of (emulated/paravirtualised) devices > > > from the command line. So it is pretty much impossible for U-Boot to > > > provide a DT that matches that configuration without adding a lot of > > > code the dynamically build it from some sort of configuration > > > specification provided by QEMU to U-Boot. But at that point QEMU > > > might as well provide the DT itself, don't you agree? > > > > Don't these devices have a DT in U-Boot? Is qemu enabling them (status > > = "okay") or actually inventing them?! > > I actually invents them. See the mail I just sent for a reference to > the code. OK I see. > > > > Anyway, replying to this thread since for the Apple M1 support that > > > I'm working on we're in a somewhat similar situation. The Asahi Linux > > > project has implemented m1n1 as a bootloader and plans to use U-Boot > > > as a "payload" to implement booting a standard Linux distribution (and > > > other OSes). In this scenario m1n1 actually provides the DT since it > > > parses Apple's version of the DT (which isn't in the standard DT > > > format) and adds/updates certain properties that depend on the actual > > > hardware it is running on. > > > > Yes I see. Still I'd like a basic DT in U-Boot, even if just for > > discoverability. > > Discoverability of what? Devices that are available / used on the board. > > > > For this code I use CONFIG_OF_BOARD and implement > > > board_fdt_blob_setup() to simple return a pointer to the DT that m1n1 > > > set up. But that seems to be exactly what CONFIG_OF_PRIOR_STAGE > > > does... > > > > Right, and neither is really documented to the level that people can > > understand the purpose. They just come across as hacks to me. > > Well, I think U-Boot by its very nature is a giant hack ;). I'm not even sure where to go with that one... > > > I'd like to see an API for passing a info (including DT) to U-Boot. I > > think riscv has it? I suggest we use a register that points to a > > bloblist. > > Well, having a generic API will be hard. It will depend on the > low-level firmware. On RISC-V the SBI specification defines such an > API. For the Apple M1 I just use the existing code that makes U-Boot > look like a Linux kernel and use the same API that is used to pass the > DTB to the kernel. The Raspberry Pi code does something similar. In > the end it just boils down to passing a pointer to the DT in a > specific register. Yes that's what I'm talking about. if RISC-V does it, great. Perhaps ARM can also? Regards, Simon