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 <koute102...@gmail.com> > Sent: Wednesday, December 1, 2021 9:16 PM > To: Alex G. <mr.nuke...@gmail.com> > Cc: Chan Kim <c...@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...@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...@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 > > >