Re: 回复: [EXT] Re: 回复: 回复: 回复: [PATCH] firmware: scmi: Drop mmu_set_region_dcache_behaviour() misuse

Patrick DELAUNAY patrick.delaunay at foss.st.com
Mon Nov 3 14:11:23 CET 2025


Hi Marek,

On 10/31/25 15:41, Marek Vasut wrote:
> On 10/31/25 8:52 AM, Alice Guo wrote:
>>> -----邮件原件-----
>>> 发件人: Marek Vasut <marek.vasut at mailbox.org>
>>> 发送时间: 2025年10月31日 12:11
>>> 收件人: Alice Guo (OSS) <alice.guo at oss.nxp.com>; u-boot at lists.denx.de
>>> 抄送: Alice Guo <alice.guo at nxp.com>; Etienne Carriere
>>> <etienne.carriere at linaro.org>; Patrick Delaunay
>>> <patrick.delaunay at foss.st.com>; Peng Fan <peng.fan at nxp.com>; Tom Rini
>>> <trini at konsulko.com>; Vinh Nguyen <vinh.nguyen.xz at renesas.com>; Viorel
>>> Suman <viorel.suman at nxp.com>; Ye Li <ye.li at nxp.com>
>>> 主题: [EXT] Re: 回复: 回复: 回复: [PATCH] firmware: scmi: Drop
>>> mmu_set_region_dcache_behaviour() misuse
>>>
>>> Caution: This is an external email. Please take care when clicking 
>>> links or
>>> opening attachments. When in doubt, report the message using the 
>>> 'Report this
>>> email' button
>>>
>>>
>>> On 10/31/25 4:36 AM, Alice Guo (OSS) wrote:
>>>
>>> Hello Alice,
>>>
>>>>> Would it be possible to fix up the SRAM mapping in:
>>>>>
>>>>> arch/arm/mach-imx/imx8ulp/soc.c:static struct mm_region
>>>>> imx8ulp_arm64_mem_map[] = {
>>>>>
>>>>> ?
>>>>>
>>>>> -- 
>>>>> Best regards,
>>>>> Marek Vasut
>>>>
>>>> Hi Marek,
>>>>
>>>> Configuring the memory region for SCMI communication as
>>> MT_DEVICE_NGNRNE resolves the issue. With this change, SCMI works
>>> correctly and the i.MX8ULP boots successfully.
>>>>
>>>>                   /* SRAM0 (align with 2M) */
>>>>                   .virt = 0x22000000UL,
>>>>                   .phys = 0x22000000UL,
>>>> -               .size = 0x200000UL,
>>>> +               .size = 0x1f000UL,
>>>> +               .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>>> +                        PTE_BLOCK_OUTER_SHARE |
>>>> +                        PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>>> +       }, {
>>>> +               .virt = 0x2201f000UL,
>>>> +               .phys = 0x2201f000UL,
>>>> +               .size = 0x1000UL,
>>>> +               .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>>>> +                        PTE_BLOCK_NON_SHARE |
>>>> +                        PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>>> +       }, {
>>>> +               .virt = 0x22020000UL,
>>>> +               .phys = 0x22020000UL,
>>>> +               .size = 0x1e0000UL,
>>>>                   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>>>                            PTE_BLOCK_OUTER_SHARE |
>>>>                            PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>>>
>>> Excellent !
>>>
>>> Can you please submit a fix like this upstream ?
>>
>> Patch has been sent out.
>> https://www.mail-archive.com/u-boot@lists.denx.de/msg557766.html
> Thank you !
>
> So I think, this now covers
> - NXP SoCs -- iMX8ULP , iMX95
> - TI SoCs -- AM6.. ?
>
> How about ST SoCs ?


No impacts for ST SoCs.


Now ae are using OP-TEE transport for SCMI messages without external 
shared memory

             compatible = "linaro,scmi-optee";
             linaro,optee-channel-id = <0>;

=> the message are managed by only by OP-TEE channel

Reference:

- b2fb22396f97 ("ARM: dts: stm32mp15: remove shmem for scmi-optee")

- 3fce6bf21309 ("ARM: dts: stm32mp13: remove shmem for scmi-optee")

Moreover the patch is coherent with linux behavior

(https://lore.kernel.org/r/20211125150730.188487-1-sudeep.holla@arm.com)


This part was initially introduced by Etienne when OP-TEE transport use 
a static or dynamic shmem in DDR,

which was mapped by default as cacheable.


But it is more the case for STM32 SoCs today or in futur

(SCMI channel with TF-M use internal memory mapped not ccheable).



>
> Anything else left over ?



Reviewed-by: Patrick Delaunay <patrick.delaunay at foss.st.com>

Thanks
Patrick




More information about the U-Boot mailing list