[U-Boot] [EXT] Re: [ARMv8] kernel entry point

[Pankaj Bansal]

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 at konsulko.com>
> Cc: 'u-boot at lists.denx.de' <u-boot at lists.denx.de>; Prabhakar Kushwaha
> <prabhakar.kushwaha at nxp.com>; Varun Sethi <V.Sethi at 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 at konsulko.com>
> > Cc: u-boot at lists.denx.de; Prabhakar Kushwaha
> > <prabhakar.kushwaha at nxp.com>; Varun Sethi <V.Sethi at nxp.com>
> > Subject: RE: [EXT] Re: [ARMv8] kernel entry point
> >
> >
> >
> > > -----Original Message-----
> > > From: Tom Rini <trini at konsulko.com>
> > > Sent: Monday, 6 May, 2019 06:59 PM
> > > To: Pankaj Bansal <pankaj.bansal at nxp.com>
> > > Cc: u-boot at lists.denx.de; Prabhakar Kushwaha
> > > <prabhakar.kushwaha at nxp.com>; Varun Sethi <V.Sethi at 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