-----Original Message----- From: Tom Rini trini@konsulko.com Sent: Friday, 10 May, 2019 08:36 PM To: Pankaj Bansal pankaj.bansal@nxp.com Cc: u-boot@lists.denx.de; Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; Varun Sethi V.Sethi@nxp.com Subject: Re: [EXT] Re: [ARMv8] kernel entry point
On Fri, May 10, 2019 at 02:40:52PM +0000, Pankaj Bansal wrote:
Hi Tom,
Further update. I asked this question to linux maintainer, and he pointed out that load address
that I am using is not correct.
The linux load address should be (2 MB aligned + text_offset). The text_offset can be obtained from first 64 bytes in linux Image. For our use case it comes out to be 0x81080000.
One thing that I wonder though is, that I did not receive any warning or error
from uboot about load address.
Can such warning/error be added in uboot ?
I think you need to debug what's going on more, now that you've gotten that far. We should already be moving the Image to 2MB aligned + text_offset with booti.
Actually I was using bootm command to boot a fit image having load address mentioned in fit image. I will check it more, as to why I did not get any error with bootm?
Regards, Pankaj Bansal
Regards, Pankaj Bansal
-----Original Message----- From: Pankaj Bansal Sent: Tuesday, 7 May, 2019 03:48 PM To: 'Tom Rini' trini@konsulko.com Cc: 'u-boot@lists.denx.de' u-boot@lists.denx.de; Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; Varun Sethi V.Sethi@nxp.com Subject: RE: [EXT] Re: [ARMv8] kernel entry point
On further testing I tried to boot the linux from ATF (https://github.com/ARM- software/arm-trusted-firmware) Without using u-boot Even with ATF, the linux is not able to boot from 0x81000000, but is able to boot from 0x80080000 Seems like linux issue and not u-boot issue. I will ask this question in linux community.
Regards, Pankaj Bansal
-----Original Message----- From: Pankaj Bansal Sent: Tuesday, 7 May, 2019 08:30 AM To: 'Tom Rini' trini@konsulko.com Cc: 'u-boot@lists.denx.de' u-boot@lists.denx.de; Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; Varun Sethi V.Sethi@nxp.com Subject: RE: [EXT] Re: [ARMv8] kernel entry point
Hi Tom,
In order to determine whether linux entry point has been called or not, I put a loop in kernel:
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 261f3f88364c..dea6cb8baa6a 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -80,6 +80,7 @@ _head: * its opcode forms the magic "MZ" signature required by UEFI. */ add x13, x18, #0x16
b . b stext#else b stext // branch to kernel start, magic
This loop is being executed when I boot the kernel, but after I jump over this loop there is no log. Does it mean that bootloader is working fine, it's the linux that is not able to boot from 0x81000000 (0x80000000 being the RAM starting
address) ?
Regards, Pankaj Bansal
-----Original Message----- From: Pankaj Bansal Sent: Monday, 6 May, 2019 07:04 PM To: Tom Rini trini@konsulko.com Cc: u-boot@lists.denx.de; Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; Varun Sethi V.Sethi@nxp.com Subject: RE: [EXT] Re: [ARMv8] kernel entry point
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: Monday, 6 May, 2019 06:59 PM To: Pankaj Bansal pankaj.bansal@nxp.com Cc: u-boot@lists.denx.de; Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; Varun Sethi V.Sethi@nxp.com Subject: [EXT] Re: [ARMv8] kernel entry point
On Mon, May 06, 2019 at 01:06:45PM +0000, Pankaj Bansal wrote:
> Hi Tom et. Al, > > I am facing an issue while booting linux on our ARMv8 based platform. > In our platform DDR address starts from 0x80000000. > If I make the linux kernel entry point 0x80080000 in > mkimage, then linux boots fine. > BUT, if I make the linux image entry point as 0x81000000 in > mkimage, the kernel doesn't boot. > > => bootm 0xa0000000 - 0xa1000000 ## Current stack ends at > 0xfbb24400 ## Booting kernel from Legacy Image at a0000000 ... > Image Name: linux > Image Type: AArch64 Linux Kernel Image (gzip compressed) > Data Size: 9110442 Bytes = 8.7 MiB > Load Address: 81000000 > Entry Point: 81000000 > Verifying Checksum ... OK ## Flattened Device Tree blob > at a1000000 > Booting using the fdt blob at 0xa1000000 > Uncompressing Kernel Image ... OK > using: FDT > reserving fdt memory region: addr=80000000 size=10000 > Loading Device Tree to 000000009fff6000, end 000000009ffff2f8 ... > OK ## Transferring control to Linux (at address 81000000)... > > Starting kernel ... > > I get no kernel logs after this. I am failing to understand why. > Can you please help me in debugging this issue?
Why are you using a legacy image on AArch64 at all? You should be using either the kernel Image (and booti) or a FIT image.
This issue is coming even if I use FIT image.
=> bootm 0xa0000000#lx2160ardb ## Current stack ends at 0xfbb24400 ## Loading kernel from FIT Image at a0000000 ... Using 'lx2160ardb' configuration Trying 'kernel' kernel subimage Description: ARM64 Kernel Type: Kernel Image Compression: gzip compressed Data Start: 0xa00000d0 Data Size: 9110442 Bytes = 8.7 MiB Architecture: AArch64 OS: Linux Load Address: 0x81000000 Entry Point: 0x81000000 Hash algo: crc32 Hash value: 39f59891 Verifying Hash Integrity ... crc32+ OK ## Loading ramdisk from FIT Image at a0000000 ... Using 'lx2160ardb' configuration Trying 'initrd' ramdisk subimage Description: initrd for arm64 Type: RAMDisk Image Compression: uncompressed Data Start: 0xa08b055c Data Size: 29171975 Bytes = 27.8 MiB Architecture: AArch64 OS: Linux Load Address: 0x00000000 Entry Point: 0x00000000 Hash algo: crc32 Hash value: 23038325 Verifying Hash Integrity ... crc32+ OK ## Loading fdt from FIT Image at a0000000 ... Using 'lx2160ardb' configuration Trying 'lx2160ardb-dtb' fdt subimage Description: lx2160ardb-dtb Type: Flat Device Tree Compression: uncompressed Data Start: 0xa249071c Data Size: 25337 Bytes = 24.7 KiB Architecture: AArch64 Load Address: 0x90000000 Hash algo: crc32 Hash value: 8e4d595f Verifying Hash Integrity ... crc32+ OK Loading fdt from 0xa249071c to 0x90000000 Booting using the fdt blob at 0x90000000 Uncompressing Kernel Image ... OK using: FDT reserving fdt memory region: addr=80000000 size=10000 Loading Device Tree to 000000009fff6000, end 000000009ffff2f8 ... OK ## Transferring control to Linux (at address 81000000)...
Starting kernel ...
-- Tom
Date: Fri, 10 May 2019 14:36:37 +0000 From: Pankaj Bansal pankaj.bansal@nxp.com To: Mark Rutland mark.rutland@arm.com CC: Catalin Marinas catalin.marinas@arm.com, Will Deacon will.deacon@arm.com, Ard Biesheuvel ard.biesheuvel@linaro.org, Wasim Khan wasim.khan@nxp.com, Varun Sethi V.Sethi@nxp.com, "linux-arm-kernel@lists.infradead.org" linux-arm-kernel@lists.infradead.org Subject: RE: [ARMv8] kernel entry point
Hi Mark,
-----Original Message----- From: Mark Rutland mark.rutland@arm.com Sent: Friday, 10 May, 2019 07:11 PM To: Pankaj Bansal pankaj.bansal@nxp.com Cc: Catalin Marinas catalin.marinas@arm.com; Will Deacon will.deacon@arm.com; Ard Biesheuvel ard.biesheuvel@linaro.org; Wasim Khan wasim.khan@nxp.com; Varun Sethi V.Sethi@nxp.com; linux-arm- kernel@lists.infradead.org Subject: Re: [ARMv8] kernel entry point
Hi Pankaj,
On Fri, May 10, 2019 at 01:24:55PM +0000, Pankaj Bansal wrote:
- Ard,
Hi Ard,
Can you please check below mail? We are not able to boot linux loading Image at 16MB offset (0x81000000) from DDR start address (0x80000000) I have tested with both u-boot as well as atf.
This issue is occurring with latest kernel (5.1) Image. If I revert kernel code to commit a7f8de168ace ("arm64: allow kernel Image to be loaded anywhere in physical memory "), then this issue doesn't
occur.
That commit allows the 2MiB base to be arbitrary, but the text_offset must still be taken into account. That's all documented in:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi t.kernel .org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftre e%
2FDocumentation%2Farm64%2Fbooting.txt%3Fh%3Dv5.1%23n125&data=
02%7C01%7Cpankaj.bansal%40nxp.com%7C045f77d8202040db896108d6d54d1
5f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636930924443311
148&sdata=nOHlA67bfSc21hS0kTnHGJ%2BqxSa2KvAGnRPq7%2FEQgmg%3
D&reserved=0
.. where we say:
| The Image must be placed text_offset bytes from a 2MB aligned base | address anywhere in usable system RAM and called there. The region | between the 2 MB aligned base address and the start of the image | has no special significance to the kernel, and may be used for other
purposes.
| At least image_size bytes from the start of the image must be free | for use by the kernel.
... and where text_offset is defined in the Image header:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi t.kernel .org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftre e%
2FDocumentation%2Farm64%2Fbooting.txt%3Fh%3Dv5.1%23n73&data=0
2%7C01%7Cpankaj.bansal%40nxp.com%7C045f77d8202040db896108d6d54d15
f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369309244433111
48&sdata=Zw2JQ176V6cFXz%2BFcS1uJuYkCZUISjHI%2Bb3HNnkf30k%3D&a
mp;reserved=0
On a contemporary defconfig kernel, text_offset is 0x80000, so 0x81000000 is not a valid address to load the kernel at.
I suspect that things will work if you load your kernel at 0x81080000.
Thank you for this tip. It worked.
I would strongly recommend you use a bootloader that parses the kernel Image header, and respects text_offset automatically.
I am using u-boot. I don't know if uboot takes into account text_offset in
kernel Image header.
I don't think it's there, otherwise uboot would have given an error to respect
the load address requirements.
I will ask uboot maintainer if such checks (load address = 2MB aligned +
text_offset) can be added in uboot.
Thanks again for your help.
Thanks, Mark.
Do you know why the support of "loading kernel Image anywhere in memory" has been removed in latest kernel ?
Regards, Pankaj Bansal
-----Original Message----- From: Pankaj Bansal Sent: Tuesday, 7 May, 2019 04:03 PM To: 'Catalin Marinas' catalin.marinas@arm.com; 'Will Deacon' will.deacon@arm.com Cc: 'linux-arm-kernel@lists.infradead.org' <linux-arm- kernel@lists.infradead.org>; Varun Sethi V.Sethi@nxp.com Subject: [ARMv8] kernel entry point
Hi Catalin/Will et. Al,
I am s/w engineer from NXP India Pvt. Ltd. I am facing an issue while booting linux on our ARMv8 based platform. In our platform DDR address starts from 0x80000000. If I load kernel image @ address 0x80080000 and then try to boot linux image from this address, then linux is booting fine. BUT if I load kernel image @ address 0x81000000 and then try to boot linux image from this address, then linux is not booting. I have tried to boot linux using u-boot as well as arm trusted firmware. Linux is not booting with either of these if the linux load address is
0x81000000.
I get no kernel logs like "[ 0.000000] Booting Linux on physical CPU 0x0"
The linux version that I am using is 4.14.53 Can you please help me in debugging this issue?
Regards, Pankaj Bansal
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fl ists .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-
kernel&data=02%7C0
1%7Cpankaj.bansal%40nxp.com%7C045f77d8202040db896108d6d54d15f2%7C
686ea
1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636930924443311148&sda
ta=Ykm
rBwDOYYLdrOtWFDeBxY2on3xwBP%2F8O1seKm9aiio%3D&reserved=0
-- Tom