a question about falcon mode

a question about falcon mode

[Chan Kim]

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).

Please someone confirm this.

Thank you.

Chan Kim

Re: a question about falcon mode

[Alex G.]

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.

Alex

RE: a question about falcon mode

[Chan Kim]

Hi Alex,
Thanks for the reply.
So I gather that to be able to use 'spl export fdt' to store the 'snapshot' to the storage I should make the spl program runnable at  least to that stage. (being able to load kernel image, dtb, initrd and give the spl export command to capture it to storage like SD card).
What I'm thinking of is to let another processor(cortext-M7 based scp, system control processor) load the u-boot-spl.bin into on-chip RAM and kernel(including initramfs)and dtb into SDRAM all from SD card (RAW mode, no file system) and let the AP(application processor) start from u-boot-spl.bin. In this scheme u-boot-spl doesn't need to load anything and DRAM is already initialized and it just needs to run from kernel image after very minimal setup (passing kernel arguments). Do you think this is possible or an absurd idea?
Any comment will be a big help for me.
Thanks!
Chan 

> -----Original Message-----
> From: Alex G. <mr.nuke.me@gmail.com>
> Sent: Thursday, November 25, 2021 11:57 PM
> To: Chan Kim <ckim@etri.re.kr>; U-Boot Mailing List <u-boot@lists.denx.de>
> Subject: Re: a question about falcon mode
> 
> 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.
> 
> Alex
> 
> 

Re: a question about falcon mode

[Alex G.]

On 11/26/21 1:53 AM, Chan Kim wrote:
> Hi Alex,
> Thanks for the reply.
> So I gather that to be able to use 'spl export fdt' to store the 'snapshot' to the storage I should make the spl program runnable at  least to that stage. (being able to load kernel image, dtb, initrd and give the spl export command to capture it to storage like SD card).
> What I'm thinking of is to let another processor(cortext-M7 based scp, system control processor) load the u-boot-spl.bin into on-chip RAM and kernel(including initramfs)and dtb into SDRAM all from SD card (RAW mode, no file system) and let the AP(application processor) start from u-boot-spl.bin. In this scheme u-boot-spl doesn't need to load anything and DRAM is already initialized and it just needs to run from kernel image after very minimal setup (passing kernel arguments). Do you think this is possible or an absurd idea?
> Any comment will be a big help for me.

I'm not sure if that mode is currently supported. You could try using 
CONFIG_SPL_RAM_SUPPORT=y, and one of two things:
   a) Package your kernel and DTB in a FIT.
   b) Extend common/spl/spl_ram.c to support the 'snapshot' dtb

Alex

> Thanks!
> Chan
> 
>> -----Original Message-----
>> From: Alex G. <mr.nuke.me@gmail.com>
>> Sent: Thursday, November 25, 2021 11:57 PM
>> To: Chan Kim <ckim@etri.re.kr>; U-Boot Mailing List <u-boot@lists.denx.de>
>> Subject: Re: a question about falcon mode
>>
>> 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.
>>
>> Alex
>>
>>
> 
> 
> 
> 

Re: a question about falcon mode

[Abder]

Hi Alex,

Just a quick remarque that intrigued me:

Le jeu. 25 nov. 2021 à 15:57, Alex G. <mr.nuke.me@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 ?

Thanks
And apologies Chan for jumping on your thread,


Best regards,
--
Abder

Re: a question about falcon mode

[Alex G.]

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@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@1 {
		target-path = "/chosen";
		__overlay__ {
			bootargs = "root=blablabla console=ttyeS0";
		};
	};
};

> Thanks
> And apologies Chan for jumping on your thread,
> 
> 
> Best regards,
> --
> Abder
> 

Re: 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@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@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@1 {
>                 target-path = "/chosen";
>                 __overlay__ {
>                         bootargs = "root=blablabla console=ttyeS0";
>                 };
>         };
> };
>
> > Thanks
> > And apologies Chan for jumping on your thread,
> >
> >
> > Best regards,
> > --
> > Abder
> >

RE: 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@gmail.com>
> Sent: Wednesday, December 1, 2021 9:16 PM
> To: Alex G. <mr.nuke.me@gmail.com>
> Cc: Chan Kim <ckim@etri.re.kr>; U-Boot Mailing List <u-boot@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@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@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@1 {
> >                 target-path = "/chosen";
> >                 __overlay__ {
> >                         bootargs = "root=blablabla console=ttyeS0";
> >                 };
> >         };
> > };
> >
> > > Thanks
> > > And apologies Chan for jumping on your thread,
> > >
> > >
> > > Best regards,
> > > --
> > > Abder
> > >