07:40 <pitillo> morning guys, I'd like to share something interesting I've learn yesterday along my jorney with uboot

07:40 <pitillo> may be you were aware of it, but anyways, I'll let it here to let the bot take note for the future xD

07:42 <pitillo> I've been speaking with marex about the problems I've found building u-boot nativelly on the cubieboard2 and the odroid-xu4 using our armhf release (3.2 on the cubieboard, 3.7 and 3.8 on the odroid-xu4)

07:43 <pitillo> he told me that the CI pipes build u-boot without problems, so I asked him to make a test for the cubieboard2 defconfig... and he did a successful build on debian armhf distro

07:43 <pitillo> so there is a big difference between CRUX-ARM armhf and Debian armhf and it's directly related to the toolchain

07:45 <pitillo> Debian builds a multiarch (multilib) toolchain, which allows using soft-float operations on armhf. In our case, we are building a true hard-float toolchain which doesn't allow soft-float operations

07:46 <pitillo> Debian calls it hwcaps and u-boot it's oriented to be built directly with soft-float, because they aren't using floating points registers, they only use integers for they operations

07:46 <pitillo> so when we try to build u-boot, the compiler flags used are exclusivelly soft-float oriented and our toolchain doesn't manage them right

07:48 <pitillo> most software, included kernels, does support real hard-float toolchains... I haven't hit any similar problem in any other software than u-boot (marex was surprissed that we were able to build kernels with our current real hard-float toolchain, but for me, it wouldn't has sense to don't be able to do that)

07:52 <pitillo> so now the question is if it's worth the effort to try to make a multiarch/multilib toolchain for armhf devices, if may be touching/adapting uboot source to add real hard-float toolchain support to provide a patch upstream to be reviewed... or directly use a Debian container or a cross toolchain with multilib support in case someone needs to build uboot is more than enough

07:54 <pitillo> we don't have many time nor many resources to put hands on any other stuff than maintaining the distro and ports.... so probably change the toolchain to add multilib/multiarch support could be expensive in terms of time and resources

07:55 <pitillo> trying to put hands on u-boot could be an option to improve its support trying to don't break current builds (ARM 32b), but the lack of knowledge it's another important handicap in this case

07:57 <pitillo> if you have any thoughts about this I'd like to listen opinions and discuss anything

14:25 <jaeger> Not sure what I would choose/recommend... if it's only u-boot for which this causes a problem, maybe just go the easy route with the cross toolchain in a container. But what are the chances it could affect something else that's just not known currently?

14:42 <cruxbridge> <pitillo (@pitillo:crux.nu)> no idea about chances jaeger .... I have many doubts/questions regarding this multilib stuff and which are the PROs of mixing soft-float on hardware with a real FPU... performance to work with integers on the CPU instead of the FPU? Shouldn't that eat CPU cycles instead of relay on the FPU which is the arithmetic unit... aimed on floating point units, but integers can be managed as float..... compatibility issues? Giving...

14:42 <cruxbridge> ... backwards compatibility for specific software

14:43 <jaeger> I would think using hard-float would perform better but admittedly I'm no expert

14:44 <cruxbridge> <pitillo (@pitillo:crux.nu)> it's a bit messy and I can't find an answer about why Debian implemented multilib on >armv7 instead of implement a real hardfp

14:44 <jaeger> I would guess just to make things simpler for varied hardware but just a guess

14:45 <cruxbridge> <pitillo (@pitillo:crux.nu)> and as a side note, the only piece I've found giving problems is u-boot, which is developed for soft-float because it only works with integers.... but it hasn't hard float support

14:45 <cruxbridge> <pitillo (@pitillo:crux.nu)> possibly, no idea really

17:25 <crux-arm-bot> [ opt-arm64/3.7 ]: docker-compose: update to 2.35.1

17:31 <crux-arm-bot> [ opt-arm64/3.8 ]: samba: update to 4.22.1

17:49 <crux-arm-bot> [ opt-arm64/3.7 ]: go: update to 1.24.2