szemzoa_ has quit [Remote host closed the connection]
tuxd3v_ has joined #linux-sunxi
tuxd3v has quit [Ping timeout: 480 seconds]
tuxd3v has joined #linux-sunxi
indy_ has joined #linux-sunxi
tuxd3v_ has quit [Ping timeout: 480 seconds]
indy has quit [Ping timeout: 480 seconds]
indy_ is now known as indy
junari_ has quit [Read error: Connection reset by peer]
chuangzhu has joined #linux-sunxi
szemzoa has joined #linux-sunxi
szemzoa has quit [Ping timeout: 480 seconds]
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #linux-sunxi
<LordKalma>
For the sake of desperation, I'll post it here too: Still about that device me and a couple people were hacking/reverse engineering. The radio has an Allwinner R16 SoC. We were doing just great, but we started getting verifiable reports of random people not being able to boot our images on certain devices. The stock uboot is a 2017 version of all
<LordKalma>
things, and the vendor's bootloader works copy/pasted (with dd) on any device with our images. Apparently in the "broken" models, the uboot spits only two lines and breaks:
<LordKalma>
And nothing else. And that is with SPL debug logging enabled... In the meanwhile a colleague said "I empirically found that the bootloader 2018.01 works on new devices. But only if you build it with GCC-7.3. If you assemble a newer GCC-12, then it works on older devices, but not on new ones!".
<LordKalma>
DRAM: 1024 MiB
<LordKalma>
Any ideas of what the hell could be going on?
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
junari has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<apritzel>
LordKalma: where do you load the rest U-Boot from? SD card?
<LordKalma>
yes
<LordKalma>
my colleague dd'ed the stock bootloader that's working on every device to his images and they boot on every device
<LordKalma>
and apparently with 2018.01 depends on the compiler (?!)
<apritzel>
why 2018.01? that's five years old?
<LordKalma>
and the stock uboot is from 2017 apparently. From what I gather he was just trying to see if he could bisect uboot to find the origin of the problem
<apritzel>
we have had reports of SD card loading being somewhat unreliable on some H3 devices. There was a hack to work around that (some delay after reset), but that looked fishy
<LordKalma>
maybe the silicon crisis made the manufacturer put some shady SoCs in there? hahaha
<apritzel>
the point is no one really wants to dig around in old code, to rediscover bugs that have been long fixed.
<LordKalma>
still, the manufacturer is booting fine and we aren't :/
<apritzel>
so can you reproduce it with mainline?
<apritzel>
manufacturers do things that you wouldn't believe to make their devices work, that is sometimes borderline nonsense
<LordKalma>
we got the uboot source through some contacts, and other than they having slapped the lcd init in there, it seems to me basically mainline 2017 uboot
<apritzel>
I still don't get what's the significance of 2018.01 then? You either use the manufacturer's version, or mainline
<LordKalma>
I don't think he build 2017 mainline though
<apritzel>
there shouldn't be anything in between, really
<apritzel>
you are moving in the wrong direction ;-)
<LordKalma>
What do you suggest?
<apritzel>
get it working on mainline
<apritzel>
then we can debug it there
<apritzel>
and fix it properly
<apritzel>
that's also the only way forward anyway
<LordKalma>
We were happily using mainline uboot, whatever most recent version buildroot wanted to give us (yes yes, buildroot, I know...)
<LordKalma>
it just worked out of the box
<LordKalma>
but now it doesn't on *some* devices
<apritzel>
ah, so you *can* reproduce it on mainline?
<apritzel>
because you were talking about 2018.01 above ...
<LordKalma>
ah yes, that was during some debugging effort, let me repeat the story, but clearly:
<LordKalma>
1) Everything was working fine with latest buildroot stable, with whatever u-boot it gave us, from sdcard. 2) Reports started appearing claiming the custom image from my colleague didn't boot, on *some* (apparently newer(?)) devices.
<LordKalma>
On the ones that the device don't boot, this is the **only** log before soft locking:
<apritzel>
that is where it's normally loading U-Boot proper
<LordKalma>
dd'ing the stock bootloader (which we know to be a 2017 version) over our custom images makes them work on both new and old devices
<LordKalma>
and the 2018.01 thing is that my colleague verified it works if built with gcc 7, but doesn't if built with gcc 12 (?!?!)
<LordKalma>
just a desperate attempt in between pulling hairs haha
<apritzel>
so you don't see the "Trying to boot from MMC1" line?
<LordKalma>
nope, just those two
<apritzel>
then, and with that compiler oddity, it's probably another problem we were seeing on H616 boards
<apritzel>
we reckon it's DRAM init related, but the research isn't very conclusive
<LordKalma>
it's my guess and #u-boot's guess as well
<apritzel>
a few people including me starred at the DRAM init disassembly between GCC 10 and GCC 11, but couldn't spot the problem
<apritzel>
so can you reproduce the problem with mainline and GCC >=11?
<LordKalma>
mainline and gcc 12 are problematic, yes
<LordKalma>
I could ask for the uboot binaries for the 2018 gcc 7 vs 12 and we could look at the assembly from those (?)
<LordKalma>
that should provide the minimum differences
<apritzel>
please, I don't want to look at old code ;-)
<apritzel>
can't you build mainline with GCC 10 and 11 (or 12)?
<apritzel>
my hunch is that the DRAM init code (on the H616) misses some delays, somewhere, and newer compilers change the generated code in a way that it now matters
<LordKalma>
I can ask, sure. It's my colleague doing all the work, as I've been busy with other things
grming has joined #linux-sunxi
<LordKalma>
I'll inquiry if gcc 10 vs 12 makes a difference and if it does, we'll look at the assembly together then :)
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
jkm has quit [Quit: Reconnecting]
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
jkm has joined #linux-sunxi
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
<jkm>
hi szemzoa
<jkm>
what is the status of your awboot bootloader for T113-S3?
cnxsoft has quit []
<szemzoa>
jkm: it should work, the last time I tested it was ok
<jkm>
szemzoa: I remember that I had some issues with SDHC card initialization with awboot on MangoPi MQ-R...
<jkm>
I will need to test it again
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has quit []
cnxsoft has quit []
Danct12 has quit [resistance.oftc.net coherence.oftc.net]
pabs has quit [resistance.oftc.net coherence.oftc.net]
Namidairo has quit [resistance.oftc.net coherence.oftc.net]
Danct12 has joined #linux-sunxi
pabs has joined #linux-sunxi
Namidairo has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
junari__ has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
szemzoa, jkm: can I recruit you guys to do some testing later on the (upcoming) U-Boot support? I will try to post a comprehensive patch set in the next few days
<wens>
apparently ChatGPT also consumes kernel patches and commit logs ... as a friend asked it to "give an example of a commit message from the Linux kernel" and it gave them one of my commits for R40 DT TCON ...
<wens>
... which doesn't seem to actually exist lol
<gamiee>
lol
<apritzel>
wens: you are supposed to ask: "are you sure?", then it will correct itself ;-)
<apritzel>
(or will become rude)
<wens>
it wasn't me who was asking :p
BroderTuck has joined #linux-sunxi
<wens>
anyway, for fun and laughs, the patch subject was "ARM: dts: sun7i: Add R40 TCON LCD bus node"
<wens>
well, other than the subject prefix being wrong and it never actually happening, the commit message seemed quite good lol
<BroderTuck>
From what I understand (haven't tried myself) is that ChatGPT will happily include quotations if asked to... that all 404.
<apritzel>
wens: that's an interesting interpretation of the word "example" then
hunbalazs has quit [Remote host closed the connection]
<apritzel>
tuxd3v: I am not sure I follow
<apritzel>
the triplet is provided by the toolchain, the kernel doesn't really care
<apritzel>
it just uses the compiler you give it, via $CROSS_COMPILE or natively
<apritzel>
and what do you mean with "arm gcc 11.3 is broken"? Can you elaborate that?
hunbalazs has joined #linux-sunxi
hunbalazs has quit [Remote host closed the connection]
hunbalazs has joined #linux-sunxi
JohnDoe_71Rus has quit []
<apritzel>
you should just ignore any toolchains from websites, and use the (cross)compilers your distro provides: $ apt-get install gcc-arm-linux-gnueabihf
sadyntax has joined #linux-sunxi
sadyntax has quit []
sadyntaxbadger has joined #linux-sunxi
<tuxd3v>
apritzel,but debian forl example provides only ARCH-linux-gnu, they don't provide ARCH-elf versions for uboot.. so I was using cross tools from arm website..
<tuxd3v>
to compile the kernel debian 10.2 should be ok,
<tuxd3v>
but Just imagine that you have a cortex-a76..10.2 doesn't have support for cortex-a76, if you want to -mtune for it..
<tuxd3v>
I think that 10.2 has support for cortex-a75 maybe..
<tuxd3v>
I need to check that..
<tuxd3v>
My bad, actually 10.2 already has cortex-a76 and also cortex-a76.cortex-a55 :)
<apritzel>
I think you are expecting too much from -mtune ...
<tuxd3v>
its 8.3 that doesn't have them..
<apritzel>
you don't need elf or none version of toolchains for most self-contained code like firmware or kernels
<apritzel>
ARCH-linux-gnu is a superset of what you need
<apritzel>
I always use the distro provided (cross-)compiler, for U-Boot, TF-A, kernel, kvm-unit-test, you name it ...
<apritzel>
I don't want to disappoint you, but I don't think that -mtune=cortex... really does anything useful
<apritzel>
especially not for kernel or firmware code
<apritzel>
-march=armv8.2-a might be useful, but the kernel uses many later arch features even without it
<apritzel>
by hand-coding instructions in (so toolchains don't need to know about the encodings), and then by patching code in at runtime
<apritzel>
... and a brief look into the GCC source tells me that the A76 target is actually using the cost table and insn scheduler for A57
<apritzel>
there are only a few features like PAC or BTI that need explicit compiler support, but an A76 has neither of them
macromorgan has joined #linux-sunxi
<tuxd3v>
apritzel, I didn't tested debian toolchains I was using arm provided ones..
<tuxd3v>
I didn't even knew that debian now provides them too :(
<LordKalma>
why aren't we all on llvm? :(
<apritzel>
LordKalma: you could, it really doesn't matter too much anymore
<tuxd3v>
LordKalma, for riscv clang seems to be in better position right now, at least in relation to some riscv extensions, like Bit Manipulation zbb
<tuxd3v>
I tested some code in godbolt c , and testing gcc 12.2 with clang 14 or 15, clang was more optimised doing __builtin_bswapn(); functions
<tuxd3v>
which is kinda crazy given the fact that those builtins were created for gcc..
<tuxd3v>
In any case the assembler generated is still not there..
<LordKalma>
llvm is getting behind for example in c++ standard support for the latest things
<LordKalma>
it's a shame
<LordKalma>
I honestly think it could be *the* compiler
junari_ has joined #linux-sunxi
<tuxd3v>
for riscv al teast in some things seems ahead of gcc..
<LordKalma>
the backends are going.
<LordKalma>
they even got AVR not long ago
<LordKalma>
clang++ is falling behind....
<LordKalma>
rustc is going full steam of course :p