From: Anshul Dalal <anshuld@ti.com>
To: Andrew Davis <afd@ti.com>, Anshul Dalal <anshuld@ti.com>
Cc: <b-liu@ti.com>, <bb@ti.com>, <m-chawdhry@ti.com>,
<n-francis@ti.com>, <nm@ti.com>, <trini@konsulko.com>,
<u-boot@lists.denx.de>, <vigneshr@ti.com>
Subject: Re: [PATCH v9 3/8] mach-k3: common: enable falcon mode from R5 SPL
Date: Thu, 30 Oct 2025 20:55:58 +0530 [thread overview]
Message-ID: <DDVRFKCHCSJB.3HC7YUPKQQVDJ@ti.com> (raw)
In-Reply-To: <e6791dc8-45b5-458e-afdf-f96778b529af@ti.com>
On Thu Oct 30, 2025 at 7:16 PM IST, Andrew Davis wrote:
> On 10/30/25 12:19 AM, Anshul Dalal wrote:
>> We use the spl_board_prepare_for_boot hook to call k3_r5_falcon_prep
>> which is ran after tispl is loaded but before jump_to_image.
>>
>> In k3_r5_falcon_prep, we find the boot media and load the kernel FIT
>> just as standard secure falcon mode (since spl_start_uboot returns 0
>> now). Once the kernel and args are loaded.
>>
>> Now when the flow goes to jump_to_image, we do the regular pre-jump
>> procedure and jump to TFA which jumps to the kernel directly since we
>> have already loaded the kernel and dtb at their respective addresses
>> (PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE).
>>
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> ---
>> arch/arm/mach-k3/common.c | 8 +++++++
>> arch/arm/mach-k3/common.h | 4 ++++
>> arch/arm/mach-k3/r5/common.c | 45 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 57 insertions(+)
>>
>> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
>> index 04a0f232d84..c446d1c47fd 100644
>> --- a/arch/arm/mach-k3/common.c
>> +++ b/arch/arm/mach-k3/common.c
>> @@ -360,6 +360,14 @@ void spl_perform_arch_fixups(struct spl_image_info *spl_image)
>>
>> void spl_board_prepare_for_boot(void)
>> {
>> +#if IS_ENABLED(CONFIG_SPL_OS_BOOT_SECURE) && !IS_ENABLED(CONFIG_ARM64)
>> + int ret;
>> +
>> + ret = k3_r5_falcon_prep();
>> + if (ret)
>> + panic("%s: Failed to boot in falcon mode: %d\n", __func__, ret);
>> +#endif /* falcon mode on R5 SPL */
>> +
>> #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
>> dcache_disable();
>> #endif
>> diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
>> index 52d3faaab5c..5807d358464 100644
>> --- a/arch/arm/mach-k3/common.h
>> +++ b/arch/arm/mach-k3/common.h
>> @@ -52,6 +52,10 @@ void do_board_detect(void);
>> void ti_secure_image_check_binary(void **p_image, size_t *p_size);
>> int shutdown_mcu_r5_core1(void);
>>
>> +#if IS_ENABLED(CONFIG_SPL_OS_BOOT_SECURE) && !IS_ENABLED(CONFIG_ARM64)
>> +int k3_r5_falcon_bootmode(void);
>> +#endif
>> +
>> #if (IS_ENABLED(CONFIG_K3_QOS))
>> void setup_qos(void);
>> #else
>> diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
>> index 6269b33f66b..439dd92ef54 100644
>> --- a/arch/arm/mach-k3/r5/common.c
>> +++ b/arch/arm/mach-k3/r5/common.c
>> @@ -376,3 +376,48 @@ void board_fit_image_post_process(const void *fit, int node, void **p_image,
>> }
>> }
>> #endif
>> +
>> +#ifdef CONFIG_SPL_OS_BOOT_SECURE
>> +
>> +static bool tifalcon_loaded;
>
> Not strictly needed as statics will default to 0, assigning false
> here makes it more clear what the starting value should be,
>
> static bool tifalcon_loaded = false;
>
>> +
>> +int spl_start_uboot(void)
>> +{
>> + /* If tifalcon.bin is not loaded, proceed to regular boot */
>> + if (!tifalcon_loaded)
>> + return 1;
>> +
>> + /* Boot to linux on R5 SPL with tifalcon.bin loaded */
>> + return 0;
>
> Extra indent tab here.
>
>> +}
>> +
>> +int k3_r5_falcon_prep(void)
>> +{
>> + struct spl_image_loader *loader, *drv;
>> + struct spl_image_info kernel_image;
>> + struct spl_boot_device bootdev;
>> + int ret = -ENXIO, n_ents;
>> +
>> + tifalcon_loaded = true;
>
> Should this be set down after we make sure loading doesn't fail?
>
That wouldn't work actually, tifalcon_loaded is used to detect if
tifalcon.bin has been loaded or not. We then in-turn use this
information in our two step boot process to decide whether or not to do
falcon boot.
The call to load_image below will internally calls spl_start_uboot to
check for falcon mode status, which will return 0 now allowing us to
load fitImage.
So, the overall boot flow looks as follows:
board_init_r
|-> boot_from_devices
| +-> load_image (we load tifalcon.bin here since spl_start_uboot returns 1)
|
+-> spl_prepare_for_boot
| +-> k3_falcon_prep
| +-> load_image (we load fitImage here since spl_start_uboot returns 0 now)
|
+-> jump_to_image
>> + memset(&kernel_image, '\0', sizeof(kernel_image));
>> + drv = ll_entry_start(struct spl_image_loader, spl_image_loader);
>> + n_ents = ll_entry_count(struct spl_image_loader, spl_image_loader);
>> + bootdev.boot_device = spl_boot_device();
>> +
>> + for (loader = drv; loader != drv + n_ents; loader++) {
>> + if (bootdev.boot_device != loader->boot_device)
>> + continue;
>> + if (loader) {
>
> If loader is NULL, the if above containing loader->boot_device would have
> already null pointer deref crashed. You might want to move this check up
> into the if check above.
You're right, this needs to be fixed. I was following a similar
structure to boot_from_devices (common/spl/spl.c) which also seems to
have the same issue.
Regards,
Anshul
>
> Andrew
>
>> + printf("Loading falcon payload from %s\n",
>> + spl_loader_name(loader));
>> + ret = loader->load_image(&kernel_image, &bootdev);
>> + if (ret)
>> + continue;
>> +
>> + return 0;
>> + }
>> + }
>> +
>> + return ret;
>> +}
>> +#endif
next prev parent reply other threads:[~2025-10-30 15:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-30 5:19 [PATCH v9 0/8] Allow falcon boot from R5 SPL on TI's AM62 devices Anshul Dalal
2025-10-30 5:19 ` [PATCH v9 1/8] arch: arm: k3-binman: add fit for falcon boot Anshul Dalal
2025-10-30 5:19 ` [PATCH v9 2/8] configs: add falcon mode fragment for k3 devices Anshul Dalal
2025-10-30 5:19 ` [PATCH v9 3/8] mach-k3: common: enable falcon mode from R5 SPL Anshul Dalal
2025-10-30 13:46 ` Andrew Davis
2025-10-30 15:25 ` Anshul Dalal [this message]
2025-10-30 15:35 ` Andrew Goodbody
2025-10-30 18:19 ` Andrew Davis
2025-10-30 5:19 ` [PATCH v9 4/8] mach-k3: common: support only MMC in R5 falcon mode Anshul Dalal
2025-10-30 13:55 ` Andrew Davis
2025-10-30 15:39 ` Anshul Dalal
2025-10-30 5:19 ` [PATCH v9 5/8] mach-k3: r5: common: add fdt fixups for " Anshul Dalal
2025-10-30 5:19 ` [PATCH v9 6/8] mach-k3: r5: common: add bootargs to kernel's dtb Anshul Dalal
2025-10-30 5:19 ` [PATCH v9 7/8] Makefile: add tifalcon.bin to CLEAN_FILES Anshul Dalal
2025-10-30 5:19 ` [PATCH v9 8/8] doc: ti: document R5 falcon mode for AM62 platforms Anshul Dalal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DDVRFKCHCSJB.3HC7YUPKQQVDJ@ti.com \
--to=anshuld@ti.com \
--cc=afd@ti.com \
--cc=b-liu@ti.com \
--cc=bb@ti.com \
--cc=m-chawdhry@ti.com \
--cc=n-francis@ti.com \
--cc=nm@ti.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.