Updating buildroot

[consp]

I've already ran into some issues with builtroot which have been patched upstream but not yet included in the current version (openssh for instance, but fixed by not using it, it was just a test). While not yet released it would be good to consider if an update is wanted when available.

• Is there interest in updating the builtroot env as long as the kernel is compatible?
• Is there any need to do so? (maybe it's just my X11 testing setup messing about)
• Do we even want to bother as long as it works?

See also issue #25.

[xblax]

Buildroot 2023.02 is the latest long term release, it should be maintained upstream for quite a while. I would like to keep that for now. Newer Buildroot releases also include Python 3.12 which I think is not that well tested for Klipper/Moonraker yet.

But when discussing Buildroot - how did you set that up for hard float? Did you add -march and -mpfu overrides?
Just enabling hard float ABI does not seem to be reflected in Python platform definition. This is what I did so far: xblax/flashforge_adm5_buildroot_chroot@5a56a19

Any tools missing in the chroot which are useful on a 3D printer? I will add git for the target, the can be useful sometimes.

[consp]

LTS is probably best then.

Setting the EABI to EABIHF should only output hf since it uses eabihf as backend.
You can check if it was done correctly by doing readelf -A [program] and looking for Tag_ABI_VFP_args: VFP registers.

By python, do you mean the cross compiled or the buildroot native?
The crosscompiled needs +vfpv4+simd as arch arguments. I'll check later today if I made a mistake or not. If you check the compile stage for the build_python script I added the check for the HARDFLOAT variable and if present adds the +simd+vfpv4 arch.

[consp]

With respect to tools:

• vim (because reasons and I simply cannot use nano without mental gymnastics)
• git
• proper netcat
• some networking tools for debugging the wifi connection etc, like ping, ifconfig or equivalent etc. (maybe already included, havn't checked)

Personally I included lots of X tools but those are not needed for the final version, e.g. setting x configuration and other stuff.

[consp]

Update:

Please try

BR2_ARM_EABIHF=y
BR2_ARM_FPU_NEON_VFPV4=y

You definitely want neon as it speeds up mem* and other kinds of libc stuff and helps with vectorization hints if present in C code.

[xblax]

Yes compiled it yesterday with these settings, but have to test again. But for the cross Python environment the platform name seems to always be just "armv7l". It seems to not be aware of hard float or any extensions being active. If "+vfpv4+simd" is added, the wheels don't match the target python.

Btw. setting BR2_ARM_FPU_NEON_VFPV4=y and BR2_ARM_EABIHF=y already enables these settings as default in the toolchain. That confused me a bit at first, but it's not necessary to pass -mabi-float=hard -mpfu=neon-vfpf4 -march=armv7-a+neon-vfpf4. Everything that's build with the buildroot toolchains get's that automatically.

After changing the settings had to purge ccache, or it would fail to build.

Packages:

• will enable vim
• will check if netcat is in and maybe enable tcpdump
• other network utils are mostly in already, also iptables but didn't check if the kernel supports it

Maybe we also want to have avahi daemon to find the printer on the network via MDNS.

[consp]

Checked it (and my commet got deleted somehow).

#:flashforge_adm5_klipper_mod/build_output/wheels/klipper_wheels$ unzip cffi-1.14.6-cp311-cp311-linux_armv7l+vfpv4+simd.whl
Archive:  cffi-1.14.6-cp311-cp311-linux_armv7l+vfpv4+simd.whl
  inflating: _cffi_backend.cpython-311-arm-linux-gnueabihf.so
... etc
#: flashforge_adm5_klipper_mod/build_output/wheels/klipper_wheels$ readelf -A _cffi_backend.cpython-311-arm-linux-gnueabihf.so | grep -E "(VFP|NEON)"
  Tag_FP_arch: VFPv4
  Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
  Tag_ABI_VFP_args: VFP registers

  Tag_CPU_name: "7VE"
  Tag_CPU_arch: v7

Do you have the following in the build_python_wheels.sh?

if [ -z "$HARDFLOAT" ]; then
        HF=""
        CROSS="arm-buildroot-linux-gnueabi"
else
        HF="+vfpv4+simd"
        CROSS="arm-buildroot-linux-gnueabihf"
fi

SYSROOT="$BUILDROOT/output/host/$CROSS/sysroot"
... more text ...
python3 -m crossenv --machine=armv7l$HF --sysroot=$SYSROOT "$TARGET_PYTHON" cross_venv

By the looks of it I was sleeping already and assumed machine was march ... Does it really matter? It's just a string. As long as you take arm-buildroot-linux-gnueabihf it will compile with hf enabled by the looks of it, everything on my config is vfpv4/neonv1 enabled.

It does matter, that is why my config was borked.

[xblax]

Have everything updated for hard float now. Probably too many pre-built components and not enough automation at the moment. Let's hope we don't have to change the toolchain again :D Will have to improve the build process at some point ...

[consp]

Did you make the prebuild virtenv's on the device?

[xblax]

Yes, I don't know any other way to create them. I wanted to speed up the install process instead of creating them from the wheels when installed.

[KaruroChori]

An NFS share where you crossbuild locally on your machine, but you mount it on the target device might help. Assuming your target device is in the same LAN. And that I properly understood the issue.
But I have no deep experience with python.

[consp]

I would run it in a qemu instance but that's a lot of effort as well.