Hello Marco,
On 1/18/26 9:26 PM, Marco Felsch wrote:
> On 26-01-16, Marco Felsch wrote:
>> Hi Ahmad,
>>
>> On 26-01-15, Ahmad Fatoum wrote:
>>> Hello,
>>>
>>> On 1/15/26 4:19 PM, Marco Felsch wrote:
>>>> On 26-01-15, Ahmad Fatoum wrote:
>>>>>>> + pr_warn("Failed to extract OP-TEE FDTO, continue
>>>>>>> without FDTO\n");
>>>>>>> + /*
>>>>>>> + * Don't BUG() because the system may have compile-time
>>>>>>> config
>>>>>>> + * support
>>>>>>> + */
>>>>>>> + return;
>>>>>>> + }
>>>>>>> +
>>>>>>> + handoff_data_add(HANDOFF_DATA_BL32_DT_OVL, fdto_dst, fdto_size);
>>>>>>
>>>>>> The overlay isn't used in barebox itself, but only for the Kernel.
>>>>
>>>> This is not true. This patchset adds to support to use the overlay
>>>> within barebox too. With the patches Fabian provided, it would eliminate
>>>> the need for i.MX6(ULL) boards to have this strange initcall which
>>>> checks a magic memory location for an overlay to apply it.
>>>>>>>
>>>>>> You Could just pick up the overlay from the i.MX scratch space in
>>>>>> barebox proper and pass it to optee_register_overlay().
>>>>>
>>>>> Agreed. There seems to be no need to do this in the PBL.
>>>>
>>>> The early barebox code checks for HANDOFF_DATA_BL32_DT_OVL and applies
>>>> the overlay. Do you suggest that I shall extract the data within barebox
>>>> common code rather? I'm not sure if this is even possible.
>>>
>>> Isn't this basically what virt_board_driver_init() is doing? Would this
>>> not work for your purposes?
>>>
>>> I am generally not a friend of putting logic that can equally well be
>>> located in barebox proper into the PBL. It's slow, it's code duplication
>>> and if we do it, there should be a strong reason why it needs to be in
>>> the PBL. There might very well be a reason here that this needs to be
>>> absolutely done in the PBL (e.g. I can understand fixing up memory size
>>> in PBL, because firmware needs it that early), but I don't yet see it
>>> here for application of the overlay.
>>
>> I see and you're completely right, if something can be done in barebox
>> proper we should do it there. I have to check the
>> virt_board_driver_init() and how this approach can be re-used for the
>> this common abbroach.
>
> I've checked the virt_board_driver_init() and have to disagree. What I
> do here is to extract the overlay-fragments into a overlay-only FDT to
> not cause any issues while applying the overlay later on. The
> virt_board_driver_init() is applying a builtin overlay-only devicetree.
Sure, but why can't you do this stuff in barebox proper? As mentioned
before PBL runs mostly with MMU disabled and we don't want to increase
its size with things that could be done much better in barebox proper,
both execution time and code size wise.
> That beeing said, I wasn't sure if we need to extract the
> overlay-fragments before applying the overlay. Applying the FDT provided
> by OP-TEE which contains both the complete FDT and the overlay-fragments
> should work too, but doesn't feel right. Therefore I went the way of
> extract them into a dedicated overlay which can be applied later on
> without worries (like the virt_board_driver_init() does).
I don't mind the extraction, just where it's currently done.
> I could check if applying the completed FDT (incl. the
> overlay-fragments9 provided by OP-TEE as of-overlay works too.
>
> IMHO this doesn't feel right, but the appending OP-TEE does doesn't feel
> right too.
Just moving it into barebox proper suffices for me.
Thanks,
Ahmad
>
> Regards,
> Marco
>
--
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 |
