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?
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. :)