> -----Original Message----- > From: Tom Rini <[email protected]> > Sent: Friday, 10 May, 2019 08:36 PM > To: Pankaj Bansal <[email protected]> > Cc: [email protected]; Prabhakar Kushwaha > <[email protected]>; Varun Sethi <[email protected]> > 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' <[email protected]> > > > Cc: '[email protected]' <[email protected]>; Prabhakar > > > Kushwaha <[email protected]>; Varun Sethi <[email protected]> > > > 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' <[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 > > > Date: Fri, 10 May 2019 14:36:37 +0000 > > From: Pankaj Bansal <[email protected]> > > To: Mark Rutland <[email protected]> > > CC: Catalin Marinas <[email protected]>, Will Deacon > > <[email protected]>, Ard Biesheuvel <[email protected]>, > > Wasim Khan <[email protected]>, Varun Sethi <[email protected]>, > > "[email protected]" > > <[email protected]> > > Subject: RE: [ARMv8] kernel entry point > > > > Hi Mark, > > > > > -----Original Message----- > > > From: Mark Rutland <[email protected]> > > > Sent: Friday, 10 May, 2019 07:11 PM > > > To: Pankaj Bansal <[email protected]> > > > Cc: Catalin Marinas <[email protected]>; Will Deacon > > > <[email protected]>; Ard Biesheuvel <[email protected]>; > > > Wasim Khan <[email protected]>; Varun Sethi <[email protected]>; > > > linux-arm- [email protected] > > > 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' <[email protected]>; 'Will Deacon' > > > > > <[email protected]> > > > > > Cc: '[email protected]' <linux-arm- > > > > > [email protected]>; Varun Sethi <[email protected]> > > > > > 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 > > > > [email protected] > > > > 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
