4

I'm following the Cross-compiled Linux From Scratch - Embedded book. I need to know the following information for the Raspberry Pi 4B:

  • Target architecture triplet - aarch64-linux-musleabihf.
  • Architecture - aarch64.
  • ARM architecture - armv7l.
  • Floating point support - hard.
  • Floating Point Unit version - neon-fp-armv8.

Is this the correct triplet? If not, what is it or how do I go about finding it out?

I got the FPU version from a post on Stackoverflow - can anyone confirm if this is correct?

I believe the architecture, ARM architecture and floating point support are correct. Please correct me if they are wrong.

junglie85
  • 181
  • 5
  • 1
    Pretty sure armv7l should be armv8 as well, the former is 32-bit. – goldilocks Feb 26 '21 at 14:40
  • Ah, yep, you're right. I hadn't realised that Raspbian uses arm7l by default because it's backwards compatible to 32-bit - https://raspberrypi.stackexchange.com/questions/101215/why-raspberry-pi-4b-claims-that-its-processor-is-armv7l-when-in-official-specif – junglie85 Feb 26 '21 at 18:08
  • ICYI the 64-bit beta version of Raspbian/RpiOS is fine, at least headless (and probably headful as I don't think we have seen any gripping about it here). – goldilocks Feb 26 '21 at 19:59

3 Answers3

4

I had to go with the following in the end:

Name Description Value
CLFS_HOST Host architecture triplet x86_64-cross-linux-gnu
CLFS_TARGET Target architecture triplet aarch64-linux-musl
CLFS_ARCH Architecture arm64
CLFS_ARM_ARCH ARM architecture armv8-a+crc
CLFS_ARM_CPU ARM CPU cortex-a72
CLFS_ABI ABI data model lp64
junglie85
  • 181
  • 5
0

As has been mentioned in the comment you want arm8 for 64bit machine.

root@buster-raspi:~# cat /boot/firmware/config.txt 
# Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
arm_64bit=1

enable_uart=1
upstream_kernel=1


kernel=vmlinuz-5.9.0-0.bpo.5-arm64


For details on the initramfs directive, see


https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=10532


initramfs initrd.img-5.9.0-0.bpo.5-arm64
0

Apparently it's down to specifying neon in the mfpu definition;-

"If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations are not generated by GCC’s auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. "

https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#index-mfloat-abi

Pat McDonald
  • 1