I get the following error while loading the LEG-UEFI kernel [1] on a BeagleBone Black (omap2plus_defconfig + efi stub support) when the kernel requests memory from UEFI.:
Shell> zImage EFI stub: Booting Linux Kernel... ConvertPages: failed to find range 80800000 - 81FFFFFF EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. EFI stub: ERROR: Failed to relocate kernel Error: Image at 0009A3F8000 start failed: Load Error Unloading driver at 0x0009A3F8000 Error reported: Load Error
`memmap` shows the map to have a gap from 80800000 - 81FFFFFF (PcdFdBaseAddress for BBB UEFI is 0x80800000, so that's where I have UEFI loaded).
Does this mean I should adjust the BBB memory map so that all external allocations are done *after* the UEFI region (possibly by reserving the lower addresses)? Is there an alternate way of getting the kernel up?
Shell> memmap Type Start End #pages Attributes LoaderData 0000000080000000-00000000807FFFFF 0000000000000800 000000000000000F Available 0000000080A00000-000000009A6BBFFF 0000000000019CBC 000000000000000F LoaderCode 000000009A6BC000-000000009A779FFF 00000000000000BE 000000000000000F Reserved 000000009A77A000-000000009A77DFFF 0000000000000004 000000000000000F RT_Code 000000009A77E000-000000009A78AFFF 000000000000000D 800000000000000F Available 000000009A78B000-000000009EE54FFF 00000000000046CA 000000000000000F BS_Data 000000009EE55000-000000009EE79FFF 0000000000000025 000000000000000F Available 000000009EE7A000-000000009EE9EFFF 0000000000000025 000000000000000F BS_Data 000000009EE9F000-000000009EEABFFF 000000000000000D 000000000000000F Available 000000009EEAC000-000000009EEB2FFF 0000000000000007 000000000000000F BS_Data 000000009EEB3000-000000009F400FFF 000000000000054E 000000000000000F Available 000000009F401000-000000009F401FFF 0000000000000001 000000000000000F BS_Data 000000009F402000-000000009F5BEFFF 00000000000001BD 000000000000000F Available 000000009F5BF000-000000009F646FFF 0000000000000088 000000000000000F BS_Code 000000009F647000-000000009F74EFFF 0000000000000108 000000000000000F RT_Code 000000009F74F000-000000009F762FFF 0000000000000014 800000000000000F RT_Data 000000009F763000-000000009F794FFF 0000000000000032 800000000000000F BS_Data 000000009F795000-000000009F795FFF 0000000000000001 000000000000000F RT_Data 000000009F796000-000000009F796FFF 0000000000000001 800000000000000F BS_Data 000000009F797000-000000009F7ACFFF 0000000000000016 000000000000000F RT_Data 000000009F7AD000-000000009F7ADFFF 0000000000000001 800000000000000F BS_Data 000000009F7AE000-000000009FFFFFFF 0000000000000852 000000000000000F Reserved : 4 Pages (16,384) LoaderCode: 190 Pages (778,240) LoaderData: 2,048 Pages (8,388,608) BS_Code : 264 Pages (1,081,344) BS_Data : 4,006 Pages (16,408,576) RT_Code : 33 Pages (135,168) RT_Data : 52 Pages (212,992) ACPI Recl : 0 Pages (0) ACPI NVS : 0 Pages (0) MMIO : 0 Pages (0) Available : 123,963 Pages (507,752,448) Total Memory: 510 MB (534,773,760 Bytes)
[1] https://git.linaro.org/people/leif.lindholm/linux.git/shortlog/refs/heads/to...
Thanks, Varad
Memmap shows the available memory 0000000080A00000-000000009A6BBFFF that should be enough to load linux.
Why EFI Linux Loader allocate memory resource from start address 80800000? Could it allocate the memory resource from the available memory region?
-----Original Message----- From: varadgautam@gmail.com [mailto:varadgautam@gmail.com] Sent: Sunday, January 04, 2015 8:41 PM To: 'edk2-devel@lists.sourceforge.net'; linaro-dev@lists.linaro.org; linaro-uefi Subject: [edk2] kernel memory allocation issue with uefi
I get the following error while loading the LEG-UEFI kernel [1] on a BeagleBone Black (omap2plus_defconfig + efi stub support) when the kernel requests memory from UEFI.:
Shell> zImage EFI stub: Booting Linux Kernel... ConvertPages: failed to find range 80800000 - 81FFFFFF EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. EFI stub: ERROR: Failed to relocate kernel Error: Image at 0009A3F8000 start failed: Load Error Unloading driver at 0x0009A3F8000 Error reported: Load Error
`memmap` shows the map to have a gap from 80800000 - 81FFFFFF (PcdFdBaseAddress for BBB UEFI is 0x80800000, so that's where I have UEFI loaded).
Does this mean I should adjust the BBB memory map so that all external allocations are done *after* the UEFI region (possibly by reserving the lower addresses)? Is there an alternate way of getting the kernel up?
Shell> memmap Type Start End #pages Attributes LoaderData 0000000080000000-00000000807FFFFF 0000000000000800 000000000000000F Available 0000000080A00000-000000009A6BBFFF 0000000000019CBC 000000000000000F LoaderCode 000000009A6BC000-000000009A779FFF 00000000000000BE 000000000000000F Reserved 000000009A77A000-000000009A77DFFF 0000000000000004 000000000000000F RT_Code 000000009A77E000-000000009A78AFFF 000000000000000D 800000000000000F Available 000000009A78B000-000000009EE54FFF 00000000000046CA 000000000000000F BS_Data 000000009EE55000-000000009EE79FFF 0000000000000025 000000000000000F Available 000000009EE7A000-000000009EE9EFFF 0000000000000025 000000000000000F BS_Data 000000009EE9F000-000000009EEABFFF 000000000000000D 000000000000000F Available 000000009EEAC000-000000009EEB2FFF 0000000000000007 000000000000000F BS_Data 000000009EEB3000-000000009F400FFF 000000000000054E 000000000000000F Available 000000009F401000-000000009F401FFF 0000000000000001 000000000000000F BS_Data 000000009F402000-000000009F5BEFFF 00000000000001BD 000000000000000F Available 000000009F5BF000-000000009F646FFF 0000000000000088 000000000000000F BS_Code 000000009F647000-000000009F74EFFF 0000000000000108 000000000000000F RT_Code 000000009F74F000-000000009F762FFF 0000000000000014 800000000000000F RT_Data 000000009F763000-000000009F794FFF 0000000000000032 800000000000000F BS_Data 000000009F795000-000000009F795FFF 0000000000000001 000000000000000F RT_Data 000000009F796000-000000009F796FFF 0000000000000001 800000000000000F BS_Data 000000009F797000-000000009F7ACFFF 0000000000000016 000000000000000F RT_Data 000000009F7AD000-000000009F7ADFFF 0000000000000001 800000000000000F BS_Data 000000009F7AE000-000000009FFFFFFF 0000000000000852 000000000000000F Reserved : 4 Pages (16,384) LoaderCode: 190 Pages (778,240) LoaderData: 2,048 Pages (8,388,608) BS_Code : 264 Pages (1,081,344) BS_Data : 4,006 Pages (16,408,576) RT_Code : 33 Pages (135,168) RT_Data : 52 Pages (212,992) ACPI Recl : 0 Pages (0) ACPI NVS : 0 Pages (0) MMIO : 0 Pages (0) Available : 123,963 Pages (507,752,448) Total Memory: 510 MB (534,773,760 Bytes)
[1] https://git.linaro.org/people/leif.lindholm/linux.git/shortlog/refs/heads/to...
Thanks, Varad
------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
On Sun, Jan 04, 2015 at 06:11:02PM +0530, varadgautam@gmail.com wrote:
I get the following error while loading the LEG-UEFI kernel [1] on a BeagleBone Black (omap2plus_defconfig + efi stub support) when the kernel requests memory from UEFI.:
Shell> zImage EFI stub: Booting Linux Kernel... ConvertPages: failed to find range 80800000 - 81FFFFFF EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. EFI stub: ERROR: Failed to relocate kernel Error: Image at 0009A3F8000 start failed: Load Error Unloading driver at 0x0009A3F8000 Error reported: Load Error
`memmap` shows the map to have a gap from 80800000 - 81FFFFFF (PcdFdBaseAddress for BBB UEFI is 0x80800000, so that's where I have UEFI loaded).
Does this mean I should adjust the BBB memory map so that all external allocations are done *after* the UEFI region (possibly by reserving the lower addresses)?
No, the stub loader should work anyway.
Is there an alternate way of getting the kernel up?
Fix the kernel :)
[1] https://git.linaro.org/people/leif.lindholm/linux.git/shortlog/refs/heads/to...
So, I rebased that branch to 3.18 in order to include all of the core changes required for this to work. But I didn't have a platform handy to test that it resolved this issue. Modifications are required in handle_kernel_image() in arm/boot/comressed/efi-stub.c.
If you don't want to wait for me to get around to sorting it, you could compare it to the arm64/kernel/efi-stub.c version and modify it yourself.
/ Leif
-
Gao, Liming -
Leif Lindholm -
varadgautam＠gmail.com