Re: [PATCH v5 3/5] arm64: dts: ti: k3-am62a-ti-ipc-firmware: Split r5f memory region

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Splitting the contiguous R5F firmware memory region into multiple smaller adjacent memory regions breaks backward compatibility with existing remoteproc ELF firmwares if any PT_LOAD segment spans across the newly introduced boundaries.
--

commit ae8536421e8ee2b18a7727698091d0c0fa7b60cb
Author: Markus Schneider-Pargmann (TI) <msp@baylibre.com>

arm64: dts: ti: k3-am62a-ti-ipc-firmware: Split r5f memory region

This commit splits the firmware memory region into multiple more specific
parts to better describe where to find information, specifically the LPM
metadata region needed by bootloader software.

> diff --git a/arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi
> --- a/arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi

[ ... ]

> @@ -78,8 +102,14 @@ &wkup_r5fss0 {
>  &wkup_r5fss0_core0 {
>  	mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>  	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> -			<&wkup_r5fss0_core0_memory_region>;
> -	memory-region-names = "dma", "firmware";
> +			<&wkup_r5fss0_core0_ipc_region>,
> +			<&wkup_r5fss0_core0_lpm_fs_stub_region>,
> +			<&wkup_r5fss0_core0_lpm_metadata_region>,
> +			<&wkup_r5fss0_core0_lpm_rest_region>,
> +			<&wkup_r5fss0_core0_dm_region>;
> +	memory-region-names = "dma", "ipc", "lpm-stub",
> +			      "lpm-metadata", "lpm-context",
> +			      "dm-firmware";

[Severity: High]
Is it safe to split the contiguous R5F firmware memory region into multiple
smaller adjacent memory regions, or could this break backward compatibility
with existing remoteproc ELF firmwares if a PT_LOAD segment spans across the
new boundaries?

The k3_rproc_da_to_va() function in drivers/remoteproc/ti_k3_common.c
strictly requires each requested ELF PT_LOAD segment to fit entirely within a
single memory-region defined in the device tree. Prior to this patch, a
single contiguous 0xf00000 memory region was provided, allowing firmware with
monolithic PT_LOAD segments to load successfully.

By splitting this single region into multiple smaller consecutive pieces, any
existing firmware binary whose ELF segment spans across one of these new
boundaries will fail to translate. The translation function will return NULL
and the firmware load will abort with -EINVAL.

Because the kernel lacks the ability to coalesce adjacent regions during this
translation, does this DTS update prevent existing deployed firmwares from
running correctly?

>  	bootph-pre-ram;
>  	status = "okay";
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601-topic-am62a-ioddr-dt-v6-19-v5-0-3856a023aff2@baylibre.com?part=3