We needs SPL LIBCOMMON and LIBGENERIC for all boards,
so we can enable them by default and no need to define
in each board.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Few SPL and U-Boot proper configs are common to all rk3399 target
defconfigs, move them and select it from platform kconfig.
Moved configs:
- SPL_ATF
- SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
- SPL_LOAD_FIT
- SPL_CLK if SPL
- SPL_PINCTRL if SPL
- SPL_RAM if SPL
- SPL_REGMAP if SPL
- SPL_SYSCON if SPL
- CLK
- FIT
- PINCTRL
- RAM
- REGMAP
- SYSCON
- DM_PMIC
- DM_REGULATOR_FIXED
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add default SPL_FIT_GENERATOR py script for rockchip platforms if
specific target enabled SPL_LOAD_FIT.
So, this would help get rid of explicitly mentioning the default
SPL FIT generator in defconfigs. however some targets, like puma_rk3399
still require their own FIT generator so in those cases the default will
override with defconfig defined generator.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig and migrate existing
values.
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
[trini: Re-run migration]
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SF_DEFAULT_BUS
CONFIG_SF_DEFAULT_CS
CONFIG_SF_DEFAULT_MODE
CONFIG_SF_DEFAULT_SPEED
I use moveconfig script and then manual check on generated u-boot.cfg
to solve the remaining issue.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add board support for Ficus EE board from Vamrs. This board utilizes
common Rock960 family support.
Following peripherals are tested and known to work:
* Gigabit Ethernet
* USB 2.0
* MMC
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
[Reworked based on common Rock960 family support]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
