Although I have not experimented with it, u-boot on L4T has supported zImage at least since R19.1. However, manual commands for loading a zImage may not have caught up. On a TX1 there may also be complications from needing both 32-bit and 64-bit support…this may have required disabling compression in order to mix 32/64-bit.
It gets more interesting if you look at the /boot/extlinux/extlinux.conf file. Instead of naming zImage, it names Image. A zImage does exist, but this isn’t what the boot loader points at. The file “Image” is a bit larger than zImage, and the “file” command claims Image is just data. I can’t say for certain, but I suspect once again that this is a complication of using both 32-bit and 64-bit compilers when building a kernel (which could also mean compression won’t be possible until switching from a mixed 32/64-bit to pure 64-bit…but this is a guess).
As an interesting experiment to convince yourself that /boot/zImage and /boot/Image are more or less the same file, do this and compare the two command outputs:
cat Image | strings | grep Linux
zcat zImage | strings | grep Linux
Or for proof:
cat Image | sha1sum
zcat zImage | sha1sum
I suspect things will return to “normal” when a pure 64-bit L4T is released (“yet another guess”). For now you might experiment with taking your zImage and creating Image:
Thanks for the clarifications. It indeed seems that zImage is just a gzipped version of Image, since checksums match. Actually, building zImage, Image is always produces as the source for zipping into zImage
make zImage
...
OBJCOPY arch/arm64/boot/Image
GZIP arch/arm64/boot/zImage
Unfortunately, this fact still makes bootz command of u-boot unusable, no matter it could be successfully compiled in the u-boot image.
Since I was trying to find a simple way of booting, the only way to do it for now seems to be the sysboot command that is using /boot/extlinux/extlinux.conf
As I read through various sources found by G, it turns out that bootz is somehow deprecated, and is especially not used in 64 bit ARM versions. But there is booti for this purpose, it turns out.
So, this successfully booted a custom built kernel:
NOTE: There is a little catch, however. Onboard ethernet doesn’t work with u-boot, nether do the USB3 host. Network boot is only possible with USB->Ethernet dongle plugged into the USB OTG interface. My experience with cheap dongles as the “dm9601” based blue translucent ones:
are not supported in u-boot. ASIX AX88772 USB 2.0 Ethernet, however, are OK.
Hello,
According to kernel\Documentation\arm64\booting.txt, it says:
[i]3. Decompress the kernel image
Requirement: OPTIONAL
The AArch64 kernel does not currently provide a decompressor and
therefore requires decompression (gzip etc.) to be performed by the boot
loader if a compressed Image target (e.g. Image.gz) is used. For
bootloaders that do not implement this requirement, the uncompressed
Image target is available instead.[/i]