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>
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>
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>
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>
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 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>
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>
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>
Builds no longer work if artifacts are placed in WORKDIR.
oe-core: b84eec5c4cbf ("base: Switch UNPACKDIR to a subdir of WORKDIR")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The dependency on pyelftools is now in upstream oe-core making this one
redundant.
oe-core: 70eca6a5ccf4 ("u-boot: add missing dependency on pyelftools-native")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
U-Boot has the ability to store its environment variables to a permanent
storage device. Whether or not it does so for any one specific device
depends on whatever settings are enabled in that specific device's
defconfig. In order to definitively configure U-Boot to be able to store
its environment into the device from which it boots, for any device
supported in this BSP, simply add the following to MACHINE_FEATURES:
rk-u-boot-env
If enabled, there is now a second choice to make: should the build also
include the U-Boot environment in the image or not? The default environment,
as generated by U-Boot, can be included in the generated wic image. If it
is included, then flashing the image will also flash the default U-Boot
environment variables and settings, wiping out anything that might have been
there already. If it is not included then your device will either continue
using whatever environment happens to be there (if valid), or will not use any
stored environment if the stored environment has not been set or is invalid.
The variable which governs this behaviour is:
RK_IMAGE_INCLUDES_UBOOT_ENV
By default this is set to "0", meaning that by default the image does not
contain the U-Boot environment. To enable this behaviour, enable this
variable. This variable only takes effect if rk-u-boot-env is listed in
MACHINE_FEATURES, and has no effect otherwise.
The script:
scripts/dump-uboot-env-from-yocto-image.sh
can be used on a rockchip wic image to see the contents of the U-Boot
environment partition at build time.
Tested by booting the same image on both eMMC and SDcard with the following
devices, verifying the ability to read and write the U-Boot environment in
both U-Boot and Linux user-space, and that changes made in one are seen in the
other:
rock-3a
rock-5a
rock-5b
rock-pi-4b
rock-pi-e
rock64
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
These patches were back-ported from upstream to fix an issue with automatically
handling different ethernet PHY chips on different spins of the rock-pi-e
board. Now that the version of U-Boot has been updated in oe-core master,
these pack-ports are no longer required to be applied explicitly.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The bbappend provided in this layer only needs to apply to the
u-boot_<version> file itself and not all u-boot files in oe-core.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The U-Boot patches that were added recently are only for the rock-pi-e
MACHINE, therefore only apply them when building for rock-pi-e.
Fixes: b5bba3a011 ("rock-pi-e: apply upstream PHY fix")
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The ROCK 3A has an rpi form factor and features:
- 4x Cortex-A55 ARM processor
- Mali G52 GPU
- 0.8TOPS NPU
- 32bit 3200Mb/s LPDDR4, up to 4K@60
- HDMI, MIPI DSI, MIPI CSI
- 3.5mm jack with mic
- USB Port
- GbE LAN
- PCIe 3.0, PCIe 2.0
- 40-pin color expansion header
- RTC
- supports USB PD and QC powering
https://wiki.radxa.com/Rock3/3a
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Anthony Davies <anthony.t.davies@gmail.com>
This patch was submitted to the U-Boot mailing list to fix an issue
initializing the PHY on the rock-pi-e.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The T-Firefly ROC-RK3308-CC is a miniature and compact main board which is
equipped with a cost-effective RK3308 Core Processor and a high-performance
CODEC.
Features:
- Rockchip RK3308, 64-bit, quad-core, Arm Cortex-A35 processor @ 1.3GHz
- 100M ethernet
- PoE
- USB 2.0 and Type-C (OTG and power)
- 802.11 b/g/n WiFi and Bluetooth 4.2
https://en.t-firefly.com/product/rocrk3308cc
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
In upstream mainline U-Boot commit 9e13fef00b8d ("rockchip: Kconfig: Enable
external TPL binary for rk3308") U-Boot was changed to incorporate the DDR TPL
using the same mechanism as the RK3568 and RK3588 platforms.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
ROCK Pi S is a Rockchip RK3308 based SBC from Radxa. It contains a 64-bit
quad core processor, USB, ethernet, wireless connectivity, and voice
detection engine in 1.7-inches square. The ROCK Pi S comes in two RAM sizes
256MB or 512MB DDR3, and uses an sdmmc card for OS and storage. Optionally,
some versions of the ROCK Pi S provide on-board storage via 1Gb/2Gb/4Gb/8Gb
of SLC NAND flash.
"S" stands for "small square" since the total board size of the rock-pi-s
is 1.7-inches square.
This BSP assumes booting from sdmmc, and using ttyS0 for the serial console
(similar to Raspberry Pi).
The latest version of the binary ddr initializer code from rkbin does not
provide a uart0 option, therefore all diagnostic output from rkbin and u-boot
is lost on the console (and replaced with a stream of gibberish until the
Linux kernel starts). Therefore, by default, the build assumes the user would
prefer to see this information and have the option to interact with U-Boot,
which means an older version of rkbin is used. The user can override this
decision by setting:
RKBIN_RK3308_LATEST = "1"
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Looking forward, rkbin should only be used by specific Rockchip platforms
for which TF-A support is not (yet?) available. If rkbin gets added by
accident without an override, add a bbfatal to let the user know an
override is required.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The goal of the default COMPATIBLE_MACHINE was to not allow
rockchip-rkbin to be even parsed if a MACHINE isn't part of the
COMPATIBLE_MACHINE.
However, COMPATIBLE_MACHINE is a regexp checked using Python's re module
approximately like:
"""
if re.match(COMPATIBLE_MACHINE, MACHINE):
return True
"""
and re.match() returns a match whatever MACHINE is if COMPATIBLE_MACHINE
is the empty string.
Therefore, let's change it to `^$` which only matches the empty string,
which shouldn't be possible for anything in MACHINEOVERRIDES, and if it
is there are probably bigger problems than parsing rockchip-rkbin.
Fixes: f8af59dd7c ("rock-5b: add")
Cc: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Group the EXTRA_OEMAKE items together and sort.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Group the INIT_FIRMWARE_DEPENDS together and sort.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Add support for the Radxa Rock 5B
https://wiki.radxa.com/Rock5/5b
The device-tree for this board is better in the 6.5 (and later) kernels,
therefore set the kernel to linux-yocto-dev for now (eventually this won't be
needed as linux-yocto moves forward).
Unfortunately the TF-A project does not currently have support for
the rk3588. Therefore, for the time-being, the only way to supply a
TPL/DDR-init for the rk3588 is to use the closed-source rkbin binaries
from Rockchip. If/when TF-A adds support for the rk3588 we can investigate
switching.
The rk3588 comes in two variants: rk3588 and rk3588s. The "s" option is a
stripped-down version of the rk3588. In the Linux kernel these two SoCs are
kept separate, with the rk3588 building on the rk3588s, so we've mimicked that
same behaviour here.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
