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>
The Radxa ZERO 3e is an ultra-small, high-performance single board computer
based on the Rockchip RK3566, with a compact form factor, and rich interfaces.
http://radxa.com/products/zeros/zero3w/
tech specs:
- Rockchip RK3566 (4x Arm Cortex-A55 @ 1.6GHz)
- Arm Mali-G52-2EE (OpenGL ES 1.1/2.0/3.0/3.1/3.2, Vulkan 1.1, OpenCL 2.0)
- LPDDR4 RAM (1/2/3/8 GB)
- µSD
- optional onboard eMMC (8/16/32/64 GB)
- IEEE 802.11 b/g/n/ac/ax(WiFi6), BT5.4 with BLE
- 1x USB 2.0 Type C OTG, 1x USB 3.0 Type C Host
- 1x µHDMI (1080p @ 60fps)
- 1x MIPI CSI camera port
- colour-coded 40-pin GPIO (uart, spi, i2c, pcm/i2s, pwm, gpio)
- 72mm x 30mm
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The Radxa ZERO 3e is an ultra-small, high-performance single board computer
based on the Rockchip RK3566, with a compact form factor, and rich interfaces.
http://radxa.com/products/zeros/zero3e/
tech specs:
- Rockchip RK3566 (4x Arm Cortex-A55 @ 1.6GHz)
- Arm Mali-G52-2EE (OpenGL ES 1.1/2.0/3.0/3.1/3.2, Vulkan 1.1, OpenCL 2.0)
- LPDDR4 RAM (1/2/3/8 GB)
- µSD
- GbE
- 1x USB 2.0 Type C OTG, 1x USB 3.0 Type C Host
- 1x µHDMI (1080p @ 60fps)
- 1x MIPI CSI camera port
- colour-coded 40-pin GPIO (uart, spi, i2c, pcm/i2s, pwm, gpio)
- 72mm x 30mm
NOTE: currently support for this board requires a U-Boot fork for the
bootloader, and linux-next for the kernel. Support will probably come in linux
kernel 6.11-ish, at which point U-Boot will then use that kernel's device tree
which means U-Boot support will come after the release of whichever kernel
includes support for this board.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Update to a newer release.
rk3568:
- update DDR init from version 1.18 → 1.21
rk3588/s:
- the name of the DDR init changed due to upstream adjusting
the frequency of the LPDDR5 to 2400MHz to "improve stability" [1]
- reference an exact version instead of using an '*'
- update DDR init from version 1.12 → 1.16
Boot tested on:
- rock-3a
- rock-5a
- rock-5b
Link [1]: f02d10e468
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> #RK3588 Jaguar, manual U-Boot compilation
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
For boards which build and boot wic images, the user can optionally specify
a compression using the WIC_COMPRESSION_EXTENSION variable. By default "wic"
images are built, but if the user would prefer, say "wic.xz" images, simply
specify:
WIC_COMPRESSION_EXTENSION = ".xz"
in the configuration (e.g. conf/local.conf).
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
RK3568.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
lima is the open-source implementation for the GPU found on RK3328, it
is therefore not specific to the Rock64 but all boards based on the
RK3328.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Since closed-tpl OVERRIDES allows us to have a common logic for all
boards using ROCKCHIP_TPL in U-Boot for specifying external TPL blobs as
DDR init, let's make use of it.
This also allows us now to not have to care about the U-Boot recipe
whenever a new SoC will be supported.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This adds closed-tpl to MACHINEOVERRIDES if ROCKCHIP_CLOSED_TPL is set
to 1. This is a way to tell U-Boot that it needs to fetch the TPL from
some place instead of building it. This will allow us to have a common
logic in U-Boot, and also avoid touching the U-Boot recipe to add
support for a new SoC.
As there may be a transition phase during which we still have closed TPL
by default but an open-source implementation exists, let's make it a
weak assignment so it can be overridden from higher configuration files.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Anyone writing their own U-Boot recipe for their Rockchip-based board
will need to repeat the same as currently done in a bbappend that only
applies to the upstream u-boot recipe from OE-Core. This is both
error-prone and more difficult to maintain as well as lowering the
number of people actually using the code in meta-rockchip (thus
increasing maintainer load by having less people debug the code).
Move everything that is Rockchip-specific but reusable in an .inc file
that can be included by other layers.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
For SoCs with open DDR init in U-Boot, there's no need for anything but
the BL31 from TF-A (maybe OP-TEE as well but that's off-topic) in
U-Boot. This is already handled by the TFA_DEPENDS variable outside of
this git context, so there's no need to duplicate it here.
By keeping the rockchip-rkbin dependency in INIT_FIRMWARE_DEPENDS and
use the PREFERRED_PROVIDER mechanism for selecting rockchip-rkbin as
provider for trusted-firmware-a as passed to TFA_DEPENDS, we make
explicit the dependency on two different pieces of software, though
currently provided by the same recipe.
The point being that this should prepare us and at the very least break
the build if we forget, for when open BL31 TF-A (so coming from
trusted-firmware-a recipe and not rockchip-rkbin) is released and we can
have rockchip-rkbin provide only the DDR bin and upstream TF-A provide
BL31 TF-A and still have a proper dependency scheme.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
All Aarch64 boards require a BL31 from TF-A to be able to boot a Linux
kernel. Therefore let's explicit this dependency right after adding the
BL31 variable to EXTRA_OEMAKE.
While it is already explicitly added later in the file, it is stored in
a variable whose name is a bit confusing as TF-A has not much to do with
being an init firmware.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The mechanism remains the same, except that everything that requires
rockchip-rkbin doesn't need to know that rk3308 boards would prefer the
rk3308-rkbin instead, it's abstracted by the PREFERRED_PROVIDER
mechanism by BitBake.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This makes it possible to select rk3308-rkbin as a PREFERRED_PROVIDER
for rockchip-rkbin, which makes it much easier to handle "flavors" in
recipes where this dependency exists.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
By making use of the newly added rockchip MACHINEOVERRIDES as well as
SOC_FAMILY, the logic can be drastically simplified in addition to not
needing to update BL31 for new SoCs.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Add "rockchip" to the MACHINEOVERRIDES so that it can be used to easily
identify things that apply only to Rockchip-based devices and keeping
other devices untouched.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The SOC_FAMILY OVERRIDES should come after the TUNE one, so it needs to
be defined before.
before:
MACHINEOVERRIDES="rk3288:armv7ve:vyasa-rk3288"
after:
MACHINEOVERRIDES="armv7ve:rk3288:vyasa-rk3288"
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The SOC_FAMILY OVERRIDES should come after the TUNE one, so it needs to
be defined before.
before:
MACHINEOVERRIDES="rk3188:armv7a:radxarock"
after:
MACHINEOVERRIDES="armv7a:rk3188:radxarock"
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The SOC_FAMILY OVERRIDES should come after the TUNE one, so it needs to
be defined before.
before:
MACHINEOVERRIDES="rk3066:armv7a:marsboard-rk3066"
after:
MACHINEOVERRIDES="armv7a:rk3066:marsboard-rk3066"
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
