Overview
This was specifically observed on the TS-4900 U-Boot LTS port, in v2026.01, where loading a file larger than 4 MB seems to fail.
Currently not going to impede the release of this U-Boot in favor of this issue, so documenting it for now to be addressed later.
Two disks were tested, both SATA III, a ~100 GB SSD and a ~500 GB HDD; tested against our latest Debian 13 / 6.18 kernel image. The image loads and boots fine from microSD as well as eMMC, however U-Boot reports issues with the kernel when booting from SATA. This was tested using both MBR and GPT partition tables, as well as ext3 and ext4 filesystems on the disk; the error occurred in all conditions, albeit presenting itself slightly differently depending.
GPT / ext4 behavior
When loading this kernel from GPT/ext4 formatted disk, the load address does not match expected starting bytes, it should look like:
=> md.l ${loadaddr} 10
12000000: 56190527 791d0b8a 0e92a869 00926000 '..V...yi....`..
12000010: 00800010 00800010 247abfe4 00020205 ..........z$....
12000020: 756e694c 2e362d78 31312e36 00000039 Linux-6.6.119...
12000030: 00000000 00000000 00000000 00000000 ................
But instead presents as:
=> md.l ${loadaddr} 10
12000000: 8d3111d2 4b801101 0da0015d bf221509 ..1....K].....".
12000010: d326bc36 85541313 d01d832f 281e7c65 6.&...T./...e|.(
12000020: 7c0d816d 0ad01210 1abe0f5f 81dc23d3 m..|...._....#..
12000030: 833f8501 1aee4e02 efcc2514 7d21c016 ..?..N...%....!}
In looking at the uImage file in a hex editor, it was observed that the byte sequence is present starting at the 4 MB boundary:
003FFFE8 6B 01 EA 38 30 8B 15 13 E2 86 E8 28 27 2E 00 84 E8 7D 26 24 8C 0A 12 B0 D2 11 31 8D 01 11 80 4B 5D 01 A0 0D 09 15 22 BF k..80......('....}&$......1....K].....".
(note that there is byte-swapping between the two, but, D2 11 31 8D immediately above matches the md.l output 8d2111d2 above and continues this)
This strongly indicates that there is some issue right at the 4 MB boundary.
It was also observed that loading any arbitrary file, smaller than 4 MB, such as .dtb files, the FPGA .bin file, etc., all read in valid and the hash was able to be validated in U-Boot (using hash md5 ${loadaddr} ${filesize} and comparing with the known hash, or by reading via microSD etc.)
MBR / ext3
It was observed that MBR partition scheme with an ext3 partition had slightly different behavior. When reading the same file in, only the first 512 KB were valid. For example, when clearing the load address range in memory, reading the file into that memory address, and then viewing the contents, the memory range was still all 0x00 after the first 512 KB.
I am not sure how the change in partition type and filesystem type have impacted this the way it has.
Overview
This was specifically observed on the TS-4900 U-Boot LTS port, in v2026.01, where loading a file larger than 4 MB seems to fail.
Currently not going to impede the release of this U-Boot in favor of this issue, so documenting it for now to be addressed later.
Two disks were tested, both SATA III, a ~100 GB SSD and a ~500 GB HDD; tested against our latest Debian 13 / 6.18 kernel image. The image loads and boots fine from microSD as well as eMMC, however U-Boot reports issues with the kernel when booting from SATA. This was tested using both MBR and GPT partition tables, as well as ext3 and ext4 filesystems on the disk; the error occurred in all conditions, albeit presenting itself slightly differently depending.
GPT / ext4 behavior
When loading this kernel from GPT/ext4 formatted disk, the load address does not match expected starting bytes, it should look like:
But instead presents as:
In looking at the uImage file in a hex editor, it was observed that the byte sequence is present starting at the 4 MB boundary:
(note that there is byte-swapping between the two, but,
D2 11 31 8Dimmediately above matches themd.loutput8d2111d2above and continues this)This strongly indicates that there is some issue right at the 4 MB boundary.
It was also observed that loading any arbitrary file, smaller than 4 MB, such as
.dtbfiles, the FPGA.binfile, etc., all read in valid and the hash was able to be validated in U-Boot (usinghash md5 ${loadaddr} ${filesize}and comparing with the known hash, or by reading via microSD etc.)MBR / ext3
It was observed that MBR partition scheme with an ext3 partition had slightly different behavior. When reading the same file in, only the first 512 KB were valid. For example, when clearing the load address range in memory, reading the file into that memory address, and then viewing the contents, the memory range was still all
0x00after the first 512 KB.I am not sure how the change in partition type and filesystem type have impacted this the way it has.