Boards which use DCD data in SCFW can drop SPL.
We tried in our mainline rework to use this approach
too as other imx8qxp boards do in mainline. But we
failed ... it was a hard way to understand the
reason!
We cannot use DCD image in container as the SCFW
from siemens, does the RAM init on boot itself!
Siemens SCFW reads the RAM config from i2c eeprom and
dependent on this settings, initializes the RAM.
Adding DCD data to the bootcontainer will result in
hang of the SCFW, also DCD data in container image is
static which do not fit our needs.
So we must drop DCD data image, and this has the side
effect that we need SPL, as the task which loads the images
from the container only loads the images to addresses,
and if executed bit is set, starts them.
As now RAM is not initialized from it, and there is no
option to "wait until SCFW has setup RAM", we can only
load SPL into internal RAM at this point, as than SPL
and SCFW boot parallel.
The SPL itself then uses the SCU API to communicate
with the SCFW and it seems that SCFW only responds to
this API requests when RAM setup is already done by the
SCFW, which has a side-effect of a "sync" for the RAM
setup is done by SCFW!
We checked if SPL is always save in accessing RAM for
loading images to it! For tests, we added in our RAM
init part in the SCFW long delays (10 seconds and more)
as we thought there is such a sync missing, and we can
break the board through delaying RAM setup... but we
did not managed to fail booting U-Boot from SPL!
Signed-off-by: Heiko Schocher <hs@denx.de>
This is supposed to be a build-system flag. Move it there so we can
define it before linux/kconfig.h is included.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update reference in many files detected by
scripts/documentation-file-ref-check
README.imx8image => imx/mkimage/imx8image.txt
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
