[PATCH 14/23] ARM: i.MX: scratch: add OP-TEE FDTO support

[Ahmad Fatoum]

Hello Marco,

On 1/18/26 7:27 PM, Marco Felsch wrote:
> Hi Ahmad,
> 
> On 26-01-15, Ahmad Fatoum wrote:
>> Hello Marco,
>>
>> On 11/10/25 9:34 PM, Marco Felsch wrote:
>>> OP-TEE has the support to write DTB overlay fragments if enabled via
>>> OP-TEE config switch CFG_EXTERNAL_DTB_OVERLAY.
>>>
>>> The overlay fragments are added to the exisiting DTB if OP-TEE was
>>> started with a DTB provided via arg2 or written to a stand-alone DTB
>>> overlay.
>>>
>>> This adds a dedicated storage slot which can be passed to OP-TEE or be
>>> used by barebox to extract the added overlay fragment into it.
>>>
>>> Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
>>> ---
>>
>>
>>> +config SCRATCH_FDTO_SIZE
>>> +	hex
>>> +	default 0x0
>>> +	default 0x4000 if PBL_EARLY_FDT_LOAD
>>> +	prompt "Scratch FDTO size"
>>> +	help
>>> +	  The size of possible FDT overlay areas used by BL3x binaries to store
>>> +	  runtime generated overlays. Can be 0x0 if early FDT support is not
>>> +	  requied e.g. during BL31 and BL32 stage.
>>
>> I understand the need, but I dislike that we add such fine-grained
>> Kconfig symbols here. With Sascha's series to make barebox proper an
>> ELF, PBL will have more insight about how much space barebox proper
>> occupies and I intend to send a series after it to allow easier
>> allocation for hand-off data.
> 
> Don't get me wrong I don't like it either. To be honest, I really
> don't like the current firmware handling since it doesn't scale for
> multi-images.
> 
>> I will include provisions for passing around the device tree and an
>> overlay with that series, so please hold off sending your v2 until then.
> 
> This series is on the list since quite a while. Unfortunately I didn't
> had the time to ping the ML since I was busy with other projects and
> also tried in the mean time to get the missing OP-TEE part mainline.
> 
> However, I would like to get this mainline. Not sure how Sascha is going
> to pick the patchsets but for the purpose of converting behaviours I
> used a generic name like SCRATCH_FDTO_SIZE, instead of going the
> Rockchip way which defined a Rockchip specific variable (unfortunately).
> 
> However, I would like to get this series mainline ASAP since my customer
> is going to rely on the mechanism we implemented here. Furthermore it
> improves the situation for i.MX6/i.MX7 by a lot (with Fabians patchset).

Ack. I am fine with some improvement as long it doesn't break API as
discussed before.

Cheers,
Ahmad

> 
> Regards,
>   Marco
> 
> 
>>
>> Thanks,
>> Ahmad
>>
>>
>>> +
>>>  config MALLOC_ALIGNMENT
>>>  	hex
>>>  	default 8
>>> diff --git a/include/mach/imx/scratch.h b/include/mach/imx/scratch.h
>>> index 43bf55de48099f1662cd4331620a93303d4dd710..a9745a95732dd961dcae83ec46c3eaa078d62a16 100644
>>> --- a/include/mach/imx/scratch.h
>>> +++ b/include/mach/imx/scratch.h
>>> @@ -15,6 +15,7 @@ const struct optee_header *imx_scratch_get_optee_hdr(void);
>>>  void imx_scratch_save_optee_hdr(const struct optee_header *hdr);
>>>  
>>>  void imx_scratch_get_fdt(void **fdt, unsigned int *fdt_sz);
>>> +void imx_scratch_get_optee_fdto(void **fdto, unsigned int *fdto_sz);
>>>  
>>>  #define imx8mq_init_scratch_space() imx8m_init_scratch_space(32, true)
>>>  #define imx8mm_init_scratch_space() imx8m_init_scratch_space(32, true)
>>>
>>
>> -- 
>> Pengutronix e.K.                  |                             |
>> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
>> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
>>
>>
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |