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...@gmail.com>
> Sent: Thursday, November 25, 2021 11:57 PM
> To: Chan Kim <c...@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
> 
> 




Reply via email to