Error compiling project in Raspberry Pi 3 with Alpine Linux aarch64

[pablojr]

I've installed Alpine Linux 3.8.1 aarch64 in Raspberry PI 3. I cloned the project with git, and want to build it natively with gcc 6.4.0 so I configured with command:

cmake -DWAVESHARE35B_ILI9486=ON -DSPI_BUS_CLOCK_DIVISOR=10 -DARMV8A=ON ..

but when I do make, these errors appear:

rpi3-64:~/projects/fbcp-ili9341/build$ make
[  5%] Building CXX object CMakeFiles/fbcp-ili9341.dir/diff.cpp.o
c++: error: unrecognized argument in option '-mtls-dialect=gnu2'
c++: note: valid arguments to '-mtls-dialect=' are: desc trad
c++: error: unrecognized command line option '-marm'; did you mean '-fasm'?
c++: error: unrecognized command line option '-mhard-float'; did you mean '--warn-format'?
c++: error: unrecognized command line option '-mfloat-abi=hard'
make[2]: *** [CMakeFiles/fbcp-ili9341.dir/build.make:63: CMakeFiles/fbcp-ili9341.dir/diff.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/fbcp-ili9341.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

[juj]

Thanks for reporting. I have not actually tested the Arm-v8a path at all, I do not have a 64-bit Raspberry Pi OS installation on any of my dev boards yet. Does the compilation error occur if you remove -DARMV8A=ON directive from CMake? (delete CMakeCache.txt before that, so it does not pick the same flag up from the cache file)

The erroring directives come from this line

fbcp-ili9341/CMakeLists.txt

Line 49 in 7df6ec3

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -marm -mabi=aapcs-linux -mhard-float -mfloat-abi=hard -mlittle-endian -mtls-dialect=gnu2 -funsafe-math-optimizations")

, though it may be that those are not related to 64-bitness, but related to the Linux distro/GCC in question. What is the GCC version on that system (gcc --version)?

Try removing the erroring directives from that line. Does that let the build pass? That line exists to aggressively optimize for performance with the compiler, so not needed for a particular feature in code.

Perhaps I'll need to gate those four out depending on GCC version, or something similar.

[pablojr]

Hi, thanks for the response.

GCC version:

$ gcc --version
gcc (Alpine 6.4.0) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I tried commenting out the line you suggested, and these errors related to assembler appeared:

make[2]: Entering directory '/home/pablo/projects/fbcp-ili9341/build'
[  5%] Building CXX object CMakeFiles/fbcp-ili9341.dir/diff.cpp.o
/usr/bin/c++   -I/opt/vc/include  -DSTATISTICS -DSPI_BUS_CLOCK_DIVISOR=10 -DUSE_DMA_TRANSFERS=1 -DILI9486 -DWAVESHARE35B_ILI9486 -O3 -DNDEBUG   -o CMakeFiles/fbcp-ili9341.dir/diff.cpp.o -c /home/pablo/projects/fbcp-ili9341/diff.cpp
/tmp/ccOnEKle.s: Assembler messages:
/tmp/ccOnEKle.s:257: Error: operand 1 must be an integer register -- `mov r0,x13'
/tmp/ccOnEKle.s:258: Error: operand 1 must be an integer register -- `mov r1,x23'
/tmp/ccOnEKle.s:259: Error: operand 1 must be an integer register -- `mov r2,x21'
/tmp/ccOnEKle.s:261: Error: unknown mnemonic `pld' -- `pld [r1,#128]'
/tmp/ccOnEKle.s:262: Error: unknown mnemonic `pld' -- `pld [r2,#128]'
/tmp/ccOnEKle.s:263: Error: unknown mnemonic `ldmia' -- `ldmia r1!,{r3,r4,r5,r6}'
/tmp/ccOnEKle.s:264: Error: unknown mnemonic `ldmia' -- `ldmia r2!,{r7,r8,r9,r10}'
/tmp/ccOnEKle.s:265: Error: operand 1 must be an integer or stack pointer register -- `cmp r3,r7'
/tmp/ccOnEKle.s:266: Error: operand 1 must be an SVE predicate register -- `cmpeq r4,r8'
/tmp/ccOnEKle.s:267: Error: operand 1 must be an SVE predicate register -- `cmpeq r5,r9'
...
...

[juj]

Ah darn, it looks like the assembler code is not 64-bit AArch/ARMv8A capable. This does make me suspect if 64-bit ARM OSes will work at all.

The handwritten assembly code in the driver repository is not mandatory, there asm algorithms are geared for Pi Zero (when UPDATE_FRAMES_WITHOUT_DIFFING or UPDATE_FRAMES_IN_SINGLE_RECTANGULAR_DIFF options are used). On multicore Pis neither of those algorithms is generally used. Pushed a patch in above commit to remove the assembly code if those options are not actually used. If you are still experimenting, check out how that code behaves.

Now that I think about it, it may be that 64-bit OS can run into some address space layout related issues at runtime, it may be that the peripheral addresses are located differently.

[pablojr]

@juj thank you for the response. I did update my working copy and the assembler errors disappeared; however the full compile didn't build as it stopped at <bcm_host.h> not found.
Since that file is related to proprietary Broadcomm software for the VideoCore 4 GPU and it's only available for 32-bit (i.e. Raspbian) Alpine Linux is not deploying such artifacts...
I'm not sure I'll pursuit this in the near term, since it seems the VC4 driver/binaries won't be released for 64-bit soon and given that I found a driver from fbtft project working fine with my LCD display, I can go with that for now.

Thanks again!

[juj]

Thanks for the info. Fbcp-ili9341 uses bcm_host.h for the following functionality:

• bcm_host_init(), bcm_host_deinit(): needed to init and deinit access to DispmanX GPU API.
• vc_dispmanx_*() GPU API functions,
• bcm_host_get_peripheral_address(), bcm_host_get_peripheral_size(), bcm_host_get_sdram_address(): used to obtain physical addresses of the Raspberry Pi peripherals (https://www.raspberrypi.org/documentation/hardware/raspberrypi/peripheral_addresses.md). These concepts do exist also in 64-bit, but not sure how access to them is mapped in 64-bit OSes.

The question is then perhaps how to avoid the DispmanX GPU API (/opt/vc/include/interface/vmcs_host/vc_dispmanx.h and /opt/vc/include/interface/vmcs_host/vc_dispmanx_types.h on Raspbian Pi, vc_dispmanx_*() API functions) side. If there is a way to snapshot, or get events of new GPU produced framebuffers, via some other performant manner, then sidestepping DispmanX may be possible. Not sure what the display stack looks like on Alpine Linux if they do not use/need DispmanX API, I always thought DispmanX was something fundamental that one cannot avoid. Fbcp-ili9341 does use a feature of DispmanX that it also rescales (on the GPU) the screen when snapshotting, if the SPI display is of different resolution than the current framebuffer. So a replacement would need to have this rescaling feature available to it, or restrict to requiring that one only uses framebuffers the same size as the SPI display is.

[pablojr]

@juj thanks for the interesting explanation.

I'm not sure you need to avoid "the DispmanX GPU API" given that your goal with this driver is speed.

I don't know what the fbtft drivers are doing, and I don't mean to compare your approach to the one from that project, but I proved the drivers provided by Alpine Linux 64 bits actually work with my LCD device so at some point and given the lack of the VC4 stuff in that same kernel, their approach is not dependent on that piece of software.

Another thing also working is Xfce once I installed/configured the drm_vc4_mesa package, also available for 64 bit OS

[billthecatt]

I ran into this same exact issue.. I was able to wkr around it by:

apt-get install libraspberrypi-dev

Hope this helps someone else.

[geerlingguy]

Has anyone tried this on the Pi OS 64-bit beta (as opposed to Alpine)?

[juj]

fbcp-ili9341 currently has a hardcoded understanding of the register address space being laid out according to the 32-bit layout, and uses fixed 32-bit pointers. (At the time of writing, a 64-bit Pi OS did not exist)

I have not since taken a peek at how it would work on a 64-bit OS.. it might work out of the box if the 32-bit portion of the address space for GPIO/SPI/DMA hardware registers etc. is the same, though I'm not quite sure. I briefly recall reading some Pi Foundation PDF about the 64-bit address space, but it's been quite some time, and cannot remember exactly what my conclusion from that was. Probably a "Hack away at will" kind of scenario to make it work :)

[leo60228]

From my research so far:

• This is different on BCM2710 vs. BCM2711
• On BCM2711, some DMA channels use 64-bit addresses while some use 32-bit addresses and paging
• I can't figure out how to convert a bus address from the VPU mailbox to a physical address on BCM2711
• I haven't tested but all evidence I've found for BCM2710 suggests that the VPU/DMA simply see the bottom 32 bits of the address space
• I'll probably do further testing on BCM2710 since that's what I'm actually interested in using fbcp-ili9341 on

[leo60228]

A 32-bit fbcp-ili9341 runs perfectly fine with a 64-bit kernel. I don't see much of a reason beyond convenience to use a 64-bit fbcp-ili9341, so this is a viable workaround.

[mcpat-it]

Any chance to get it in 64Bit? Rpi 5 is coming, and it would be fine...

[leo60228]

The Raspberry Pi 5 makes major changes to the peripherals. I don't think 64-bit support for BCM283x will impact much either way.