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>
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>
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>
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>
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>
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>
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>
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>
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>
This adds an SOC_FAMILY for rk3588 and rk3588s.
Note that we are NOT "require"'ing conf/machine/include/soc-family.inc
so SOC_FAMILY is just another BitBake variable. If we were to require
this file, it would break the MACHINEOVERRIDES order, so some more
changes would be required to handle those properly.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
On systems where KERNEL_IMAGETYPE is not set to fitImage, one needs to
either pass an DTB or a path to a directory where DTBs are located on
the rootfs.
When FDT property in extlinux is provided, FDTDIR isn't used (and
actually u-boot-extlinux-config doesn't even write it to the
configuration file).
When relative paths are used, they are relative to the directory where
extlinux.conf is stored[1]. Since the DTBs are stored in /boot, just
providing the filename of the DTB won't work because extlinux in U-Boot
will search for it in /boot/extlinux. We should therefore either use ../
prefix for relative paths or use /boot to make it absolute. /boot is
more explicit and easily parseable, so let's use the latter.
[1] https://wiki.syslinux.org/wiki/index.php?title=Config#Working_directory
Fixes: d80fa46c42 ("rockchip-extlinux.inc: handle multiple DTs in KERNEL_DEVICETREE")
Fixes: 3b51866f22 ("remove /boot partition")
Fixes: 13316b7968 ("KERNEL_DEVICETREE: 32-bit re-org")
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
If an image doesn't include kernel-modules, the kernel-image package
won't be installed by default. This means that no
kernel-image-${KERNEL_IMAGETYPE} package will be pulled in, resulting in
neither fitImage nor Image (or uImage, or zImage, or...) making it to
the filesystem, rendering the image non-bootable.
For non-fitImage scenarios, we currently expect DTB-less kernel images
(no bundle, like in uImage) so we also need to pull in the DTB via the
kernel-devicetree package.
Those packages used to be pulled in by the wic plugin through the
IMAGE_BOOT_FILES variable.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Fixes: 3b51866f22 ("remove /boot partition")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
KERNEL_DEVICETREE may contain more than one DTB, the first one being the
default one. Therefore, let's split on space first, to get the first DTB
before stripping the directory name from it.
This doesn't add support for creating multiple labels for each DTB in
KERNEL_DEVICETREE.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Fixes: 3b51866f22 ("remove /boot partition")
Fixes: 13316b7968 ("KERNEL_DEVICETREE: 32-bit re-org")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Rename the root partition to "rootfsA" in the off-chance the user may someday
be interested in implementing some sort of whole-partition update mechanism.
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>
In order to boot successfully, most Rockchip SoCs require a specific
partitioning scheme which was defined many years (and many SoCs) ago. That
partitioning scheme places the SPL and U-Boot at specific offsets at the
start of the boot block device:
https://opensource.rock-chips.com/wiki_Partitions
The Rockchip partitioning scheme goes on to also define the locations
of a number of additional partitions, including the "boot" and "root"
partitions.
Since both the SPL and U-Boot have already been placed on the block device,
the "boot" partition only contains the extlinux config file and the
kernel+dtb/fitImage; it doesn't contain any bootloader artifacts (other
than the extlinux config).
The location of the SPL partition is a hard dependency since the BOOTROM
etched inside the Rockchip SoCs is programmed to load and run a validated
binary it finds at this location. The locations of the "boot" and "root"
partitions are not so rigid since it is U-Boot which interacts with them.
U-Boot is very flexible with how it finds boot components, and in its
support for various devices, filesystems, sizes, etc.
Both oe-core's U-Boot metadata and wic's bootimg-partition script contain
logic to generate the extlinux pieces required for a bootloader to boot
a Linux system. If both are enabled, the wic pieces silently clobber the
U-Boot pieces. However, the mechanisms contained in the U-Boot metadata are
much more flexible, from a user's point of view, than the mechanisms in
wic's bootimg-partition.
If a user wishes to setup some sort of A/B redundant update mechanism, they
must have redundant root partitions (in order to update their filesystem
contents) but they also need to have redundant boot partitions if they
wish to update the kernel as part of their update mechanism. Pairing
redundant kernel partitions with redundant filesystem partitions becomes
unnecessarily complicated. Therefore it makes sense to combine the kernel
and the filesystem into the same partition so that both the kernel and
filesystem are updated, or rolled back, in lock-step as one unit. Specific
kernel versions and configurations often have dependencies on user-space
components and versions.
The /boot location is not going away. This patch simply transfers
responsibility for its creation to the more flexible U-Boot mechanism
and includes the kernel as part of the same partition as the root
filesystem. Not only does it add flexibility, it also makes update schemes
more straightforward. Although having a separate /boot partition is a
"requirement" of the Rockchip partitioning scheme, it is not an actual
hard requirement when using a flexible, open-source bootloader (such as
U-Boot) instead of using Rockchip's proprietary miniloader, preloader, and
trust.img.
Build-tested for all boards.
Run-tested on:
nanopi-m4-2gb, nanopi-m4b, nanopi-r2s, nanopi-r4s, roc-rk3328-cc,
rock-3a, rock-5a, rock-5b, rock-pi-4b, rock-pi-e, rock-pi-s,
rock64
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Allow the user to provide their own WKS_FILE in situations where they want a
different layout (e.g. to support A/B updates).
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The upstream kernel reorganized the 32-bit arch/arm device-tree directory
structure to separate out the device-trees by manufacturer (similar to the
organization of the arch/arm64 device-trees). Update the references to
32-bit arm device-trees to match.
This patch can now be applied since all pre-6.5-rc1 kernels have been
removed from oe-core.
NOTE: trying to build a post-6.5-rc1 32-bit kernel with this patch applied
will fail
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Stephen Chen <stephen@radxa.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>
Update machine include files to allow overriding of KERNEL_IMAGETYPE.
[
with the following 2 tweaks by Trevor:
- remove the "v3" from the commit's subject
- extended patch to rk3308 and rk3588s, which were added in between this patch
being submitted, and this patch being applied
]
Signed-off-by: Anthony Davies <anthony.t.davies@gmail.com>
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>
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>
Remove the non-rockchip architectures from the kernel build since these are
all a waste of build time, filesystem space, and runtime memory.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The commit ed3a97f7b2 ("rockchip-wic.inc: don't let wic edit fstab")
removing this ability was introduced to fix an issue in the wic tool in
OE-Core in which wic partitions whose "mountpoint" is not a valid path
are still added to fstab.
This was eventually fixed in OE-Core in commit 7aa678ce804c
("wic:direct.py: ignore invalid mountpoints during fstab update") which
is part of release Honister (3.4) and later.
Therefore, it should be safe to now let wic update fstab again for
partitions with a valid mountpoint path. The benefit being that the wic
partitions with a mountpoint are now automounted at boot.
Cc: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
xf86-input-keyboard was removed from openembedded-core at its commit:
f1d7c33b64 (xf86-input-keyboard: remove the recipe, 2022-07-20). Therefore
remove it from the XSERVER definition.
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Rockchip PX30 SoC is a quad-core ARM Cortex-A35 CPU fully implementing
the ARMv8-A instruction set with ARM Neon Advanced SIMD and Cryptography
Extensions.
This adds a base configuration file which can be included by PX30-based
boards and the required changes in U-Boot and TF-A for proper support.
Cc: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Started seeing the following error in my builds:
ERROR: A native program mkfs.ext4 required to build the image was not found
Please make sure wic-tools have e2fsprogs-native in its DEPENDS
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The _virtual notation is not an override. These syntax "fixes" need to be
reverted.
In the case of the kernel override, when it was added, the rock-pi-e needed
the latest kernel (linux-yocto-dev) but now the default linux-yocto kernel
will suffice. So this mistake actually switched the rock-pi-e from
linux-yocto-dev back to linux-yocto inadvertently but at a time when
linux-yocto-dev was no longer required.
In the case of the bootloader overrides, u-boot was always the default, so
these overrides were always redundant.
Therefore, in the end, simply removing these overrides is the best way
forward (considering these aren't doing anything, and the builds are working
fine regardless).
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
There is no "nanopi-m4" defined in any yocto kernel metadata (yet?), therefore
remove this superfluous line.
Build (core-image-base) and run tested (both systemd and sysvinit) on:
- nanopi-m4
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
For a while we've noticed that /etc/fstab ends up with "junk" appended to the
end e.g.:
/dev/sda1 loader1 vfat defaults 0 0
/dev/sda2 reserved1 vfat defaults 0 0
/dev/sda3 reserved2 vfat defaults 0 0
/dev/sda4 loader2 vfat defaults 0 0
/dev/sda5 atf vfat defaults 0 0
/dev/sda6 /boot vfat defaults 0 0
In most cases this doesn't appear to affect the systems negatively.
However, with the recent patch to switch to UUIDs [0aa5e600: "use uuid
instead of hard-coding root device"] this started becoming an issue on systems
using systemd. Therefore we need to stop wic from adding these junk entries so
that systems continue to boot correctly.
Build tested with core-image-base, nodistro, with both sysvinit and systemd
for:
- marsboard-rk3066
- rock2-square
- firefly-rk3288
- vyasa-rk3288
- nanopi-m4[-2gb]
- tinker-board[-s]
- rock-pi-e
- rock-pi-4[abc]
- rock64
Run tested, core-image-base, both sysvinit and systemd on:
- tinker-board
- rock-pi-e
- rock-pi-4b
- rock64
Commit message updated by Trevor Woerner <twoerner@gmail.com>
Tested-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: MarkusVolk <f_l_k@t-online.de>
Recent upstream kernel changes have made the mmc probing order unpredictable.
Therefore, boards with both an emmc and sdmmc interface aren't guaranteed to
boot with a hard-coded root device selected.
For example, on the rock64, with linux-yocto 5.10.y, using the uSD card (i.e.
the sdmmc interface) about 50% of the time the boot would succeed, and roughly
50% of the time it wouldn't:
...
[ 0.612233] Waiting for root device /dev/mmcblk1p7...
[ 0.634551] mmc_host mmc1: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
[ 0.639064] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ di)
[ 0.640007] mmc0: new high speed SDXC card at address 5048
[ 0.641176] mmcblk0: mmc0:5048 SD64G 58.0 GiB
[ 0.647610] random: fast init done
[ 0.648279] GPT:Primary header thinks Alt. header is not at the end of the disk.
[ 0.648941] GPT:376479 != 121634815
[ 0.649252] GPT:Alternate GPT header not at the end of the disk.
[ 0.649796] GPT:376479 != 121634815
[ 0.650106] GPT: Use GNU Parted to correct GPT errors.
[ 0.650598] mmcblk0: p1 p2 p3 p4 p5 p6 p7
NOTE the discrepancy between the kernel waiting for device /dev/mmcblk1p7,
which comes from the hard-coded kernel cmdline, and the kernel probing putting
the sdmmc on mmcblk0.
With linux-yocto 5.13.y on the rock64 using the uSD card the board would never
boot, the sdmmc always appears on mmcblk0.
Instead of simply changing the hard-coded root device (i.e. from mmcblk0 to
mmcblk1) switch to using partition UUIDs instead. Hard-coding the boot device
would work with 5.13.y but would fail 50% of the time with 5.10.y; who knows
what other kernels will do?
In any case, switching to UUIDs works regardless of board, kernel, or
available mmc interfaces.
Boot tested on:
- rock64
- nanopi-m4-2gb
- tinker-board
- rock-pi-e
- rock-pi-4b
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
With bitbake commit 7dcf317cc141dc980634f8c18bfa84f83e57206a
("bitbake: Switch to using new override syntax"), applied on
Aug 2, 2021, the OVERRIDE separator is now a colon instead of
an underscore. Therefore all builds performed with a bitbake
before this change must use a meta-rockchip commit before this
one, and any builds performed with a bitbake after this change
must use a meta-rockchip starting from this commit onwards.
Build-tested for all meta-rockchip MACHINEs.
Run tested on:
- tinker-board
- nanopi-m4-2gb
- rock64
- rock-pi-4b
- rock-pi-e
The tinker-board and rock-pi-e work fine. The rest of the boards
seem to have a, hopefully unrelated, issue running a
5.13-yocto-standard kernel. However, all boards work with the
5.10-yocto-standard kernel.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Adding "-rockchip" to the Linux kernel name implies, to me anyway, that this
is a vendor kernel. The PREFERRED_PROVIDERs of all kernels specified in this
BSP are upstream linux-yocto kernels, not vendor kernels. Therefore remove the
version name extension to avoid confusion.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
By exporting a couple more variables the wks file for every rockchip device
can be built from one template instead of having separate wks files for each
board and platform.
The following BSP variables were checked before and after this change to make
sure they remained valid/sensible:
- WKS_FILE
- UBOOT_SUFFIX
- SPL_BINARY
- IMAGE_FSTYPES
Built-tested for every MACHINE in this BSP.
Run-tested on the following devices to ensure they continue to boot correctly
to a cmdline (core-image-base):
- tinker-board
- rock-pi-e
- rock-pi-4b
- rock64
- nanopi-m4-2gb
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The ext4 IMAGE_FSTYPES does not need to be mentioned explicitly. It will be
automatically generated in cases where it is needed.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Create a conf/machine/include/rockchip-wic.inc file to contain all the common
wic/wks things for easy inclusion by any MACHINEs that use wic for their image
creation.
NOTE: the wic image type of rock-pi-e changed from "wic.xz" to "wic" which
matches all the other meta-rockchip MACHINEs that use wic
The following variables were checked before and after to make sure they remain
correct/sensible:
- IMAGE_FSTYPES
- WKS_FILE_DEPENDS
- IMAGE_BOOT_FILES
- RK_CONSOLE_BAUD
- RK_CONSOLE_DEVICE
- RK_BOOT_DEVICE
- SERIAL_CONSOLES
- WICVARS
Build-tested for all currently-defined MACHINEs.
Boot-tested on the following boards to make sure they continue to boot to a
console correctly (core-image-base):
- tinker-board
- rock64
- rock-pi-4b
- rock-pi-e
- nanopi-m4-2gb
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
