Hi Rasmus, On Sat, 27 Aug 2022 at 19:52, Simon Glass <s...@chromium.org> wrote: > > Hi Rasmus, > > On Wed, 24 Aug 2022 at 19:25, Simon Glass <s...@chromium.org> wrote: > > > > Hi Rasmus, > > > > On Tue, 23 Aug 2022 at 23:57, Rasmus Villemoes > > <rasmus.villem...@prevas.dk> wrote: > > > > > > On 23/08/2022 16.35, Simon Glass wrote: > > > > Hi Rasmus, > > > > > > > > On Tue, 23 Aug 2022 at 07:06, Rasmus Villemoes > > > > <rasmus.villem...@prevas.dk> 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.
Well, I sent it and I think you saw it. What shall we do with this patch? Apply it? Regards, Simon
