efi_loader : Suppress error print message

Message ID	20240122191242.2989327-1-tejas.arvind.bhumkar@amd.com
State	Rejected, archived
Delegated to:	Heinrich Schuchardt
Headers	show Return-Path: <u-boot-bounces@lists.denx.de> Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com> To: <u-boot@lists.denx.de> CC: <xypron.glpk@gmx.de>, <ilias.apalodimas@linaro.org>, <trini@konsulko.com>, <sjg@chromium.org>, <michal.simek@amd.com>, <venkatesh.abbarapu@amd.com>, <git@xilinx.com> Subject: [PATCH] efi_loader : Suppress error print message Date: Tue, 23 Jan 2024 00:42:42 +0530 Message-ID: <20240122191242.2989327-1-tejas.arvind.bhumkar@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Precedence: list Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" <u-boot-bounces@lists.denx.de>
Series	efi_loader : Suppress error print message \| expand efi_loader : Suppress error print message

Bhumkar, Tejas Arvind Jan. 22, 2024, 7:12 p.m. UTC

Currently, on certain Xilinx platforms, an issue has been
identified, manifesting as follows:

Starting kernel ...

efi_free_pool: illegal free 0x0000000077830040
efi_free_pool: illegal free 0x000000007782d040
efi_free_pool: illegal free 0x000000007782c040

The issue arises when the ramdisk image is relocated, placing
it within the previously allocated EFI memory region( as EFI 
is established quite early in U-Boot). Consequently, when 
attempting to release memory in the EFI memory region during 
the handover process to the kernel,we encounter memory violations.

Highlighting that EFI remains active primarily during the 
booting of an EFI application, and the lmb persists while 
configuring images for the boot process. Since we aren't 
utilizing the EFI memory region during the boot process, 
there is no adverse impact even in the event of a violation.

Currently, there is an ongoing discussion regarding the handling
strategies of three memory allocators: malloc, lmb, and EFI. This
discussion is documented in the email chain
titled "Proposal: U-Boot memory management."

Therefore, it is advisable to suppress the print message during
the boot process for now.

Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com> 
---
 lib/efi_loader/efi_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Ilias Apalodimas Jan. 23, 2024, 8:33 a.m. UTC | #1

Hi Tejas,

On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
<tejas.arvind.bhumkar@amd.com> wrote:
>
> Currently, on certain Xilinx platforms, an issue has been
> identified, manifesting as follows:
>
> Starting kernel ...
>
> efi_free_pool: illegal free 0x0000000077830040
> efi_free_pool: illegal free 0x000000007782d040
> efi_free_pool: illegal free 0x000000007782c040
>
> The issue arises when the ramdisk image is relocated, placing
> it within the previously allocated EFI memory region( as EFI
> is established quite early in U-Boot).

I don't mind suppressing the print for some time, but out of
curiosity, how is the ramdisk relocated? LMB should be aware of the
EFI regions by then, so I assume the relocation code doesn't check
those?

Thanks
/Ilias

> Consequently, when
> attempting to release memory in the EFI memory region during
> the handover process to the kernel,we encounter memory violations.
>
> Highlighting that EFI remains active primarily during the
> booting of an EFI application, and the lmb persists while
> configuring images for the boot process. Since we aren't
> utilizing the EFI memory region during the boot process,
> there is no adverse impact even in the event of a violation.
>
> Currently, there is an ongoing discussion regarding the handling
> strategies of three memory allocators: malloc, lmb, and EFI. This
> discussion is documented in the email chain
> titled "Proposal: U-Boot memory management."
>
> Therefore, it is advisable to suppress the print message during
> the boot process for now.
>
> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
> ---
>  lib/efi_loader/efi_memory.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index edfad2d95a..821fe7616e 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
>         /* Check that this memory was allocated by efi_allocate_pool() */
>         if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
>             alloc->checksum != checksum(alloc)) {
> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
> +               debug("%s: illegal free 0x%p\n", __func__, buffer);
>                 return EFI_INVALID_PARAMETER;
>         }
>         /* Avoid double free */
> --
> 2.27.0
>

Heinrich Schuchardt Jan. 23, 2024, 10 a.m. UTC | #2

On 1/23/24 09:33, Ilias Apalodimas wrote:
> Hi Tejas,
>
> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
> <tejas.arvind.bhumkar@amd.com> wrote:
>>
>> Currently, on certain Xilinx platforms, an issue has been
>> identified, manifesting as follows:

Hello Tejas,

thank you for bringing forward this issue.

Which defconfig are you relating to?

>>
>> Starting kernel ...
>>
>> efi_free_pool: illegal free 0x0000000077830040
>> efi_free_pool: illegal free 0x000000007782d040
>> efi_free_pool: illegal free 0x000000007782c040
>>
>> The issue arises when the ramdisk image is relocated, placing
>> it within the previously allocated EFI memory region( as EFI
>> is established quite early in U-Boot).

Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider
EFI memory map") was meant to avoid such a situation.

>
> I don't mind suppressing the print for some time, but out of
> curiosity, how is the ramdisk relocated? LMB should be aware of the
> EFI regions by then, so I assume the relocation code doesn't check
> those?

The indicated situation is serious. If the EFI sub-system is using the
same memory area as the ramdisk, this may lead to corruption of the
ramdisk. Suppressing the messages is by no means adequate to solve the
problem.

Best regards

Heinrich


>
> Thanks
> /Ilias
>
>> Consequently, when
>> attempting to release memory in the EFI memory region during
>> the handover process to the kernel,we encounter memory violations.
>>
>> Highlighting that EFI remains active primarily during the
>> booting of an EFI application, and the lmb persists while
>> configuring images for the boot process. Since we aren't
>> utilizing the EFI memory region during the boot process,
>> there is no adverse impact even in the event of a violation.
>>
>> Currently, there is an ongoing discussion regarding the handling
>> strategies of three memory allocators: malloc, lmb, and EFI. This
>> discussion is documented in the email chain
>> titled "Proposal: U-Boot memory management."
>>
>> Therefore, it is advisable to suppress the print message during
>> the boot process for now.
>>
>> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
>> ---
>>   lib/efi_loader/efi_memory.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>> index edfad2d95a..821fe7616e 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
>>          /* Check that this memory was allocated by efi_allocate_pool() */
>>          if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
>>              alloc->checksum != checksum(alloc)) {
>> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
>> +               debug("%s: illegal free 0x%p\n", __func__, buffer);
>>                  return EFI_INVALID_PARAMETER;
>>          }
>>          /* Avoid double free */
>> --
>> 2.27.0
>>

Bhumkar, Tejas Arvind Jan. 23, 2024, 6:53 p.m. UTC | #3

[AMD Official Use Only - General]

Hi Ilias & Heinrich,

> -----Original Message-----
> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Sent: Tuesday, January 23, 2024 3:30 PM
> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>; Bhumkar, Tejas Arvind
> <tejas.arvind.bhumkar@amd.com>
> Cc: u-boot@lists.denx.de; xypron.glpk@gmx.de; trini@konsulko.com;
> sjg@chromium.org; Simek, Michal <michal.simek@amd.com>; Abbarapu,
> Venkatesh <venkatesh.abbarapu@amd.com>; git@xilinx.com
> Subject: Re: [PATCH] efi_loader : Suppress error print message
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 1/23/24 09:33, Ilias Apalodimas wrote:
> > Hi Tejas,
> >
> > On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
> > <tejas.arvind.bhumkar@amd.com> wrote:
> >>
> >> Currently, on certain Xilinx platforms, an issue has been identified,
> >> manifesting as follows:
>
> Hello Tejas,
>
> thank you for bringing forward this issue.
>
> Which defconfig are you relating to?

[Tejas]:
Checking with xilinx_zynqmp_virt_defconfig

>
> >>
> >> Starting kernel ...
> >>
> >> efi_free_pool: illegal free 0x0000000077830040
> >> efi_free_pool: illegal free 0x000000007782d040
> >> efi_free_pool: illegal free 0x000000007782c040
> >>
> >> The issue arises when the ramdisk image is relocated, placing it
> >> within the previously allocated EFI memory region( as EFI is
> >> established quite early in U-Boot).
>
> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider EFI
> memory map") was meant to avoid such a situation.

[Tejas] :
I'm verifying against the latest changes in the master branch. The introduction of commit 06d514d77c37 ("lmb: consider EFI memory map") has resolved the occurrence of the "efi_free_pool: illegal free" error. but, it leads to a new error, as detailed in the following patch: https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora.com/

>
> >
> > I don't mind suppressing the print for some time, but out of
> > curiosity, how is the ramdisk relocated? LMB should be aware of the
> > EFI regions by then, so I assume the relocation code doesn't check
> > those?


[Tejas] :  I observe that the relocation of the RAM disk is taking place in the line below.
https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491
Yes, the relocated code specifically examines the LMB region and does not consider the EFI region.

>
> The indicated situation is serious. If the EFI sub-system is using the same memory
> area as the ramdisk, this may lead to corruption of the ramdisk. Suppressing the
> messages is by no means adequate to solve the problem.

[Tejas] :
The challenge arises when relocating the ramdisk image, inserting it into the previously assigned EFI memory region,
established early in U-Boot. Consequently, when attempting to release memory in the EFI region during the handover
process to the kernel in the efi_free_pool function, we first verify if the memory was allocated by efi_allocate_pool().
The issue originates from a checksum mismatch because, during the ramdisk relocation, we overwrite memory allocated by EFI.
This leads to the appearance of the error message: efi_free_pool: illegal free 0x0000000077830040.
Crucially, there is no corruption of the ramdisk seen since we do not actually releasing memory due to the checksum mismatch.
In our testing, this issue was observed only when the ramdisk size exceeded approximately 24 MB.

>
> Best regards
>
> Heinrich
>
>
> >
> > Thanks
> > /Ilias
> >
> >> Consequently, when
> >> attempting to release memory in the EFI memory region during the
> >> handover process to the kernel,we encounter memory violations.
> >>
> >> Highlighting that EFI remains active primarily during the booting of
> >> an EFI application, and the lmb persists while configuring images for
> >> the boot process. Since we aren't utilizing the EFI memory region
> >> during the boot process, there is no adverse impact even in the event
> >> of a violation.
> >>
> >> Currently, there is an ongoing discussion regarding the handling
> >> strategies of three memory allocators: malloc, lmb, and EFI. This
> >> discussion is documented in the email chain titled "Proposal: U-Boot
> >> memory management."
> >>
> >> Therefore, it is advisable to suppress the print message during the
> >> boot process for now.
> >>
> >> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
> >> ---
> >>   lib/efi_loader/efi_memory.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/lib/efi_loader/efi_memory.c
> >> b/lib/efi_loader/efi_memory.c index edfad2d95a..821fe7616e 100644
> >> --- a/lib/efi_loader/efi_memory.c
> >> +++ b/lib/efi_loader/efi_memory.c
> >> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
> >>          /* Check that this memory was allocated by efi_allocate_pool() */
> >>          if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
> >>              alloc->checksum != checksum(alloc)) {
> >> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
> >> +               debug("%s: illegal free 0x%p\n", __func__, buffer);
> >>                  return EFI_INVALID_PARAMETER;
> >>          }
> >>          /* Avoid double free */
> >> --
> >> 2.27.0
> >>

Heinrich Schuchardt Jan. 23, 2024, 8:38 p.m. UTC | #4

On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote:
> [AMD Official Use Only - General]
>
> Hi Ilias & Heinrich,
>
>> -----Original Message-----
>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> Sent: Tuesday, January 23, 2024 3:30 PM
>> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>; Bhumkar, Tejas Arvind
>> <tejas.arvind.bhumkar@amd.com>
>> Cc: u-boot@lists.denx.de; xypron.glpk@gmx.de; trini@konsulko.com;
>> sjg@chromium.org; Simek, Michal <michal.simek@amd.com>; Abbarapu,
>> Venkatesh <venkatesh.abbarapu@amd.com>; git@xilinx.com
>> Subject: Re: [PATCH] efi_loader : Suppress error print message
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> On 1/23/24 09:33, Ilias Apalodimas wrote:
>>> Hi Tejas,
>>>
>>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
>>> <tejas.arvind.bhumkar@amd.com> wrote:
>>>>
>>>> Currently, on certain Xilinx platforms, an issue has been identified,
>>>> manifesting as follows:
>>
>> Hello Tejas,
>>
>> thank you for bringing forward this issue.
>>
>> Which defconfig are you relating to?
>
> [Tejas]:
> Checking with xilinx_zynqmp_virt_defconfig
>
>>
>>>>
>>>> Starting kernel ...
>>>>
>>>> efi_free_pool: illegal free 0x0000000077830040
>>>> efi_free_pool: illegal free 0x000000007782d040
>>>> efi_free_pool: illegal free 0x000000007782c040
>>>>
>>>> The issue arises when the ramdisk image is relocated, placing it
>>>> within the previously allocated EFI memory region( as EFI is
>>>> established quite early in U-Boot).
>>
>> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider EFI
>> memory map") was meant to avoid such a situation.
>
> [Tejas] :
> I'm verifying against the latest changes in the master branch. The introduction of commit 06d514d77c37 ("lmb: consider EFI memory map") has resolved the occurrence of the "efi_free_pool: illegal free" error. but, it leads to a new error, as detailed in the following patch: https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora.com/

Could you, please, try to reproduce your issues with origin/master as of
today and provide the full boot log. Please, also provide the output of
the bdinfo and the printenv command as well as the sizes of the kernel
and the RAM disk.

Best regards

Heinrich

>
>>
>>>
>>> I don't mind suppressing the print for some time, but out of
>>> curiosity, how is the ramdisk relocated? LMB should be aware of the
>>> EFI regions by then, so I assume the relocation code doesn't check
>>> those?
>
>
> [Tejas] :  I observe that the relocation of the RAM disk is taking place in the line below.
> https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491
> Yes, the relocated code specifically examines the LMB region and does not consider the EFI region.
>
>>
>> The indicated situation is serious. If the EFI sub-system is using the same memory
>> area as the ramdisk, this may lead to corruption of the ramdisk. Suppressing the
>> messages is by no means adequate to solve the problem.
>
> [Tejas] :
> The challenge arises when relocating the ramdisk image, inserting it into the previously assigned EFI memory region,
> established early in U-Boot. Consequently, when attempting to release memory in the EFI region during the handover
> process to the kernel in the efi_free_pool function, we first verify if the memory was allocated by efi_allocate_pool().
> The issue originates from a checksum mismatch because, during the ramdisk relocation, we overwrite memory allocated by EFI.
> This leads to the appearance of the error message: efi_free_pool: illegal free 0x0000000077830040.
> Crucially, there is no corruption of the ramdisk seen since we do not actually releasing memory due to the checksum mismatch.
> In our testing, this issue was observed only when the ramdisk size exceeded approximately 24 MB.
>
>>
>> Best regards
>>
>> Heinrich
>>
>>
>>>
>>> Thanks
>>> /Ilias
>>>
>>>> Consequently, when
>>>> attempting to release memory in the EFI memory region during the
>>>> handover process to the kernel,we encounter memory violations.
>>>>
>>>> Highlighting that EFI remains active primarily during the booting of
>>>> an EFI application, and the lmb persists while configuring images for
>>>> the boot process. Since we aren't utilizing the EFI memory region
>>>> during the boot process, there is no adverse impact even in the event
>>>> of a violation.
>>>>
>>>> Currently, there is an ongoing discussion regarding the handling
>>>> strategies of three memory allocators: malloc, lmb, and EFI. This
>>>> discussion is documented in the email chain titled "Proposal: U-Boot
>>>> memory management."
>>>>
>>>> Therefore, it is advisable to suppress the print message during the
>>>> boot process for now.
>>>>
>>>> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
>>>> ---
>>>>    lib/efi_loader/efi_memory.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/lib/efi_loader/efi_memory.c
>>>> b/lib/efi_loader/efi_memory.c index edfad2d95a..821fe7616e 100644
>>>> --- a/lib/efi_loader/efi_memory.c
>>>> +++ b/lib/efi_loader/efi_memory.c
>>>> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
>>>>           /* Check that this memory was allocated by efi_allocate_pool() */
>>>>           if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
>>>>               alloc->checksum != checksum(alloc)) {
>>>> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
>>>> +               debug("%s: illegal free 0x%p\n", __func__, buffer);
>>>>                   return EFI_INVALID_PARAMETER;
>>>>           }
>>>>           /* Avoid double free */
>>>> --
>>>> 2.27.0
>>>>
>

Bhumkar, Tejas Arvind Jan. 28, 2024, 5:20 a.m. UTC | #5

[AMD Official Use Only - General]

Hi Heinrich,

> -----Original Message-----
> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Sent: Wednesday, January 24, 2024 2:09 AM
> To: Bhumkar, Tejas Arvind <tejas.arvind.bhumkar@amd.com>
> Cc: u-boot@lists.denx.de; trini@konsulko.com; sjg@chromium.org; Simek, Michal
> <michal.simek@amd.com>; Abbarapu, Venkatesh
> <venkatesh.abbarapu@amd.com>; git@xilinx.com; Ilias Apalodimas
> <ilias.apalodimas@linaro.org>
> Subject: Re: [PATCH] efi_loader : Suppress error print message
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote:
> > [AMD Official Use Only - General]
> >
> > Hi Ilias & Heinrich,
> >
> >> -----Original Message-----
> >> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> Sent: Tuesday, January 23, 2024 3:30 PM
> >> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>; Bhumkar, Tejas
> >> Arvind <tejas.arvind.bhumkar@amd.com>
> >> Cc: u-boot@lists.denx.de; xypron.glpk@gmx.de; trini@konsulko.com;
> >> sjg@chromium.org; Simek, Michal <michal.simek@amd.com>; Abbarapu,
> >> Venkatesh <venkatesh.abbarapu@amd.com>; git@xilinx.com
> >> Subject: Re: [PATCH] efi_loader : Suppress error print message
> >>
> >> Caution: This message originated from an External Source. Use proper
> >> caution when opening attachments, clicking links, or responding.
> >>
> >>
> >> On 1/23/24 09:33, Ilias Apalodimas wrote:
> >>> Hi Tejas,
> >>>
> >>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
> >>> <tejas.arvind.bhumkar@amd.com> wrote:
> >>>>
> >>>> Currently, on certain Xilinx platforms, an issue has been
> >>>> identified, manifesting as follows:
> >>
> >> Hello Tejas,
> >>
> >> thank you for bringing forward this issue.
> >>
> >> Which defconfig are you relating to?
> >
> > [Tejas]:
> > Checking with xilinx_zynqmp_virt_defconfig
> >
> >>
> >>>>
> >>>> Starting kernel ...
> >>>>
> >>>> efi_free_pool: illegal free 0x0000000077830040
> >>>> efi_free_pool: illegal free 0x000000007782d040
> >>>> efi_free_pool: illegal free 0x000000007782c040
> >>>>
> >>>> The issue arises when the ramdisk image is relocated, placing it
> >>>> within the previously allocated EFI memory region( as EFI is
> >>>> established quite early in U-Boot).
> >>
> >> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb:
> >> consider EFI memory map") was meant to avoid such a situation.
> >
> > [Tejas] :
> > I'm verifying against the latest changes in the master branch. The
> > introduction of commit 06d514d77c37 ("lmb: consider EFI memory map")
> > has resolved the occurrence of the "efi_free_pool: illegal free"
> > error. but, it leads to a new error, as detailed in the following
> > patch:
> > https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora.
> > com/
>
> Could you, please, try to reproduce your issues with origin/master as of today and
> provide the full boot log. Please, also provide the output of the bdinfo and the
> printenv command as well as the sizes of the kernel and the RAM disk.

[Tejas]: I've provided two logs: one obtained from the latest u-boot origin/master, resulting in the "ERROR: reserving fdt memory region failed" error, and the other from reverting commit 06d514d77c37 ("lmb: consider EFI memory map"), which leads to the "efi_free_pool: illegal free" error.

Thank You,
Tejas.

>
> Best regards
>
> Heinrich
>
> >
> >>
> >>>
> >>> I don't mind suppressing the print for some time, but out of
> >>> curiosity, how is the ramdisk relocated? LMB should be aware of the
> >>> EFI regions by then, so I assume the relocation code doesn't check
> >>> those?
> >
> >
> > [Tejas] :  I observe that the relocation of the RAM disk is taking place in the line
> below.
> > https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491
> > Yes, the relocated code specifically examines the LMB region and does not
> consider the EFI region.
> >
> >>
> >> The indicated situation is serious. If the EFI sub-system is using
> >> the same memory area as the ramdisk, this may lead to corruption of
> >> the ramdisk. Suppressing the messages is by no means adequate to solve the
> problem.
> >
> > [Tejas] :
> > The challenge arises when relocating the ramdisk image, inserting it
> > into the previously assigned EFI memory region, established early in
> > U-Boot. Consequently, when attempting to release memory in the EFI region
> during the handover process to the kernel in the efi_free_pool function, we first
> verify if the memory was allocated by efi_allocate_pool().
> > The issue originates from a checksum mismatch because, during the ramdisk
> relocation, we overwrite memory allocated by EFI.
> > This leads to the appearance of the error message: efi_free_pool: illegal free
> 0x0000000077830040.
> > Crucially, there is no corruption of the ramdisk seen since we do not actually
> releasing memory due to the checksum mismatch.
> > In our testing, this issue was observed only when the ramdisk size exceeded
> approximately 24 MB.
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>
> >>>
> >>> Thanks
> >>> /Ilias
> >>>
> >>>> Consequently, when
> >>>> attempting to release memory in the EFI memory region during the
> >>>> handover process to the kernel,we encounter memory violations.
> >>>>
> >>>> Highlighting that EFI remains active primarily during the booting
> >>>> of an EFI application, and the lmb persists while configuring
> >>>> images for the boot process. Since we aren't utilizing the EFI
> >>>> memory region during the boot process, there is no adverse impact
> >>>> even in the event of a violation.
> >>>>
> >>>> Currently, there is an ongoing discussion regarding the handling
> >>>> strategies of three memory allocators: malloc, lmb, and EFI. This
> >>>> discussion is documented in the email chain titled "Proposal:
> >>>> U-Boot memory management."
> >>>>
> >>>> Therefore, it is advisable to suppress the print message during the
> >>>> boot process for now.
> >>>>
> >>>> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
> >>>> ---
> >>>>    lib/efi_loader/efi_memory.c | 2 +-
> >>>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/lib/efi_loader/efi_memory.c
> >>>> b/lib/efi_loader/efi_memory.c index edfad2d95a..821fe7616e 100644
> >>>> --- a/lib/efi_loader/efi_memory.c
> >>>> +++ b/lib/efi_loader/efi_memory.c
> >>>> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
> >>>>           /* Check that this memory was allocated by efi_allocate_pool() */
> >>>>           if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
> >>>>               alloc->checksum != checksum(alloc)) {
> >>>> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
> >>>> +               debug("%s: illegal free 0x%p\n", __func__, buffer);
> >>>>                   return EFI_INVALID_PARAMETER;
> >>>>           }
> >>>>           /* Avoid double free */
> >>>> --
> >>>> 2.27.0
> >>>>
> >
U-Boot 2024.01-01064-g15e7927b5a-dirty (Jan 27 2024 - 21:57:38 +0530)

CPU:   ZynqMP
Silicon: v3
Chip:  xck26
Model: ZynqMP KV260 revB
Board: Xilinx ZynqMP
DRAM:  2 GiB (effective 4 GiB)
PMUFW:	v1.1
Xilinx I2C FRU format at nvmem0:
 Manufacturer Name: XILINX
 Product Name: SMK-K26-XCL2G
 Serial No: XFL1NVGB5TUN
 Part Number: 5057-01  
 File ID: 0x0
 Revision Number: 1
Xilinx I2C FRU format at nvmem1:
 Manufacturer Name: XILINX
 Product Name: SCK-KV-G        
 Serial No: XFL1P1DYKME5
 Part Number: 5066-01  
 File ID: 0x0
 Revision Number: 1
EL Level:	EL2
Secure Boot:	not authenticated, not encrypted
EFI: efi_add_memory_map_pg: 0x0 0x80000 7 no
EFI: efi_add_memory_map_pg: 0x7fe00000 0x200 4 yes
EFI: efi_add_memory_map_pg: 0x800000000 0x80000 7 no
EFI: efi_add_memory_map_pg: 0x800000000 0x80000 4 yes
EFI: efi_add_memory_map_pg: 0x7780f000 0x85f1 3 no
EFI: efi_add_memory_map_pg: 0x7f890000 0x10 5 no
Core:  92 devices, 33 uclasses, devicetree: board
EFI: efi_add_memory_map_pg: 0x7780e000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x7780d000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x7780c000 0x1 4 yes
NAND:  0 MiB
MMC:   mmc@ff170000: 1
Loading Environment from nowhere... OK
In:    No input devices available!
Out:   No output devices available!
Err:   No error devices available!
Bootmode: JTAG_MODE
Reset reason:	DEBUG 
Net:   
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 1, interface rgmii-id
eth0: ethernet@ff0e0000
tpm_tis_spi_probe: missing reset GPIO
TPM done

gpio: pin gpio@ff0a000038 (gpio 38) value is 0
gpio: pin gpio@ff0a000038 (gpio 38) value is 1
scanning bus for devices...
starting USB...
No working controllers found
Hit any key to stop autoboot:  0 
ZynqMP> 
ZynqMP> 
ZynqMP> 
ZynqMP> fatls mmc 1
EFI: efi_add_memory_map_pg: 0x7780b000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x7780a000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77809000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77808000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77809000 0x1 7 no
EFI: efi_add_memory_map_pg: 0x77809000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77807000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77806000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77807000 0x1 7 no
EFI: efi_add_memory_map_pg: 0x77807000 0x1 4 yes
 22809088   Image
 25933956   ramdisk.cpio.gz.u-boot
    43353   system.dtb
    43353   system-zynqmp-sck-kv-g-revB.dtb
     3474   boot.scr
 24881329   ramdisk_petalinux.cpio.gz.u-boot

6 file(s), 0 dir(s)

ZynqMP> printenv
autoload=no
baudrate=115200
board_manufacturer=XILINX
board_name=SMK-K26-XCL2G
board_rev=1
board_serial=XFL1NVGB5TUN
board_uuid=19015af8-58be-4215-801f-585b4047307a
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
bootcmd=setenv model $board_name && if setexpr model gsub .*$starter* $starter; then run som_cc_boot; else bootmenu; fi
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_jtag=echo JTAG: Trying to boot script at ${scriptaddr} && source ${scriptaddr}; echo JTAG: SCRIPT FAILED: continuing...;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_nand0= nand info && nand read $scriptaddr $script_offset_f $script_size_f && echo NAND: Trying to boot script at ${scriptaddr} && source ${scriptaddr}; echo NAND: SCRIPT FAILED: continuing...;
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_qspi0=sf probe 0 0 0 && sf read $scriptaddr $script_offset_f $script_size_f && echo QSPI: Trying to boot script at ${scriptaddr} && source ${scriptaddr}; echo QSPI: SCRIPT FAILED: continuing...;
bootcmd_scsi0=devnum=0; run scsi_boot
bootcmd_usb0=devnum=0; run usb_boot
bootcmd_usb1=devnum=1; run usb_boot
bootcmd_usb2=devnum=2; run usb_boot
bootcmd_usb3=devnum=3; run usb_boot
bootcmd_usb4=devnum=4; run usb_boot
bootcmd_usb5=devnum=5; run usb_boot
bootdelay=2
bootfstype=fat
bootm_low=0
bootm_size=7fe00000
bootmenu_0=Auto-Select - 1. CC boot 2. SOM boot=run som_cc_boot || run som_mmc_boot
bootmenu_1=Carrier Card (CC) boot device=run som_cc_boot
bootmenu_2=System on Module (SOM) boot device=run som_mmc_boot
bootmenu_default=0
bootmenu_delay=5
card1_manufacturer=XILINX
card1_name=SCK-KV-G
card1_rev=1
card1_serial=XFL1P1DYKME5
card1_uuid=4e9849f8-80a2-4acd-821a-1a5d10c3e7fa
dfu_ram=run dfu_ram_info && dfu 0 ram 0
dfu_ram_info=setenv dfu_alt_info Image ram $kernel_addr $kernel_size\\;system.dtb ram $fdt_addr $fdt_size
distro_bootcmd=scsi_need_init=; for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
eth-kv260=if test ${card1_name} = SCK-KV-G; then run kv260_gem3; fi
eth_init=run eth-kv260
ethaddr=00:0a:35:0f:26:0c
fdt_addr_r=0x40000000
fdt_high=10000000
fdtcontroladdr=7b80f290
fdtfile=xilinx/zynqmp-sk-kv260-rev2.dtb
fileaddr=18000000
initrd_high=79000000
kernel_addr_r=0x18000000
kv260_gem3=gpio toggle gpio@ff0a000038 && gpio toggle gpio@ff0a000038
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
multiboot=0
preboot=setenv boot_targets; setenv modeboot; run tpm_start; cls; run eth_init; run scsi_init; usb start
pwm23=mw 0xFF18005C 0xa0
pwm7=mw 0xFF18001C 0xa0
pxefile_addr_r=0x10000000
qspi0=sf erase 200000 +${filesize} && sf write 100000 200000 ${filesize}
qspi1=sf erase f80000 +${filesize} && sf write 100000 f80000 ${filesize}
qspi_spl=sf probe && load mmc 1 100000 boot.bin && run qspi0 && load mmc 1 100000 u-boot.itb && run qspi1
qspi_spl_net=sf probe && dhcp && tftpboot 100000 192.168.0.105:boot.bin && run qspi0 && dhcp && tftpboot 100000 192.168.0.105:u-boot.itb && run qspi1
ramdisk_addr_r=0x02100000
reset_reason=DEBUG
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
script_offset_f=3e80000
script_size_f=0x80000
scriptaddr=20000000
scsi_boot=run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
som_cc_boot=if test ${card1_name} = SCK-KR-G; then setenv boot_targets usb0 usb1 usb2 usb3 dhcp pxe; else setenv boot_targets mmc1 usb0 usb1 usb2 usb3 scsi0 dhcp pxe; fi && run distro_bootcmd
som_eeprom_lock=i2c dev 1; i2c mw 68 25 3f
som_eeprom_unlock=i2c dev 1; i2c mw 68 25 00
som_mmc_boot=setenv boot_targets mmc0 && run distro_bootcmd
som_pwm=load mmc 1 100000 fpga.bit && fpga loadb 0 100000 $filesize && pwm config 0 0 10000 1200 && pwm enable 0 0 && pwm config 0 0 10000 1400 && pwm config 0 0 10000 1600
starter=SMK-K26-XCL2G
thor_ram=run dfu_ram_info && thordown 0 ram 0
tpm_start=tpm init && tpm startup TPM2_SU_CLEAR && echo "TPM done"
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi

Environment size: 6714/262139 bytes
ZynqMP> bdinfo
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000000000000
-> size     = 0x0000000080000000
DRAM bank   = 0x0000000000000001
-> start    = 0x0000000800000000
-> size     = 0x0000000080000000
flashstart  = 0x0000000000000000
flashsize   = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate    = 115200 bps
relocaddr   = 0x000000007f89a000
reloc off   = 0x000000007789a000
Build       = 64-bit
current eth = ethernet@ff0e0000
ethaddr     = 00:0a:35:0f:26:0c
IP addr     = <NULL>
fdt_blob    = 0x000000007b80f290
new_fdt     = 0x000000007b80f290
fdt_size    = 0x000000000000aae0
Video       = display@fd4a0000 inactive
## Current stack ends at 0x7b80ec20 lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x4 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x7b80ac20-0x7fdfffff], 0x045f53e0 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
devicetree  = board
arch_number = 0x0000000000000000
TLB addr    = 0x000000007fde0000
irq_sp      = 0x000000007b80f280
sp start    = 0x000000007b80f280
ARM frequency = 99 MHz
DSP frequency = 0 MHz
DDR frequency = 0 MHz
Early malloc usage: 1a48 / 8000
ZynqMP> boot
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot.scr
## Current stack ends at 0x7b80cd70 lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x4 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x7b808d70-0x7fdfffff], 0x045f7290 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
3474 bytes read in 52 ms (64.5 KiB/s)
## Executing script at 20000000
Trying to load boot images from mmc1
## Current stack ends at 0x7b80c6d0 lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x4 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x7b8086d0-0x7fdfffff], 0x045f7930 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
EFI: efi_add_memory_map_pg: 0x77805000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77804000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77803000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77802000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77804000 0x1 7 no
22809088 bytes read in 1517 ms (14.3 MiB/s)
## Current stack ends at 0x7b80c6d0 lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x4 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x7b8086d0-0x7fdfffff], 0x045f7930 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
43353 bytes read in 57 ms (742.2 KiB/s)
## Current stack ends at 0x7b80c6d0 lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x4 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x7b8086d0-0x7fdfffff], 0x045f7930 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
25933956 bytes read in 1725 ms (14.3 MiB/s)
## Current stack ends at 0x7b80cb30 *  ramdisk: cmdline image address = 0x04000000
## Loading init Ramdisk from Legacy Image at 04000000 ...
   Image Name:   kria-image-initramfs-k26-smk-202
   Created:      2011-04-05  23:00:00 UTC
   Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
   Data Size:    25933892 Bytes = 24.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   ramdisk start = 0x04000040, ramdisk end = 0x058bb884
## Flattened Device Tree blob at 00100000
   Booting using the fdt blob at 0x100000
Working FDT set to 100000
## FIT configuration was not specified
## FIT configuration was not specified
images->rd_start = 0x04000040, images->rd_end = 0x058bb884
rd_len = 0x018bb844
## initrd_high = 0x79000000, copy_to_ram = 1
lmbbase_lmbsize=0x7fe00000
base_min = 0x79000000
   Loading Ramdisk to 77744000, end 78fff844 ... OK
   ramdisk load start = 0x77744000, ramdisk load end = 0x78fff844
using: FDT
lmbbase_lmbsize=0x7fe00000
base_min = 0x10000000
   Loading Device Tree to 000000000fff2000, end 000000000ffff958 ... OK
Working FDT set to fff2000
## Transferring control to Linux (at address 200000)...

Starting kernel ...

efi_free_pool: illegal free 0x000000007780b040
efi_free_pool: illegal free 0x0000000077808040
efi_free_pool: illegal free 0x0000000077806040
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
U-Boot 2024.01-01064-g15e7927b5a-dirty (Jan 27 2024 - 22:24:10 +0530)

CPU:   ZynqMP
Silicon: v3
Chip:  xck26
Model: ZynqMP KV260 revB
Board: Xilinx ZynqMP
DRAM:  2 GiB (effective 4 GiB)
PMUFW:	v1.1
Xilinx I2C FRU format at nvmem0:
 Manufacturer Name: XILINX
 Product Name: SMK-K26-XCL2G
 Serial No: XFL1NVGB5TUN
 Part Number: 5057-01  
 File ID: 0x0
 Revision Number: 1
Xilinx I2C FRU format at nvmem1:
 Manufacturer Name: XILINX
 Product Name: SCK-KV-G        
 Serial No: XFL1P1DYKME5
 Part Number: 5066-01  
 File ID: 0x0
 Revision Number: 1
EL Level:	EL2
Secure Boot:	not authenticated, not encrypted
EFI: efi_add_memory_map_pg: 0x0 0x80000 7 no
EFI: efi_add_memory_map_pg: 0x7fe00000 0x200 4 yes
EFI: efi_add_memory_map_pg: 0x800000000 0x80000 7 no
EFI: efi_add_memory_map_pg: 0x800000000 0x80000 4 yes
EFI: efi_add_memory_map_pg: 0x7780f000 0x85f1 3 no
EFI: efi_add_memory_map_pg: 0x7f890000 0x10 5 no
Core:  92 devices, 33 uclasses, devicetree: board
EFI: efi_add_memory_map_pg: 0x7780e000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x7780d000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x7780c000 0x1 4 yes
NAND:  0 MiB
MMC:   mmc@ff170000: 1
Loading Environment from nowhere... OK
In:    No input devices available!
Out:   No output devices available!
Err:   No error devices available!
Bootmode: JTAG_MODE
Reset reason:	DEBUG 
Net:   
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 1, interface rgmii-id
eth0: ethernet@ff0e0000
tpm_tis_spi_probe: missing reset GPIO
TPM done

gpio: pin gpio@ff0a000038 (gpio 38) value is 0
gpio: pin gpio@ff0a000038 (gpio 38) value is 1
scanning bus for devices...
starting USB...
No working controllers found
Hit any key to stop autoboot:  0 
ZynqMP> 
ZynqMP> 
ZynqMP> 
ZynqMP> fatls mmc 1
EFI: efi_add_memory_map_pg: 0x7780b000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x7780a000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77809000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77808000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77809000 0x1 7 no
EFI: efi_add_memory_map_pg: 0x77809000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77807000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77806000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77807000 0x1 7 no
EFI: efi_add_memory_map_pg: 0x77807000 0x1 4 yes
 22809088   Image
 25933956   ramdisk.cpio.gz.u-boot
    43353   system.dtb
    43353   system-zynqmp-sck-kv-g-revB.dtb
     3474   boot.scr
 24881329   ramdisk_petalinux.cpio.gz.u-boot

6 file(s), 0 dir(s)

ZynqMP> printenv
autoload=no
baudrate=115200
board_manufacturer=XILINX
board_name=SMK-K26-XCL2G
board_rev=1
board_serial=XFL1NVGB5TUN
board_uuid=19015af8-58be-4215-801f-585b4047307a
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
bootcmd=setenv model $board_name && if setexpr model gsub .*$starter* $starter; then run som_cc_boot; else bootmenu; fi
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_jtag=echo JTAG: Trying to boot script at ${scriptaddr} && source ${scriptaddr}; echo JTAG: SCRIPT FAILED: continuing...;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_nand0= nand info && nand read $scriptaddr $script_offset_f $script_size_f && echo NAND: Trying to boot script at ${scriptaddr} && source ${scriptaddr}; echo NAND: SCRIPT FAILED: continuing...;
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_qspi0=sf probe 0 0 0 && sf read $scriptaddr $script_offset_f $script_size_f && echo QSPI: Trying to boot script at ${scriptaddr} && source ${scriptaddr}; echo QSPI: SCRIPT FAILED: continuing...;
bootcmd_scsi0=devnum=0; run scsi_boot
bootcmd_usb0=devnum=0; run usb_boot
bootcmd_usb1=devnum=1; run usb_boot
bootcmd_usb2=devnum=2; run usb_boot
bootcmd_usb3=devnum=3; run usb_boot
bootcmd_usb4=devnum=4; run usb_boot
bootcmd_usb5=devnum=5; run usb_boot
bootdelay=2
bootfstype=fat
bootm_low=0
bootm_size=7fe00000
bootmenu_0=Auto-Select - 1. CC boot 2. SOM boot=run som_cc_boot || run som_mmc_boot
bootmenu_1=Carrier Card (CC) boot device=run som_cc_boot
bootmenu_2=System on Module (SOM) boot device=run som_mmc_boot
bootmenu_default=0
bootmenu_delay=5
card1_manufacturer=XILINX
card1_name=SCK-KV-G
card1_rev=1
card1_serial=XFL1P1DYKME5
card1_uuid=4e9849f8-80a2-4acd-821a-1a5d10c3e7fa
dfu_ram=run dfu_ram_info && dfu 0 ram 0
dfu_ram_info=setenv dfu_alt_info Image ram $kernel_addr $kernel_size\\;system.dtb ram $fdt_addr $fdt_size
distro_bootcmd=scsi_need_init=; for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
eth-kv260=if test ${card1_name} = SCK-KV-G; then run kv260_gem3; fi
eth_init=run eth-kv260
ethaddr=00:0a:35:0f:26:0c
fdt_addr_r=0x40000000
fdt_high=10000000
fdtcontroladdr=7b80f290
fdtfile=xilinx/zynqmp-sk-kv260-rev2.dtb
fileaddr=18000000
initrd_high=79000000
kernel_addr_r=0x18000000
kv260_gem3=gpio toggle gpio@ff0a000038 && gpio toggle gpio@ff0a000038
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
multiboot=0
preboot=setenv boot_targets; setenv modeboot; run tpm_start; cls; run eth_init; run scsi_init; usb start
pwm23=mw 0xFF18005C 0xa0
pwm7=mw 0xFF18001C 0xa0
pxefile_addr_r=0x10000000
qspi0=sf erase 200000 +${filesize} && sf write 100000 200000 ${filesize}
qspi1=sf erase f80000 +${filesize} && sf write 100000 f80000 ${filesize}
qspi_spl=sf probe && load mmc 1 100000 boot.bin && run qspi0 && load mmc 1 100000 u-boot.itb && run qspi1
qspi_spl_net=sf probe && dhcp && tftpboot 100000 192.168.0.105:boot.bin && run qspi0 && dhcp && tftpboot 100000 192.168.0.105:u-boot.itb && run qspi1
ramdisk_addr_r=0x02100000
reset_reason=DEBUG
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
script_offset_f=3e80000
script_size_f=0x80000
scriptaddr=20000000
scsi_boot=run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
som_cc_boot=if test ${card1_name} = SCK-KR-G; then setenv boot_targets usb0 usb1 usb2 usb3 dhcp pxe; else setenv boot_targets mmc1 usb0 usb1 usb2 usb3 scsi0 dhcp pxe; fi && run distro_bootcmd
som_eeprom_lock=i2c dev 1; i2c mw 68 25 3f
som_eeprom_unlock=i2c dev 1; i2c mw 68 25 00
som_mmc_boot=setenv boot_targets mmc0 && run distro_bootcmd
som_pwm=load mmc 1 100000 fpga.bit && fpga loadb 0 100000 $filesize && pwm config 0 0 10000 1200 && pwm enable 0 0 && pwm config 0 0 10000 1400 && pwm config 0 0 10000 1600
starter=SMK-K26-XCL2G
thor_ram=run dfu_ram_info && thordown 0 ram 0
tpm_start=tpm init && tpm startup TPM2_SU_CLEAR && echo "TPM done"
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi

Environment size: 6714/262139 bytes
ZynqMP> bdinfo
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000000000000
-> size     = 0x0000000080000000
DRAM bank   = 0x0000000000000001
-> start    = 0x0000000800000000
-> size     = 0x0000000080000000
flashstart  = 0x0000000000000000
flashsize   = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate    = 115200 bps
relocaddr   = 0x000000007f89a000
reloc off   = 0x000000007789a000
Build       = 64-bit
current eth = ethernet@ff0e0000
ethaddr     = 00:0a:35:0f:26:0c
IP addr     = <NULL>
fdt_blob    = 0x000000007b80f290
new_fdt     = 0x000000007b80f290
fdt_size    = 0x000000000000aae0
Video       = display@fd4a0000 inactive
## Current stack ends at 0x7b80ec10 EFI: efi_add_memory_map_pg: 0x77805000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77805000 0x1 7 no
lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x5 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x77805000-0x7fffffff], 0x087fb000 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
 reserved[4]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
devicetree  = board
arch_number = 0x0000000000000000
TLB addr    = 0x000000007fde0000
irq_sp      = 0x000000007b80f280
sp start    = 0x000000007b80f280
ARM frequency = 99 MHz
DSP frequency = 0 MHz
DDR frequency = 0 MHz
Early malloc usage: 1a48 / 8000
ZynqMP> boot
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot.scr
## Current stack ends at 0x7b80cd60 EFI: efi_add_memory_map_pg: 0x77805000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77805000 0x1 7 no
lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x5 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x77805000-0x7fffffff], 0x087fb000 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
 reserved[4]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
3474 bytes read in 66 ms (50.8 KiB/s)
## Executing script at 20000000
Trying to load boot images from mmc1
## Current stack ends at 0x7b80c6c0 EFI: efi_add_memory_map_pg: 0x77805000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77805000 0x1 7 no
lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x5 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x77805000-0x7fffffff], 0x087fb000 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
 reserved[4]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
EFI: efi_add_memory_map_pg: 0x77805000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77804000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77803000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77802000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77804000 0x1 7 no
22809088 bytes read in 1532 ms (14.2 MiB/s)
## Current stack ends at 0x7b80c6c0 EFI: efi_add_memory_map_pg: 0x77804000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77804000 0x1 7 no
lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x5 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x77802000-0x7fffffff], 0x087fe000 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
 reserved[4]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
43353 bytes read in 73 ms (579.1 KiB/s)
## Current stack ends at 0x7b80c6c0 EFI: efi_add_memory_map_pg: 0x77804000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77804000 0x1 7 no
lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x0-0x7fffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x5 / max = 0x10
 reserved[0]	[0x3ed00000-0x3ed3ffff], 0x00040000 bytes flags: 4
 reserved[1]	[0x3ef00000-0x3ef3ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x77802000-0x7fffffff], 0x087fe000 bytes flags: 0
 reserved[3]	[0x7ff00000-0x7fffffff], 0x00100000 bytes flags: 4
 reserved[4]	[0x800000000-0x87fffffff], 0x80000000 bytes flags: 0
25933956 bytes read in 1740 ms (14.2 MiB/s)
## Current stack ends at 0x7b80cb10 EFI: efi_add_memory_map_pg: 0x77804000 0x1 4 yes
EFI: efi_add_memory_map_pg: 0x77804000 0x1 7 no
*  ramdisk: cmdline image address = 0x04000000
## Loading init Ramdisk from Legacy Image at 04000000 ...
   Image Name:   kria-image-initramfs-k26-smk-202
   Created:      2011-04-05  23:00:00 UTC
   Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
   Data Size:    25933892 Bytes = 24.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   ramdisk start = 0x04000040, ramdisk end = 0x058bb884
## Flattened Device Tree blob at 00100000
   Booting using the fdt blob at 0x100000
Working FDT set to 100000
## FIT configuration was not specified
## FIT configuration was not specified
images->rd_start = 0x04000040, images->rd_end = 0x058bb884
rd_len = 0x018bb844
## initrd_high = 0x79000000, copy_to_ram = 1
lmbbase_lmbsize=0x7fe00000
base_min = 0x79000000
   Loading Ramdisk to 75f46000, end 77801844 ... OK
   ramdisk load start = 0x75f46000, ramdisk load end = 0x77801844
using: FDT
ERROR: reserving fdt memory region failed (addr=7ff00000 size=100000 flags=4)
lmbbase_lmbsize=0x7fe00000
base_min = 0x10000000
   Loading Device Tree to 000000000fff2000, end 000000000ffff958 ... OK
Working FDT set to fff2000
## Transferring control to Linux (at address 200000)...

Starting kernel ...

EFI: efi_add_memory_map_pg: 0x7780b000 0x1 7 no
EFI: efi_add_memory_map_pg: 0x77808000 0x1 7 no
EFI: efi_add_memory_map_pg: 0x77806000 0x1 7 no
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

Heinrich Schuchardt Jan. 28, 2024, 9:20 a.m. UTC | #6

On 1/28/24 06:20, Bhumkar, Tejas Arvind wrote:
> [AMD Official Use Only - General]
>
> Hi Heinrich,
>
>> -----Original Message-----
>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> Sent: Wednesday, January 24, 2024 2:09 AM
>> To: Bhumkar, Tejas Arvind <tejas.arvind.bhumkar@amd.com>
>> Cc: u-boot@lists.denx.de; trini@konsulko.com; sjg@chromium.org; Simek, Michal
>> <michal.simek@amd.com>; Abbarapu, Venkatesh
>> <venkatesh.abbarapu@amd.com>; git@xilinx.com; Ilias Apalodimas
>> <ilias.apalodimas@linaro.org>
>> Subject: Re: [PATCH] efi_loader : Suppress error print message
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote:
>>> [AMD Official Use Only - General]
>>>
>>> Hi Ilias & Heinrich,
>>>
>>>> -----Original Message-----
>>>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>> Sent: Tuesday, January 23, 2024 3:30 PM
>>>> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>; Bhumkar, Tejas
>>>> Arvind <tejas.arvind.bhumkar@amd.com>
>>>> Cc: u-boot@lists.denx.de; xypron.glpk@gmx.de; trini@konsulko.com;
>>>> sjg@chromium.org; Simek, Michal <michal.simek@amd.com>; Abbarapu,
>>>> Venkatesh <venkatesh.abbarapu@amd.com>; git@xilinx.com
>>>> Subject: Re: [PATCH] efi_loader : Suppress error print message
>>>>
>>>> Caution: This message originated from an External Source. Use proper
>>>> caution when opening attachments, clicking links, or responding.
>>>>
>>>>
>>>> On 1/23/24 09:33, Ilias Apalodimas wrote:
>>>>> Hi Tejas,
>>>>>
>>>>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
>>>>> <tejas.arvind.bhumkar@amd.com> wrote:
>>>>>>
>>>>>> Currently, on certain Xilinx platforms, an issue has been
>>>>>> identified, manifesting as follows:
>>>>
>>>> Hello Tejas,
>>>>
>>>> thank you for bringing forward this issue.
>>>>
>>>> Which defconfig are you relating to?
>>>
>>> [Tejas]:
>>> Checking with xilinx_zynqmp_virt_defconfig
>>>
>>>>
>>>>>>
>>>>>> Starting kernel ...
>>>>>>
>>>>>> efi_free_pool: illegal free 0x0000000077830040
>>>>>> efi_free_pool: illegal free 0x000000007782d040
>>>>>> efi_free_pool: illegal free 0x000000007782c040
>>>>>>
>>>>>> The issue arises when the ramdisk image is relocated, placing it
>>>>>> within the previously allocated EFI memory region( as EFI is
>>>>>> established quite early in U-Boot).
>>>>
>>>> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb:
>>>> consider EFI memory map") was meant to avoid such a situation.
>>>
>>> [Tejas] :
>>> I'm verifying against the latest changes in the master branch. The
>>> introduction of commit 06d514d77c37 ("lmb: consider EFI memory map")
>>> has resolved the occurrence of the "efi_free_pool: illegal free"
>>> error. but, it leads to a new error, as detailed in the following
>>> patch:
>>> https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora.
>>> com/
>>
>> Could you, please, try to reproduce your issues with origin/master as of today and
>> provide the full boot log. Please, also provide the output of the bdinfo and the
>> printenv command as well as the sizes of the kernel and the RAM disk.
>
> [Tejas]: I've provided two logs: one obtained from the latest u-boot origin/master, resulting in the "ERROR: reserving fdt memory region failed" error, and the other from reverting commit 06d514d77c37 ("lmb: consider EFI memory map"), which leads to the "efi_free_pool: illegal free" error.
>
> Thank You,
> Tejas.

Where can I find these logs?

Best regards

Heinrich

>
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>>>
>>>>>
>>>>> I don't mind suppressing the print for some time, but out of
>>>>> curiosity, how is the ramdisk relocated? LMB should be aware of the
>>>>> EFI regions by then, so I assume the relocation code doesn't check
>>>>> those?
>>>
>>>
>>> [Tejas] :  I observe that the relocation of the RAM disk is taking place in the line
>> below.
>>> https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491
>>> Yes, the relocated code specifically examines the LMB region and does not
>> consider the EFI region.
>>>
>>>>
>>>> The indicated situation is serious. If the EFI sub-system is using
>>>> the same memory area as the ramdisk, this may lead to corruption of
>>>> the ramdisk. Suppressing the messages is by no means adequate to solve the
>> problem.
>>>
>>> [Tejas] :
>>> The challenge arises when relocating the ramdisk image, inserting it
>>> into the previously assigned EFI memory region, established early in
>>> U-Boot. Consequently, when attempting to release memory in the EFI region
>> during the handover process to the kernel in the efi_free_pool function, we first
>> verify if the memory was allocated by efi_allocate_pool().
>>> The issue originates from a checksum mismatch because, during the ramdisk
>> relocation, we overwrite memory allocated by EFI.
>>> This leads to the appearance of the error message: efi_free_pool: illegal free
>> 0x0000000077830040.
>>> Crucially, there is no corruption of the ramdisk seen since we do not actually
>> releasing memory due to the checksum mismatch.
>>> In our testing, this issue was observed only when the ramdisk size exceeded
>> approximately 24 MB.
>>>
>>>>
>>>> Best regards
>>>>
>>>> Heinrich
>>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> /Ilias
>>>>>
>>>>>> Consequently, when
>>>>>> attempting to release memory in the EFI memory region during the
>>>>>> handover process to the kernel,we encounter memory violations.
>>>>>>
>>>>>> Highlighting that EFI remains active primarily during the booting
>>>>>> of an EFI application, and the lmb persists while configuring
>>>>>> images for the boot process. Since we aren't utilizing the EFI
>>>>>> memory region during the boot process, there is no adverse impact
>>>>>> even in the event of a violation.
>>>>>>
>>>>>> Currently, there is an ongoing discussion regarding the handling
>>>>>> strategies of three memory allocators: malloc, lmb, and EFI. This
>>>>>> discussion is documented in the email chain titled "Proposal:
>>>>>> U-Boot memory management."
>>>>>>
>>>>>> Therefore, it is advisable to suppress the print message during the
>>>>>> boot process for now.
>>>>>>
>>>>>> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
>>>>>> ---
>>>>>>     lib/efi_loader/efi_memory.c | 2 +-
>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/lib/efi_loader/efi_memory.c
>>>>>> b/lib/efi_loader/efi_memory.c index edfad2d95a..821fe7616e 100644
>>>>>> --- a/lib/efi_loader/efi_memory.c
>>>>>> +++ b/lib/efi_loader/efi_memory.c
>>>>>> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
>>>>>>            /* Check that this memory was allocated by efi_allocate_pool() */
>>>>>>            if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
>>>>>>                alloc->checksum != checksum(alloc)) {
>>>>>> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
>>>>>> +               debug("%s: illegal free 0x%p\n", __func__, buffer);
>>>>>>                    return EFI_INVALID_PARAMETER;
>>>>>>            }
>>>>>>            /* Avoid double free */
>>>>>> --
>>>>>> 2.27.0
>>>>>>
>>>
>

Heinrich Schuchardt Jan. 28, 2024, 10:38 p.m. UTC | #7

On 1/28/24 18:38, Bhumkar, Tejas Arvind wrote:
> [AMD Official Use Only - General]
>
> Hi Heinrich,
>
>> -----Original Message-----
>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> Sent: Sunday, January 28, 2024 2:51 PM
>> To: Bhumkar, Tejas Arvind <tejas.arvind.bhumkar@amd.com>
>> Cc: u-boot@lists.denx.de; trini@konsulko.com; sjg@chromium.org; Simek, Michal
>> <michal.simek@amd.com>; Abbarapu, Venkatesh
>> <venkatesh.abbarapu@amd.com>; git@xilinx.com; Ilias Apalodimas
>> <ilias.apalodimas@linaro.org>
>> Subject: Re: [PATCH] efi_loader : Suppress error print message
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> On 1/28/24 06:20, Bhumkar, Tejas Arvind wrote:
>>> [AMD Official Use Only - General]
>>>
>>> Hi Heinrich,
>>>
>>>> -----Original Message-----
>>>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>> Sent: Wednesday, January 24, 2024 2:09 AM
>>>> To: Bhumkar, Tejas Arvind <tejas.arvind.bhumkar@amd.com>
>>>> Cc: u-boot@lists.denx.de; trini@konsulko.com; sjg@chromium.org;
>>>> Simek, Michal <michal.simek@amd.com>; Abbarapu, Venkatesh
>>>> <venkatesh.abbarapu@amd.com>; git@xilinx.com; Ilias Apalodimas
>>>> <ilias.apalodimas@linaro.org>
>>>> Subject: Re: [PATCH] efi_loader : Suppress error print message
>>>>
>>>> Caution: This message originated from an External Source. Use proper
>>>> caution when opening attachments, clicking links, or responding.
>>>>
>>>>
>>>> On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote:
>>>>> [AMD Official Use Only - General]
>>>>>
>>>>> Hi Ilias & Heinrich,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>> Sent: Tuesday, January 23, 2024 3:30 PM
>>>>>> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>; Bhumkar, Tejas
>>>>>> Arvind <tejas.arvind.bhumkar@amd.com>
>>>>>> Cc: u-boot@lists.denx.de; xypron.glpk@gmx.de; trini@konsulko.com;
>>>>>> sjg@chromium.org; Simek, Michal <michal.simek@amd.com>; Abbarapu,
>>>>>> Venkatesh <venkatesh.abbarapu@amd.com>; git@xilinx.com
>>>>>> Subject: Re: [PATCH] efi_loader : Suppress error print message
>>>>>>
>>>>>> Caution: This message originated from an External Source. Use
>>>>>> proper caution when opening attachments, clicking links, or responding.
>>>>>>
>>>>>>
>>>>>> On 1/23/24 09:33, Ilias Apalodimas wrote:
>>>>>>> Hi Tejas,
>>>>>>>
>>>>>>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
>>>>>>> <tejas.arvind.bhumkar@amd.com> wrote:
>>>>>>>>
>>>>>>>> Currently, on certain Xilinx platforms, an issue has been
>>>>>>>> identified, manifesting as follows:
>>>>>>
>>>>>> Hello Tejas,
>>>>>>
>>>>>> thank you for bringing forward this issue.
>>>>>>
>>>>>> Which defconfig are you relating to?
>>>>>
>>>>> [Tejas]:
>>>>> Checking with xilinx_zynqmp_virt_defconfig
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Starting kernel ...
>>>>>>>>
>>>>>>>> efi_free_pool: illegal free 0x0000000077830040
>>>>>>>> efi_free_pool: illegal free 0x000000007782d040
>>>>>>>> efi_free_pool: illegal free 0x000000007782c040
>>>>>>>>
>>>>>>>> The issue arises when the ramdisk image is relocated, placing it
>>>>>>>> within the previously allocated EFI memory region( as EFI is
>>>>>>>> established quite early in U-Boot).
>>>>>>
>>>>>> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb:
>>>>>> consider EFI memory map") was meant to avoid such a situation.
>>>>>
>>>>> [Tejas] :
>>>>> I'm verifying against the latest changes in the master branch. The
>>>>> introduction of commit 06d514d77c37 ("lmb: consider EFI memory map")
>>>>> has resolved the occurrence of the "efi_free_pool: illegal free"
>>>>> error. but, it leads to a new error, as detailed in the following
>>>>> patch:
>>>>> https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora.
>>>>> com/
>>>>
>>>> Could you, please, try to reproduce your issues with origin/master as
>>>> of today and provide the full boot log. Please, also provide the
>>>> output of the bdinfo and the printenv command as well as the sizes of the
>> kernel and the RAM disk.
>>>
>>> [Tejas]: I've provided two logs: one obtained from the latest u-boot
>> origin/master, resulting in the "ERROR: reserving fdt memory region failed" error,
>> and the other from reverting commit 06d514d77c37 ("lmb: consider EFI memory
>> map"), which leads to the "efi_free_pool: illegal free" error.
>>>
>>> Thank You,
>>> Tejas.
>>
>> Where can I find these logs?
> [Tejas ] : I've sent the attachment in a previous email. I'm not sure why you didn't receive it.
> I've attached it again now. Please confirm if you still haven't received it.
>
> Thank You,
> Tejas.
>>

If I understand your FDT_memory_region_failed.log correctly:

Except for some added debug messages this log matches booting with an
unmodified upstream U-Boot as of Jan 22nd.

Your memory is split into two regions:

0x0 - 0x7ffffff and
0x800000000 - 0x87ffffff.

Your device-tree has a reserved region 0x7ff00000-0x7fffffff.

U-Boot relocates itself into the lower memory block due to current design.

efi_lmb_reserve() marks memory up to 0x7fffffff and
0x800000000-0x87fffffff as reserved.

boot_fdt_reserve_region() writes an error when it tries to reserve the
overlapping region 0x7ff00000-0x7fffffff because LMB recognizes this
region is already reserved.

This should not interfere with booting as boot_fdt_reserve_region() does
not have a return value but is not very clean and should be fixed.

Best regards

Heinrich
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> I don't mind suppressing the print for some time, but out of
>>>>>>> curiosity, how is the ramdisk relocated? LMB should be aware of
>>>>>>> the EFI regions by then, so I assume the relocation code doesn't
>>>>>>> check those?
>>>>>
>>>>>
>>>>> [Tejas] :  I observe that the relocation of the RAM disk is taking
>>>>> place in the line
>>>> below.
>>>>> https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491
>>>>> Yes, the relocated code specifically examines the LMB region and
>>>>> does not
>>>> consider the EFI region.
>>>>>
>>>>>>
>>>>>> The indicated situation is serious. If the EFI sub-system is using
>>>>>> the same memory area as the ramdisk, this may lead to corruption of
>>>>>> the ramdisk. Suppressing the messages is by no means adequate to
>>>>>> solve the
>>>> problem.
>>>>>
>>>>> [Tejas] :
>>>>> The challenge arises when relocating the ramdisk image, inserting it
>>>>> into the previously assigned EFI memory region, established early in
>>>>> U-Boot. Consequently, when attempting to release memory in the EFI
>>>>> region
>>>> during the handover process to the kernel in the efi_free_pool
>>>> function, we first verify if the memory was allocated by efi_allocate_pool().
>>>>> The issue originates from a checksum mismatch because, during the
>>>>> ramdisk
>>>> relocation, we overwrite memory allocated by EFI.
>>>>> This leads to the appearance of the error message: efi_free_pool:
>>>>> illegal free
>>>> 0x0000000077830040.
>>>>> Crucially, there is no corruption of the ramdisk seen since we do
>>>>> not actually
>>>> releasing memory due to the checksum mismatch.
>>>>> In our testing, this issue was observed only when the ramdisk size
>>>>> exceeded
>>>> approximately 24 MB.
>>>>>
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Heinrich
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> /Ilias
>>>>>>>
>>>>>>>> Consequently, when
>>>>>>>> attempting to release memory in the EFI memory region during the
>>>>>>>> handover process to the kernel,we encounter memory violations.
>>>>>>>>
>>>>>>>> Highlighting that EFI remains active primarily during the booting
>>>>>>>> of an EFI application, and the lmb persists while configuring
>>>>>>>> images for the boot process. Since we aren't utilizing the EFI
>>>>>>>> memory region during the boot process, there is no adverse impact
>>>>>>>> even in the event of a violation.
>>>>>>>>
>>>>>>>> Currently, there is an ongoing discussion regarding the handling
>>>>>>>> strategies of three memory allocators: malloc, lmb, and EFI. This
>>>>>>>> discussion is documented in the email chain titled "Proposal:
>>>>>>>> U-Boot memory management."
>>>>>>>>
>>>>>>>> Therefore, it is advisable to suppress the print message during
>>>>>>>> the boot process for now.
>>>>>>>>
>>>>>>>> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
>>>>>>>> ---
>>>>>>>>      lib/efi_loader/efi_memory.c | 2 +-
>>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/lib/efi_loader/efi_memory.c
>>>>>>>> b/lib/efi_loader/efi_memory.c index edfad2d95a..821fe7616e 100644
>>>>>>>> --- a/lib/efi_loader/efi_memory.c
>>>>>>>> +++ b/lib/efi_loader/efi_memory.c
>>>>>>>> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
>>>>>>>>             /* Check that this memory was allocated by efi_allocate_pool() */
>>>>>>>>             if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
>>>>>>>>                 alloc->checksum != checksum(alloc)) {
>>>>>>>> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
>>>>>>>> +               debug("%s: illegal free 0x%p\n", __func__,
>>>>>>>> + buffer);
>>>>>>>>                     return EFI_INVALID_PARAMETER;
>>>>>>>>             }
>>>>>>>>             /* Avoid double free */
>>>>>>>> --
>>>>>>>> 2.27.0
>>>>>>>>
>>>>>
>>>
>

Michal Simek Jan. 29, 2024, 8:27 a.m. UTC | #8

On 1/28/24 10:20, Heinrich Schuchardt wrote:
> On 1/28/24 06:20, Bhumkar, Tejas Arvind wrote:
>> [AMD Official Use Only - General]
>>
>> Hi Heinrich,
>>
>>> -----Original Message-----
>>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>> Sent: Wednesday, January 24, 2024 2:09 AM
>>> To: Bhumkar, Tejas Arvind <tejas.arvind.bhumkar@amd.com>
>>> Cc: u-boot@lists.denx.de; trini@konsulko.com; sjg@chromium.org; Simek, Michal
>>> <michal.simek@amd.com>; Abbarapu, Venkatesh
>>> <venkatesh.abbarapu@amd.com>; git@xilinx.com; Ilias Apalodimas
>>> <ilias.apalodimas@linaro.org>
>>> Subject: Re: [PATCH] efi_loader : Suppress error print message
>>>
>>> Caution: This message originated from an External Source. Use proper caution
>>> when opening attachments, clicking links, or responding.
>>>
>>>
>>> On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote:
>>>> [AMD Official Use Only - General]
>>>>
>>>> Hi Ilias & Heinrich,
>>>>
>>>>> -----Original Message-----
>>>>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>> Sent: Tuesday, January 23, 2024 3:30 PM
>>>>> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>; Bhumkar, Tejas
>>>>> Arvind <tejas.arvind.bhumkar@amd.com>
>>>>> Cc: u-boot@lists.denx.de; xypron.glpk@gmx.de; trini@konsulko.com;
>>>>> sjg@chromium.org; Simek, Michal <michal.simek@amd.com>; Abbarapu,
>>>>> Venkatesh <venkatesh.abbarapu@amd.com>; git@xilinx.com
>>>>> Subject: Re: [PATCH] efi_loader : Suppress error print message
>>>>>
>>>>> Caution: This message originated from an External Source. Use proper
>>>>> caution when opening attachments, clicking links, or responding.
>>>>>
>>>>>
>>>>> On 1/23/24 09:33, Ilias Apalodimas wrote:
>>>>>> Hi Tejas,
>>>>>>
>>>>>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
>>>>>> <tejas.arvind.bhumkar@amd.com> wrote:
>>>>>>>
>>>>>>> Currently, on certain Xilinx platforms, an issue has been
>>>>>>> identified, manifesting as follows:
>>>>>
>>>>> Hello Tejas,
>>>>>
>>>>> thank you for bringing forward this issue.
>>>>>
>>>>> Which defconfig are you relating to?
>>>>
>>>> [Tejas]:
>>>> Checking with xilinx_zynqmp_virt_defconfig
>>>>
>>>>>
>>>>>>>
>>>>>>> Starting kernel ...
>>>>>>>
>>>>>>> efi_free_pool: illegal free 0x0000000077830040
>>>>>>> efi_free_pool: illegal free 0x000000007782d040
>>>>>>> efi_free_pool: illegal free 0x000000007782c040
>>>>>>>
>>>>>>> The issue arises when the ramdisk image is relocated, placing it
>>>>>>> within the previously allocated EFI memory region( as EFI is
>>>>>>> established quite early in U-Boot).
>>>>>
>>>>> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb:
>>>>> consider EFI memory map") was meant to avoid such a situation.
>>>>
>>>> [Tejas] :
>>>> I'm verifying against the latest changes in the master branch. The
>>>> introduction of commit 06d514d77c37 ("lmb: consider EFI memory map")
>>>> has resolved the occurrence of the "efi_free_pool: illegal free"
>>>> error. but, it leads to a new error, as detailed in the following
>>>> patch:
>>>> https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora.
>>>> com/
>>>
>>> Could you, please, try to reproduce your issues with origin/master as of 
>>> today and
>>> provide the full boot log. Please, also provide the output of the bdinfo and the
>>> printenv command as well as the sizes of the kernel and the RAM disk.
>>
>> [Tejas]: I've provided two logs: one obtained from the latest u-boot 
>> origin/master, resulting in the "ERROR: reserving fdt memory region failed" 
>> error, and the other from reverting commit 06d514d77c37 ("lmb: consider EFI 
>> memory map"), which leads to the "efi_free_pool: illegal free" error.
>>
>> Thank You,
>> Tejas.
> 
> Where can I find these logs?

They were attached but you can see them for example here.
https://lore.kernel.org/all/BL3PR12MB645027991850D2C0887FA80DD87F2@BL3PR12MB6450.namprd12.prod.outlook.com/

Thanks,
Michal

Bhumkar, Tejas Arvind Feb. 4, 2024, 4:42 p.m. UTC | #9

[AMD Official Use Only - General]

Hi Heinrich,

> -----Original Message-----
> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Sent: Monday, January 29, 2024 4:09 AM
> To: Bhumkar, Tejas Arvind <tejas.arvind.bhumkar@amd.com>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>; U-Boot Mailing List <u-
> boot@lists.denx.de>; Tom Rini <trini@konsulko.com>
> Subject: Re: [PATCH] efi_loader : Suppress error print message
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 1/28/24 18:38, Bhumkar, Tejas Arvind wrote:
> > [AMD Official Use Only - General]
> >
> > Hi Heinrich,
> >
> >> -----Original Message-----
> >> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> Sent: Sunday, January 28, 2024 2:51 PM
> >> To: Bhumkar, Tejas Arvind <tejas.arvind.bhumkar@amd.com>
> >> Cc: u-boot@lists.denx.de; trini@konsulko.com; sjg@chromium.org;
> >> Simek, Michal <michal.simek@amd.com>; Abbarapu, Venkatesh
> >> <venkatesh.abbarapu@amd.com>; git@xilinx.com; Ilias Apalodimas
> >> <ilias.apalodimas@linaro.org>
> >> Subject: Re: [PATCH] efi_loader : Suppress error print message
> >>
> >> Caution: This message originated from an External Source. Use proper
> >> caution when opening attachments, clicking links, or responding.
> >>
> >>
> >> On 1/28/24 06:20, Bhumkar, Tejas Arvind wrote:
> >>> [AMD Official Use Only - General]
> >>>
> >>> Hi Heinrich,
> >>>
> >>>> -----Original Message-----
> >>>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>> Sent: Wednesday, January 24, 2024 2:09 AM
> >>>> To: Bhumkar, Tejas Arvind <tejas.arvind.bhumkar@amd.com>
> >>>> Cc: u-boot@lists.denx.de; trini@konsulko.com; sjg@chromium.org;
> >>>> Simek, Michal <michal.simek@amd.com>; Abbarapu, Venkatesh
> >>>> <venkatesh.abbarapu@amd.com>; git@xilinx.com; Ilias Apalodimas
> >>>> <ilias.apalodimas@linaro.org>
> >>>> Subject: Re: [PATCH] efi_loader : Suppress error print message
> >>>>
> >>>> Caution: This message originated from an External Source. Use
> >>>> proper caution when opening attachments, clicking links, or responding.
> >>>>
> >>>>
> >>>> On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote:
> >>>>> [AMD Official Use Only - General]
> >>>>>
> >>>>> Hi Ilias & Heinrich,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>>>> Sent: Tuesday, January 23, 2024 3:30 PM
> >>>>>> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>; Bhumkar,
> >>>>>> Tejas Arvind <tejas.arvind.bhumkar@amd.com>
> >>>>>> Cc: u-boot@lists.denx.de; xypron.glpk@gmx.de; trini@konsulko.com;
> >>>>>> sjg@chromium.org; Simek, Michal <michal.simek@amd.com>; Abbarapu,
> >>>>>> Venkatesh <venkatesh.abbarapu@amd.com>; git@xilinx.com
> >>>>>> Subject: Re: [PATCH] efi_loader : Suppress error print message
> >>>>>>
> >>>>>> Caution: This message originated from an External Source. Use
> >>>>>> proper caution when opening attachments, clicking links, or responding.
> >>>>>>
> >>>>>>
> >>>>>> On 1/23/24 09:33, Ilias Apalodimas wrote:
> >>>>>>> Hi Tejas,
> >>>>>>>
> >>>>>>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
> >>>>>>> <tejas.arvind.bhumkar@amd.com> wrote:
> >>>>>>>>
> >>>>>>>> Currently, on certain Xilinx platforms, an issue has been
> >>>>>>>> identified, manifesting as follows:
> >>>>>>
> >>>>>> Hello Tejas,
> >>>>>>
> >>>>>> thank you for bringing forward this issue.
> >>>>>>
> >>>>>> Which defconfig are you relating to?
> >>>>>
> >>>>> [Tejas]:
> >>>>> Checking with xilinx_zynqmp_virt_defconfig
> >>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>> Starting kernel ...
> >>>>>>>>
> >>>>>>>> efi_free_pool: illegal free 0x0000000077830040
> >>>>>>>> efi_free_pool: illegal free 0x000000007782d040
> >>>>>>>> efi_free_pool: illegal free 0x000000007782c040
> >>>>>>>>
> >>>>>>>> The issue arises when the ramdisk image is relocated, placing
> >>>>>>>> it within the previously allocated EFI memory region( as EFI is
> >>>>>>>> established quite early in U-Boot).
> >>>>>>
> >>>>>> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb:
> >>>>>> consider EFI memory map") was meant to avoid such a situation.
> >>>>>
> >>>>> [Tejas] :
> >>>>> I'm verifying against the latest changes in the master branch. The
> >>>>> introduction of commit 06d514d77c37 ("lmb: consider EFI memory
> >>>>> map") has resolved the occurrence of the "efi_free_pool: illegal free"
> >>>>> error. but, it leads to a new error, as detailed in the following
> >>>>> patch:
> >>>>> https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora.
> >>>>> com/
> >>>>
> >>>> Could you, please, try to reproduce your issues with origin/master
> >>>> as of today and provide the full boot log. Please, also provide the
> >>>> output of the bdinfo and the printenv command as well as the sizes
> >>>> of the
> >> kernel and the RAM disk.
> >>>
> >>> [Tejas]: I've provided two logs: one obtained from the latest u-boot
> >> origin/master, resulting in the "ERROR: reserving fdt memory region
> >> failed" error, and the other from reverting commit 06d514d77c37
> >> ("lmb: consider EFI memory map"), which leads to the "efi_free_pool: illegal
> free" error.
> >>>
> >>> Thank You,
> >>> Tejas.
> >>
> >> Where can I find these logs?
> > [Tejas ] : I've sent the attachment in a previous email. I'm not sure why you
> didn't receive it.
> > I've attached it again now. Please confirm if you still haven't received it.
> >
> > Thank You,
> > Tejas.
> >>
>
> If I understand your FDT_memory_region_failed.log correctly:
>
> Except for some added debug messages this log matches booting with an
> unmodified upstream U-Boot as of Jan 22nd.
>
> Your memory is split into two regions:
>
> 0x0 - 0x7ffffff and
> 0x800000000 - 0x87ffffff.
>
> Your device-tree has a reserved region 0x7ff00000-0x7fffffff.
>
> U-Boot relocates itself into the lower memory block due to current design.
>
> efi_lmb_reserve() marks memory up to 0x7fffffff and 0x800000000-0x87fffffff as
> reserved.
>
> boot_fdt_reserve_region() writes an error when it tries to reserve the overlapping
> region 0x7ff00000-0x7fffffff because LMB recognizes this region is already
> reserved.
>
> This should not interfere with booting as boot_fdt_reserve_region() does not have
> a return value but is not very clean and should be fixed.
[Tejas]:

Thank you for the explanation. Could you please confirm if the maintainer will be looking into this matter?

Thank You,
Tejas
>
> Best regards
>
> Heinrich
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I don't mind suppressing the print for some time, but out of
> >>>>>>> curiosity, how is the ramdisk relocated? LMB should be aware of
> >>>>>>> the EFI regions by then, so I assume the relocation code doesn't
> >>>>>>> check those?
> >>>>>
> >>>>>
> >>>>> [Tejas] :  I observe that the relocation of the RAM disk is taking
> >>>>> place in the line
> >>>> below.
> >>>>> https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491
> >>>>> Yes, the relocated code specifically examines the LMB region and
> >>>>> does not
> >>>> consider the EFI region.
> >>>>>
> >>>>>>
> >>>>>> The indicated situation is serious. If the EFI sub-system is
> >>>>>> using the same memory area as the ramdisk, this may lead to
> >>>>>> corruption of the ramdisk. Suppressing the messages is by no
> >>>>>> means adequate to solve the
> >>>> problem.
> >>>>>
> >>>>> [Tejas] :
> >>>>> The challenge arises when relocating the ramdisk image, inserting
> >>>>> it into the previously assigned EFI memory region, established
> >>>>> early in U-Boot. Consequently, when attempting to release memory
> >>>>> in the EFI region
> >>>> during the handover process to the kernel in the efi_free_pool
> >>>> function, we first verify if the memory was allocated by efi_allocate_pool().
> >>>>> The issue originates from a checksum mismatch because, during the
> >>>>> ramdisk
> >>>> relocation, we overwrite memory allocated by EFI.
> >>>>> This leads to the appearance of the error message: efi_free_pool:
> >>>>> illegal free
> >>>> 0x0000000077830040.
> >>>>> Crucially, there is no corruption of the ramdisk seen since we do
> >>>>> not actually
> >>>> releasing memory due to the checksum mismatch.
> >>>>> In our testing, this issue was observed only when the ramdisk size
> >>>>> exceeded
> >>>> approximately 24 MB.
> >>>>>
> >>>>>>
> >>>>>> Best regards
> >>>>>>
> >>>>>> Heinrich
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> /Ilias
> >>>>>>>
> >>>>>>>> Consequently, when
> >>>>>>>> attempting to release memory in the EFI memory region during
> >>>>>>>> the handover process to the kernel,we encounter memory violations.
> >>>>>>>>
> >>>>>>>> Highlighting that EFI remains active primarily during the
> >>>>>>>> booting of an EFI application, and the lmb persists while
> >>>>>>>> configuring images for the boot process. Since we aren't
> >>>>>>>> utilizing the EFI memory region during the boot process, there
> >>>>>>>> is no adverse impact even in the event of a violation.
> >>>>>>>>
> >>>>>>>> Currently, there is an ongoing discussion regarding the
> >>>>>>>> handling strategies of three memory allocators: malloc, lmb,
> >>>>>>>> and EFI. This discussion is documented in the email chain titled
> "Proposal:
> >>>>>>>> U-Boot memory management."
> >>>>>>>>
> >>>>>>>> Therefore, it is advisable to suppress the print message during
> >>>>>>>> the boot process for now.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
> >>>>>>>> ---
> >>>>>>>>      lib/efi_loader/efi_memory.c | 2 +-
> >>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git a/lib/efi_loader/efi_memory.c
> >>>>>>>> b/lib/efi_loader/efi_memory.c index edfad2d95a..821fe7616e
> >>>>>>>> 100644
> >>>>>>>> --- a/lib/efi_loader/efi_memory.c
> >>>>>>>> +++ b/lib/efi_loader/efi_memory.c
> >>>>>>>> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
> >>>>>>>>             /* Check that this memory was allocated by efi_allocate_pool()
> */
> >>>>>>>>             if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
> >>>>>>>>                 alloc->checksum != checksum(alloc)) {
> >>>>>>>> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
> >>>>>>>> +               debug("%s: illegal free 0x%p\n", __func__,
> >>>>>>>> + buffer);
> >>>>>>>>                     return EFI_INVALID_PARAMETER;
> >>>>>>>>             }
> >>>>>>>>             /* Avoid double free */
> >>>>>>>> --
> >>>>>>>> 2.27.0
> >>>>>>>>
> >>>>>
> >>>
> >

efi_loader : Suppress error print message

Commit Message

Comments

Patch