Message ID | 20190604225555.12186-1-dannenberg@ti.com |
---|---|
Headers | show |
Series | System Firmware Loader for TI K3 family SoCs | expand |
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 >
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