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 8631CC433EF for ; Thu, 2 Dec 2021 16:51:01 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D9EB183740; Thu, 2 Dec 2021 17:50:58 +0100 (CET) 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="L8wRsxHS"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4987C83776; Thu, 2 Dec 2021 17:50:56 +0100 (CET) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 26A7E83514 for ; Thu, 2 Dec 2021 17:50:52 +0100 (CET) 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-vk1-xa2a.google.com with SMTP id b192so17106vkf.3 for ; Thu, 02 Dec 2021 08:50:52 -0800 (PST) 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=rEbToTwHty8lrKhQ4Doxfe7viiUx0/RrvuB1PQd7RPE=; b=L8wRsxHSPRwbOXSm/IKozs8BCFGgEOQhbxjpu4JzINWdzSsbnZ4XfU4R823WFsjL62 8cgLMW6ca5cKXYgijw4MtqbIxiFNGFrp0+GVqcTyREI9/6w9qmal2ns6P5+k5sBpWUbH 90hgPTdtWC5y/JiOR/v5EffUAVa+Orfmh9QAQ= 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=rEbToTwHty8lrKhQ4Doxfe7viiUx0/RrvuB1PQd7RPE=; b=lqbFtiyadQ/QKFM3H/pf84uzOeliefUveGSEhhyTRg25qQYOd7tDS0AQTAue5blDgX KZVvK5shIXJfTbaXZfNFQvSv57TKm/1pW/JhlGtbFpqEx5IZTG52hDPPwasp3Scs0v3+ Zb1rdGNI9sKAyEE+w1CbPTtlry1NICjLfjEAtFI5aQAiQxZ6QLAJCe41UfXfM+kSqV7Q APJY6UybYfTfZ5LWWAQEkS9kcTvpAdmtNDIVCA+7j3hyzV8336UI7kguOJNmHJSE7tHz vkwzxBCvYvowEgkqO20QcNemCU7r00eVACv7qWgKMsmCgy1y2vxJsARvif4GTTewaJu4 PgdA== X-Gm-Message-State: AOAM532nw09ITH5u2xLgmLYxiNZHot/mDIkmWQg9anN+OdiFfWeqAlSf ClyB3GgH3K6OpBb/AzEEHGVImLcK1E+QStmblQof/Q== X-Google-Smtp-Source: ABdhPJxdiJwkMweX/ZFvnT/EUZXBmzL9gdnwttqTCwbZlbMJm3XCa68DeAw1VyiN1qjD2zXU2oaAH5vE8/ErCu5TxFE= X-Received: by 2002:a05:6122:21a6:: with SMTP id j38mr17499693vkd.3.1638463850616; Thu, 02 Dec 2021 08:50:50 -0800 (PST) MIME-Version: 1.0 References: <20211202155919.2429190-1-sjg@chromium.org> In-Reply-To: From: Simon Glass Date: Thu, 2 Dec 2021 09:50:39 -0700 Message-ID: Subject: Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option To: Heinrich Schuchardt Cc: Mark Kettenis , Sean Anderson , Ilias Apalodimas , Tom Rini , =?UTF-8?Q?Fran=C3=A7ois_Ozog?= , Aaron Williams , Albert Aribaud , Alexander Graf , Anastasiia Lukianenko , Andre Przywara , Bin Meng , Jerry Van Baren , Linus Walleij , Matthias Brugger , Michal Simek , Oleksandr Andrushchenko , Peter Maydell , Stephen Warren , Stephen Warren , Thomas Fitzsimmons , Tuomas Tynkkynen , U-Boot Mailing List , Heinrich Schuchardt Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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 Heinrich, On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt wrote: > > On 12/2/21 16:58, Simon Glass wrote: > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > > - OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > > - OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented in another patch in this > > series: "doc: Add documentation about devicetree usage" > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > caller may have a better idea about the hardware available in the machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > > > Note: If board maintainers are able to add their own patch to add the > > files, some patches in this series can be dropped. > > > > It also provides a few qemu clean-ups discovered along the way. The > > qemu-riscv64_spl problem is fixed. > > Distros like Ubuntu are provided as preinstalled images using U-Boot to > launch Linux for usage with QEMU. A single image must be able to be > usable in the future irrespective of the QEMU command line device > configuration. > > This means that the devicetree coming from QEMU must be accurately > parsed in U-Boot to setup the UEFI memory map. The number and type of > CPUs and the NUMA configuration must be accurate. All devices enabled > via the QEMU command line must be visible in the device-tree of Linux. > > Please, observe that information like number of CPU cores, number and > type of block devices, namespace IDs used for NVMe drives, etc. cannot > be available at build time. > > It this all guaranteed with this series? If not, this would > unfortunately imply a NAK. Yes, it is guaranteed and there is no change there. Regards, Simon