[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

Wed May 15 21:24:35 UTC 2019

Hi TF,

On Mon, May 13, 2019 at 01:37:22PM +0000, Chee, Tien Fong wrote:
> On Wed, 2019-05-08 at 13:43 -0500, dannenberg at ti.com wrote:
> > Hi TF,
> > thanks for chiming in. Comments inlined...
> > 
> > On Wed, May 08, 2019 at 04:31:35AM +0000, Chee, Tien Fong wrote:
> > > 
> > > On Tue, 2019-05-07 at 22:00 +0200, Simon Goldschmidt wrote:
> > > > 
> > > > 
> > > > On 07.05.19 19:25, Andreas Dannenberg wrote:
> > > > > 
> > > > > 
> > > [...]
> > > > 
> > > > > 
> > > > > 
> > > > > While I also have a working solution based on the existing FS
> > > > > loader
> > > > > framework this has its own challenges, namely by its very
> > > > > nature
> > > > > only
> > > > > addressing a subset of our use cases (no eMMC/SD RAW boot
> > > > > support
> > > > > for
> > > > > example), 
> > > IMO, it's actually not that hard to enhance RAW support, i think
> > > minimal changes are required. I have attached the patches about an
> > > example of loading RAW from QSPI that i have done locally last few
> > > week
> > > ago.
> > As your patches show, no it's not hard, it's more or less taking
> > pieces
> > from the SPL loader framework and refactoring them into the FS
> > loader,
> > creating a good and universal solution usable across SPL and U-Boot
> > in
> > environments that are not tightly constrained in terms of memory.
> > 
> > What I was going after is finding a way to load from different media
> > "pre-relocation" SPL (board_init_f), with almost no memory available,
> > where I have to agonize over every single KB available.
> 
> This is just a simple "loader", provide user flexibility of loading
> stuff in anywhere, from SPL to U-Boot. As long as DM is supported by
> the time running at "pre-relocation" SPL, then FS loader should be able
> to work.

Understood. FS loader also relies on the peripheral being brought up.
For MMC, from my SPL board_init_f() user code I had to do a sequence of
mmc_initialize(), mmc_get_mmc_dev(), and mmc_init() before I could use
the FS loader functionality - just like the U-Boot SPL loader is already
doing this. Hence my concern with code duplication for certain use
cases. Anyways I'll post my use of the FS loader as an RFC here soon
so you can have a look at the whole thing if you like.

> > > > > being heavier on resource usage (needing to use ENV to pass
> > > > > parameters),
> > > ENV is optional, you can use DTS.
> > Is it? I had to update the FS loader framework when I experimented
> > with
> > it, please see attached patch. I had refactored it such that I can
> > pass
> > in all relevant data via platform data for the intial boot mode I was
> > going after, so that I can dynamically configure it on the fly from
> > early SPL board_init_f() based on boot media / boot mode, etc.
> 
> Yes, you can tie up loader with target HW node for destination loading.
> For example, tie up with FPGA manager node, loading bistream file from
> MMC to FPGA manager.
> 
> Here is an example, but i put the fs loader phandle under chosen node
> because most files and images are stored in the same storage.
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=0a42a132a4b8
> 46031df2c4a7d04692240ed34843

Thanks for pointing to this example for DTS-based loading, I think I had
seen this earlier when I looked for implementations using the FS loader
framework.

> > > 
> > > For example loading FPGA bitstream from QSPI RAW:
> > > 
> > > /* DTS */
> > > / {
> > > +	aliases {
> > > +		spi0 = &qspi;
> > > +	};
> > > +
> > > +	fs_loader0: fs-loader {
> > > +		u-boot,dm-pre-reloc;
> > > +		compatible = "u-boot,fs-loader";
> > > +		sfconfig = <0 0 100000000 3>;
> > > +	};
> > > +};
> > > +
> > > +&fpga_mgr {
> > > +	u-boot,dm-pre-reloc;
> > > +	firmware-loader = <&fs_loader0>;
> > > +	altr,bitstream = "300000";
> > > +};
> > The above hard-codes and duplicates information that is already known
> > to
> > U-Boot (CONFIG_SF_DEFAULT_*), and will do more of the same as this is
> > being extended. How does one keep this consistent?
> 
> Current fs loader not support RAW loading yet, i'm not sure whether it
> should support it by adding more specific storage API(much more messy),
> or just fully support filesystem only with one generic filesystem
> abstract interface.
> 
> This example codes provide user opportunity to override the spi setting
> when running fs loader. CONFIG_SF_DEFAULT_* would be used by the
> drivers which are not running the fs loader.
> 
> > 
> > And how does this scale to support like 5 different boot modes using
> > a
> > single DTB? I guess one  could populate 5 nodes, and then pick one
> > based
> > on boot mode during SPL execution, by extending the probe function
> > accordingly.
> 
> This is just a very simple fs loader. This is totally up to user how
> they want to scale it up, may be adding the function to populate the fs
> loader nodes, or loading the images based on boot storages ordering in
> DTS?

This would require on-the-fly FDT manipulation. Again something that can
be done, but challenging in tight environments. I'm not arguing against
FS loader, it is very useful, we actually use it ourselves (not
upstream yet) for use cases involving remote core program loading...

> > > > > and not addressing the need to probe the boot peripheral.
> > > You can add more different probing method in function called
> > > "fs_loader_probe". Current fs_loader supports block(sdmmc, emmc,
> > > etc...) probing, and with
> > > the patches attached support QSPI probing.
> > > 
> > > Another idea come to mind, we can use fs_loader for loading FIT
> > > boot
> > > image into RAM, and boot from RAM with existing SPL loader
> > > framework,
> > > but i'm not sure this implementation fit to your use case?
> > Unfortunately for what I'm working on there is no space for this. It
> > would be nice to be able to load our "System Firmware" alongside the
> > next stage of U-Boot in a single FIT, and then just extact that
> > firmware
> > image similar to what CONFIG_SPL_FPGA_SUPPORT does in spl_fit.c. 
> > However I must load SYSFW and the U-Boot next stage as two steps
> > (while bringing up DDR in-between....).
> > 
> > As I tried to explain in my earlier email to Simon, I almost see the
> > minimally-intrusive extensions I did to the SPL loader framework via
> > "spl: Make image loader infrastructure more universal" and the FS
> > loader
> > framework to be elements that are orthogonal and can both exist.
> > Maybe
> > FS loader can partially build upon the SPL loader foundation as well?
> 
> Yes, fs loader can be in anywhere, it can be part of SPL loader
> framework as well. It can be as complement to SPL loader also.

Yes exactly.

Thanks,

--
Andreas Dannenberg
Texas Instruments Inc