Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
Hi Tom, On Wed, May 15, 2019 at 11:16:43AM -0400, Tom Rini wrote: > On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote: > > > TI K3 SoCs like the AM654x devices are fundamentally dependent on a > > firmware called SYSFW (System Firmware) being loaded into the dedicated > > DMSC (Device Management and Security Controller) processor to provide > > various services via TISCI (Texas Instruments System Control Interface) > > to manage device aspects such as core bringup, power, clocks, security, > > and so on across the entire SoC. > [snip] > > 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), being heavier on resource usage (needing to use ENV to pass > > parameters), and not addressing the need to probe the boot peripheral. > > This particular framework works well for use cases requiring to load > > firmware from FS-based media once DDR is up and U-Boot is in a more > > "initialized" state but it is not a one-fits all solution for very > > early use in SPL board_init_f() accross different boot modes. > > I think one thing that might help here is to post this alternative > solution and provide the 'size' information for both series. In > addition, build something like am335x_evm and socfpga_stratix10 for both > series and include their before/after 'size' info too. Thanks! I collected some data how this series extending the SPL framework affects the size of the SPL, the increase is quite small nevertheless there is an increase that may or may not be an issue on certain platforms: |SPL File| v2019.07-rc2 | plus SYSFW loader series --++--+- am335x_evm| MLO| 109,884 | 109,964 (+120 bytes) socfpga_stratix10 | u-boot-spl.bin | 78,760 | 78,872 (+112 bytes) Then, I also collected some data comparing how the SYSFW loader based on extending the SPL loader function (this patch series) stacks up against a basic FS loader-based implementation of the SYSFW loader functionality from an AM654 R5 SPL size POV: What | SPL (tiboot3.bin) | Solution Size (bytes) --+---+--- No SYSFW Loader | 91,725 | 0 (base for comp) SPL loader-based solution | 93,265 | 1,540 FS loader-based solution | 95,417 | 3,692 Basically the FS loader-based solution is ~2x bigger than the SPL-loader based solution, while also dropping eMMC/SD partition- and sector-based RAW support. The difference between the solutions is 2,152 and will be even larger once RAW boot support is added in. Will post the FS loader- based solution for reference next. One more word on why I am so concerned with memory. Below is a rough memory map of our SPL running on an R5 core out of on-chip MCU SRAM (512KB on AM654x). The stack during "pre-relocation" SPL is growing down towards where the actual SPL image is. Inside board_init_f() the SP currently sits at SP=0x41c25b10. The image size of an R5 SPL with the SPL loader-based solution as proposed with this patch series sits at 93,265 bytes, effectively leaving 61,119 bytes to be shared between features that are yet to get added to tiboot3.bin (such as board-detection EEPROM support, other early boot remote core loading, additions to dtb), and what can be used as stack by board_init_f() and its callees. Hence, every kilobyte really counts. +---+ 0x41c8 |BSS| CONFIG_SPL_BSS_MAX_SIZE=0x5000 +---+ | malloc | CONFIG_SYS_MALLOC_F_LEN=0x55000 +---+ |gd | +---+ | Stack | +---+ | | \ ~ ~ |== Room for stack growth | | / and R5 SPL feature +---+ additions | | |tiboot3.bin| | (SPL) | | | +---+ 0x41c0 -- Andreas Dannenberg Texas Instruments Inc ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
Hi TF,
On Mon, May 13, 2019 at 01:37:22PM +, Chee, Tien Fong wrote:
> On Wed, 2019-05-08 at 13:43 -0500, dannenb...@ti.com wrote:
> > Hi TF,
> > thanks for chiming in. Comments inlined...
> >
> > On Wed, May 08, 2019 at 04:31:35AM +, 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 1 3>;
> > > + };
> > > +};
> > > +
> > > +&fpga_mgr {
> > > + u-boot,dm-pre-reloc;
> > > + firmware-loader = <&fs_loader0>;
> > > + altr,bitstream = "30";
> > > +};
> > 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. A
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
Hi Tom, On Wed, May 15, 2019 at 11:16:43AM -0400, Tom Rini wrote: > On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote: > > > TI K3 SoCs like the AM654x devices are fundamentally dependent on a > > firmware called SYSFW (System Firmware) being loaded into the dedicated > > DMSC (Device Management and Security Controller) processor to provide > > various services via TISCI (Texas Instruments System Control Interface) > > to manage device aspects such as core bringup, power, clocks, security, > > and so on across the entire SoC. > [snip] > > 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), being heavier on resource usage (needing to use ENV to pass > > parameters), and not addressing the need to probe the boot peripheral. > > This particular framework works well for use cases requiring to load > > firmware from FS-based media once DDR is up and U-Boot is in a more > > "initialized" state but it is not a one-fits all solution for very > > early use in SPL board_init_f() accross different boot modes. > > I think one thing that might help here is to post this alternative > solution and provide the 'size' information for both series. In > addition, build something like am335x_evm and socfpga_stratix10 for both > series and include their before/after 'size' info too. Thanks! thanks for looking at this more closely. Sure, let me collect some data on this front and also post the alternative solution. It won't be a completely fair comparison however as the alternative solution only supports FS-based MMC boot, whereas the solution proposed here also supports eMMC/SD RAW boot, both partition and sector-based (and a combination thereof). -- Andreas Dannenberg Texas Instruments Inc ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote: > TI K3 SoCs like the AM654x devices are fundamentally dependent on a > firmware called SYSFW (System Firmware) being loaded into the dedicated > DMSC (Device Management and Security Controller) processor to provide > various services via TISCI (Texas Instruments System Control Interface) > to manage device aspects such as core bringup, power, clocks, security, > and so on across the entire SoC. [snip] > 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), being heavier on resource usage (needing to use ENV to pass > parameters), and not addressing the need to probe the boot peripheral. > This particular framework works well for use cases requiring to load > firmware from FS-based media once DDR is up and U-Boot is in a more > "initialized" state but it is not a one-fits all solution for very > early use in SPL board_init_f() accross different boot modes. I think one thing that might help here is to post this alternative solution and provide the 'size' information for both series. In addition, build something like am335x_evm and socfpga_stratix10 for both series and include their before/after 'size' info too. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
On Wed, 2019-05-08 at 13:43 -0500, dannenb...@ti.com wrote:
> Hi TF,
> thanks for chiming in. Comments inlined...
>
> On Wed, May 08, 2019 at 04:31:35AM +, 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.
> >
> > >
> > > >
> > > > 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
>
> >
> > 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 1 3>;
> > + };
> > +};
> > +
> > +&fpga_mgr {
> > + u-boot,dm-pre-reloc;
> > + firmware-loader = <&fs_loader0>;
> > + altr,bitstream = "30";
> > +};
> 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?
>
> >
> >
> > >
> > > >
> > > > 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
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
Am 08.05.2019 um 20:04 schrieb Andreas Dannenberg: Hi Simon, comments inlined... On Tue, May 07, 2019 at 10:00:03PM +0200, Simon Goldschmidt wrote: On 07.05.19 19:25, Andreas Dannenberg wrote: TI K3 SoCs like the AM654x devices are fundamentally dependent on a firmware called SYSFW (System Firmware) being loaded into the dedicated DMSC (Device Management and Security Controller) processor to provide various services via TISCI (Texas Instruments System Control Interface) to manage device aspects such as core bringup, power, clocks, security, and so on across the entire SoC. Currently public U-Boot does not boot on an actual AM654x EVM due to the missing loading and startup of SYSFW, with this being the only piece missing preventing a successful boot from SD/MMC-type media. This gap is addressed with this patch series. Note that the loading and starting of SYSFW is done in the context of board_init_f() in SPL which poses some unique challenges due to the very constrained nature of this environment (minimal amount of SRAM, no DDR yet available). In order to be as lean as possible on resource use an approach was chosen that extends the existing SPL loader framework to be usable beyond the usual "loading U-Boot" use case. While this patch series only makes changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS- and sector/partition-based RAW boot at this time we have this solution in production today but extended to SPI/OSPI and Y-Modem without any issues. 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), being heavier on resource usage (needing to use ENV to pass parameters), and not addressing the need to probe the boot peripheral. This particular framework works well for use cases requiring to load firmware from FS-based media once DDR is up and U-Boot is in a more "initialized" state but it is not a one-fits all solution for very early use in SPL board_init_f() accross different boot modes. And would it be an option to improve the loader (maybe dropping the "fs" from its name)? I think it's an "fs" loader because its idea has been copied from Linux. I think in U-Boot, it's more common to have things at a raw offset instead of a file system. Just thinking... Agreed this can be refactored and extended and would be useful - except for some very memory-constrained situations, see below. And the current state of that fs_loader is like it is because it fits its single user (socfpga stratix 10), I think. What I needed was something very small as even with the here proposed solution that heavily re-uses SPL loader code there is only about 61KB left at the moment in the SRAM memory region SPL executes from, and some of that 61KB will be used by the stack, and some will be used by other features still needing to get added to the SPL image unrelated to the loader functionality under discussion. So space is super tight, and literally every KB counts. I wish the environment was less constrained from a memory POV... I can understand your point on memory usage, but fs_loader started by Intel is used in SPL, too. And while they obviously aren't as tight with memory there (although I think this is pre DDR, too), I still think we should come up with *one* solution, not two. Anyway, even if you do need yet another loader, would it make sense to create a common file instead of adding this in your arch/mach? Be careful not to be mislead from what I'm actually proposing here: 1) A method to load, start (via rproc) and configure the TI K3 System Firmware with the patch "arm: K3: Introduce System Firmware loader framework" under arch/mach. You can review this patch, 95% of this code is only applicable to TI K3 devices, and not any other device, platform, or vendor. The actual "loading" part you are concerned with is nothing more than a single call over to spl_mmc_load() located in the SPL framework. So the logical place for the "SYSFW Loader" is said arm/mach location. OK. 2) A method to re-use most/all of the SPL loader code including peripheral init/probe functionality most commonly used for only loading U-Boot by exposing the core loader functions as an API. For MMC/SD, this is introduced with the patch "spl: Make image loader infrastructure more universal" and doesn't really add any code at all. This has the advantage of minimizing memory footprint and code duplication (FS loader replicates some of what the SPL loader does, and even more so if extended). I argue this method of opening up the SPL loader is actually orthogonal to the current FS loader framework, and the FS loader framework could as well tap into the SPL loader code as well as it extends and grows to avoid duplication. You're talking about 3/13 here? I think that's a good appr
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
Hi TF,
thanks for chiming in. Comments inlined...
On Wed, May 08, 2019 at 04:31:35AM +, 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.
> > > 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.
> 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 1 3>;
> + };
> +};
> +
> +&fpga_mgr {
> + u-boot,dm-pre-reloc;
> + firmware-loader = <&fs_loader0>;
> + altr,bitstream = "30";
> +};
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?
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.
>
> > > 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?
--
Andreas Dannenberg
Texas Instruments Inc
>
> > > This particular framework works well for use cases requiring to
> > > load
> > > firmware from FS-based media once DDR is up and U-Boot is in a more
> > > "initialized" state but it is not a one-fits all solution for very
> > > early use in SPL board_init_f() accross different boot modes.
> > And would it be an option to improve the loader (maybe dropping the
> > "fs"
> > from its name)? I think it's an "fs" loader because its idea has
> > been
> > copied from Linux. I think in U-Boot, it's more common to have things
> > at
> > a raw offset instead of a file system. Just thinking...
>
> Current fs_loader only support filesystem, and i agree that it made
> sense to remove the "fs" once it supports the RAW offset as well.
>
> Thanks.
>
> Regards,
> TF
>
> >
> > And the current state of that fs_loader is like it is because it
> > fits
> > its single user (socfpga stratix 10), I think.
> >
> > Anyway, even if you do need yet another loader, would it make sense
> > to
> > create a common file instead of adding this in your arch/mach?
> >
> > Regards,
> > Simon
> >
> > >
> > >
> > > Andreas Dannenberg (10):
> > > mmc: k3_arasan: Allow driver t
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
Hi Simon, comments inlined... On Tue, May 07, 2019 at 10:00:03PM +0200, Simon Goldschmidt wrote: > > > On 07.05.19 19:25, Andreas Dannenberg wrote: > > TI K3 SoCs like the AM654x devices are fundamentally dependent on a > > firmware called SYSFW (System Firmware) being loaded into the dedicated > > DMSC (Device Management and Security Controller) processor to provide > > various services via TISCI (Texas Instruments System Control Interface) > > to manage device aspects such as core bringup, power, clocks, security, > > and so on across the entire SoC. > > > > Currently public U-Boot does not boot on an actual AM654x EVM due to > > the missing loading and startup of SYSFW, with this being the only piece > > missing preventing a successful boot from SD/MMC-type media. This gap > > is addressed with this patch series. > > > > Note that the loading and starting of SYSFW is done in the context of > > board_init_f() in SPL which poses some unique challenges due to the very > > constrained nature of this environment (minimal amount of SRAM, no DDR > > yet available). > > > > In order to be as lean as possible on resource use an approach was chosen > > that extends the existing SPL loader framework to be usable beyond the > > usual "loading U-Boot" use case. While this patch series only makes > > changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS- > > and sector/partition-based RAW boot at this time we have this solution > > in production today but extended to SPI/OSPI and Y-Modem without any > > issues. > > > > 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), being heavier on resource usage (needing to use ENV to pass > > parameters), and not addressing the need to probe the boot peripheral. > > This particular framework works well for use cases requiring to load > > firmware from FS-based media once DDR is up and U-Boot is in a more > > "initialized" state but it is not a one-fits all solution for very > > early use in SPL board_init_f() accross different boot modes. > > And would it be an option to improve the loader (maybe dropping the "fs" > from its name)? I think it's an "fs" loader because its idea has been copied > from Linux. I think in U-Boot, it's more common to have things at a raw > offset instead of a file system. Just thinking... Agreed this can be refactored and extended and would be useful - except for some very memory-constrained situations, see below. > > And the current state of that fs_loader is like it is because it fits its > single user (socfpga stratix 10), I think. What I needed was something very small as even with the here proposed solution that heavily re-uses SPL loader code there is only about 61KB left at the moment in the SRAM memory region SPL executes from, and some of that 61KB will be used by the stack, and some will be used by other features still needing to get added to the SPL image unrelated to the loader functionality under discussion. So space is super tight, and literally every KB counts. I wish the environment was less constrained from a memory POV... > Anyway, even if you do need yet another loader, would it make sense to > create a common file instead of adding this in your arch/mach? Be careful not to be mislead from what I'm actually proposing here: 1) A method to load, start (via rproc) and configure the TI K3 System Firmware with the patch "arm: K3: Introduce System Firmware loader framework" under arch/mach. You can review this patch, 95% of this code is only applicable to TI K3 devices, and not any other device, platform, or vendor. The actual "loading" part you are concerned with is nothing more than a single call over to spl_mmc_load() located in the SPL framework. So the logical place for the "SYSFW Loader" is said arm/mach location. 2) A method to re-use most/all of the SPL loader code including peripheral init/probe functionality most commonly used for only loading U-Boot by exposing the core loader functions as an API. For MMC/SD, this is introduced with the patch "spl: Make image loader infrastructure more universal" and doesn't really add any code at all. This has the advantage of minimizing memory footprint and code duplication (FS loader replicates some of what the SPL loader does, and even more so if extended). I argue this method of opening up the SPL loader is actually orthogonal to the current FS loader framework, and the FS loader framework could as well tap into the SPL loader code as well as it extends and grows to avoid duplication. -- Andreas Dannenberg Texas Instruments Inc > > Regards, > Simon > > > > > > > Andreas Dannenberg (10): > >mmc: k3_arasan: Allow driver to probe without PDs specified > >spl: Allow skipping clearing BSS during relocation > >spl: Ma
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
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.
> > being heavier on resource usage (needing to use ENV to pass
> > parameters),
ENV is optional, you can use DTS. 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 1 3>;
+ };
+};
+
+&fpga_mgr {
+ u-boot,dm-pre-reloc;
+ firmware-loader = <&fs_loader0>;
+ altr,bitstream = "30";
+};
> > 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?
> > This particular framework works well for use cases requiring to
> > load
> > firmware from FS-based media once DDR is up and U-Boot is in a more
> > "initialized" state but it is not a one-fits all solution for very
> > early use in SPL board_init_f() accross different boot modes.
> And would it be an option to improve the loader (maybe dropping the
> "fs"
> from its name)? I think it's an "fs" loader because its idea has
> been
> copied from Linux. I think in U-Boot, it's more common to have things
> at
> a raw offset instead of a file system. Just thinking...
Current fs_loader only support filesystem, and i agree that it made
sense to remove the "fs" once it supports the RAW offset as well.
Thanks.
Regards,
TF
>
> And the current state of that fs_loader is like it is because it
> fits
> its single user (socfpga stratix 10), I think.
>
> Anyway, even if you do need yet another loader, would it make sense
> to
> create a common file instead of adding this in your arch/mach?
>
> Regards,
> Simon
>
> >
> >
> > Andreas Dannenberg (10):
> > mmc: k3_arasan: Allow driver to probe without PDs specified
> > spl: Allow skipping clearing BSS during relocation
> > spl: Make image loader infrastructure more universal
> > arm: K3: Introduce System Firmware loader framework
> > armV7R: K3: am654: Allow using SPL BSS pre-relocation
> > armv7R: K3: am654: Use full malloc implementation in SPL
> > armV7R: K3: am654: Load SYSFW binary and config from boot media
> > configs: am65x_evm_r5: All sysfw to be loaded via MMC
> > configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
> > configs: am65x_hs_evm: Add Support for eMMC boot
> >
> > Faiz Abbas (2):
> > configs: am65x_evm: Add Support for eMMC boot
> > am65x: README: Add eMMC layout and flash instructions
> >
> > Lokesh Vutla (1):
> > armv7R: dts: k3: am654: Update mmc nodes for loading sysfw
> >
> > arch/arm/dts/k3-am654-r5-base-board.dts | 18 ++
> > arch/arm/lib/crt0.S | 3 +
> > arch/arm/mach-k3/Kconfig | 40 +++
> > arch/arm/mach-k3/Makefile| 1 +
> > arch/arm/mach-k3/am6_init.c | 34 ++-
> > arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 +
> > arch/arm/mach-k3/sysfw-loader.c | 263
> > +++
> > board/ti/am65x/Kconfig | 1 +
> > board/ti/am65x/README| 52
> > common/spl/Kconfig | 13 +
> > common/spl/spl_fit.c | 14 +
> > common/spl/spl_mmc.c | 76 --
> > configs/am65x_evm_a53_defconfig | 2 +
> > configs/am65x_evm_r5_defconfig | 7 +-
> > configs/am65x_hs_evm_a53_defconfig | 2 +
> > configs/am65x_hs_evm_r5_defconfig| 7 +-
> > drivers/mmc/k3_arsan_sdhci.c | 16 +-
> > include/configs/am65x_evm.h | 30 ++-
> > include/spl.h| 26 ++
> > 19 files changed, 577 insertions(+), 40 deletions(-)
> > create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
> > create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> > From ff0fa68b8141fa7c83b3b42e7d6cf5a6bc27c980 Mon Sep 17 00:00:00 2001
From: Tien Fong Chee
Date: Mon, 15 Apr 2019 14:02:44 +0800
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
On 07.05.19 19:25, Andreas Dannenberg wrote: TI K3 SoCs like the AM654x devices are fundamentally dependent on a firmware called SYSFW (System Firmware) being loaded into the dedicated DMSC (Device Management and Security Controller) processor to provide various services via TISCI (Texas Instruments System Control Interface) to manage device aspects such as core bringup, power, clocks, security, and so on across the entire SoC. Currently public U-Boot does not boot on an actual AM654x EVM due to the missing loading and startup of SYSFW, with this being the only piece missing preventing a successful boot from SD/MMC-type media. This gap is addressed with this patch series. Note that the loading and starting of SYSFW is done in the context of board_init_f() in SPL which poses some unique challenges due to the very constrained nature of this environment (minimal amount of SRAM, no DDR yet available). In order to be as lean as possible on resource use an approach was chosen that extends the existing SPL loader framework to be usable beyond the usual "loading U-Boot" use case. While this patch series only makes changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS- and sector/partition-based RAW boot at this time we have this solution in production today but extended to SPI/OSPI and Y-Modem without any issues. 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), being heavier on resource usage (needing to use ENV to pass parameters), and not addressing the need to probe the boot peripheral. This particular framework works well for use cases requiring to load firmware from FS-based media once DDR is up and U-Boot is in a more "initialized" state but it is not a one-fits all solution for very early use in SPL board_init_f() accross different boot modes. And would it be an option to improve the loader (maybe dropping the "fs" from its name)? I think it's an "fs" loader because its idea has been copied from Linux. I think in U-Boot, it's more common to have things at a raw offset instead of a file system. Just thinking... And the current state of that fs_loader is like it is because it fits its single user (socfpga stratix 10), I think. Anyway, even if you do need yet another loader, would it make sense to create a common file instead of adding this in your arch/mach? Regards, Simon Andreas Dannenberg (10): mmc: k3_arasan: Allow driver to probe without PDs specified spl: Allow skipping clearing BSS during relocation spl: Make image loader infrastructure more universal arm: K3: Introduce System Firmware loader framework armV7R: K3: am654: Allow using SPL BSS pre-relocation armv7R: K3: am654: Use full malloc implementation in SPL armV7R: K3: am654: Load SYSFW binary and config from boot media configs: am65x_evm_r5: All sysfw to be loaded via MMC configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC configs: am65x_hs_evm: Add Support for eMMC boot Faiz Abbas (2): configs: am65x_evm: Add Support for eMMC boot am65x: README: Add eMMC layout and flash instructions Lokesh Vutla (1): armv7R: dts: k3: am654: Update mmc nodes for loading sysfw arch/arm/dts/k3-am654-r5-base-board.dts | 18 ++ arch/arm/lib/crt0.S | 3 + arch/arm/mach-k3/Kconfig | 40 +++ arch/arm/mach-k3/Makefile| 1 + arch/arm/mach-k3/am6_init.c | 34 ++- arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 + arch/arm/mach-k3/sysfw-loader.c | 263 +++ board/ti/am65x/Kconfig | 1 + board/ti/am65x/README| 52 common/spl/Kconfig | 13 + common/spl/spl_fit.c | 14 + common/spl/spl_mmc.c | 76 -- configs/am65x_evm_a53_defconfig | 2 + configs/am65x_evm_r5_defconfig | 7 +- configs/am65x_hs_evm_a53_defconfig | 2 + configs/am65x_hs_evm_r5_defconfig| 7 +- drivers/mmc/k3_arsan_sdhci.c | 16 +- include/configs/am65x_evm.h | 30 ++- include/spl.h| 26 ++ 19 files changed, 577 insertions(+), 40 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h create mode 100644 arch/arm/mach-k3/sysfw-loader.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
TI K3 SoCs like the AM654x devices are fundamentally dependent on a firmware called SYSFW (System Firmware) being loaded into the dedicated DMSC (Device Management and Security Controller) processor to provide various services via TISCI (Texas Instruments System Control Interface) to manage device aspects such as core bringup, power, clocks, security, and so on across the entire SoC. Currently public U-Boot does not boot on an actual AM654x EVM due to the missing loading and startup of SYSFW, with this being the only piece missing preventing a successful boot from SD/MMC-type media. This gap is addressed with this patch series. Note that the loading and starting of SYSFW is done in the context of board_init_f() in SPL which poses some unique challenges due to the very constrained nature of this environment (minimal amount of SRAM, no DDR yet available). In order to be as lean as possible on resource use an approach was chosen that extends the existing SPL loader framework to be usable beyond the usual "loading U-Boot" use case. While this patch series only makes changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS- and sector/partition-based RAW boot at this time we have this solution in production today but extended to SPI/OSPI and Y-Modem without any issues. 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), being heavier on resource usage (needing to use ENV to pass parameters), and not addressing the need to probe the boot peripheral. This particular framework works well for use cases requiring to load firmware from FS-based media once DDR is up and U-Boot is in a more "initialized" state but it is not a one-fits all solution for very early use in SPL board_init_f() accross different boot modes. Andreas Dannenberg (10): mmc: k3_arasan: Allow driver to probe without PDs specified spl: Allow skipping clearing BSS during relocation spl: Make image loader infrastructure more universal arm: K3: Introduce System Firmware loader framework armV7R: K3: am654: Allow using SPL BSS pre-relocation armv7R: K3: am654: Use full malloc implementation in SPL armV7R: K3: am654: Load SYSFW binary and config from boot media configs: am65x_evm_r5: All sysfw to be loaded via MMC configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC configs: am65x_hs_evm: Add Support for eMMC boot Faiz Abbas (2): configs: am65x_evm: Add Support for eMMC boot am65x: README: Add eMMC layout and flash instructions Lokesh Vutla (1): armv7R: dts: k3: am654: Update mmc nodes for loading sysfw arch/arm/dts/k3-am654-r5-base-board.dts | 18 ++ arch/arm/lib/crt0.S | 3 + arch/arm/mach-k3/Kconfig | 40 +++ arch/arm/mach-k3/Makefile| 1 + arch/arm/mach-k3/am6_init.c | 34 ++- arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 + arch/arm/mach-k3/sysfw-loader.c | 263 +++ board/ti/am65x/Kconfig | 1 + board/ti/am65x/README| 52 common/spl/Kconfig | 13 + common/spl/spl_fit.c | 14 + common/spl/spl_mmc.c | 76 -- configs/am65x_evm_a53_defconfig | 2 + configs/am65x_evm_r5_defconfig | 7 +- configs/am65x_hs_evm_a53_defconfig | 2 + configs/am65x_hs_evm_r5_defconfig| 7 +- drivers/mmc/k3_arsan_sdhci.c | 16 +- include/configs/am65x_evm.h | 30 ++- include/spl.h| 26 ++ 19 files changed, 577 insertions(+), 40 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h create mode 100644 arch/arm/mach-k3/sysfw-loader.c -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
