[PATCH] Kconfig: Fix SYS_MALLOC_F_LEN for i.MX8MQ

[Peng Fan]

On 7/6/2022 5:01 PM, Heiko Thiery wrote:
> Hi Peng
> 
> Am Di., 5. Juli 2022 um 18:04 Uhr schrieb Tom Rini <trini at konsulko.com>:
>>
>> On Tue, Jul 05, 2022 at 05:20:46PM +0200, Heiko Thiery wrote:
>>> Hi Tom,
>>>
>>> Am Di., 5. Juli 2022 um 15:35 Uhr schrieb Tom Rini <trini at konsulko.com>:
>>>>
>>>> On Tue, Jul 05, 2022 at 12:19:54PM +0200, Heiko Thiery wrote:
>>>>> Hi all,
>>>>>
>>>>> Am Mo., 11. Apr. 2022 um 14:29 Uhr schrieb Tom Rini <trini at konsulko.com>:
>>>>>>
>>>>>> On Mon, Apr 11, 2022 at 05:07:04PM +0800, Peng Fan (OSS) wrote:
>>>>>>
>>>>>>> From: Peng Fan <peng.fan at nxp.com>
>>>>>>>
>>>>>>> i.MX8MQ use SYS_MALLOC_F_LEN 0x2000, not 0x10000. The OCRAM_S only has
>>>>>>> 32KB memory, use 0x10000 will make SPL not bootable.
> 
> It is strange. You said the i.MX8MQ has 32KB OCRAM memory. That means
> a value of 0x8000 should be the max usable value. But I see when
> setting to this value my board does not start. Only when I set the
> value to 0xc000 the board starts.
> 
> In the RM I see:
> - On-Chip RAM - OCRAM (128 KB)
> - On-Chip RAM for State Retention - OCRAM_S (32 KB)

Yes. I said OCRAM_S only has 32KB. The MALLOC BASE is set in OCRAM_S.

If your board has other settings, you could change that for your
requirement. I think I have checked all boards, When I worked out
this patch, I may overlook your board.

Regards,
Peng.

> 
>>>>>>>
>>>>>>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
>>>>>>> Reviewed-by: Michael Trimarchi <michael at amarulasolutions.com>
>>>>>>> Reviewed-by: Fabio Estevam <festevam at denx.de>
>>>>>>> ---
>>>>>>>   Kconfig | 6 ++++--
>>>>>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/Kconfig b/Kconfig
>>>>>>> index 6b1ddfc549e..3e95ec9d7b9 100644
>>>>>>> --- a/Kconfig
>>>>>>> +++ b/Kconfig
>>>>>>> @@ -251,8 +251,10 @@ config SYS_MALLOC_F_LEN
>>>>>>>        default 0x4000 if SANDBOX || RISCV
>>>>>>>        default 0x2000 if (ARCH_MX7 || ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \
>>>>>>>                           ARCH_QEMU || ARCH_SUNXI || ARCH_OWL)
>>>>>>> -     default 0x10000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_LS1012A || \
>>>>>>> -                         ARCH_LS1021A || ARCH_LS1043A || ARCH_LS1046A)
>>>>>>> +     default 0x10000 if (ARCH_IMX8 || (ARCH_IMX8M && !IMX8MQ) || \
>>>>>>> +                         ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \
>>>>>>> +                         ARCH_LS1046A)
>>>>>>> +     default 0x2000 if IMX8MQ
>>>>>>>        default 0x400
>>>>>>>        help
>>>>>>>          Before relocation, memory is very limited on many platforms. Still,
>>>>>>
>>>>>> Note that we can put this with the rest of the 0x2000 default instances.
>>>>>> And as an aside, imx8mq_phanbell_defconfig sets this to 0x4000.  That
>>>>>> said, I've applied this to master (with the location change I noted), thanks!
>>>>>>
>>>>>> --
>>>>>> Tom
>>>>>
>>>>> I just tested v2022.07-rc6 and noticed that by reducing the value the
>>>>> kontron pitx-imx8m (imx8mq) board does not start anymore. I locally
>>>>> increased the value to 0xc000 and the board works again.
>>>>>
>>>>> So should I increase the value just for this board or should I
>>>>> increase the default value for the IMX8MQ?
>>>>
>>>> I would _really_ like to see defaults per SoC.  Even if that means
>>>> saying "default 0xc000 if IMX8Q && SPL_FEAT_X" as I know with tight
>>>> constraints on memory AND the need to have some of the bigger feature
>>>> knobs enabled it can be tricky to get usable defaults.  But what I
>>>> really want to avoid are both the problem of everyone copy/pasting a
>>>> value that's too big or too small and also avoid the problem of N boards
>>>> needing the same fix because they all failed due to the same problem.
>>>
>>> I understand your concerns but the value that has to be adjusted is
>>> not SPL_SYS_MALLOC_F_LEN. Therefore I'm not sure if the '&&
>>> SPL_FEAT_X' would be correct here.
>>
>> Ah right, sorry.  So yes, it's even more likely we should be able to
>> come up with one default for the family.
>>
>> --
>> Tom
> 
> --
> Heiko