a question about falcon mode

[Chan Kim]

Hi, Alex and Abder,
Thank you for the comments.
Those will be a good hint for me (especially CONFIG_SPL_RAM_SUPPORT , using FIT image etc..) in reading the document and doing the experiment later.
Best regards
Chan

> -----Original Message-----
> From: Abder <koute102030 at gmail.com>
> Sent: Wednesday, December 1, 2021 9:16 PM
> To: Alex G. <mr.nuke.me at gmail.com>
> Cc: Chan Kim <ckim at etri.re.kr>; U-Boot Mailing List <u-boot at lists.denx.de>
> Subject: Re: a question about falcon mode
> 
> 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
> > >