Build for pihole-FTL ARM soft-float

Feldwebel · October 10, 2020, 12:37pm

In the latest release of FTL (v5.2): Releases · pi-hole/FTL · GitHub there are 3 ARM builds:
pihole-FTL-arm-linux-gnueabi
pihole-FTL-arm-linux-gnueabihf
pihole-FTL-armel-native

Analyzed them with readelf command and it seems that both first two are hard-float and last is soft-float.

Question 1: Shouldn't pihole-FTL-arm-linux-gnueabi be soft-float ?

I do have an armv5 machine which is soft-float. Output of uname -a:
Linux debian-nas 4.20.6-kirkwood-tld-1 #1 PREEMPT Thu Jan 31 21:41:45 PST 2019 armv5tel GNU/Linux

When I'm installing pihole it downloads and installs pihole-FTL-arm-linux-gnueabi which is hard-float does not work on a soft-float machine.

Question 2: Is this a bug or is it normal ? I don't know if that build should either be soft-float or the installer detects the architecture wrong.

Finally, I checked out the source code at V5.2, built and installed the pihole-FTL binary and everything is working fine, but every time I do a pihole reconfigure (needed to fix when I mess up something) the installer states: Corruption detected and reinstalls again the wrong binary for my architecture.

So, Question 3: What can I do for the installer to not detect the binary as corrupted when is built and installed locally ?

Thanks

DanSchaper · October 10, 2020, 2:09pm

Pogoplug?

Feldwebel · October 10, 2020, 4:37pm

No, Lenovo IX2 NG flashed with Debian 10.

DL6ER · October 10, 2020, 7:37pm

These notations come from the days of when Pi-hole was still Raspberry Pi-focused. The Raspbian foundation denotes

arm-linux-gnueabi -> ARMv6 with hard-float (BCM2835 as used in Zero and Model 1)
arm-linux-gnueabihf -> ARMv8 with hard-float (BCM2837, BCM2837B0, BCM2711 as used in Model 2 B v1.2, 3 and 4)

since we use their official cross-compilers, this is what these point to. They all have hardware vector floating point support

This is intentional, see the reasons above.

Not much. However, you are not the first one to request support for ARMv5TE processors. We should not change our regular pihole-FTL-arm-linux-gnueabi from v6 hard-float to v5TE soft-float as this may lead to a significant drop in performance. However, I'm of good cheer that we can add a v5TE build on top. Stay tuned to this space for updates.

Feldwebel · October 10, 2020, 9:56pm

Thanks for the great explanations.

But still, in this case, shouldn't the installer download the pihole-FTL-armel-native binary when running on an ARMV5 ?

DL6ER · October 11, 2020, 9:07am

is

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int

so no. At least not how it is currently built.

DL6ER · October 11, 2020, 10:30am

The reason is that the multiarch/debian-bootstrap container is an armv7l emulation:

$ docker run -it --rm multiarch/debian-debootstrap:armel-stretch-slim
root@d471d2b8697c:/# uname -a
Linux d471d2b8697c 5.4.0-45-generic #49~18.04.2-Ubuntu SMP Wed Aug 26 16:29:02 UTC 2020 armv7l GNU/Linux

I did some research on this and after some tweaking, the debian-armel build is now v4T-compliant:

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "4T"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int

I guess that's the way to go then. This binary will run on all ARM machines being able to run a Debian image.

Feldwebel · October 11, 2020, 10:37am

I see. So as far as I can tell that should work on armv5te although it's not the right build.

Also, I don't know the build system process in this project, but I do have a buildroot setup used to crosscompile for this arch so if I can support with the buildroot config, a docker image with the toolchain and/or testing I would be glad to.

LE: Nevermind this, just saw your last post

Yes, that looks good. But I did not quite understand, did you manage to build this binary in the armv7l container ?

DL6ER · October 12, 2020, 5:57am

Yes, even when the emulated machine is a ARMv7 one, I can instruct the compiler to avoid opcodes that are only available in more recent processors. This time, I specifically asked the compiler to compile for ARMv5TE and the resulting binary was even ARMv4T.

You can compare the ARMv7 (page 25ff) and the ARMv4T instruction set if you want to know more.

DL6ER · October 12, 2020, 6:17am

github.com/pi-hole/docker-base-images

Make arm-qemu builds ARMv4T compliant (was ARMv6) to support more devices

pi-hole:master ← pi-hole:ftl-build/debian-armv4t

opened 06:17AM - 12 Oct 20 UTC

DL6ER

+6 -6

**By submitting this pull request, I confirm the following:** - [X] I have re…ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** ## 10 --- Explicitly specify the building host to achieve true ARM Debian compliance with the cross-compiled build. We remove concurrent building of the dependencies as this can lead to compiler segmentation faults on many-core machines with a lot of concurrency in the emulator. Even though this build only requested ARMv5 compliance, the produce code actually generated a binary that is even ARMv4T complaint: ``` Attribute Section: aeabi File Attributes Tag_CPU_name: "4T" Tag_CPU_arch: v4T Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_rounding: Needed Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_enum_size: int ``` Even when this is not the expected outcome, any ARMv5TE processor will be able to run ARMv4T code. And as the compiler generated ARMv4T code while it was allowed to generate ARMv5TE means that, despite the fact that all compiler optimizations are enabled, no ARMv5TE-specific instructions are useful here and the generation of ARMv4T-compliant code is not slower by any means (due to missed optimizations). The PR updating the FTL builds for ARMv4T-compliance will also address the changed architecture in the tests. This has to come *after* this PR was merged.

Feldwebel · October 12, 2020, 9:12am

Great info

I guess in the next release there should be a binary for armv4t and armv5te so this topic may be closed.

Thanks.

DL6ER · October 12, 2020, 10:23am

Yes, after

github.com/pi-hole/FTL

Make arm-qemu builds ARMv4T compliant (was ARMv6) to support more devices

pi-hole:development ← pi-hole:new/ARMv4T-compliance

opened 09:11AM - 12 Oct 20 UTC

DL6ER

+47 -34

**By submitting this pull request, I confirm the following:** - [X] I have re…ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** ## 10 --- Explicitly specify the building host to achieve true ARM Debian compliance with the cross-compiled build. We remove concurrent building of the dependencies as this can lead to compiler segmentation faults on many-core machines with a lot of concurrency in the emulator. Even though this build only requested ARMv5 compliance, the produce code actually generated a binary that is even ARMv4T complaint: ``` Attribute Section: aeabi File Attributes Tag_CPU_name: "4T" Tag_CPU_arch: v4T Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_rounding: Needed Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_enum_size: int ``` Even when this is not the expected outcome, any ARMv5TE processor will be able to run ARMv4T code. And as the compiler generated ARMv4T code while it was allowed to generate ARMv5TE means that, despite the fact that all compiler optimizations are enabled, no ARMv5TE-specific instructions are useful here and the generation of ARMv4T-compliant code is not slower by any means (due to missed optimizations). The PR updating the FTL builds for ARMv4T-compliance will also address the changed architecture in the tests. This has to come *after* this PR was merged.

has been merged, the development branch will already have a armv4t+-complaint binary. This will then automatically extend to the next release version as well.

DL6ER · October 13, 2020, 11:02am

@Feldwebel I'm currently improving the automatic detection of which binary is to be used (this is less trivial than one would naively assume...).

Can you give me the output of the following commands?

uname -m | sed "s/[^0-9]//g;"
ldd /bin/ls | grep -E '^\s*/lib' | awk '{ print $1 }'

It should be

5
/lib/ld-linux.so.3

for you.

Feldwebel · October 13, 2020, 11:36am

Sure thing.

feldwebel@debian-nas:~$ uname -m | sed "s/[^0-9]//g;"
5
feldwebel@debian-nas:~$ ldd /bin/ls | grep -E '^\s*/lib' | awk '{ print $1 }'
/lib/ld-linux.so.3

DL6ER · October 18, 2020, 5:59pm

The mentioned PR was superseded by

github.com/pi-hole/FTL

Add pre-compiled ARMv4, ARMv5 and ARMv8 binaries to CI workflow

pi-hole:development ← pi-hole:new/armv4_armv5

opened 05:45AM - 14 Oct 20 UTC

DL6ER

+74 -33

**By submitting this pull request, I confirm the following:** - [X] I have re…ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** ## 10 --- Add additional - ARMv4 (`armv4t`, 3-stage pipeline, Thumb, ARMv4 first to drop legacy ARM 26-bit addressing), - ARMv5 (`armv5te`, Thumb, enhanced DSP instructions, caches), and - ARMv8 (`armv8-a`, fundamental change to the ARM architecture with mandatory vector floating point and SIMD (Neon)) workflows. - ARMv6 (with hard-float, for Raspberry Pi Model 1 and Zero), and - ARMv7 (with hard-float, for Raspberry Pi Model 2) already exist and have just been renamed to clarify the supported architecture.

to have binaries with maximum performance for all ARM binaries around there.

DL6ER · November 9, 2020, 12:55am

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.