a question about falcon mode

[Abder]

Hi Alex,

Well yeah! I thought about that, my question was deliberately open to
that answer too... but what I was looking for is if a dynamic
capability was (already) implemented in the SPL for generating the
fdtargs i.e., taking the dtb and the bootargs env variable (plus
calculating the address and size of the initramfs if used) and putting
all that info in the fdtarg blob just like u-boot does !
But surely that also can be implemented in the SPL. I'm willing to try
that in the near future... and eventually submit a patch for it, if
everything goes as expected !

Thanks for the reply though, and the snippet code too !

Best regards
--
Abder


Le lun. 29 nov. 2021 à 23:12, Alex G. <mr.nuke.me at gmail.com> a écrit :
>
>
>
> On 11/26/21 4:36 PM, Abder wrote:
> > Hi Alex,
> >
> > Just a quick remarque that intrigued me:
> >
> > Le jeu. 25 nov. 2021 à 15:57, Alex G. <mr.nuke.me at gmail.com> a écrit :
> >>
> >> On 11/25/21 1:07 AM, Chan Kim wrote:
> >>> Hello all,
> >>>
> >>> I'm trying to implement falcon mode for our board. Then should I first
> >>> implement the normal mode(spl + proper)?
> >>>
> >>> It looks like so while I'm reading doc/README.falcon. (It says, after
> >>> loading kernel, DT etc. I should give 'spl export' command).
> >>>
> >>
> >> Falcon mode is a bit board dependent.  There are a couple of ways you
> >> could go about this.
> >>
> >> The first is to have an "fdtargs" partition. This is where "spl export"
> >> comes in. Once you run "spl export", it will give a modified dtb at
> >> "$fdtargsaddr". It's that DTB that you need to write to your ftdargs
> >> partition. For example:
> >>
> >>       > spl export fdt $loadaddr - $fdt_addr_r
> >>       > mmc write $fdtargsaddr 0x9800 0x8000
> >>
> >> In this example the ftdargs partition starts at sector 0x9800, and is
> >> 0x800 sectors long.
> >>
> >>
> >> The second option is to forget about "spl export" and "fdtargs", and
> >> package your kernel, devicetree, and overlays in a FIT container. You'd
> >> make sure to enable SPL_LOAD_FIT_APPLY_OVERLAY. There isn't much more to
> >> this other than the usual gotcha's with FIT and overlays.
> >>
> >
> > Do you mean by this that the SPL has the capability to generate the
> > "fdtargs" by it self (if we provide it with the dtb in the fitImage) ?
> >
> > Form my last experience with the falcon mode, I had a - not sure -
> > conclusion that the only way to generate the "fdtargs" is by using the
> > "spl export" command from uboot cmdline !
> > because the reality of the fdtargs blob, as its name indicates, is not
> > just the fdt but it has also the bootargs (inside the chosen node )
> > that are required by the kernel. So if you give only the DTB to the
> > SPL it will not work - to my knowledge -, cuz the data that will be
> > passed to the kernel needs to contain also the bootargs !
> >
> > Can you please confirm to me if this capability is implemented on the
> > SPL and that we can actually forget about the "spl export" command ?
>
> It might not be obvious that an overlay can contain the "/chosen" node
> with the appropriate bootargs:
>
> /dts-v1/;
> /plugin/;
> / {
>         fragment at 1 {
>                 target-path = "/chosen";
>                 __overlay__ {
>                         bootargs = "root=blablabla console=ttyeS0";
>                 };
>         };
> };
>
> > Thanks
> > And apologies Chan for jumping on your thread,
> >
> >
> > Best regards,
> > --
> > Abder
> >