[Buildroot] [PATCH 0/2] rpi-utils replaces rpi-userland

[Buildroot] [PATCH 0/2] rpi-utils replaces rpi-userland

[Gaël PORTAY]

Hello,

The package rpi-userland has been marked as ancient and deprecated[1]
nine-month ago.

This patch series adds its replacing package rpi-utils (first patch),
and it adds the message in the rpi-userland help (second patch).

Tell me if the package should go in the legacy thing.

[1]: https://github.com/raspberrypi/userland/commit/96a7334ae9d5fc9db7ac92e59852377df63f1848

Regards,
Gaël PORTAY (2):
  package/rpi-utils: new package
  package/rpi-userland: package is deprecated

 package/rpi-userland/Config.in   | 11 +++++++++++
 package/rpi-utils/Config.in      |  9 +++++++++
 package/rpi-utils/rpi-utils.hash |  3 +++
 package/rpi-utils/rpi-utils.mk   | 16 ++++++++++++++++
 4 files changed, 39 insertions(+)
 create mode 100644 package/rpi-utils/Config.in
 create mode 100644 package/rpi-utils/rpi-utils.hash
 create mode 100644 package/rpi-utils/rpi-utils.mk

-- 
2.45.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Gaël PORTAY]

The package rpi-userland has been marked as ancient and deprecated[1].

The useful tools (dtoverlay, dtmerge, vcmailbox, vcgencmd) were moved to
the repository rpi-utils since then.

This adds the new package rpi-utils at latest commit as there is no
tagged commit.

[1]: https://github.com/raspberrypi/userland/commit/96a7334ae9d5fc9db7ac92e59852377df63f1848

Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>
---
 package/rpi-utils/Config.in      |  9 +++++++++
 package/rpi-utils/rpi-utils.hash |  3 +++
 package/rpi-utils/rpi-utils.mk   | 16 ++++++++++++++++
 3 files changed, 28 insertions(+)
 create mode 100644 package/rpi-utils/Config.in
 create mode 100644 package/rpi-utils/rpi-utils.hash
 create mode 100644 package/rpi-utils/rpi-utils.mk

diff --git a/package/rpi-utils/Config.in b/package/rpi-utils/Config.in
new file mode 100644
index 0000000000..4ae82257a0
--- /dev/null
+++ b/package/rpi-utils/Config.in
@@ -0,0 +1,9 @@
+config BR2_PACKAGE_RPI_UTILS
+	bool "rpi-utils"
+	depends on !BR2_STATIC_LIBS # dtc
+	select BR2_PACKAGE_DTC
+	help
+	  A collection of scripts and simple applications for the
+	  Raspberry Pi.
+
+	  https://github.com/raspberrypi/utils/
diff --git a/package/rpi-utils/rpi-utils.hash b/package/rpi-utils/rpi-utils.hash
new file mode 100644
index 0000000000..a6612373b0
--- /dev/null
+++ b/package/rpi-utils/rpi-utils.hash
@@ -0,0 +1,3 @@
+# Locally computed
+sha256  c35932e501b43e5fb48cfc488aadc4a8bbceb0e9e6dafdf6c7cd2066b58acd61  rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789.tar.gz
+sha256  731da956431d1a7c5073e7ee5ebe01f54e359c5339310b32f0893c6fe6507d5a  LICENCE
diff --git a/package/rpi-utils/rpi-utils.mk b/package/rpi-utils/rpi-utils.mk
new file mode 100644
index 0000000000..1c74951e4a
--- /dev/null
+++ b/package/rpi-utils/rpi-utils.mk
@@ -0,0 +1,16 @@
+################################################################################
+#
+# rpi-utils
+#
+################################################################################
+
+RPI_UTILS_VERSION = a1d522f0f1b50858a44fac80523a2bd80098e789
+RPI_UTILS_SITE = $(call github,raspberrypi,utils,$(RPI_UTILS_VERSION))
+RPI_UTILS_LICENSE = BSD-3-Clause
+RPI_UTILS_LICENSE_FILES = LICENCE
+RPI_UTILS_INSTALL_STAGING = YES
+RPI_UTILS_DEPENDENCIES = dtc
+
+RPI_UTILS_CONF_OPTS = -DSTATIC=STATIC
+
+$(eval $(cmake-package))
-- 
2.45.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Thomas Petazzoni via buildroot]

Hello Gaël,

On Tue, 23 Jul 2024 23:20:10 +0200
"Gaël PORTAY" <gael.portay@gmail.com> wrote:

> The package rpi-userland has been marked as ancient and deprecated[1].
> 
> The useful tools (dtoverlay, dtmerge, vcmailbox, vcgencmd) were moved to
> the repository rpi-utils since then.
> 
> This adds the new package rpi-utils at latest commit as there is no
> tagged commit.
> 
> [1]: https://github.com/raspberrypi/userland/commit/96a7334ae9d5fc9db7ac92e59852377df63f1848
> 
> Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>

Thanks for the patch. See some comments below.

> ---
>  package/rpi-utils/Config.in      |  9 +++++++++
>  package/rpi-utils/rpi-utils.hash |  3 +++
>  package/rpi-utils/rpi-utils.mk   | 16 ++++++++++++++++
>  3 files changed, 28 insertions(+)

Please add an entry in the DEVELOPERS file for this new package.

>  create mode 100644 package/rpi-utils/Config.in
>  create mode 100644 package/rpi-utils/rpi-utils.hash
>  create mode 100644 package/rpi-utils/rpi-utils.mk
> 
> diff --git a/package/rpi-utils/Config.in b/package/rpi-utils/Config.in
> new file mode 100644
> index 0000000000..4ae82257a0
> --- /dev/null
> +++ b/package/rpi-utils/Config.in
> @@ -0,0 +1,9 @@
> +config BR2_PACKAGE_RPI_UTILS
> +	bool "rpi-utils"
> +	depends on !BR2_STATIC_LIBS # dtc
> +	select BR2_PACKAGE_DTC
> +	help
> +	  A collection of scripts and simple applications for the
> +	  Raspberry Pi.
> +
> +	  https://github.com/raspberrypi/utils/

Please add a Config.in comment:

comment "rpi-utils needs a toolchain w/ dynamic library"
	depends on BR2_STATIC_LIBS

also, this Config.in file is not included anywhere, so things cannot
work.


> diff --git a/package/rpi-utils/rpi-utils.mk b/package/rpi-utils/rpi-utils.mk
> new file mode 100644
> index 0000000000..1c74951e4a
> --- /dev/null
> +++ b/package/rpi-utils/rpi-utils.mk
> @@ -0,0 +1,16 @@
> +################################################################################
> +#
> +# rpi-utils
> +#
> +################################################################################
> +
> +RPI_UTILS_VERSION = a1d522f0f1b50858a44fac80523a2bd80098e789
> +RPI_UTILS_SITE = $(call github,raspberrypi,utils,$(RPI_UTILS_VERSION))
> +RPI_UTILS_LICENSE = BSD-3-Clause
> +RPI_UTILS_LICENSE_FILES = LICENCE
> +RPI_UTILS_INSTALL_STAGING = YES
> +RPI_UTILS_DEPENDENCIES = dtc
> +
> +RPI_UTILS_CONF_OPTS = -DSTATIC=STATIC

What is this thing doing? It seems a bit odd.

Also, could you give a test to this package using the ./utils/test-pkg
utility?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Gaël PORTAY]

Hello Thomas,

On Wed Jul 24, 2024 at 6:21 PM CEST, Thomas Petazzoni wrote:
> > diff --git a/package/rpi-utils/rpi-utils.mk b/package/rpi-utils/rpi-utils.mk
> > new file mode 100644
> > index 0000000000..1c74951e4a
> > --- /dev/null
> > +++ b/package/rpi-utils/rpi-utils.mk
> > @@ -0,0 +1,16 @@
> > +################################################################################
> > +#
> > +# rpi-utils
> > +#
> > +################################################################################
> > +
> > +RPI_UTILS_VERSION = a1d522f0f1b50858a44fac80523a2bd80098e789
> > +RPI_UTILS_SITE = $(call github,raspberrypi,utils,$(RPI_UTILS_VERSION))
> > +RPI_UTILS_LICENSE = BSD-3-Clause
> > +RPI_UTILS_LICENSE_FILES = LICENCE
> > +RPI_UTILS_INSTALL_STAGING = YES
> > +RPI_UTILS_DEPENDENCIES = dtc
> > +
> > +RPI_UTILS_CONF_OPTS = -DSTATIC=STATIC
>
> What is this thing doing? It seems a bit odd.
>

The CMakeLists.txt of the dtmerge utils creates an internal library by
doing[1]:

	add_library (dtovl ${STATIC} dtoverlay.c)

According to online documentation of cmake[2]:

	add_library(<name> [<type>] [EXCLUDE_FROM_ALL] <sources>...)

		Add a library target called <name> to be built from the
		source files listed in the command invocation.

		The optional <type> specifies the type of library to be
		created:

			STATIC An archive of object files for use when
			       linking other targets.

			SHARED A dynamic library that may be linked by
			       other targets and loaded at runtime.

			MODULE A plugin that may not be linked by other
			       targets, but may be dynamically loaded at
			       runtime using dlopen-like functionality.

		If no <type> is given the default is STATIC or SHARED
		based on the value of the BUILD_SHARED_LIBS variable.

In rpi-utils, the optional type is controlled thanks to the environment
variable ${STATIC}; it is unset by default. It is expected cmake builds
a STATIC library; but...

cmake creates a STATIC library if configuring the project for my host
system (Arch Linux).

And, cmake creates a SHARED library through buildroot (maybe because of
BUILD_SHARED_LIBS?).

The file CMakeLists.txt does not install the shared library, and it
results in a run-time issue saying the library libdtovl.so is not found.

So, I have decided to ensure the library is statically build by setting
the environment variable STATIC to STATIC.

Do you prefer I install the shared library from an install hook or
whatsover?

> Also, could you give a test to this package using the ./utils/test-pkg
> utility?
>

Well, I wanted to give a try before sending the package, but the
toolchain all skipped.

Give me some time to test it.

> Thanks a lot!
>
> Thomas

Gaël

[1]: https://github.com/raspberrypi/utils/blob/master/dtmerge/CMakeLists.txt#L14
[2]: https://cmake.org/cmake/help/latest/command/add_library.html
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Thomas Petazzoni via buildroot]

Hello,

On Thu, 25 Jul 2024 10:05:54 +0200
Gaël PORTAY <gael.portay@gmail.com> wrote:

> The CMakeLists.txt of the dtmerge utils creates an internal library by
> doing[1]:
> 
> 	add_library (dtovl ${STATIC} dtoverlay.c)
> 
> According to online documentation of cmake[2]:
> 
> 	add_library(<name> [<type>] [EXCLUDE_FROM_ALL] <sources>...)
> 
> 		Add a library target called <name> to be built from the
> 		source files listed in the command invocation.
> 
> 		The optional <type> specifies the type of library to be
> 		created:
> 
> 			STATIC An archive of object files for use when
> 			       linking other targets.
> 
> 			SHARED A dynamic library that may be linked by
> 			       other targets and loaded at runtime.
> 
> 			MODULE A plugin that may not be linked by other
> 			       targets, but may be dynamically loaded at
> 			       runtime using dlopen-like functionality.
> 
> 		If no <type> is given the default is STATIC or SHARED
> 		based on the value of the BUILD_SHARED_LIBS variable.
> 
> In rpi-utils, the optional type is controlled thanks to the environment
> variable ${STATIC}; it is unset by default. It is expected cmake builds
> a STATIC library; but...
> 
> cmake creates a STATIC library if configuring the project for my host
> system (Arch Linux).
> 
> And, cmake creates a SHARED library through buildroot (maybe because of
> BUILD_SHARED_LIBS?).
> 
> The file CMakeLists.txt does not install the shared library, and it
> results in a run-time issue saying the library libdtovl.so is not found.
> 
> So, I have decided to ensure the library is statically build by setting
> the environment variable STATIC to STATIC.
> 
> Do you prefer I install the shared library from an install hook or
> whatsover?

Meh, this is really crappy stuff from rpi-utils's CMakeLists.txt. I'd
say keep the -DSTATIC=STATIC as you had, but with a comment above that
explains what's going on.

> Well, I wanted to give a try before sending the package, but the
> toolchain all skipped.

Well, your patch was not including package/rpi-utils/Config.in, so the
option BR2_PACKAGE_RPI_UTILS does not exist. Perhaps why it gets
skipped?

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Gaël PORTAY]

Thomas,

On Thu Jul 25, 2024 at 10:10 AM CEST, Thomas Petazzoni wrote:
> Well, your patch was not including package/rpi-utils/Config.in, so the
> option BR2_PACKAGE_RPI_UTILS does not exist. Perhaps why it gets
> skipped?
>

So there is a build issue with the uclibc toolchains because of
reallocarray().

	gportay@archlinux ~/src/buildroot $ utils/test-pkg -p rpi-utils
	                    bootlin-armv5-uclibc [1/6]: FAILED
	                     bootlin-armv7-glibc [2/6]: OK
	                   bootlin-armv7m-uclibc [3/6]: SKIPPED
	                     bootlin-x86-64-musl [4/6]: OK
	                      br-arm-full-static [5/6]: SKIPPED
	                             arm-aarch64 [6/6]: OK

See:

	/home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/pinctrl/pinctrl.c: In function ‘do_gpio_poll_add’:
	/home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/pinctrl/pinctrl.c:268:18: error: implicit declaration of function ‘reallocarray’ [-Werror=implicit-function-declaration]
	  268 |     poll_gpios = reallocarray(poll_gpios, num_poll_gpios + 1,
	      |                  ^~~~~~~~~~~~
	/home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/pinctrl/pinctrl.c:268:16: error: assignment to ‘struct poll_gpio_state *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
	  268 |     poll_gpios = reallocarray(poll_gpios, num_poll_gpios + 1,
	      |                ^
	In function ‘gencmd’,
	    inlined from ‘main’ at /home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/vcgencmd/vcgencmd.c:152:14:
	/home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/vcgencmd/vcgencmd.c:109:4: warning: ‘strncat’ specified bound 1024 equals destination size [-Wstringop-overflow=]
	  109 |    strncat (  ~~~~~~~~~~

Do you want me to make a patch? or works around for it using Kconfig?

	config BR2_PACKAGE_RPI_UTILS
		(...)
		depends on !BR2_TOOLCHAIN_USES_UCLIBC # no reallocarray

	comment "rpi-utils needs a glibc or musl toolchain w/ threads"
	        depends on BR2_TOOLCHAIN_USES_UCLIBC

Regards,
Gaël
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Waldemar Brodkorb]

Hi,
Gaël PORTAY wrote,

> Thomas,
> 
> On Thu Jul 25, 2024 at 10:10 AM CEST, Thomas Petazzoni wrote:
> > Well, your patch was not including package/rpi-utils/Config.in, so the
> > option BR2_PACKAGE_RPI_UTILS does not exist. Perhaps why it gets
> > skipped?
> >
> 
> So there is a build issue with the uclibc toolchains because of
> reallocarray().
> 
> 	gportay@archlinux ~/src/buildroot $ utils/test-pkg -p rpi-utils
> 	                    bootlin-armv5-uclibc [1/6]: FAILED
> 	                     bootlin-armv7-glibc [2/6]: OK
> 	                   bootlin-armv7m-uclibc [3/6]: SKIPPED
> 	                     bootlin-x86-64-musl [4/6]: OK
> 	                      br-arm-full-static [5/6]: SKIPPED
> 	                             arm-aarch64 [6/6]: OK
> 
> See:
> 
> 	/home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/pinctrl/pinctrl.c: In function ‘do_gpio_poll_add’:
> 	/home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/pinctrl/pinctrl.c:268:18: error: implicit declaration of function ‘reallocarray’ [-Werror=implicit-function-declaration]
> 	  268 |     poll_gpios = reallocarray(poll_gpios, num_poll_gpios + 1,
> 	      |                  ^~~~~~~~~~~~
> 	/home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/pinctrl/pinctrl.c:268:16: error: assignment to ‘struct poll_gpio_state *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
> 	  268 |     poll_gpios = reallocarray(poll_gpios, num_poll_gpios + 1,
> 	      |                ^
> 	In function ‘gencmd’,
> 	    inlined from ‘main’ at /home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/vcgencmd/vcgencmd.c:152:14:
> 	/home/gportay/br-test-pkg/bootlin-armv5-uclibc/build/rpi-utils-a1d522f0f1b50858a44fac80523a2bd80098e789/vcgencmd/vcgencmd.c:109:4: warning: ‘strncat’ specified bound 1024 equals destination size [-Wstringop-overflow=]
> 	  109 |    strncat (  ~~~~~~~~~~
> 
> Do you want me to make a patch? or works around for it using Kconfig?
> 
> 	config BR2_PACKAGE_RPI_UTILS
> 		(...)
> 		depends on !BR2_TOOLCHAIN_USES_UCLIBC # no reallocarray
> 
> 	comment "rpi-utils needs a glibc or musl toolchain w/ threads"
> 	        depends on BR2_TOOLCHAIN_USES_UCLIBC
> 
reallocarray was added in uClibc-ng 1.0.47. uClibc-ng 1.0.48 is in
Buildroot 2024.05.1. 
@Thomas: Would it be possible to rebuild bootlin toolchains?

best regards
 Waldemar
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Thomas Petazzoni via buildroot]

On Thu, 25 Jul 2024 12:05:59 +0200
Waldemar Brodkorb <wbx@openadk.org> wrote:

> reallocarray was added in uClibc-ng 1.0.47. uClibc-ng 1.0.48 is in
> Buildroot 2024.05.1. 
> @Thomas: Would it be possible to rebuild bootlin toolchains?

Yep, planned. I have actually already restarted a build of all
tolchains, but got some failures that I need to investigate and fix.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Gaël PORTAY]

Waldemar,

On Thu Jul 25, 2024 at 12:05 PM CEST, Waldemar Brodkorb wrote:
> reallocarray was added in uClibc-ng 1.0.47. uClibc-ng 1.0.48 is in
> Buildroot 2024.05.1. 
> @Thomas: Would it be possible to rebuild bootlin toolchains?
>

Oh cool, I have (just) resent a version with the filtering on uclibc. I
will remove it in v3.

Thanks!
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/2] package/rpi-userland: package is deprecated

[Gaël PORTAY]

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(+)

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
-- 
2.45.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/rpi-userland: package is deprecated

[Thomas Petazzoni via buildroot]

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 Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/rpi-userland: package is deprecated

[Gaël PORTAY]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/rpi-userland: package is deprecated

[Thomas Petazzoni via buildroot]

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 Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/rpi-userland: package is deprecated

[Gaël PORTAY]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/rpi-userland: package is deprecated

[Thomas Petazzoni via buildroot]

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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/rpi-userland: package is deprecated

[Gaël PORTAY]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot