On Sat Oct 11, 2025 at 3:26 PM IST, Anshul Dalal wrote: > Hi Tom, > > On Fri Oct 10, 2025 at 9:35 PM IST, Tom Rini wrote: >> On Fri, Oct 10, 2025 at 06:48:25PM +0530, Anshul Dalal wrote: >> >>> With CONFIG_SPL_OS_BOOT enabled, U-Boot checks for the return value of >>> spl_start_uboot to select between falcon or the regular boot flow. With >>> a return value of 0 implying falcon mode. >>> >>> This patch overrides the weak definition form common/spl/spl.c to allow >>> K3 devices to use falcon mode with SPL_OS_BOOT enabled. >>> >>> Signed-off-by: Anshul Dalal <[email protected]> >>> --- >>> arch/arm/mach-k3/common.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c >>> index 5483ac9906c..41c96cbd4c5 100644 >>> --- a/arch/arm/mach-k3/common.c >>> +++ b/arch/arm/mach-k3/common.c >>> @@ -425,3 +425,10 @@ release_proc_ctrl: >>> proc_ops->proc_release(ti_sci, PROC_ID_MCU_R5FSS0_CORE1); >>> return ret; >>> } >>> + >>> +#if CONFIG_IS_ENABLED(OS_BOOT) >>> +int spl_start_uboot(void) >>> +{ >>> + return 0; >>> +} >>> +#endif >> >> I've seen this in other parts of the series too, sorry. >> CONFIG_IS_ENABLED(OS_BOOT) doesn't make sense, it should be > > Is that because OS_BOOT by itself is meaningless and > CONFIG_IS_ENABLED(OS_BOOT) would always fall to checking for > CONFIG_SPL_OS_BOOT? I mostly stuck with CONFIG_IS_ENABLED to avoid the > extra three characters when using IS_ENABLED instead. >
Apparently there are quite a few instances of CONFIG_IS_ENABLED(OS_BOOT) in the source even before this patch series. I'll change it to IS_ENABLED for this series in a v2 but for the existing instances, I think it's better to follow up with a clean up patch once all other remaining falcon series are merged. >> IS_ENABLED(CONFIG_SPL_OS_BOOT) or just a regular #ifdef. Also for this >> example please add a comment to the function explaining why it's always >> enabling falcon mode. > > Will add an explantory comment in the next revision. > > Regards, > Anshul
