We are trying to enable the graphics hardware subsystem on the Raspberry Pi 4. This driver lives in mesa. The current Centos mesa.spec file does not enable the V3D Driver we need. Here are the steps I am going through to build the driver and integrate it into the meta-rpm build.

mesa.spec changes

The mesa.spec file has conditionals that enable differerent drivers for different situations. The Raspberry PI 4 is has an aarch64 processor and thus the V3D drivers should only be built for that chipset. That code looks like this:

%ifarch %{arm} aarch64
%define with_xa        1
%define with_v3d       1
%endif

Once that flag is enabled, we need to use it in the compile step. To do that, add it to the end of the gallium drivers:

%if 0%{?with_hardware}
  -Dgallium-drivers=swrast%{?with_iris:,iris},virgl,nouveau%{?with_vmware:,svga},radeonsi,r600%{?with_freedreno:,freedreno}%{?with_etnaviv:,etnaviv}%{?with_tegra:,tegra}%{?with_vc4:,vc4}%{?with_kmsro:,kmsro}%{?with_v3d:,v3d} \
%else

If we only go this far, the rpmbuild process will error out, as we are now generating an artifact that is not accounted for in any of the packages.
Our current thinking is that this driver should be included in the dri-drivers RPM. To include it there, add it to the %files dri-drivers section

%if 0%{?with_vmware}
%{_libdir}/dri/vmwgfx_dri.so
%endif
#{_libdir}/dri/nouveau_drv_video.so
#{_libdir}/dri/r600_drv_video.so
#{_libdir}/dri/radeonsi_drv_video.so
%endif
%{_libdir}/dri/kms_swrast_dri.so
%{_libdir}/dri/swrast_dri.so
%{_libdir}/dri/virtio_gpu_dri.so
%if 0%{?with_v3d}
%{_libdir}/dri/v3d_dri.so
%endif

To ensure I know the difference between the RPM I am building and the source, I modified the version string to have tyt in it, like this:

Release:        2%{?rctag:.%{rctag}}.tyt

With these changes, we can build the rpms using the rpmbuild tool. To get all of the dependencies, use the yum-builddep tool as root.

sudo yum-builddep /home/ayoung/rpmbuild/SPECS/libdrm.spec

And, of course, build the rpms with

EDIT: Previously I was building using rpmbuild. Now I use Mock, as the Stream RPM set is different enough from the RHEL 8 that things will not work. Replace the below command….

 rpmbuild -ba $HOME/rpmbuild/SPECS/mesa.spec

With this:

mock -r centos-stream-8-aarch64  rebuild ~/rpmbuild/SRPMS/mesa-20.3.3-2.tyt.src.rpm

This will produce a bunch of RPMs in the subdir $HOME/rpmbuild/rpms/aarch64 subdir.

Note that the build process when done this way makes use of the RPMs installed on the base system. Since the Mesa subsystem has some changes, i found it necessary to install certain RPMs from Centos Stream directly, or rpmbuild complained of incompatible versions.
Here is what I installed last time:

yum install http://mirror.centos.org/centos/8-stream/AppStream/aarch64/os/Packages/libglvnd-1.3.2-1.el8.aarch64.rpm http://mirror.centos.org/centos/8-stream/AppStream/aarch64/os/Packages/libglvnd-devel-1.3.2-1.el8.aarch64.rpm http://mirror.centos.org/centos/8-stream/AppStream/aarch64/os/Packages/libglvnd-core-devel-1.3.2-1.el8.aarch64.rpm http://mirror.centos.org/centos/8-stream/AppStream/aarch64/os/Packages/libglvnd-egl-1.3.2-1.el8.aarch64.rpm http://mirror.centos.org/centos/8-stream/AppStream/aarch64/os/Packages/libglvnd-gles-1.3.2-1.el8.aarch64.rpm http://mirror.centos.org/centos/8-stream/AppStream/aarch64/os/Packages/libglvnd-glx-1.3.2-1.el8.aarch64.rpm http://mirror.centos.org/centos/8-stream/AppStream/aarch64/os/Packages/libglvnd-opengl-1.3.2-1.el8.aarch64.rpm

repository generation

Once the rpmbuild process is complete, I need to make the rpms available for building. I could do this in place on the system, but then other people cannot test them. So, instead, I am hosting a small repo on Fedora People. This is not intened to be a long lived repo, even in the nature of a COPR, but rather an interim step to sort out the RPM changes required.

Since my build machine does not have my private key on it, I need to pull the RPMS onto my desktop. I could build the repo either before or after I do this, but I tend to do it after. This allows me to keep the repo artifacts out of the rpmbuild tree on my build host. If I have other RPMS in my rpmbuild/RPMS/aarch64 subdir, I can leave them there without having them pollute the repo.

scp 10.19.241.44:rpmbuild/RPMS/aarch64/* /home/ayoung/Documents/pi
scp 10.19.241.44:rpmbuild/SPECS/mesa.spec /home/ayoung/Documents/pi
cd /home/ayoung/Documents/pi
createrepo .
rsync -a /home/ayoung/Documents/pi admiyo@admiyo.fedorapeople.org:public_html/

The one step the leaves out is where I manually go to the fedorapeople machine and remove the old content. Not strictly necessary to be this manual, but I like to keep a hand on that process for now.

The repo is then exposed here:

Here is a sample .repo file that consumes it;

[fedorapeople]
name=fedorapeople hosted repo of R Pi specific files
baseurl=https://admiyo.fedorapeople.org/pi/
#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever&arch=$basearch&infra=$infra&content=$contentdir
enabled=1
gpgcheck=1
countme=1
priority = 50
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8

That file can be used to test the repo, and also will be used in the next step.

recipe update

The recipes in the meta-rpm project are automatically generated from dnf/yum repository meta data. In order to use the repository posted above, the recipes need to be regenerated using an the .repo file from the previous section.

$ git status
On branch centos-stream
Your branch is up to date with 'origin/centos-stream'.
 
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	meta-rpm/recipes-rpms/overrides/dnf/repos/fedorapeople.repo

With this file in place, run make in the top level directory of your meta-rpm git repository.

To confirm that the generated recipes have the right repository, look in the file meta-rpm/meta-rpm/recipes-rpms/generated/mesa.bb and check that the URLS look like thisL

https://admiyo.fedorapeople.org/pi/mesa-vulkan-drivers-debuginfo-20.3.3-2.tyt.aarch64.rpm 72fc207edfbcdbb5c32714342bd073500402082f41caf1b2546b229fa167a42e"

As of now, running bitbake rpmbased-desktop-image on the centos-streams branch will fail, but I don’t think it is based on these changes. I’ll update once I know what is going on, but for now, I want to post this to share the work I’ve done.