| Message ID | 20240723212011.23048-3-gael.portay@rtone.fr |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | rpi-utils replaces rpi-userland | expand |
On Tue, 23 Jul 2024 23:20:11 +0200 "Gaël PORTAY" <gael.portay@gmail.com> wrote: > + Important: The package is ancient and deprecated. > + > + It largely contains code using proprietary APIs to interface > + to the VideoCore firmware. It has since moved to standard > + linux APIs. > + > + V4L2, DRM/KMS and Mesa are the APIs you should be using. Does Mesa now has a driver that supports all generations of the GPUs found in RaspberryPi, all the way up to the first generation RaspberryPi ? Thanks! Thomas
Thomas, On Wed Jul 24, 2024 at 6:21 PM CEST, Thomas Petazzoni wrote: > On Tue, 23 Jul 2024 23:20:11 +0200 > "Gaël PORTAY" <gael.portay@gmail.com> wrote: > > > + Important: The package is ancient and deprecated. > > + > > + It largely contains code using proprietary APIs to interface > > + to the VideoCore firmware. It has since moved to standard > > + linux APIs. > > + > > + V4L2, DRM/KMS and Mesa are the APIs you should be using. > > Does Mesa now has a driver that supports all generations of the GPUs > found in RaspberryPi, all the way up to the first generation > RaspberryPi ? > Well, I have no idea to be honest. All I know for now is that I was able to make it works on pi5 with qt5webengine (v3d is supposed to support pi4/5, vc4 is supposed to support the former pi); but mesa cannot be built on pi 1/zero for now as it requires support for Neon and BCM2835 has no support for it. I have planned to give a try anyway. But first, I am fixing the last issues with qt5webengine on ARM 32-bit using raspberrypi3_qt5we_defconfig and I am making the package more robust. I will sent the patch once I have the time to write the commit messages. And thank you very much for your fixes! Gaël
Hello Gaël, On Thu, 25 Jul 2024 11:53:45 +0200 Gaël PORTAY <gael.portay@gmail.com> wrote: > Well, I have no idea to be honest. > > All I know for now is that I was able to make it works on pi5 with > qt5webengine (v3d is supposed to support pi4/5, vc4 is supposed to > support the former pi); but mesa cannot be built on pi 1/zero for now as > it requires support for Neon and BCM2835 has no support for it. Well, then we need to figure out this before declaring rpi-userland as obsolete/deprecated. Indeed, not having support for the older RPi platforms is a problem. > But first, I am fixing the last issues with qt5webengine on ARM 32-bit > using raspberrypi3_qt5we_defconfig and I am making the package more > robust. I will sent the patch once I have the time to write the commit > messages. And thank you very much for your fixes! Yeah, I spent quite a lot of time during the recent Buildroot hackathon to fix the build of qt5webengine. For ARM 32-bit, it was building entirely all the way to point of linking QtWebEngine.so, where the linker was simply returning an error (non zero exit code), but without spitting any error message. I downgraded to an older version of binutils just to check, and exact same behavior. I ran "strace" on the linker, and it does write the libQtWebEngine.so file, apparently entirely and then at some point it decides something is wrong, and it deletes it and exits with an error. I couldn't figure out what was happening. Best regards, Thomas
Thomas, On Thu Jul 25, 2024 at 12:15 PM CEST, Thomas Petazzoni wrote: > Well, then we need to figure out this before declaring rpi-userland as > obsolete/deprecated. Indeed, not having support for the older RPi > platforms is a problem. > I agree, this is why I have limited my change to adding the message in the help message of the package. > Yeah, I spent quite a lot of time during the recent Buildroot hackathon > to fix the build of qt5webengine. For ARM 32-bit, it was building > entirely all the way to point of linking QtWebEngine.so, where the > linker was simply returning an error (non zero exit code), but without > spitting any error message. I downgraded to an older version of > binutils just to check, and exact same behavior. I ran "strace" on the > linker, and it does write the libQtWebEngine.so file, apparently > entirely and then at some point it decides something is wrong, and it > deletes it and exits with an error. I couldn't figure out what was > happening. > Testing the change in QtWebengine is pretty long... and even more on a laptop. I faces issues two issues. The first raises if the proprietary-codecs is set as the bundle ffmpeg has hardcoded configs; it builds the vp8 requiring thumb for arm (well maybe it builds vp8 even if the proprietary codecs is unset :/). However, qmake creates the arm flags given to the compiler itself. It guesses them from the $QMAKE and $QMAKE_CFLAGS set in the qmake.conf generated in qt5base; but buildroot does not set the -march, -mtune, -mfloat-abi, -mfpu -marm/-mthumb flags to it. So qmake is lost and builds any ARM 32-bis target with the default flags -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -marm. The flag -marm raise raises the error below for vp8.c (because it is a thumb mnemonic): {standard input}: Assembler messages: {standard input}:1119: Error: bad instruction `ldrhcs r0,[ip],#2' Note: chromium fails at configure if -feature-webengine-arm-thumb is forced to its command-line instead of failing afterward at build; so it is interresting to enforce it if CPU supports Thumb. Also, it is wrong for raspberry pi 1 (armv6). The second raises at linking blink: /home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: warning: /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o: missing .note.GNU-stack section implies executable stack /home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker collect2: error: ld returned 1 exit status Is that possible this is the issue you mentioned? Also, I have noticed that chromium checks for jpeg-turbo specific symbols if -feature-webengine-system-jpeg; raspberrypi uses libjpeg as jpeg-turbo cannot be built for this target, and qt5webengine fails at configure. Now, I am at the point where I can build every raspberry configuration for 32-bits but webengine does not necessarily run. I will send the patches separatly. Regards, Gaël
Hello, On Thu, 25 Jul 2024 13:05:27 +0200 Gaël PORTAY <gael.portay@gmail.com> wrote: > Testing the change in QtWebengine is pretty long... and even more on a > laptop. Oh yes, I have been using a very fast build server to do this debugging/investigation. > The first raises if the proprietary-codecs is set as the bundle ffmpeg > has hardcoded configs; it builds the vp8 requiring thumb for arm (well > maybe it builds vp8 even if the proprietary codecs is unset :/). > > However, qmake creates the arm flags given to the compiler itself. It > guesses them from the $QMAKE and $QMAKE_CFLAGS set in the qmake.conf > generated in qt5base; but buildroot does not set the -march, -mtune, > -mfloat-abi, -mfpu -marm/-mthumb flags to it. > > So qmake is lost and builds any ARM 32-bis target with the default flags > -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 > -marm. > > The flag -marm raise raises the error below for vp8.c (because it is a > thumb mnemonic): I highly doubt that the VP8 code is using Thumb-only instructions. > > {standard input}: Assembler messages: > {standard input}:1119: Error: bad instruction `ldrhcs r0,[ip],#2' I did a bit of experiment, but could not come to a conclusion. ldrh is definitely recognized, but not ldrhcs. And building in Thumb mode doesn't make any difference: thomas@windsurf:/tmp$ cat plop.S ldrhcs r0, [ip], #2 thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv6zk -c plop.S plop.S: Assembler messages: plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2' thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv6zk -mthumb -c plop.S plop.S: Assembler messages: plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2' thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv8-a -mthumb -c plop.S plop.S: Assembler messages: plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2' thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv8-a -c plop.S plop.S: Assembler messages: plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2' > Note: chromium fails at configure if -feature-webengine-arm-thumb is > forced to its command-line instead of failing afterward at build; so it > is interresting to enforce it if CPU supports Thumb. Not sure to understand this part. > Also, it is wrong for raspberry pi 1 (armv6). > > The second raises at linking blink: > > /home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: warning: /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o: missing .note.GNU-stack section implies executable stack > /home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker > collect2: error: ld returned 1 exit status > > Is that possible this is the issue you mentioned? This is the issue I mentioned indeed. The linker bails out with a non-zero error code, but does not show any error message. > Also, I have noticed that chromium checks for jpeg-turbo specific > symbols if -feature-webengine-system-jpeg; raspberrypi uses libjpeg as > jpeg-turbo cannot be built for this target, and qt5webengine fails at > configure. Dang, I am pretty sure I saw this, switched to jpeg-turbo, but I forgot to include it in my patch series. How come jpeg-turbo cannot be built for your target? As far as I can see, jpeg-turbo does not have any architecture dependency. Are you sure you didn't misread package/jpeg/Config.in? It uses jpeg-turbo as default if BR2_PACKAGE_JPEG_SIMD_SUPPORT, but it does not prevent from selecting jpeg-turbo if BR2_PACKAGE_JPEG_SIMD_SUPPORT is not true. Best regards, Thomas
Hello Thomas, On Thu Jul 25, 2024 at 4:59 PM CEST, Thomas Petazzoni wrote: > I did a bit of experiment, but could not come to a conclusion. ldrh is > definitely recognized, but not ldrhcs. And building in Thumb mode > doesn't make any difference: > > thomas@windsurf:/tmp$ cat plop.S > ldrhcs r0, [ip], #2 > > thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv6zk -c plop.S > plop.S: Assembler messages: > plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2' > > thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv6zk -mthumb -c plop.S > plop.S: Assembler messages: > plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2' > > thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv8-a -mthumb -c plop.S plop.S: Assembler messages: > plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2' > > thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv8-a -c plop.S > plop.S: Assembler messages: > plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2' > Oh, it appears I conclude to something inexact too fast. The vp8.o is compiled with the following command: /home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-gcc -MMD -MF obj/third_party/ffmpeg/ffmpeg_internal/vp8.o.d -DHAVE_AV_CONFIG_H -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DFFMPEG_CONFIGURATION=NULL -DCHROMIUM_NO_LOGGING -D_ISOC99_SOURCE -D_LARGEFILE_SOURCE -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -DCR_SYSROOT_HASH=c2e54f675b83a61301dcdb22e8e7a2b85c01d58c -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../3rdparty/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/arm -I../../3rdparty/chromium/third_party/ffmpeg -I../../3rdparty/chromium/third_party/ffmpeg/compat/atomics/gcc -Igen -I../../3rdparty/chromium -Igen -fPIC -Wno-deprecated-declarations -fomit-frame-pointer -w -std=c99 -pthread -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -marm -g0 -fvisibility=hidden -Wno-psabi -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -I/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/opus -std=gnu11 --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -c ../../3rdparty/chromium/third_party/ffmpeg/libavcodec/vp8.c -o obj/third_party/ffmpeg/ffmpeg_internal/vp8.o The compiler flag -marm is set; and if the -mthumb is used instead, the assembler errors gone and the Elf object is assembled. That is why I assumed badly the instruction is taken from the Thumb instruction set. Then I googled for ldrh (without the syntax fields c/e) + Thumb, I open the first response without reading too much and I closed the tab right after. ARM has introduced the Unified Assembler Language (since armv6t2 IIRC?), allowing mixing A32 and T32 instructions (ARM32 and Thumb32; not using the old Thumb 16-bit instructions). This is certainly why ffmpeg have the two options --enable-armv6 and --enable-armv6t2, and why the hardcoded configs in the bundled ffmpeg enables both for arm[1] and arm-neon[2]. Better to reread: https://developer.arm.com/documentation/ddi0406/cb/Appendixes/ARMv6-Differences/Instruction-set-support > > Note: chromium fails at configure if -feature-webengine-arm-thumb is > > forced to its command-line instead of failing afterward at build; so it > > is interresting to enforce it if CPU supports Thumb. > > Not sure to understand this part. > It the configure flag -feature-webengine-arm-thumb is forced at configure, the configure script fails with the error below because the condition is unmet[3]: WARNING: Thumb instruction set is required to build ffmpeg for QtWebEngine. ERROR: Feature 'webengine-arm-thumb' was enabled, but the pre-condition 'config.linux && arch.arm && tests.webengine-arm-thumb' failed. Otherwise, the build fails at compilation with the issue we are talking about. > > Also, it is wrong for raspberry pi 1 (armv6). > > > > The second raises at linking blink: > > > > /home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: warning: /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o: missing .note.GNU-stack section implies executable stack > > /home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker > > collect2: error: ld returned 1 exit status > > > > Is that possible this is the issue you mentioned? > > This is the issue I mentioned indeed. The linker bails out with a > non-zero error code, but does not show any error message. > Nice, I have sent a patch and added you in CC; see: https://patchwork.ozlabs.org/project/buildroot/patch/20240731110813.17489-1-gael.portay@rtone.fr/ I need the help of generate ninja warriors for it. > > Also, I have noticed that chromium checks for jpeg-turbo specific > > symbols if -feature-webengine-system-jpeg; raspberrypi uses libjpeg as > > jpeg-turbo cannot be built for this target, and qt5webengine fails at > > configure. > > Dang, I am pretty sure I saw this, switched to jpeg-turbo, but I forgot > to include it in my patch series. How come jpeg-turbo cannot be built > for your target? As far as I can see, jpeg-turbo does not have any > architecture dependency. Are you sure you didn't misread > package/jpeg/Config.in? It uses jpeg-turbo as default if > BR2_PACKAGE_JPEG_SIMD_SUPPORT, but it does not prevent from selecting > jpeg-turbo if BR2_PACKAGE_JPEG_SIMD_SUPPORT is not true. > Oh right, the choice is based on BR2_PACKAGE_JPEG_SIMD_SUPPORT that requires BR2_ARM_CPU_HAS_NEON (not available on armv6). > Best regards, > > Thomas Regards, Gaël [1]: https://github.com/qt/qtwebengine-chromium/blob/87-based/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/arm/config.h [2]: https://github.com/qt/qtwebengine-chromium/blob/87-based/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/arm-neon/config.h [3]: https://github.com/qt/qtwebengine/blob/v5.15.14-lts/src/buildtools/configure.json#L709-L713
diff --git a/package/rpi-userland/Config.in b/package/rpi-userland/Config.in index 4219bdb9c4..c39eb4598f 100644 --- a/package/rpi-userland/Config.in +++ b/package/rpi-userland/Config.in @@ -16,6 +16,17 @@ config BR2_PACKAGE_RPI_USERLAND mmal, GLESv2, vcos, openmaxil, vchiq_arm, bcm_host, WFC, OpenVG. + Important: The package is ancient and deprecated. + + It largely contains code using proprietary APIs to interface + to the VideoCore firmware. It has since moved to standard + linux APIs. + + V4L2, DRM/KMS and Mesa are the APIs you should be using. + + The few useful tools from here (dtoverlay, dtmerge, + vcmailbox, vcgencmd) have been moved to the package rpi-utils. + https://github.com/raspberrypi/userland/ if BR2_PACKAGE_RPI_USERLAND && BR2_arm
The package rpi-userland has been marked as ancient and deprecated[1]. This adds the message in its help. [1]: https://github.com/raspberrypi/userland/commit/96a7334ae9d5fc9db7ac92e59852377df63f1848 Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr> --- package/rpi-userland/Config.in | 11 +++++++++++ 1 file changed, 11 insertions(+)