* [U-Boot] [ARMv8] kernel entry point @ 2019-05-06 13:06 Pankaj Bansal 2019-05-06 13:28 ` Tom Rini 0 siblings, 1 reply; 9+ messages in thread From: Pankaj Bansal @ 2019-05-06 13:06 UTC (permalink / raw) To: u-boot 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? Regards, Pankaj Bansal ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [ARMv8] kernel entry point 2019-05-06 13:06 [U-Boot] [ARMv8] kernel entry point Pankaj Bansal @ 2019-05-06 13:28 ` Tom Rini 2019-05-06 13:33 ` [U-Boot] [EXT] " Pankaj Bansal 0 siblings, 1 reply; 9+ messages in thread From: Tom Rini @ 2019-05-06 13:28 UTC (permalink / raw) To: u-boot 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190506/dacb985f/attachment.sig> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [EXT] Re: [ARMv8] kernel entry point 2019-05-06 13:28 ` Tom Rini @ 2019-05-06 13:33 ` Pankaj Bansal 2019-05-07 3:00 ` Pankaj Bansal 0 siblings, 1 reply; 9+ messages in thread From: Pankaj Bansal @ 2019-05-06 13:33 UTC (permalink / raw) To: u-boot > -----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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [EXT] Re: [ARMv8] kernel entry point 2019-05-06 13:33 ` [U-Boot] [EXT] " Pankaj Bansal @ 2019-05-07 3:00 ` Pankaj Bansal 2019-05-07 10:18 ` Pankaj Bansal 0 siblings, 1 reply; 9+ messages in thread From: Pankaj Bansal @ 2019-05-07 3:00 UTC (permalink / raw) To: u-boot 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 at 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 at 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [U-Boot] [EXT] Re: [ARMv8] kernel entry point 2019-05-07 3:00 ` Pankaj Bansal @ 2019-05-07 10:18 ` Pankaj Bansal 2019-05-10 14:40 ` Pankaj Bansal 0 siblings, 1 reply; 9+ messages in thread From: Pankaj Bansal @ 2019-05-07 10:18 UTC (permalink / raw) To: u-boot 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 at 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 at 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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [EXT] Re: [ARMv8] kernel entry point 2019-05-07 10:18 ` Pankaj Bansal @ 2019-05-10 14:40 ` Pankaj Bansal 2019-05-10 15:05 ` Tom Rini 0 siblings, 1 reply; 9+ messages in thread From: Pankaj Bansal @ 2019-05-10 14:40 UTC (permalink / raw) To: u-boot 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 ? 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 at 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 at 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 at 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 at 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 -------------- next part -------------- An embedded message was scrubbed... From: Pankaj Bansal <pankaj.bansal@nxp.com> Subject: RE: [ARMv8] kernel entry point Date: Fri, 10 May 2019 14:36:37 +0000 Size: 6778 URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190510/1cd5073c/attachment.mht> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [EXT] Re: [ARMv8] kernel entry point 2019-05-10 14:40 ` Pankaj Bansal @ 2019-05-10 15:05 ` Tom Rini 2019-05-10 15:14 ` Pankaj Bansal 0 siblings, 1 reply; 9+ messages in thread From: Tom Rini @ 2019-05-10 15:05 UTC (permalink / raw) To: u-boot 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. > > 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 at 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 at 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 at 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 at 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 at 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 at 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%2Fgit.kernel > > .org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree% > > 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%2Fgit.kernel > > .org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree% > > 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 at lists.infradead.org' <linux-arm- > > > > kernel at 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 at lists.infradead.org > > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists > > > .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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190510/d1d7c90a/attachment.sig> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [EXT] Re: [ARMv8] kernel entry point 2019-05-10 15:05 ` Tom Rini @ 2019-05-10 15:14 ` Pankaj Bansal 2019-05-10 15:16 ` Tom Rini 0 siblings, 1 reply; 9+ messages in thread From: Pankaj Bansal @ 2019-05-10 15:14 UTC (permalink / raw) To: u-boot > -----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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.infradead.org' <linux-arm- > > > > > kernel at 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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [EXT] Re: [ARMv8] kernel entry point 2019-05-10 15:14 ` Pankaj Bansal @ 2019-05-10 15:16 ` Tom Rini 0 siblings, 0 replies; 9+ messages in thread From: Tom Rini @ 2019-05-10 15:16 UTC (permalink / raw) To: u-boot On Fri, May 10, 2019 at 03:14:40PM +0000, Pankaj Bansal wrote: > > > > -----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 at 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? Perhaps the issue is that a FIT image with an arm64 Image inside needs to be calling out to the booti code to ensure we're respecting the header? > > 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.infradead.org' <linux-arm- > > > > > > kernel at 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 at 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 -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190510/f224466c/attachment.sig> ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-05-10 15:16 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-05-06 13:06 [U-Boot] [ARMv8] kernel entry point Pankaj Bansal 2019-05-06 13:28 ` Tom Rini 2019-05-06 13:33 ` [U-Boot] [EXT] " Pankaj Bansal 2019-05-07 3:00 ` Pankaj Bansal 2019-05-07 10:18 ` Pankaj Bansal 2019-05-10 14:40 ` Pankaj Bansal 2019-05-10 15:05 ` Tom Rini 2019-05-10 15:14 ` Pankaj Bansal 2019-05-10 15:16 ` Tom Rini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox