On Wed, Oct 15, 2025 at 02:31:49PM +0530, Anshul Dalal wrote: > 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.
Sounds good, thanks. -- Tom
signature.asc
Description: PGP signature
