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' <[email protected]> > Cc: '[email protected]' <[email protected]>; Prabhakar Kushwaha > <[email protected]>; Varun Sethi <[email protected]> > 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 <[email protected]> > > Cc: [email protected]; Prabhakar Kushwaha > > <[email protected]>; Varun Sethi <[email protected]> > > Subject: RE: [EXT] Re: [ARMv8] kernel entry point > > > > > > > > > -----Original Message----- > > > From: Tom Rini <[email protected]> > > > Sent: Monday, 6 May, 2019 06:59 PM > > > To: Pankaj Bansal <[email protected]> > > > Cc: [email protected]; Prabhakar Kushwaha > > > <[email protected]>; Varun Sethi <[email protected]> > > > 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
