[PATCH 2/2] arm64: imx8mp: Read item and serial number from EEPROM ID page on DH i.MX8MP DHCOM
Marek Vasut
marex at denx.de
Wed Oct 23 16:04:45 CEST 2024
On 10/23/24 3:20 PM, Christoph Niedermaier wrote:
> From: Marek Vasut <marex at denx.de>
> Sent: Wednesday, October 23, 2024 2:41 PM
>> On 10/23/24 2:18 PM, Christoph Niedermaier wrote:
>>
>> [...]
>>
>>>> You do not, the following automatically reserves space on stack when
>>>> called and frees it up upon function return:
>>>>
>>>> function foo() {
>>>> u8 array[12];
>>>> ...
>>>> stuff(array);
>>>> ...
>>>> }
>>>
>>> Sorry, I expressed myself incorrectly here. Of course I meant that
>>> I don't want to reserve memory on the stack for the EEPROM ID page
>>> in the board_init() function.
>>
>> Why ?
>
> It's about structuring the software. I want to isolate the function which
> is responsible for evaluate the EEPROM from the caller function. I wanted
> to avoid entangling the two. This means that I, as the caller of the function,
> do not have to worry about the internal structure of the EEPROM ID page.
You are only passing in a block of unstructured memory allocated on
stack, u8 block[64].
>>>>> I want to handle
>>>>> size and caching in the function dh_get_value_from_eeprom_id_page(). So I don't
>>>>> want to deal with size and structure in the function board_init(). For me, the use
>>>>> of a static variable is OK, but you don't like it. Do you know how I can do this
>>>>> without assigning a static variable, but not allocate the memory somewhere in a
>>>>> caller function?
>>>> Even the static variable space is allocated somewhere, either in .bss or
>>>> .data section, except with static variable(s) the memory persists
>>>> throughout the lifetime of U-Boot because their content has to be
>>>> retained even when the function using their content returns.
>>>>
>>>> With variable(s) allocated on stack (which is majority of variable), the
>>>> memory allocation happens on entry to the function and the memory is
>>>> automatically freed on exit from the function.
>>>>
>>>> It is perfectly fine to call some wrapper superfunction from
>>>> board_init() which holds the array on stack and calls all the EEPROM
>>>> parser/handler functions:
>>>>
>>>> eeprom_superwrapper() {
>>>> u8 eeprom[64];
>>>> ...
>>>> eeprom_do_stuff1(eeprom);
>>>> eeprom_do_stuff2(eeprom);
>>>> ...
>>>> }
>>>>
>>>> board_init() {
>>>> ...
>>>> eeprom_superwrapper();
>>>> ...
>>>> }
>>>
>>> That's not what I'm looking for. Do you have another solution?
>> No. I do not understand what is the problem with allocating 64 Bytes on
>> stack ?
>
> There is no problem with the reservation of the EEPROM buffer on the
> stack. I wanted to isolate the evaluation function from the caller
> function, so that I have no dependencies on the caller. Since there
> seems to be no better solution, I will add the variable to the
> board_init() function in V2.
There seem to be multiple functions using the same data, so you have to
pass pointer to those data around.
More information about the U-Boot
mailing list