From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Wed, 29 Jun 2016 16:25:06 -0700 Subject: [U-Boot] U-boot support for FIT image with 64 bit Linux Kernel In-Reply-To: References: Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 27 June 2016 at 00:07, vinoth eswaran wrote: > On Sun, Jun 26, 2016 at 4:53 AM, Simon Glass wrote: >> >> +Bin >> >> Hi, >> >> On 23 June 2016 at 08:45, vinoth eswaran wrote: >> > Hello, >> > >> > I am working on an embedded project with the u-boot and Minnowboard >> > max. With compressed kernel (bzImage) everything works fine, I want to >> > check the performance with >> > uncompressed kernel (vmlinux). >> > >> > So for creating the image.fit file I followed the instructions as per >> > the file x86-fit-boot.txt except that I have changed the compression >> > to none in the image.its file since I want to check the uncompressed >> > Kernel >> > >> > data = /incbin/("./vmlinux.bin"); >> > type = "kernel"; >> > arch = "x86"; >> > os = "linux"; >> > compression = "none"; >> >> Do you have a load address? >> >> > >> > The bootcmd is "bootcmd=fatload mmc 1:1 0x02000000 image.fit ; bootm >> > 0x02000000". Now I am seeing that the >> > start up hangs after printing the commands starting kernel ... and the >> > time summary. Do you have any idea why it is happening? >> > >> > reading imagefit >> > 14566018 bytes read in 317 ms (43.8 MiB/s) >> > ## Loading kernel from FIT Image at 02000000 ... >> > Using 'config at 1' configuration >> > Verifying Hash Integrity ... OK >> > Trying 'kernel at 1' kernel subimage >> > Description: Vanilla Linux kernel >> > Created: 2016-06-23 14:22:21 UTC >> > Type: Kernel Image >> > Compression: uncompressed >> > Data Start: 0x020000e8 >> > Data Size: 14548992 Bytes = 13.9 MiB >> > Architecture: Intel x86 >> > OS: Linux >> > Load Address: 0x01000000 >> > Entry Point: 0x00000000 >> > Hash algo: sha1 >> > Hash value: 5a0bddcbf1f54ac989fff662fc43fb5fc801ebbc >> > Verifying Hash Integrity ... sha1+ OK >> > ## Loading setup from FIT Image at 02000000 ... >> > Using 'config at 1' configuration >> > Trying 'setup at 1' setup subimage >> > Description: Linux setup.bin >> > Created: 2016-06-23 14:22:21 UTC >> > Type: x86 setup.bin >> > Compression: uncompressed >> > Data Start: 0x02de01d0 >> > Data Size: 15708 Bytes = 15.3 KiB >> > Hash algo: sha1 >> > Hash value: 08ffa163d054b9b0f5b11d4b3db2a16247cee395 >> > Verifying Hash Integrity ... sha1+ OK >> > Loading setup from 0x02de01d0 to 0x00090000 >> > Loading Kernel Image ... OK >> > Setup at 0x090000 >> > Magic signature found >> > Kernel command line: "quiet" >> > >> > Starting kernel ... >> > >> > >> > I have seen in the document that it doesn't support for 64 bit kernel >> > and the document link given is now not accessible. >> > http://wiki.osdev.org/64-bit_Higher_Half_Kernel_with_GRUB_2 >> >> Actually this comment is incorrect: >> >> "Note: these instructions assume a 32-bit kernel. U-Boot does not currently >> support booting a 64-bit kernel as it has no way of going into 64-bit mode on >> x86." >> >> U-Boot supports this. But you need to use x86_64 as the image type >> instead of x86. >> >> Are you booting with a 32- or 64-bit kernel? >> >> Perhaps try without the 'qiuet'? >> > > Thanks for reply, your information helped me. But I would like to > request to sort this message when using x86_64 as architecture type in > the mkimage. The following debug message when creating the FIT image > guided me in the wrong path for the past few days, as I thought x86_64 > is not supported and I need to use x86. With arch=x86_64 while > creating FIT/uImage, > > Invalid CPU Type - valid names are: alpha, arm, x86, ia64, m68k, > microblaze, mips, mips64, nios2, powerpc, ppc, s390, sh, sparc, > sparc64, blackfin, avr32 > Architecture: Unknown Architecture > > Also the image type used for setup.bin. With image type= x86_setup > > Invalid Image Type - valid names are: filesystem, firmware, > flat_dt, imximage, kernel, kwbimage, multi, omapimage, ramdisk, > script, standalone, flat_dt, kwbimage, imximage, ublimage > > Many Thanks:) > > Now with x86_64 as arch type I could run the system again. I should > have ignored the message and tested initially, but also confusions > with Load and entry addresses let me to stay blank. I've found various infidelities with mkimage errors - I'll send a series to improve things. Regards, Simon