In case of xSPI bootmode OSPI flash is in DDR mode and needs to be accessed
in multiple of 16bit accesses Hence we cannot parse sysfw.itb FIT image
directly on OSPI flash via MMIO window. So, copy the image to internal
on-chip RAM before parsing the image.
Moreover, board cfg data maybe modified by ROM/TIFS in case of HS platform
and thus cannot reside in OSPI/xSPI and needs to be copied over to
internal OCRAM.
This unblocks OSPI/xSPI boot on HS platforms
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Dave Gerlach <d-gerlach@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
Rename these options so that CONFIG_IS_ENABLED can be used with them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>
Copy the contents of the board config loaded from sysfw.itb into an
EXTBOOT shared memory buffer that gets passed to sciserver. This only
needs to be done if EXTBOOT area has not been populated by ROM code yet.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
If the raw PM support is built in, we are operating in the split
firmware approach mode where PM support is not available. In this
case, skip the board config for this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that there is only one sequence number (rather than both requested and
assigned ones) we can simplify this function. Also update its caller to
simplify the logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Starting J7200 SoC, ROM supports for loading sysfw directly from boot
image. In such cases, SPL need not load sysfw from boot media, but need
to receive boot notification message from sysfw. So separate out
remoteproc calls for system controller from sysfw loader and just
receive the boot notification if sysfw is already loaded.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
This header file should not be included in other header files. Remove it
and use a forward declaration instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.
Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
K3 J721E:
* OSPI boot support
* Support for loading remote cores in R5 SPL
* PMIC ESM Support
* Minor fixes for R5F and C7x remoteproc drivers
K3 AM654:
* Update AVS class 0 voltages.
* Add I2C nodes
DRA7xx/AM57xx:
* Fixed Android boot on AM57xx
AM33/AM43/Davinci:
* switch to driver model for the net and mdio driver for baltos
* Add DM/DTS support for omap video driver
* Enable fastboot on am335x-evm
Add a separate function for printing sysfw version so that it can be
called independently of k3_sysfw_loader.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
System firmware does not guarantee that clocks going out of the device
will be stable during power management configuration. There are some
DCRC errors when SPL tries to get the next stage during eMMC boot after
sysfw pm configuration.
Therefore add a config_pm_pre_callback() to switch off the eMMC clock
before power management and restart it after it is done.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Since ROM configures OSPI controller to be in memory mapped mode in OSPI
boot, R5 SPL can directly pass the memory mapped pointer to ROM. With
this ROM can directly pull the SYSFW image from OSPI.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add support to download SYSFW into internal RAM via DFU in DFU boot
mode. Prepare a DFU config entity entry dynamically using buffer address
allocated for SYSFW and start DFU gadget to get SYSFW.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In order to allow booting TI K3 family SoCs via Y-Modem add support for
loading System Firmware by tapping into the associated SPL core loader
function.
In this context also make sure a console is available and if not go
ahead and activate the early console feature which allows bringing up
an alternate full console before the main console is activated. Such
an alternate console is typically setup in a way that the associated
UART can be fully initialized prior to SYSFW services being available.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
A previous commit...
commit 2a51e16bd5 ("configs: Make USE_TINY_PRINTF depend on SPL||TPL and be default")
...causes the System Firmware version string during SPL boot to no longer
getting printed to the console as expected. To fix this issue rework the
handling of that string to only use basic printf() syntax rather than
for example disabling CONFIG_USE_TINY_PRINTF on affected devices, this
way maintaining most of the memory size benefit the initial patch brings
when it comes to SPL.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Introduce a framework that allows loading the System Firmware (SYSFW)
binary as well as the associated configuration data from an image tree
blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
RAW mode partition or sector.
To simplify the handling of and loading from the different boot media
we tap into the existing U-Boot SPL framework usually used for loading
U-Boot by building on an earlier commit that exposes some of that
functionality.
Note that this initial implementation only supports FS and RAW-based
eMMC/SD card boot.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
