mbox series

[U-Boot,v2,00/12] System Firmware Loader for TI K3 family SoCs

Message ID 20190604225555.12186-1-dannenberg@ti.com
Headers show
Series System Firmware Loader for TI K3 family SoCs | expand

Message

Andreas Dannenberg June 4, 2019, 10:55 p.m. UTC
Updated version of the SYSFW loader series for K3 family AM654x devices.
The fundamantal approach of tapping into the SPL loader framework has
been kept for reasons discussed already. The series also still uses
"early BSS" in SPL's board_init_f(). I'm well aware of the concerns
previously brought up regarding this mainly by Simon Glass but I have
not been able to find a better / more universal solution for this yet
(one proposal was to move SYSFW loading into board_init_r() which is not
easily solvable as SYSFW is needed to bring up DDR on K3 SoCs). Long
story short I propose to consider the current proposed approach
nevertheless (as it is also used by other platforms) at least as an
initial step, and then migrate once a better solution is available.

I have not yet included support for TI's newest K3 family J721E SoC
which Lokesh posted an initial patch series [5] for due to the
complex dependencies of all the different series we have currently
posted/pending (if I were to add support for J721E which eventually will
be required then the SYSFW loader series would have Lokesh's series as a
pre-requisite as well).

This being said I would like to propose the following staging sequence
for the different TI K3 SoCs patches currently under review:

Step 1) Faiz' "Add Support for eMMC in Am65x-evm" series [1]. It needs
        a small update to actuall allow for eMMC boot I posted earlier.
Step 2) The SYSFW loader series proposed here
Step 3) An updated version (v3) of the AM654x EEPROM support [3].
        Will post this today. 
Step 4) An updated version of Lokesh's "arm: k3: Allow for exclusive
        and shared device requests" series. In addition to a rebase
        such an updated series should include updating power domain
        properties for devices that were added during the previous
        steps.
Step 5) An updated version of Lokesh's "arm: k3: arm64: Initial support
        Texas Instrument's J721E Platform" series [5] also adding
        in the few lines of codes to leverage SYSFW.
Step 6 & beyond) Various rproc patches, etc.


The above is to allow for things to build in a logical order while
avoiding merge conflicts. 1+2+3 added will provide a pretty good initial
working U-Boot using eMMC and SD media for AM654x which is a device
available today plus a foundation for everything else, hence it is at
the top of the list.


Changes since initial submission:
- Dropped patch "armv7R: dts: k3: am654: Update mmc nodes for loading
  sysfw". This is taken care off by the "Add Support for eMMC in
  Am65x-evm" patch series [1] which this series was rebased on.
- Replaced patch "spl: Allow skipping clearing BSS during relocation"
  with a functionally equivalent patch "spl: Allow performing BSS init
  early before board_init_f()" which is a bit more elegant solution
  which itself is a slight evolution what previously posted by Simon
  Goldschmidt [2]
- Collected various review tags


[1] https://patchwork.ozlabs.org/project/uboot/list/?series=111723
[2] https://patchwork.ozlabs.org/patch/1067363/
[3] https://patchwork.ozlabs.org/project/uboot/list/?series=109266
[4] https://patchwork.ozlabs.org/project/uboot/list/?series=109163
[5] https://patchwork.ozlabs.org/project/uboot/list/?series=109296


--
Andreas Dannenberg
Texas Instruments Inc


Andreas Dannenberg (10):
  mmc: am654_sdhci: Allow driver to probe without PDs specified
  spl: Allow performing BSS init early before board_init_f()
  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

 arch/arm/lib/crt0.S                          |  53 ++--
 arch/arm/mach-k3/Kconfig                     |  39 +++
 arch/arm/mach-k3/Makefile                    |   3 +
 arch/arm/mach-k3/am6_init.c                  |  27 +-
 arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
 arch/arm/mach-k3/sysfw-loader.c              | 260 +++++++++++++++++++
 board/ti/am65x/Kconfig                       |   1 +
 board/ti/am65x/README                        |  52 ++++
 common/spl/Kconfig                           |  10 +
 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/am654_sdhci.c                    |  16 +-
 include/configs/am65x_evm.h                  |  30 ++-
 include/spl.h                                |  26 ++
 18 files changed, 580 insertions(+), 57 deletions(-)
 create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
 create mode 100644 arch/arm/mach-k3/sysfw-loader.c

Comments

Lokesh Vutla June 5, 2019, 6:22 a.m. UTC | #1
On 05/06/19 4:25 AM, Andreas Dannenberg wrote:
> Updated version of the SYSFW loader series for K3 family AM654x devices.
> The fundamantal approach of tapping into the SPL loader framework has
> been kept for reasons discussed already. The series also still uses
> "early BSS" in SPL's board_init_f(). I'm well aware of the concerns
> previously brought up regarding this mainly by Simon Glass but I have
> not been able to find a better / more universal solution for this yet
> (one proposal was to move SYSFW loading into board_init_r() which is not
> easily solvable as SYSFW is needed to bring up DDR on K3 SoCs). Long
> story short I propose to consider the current proposed approach
> nevertheless (as it is also used by other platforms) at least as an
> initial step, and then migrate once a better solution is available.

tested this series on AM654 evm using SD boot. FWIW:
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>



> 
> I have not yet included support for TI's newest K3 family J721E SoC
> which Lokesh posted an initial patch series [5] for due to the
> complex dependencies of all the different series we have currently
> posted/pending (if I were to add support for J721E which eventually will
> be required then the SYSFW loader series would have Lokesh's series as a
> pre-requisite as well).
> 
> This being said I would like to propose the following staging sequence
> for the different TI K3 SoCs patches currently under review:
> 
> Step 1) Faiz' "Add Support for eMMC in Am65x-evm" series [1]. It needs
>         a small update to actuall allow for eMMC boot I posted earlier.
> Step 2) The SYSFW loader series proposed here
> Step 3) An updated version (v3) of the AM654x EEPROM support [3].
>         Will post this today. 

I would like to see the above 3 series be merged first. Will take care of the
rest of the J721e support and other.

> Step 4) An updated version of Lokesh's "arm: k3: Allow for exclusive
>         and shared device requests" series. In addition to a rebase
>         such an updated series should include updating power domain
>         properties for devices that were added during the previous
>         steps.
> Step 5) An updated version of Lokesh's "arm: k3: arm64: Initial support
>         Texas Instrument's J721E Platform" series [5] also adding
>         in the few lines of codes to leverage SYSFW.
> Step 6 & beyond) Various rproc patches, etc.

I have a slightly different order that you mentioned. Will repost everything
once the first 3 steps are sorted out.

Thanks and regards,
Lokesh

> 
> 
> The above is to allow for things to build in a logical order while
> avoiding merge conflicts. 1+2+3 added will provide a pretty good initial
> working U-Boot using eMMC and SD media for AM654x which is a device
> available today plus a foundation for everything else, hence it is at
> the top of the list.
> 
> 
> Changes since initial submission:
> - Dropped patch "armv7R: dts: k3: am654: Update mmc nodes for loading
>   sysfw". This is taken care off by the "Add Support for eMMC in
>   Am65x-evm" patch series [1] which this series was rebased on.
> - Replaced patch "spl: Allow skipping clearing BSS during relocation"
>   with a functionally equivalent patch "spl: Allow performing BSS init
>   early before board_init_f()" which is a bit more elegant solution
>   which itself is a slight evolution what previously posted by Simon
>   Goldschmidt [2]
> - Collected various review tags
> 
> 
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=111723
> [2] https://patchwork.ozlabs.org/patch/1067363/
> [3] https://patchwork.ozlabs.org/project/uboot/list/?series=109266
> [4] https://patchwork.ozlabs.org/project/uboot/list/?series=109163
> [5] https://patchwork.ozlabs.org/project/uboot/list/?series=109296
> 
> 
> --
> Andreas Dannenberg
> Texas Instruments Inc
> 
> 
> Andreas Dannenberg (10):
>   mmc: am654_sdhci: Allow driver to probe without PDs specified
>   spl: Allow performing BSS init early before board_init_f()
>   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
> 
>  arch/arm/lib/crt0.S                          |  53 ++--
>  arch/arm/mach-k3/Kconfig                     |  39 +++
>  arch/arm/mach-k3/Makefile                    |   3 +
>  arch/arm/mach-k3/am6_init.c                  |  27 +-
>  arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
>  arch/arm/mach-k3/sysfw-loader.c              | 260 +++++++++++++++++++
>  board/ti/am65x/Kconfig                       |   1 +
>  board/ti/am65x/README                        |  52 ++++
>  common/spl/Kconfig                           |  10 +
>  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/am654_sdhci.c                    |  16 +-
>  include/configs/am65x_evm.h                  |  30 ++-
>  include/spl.h                                |  26 ++
>  18 files changed, 580 insertions(+), 57 deletions(-)
>  create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
>  create mode 100644 arch/arm/mach-k3/sysfw-loader.c
>
Andreas Dannenberg June 5, 2019, 3:15 p.m. UTC | #2
On Wed, Jun 05, 2019 at 11:52:52AM +0530, Lokesh Vutla wrote:
> 
> 
> On 05/06/19 4:25 AM, Andreas Dannenberg wrote:
> > Updated version of the SYSFW loader series for K3 family AM654x devices.
> > The fundamantal approach of tapping into the SPL loader framework has
> > been kept for reasons discussed already. The series also still uses
> > "early BSS" in SPL's board_init_f(). I'm well aware of the concerns
> > previously brought up regarding this mainly by Simon Glass but I have
> > not been able to find a better / more universal solution for this yet
> > (one proposal was to move SYSFW loading into board_init_r() which is not
> > easily solvable as SYSFW is needed to bring up DDR on K3 SoCs). Long
> > story short I propose to consider the current proposed approach
> > nevertheless (as it is also used by other platforms) at least as an
> > initial step, and then migrate once a better solution is available.
> 
> tested this series on AM654 evm using SD boot. FWIW:
> Tested-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks Lokesh.


> > I have not yet included support for TI's newest K3 family J721E SoC
> > which Lokesh posted an initial patch series [5] for due to the
> > complex dependencies of all the different series we have currently
> > posted/pending (if I were to add support for J721E which eventually will
> > be required then the SYSFW loader series would have Lokesh's series as a
> > pre-requisite as well).
> > 
> > This being said I would like to propose the following staging sequence
> > for the different TI K3 SoCs patches currently under review:
> > 
> > Step 1) Faiz' "Add Support for eMMC in Am65x-evm" series [1]. It needs
> >         a small update to actuall allow for eMMC boot I posted earlier.
> > Step 2) The SYSFW loader series proposed here
> > Step 3) An updated version (v3) of the AM654x EEPROM support [3].
> >         Will post this today. 
> 
> I would like to see the above 3 series be merged first. Will take care of the
> rest of the J721e support and other.

Yes that's what I'm proposing.


> > Step 4) An updated version of Lokesh's "arm: k3: Allow for exclusive
> >         and shared device requests" series. In addition to a rebase
> >         such an updated series should include updating power domain
> >         properties for devices that were added during the previous
> >         steps.
> > Step 5) An updated version of Lokesh's "arm: k3: arm64: Initial support
> >         Texas Instrument's J721E Platform" series [5] also adding
> >         in the few lines of codes to leverage SYSFW.
> > Step 6 & beyond) Various rproc patches, etc.
> 
> I have a slightly different order that you mentioned. Will repost everything
> once the first 3 steps are sorted out.

I don't have an issue with changing the order of what happens past step
3. But without the first three things (or first two, really) in place, we
are kind of stuck turning in circles... :)

--
Andreas Dannenberg
Texas Instruments Inc