bootcmd_ti_mmc had cpsw0_qsgmii_phyinit related scripts even though this
was only relevant for the j721e/j7200 SoCs. This patch instead factors
out those scripts into a generic 'board_init' which is called as part of
bootcmd_ti_mmc.

This allows boards to more easily add custom behaviour to the ti_mmc
bootflow instead of having to modify the ti_common.env file.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

Since commit 27cc5951c862 ("include: env: ti: add default for
do_main_cpsw0_qsgmii_phyinit"), the value of the environment variable
do_main_cpsw0_qsgmii_phyinit happened to remain '0' and couldn't be
changed without user intervention. This behavior is due to the following
cyclic dependency:
A) ti_common.env sets do_main_cpsw0_qsgmii_phyinit to '0' and its value
   can only be updated automatically by main_cpsw0_qsgmii_phyinit.
B) main_cpsw0_qsgmii_phyinit is defined in j721e.env and it can run only
   if 'do_main_cpsw0_qsgmii_phyinit' is already '1' which isn't possible
   unless the user manually assigns the value.

Fix the aforementioned cyclic dependency by using board_late_init() to
detect the QSGMII Daughtercard and set do_main_cpsw0_qsgmii_phyinit.

Additionally, to address the issue of do_main_cpsw0_qsgmii_phyinit being
'undefined' for other platforms, replace:
	if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1;
with:
	if env exists do_main_cpsw0_qsgmii_phyinit;
in ti_common.env.

Fixes: 27cc5951c862 ("include: env: ti: add default for do_main_cpsw0_qsgmii_phyinit")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>

Add omap common environment variables to .env. We retain the old-style C
environment .h files to maintain compatibility with other omap devices that
have not moved to using .env yet.

Signed-off-by: Anurag Dutta <a-dutta@ti.com>

As the size of 64b ARM kernels, DTs, vendor firmware, and initial ram
disks continues to grow, the 256MB size limit set aside for image
processing by the bootm command has become too small for some K3
reference boards.

For ARMv7 removing this limit could introduce issues so move the
bootm_size variable to ti_armv7_keystone2.env and remove the limit for
any board using a TI K3 SoC.

Signed-off-by: Bryan Brattlof <bb@ti.com>

As AM57x uses overlays for display and camera interfaces, add support to
load DT overlay files to MMC boot.

Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Anurag Dutta <a-dutta@ti.com>

Add Android bootflow support for AM62X SK EVM board with
new android boot method.

To build for AM62x for Android, we use the
am62x_a53_android.config fragment when building A53 bootloaders:

  $ make am62x_evm_a53_defconfig
  $ make am62x_a53_android.config
  $ make

Co-developed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>

findfdt is used by bootcmd_ti_mmc by default which used to help populate
the fdtfile. The users of findfdt from bootcmd_ti_mmc have migrated to
ti_set_fdt_env for populating fdtfile; Hence, findfdt can be removed from
bootcmd_ti_mmc having no-impact for any platform.

Remove findfdt to not print out the warning that gets set after calling
ti_set_fdt_env. viz.
"echo WARN: fdtfile already set. Stop using findfdt in script"

Signed-off-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

name_fdt is kept for backward compatibility but it depends on EEPROM
detection logic and some of the TI K3 platforms don't have that anymore
which causes boot failure in legacy boot flow using bootcmd_ti_mmc.

K2g platforms which uses the same file have their own override causing
this change to be no-impact for them.

Replacing name_fdt usage to fdtfile as fdtfile is populated based on
CONFIG_DEFAULT_DEVICE_TREE after using ti_set_fdt_env.

Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

According to [0], raw access to mmc should not have mmcpart in the
entry. This was fixed in k3_dfu_combined.env but k3_dfu.env had been
overlooked.

[0] doc/usage/dfu.rst

Fixes: 53b406369e9d ("DFU: Check the number of arguments and argument string strictly")
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>

Secure firmwares must be loaded if SOC is secure,
currently rproc framework chooses non-secure firmware always.

So adding support to load secure firmware, when SOC is secure

Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>