Trisquel on ODROID

"I haven't yet been able to use Trisquel's Linux kernel or Linux-libre, because this u-boot bootloader seems to require the kernel image in "zImage" format, which I have not found to be commonly distributed"

I could make one for you, if you'd like to experiment and report back.

jxself, Thanks, that's very nice of you!

I have not been able to get it to working, unfortunately. The system hangs at "Starting kernel ..."

Using the USB UART serial console I can try things more easily now. I reduced the u-boot commands to the following, to copy-paste and run at the u-boot prompt:

fatload mmc 0:1 0x40008000 zimage
fatload mmc 0:1 0x42000000 uinitrd
fatload mmc 0:1 0x48000000 exynos5422-odroidxu4.dtb
setenv bootargs "[my /proc/cmdline]"
bootz 0x40008000 0x42000000 0x48000000

Attached is a log of a boot to systemd using Ubuntu's kernel (xu4-boot-ok.txt), and of my attempt to boot with the zImage you provided and the uInitrd generated on my machine (xu4-no-boot.txt).

I'm not sure if I am generating uInitrd correctly; I have not successfully been able to run one other than the one from the Ubuntu image.
I used a command like the following (found via https://linux-sunxi.org/Initial_Ramdisk):

mkimage -A arm -T ramdisk -C none -n uInitrd -d /boot/initrd.img-5.17.3-gnu /boot/uInitrd-gnu

The file command and mkimage command show the uInitrd files appear to be the same format; but I wonder why the one I built is 5 times larger than Ubuntu's:

$ du -sh /boot/uInitrd*
9.9M    /boot/uInitrd
48M     /boot/uInitrd-gnu

$ file /boot/uInitrd*
/boot/uInitrd:                       u-boot legacy uImage, uInitrd, Linux/ARM, RAMDisk Image (Not compressed), 10322645 bytes, Tue Sep 28 21:36:31 2021, Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0x221D4F5A, Data CRC: 0x1A72CC67
/boot/uInitrd-gnu:                   u-boot legacy uImage, uInitrd, Linux/ARM, RAMDisk Image (Not compressed), 49931352 bytes, Sun Apr 17 19:24:36 2022, Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0x66696105, Data CRC: 0x0B9EFBE8

$ mkimage -l /boot/uInitrd
Image Name:   uInitrd
Created:      Tue Sep 28 17:36:31 2021
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:    10322645 Bytes = 10080.71 KiB = 9.84 MiB
Load Address: 00000000
Entry Point:  00000000

$ mkimage -l /boot/uInitrd-gnu
Image Name:   uInitrd
Created:      Sun Apr 17 15:24:36 2022
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:    49931352 Bytes = 48761.09 KiB = 47.62 MiB
Load Address: 00000000
Entry Point:  00000000

With zImage it appears might be something else going on. File sizes are similar:

$ du -sh /boot/z*
6.3M    /boot/zImage
9.8M    /boot/zImage-gnu

But the file command reports different information:

$ file /boot/z*
/boot/zImage:     ARM OpenFirmware FORTH Dictionary, Text length: -509607936 bytes, Data length: -509607936 bytes, Text Relocation Table length: -369098747 bytes, Data Relocation Table length: 24061976 bytes, Entry Point: 0x00000000, BSS length: 6512744 bytes
/boot/zImage-gnu: Linux kernel ARM boot executable zImage (little-endian)

Here's a comparison of the file headers:

$ hexdump -C /boot/zImage|head
00000000  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|
*
00000020  05 00 00 ea 18 28 6f 01  00 00 00 00 68 60 63 00  |.....(o.....h`c.|
00000030  01 02 03 04 45 45 45 45  28 67 00 00 00 90 0f e1  |....EEEE(g......|
00000040  de 0d 00 eb 01 70 a0 e1  02 80 a0 e1 00 20 0f e1  |.....p....... ..|
00000050  03 00 12 e3 01 00 00 1a  17 00 a0 e3 56 34 12 ef  |............V4..|
00000060  00 00 0f e1 1a 00 20 e2  1f 00 10 e3 1f 00 c0 e3  |...... .........|
00000070  d3 00 80 e3 04 00 00 1a  01 0c 80 e3 0c e0 8f e2  |................|
00000080  00 f0 6f e1 0e f3 2e e1  6e 00 60 e1 00 f0 21 e1  |..o.....n.`...!.|
00000090  09 f0 6f e1 00 00 00 00  00 00 00 00 00 00 00 00  |..o.............|

$ hexdump -C /boot/zImage-gnu|head
00000000  4d 5a 25 e2 4d 5a 25 e2  00 00 a0 e1 00 00 a0 e1  |MZ%.MZ%.........|
00000010  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|
00000020  f6 03 00 ea 18 28 6f 01  00 00 00 00 00 b2 9c 00  |.....(o.........|
00000030  01 02 03 04 45 45 45 45  80 d4 00 00 40 00 00 00  |....EEEE....@...|
00000040  50 45 00 00 c2 01 02 00  00 00 00 00 00 00 00 00  |PE..............|
00000050  00 00 00 00 90 00 06 03  0b 01 02 14 00 a0 9c 00  |................|
00000060  00 14 00 00 00 00 00 00  e8 7d 00 00 00 10 00 00  |.........}......|
00000070  00 b0 9c 00 00 00 00 00  00 10 00 00 00 02 00 00  |................|
00000080  00 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 c4 9c 00 00 10 00 00  00 00 00 00 0a 00 00 00  |................|

I also confirmed that the efiboot command is not present in this u-boot build; although it's listed in the help, I suppose it was disabled at compile time. So boot via grub-efi seems to not be possible unless I can upgrade u-boot. ext2 commands are present in this u-boot.

OK, oh well... thanks for looking into it!