<xypron>
sjg1: what I wantis to run tests in phase 2 of CI. It seems you have been thinking about the global builds.
mmu_man has joined #u-boot
haritzondo has quit [Changing host]
haritzondo has joined #u-boot
qschulz has quit [Quit: qschulz]
qschulz has joined #u-boot
jmasson has joined #u-boot
haritzondo has quit [Ping timeout: 268 seconds]
haritz has joined #u-boot
haritz has quit [Changing host]
haritz has joined #u-boot
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #u-boot
<Tartarus>
xypron: You should likely just add a defconfig that uses #include at this point.
zsoltiv_ has quit [Quit: Left]
zsoltiv_ has joined #u-boot
persmule has quit [Remote host closed the connection]
LeSpocky has quit [Ping timeout: 252 seconds]
LeSpocky has joined #u-boot
haritz has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
mmu_man has quit [Ping timeout: 276 seconds]
vagrantc has quit [Ping timeout: 248 seconds]
vardhan has joined #u-boot
sakman has quit [Remote host closed the connection]
clamor has joined #u-boot
sakman has joined #u-boot
vardhan has quit [Remote host closed the connection]
gsz has joined #u-boot
clamor has quit [Ping timeout: 260 seconds]
clamor has joined #u-boot
Stat_headcrabbed has joined #u-boot
gsz has quit [Ping timeout: 276 seconds]
dhruvag2000 has joined #u-boot
gsz has joined #u-boot
godvino has quit [Remote host closed the connection]
godvino has joined #u-boot
frytaped has joined #u-boot
frytaped has quit [Client Quit]
vagrantc has joined #u-boot
vagrantc has quit [Quit: leaving]
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 276 seconds]
rvalue- is now known as rvalue
dhruvag2000 has quit [Quit: Connection closed for inactivity]
alpernebbi has quit [Ping timeout: 245 seconds]
Stat_headcrabbed has quit [Remote host closed the connection]
alpernebbi has joined #u-boot
sally_ has joined #u-boot
pitillo has joined #u-boot
sally has quit [Ping timeout: 268 seconds]
<pitillo>
Hello everybody, I have a question (sorry for my english level and my low knowledge), can the latest version of u-boot be compiled for old devices? I am seeing that there is a default configuration for the Cubieboard2 but I am having problems to compile it using different tags (v2025.04, v2015.04, v2015.01, v2014.10 and v2014.07. These last older ones recommended from the official page of the device).
mmu_man has joined #u-boot
clamor has quit [Ping timeout: 248 seconds]
clamor has joined #u-boot
<sjg1>
xypron: Yes, Tom asked that we add specific boards. I would like fragments to be tied to boards which they are known to work on, which is why I suggested that file format
<sjg1>
xypron: I am the easiest guy in the world with most people, but when I sense that things are difficult, I adjust accordingly and I seldom back down. If people want me to be flexible and easy-going, they can be that way with me.
vardhan has joined #u-boot
vardhan_ has joined #u-boot
mtoy has quit [Ping timeout: 240 seconds]
mtoy has joined #u-boot
<marex>
pitillo: what kind of problems ?
<marex>
pitillo: the CI builds every reachable configuration
vardhan has quit [Ping timeout: 276 seconds]
vardhan_ has quit [Ping timeout: 276 seconds]
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
goliath has joined #u-boot
Poltawer has joined #u-boot
clamor has quit [Remote host closed the connection]
clamor has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 248 seconds]
<Tartarus>
sjg1: That's not a great way to work with a community however.
haritz has joined #u-boot
haritz has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
mmu_man has joined #u-boot
persmule has joined #u-boot
dsimic has quit [Ping timeout: 244 seconds]
dsimic has joined #u-boot
<sjg1>
Tartarus: What a community really needs is compromise
K900 has quit [Remote host closed the connection]
K900 has joined #u-boot
sally_ has quit [Changing host]
sally_ has joined #u-boot
sally_ is now known as sally
<Tartarus>
Yes, and so "seldom back down" is a problem.
Stalevar has quit [Read error: Connection reset by peer]
Stalevar has joined #u-boot
<sjg1>
Tartarus: Taken out of context it would be. You seem to have missed the whole meaning of my message though
<pitillo>
hey marex, long time!
<pitillo>
I'm trying to build u-boot nativelly on a cubieboard2 and on a odroidxu4 (for the cubieboard2) and I'm getting assembler errors due to Thumb mode, so I don't understand what's happening and what could be the root cause. Let me share the log of the build on the odroidxu4 (gcc 14.2.0) -> https://crux.nu/rpaste/XhpdUbnj.txt
persmule has quit [Remote host closed the connection]
<pitillo>
What I noticed is that it's built with -msoft-float on a hardfloat toolchain so there is an strange mix in this scenario. So another question is if the CI is tested on a cross enviroment or if it's nativelly built
persmule has joined #u-boot
clamor has quit [Ping timeout: 252 seconds]
clamor has joined #u-boot
<marex>
pitillo: did you set CROSS_COMPILE to arm-something-eabi- toolchain prefix ?
<marex>
pitillo: export ARCH=arm ; export CROSS_COMPILE=arm-linux-gnueabi- ; make -j`nproc`
<marex>
... assuming your armv7a toolchain gcc is called arm-linux-gnueabi-gcc
<pitillo>
but I'm not cross compiling, I'm trying to build it nativelly with current host's gcc version
<marex>
pitillo: and the host is armv7a or armv8a ?
<marex>
I can try and run a test build for you with debian armhf
<pitillo>
I haven't tested other distro, I'm currently using CRUX-ARM, so it'd be great if you can confirm if it's working right for you there
<pitillo>
if it doesn't take you too many time or or may be an inconvenience for you
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 248 seconds]
rvalue- is now known as rvalue
<marex>
u-boot# gcc --version
<marex>
gcc (Debian 14.2.0-13) 14.2.0
<marex>
pitillo: compiled just fine
<marex>
pitillo: check if your toolchain isnt armv5 or recognized as armv5
<pitillo>
only with the export and make?
<pitillo>
or the export isn't really needed?
<marex>
without any export in fact
<marex>
the export is needed for crosscompiling
<pitillo>
good to know, so there is something broken in our toolchain
<pitillo>
I need to check how to verify if the toolchain is recognized as armv5
<marex>
poke around arch/arm/config.mk
<pitillo>
yeah, I was making some changes/tests there. I need to deep more, but if debian's toolchain is working as expected, there is something wrong in our side
<marex>
in your case, that would be I think "armhf" and not "arm64"
<pitillo>
in this case I believe I need to look for 32b armhf toolchain
<pitillo>
yeah
<marex>
I think mkosi can even spit out VM (qemu?) image, so you can boot that on your host system and experiment
<marex>
back in a bit
bjoto has quit [Remote host closed the connection]
<pitillo>
marex: if it possible, could you please share a verbose build to compare? I'm trying to understand why it's detecting our toolchain as a soft-float toolchain
clamor has quit [Read error: Connection reset by peer]
<marex>
pitillo: sec
zkrx has quit []
<marex>
pitillo: I have to redo the whole thing
<pitillo>
so don't worry, I'll keep deeping in sources
<pitillo>
the clue is cc-option.... who checks compiler options/features.... so I need to know how that works to understand what's happening
<pitillo>
yes, that helps to see that our triplet differs from debian's triplet
<pitillo>
but I can see that it's still compiling with soft-float instead of hard-float, what is something strange for me when a hard-float toolchain is used in that case too
<marex>
here is the psci.c which blows up in your case
<marex>
pitillo: you shouldnt need hardfloat stuff in U-Boot, it is all integer arithmetics
<pitillo>
interesting, so probably is something related to our toolchain and how it manages soft-float stuff
<marex>
well ...
<marex>
arch/arm/cpu/armv7/sunxi/psci.c:295:1: error: Interrupt Service Routines cannot be coded in Thumb-1 mode
<marex>
this is weird
<marex>
pitillo: btw try u-boot/master, also fails ?
<pitillo>
it's the same output in both cases, yours and mine, and your toolchain is ready to "understand" all those flags from a soft-float toolchain, ours die
<pitillo>
I haven't tried master, let me give it a try
<pitillo>
ummmm trying other toolchains won't solve our real problem :(
<pitillo>
I'd like to understand what's happening
<marex>
pitillo: test another easy to test toolchain and see if the issue disappears, if yes, then it is surely toolchain
<marex>
else it might be something else
<pitillo>
because the root cause of the problem will be there and may be it affects more things (I only noticed a problem here, but without understanding what's happening, it makes me scare)
<pitillo>
you have done a good test with a strong distro toolchain
<pitillo>
something I can test is trying to build u-boot on a newer device using our aarch64 toolchain...
<pitillo>
and check if it shares the same behavior as armhf... both are built in the same way (adapting options for each architecture)
<marex>
pitillo: aarch64 toolchain cannot be used to build armv7a stuff
<pitillo>
yeah, of course... I mean try to build u-boot for a 64b capable device >armv8 (not to use it to build for <armv7)
<marex>
that wont really give you any useful info, arm64 is a different isa
<pitillo>
yes, but in our case both toolchains share the same build process, adapting options for each one. So I'm afraid that we are doing something wrong in the most important part of a source based distro
gsz has quit [Ping timeout: 276 seconds]
<marex>
pitillo: wouldnt that blow up all over the place during some other package rebuild ?
<marex>
kernel comes to mind
<pitillo>
no problem on any of them (we are able to build kernels nativelly on 32b and 64b)
<pitillo>
package builds works fine too... but may be there is something hidden over there which could affect, like I'm seeing with u-boot currently
haritz has quit [Ping timeout: 265 seconds]
haritz has joined #u-boot
haritz has quit [Changing host]
haritz has joined #u-boot
<pitillo>
so building rpi_arm64_defconfig on a CRUX-ARM aarch64 podman container worked right
<pitillo>
must be there something broken or wrong in our 32b toolchain
haritz has quit [Ping timeout: 276 seconds]
haritz has joined #u-boot
<pitillo>
well, I've readed something interesting regarding Debian toolchain.... hwcaps... which if I'm right, allows to run soft/hard binaries (multilib)... ours is pure hard-float
haritz has quit [Changing host]
haritz has joined #u-boot
<marex>
pitillo: interesting that you can compile kernel with that toolchain
<pitillo>
being a hard-float toolchain isn't fully supported by linux kernel? I actually compiled a 6.1.90 kernel for the odroidxu4 at the end of March.
<marex>
I think the kernel also does not use any of the hard float stuff
<pitillo>
we really thought on performance at userland (no at kernel/boot level)
<pitillo>
Anyway, it's good to know that even though we don't actually use the HW, it allows us to compile it with a pure hard-float toolchain without needing support for soft-float.
<pitillo>
at the end, the fpu is not really used when working with integers, but being forced to use a multilib libc to work with integers sounds strange for me too
<pitillo>
btw... for me and IMHO, ARM has always been "wild"
<marex>
pitillo: I am not entirely sure if this is related to toolchain being hardfloat
<pitillo>
I trust you more than me.... but from what I've read about Debian's toolchain, that's a big difference with our toolchain
<pitillo>
may be there are more differences (and probably at many levels)... but from what I understand, currently on my system I'm trying to build objects specifying soft-float usage, when our toolchain isn't multiarch
<pitillo>
but it's just a feeling.... your knowledge was and it is far far away from mine... the efika smarttop days are long gone now :)
<marex>
pitillo: maybe check with vagrantc when he appears here ... he might have some hint
<pitillo>
I'll be around and keep trying things, although I'll probably end up breaking more than fixing :)
<pitillo>
anyway, I would like to thank you for sharing your time, knowledge and patience with me. It's always been a pleasure
<marex>
sure, you're welcome
haritz has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]