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>
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>
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>
b4[1] is a very nice tool for mail-based contribution. A config[2] file
exists to set up a few defaults. We can use it to set the To recipients
to always add, in our case the mailing list.
This shouldn't be necessary if we had a script that b4 prep --auto-to-cc
could call to find the mail address(es) to send to. While we could do
that, this opens the door to people trying to add a way to notify some
people (e.g. a MAINTAINERS file) which is not somewhere the project
wants to go right now, and this also makes sure the address is always
added even if one forgets to run b4 prep --auto-to-cc (which is part of
the typical workflow for U-Boot and Linux kernel, but is not necessary
thanks to this patch).
Additionally, automatically provide a default prefix so that one doesn't
need to not forget to run `b4 prep --set-prefixes meta-rockchip` for
each series.
[1] https://pypi.org/project/b4/
[2] https://b4.docs.kernel.org/en/latest/config.html
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>
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>
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>
A filesystem label (/dev/disk/by-label) is a property of, and stored in, the
filesystem itself. Partitions that are not destined to hold filesystems are
not formatted, therefore it is not possible to assign filesystem labels to
such partitions.
However, if GPT partitioning is being used, GPT supports the notion of
assigning labels/names to the partitions which are stored as part of the GPT
partition table itself (instead of being stored in the filesystem in the
partition). The naming is a bit confusing (different tools use different
names) but `wic` calls this "--part-name", `lsblk` calls this "PARTLABEL", and
`parted` calls this "name".
In Linux user-space these partition labels are referenced via
/dev/disk/by-partlabel and provide an excellent way of finding these GPT
partitions regardless of which backing device is actually being used (e.g.
mmcblk0, mmcblk1... i.e. emmc, sdcard...).
An example where this would be handy is for interacting with a stored U-Boot
environment. Another potential use would be to use one of the unused raw
partitions to store information such as MAC addresses, serial numbers, etc.
which could be set/updated "at the factory" as images are flashed.
Tested with both systemd and sysvinit on both rock-pi-e and rock-pi-s.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
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 project now has a new mailing list dedicated to patches for projects that
don't warrant their own mailing list. Please use this new mailing list when
sending patches so as to not clutter up the main discussion mailing list and
potentially deterring newcomers.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Upstream kernel support for both the rock-5a and rock-5b landed in version
6.5. Nanbield contained linux-yocto recipes for both 6.1 and 6.5 so it
was best to simply have these MACHINEs use linux-yocto-dev. Post-nanbield
oecore master only has a recipe for 6.6 (so far), therefore these two
MACHINEs can use linux-yocto by default, instead of linux-yocto-dev.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Cleanup the elements of the wic/rockchip.wks file so that they take up less
horizontal space.
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
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>
Rockchip defines the expected layout/map of the default storage device.
Fill out the wks description so it matches.
https://opensource.rock-chips.com/wiki_Partitions
There are 2 partitions at the start that can not be specified in
rockchip.wks due to a limitation in wic which assumes all sizes (e.g.
--size or --fixed-size) are specified in units of 1024 bytes. Since these
partitions don't fall on 1024-byte boundaries, they can not be specified at
this time.
Note: in the Rockchip layout, not all partitions are expected to show up
in the gpt partition table. While --no-table could be used to hide these
partitions from the partition table, as specified in the wiki, there's
no practical reason to do so. In fact, exposing these partitions in the
partition table makes it easier and safer for users to interact with them.
For example, a user dd'ing some data to a particular area would need to
ensure they're using the correct offset and size values when accessing the
raw disk directly. However being able to specify a partition ensures data
won't accidentally "spill" out into adjacent regions.
Note: there is a mistake in the Rockchip table (which I've copied verbatim
here in this commit message but corrected in rockchip.wks). Going by the
values of the "Start Sector", the size of the "reserved1" partition is
listed as being 2x its actual size/number of sectors.
Expected:
Partition Start Sector Number of Sectors Partition Size PartNum in GPT Requirements
MBR 0 00000000 1 00000001 512 0.5KB
Primary GPT 1 00000001 63 0000003F 32256 31.5KB
loader1 64 00000040 7104 00001bc0 4096000 2.5MB 1 preloader (miniloader or U-Boot SPL)
Vendor Storage 7168 00001c00 512 00000200 262144 256KB SN, MAC and etc.
Reserved Space 7680 00001e00 384 00000180 196608 192KB Not used
reserved1 8064 00001f80 128 00000080 65536 64KB legacy DRM key
U-Boot ENV 8128 00001fc0 64 00000040 32768 32KB
reserved2 8192 00002000 8192 00002000 4194304 4MB legacy parameter
loader2 16384 00004000 8192 00002000 4194304 4MB 2 U-Boot or UEFI
trust 24576 00006000 8192 00002000 4194304 4MB 3 trusted-os like ATF, OP-TEE
boot 32768 00008000 229376 00038000 117440512 112MB 4 kernel, dtb, extlinux.conf, ramdisk
rootfs 262144 00040000 - - - -MB 5 Linux system
Prior to this patch:
# fdisk -l /dev/mmcblk1
GPT PMBR size mismatch (1504727 != 30375935) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 00000000-0000-0000-0000-00004D9B9EF0
Device Start End Sectors Size Type
/dev/mmcblk1p1 64 8063 8000 3.9M Microsoft basic data
/dev/mmcblk1p2 8064 8191 128 64K Microsoft basic data
/dev/mmcblk1p3 8192 16383 8192 4M Microsoft basic data
/dev/mmcblk1p4 16384 24575 8192 4M Microsoft basic data
/dev/mmcblk1p5 24576 32767 8192 4M Microsoft basic data
/dev/mmcblk1p6 32768 330955 298188 145.6M Microsoft basic data
/dev/mmcblk1p7 330956 1504693 1173738 573.1M Linux filesystem
New:
# fdisk -l /dev/mmcblk1
GPT PMBR size mismatch (1504473 != 30375935) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 00000000-0000-0000-0000-00004D9B9EF0
Device Start End Sectors Size Type
/dev/mmcblk1p1 64 7167 7104 3.5M Linux filesystem
/dev/mmcblk1p2 7168 7679 512 256K Linux filesystem
/dev/mmcblk1p3 7680 8063 384 192K Linux filesystem
/dev/mmcblk1p4 8064 8127 64 32K Linux filesystem
/dev/mmcblk1p5 8128 8191 64 32K Linux filesystem
/dev/mmcblk1p6 8192 16383 8192 4M Linux filesystem
/dev/mmcblk1p7 16384 24575 8192 4M Linux filesystem
/dev/mmcblk1p8 24576 32767 8192 4M Linux filesystem
/dev/mmcblk1p9 32768 330955 298188 145.6M Microsoft basic data
/dev/mmcblk1p10 330956 1504439 1173484 573M Linux filesystem
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
If the wks file doesn't specify, the assumption is that each partition
contains a vfat-formatted filesystem. Most of the partitions in the
Rockchip layout don't have filesystems. Implicitly setting the fstype to
vfat causes wic to format the partitions. It doesn't make sense to format
the rawcopy partitions as vfat just to immediately overwrite them with
binaries, and it wastes time formatting partitions that won't ever be used
as filesystems.
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
In WIC, size arguments can be optionally specified using one of a variety
of suffixes (e.g. K, M, G, etc.) thanks to sizetype(). One such suffix being
"s/S" for handling sector sizes which are assumed to be 512 bytes, rather than
the other size suffixes which are multiples of 1024 bytes.
Using the s/S sizetype allows the definition to match the documentation.
Unfortunately we can not use the s/S suffix for --fixed-size.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
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>
