Infrastructure #974
closedxcc bump to 1.25.0
100%
Description
Time for an xcc bump.
Updated by Hammel over 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
RPi 2 and 3 can use a 64-bit toolchain.
RPi B+ and Zero/Zero-W must use a 32-bit toolchain. The Zero-W 2 is not supported as of yet, but would use the same toolchain as the RPi 2/3.
Updated by Hammel over 1 year ago
I built the toolchain for RPi 2/3 but made it 32-bit. I need to change it to 64-bit and rebuild the kernel (which I'd already built as 32-bit).
Updated by Hammel over 1 year ago
Found a walkthrough for building with Crosstool-NG for 64bit.
Looks like my config file might not be appropriate for aarch64. I need to run
ct-ng aarch64-rpi3-linux-gnu
and then compare that .config with my saved config (re: make xcc-meld, which doesn't exist yet).
Updated by Hammel over 1 year ago
- % Done changed from 10 to 30
I got a working toolchain and built an arm64 kernel with it.
Next is to build gles, but that fails to build due to "compiler error". gles is at an older commit id. I need to check if I can bump that up to something newer that can work with the 64bit compiler.
Updated by Hammel over 1 year ago
Use of compiler options need to be removed with aarch64 builds, and an additional --aarch64 passed to the buildme script. However, I have a custom copy called buildme.pibox which needs merging with the upstream because it's missing the --aarch64 option.
Updated by Hammel over 1 year ago
- % Done changed from 30 to 40
I've now gles building for rpi2 with aarch64.
Busybox is also building with aarch64.
Buildroot build is failing:
Incorrect selection of gcc version: expected 10.x, got 11.2.0
This is likely because the version of Buildroot I'm using is too old. I'll have to bump it. That's actually RM #973.
Bumping to 64bit builds for RPi2/3 is requiring bumps to just about all the components builds, but that's to be expected since it's been quite some time since I've updated those component versions.
Updated by Hammel over 1 year ago
64bit build fails on nodejs for reasons I don't understand. Node.js is only used with Ironman. I could have 64bit and 32bit builds for RPI3 as a workaround.
However, I'd like to dump node.js. Javascriopt is fine - it's client side. But I don't need node.js on the server side. I should drop all node.js dependencies in ironman so I can use the 64bit builds on RPi 2 and 3.
Updated by Hammel over 1 year ago
Buildroot build completes after removing nodejs, but generation of ext4 file system fails, probably because the rootfs has gotten huge (see RM #1003). The ext4 file system isn't really needed anyway - there is already a tarball created by buildroot that can be used to create a non-squashfs install. So I'll drop the ext4 image (see RM #1004).
Updated by Hammel over 1 year ago
Buildroot now gets passed file system image creation but fails here.
>>> Executing post-image script board/raspberrypi3-64/post-image.sh INFO: cmd: "mkdir -p "/home/mjhammel/src/ximba/raspberrypi/bld/buildroot-2023.02.2/output/build/genimage.tmp"" (stderr): INFO: cmd: "rm -rf "/home/mjhammel/src/ximba/raspberrypi/bld/buildroot-2023.02.2/output/build/genimage.tmp"/*" (stderr): INFO: cmd: "mkdir -p "/home/mjhammel/src/ximba/raspberrypi/bld/buildroot-2023.02.2/output/build/genimage.tmp"" (stderr): INFO: cmd: "cp -a "/tmp/tmp.HnXquGN49Z" "/home/mjhammel/src/ximba/raspberrypi/bld/buildroot-2023.02.2/output/build/genimage.tmp/root"" (stderr): ERROR: file(bcm2710-rpi-3-b.dtb): stat(/home/mjhammel/src/ximba/raspberrypi/bld/buildroot-2023.02.2/output/images/bcm2710-rpi-3-b.dtb) failed: No such file or directory ERROR: vfat(boot.vfat): could not setup bcm2710-rpi-3-b.dtb
Updated by Hammel over 1 year ago
Now I've hit an impasse - the GLES (re: Userland) build doesn't officially support 64bit. It does build, but it doesn't build all libraries. One that's missing is the openmax library (all the mmal libraries, actually) required by omxplayer. So that's a show stopper - I can't build for 64bit because I require omxplayer. I don't want to switch to vlc because omxplayer fits my use cases better.
So it's back to a 32bit build.
Updated by Hammel over 1 year ago
Another twist: crosstool-ng has defconfigs for all rpi platforms, but now rpi2 and rpi3 are different. I could build for rpi2 and run on both (that worked up till now) but that may not optimize for rpi3.
So now I need rpi, rpi2 and rpi3 builds. Well, if that's what it takes to optimize, so be it.
I'll start with rpi2 and then add rpi3, then go back and update rpi1.
Updated by Hammel over 1 year ago
After cleaning out the aarch64 build options I rebuilt the toolchain and tried to rebuild the kernel. It failed looking for gmp.h. As it happens, this file is required on the build host from the libgmp-dev package. After installing libgmp-dev, I tried again and found I was missing mpc.h, which is in libmpc-dev. So I have added these two libraries to the docker build.
Kernel is now building.
Updated by Hammel over 1 year ago
- % Done changed from 40 to 80
Build is complete through to pkg target. So now it just needs testing on hardware.
Updated by Hammel over 1 year ago
- % Done changed from 80 to 30
It didn't boot on hardware. I can't tell why yet. I've had some problems with the RPi boards when running for a long time, like the PiSentry boxes. So it might be the boards or it might be the build.
I bumped everything to get here and that's really the wrong way to do things. The better solution is to build just a new toolchain and then test it by building everything with the old configs. If that works, then I start bumping the components.
So back to the drawing board. I'm going to retest the build one more time, with all the board powered down for a day first. I don't expect them to work, however. I'm also going to rebuild just the rpifirmware back to it's old release and test with that. But I don't think any of that will actually work.
Assuming all that fails, I need to create a branch with all the changes, then pull them in one at a time on another branch.
Bumping completion back down to 30%.
Updated by Hammel over 1 year ago
Retesting the build I found that the kernel didn't boot. Replacing my kernel with the kernel7.img found in the firmware collection allowed the kernel to boot, but that's all. So my build of the kernel with the new gcc didn't work. So, first step is to rebuild the kernel with the old gcc to make sure that works.
Then rebuild the toolchain with the latest Crosstool-NG but the same config (as much as possible) and rebuild the kernel. Then retest to see if that boots. It's best to keep the SD card I've already made and just replace the bits as I go, at least until I have the kernel booting.
Disregard that comment. I was using the wrong sandbox for the test.
Retesting with full component update build does allow the kernel to start to boot but then it crashes. I'll try putting the old firmware on the SD card and see if that helps, but I kind of doubt it.
Updated by Hammel over 1 year ago
Tested with old firmware - no change.
Testing with old kernel but new xcc.
Note: I had problems proving the SD cards were okay because somehow the existing build from the 2.0 release for rpi2 was corrupted. I rebuilt that release and retested to make sure both the SD card and RPi3 B+ were working - they are. So now I'm rebuilding just xcc and then will use that to rebuild the kernel. I only need it to boot cleanly, even if busybox doesn't work with it yet.
Updated by Hammel over 1 year ago
- Status changed from In Progress to Closed
- % Done changed from 30 to 100
Updated toolchain tested by building all existing component revs and booting on hardware. It all works.
Changes committed and pushed.
Closing issue.