On 17/11/2020 11:22, Tero Kristo wrote:
On 17/11/2020 08:14, Lokesh Vutla wrote:
On 16/11/20 5:57 pm, Tero Kristo wrote:
On 16/11/2020 06:23, Lokesh Vutla wrote:
On 10/11/20 2:35 pm, Tero Kristo wrote:
If the raw PM support is built in, we are operating in the split
firmware approach mode where RM and PM support is not available. In
this
case, skip the board config for these two.
Signed-off-by: Tero Kristo <t-kri...@ti.com>
---
arch/arm/mach-k3/sysfw-loader.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-k3/sysfw-loader.c
b/arch/arm/mach-k3/sysfw-loader.c
index 78c158c63f..154d2df049 100644
--- a/arch/arm/mach-k3/sysfw-loader.c
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -158,11 +158,13 @@ static void k3_sysfw_configure_using_fit(void
*fit,
ret);
/* Apply power/clock (PM) specific configuration to SYSFW */
+#ifdef CONFIG_CLK_TI_SCI
IMHO, using CONFIG_CLK_TI_SCI is hack here. Can we showhow derive this
information based on the images loaded in FIT?
At this point we have only loaded the sysfw image. DM image against
which we
This sysfw.itb contains all the board configurations?
If yes, then we are adding board configurations in sysfw.itb that does
not
belong here.
If no, then can we check for the entries before loading?
Technically feasible yes, let me check with Dave offline what we can
craft for this (the image generation part was done by him); the firmware
image generator does something along these lines already, basically
splitting the cfg portions to different images.
Ok, after some offline discussions, we ended up with a solution that for
the sysfw_loader portion at least we have to use a config option, as
otherwise the build process becomes completely broken with multiple
cross dependencies towards/between external build tools etc... To make
things a bit more clear though, I'll add a new config option called
CONFIG_TI_DM_FW, which would indicate that we are using a separate DM
firmware image in the system. This avoids overloading the
CONFIG_CLK_TI_SCI or something else, even if these two effectively
follow each other in their value.
I'll re-work the relevant patches around this and re-post.
-Tero
-Tero
Thanks and regards,
Lokesh
could check this will only be loaded during A72 SPL FIT loading
process, and it
will only happen later.
-Tero
Thanks and regards,
Lokesh
ret = board_ops->board_config_pm(ti_sci,
(u64)(u32)cfg_fragment_addr,
(u32)cfg_fragment_size);
if (ret)
panic("Failed to set board PM configuration (%d)\n", ret);
+#endif
/* Extract resource management (RM) specific configuration
from FIT */
ret = fit_get_data_by_name(fit, images, SYSFW_CFG_RM,
@@ -171,12 +173,14 @@ static void k3_sysfw_configure_using_fit(void
*fit,
panic("Error accessing %s node in FIT (%d)\n",
SYSFW_CFG_RM,
ret);
+#ifdef CONFIG_CLK_TI_SCI
/* Apply resource management (RM) configuration to SYSFW */
ret = board_ops->board_config_rm(ti_sci,
(u64)(u32)cfg_fragment_addr,
(u32)cfg_fragment_size);
if (ret)
panic("Failed to set board RM configuration (%d)\n", ret);
+#endif
/* Extract security specific configuration from FIT */
ret = fit_get_data_by_name(fit, images, SYSFW_CFG_SEC,
--
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
