The Mali G610 found in the RK3588(S) SoC still requires a blob coming
from a linux-firmware package to work.
Therefore, recommend that package when building mesa for rk3588(s).
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Let's assume most Rockchip SoCs to come will be based on an Arm Mali GPU
supported by Panfrost so let's always add panfrost drivers to mesa.
Make the Mali-400/450 SoC such as RK3066, RK3188 and RK3328 use lima
instead.
Finally, do not add any mesa mali (panfrost or lima) driver for GPU-less
SoC like RK3308.
This means we will not need to touch this recipe every time we add support
for a new SoC with GPU supported by Mesa Panfrost.
This also **almost** brings support for the GPU found on RK3588.
Note that some GPUs (gen10; Valhall; Panthor; like on RK3588) still
require additional firmware (CSFFW).
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
lima is the open-source implementation for the GPU found on RK3188,
the Mali 400, so let's enable it for RK3188 boards by default.
Not tested.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
lima is the open-source implementation for the GPU found on RK3066,
the Mali 400, so let's enable it for RK3066 boards by default.
Not tested.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Panfrost mesa drivers do not compile without libclc support anymore, I
assume since commit 20970bcd9652 ("panfrost: Add base of OpenCL C
infrastructure") merged in 25.1.0.
So this adds the missing libclc PACKAGECONFIG to Panfrost-supported
SoCs.
Note that mesa recipe in OE-Core will be updated to not build panfrost
if libclc PACKAGECONFIG is missing.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Mesa has dropped[1] support for a separate kmsro option to the
gallium-drivers.
It is therefore not necessary to pass it to PACKAGECONFIG anymore,
especially since the kmsro PACKAGECONFIG doesn't exit in the mesa recipe
anymore[2].
[1] 89863a050b
[2] https://git.openembedded.org/openembedded-core/commit/?id=3d9ec347e651e05d0246a8723ca4038bb1f5b765
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
oe-core has completely re-written the fitImage support starting roughly at
commit [1], update meta-rockchip to match.
Most of the MACHINEs in meta-rockchip use a fitImage for the kernel, but
some don't. Create a boolean variable (RK_KERNEL_FITIMAGE), enabled by
default, to keep track of which ones do and which ones don't. Use this
variable to decide how to configure various image-related fields.
Build tested with all meta-rockchip MACHINEs both with and without RAUC.
Run tested on the following with RAUC configured:
- nanopi-m4b
- nanopi-r2s
- radxa-zero-3e
- rock-pi-4b
- rock-pi-e
- rock-pi-s
Run tested on the following without RAUC:
- radxa-zero-3e
- rock-pi-e
- rock-pi-s
[1] oe-core: 3442d9297dca ("oe-selftest: fitimage: test external dtb")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Since commit 46480a5e6674 ("insane/do_qa_unpack: add checks that ensure
S is set correctly") it is not allowed to have S refer to WORKDIR
directly and we should instead use UNPACKDIR.
The default path of S is ${UNPACKDIR}/${BP} which is where the git
fetcher will unpack the sources. However, we want to go into the tools/
directory, hence S being ${UNPACKDIR}/${BP}/tools now.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
S = "${WORKDIR}/git" is now implied when using the git fetcher and since
commit 46480a5e6674 ("insane/do_qa_unpack: add checks that ensure S is
set correctly") the build fails if it is set to such a value.
Therefore, let's remove the line in rkbin to make the build of those
recipes successful again.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The two patches being carried in this layer for tf-a are no longer required
and can be dropped since they have been merged upstream.
upstream tf-a: https://review.trustedfirmware.org/TF-A/trusted-firmware-a.git
upstream tf-a: f86c230ab02c ("fix(rk3399): dram: Fix build with gcc 11")
upstream tf-a: 7f25d3cc7823 ("fix(rockchip): pmu: Do not mark already defined functions as weak")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Make setting the PACKAGE_ARCH occur only when the user has enabled the
rk-rauc-demo feature.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
do_deploy is now identical for all recipes including rockchip-rkbin.inc
so let's simply move it to the .inc file to avoid duplication.
While at it, RKBIN_BINDIR is also identical so can also be moved to the
.inc, so do it.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The do_deploy task is essentially the same for all SoCs, install a file
from a specific path to another one.
No magic involved, so let's rather have one generic do_deploy task. For
this to work nicely, we check that all necessary variables are set and
notify the developer otherwise. This may be useful whenever a new SoC
will be supported by this recipe.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The do_deploy task is essentially the same for all SoCs, install a file
from a specific path to another one.
No magic involved, so let's rather have one generic do_deploy task. For
this to work nicely, we check that all necessary variables are set and
notify the developer otherwise. This may be useful whenever a new SoC
will be supported by this recipe.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The do_deploy task is essentially the same for all SoCs, install a file
from a specific path to another one.
No magic involved, so let's rather have one generic do_deploy task. For
this to work nicely, we check that all necessary variables are set and
notify the developer otherwise. This may be useful whenever a new SoC
will be supported by this recipe.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Rockchip provides a tool to customize the DDR bin blob which can prove
to be extremely useful, for example if your HW doesn't follow the HW
reference design and uses a different UART controller or UART mux for
the serial console, or use a different baudrate.
If RKBIN_DDR_RECONFIGURE is set to 1 for a machine, a ddrbin_params.txt
needs to be provided for said machine and ddrbin_tool.py will be run
against it to generate a new custom binary with the desired config.
Note that future implementations may allow to provide configuration
through a different mechanism than a simple and difficult to
maintain/modify file. E.g. this doesn't really work well when one wants
to have this in sync with SERIAL_CONSOLES for example. But that may be
much harder to support as the serial controller index in
SERIAL_CONSOLES does not necessarily match the hardware index expected
by ddrbin_params.txt. It also doesn't provide the UART mux.
In any case, I believe this is a decent start at allowing customization
of the DDR bin blob without having to provide a blob directly in-tree.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This will allow us to use tools from rkbin repo destined to be used on
the host in recipes for the target. For example, ddrbin_tool.py which
is used to modify the configuration of the DDR bin blob.
This has limited usefulness for ddrbin_tool.py as it is a python script
with no external dependencies and could be run directly from
rockchip-ddr-bin recipe. However, this is required so we can decouple
the version of the git repo used for rockchip-ddr-bin DDR bin blob from
the version of the git repo used for ddrbin_tool.py (which is very
recent).
This recipe will be used in a later commit to modify the DDR bin blob if
need be.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This will also allow us to generate an SoC-agnostic do_deploy instead of
duplicating it for each SoC.
Additionally, it allows users to pick a different name for the deployed
binary.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This will be used in a later commit when an SoC-agnostic do_configure will
call ddrbin_tool.py with the DDR bin blob as input.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Since this bbappend is modifying the rauc config file with a MACHINE-specific
search-and-replace, the architecture setting of the package needs to be
MACHINE-specific as well. Otherwise if multiple images are built for the same
SoC, the sstate mechanism will use the first-built SoC copy of the
rauc/system.conf file, which may or may not match this device's MACHINE
setting.
At runtime this leads to compatible mismatch issues:
# rauc install <bundle>
...
LastError: Compatible mismatch: Expected 'nanopi-r2s' but bundle manifest has 'rock-pi-e'
These errors can be worked around by using the "--ignore-compatible" cmdline
switch to the "rauc install" command. Or can be fixed by updating the
on-device /etc/rauc/system.conf file and restarting the rauc.service systemd
service unit. This patch, however, is the more correct, build-time, fix,
rather than having to fix the issue at run-time.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2.12.0 already has this patch, see 52cdebbcc5d1 ("fix(rockchip): fix
"unexpected token" error with clang"), so let's remove it.
Build-tested-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Upstream U-Boot 2024.10 (the latest release supported by Yocto) has support
for radxa-zero-3{e|w}. Therefore switch away from the fork where the initial
U-Boot development for this board had been added.
Reported-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
Reviewed-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
Signed-off-by: Trevor Woerner <trevor.woerner@amd.com>
The next patch (involving changes for radxa-zero-3) only applies to master
(walnascar) and not styhead.
Signed-off-by: Trevor Woerner <trevor.woerner@amd.com>
The radxa-zero-3{e|w} devices are not supported in the current yocto kernel,
but they are supported in the yocto-dev kernel. Switch to yocto-dev until
support is available in the yocto kernel.
Reported-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
Reviewed-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
Signed-off-by: Trevor Woerner <trevor.woerner@amd.com>
When the rk-u-boot-env feature was implemented, in order for it to work the
build needed a version of U-Boot that was slightly newer than 2024.04 (the
current release supported by Yocto at that time). Now that 2024.10 is out,
remove the SRCREV pin since the necessary code is now part of this release.
Run tested both with and without RK_RAUC_DEMO on:
nanopi-m4-2gb
nanopi-m4b
nanopi-r2s
rock-3a
rock-5a
rock-5b
rock-pi-4b
rock-pi-e
rock-pi-s
rock64
Signed-off-by: Trevor Woerner <trevor.woerner@amd.com>
This seems to be fixing random RCU stalls, system hangs or resets while
running upstream Linux kernel on RK3588 boards.
License-Update: Fixing typos c.f. 385bf9f1700c ("license: typo fix")
Before and after run-tested on:
rk3308 rock-pi-s (with and without RKBIN_RK3308_LATEST)
rk3566 radxa-zero-3e
rk3568 rock-3a
rk3588 rock-5a
rk3588s rock-5b
Run-tested-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
By using variables to give the path where to find the file to install,
it is easier for users to have a different SRCREV for their own machine.
Additionally, because glob patterns are now not used by default, it is
guaranteed only to match a single file.
The glob pattern for rk3308 has been hardcoded with the only file that
matches in the rkbin git repository at the currently used commit.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
A PREFERRED_PROVIDER entry was missed for rk3308 builds:
NOTE: Multiple providers are available for trusted-firmware-a (rk3308-rkbin, rockchip-rkbin-tf-a)
Consider defining a PREFERRED_PROVIDER entry to match trusted-firmware-a
This allows the RKBIN_RK3308_LATEST knob to work in all cases again.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <trevor.woerner@amd.com>
Upstream TF-A > 2.11 (no release available yet) has initial support for
the RK3588 (and thus RK3588S).
This was boot tested on an RK3588 Jaguar, the modified baudrate is taken
into account as well.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Upstream TF-A > 2.11 (no release available yet) has initial support for
the RK3566 and RK3568. They both share the same code base.
This was not tested as I do not own RK356x boards.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Nothing needs to be done for rkbin recipes except taking a file and
putting in do_deploy, therefore there's no need for the default typical
DEPENDS dependencies to be pulled in. As such, set INHIBIT_DEFAULT_DEPS
to avoid having them pulled in.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Having one common recipe for optee-os, TF-A and DDR init blobs coming
from rkbin is nice for maintenance but it doesn't allow for having e.g.
TF-A come from another recipe and optee-os and DDR init from this one.
Now that upstream TF-A has initial support for RK356x and RK3588, but
there's still no open OP-TEE OS or DDR init, it'd be nice to allow users
to have upstream TF-A.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
In future commits, the rkbin recipe will be split into multiple ones:
- one for TPL DRAM init
- one for TF-A blob (BL31)
- one for OP-TEE OS blob (BL32)
Since in most cases those three blobs will be coming from the exact same
commit hash and repo, let's have a .inc so some duplication can be
avoided.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The rauc demo implementation provided by this layer uses ext4-formatted
partitions. Therefore the tool required to format ext4 partitions is required
otherwise the repartitioning will fail.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
oe-core recently bumped linux-yocto to v6.10.8 which already contains this
patch to fix the pinctrl driver for the rk3328-based Rockchip SoCs (which
enables SPI to work again).
oe-core: 48ac41fdc02c ("linux-yocto/6.10: update to v6.10.8")
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
v4l2codecs is the gstreamer plugin for V4L2 stateless video hardware
decoding. The Rockchip SoCs that have a VPU all seems to be based on
Hantro, RKVDEC or RKVDECv2, all stateless encoding/decoding VPUs.
Therefore, let's enable VPU decoding in Gstreamer whenever possible,
when the SoC supports it.
PX30, RK3066, RK3188, RK3288, RK3328, RK3399, RK356x and RK3588(s) all
have at least one Hantro VPU.
RK3328, RK3399, RK356x and RK3588(s) all have at least one
RKVDEC/RKVDECv2 VPU (though not necessarily supported in the upstream
kernel just yet).
=== PX30
Tested on PX30 Ringneck with with Haikou+Haikou Video Demo adapter:
$ gst-launch-1.0 filesrc location=$FILE ! parsebin ! v4l2slh264dec ! waylandsink
with FILE storing the path to any h264 file, e.g.
https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_h264.movhttps://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov
Needed packages are:
- weston
- gstreamer1.0-plugins-bad (for waylandsink and v4l2slh264dec)
- gstreamer1.0-plugins-base (for parsebin)
A few frames are dropped every other second for 1080p but otherwise
smooth.
=== RK3399
Tested on RK3399 Puma with Haikou:
$ gst-launch-1.0 filesrc location=$FILE ! parsebin ! v4l2slh264dec ! waylandsink
with FILE storing the path to any h264 file, e.g.
https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.movhttps://download.blender.org/demo/movies/BBB/bbb_sunflower_2160p_30fps_normal.mp4.zip
Needed packages are:
- weston
- gstreamer1.0-plugins-bad (for waylandsink and v4l2codecs)
- gstreamer1.0-plugins-base (for parsebin)
=== RK3588
Tested on a RK3588 Tiger with Haikou+Haikou Video Demo adapter - on a
downstream v6.6 (upstream-based, not Rockchip BSP-based) with DSI
patches - :
$ gst-launch-1.0 filesrc location=$FILE ! parsebin ! v4l2slav1dec ! fakesink
with FILE storing the path to any AV1 file, e.g.
http://download.opencontent.netflix.com.s3.amazonaws.com/AV1/cmaf/spark-8b-59.94fps/spark_606kbps_432p.mp4https://woolyss.com/f/av1-nosound-chimera.mp4https://woolyss.com/f/av1-opus-sita.webm
Needed packages are:
- gstreamer1.0-plugins-bad (for fakesink and v4l2slav1dec)
- gstreamer1.0-plugins-base (for parsebin)
For some reason though, waylandsink is very choppy. Combining
fpsdisplaysink with fakesink shows a ~60fps when decoding the 432p file,
~24fps for the two others.
Note that 10b-depth isn't supported (at least in my setup).
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The kernel needs a couple configuration tweaks in order to work with RAUC, and
the default upstream kernel recipes already have this built-in due to
meta-rauc. The non-upstream, one-off kernel required to support the Radxa Zero
3{e|w} boards (linux-torvalds-next) needs a similar tweak.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
oe-core has raised the status of some checks from warnings to errors. Ignore
the "...contains references to TMPDIR..." error when building the
torvalds-next kernel.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Add an example of implementing rauc on a rockchip board. Adding the meta-rauc
layer, adding 'rauc' to DISTRO_FEATURES, and enabling RK_RAUC_DEMO will build
an image using the example provided in dynamic-layers/rk-rauc-demo.
This example uses a simple A/B + D scheme (i.e. two root partitions and a
non-updated /data partition). Repartitioning occurs automatically on first
boot thanks to systemd's 'repart' mechanism.
NOTE:
- this example only works with systemd
If you wish to provide your own implementation, simply add the meta-rauc
layer, add 'rauc' to DISTRO_FEATURES, don't enable RK_RAUC_DEMO, and provide
your own implementation in a separate layer.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Switch back to using a SRCREV, but this time without a branch (since this
commit is no longer reachable from any branch), so that network-less builds
can take place (or builds that don't need to resolve the tag (over the
network)).
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Use the tag name specifically; note that it is no longer reachable from any
branch.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The RK356x SoC family (of which we currently only support RK3568) has a
Bifrost GPU that is supported by open-source Panfrost Linux kernel and
Mesa drivers, therefore let's build mesa with Panfrost support for
RK3566.
Signed-off-by: Marcin Bober <mbober1@gmail.com>
Previously the MACHINEs were listed in the order in which they were added to
the layer. Going forward, separate the list into 32 vs 64 bit, sort each of
those groups, while distinguishing between which boards support wic and which
don't.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
