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 936BCECAAD1 for ; Sun, 28 Aug 2022 01:52:41 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C0F4584594; Sun, 28 Aug 2022 03:52:38 +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="m179LVkp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A551B848E7; Sun, 28 Aug 2022 03:52:37 +0200 (CEST) Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) (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 7AEBB84594 for ; Sun, 28 Aug 2022 03:52:34 +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-yw1-x112e.google.com with SMTP id 00721157ae682-33dc345ad78so121697687b3.3 for ; Sat, 27 Aug 2022 18:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=qGpoRbFSlSKuNopA1xt6OvBaJeHYWuHTHuC1tTecGsU=; b=m179LVkpGpsQaZwjWgpYCTMtWF9+8A1SnoQ/CyXTkoSiGodGArzq3/E39fkS/c5aBJ gTdw5NNU5g664vcKWttxthdT3f+wG60aYPNgWnci08BGBIcvpZJ8N6NmOUu2p5Ncb9e0 LTRPKpjC5w8m0aLDscghyxEEznkLJ/iLx567M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=qGpoRbFSlSKuNopA1xt6OvBaJeHYWuHTHuC1tTecGsU=; b=lbMT34F7xbvC0bu6sq2iSH0H9KGlT/Mj1YINlWD0yNPVmfUwmcu5Z5XmLFKAH81RRn LyFm4kB6hxEgDg61nzt8V7YKm6/pc6iJnIU6S5P8Q/MuUnVVOB27rJGQ7Fe00v2zD901 M5/AX4JXOVgRy7ipYsQuA8Voe5v9GKTy6dwHVRhabqb9Dr6kD6te9o8fGksIb3x8o+Hd tx5j4HGO+ISQVN02CT8YeXTDGi3JjSlshg6ukM9Ykk3zCKbePvetHeEv+uGAx9vyXt50 4WKQOcLiZGL20hlJSJbc6OJpiYHdBXuQD1yOOob4VuYgOizQxfPgiygymEXmRJnrRd4u kvdA== X-Gm-Message-State: ACgBeo3Bg6WZqJYdSPW8yhFzUGDKtuyxw7bnc5zCE9xn/FxeHwSffrS/ OABdpxcLh6IHoLEY92ruB40zx09vXaezNKNoZfsf8Q== X-Google-Smtp-Source: AA6agR7wIAwhgcF4kcKIlhNfo7gvpr04vvqjD9OKoxOvv7JEW/85+Jx17TiL2/B1coZZORXwFc6PE119SHZMDPhmWLo= X-Received: by 2002:a81:6803:0:b0:340:a05d:dc09 with SMTP id d3-20020a816803000000b00340a05ddc09mr5538991ywc.402.1661651552911; Sat, 27 Aug 2022 18:52:32 -0700 (PDT) MIME-Version: 1.0 References: <20220822073423.3663582-1-rasmus.villemoes@prevas.dk> <4557fbd0-812c-27eb-78b3-b8fc6a1201a8@prevas.dk> <174d43f5-c0ee-c0ce-7491-b1f944294d4a@prevas.dk> In-Reply-To: From: Simon Glass Date: Sat, 27 Aug 2022 19:52:21 -0600 Message-ID: Subject: Re: [PATCH] fdt_support: add optional board_rng_seed() hook To: Rasmus Villemoes Cc: U-Boot Mailing List , Michal Simek , Tom Rini Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean Hi Rasmus, On Wed, 24 Aug 2022 at 19:25, Simon Glass wrote: > > Hi Rasmus, > > On Tue, 23 Aug 2022 at 23:57, Rasmus Villemoes > wrote: > > > > On 23/08/2022 16.35, Simon Glass wrote: > > > Hi Rasmus, > > > > > > On Tue, 23 Aug 2022 at 07:06, Rasmus Villemoes > > > wrote: > > >> > > >> On 23/08/2022 15.38, Simon Glass wrote: > > >> > > >>>> +/** > > >>>> + * board_rng_seed() - Provide a seed to be passed via /chosen/rng-seed > > >>>> + * > > >>>> + * This function is called if CONFIG_BOARD_RNG_SEED is set, and must > > >>>> + * be provided by the board. It should return, via @buf, some suitable > > >>>> + * seed value to pass to the kernel. > > >>>> + * > > >>>> + * @param buf A struct abuf for returning the seed and its size. > > >>>> + * @return 0 if ok, negative on error. > > >>>> + */ > > >>>> +int board_rng_seed(struct abuf *buf); > > >>> > > >>> Instead of yet another hook, can we use EVT_FT_FIXUP? An even better > > >>> option might be to use EVT_FT_FIXUP and then call a UCLASS_BOARD > > >>> method to obtain the information. > > >> > > >> I didn't know there was anything called EVT_FT_FIXUP, and from grepping, > > >> it seems suffer the same problem as ft_board_setup() as I mention, > > >> namely running after the command line (aka /chosen/bootargs) has been > > >> set up. > > > > > > If that is the only problem, then you could add another event for > > > doing an earlier fixup. > > > > Then I'd much rather just add a board_fdt_chosen() hook called early in > > fdt_chosen(), rather than having to enable yet another overcomplicated > > generic framework. But this was very much specifically targeted at > > rng-seed, because that's a generic, defined binding in /chosen, and I > > wanted to support that explicitly rather than having each board > > implement the logic for populating that - even if, due to its nature, > > the board must supply the actual value to put there. > > You can put the event spy in generic code if you like. I am trying to > think more generic ways to handle things, since we have so many > 'hooks'. > > > > > >> Also, I can't see how it can actually affect the blob being passed to > > >> the kernel, doesn't > > >> > > >> fixup.tree = oftree_default(); > > >> ret = event_notify(EVT_FT_FIXUP, &fixup, sizeof(fixup)); > > >> > > >> mean that fixup.tree points at U-Boot's control fdt rather than the blob > > >> that will be passed as the kernel's fdt? That seems wrong. > > > > > > Yes that is wrong for many platforms. We should probably just change > > > it, but there is a complication. > > > > > > My recent series made a start at supporting writing to a DT using the > > > ofnode interface. See vbe_simple_test_base() for some comments on the > > > current state. You could require OF_LIVE to be enabled for your new > > > feature. > > > > > > Ideally I'd like to see ofnode used for all devicetree access, but it > > > will need to be done in stages. In the meantime we should try to head > > > in that direction. > > > > Huh? You'd need to deserialize the blob we've loaded (from FIT or uImage > > or given directly to a bootm command), > > yes > > > then have _all_ the various fixup > > functions (setting mac addresses, populating /chosen, all the various > > arch and board fixups etc.) modify that deserialized tree, > > Well they only need to use ofnode. > > > and then at > > the end of the day, you need to serialize the tree again to pass to > > linux. I don't see how that could happen incrementally, and I don't see > > what advantage this would bring anyway. > > Yes that's right. It can actually happen incrementally. > > Unless there is very little going on, it is faster to modify the live > tree and then flatten it before calling Linux. > > > > > All that has nothing at all to do with how U-Boot code accesses U-Boot's > > control DT. > > As I mentioned, ofnode can now access any tree, at least when OF_LIVE > is enabled. But as you point out, there is lots of work to do here. I'm looking at adding full support to ofnode for reading/writing any tree, not just the control FDT. I should have a series out before the end of next week. Regards, Simon