u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: zong.li@sifive.com, trini@konsulko.com,
	bharat.gooty@broadcom.com, rayagonda.kokatanur@broadcom.com,
	rick@andestech.com, ycliang@andestech.com, fitzsim@fitzsim.org,
	sjg@chromium.org, bmeng.cn@gmail.com, marek.behun@nic.cz,
	green.wan@sifive.com, seanga2@gmail.com, lukas@auer.io,
	brad.kim@semifive.com, xypron.glpk@gmx.de,
	david.abdurachmanov@sifive.com, dimitri.ledkov@canonical.com,
	u-boot@lists.denx.de
Subject: Re: [PATCH 1/3] treewide: Remove OF_PRIOR_STAGE from RISC-V boards
Date: Wed, 29 Sep 2021 14:59:10 +0200 (CEST)	[thread overview]
Message-ID: <5614943fc1ec0ac8@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <YVRiVFP+sYGZhJiY@apalos.home> (message from Ilias Apalodimas on Wed, 29 Sep 2021 15:55:48 +0300)

> Date: Wed, 29 Sep 2021 15:55:48 +0300
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> 
> > > > > > -       if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
> > > > > > -               if (gd->arch.firmware_fdt_addr)
> > > > > > -                       return (ulong *)gd->arch.firmware_fdt_addr;
> > > > > > -               else
> > > > > > -                       return (ulong *)&_end;
> > > > > > -       }
> > > > > > +       if (gd->arch.firmware_fdt_addr)
> > > > > > +               return (void *)gd->arch.firmware_fdt_addr;
> > > > > > +       else
> > > > > > +               return (void *)&_end;
> > > > > >  }
> > > > >
> > > > > I was wondering if we need to check CONFIG_OF_BOARD here? I'm not sure
> > > > > whether we should distinguish the value of a1 register which is
> > > > > meaningless. It means that if we don't expect the device tree to be
> > > > > passed by prior stage, then the a1 register might be a trash value at
> > > > > the beginning, so it would still return the arch.firmware_fdt_addr
> > > > > here, rather than _end.
> > > >
> > > > I thought about it as well.  Those boards were configured up to now with
> > > > 'CONFIG_OF_SEPARATE'.  Which means we are looking at an existing issue?
> > > > IOW the device tree was passed as part of U-Boot,  which would mean a1 would
> > > > have had thrash as well.  Maybe a1 always has a valid DT on those boards
> > > > so we never noticed?
> > > >
> > > >
> > > > > And do you think that we should enable the
> > > > > CONFIG_OF_BOARD for unmatched and unleashed? Because it seems to me
> > > > > that we actually pass the device tree by prior stage (i.e. OpenSBI).
> > > >
> > > > Yes in that case what you request makes sense for unmatched/unleashed.
> > > > Return gd->arch.firmware_fdt_addr in OF_BOARD is selected otherwise return
> > > > _end (instead of the current check).
> > > > If that sounds good to you I'll send a v2
> > >
> > > Looking a bit more at it...
> > > Apparently those boards boot from SPL.  So it's SPL->OpenSBI->U-Boot.
> > > By having the config as OF_SEPARATE the *U-Boot* DTB is used. SPL passes it to
> > > OpenSBI and OpenSBI passes it on a1 to U-Boot proper.  That's why the register
> > > reading works for that config.
> > >
> > > In that case the pre-existing code is 'wrong' as well,  since the DTB is
> > > not at _end,  but the bogus path is never taken...
> > > (check the __weak board_fdt_blob_setup for details).
> > >
> > 
> > If I remember correctly, the SPL would calculate the size of u-boot
> > proper, and then put the DTB at the end of  u-boot proper, so the DTB
> > would fortuitously be put at the _end location.
> 
> I haven't yet seen the creation part,  but looking into the default
> board_fdt_blob_setup() the location seems to vary depending on
> CONFIG_SPL_BUILD.  If that's selected (which is the case for those boards),
> then it depends on yet another SPL config for a separate .bsdd section.
> 
> I don't have a board to verify my suspicion but I think reading the DTB
> without looking into a1 is broken for these boards.
> 
> > 
> > > So I think I'll send a v2, keeping the config as-is and fixing the return
> > > address of the DTB in case OF_BOARD is ever selected.
> > >
> > 
> > Yes, it seems to me that we could use a config to separate the case
> > between the prior stage and the _end. 
> 
> Untangling OF_SEPARATE and OF_BOARD is part of a bigger revamp I wanted to 
> do on the handover of a device tree from previous bootloaders,  since we do 
> have similar 'problems' in Arm and TF-A.  But in principle OF_SEPARATE
> shouldn't have per board code to overwrite it.  OF_BOARD should be used for
> that.  OF_SEPARATE should merely mean "The dtb is concatenated to my U-Boot
> binary.
> 
> Right now RISC-V uses OF_SEPARATE reads the DTB on SPL and then goes back
> to using the a1 register for U-Boot proper.  We could instead read the 
> U-Boot concatenated DTB always in that case.  OF_BOARD would then be used in
> case OpenSBI is compiled with a *different* DTB and you'd want to use that.
> Any idea if OpenSBI performs fixups before handing over the dtb in a1?

It does.  One of the things it does is add a reserved memory entry for
itself.

> Unfortunately I don't have a board to test apart from QEMU.  Let me respin
> this, with a potential fix I have in mind and we can discuss further.
> 
> > Just note that, there is a patch
> > on the fly, it modifies the same snippet of code, you might need to
> > update your code based on top of it.
> > https://lists.denx.de/pipermail/u-boot/2021-September/460378.html
> 
> I'll reply to that and see if the _end is indeed a problem.
> 
> Thanks
> /Ilias
> 

  reply	other threads:[~2021-09-29 12:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27  6:47 Ilias Apalodimas
2021-09-27  6:47 ` [PATCH 2/3] board: arm: Remove OF_PRIOR_STAGE Ilias Apalodimas
2021-09-27 20:15   ` Simon Glass
2021-09-27  6:47 ` [PATCH 3/3] treewide: " Ilias Apalodimas
2021-09-27 20:15   ` Simon Glass
2021-09-27 20:14 ` [PATCH 1/3] treewide: Remove OF_PRIOR_STAGE from RISC-V boards Simon Glass
2021-09-29  8:33 ` Zong Li
2021-09-29  9:02   ` Ilias Apalodimas
2021-09-29 10:17     ` Ilias Apalodimas
2021-09-29 11:51       ` Zong Li
2021-09-29 12:55         ` Ilias Apalodimas
2021-09-29 12:59           ` Mark Kettenis [this message]
2021-09-29 13:11             ` Ilias Apalodimas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5614943fc1ec0ac8@bloch.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=bharat.gooty@broadcom.com \
    --cc=bmeng.cn@gmail.com \
    --cc=brad.kim@semifive.com \
    --cc=david.abdurachmanov@sifive.com \
    --cc=dimitri.ledkov@canonical.com \
    --cc=fitzsim@fitzsim.org \
    --cc=green.wan@sifive.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=lukas@auer.io \
    --cc=marek.behun@nic.cz \
    --cc=rayagonda.kokatanur@broadcom.com \
    --cc=rick@andestech.com \
    --cc=seanga2@gmail.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    --cc=ycliang@andestech.com \
    --cc=zong.li@sifive.com \
    --subject='Re: [PATCH 1/3] treewide: Remove OF_PRIOR_STAGE from RISC-V boards' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).