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