Phil M0OFXKernel 4.10 with Linaro gcc 4.8 went pop, the kernel complains that the compiler is buggy. And the Binutils bits don't build. So that's good.
Now trying Kernel 6.18.2 plus GCC 9, which is the oldest ARMHF EABI GCC cross compiler which Ubuntu still ship.
A pile of failures and finally a success!
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.19.7 (philpem@panther) (gcc version 4.9.4 (Linaro GCC 4.9-2017.01) ) #1 Sun Dec 28 23:33:40 GMT 2025
It spins on "sending BOOTP requests" but that's because I'm missing the TS7xxx Watchdog driver. But this is success!
Hmm. The 4.14.336 kernel doesn't run on the TS board when it's built with the EP93xx defconfig and the Linaro GCC 4.9 compiler.
But what if I take the .config from 3.19.7 and use that? "make oldconfig" to the rescue, maybe?
But what if I take the .config from 3.19.7 and use that? "make oldconfig" to the rescue, maybe?
Getting there!
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.14.336 (philpem@panther) (gcc version 4.9.4 (Linaro GCC 4.9-2017.01)) #4 Sun Dec 28 23:59:37 GMT 2025
5.10.247 doesn't like the Linaro 4.9.4 or 5.5.0 compilers (or rather their assemblers), and Linaro 6.4.1 doesn't produce a working 5.10.247 kernel. So that's "good", I guess?
It's not the compiler, Linaro 6.4.1 can make a working 4.14.336 kernel:
Linux version 4.14.336 (philpem@panther) (gcc version 6.4.1 20171012 (Linaro GCC 6.4-2017.11)) #8 Mon Dec 29 01:23:48 GMT 2025
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c000717f
Machine: Technologic Systems TS-72xx SBC
(I had to fix a bug in Technologic's boot sector - it sets the machine ID wrong)
Interestingly 4.20.9 doesn't work. Okay. That means something changed between 4.14 and 4.20. Time to bisect!
4.17.19 works...
Linux version 4.17.19 (philpem@panther) (gcc version 6.4.1 20171012 (Linaro GCC 6.4-2017.11)) #1 Mon Dec 29 01:47:33 GMT 2025
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c000717f
CPU: VIVT data cache, VIVT instruction cache
Machine: Technologic Systems TS-72xx SBC
Ho hum. 4.19.325 is broken too.
I'm leaving the kernel Git repo cloning so I'm not constantly pulling tarballs, then I'll bisect. I'd like to know which rev (ideally which commit) broke this.
But I'd also like a Das U-boot port.
I'm leaving the kernel Git repo cloning so I'm not constantly pulling tarballs, then I'll bisect. I'd like to know which rev (ideally which commit) broke this.
But I'd also like a Das U-boot port.
4.19.150 also broken... and 4.18.1! Seems like EP29xx broke somewhere between kernel 4.17.19 and 4.18.1.
Time for a git bisect!
Time for a git bisect!
13 tests estimated, and thousands of commits. Woo?
Bisecting: 1716 revisions left to test after this (roughly 11 steps)
[4205c88eaf17b5f3ee30032d68df55cd5d9077a1] net: stmmac: Set DMA buffer size in HW
[4205c88eaf17b5f3ee30032d68df55cd5d9077a1] net: stmmac: Set DMA buffer size in HW
Getting closer.
philpem@panther:~/TS7300/os/linux-git$ git bisect good
Bisecting: 209 revisions left to test after this (roughly 8 steps)
[f5b7769eb0400ec5217a47e41148a9f816ca1f9f] Revert "debugfs: inode: debugfs_create_dir uses mode permission from parent"
I feel like I'm probably going to find that the breaking commit is a huge merge.
Dear person who broke Linux on EP93xx about ten years ago, I'm about 90 minutes away from finding your commit. Maybe it's not too late to confess and free your soul from the burden of sin? :p /jk
Bisecting: 20 revisions left to test after this (roughly 4 steps)
[11c92f144bf39f448f65202cccba672097a1100b] apparmor: fix mediation of prlimit
[11c92f144bf39f448f65202cccba672097a1100b] apparmor: fix mediation of prlimit
Commit is sus.
linux-git$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[050e9baa9dc9fbd9ce2b27f0056990fc9e0a08a0] Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables
$ git bisect good
050e9baa9dc9fbd9ce2b27f0056990fc9e0a08a0 is the first bad commit
commit 050e9baa9dc9fbd9ce2b27f0056990fc9e0a08a0
Author: Linus Torvalds <[email protected]>
Date: Thu Jun 14 12:21:18 2018 +0900
Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables
Hmm. So either Linux screwed something up in this commit, or there's a change in config which hasn't been accounted for.
$ grep STACKPRO ../linux-4.14.336-ts7300.config
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
And for 4.18.1...
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
So the strong stack protector is wot's broke, and needs turning off.
And the offending article is CONFIG_STACKPROTECTOR_STRONG -- turn this off and 4.18.1 boots:
Linux version 4.18.1 (philpem@panther) (gcc version 6.4.1 20171012 (Linaro GCC 6.4-2017.11)) #2 Mon Dec 29 14:50:02 GMT 2025
And 4.19 breaks too. Yay?
Went back to 4.18.1. I have an NFS root FS! According to mailing list posts there's a 5.x kernel which works on these boards, but this is a good start.
I happened to notice this gem in /proc/iomem.
00000000-007fffff : System RAM
00008000-00436fff : Kernel code
0045a000-004a1af3 : Kernel data
01000000-017fffff : System RAM
04000000-047fffff : System RAM
05000000-057fffff : System RAM
The RAM is 32 MiB, split into four non-contiguous 8MiB banks.
The compressed kernel gets loaded at 0x218000, roughly 2MB into the first. Initrd ends up at 0x01000000 - in the 2nd bank.
The kernel decompressor relocates if it needs to (in theory).
But what happens if uncompressed kernel + compressed kernel > 8MB?
From the description of the decompression process in the kernel documentation (about how it gets the decompression base address by ANDing the PC with 0xF800_0000 and adding 0x8000) I don't think it's smart enough to parse the ATAGS to find out about memory gaps.
What if I load the kernel at 0x0400_0000?
Linux version 4.19.325 (philpem@panther) (gcc version 6.5.0 (Linaro GCC 6.5-2018.12)) #2 Tue Dec 30 23:22:17 GMT 2025
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c000717f
CPU: VIVT data cache, VIVT instruction cache
Machine: Technologic Systems TS-72xx SBC
Nice.
Oh dear, 6.18.2 is too big to load into a single SDRAM bank. Time to put it on a diet. (and enable decompression debug)
Almost...
Error: invalid dtb and unrecognized/unsupported machine ID
r1=0x000002a1, r2=0x00000100
r2[]=05 00 00 00 01 00 41 54 00 00 00 00 00 00 00 00
Available machine support:
ID (hex) NAME
ffffffff Generic DT based system
Please check your kernel config and/or bootloader.
Aha! "make cirrus/ep93xx_ts7250.dtb" builds the DTB, and with the right options it can be cat'ed onto the end of the zImage.
DTB:0x04367EF8 (0x000021EE)
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 6.18.2 (philpem@panther) (arm-linux-gnueabi-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #2 Wed Dec 31 03:13:33 GMT 2025
Shame the Ethernet interface isn't working - that's probably PHY related.
Tvorsk
@philpem ... so I was catching up on the thread and uh, that's one "heck yes! / brick wall around next corner" moment. Sorry :(
@Tvorsk not so much of a brick wall, 4.18.1 still works. Rumour has it there's a working 5.x kernel too.
@philpem
I meant it like... after all this binary search to find the stack protector config change in 4.18.1, and having that change fix it on this version, there was some hope/expectation that at least some following versions will work as well but 4.19 was another immediate disappointing stop.
Glad to hear that one might be modern enough for your plans, though. :)
I meant it like... after all this binary search to find the stack protector config change in 4.18.1, and having that change fix it on this version, there was some hope/expectation that at least some following versions will work as well but 4.19 was another immediate disappointing stop.
Glad to hear that one might be modern enough for your plans, though. :)
JennyFluff 
💾@philpem CONFIG_HAS_SNACCPROTECTOR
@JennyFluff om nom nom
penguin42