mirror of https://github.com/jetkvm/rv1106-system.git synced 2026-05-21 05:20:41 +00:00

Files

T

History

Lian Duan a8a9a8502d Dual storage options eMMC & TF Card (#63 )

* feat: support dual storage variants (eMMC + SDMMC/TF card) and upgrade jetkvm_app to 0.5.6

Introduce two separate build configurations for JetKVM V2 hardware
variants that differ only in storage medium:

  BoardConfig-EMMC-NONE-RV1106_JETKVM_V2.mk  → boots from eMMC  (mmcblk0, 13640M userdata)
  BoardConfig-SDMMC-NONE-RV1106_JETKVM_V2.mk → boots from TF card (mmcblk1, dynamic userdata)

DTS refactor:
- Extract all shared board peripherals (backlight, gmac, i2c1/AT24C02,
  i2c3/FT5x06, spi0/ST7789V, uart3, rtc, wdt, pwm5, sfc=disabled) into
  rv1106-jetkvm-v2.dtsi as a common base
- rv1106g-jetkvm-v2.dts becomes a thin file with only the eMMC node
- New rv1106g-jetkvm-v2-sdmmc.dts thin file with only the sdmmc node
- Verified: both DTBs compile correctly; eMMC DTB is binary-identical
  to upstream

Build system:
- Add sdmmc as a new RK_BOOT_MEDIUM type throughout project/build.sh:
  sd_parts device, parse_partition_file, rootfs bootarg, build_recovery,
  build_factory, build_uboot INI selection, and mount_part script
- sysdrv/Makefile: add sdmmc block for KERNEL_CMDLINE_FRAGMENT and env
  target using mmcblk1; restore emmc back to mmcblk0
- project/scripts/mk-tftp_sd_update.sh: recognize sdmmc alongside emmc
- tools/linux/Linux_Pack_Firmware/mk-update_pack.sh: add mmcblk0 to the
  boot medium list so eMMC update packages are correctly generated

U-Boot:
- android_ab.c: replace hardcoded mmcblk1 with dev_desc->devnum so the
  A/B root device path is correct for both eMMC (devnum=0) and SDMMC
  (devnum=1), matching the DTS alias assignments

jetkvm_app:
- Upgrade from 0.4.8 to 0.5.6 (SHA256 verified)
- Note: 0.5.6 switches from static to dynamic linking (ld-uClibc.so.0)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* ci: switch to ubuntu-22.04 runner and build both EMMC and SDMMC variants

- Replace buildjet-16vcpu-ubuntu-2204 with standard ubuntu-22.04 runner
- Use matrix strategy (fail-fast: false) to build EMMC and SDMMC in parallel
- Artifact names include board variant: OTA-Image-EMMC, Full-Image-EMMC, etc.
- buildkit upload remains EMMC-only

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* feat: bake SKU identifier into system image for OTA targeting

Each build variant writes /etc/jetkvm-sku to the system partition so
the jetkvm_app can report the correct SKU when querying the OTA service:

  BoardConfig-EMMC  → RK_SKU=jetkvm-emmc
  BoardConfig-SDMMC → RK_SKU=jetkvm-sdmmc

Matches the SKU routing introduced in jetkvm/cloud-api#49, where the
OTA API serves variant-specific binaries under
{prefix}/{version}/skus/{sku}/ and defaults to legacy path for
unrecognised SKUs.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix: align OTA SKU names with cloud-api DEFAULT_SKU convention

  jetkvm-emmc  → jetkvm-v2       (matches cloud-api DEFAULT_SKU)
  jetkvm-sdmmc → jetkvm-v2-sdmmc

Ref: jetkvm/cloud-api@1958830

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix(dts): remove contradictory cap-mmc-highspeed from sdmmc node

no-mmc prevents MMC protocol probing entirely, making cap-mmc-highspeed
dead and misleading. Only cap-sd-highspeed is relevant for TF card use.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix: handle IGNORE mountpoint for sdmmc in mount_part script

Line 1601's guard only matched emmc, so SDMMC partitions with
IGNORE mountpoint (e.g. inactive A/B slot) would fall through to
return 1 instead of return 0, causing boot-time mount errors.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix: add sdmmc to block-device filesystem tool checks in build_mkimg

erofs and squashfs paths were missing sdmmc, causing them to fall
through to ubifs (NAND-only tool). Latent with current ext4-only
config but would silently produce a corrupt image if fs type changed.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* feat(sdmmc): build dd-able SD card image for direct flashing

Adds build_sd_dd_image() that assembles a flat raw image from the
fixed-size partitions (env, idblock, uboot_a/b, boot_a/b, system_a/b)
plus a 256 MiB seed userdata.img containing install_to_userdata
content (jetkvm_app etc.). Layout follows the cmdline blkdevparts —
no MBR/GPT, since the kernel reads partitioning from u-boot env.

Why a seed userdata: the SDMMC partition spec terminates with
'-(userdata)' which build_mkimg skips, so jetkvm_app never landed in
update.img on SDMMC. The mount_part init script (project/build.sh
mount_part) calls resize2fs on first boot, which grows the 256 MiB
ext4 to the end of the SD card automatically.

Workflow: SDMMC artifact is now update_sd.img.zip (zip -9 of a sparse
~1.4 GiB image, ~45 MiB compressed). update.img remains the EMMC
artifact since RKDevTool still uses it for production flashing.

* fix(sdmmc): chown userdata seed root:root before mkfs.ext4

build_mkimg userdata is a no-op on SDMMC (partition size '-' → 0), so the
__RELEASE_FILESYSTEM_FILES chown that build_mkimg normally runs never fires.
Without it, mkfs.ext4 -d preserves the builder's uid/gid into the image, so
/userdata/jetkvm on the SD card depended on whoever ran the build.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(sdmmc): tune userdata mkfs.ext4 so first-boot resize2fs scales to 1 TiB

The previous flags (mkfs default 1K block size, -O ^64bit,^huge_file) made
the first-boot resize hang on large cards:

  - 1K blocks × 8K-blocks-per-group → 128K block groups for 1 TiB. resize2fs
    has to write GD/bitmap entries for every new group; on slow SD random
    writes this stretches to many minutes.
  - Default inode_ratio at 1K = 2048 inodes/group → ~256M inodes after
    resize. ext4lazyinit kthread then zeroes ~32 GiB of inode tables in
    the background, saturating SD I/O long after mount returns.
  - resize_inode reserve = 256 GDT blocks × 32 entries = 8192 group
    descriptors, capping resize_inode-style growth at 64 GiB. Beyond that,
    resize2fs falls back to meta_bg, but ^64bit blocks the cleaner path.

Switch to: 4K blocks, -T largefile (1 inode/MiB), -O 64bit, and an explicit
-E resize= reservation covering 2 TiB. Measured on a 1 TiB sparse loop
(host mkfs.ext4 1.47.2): online resize drops from 40 s to 0.4 s, and the
post-mount lazy-itable workload drops from ~32 GiB to ~256 MiB of writes.

32 GiB minimum supported card capacity.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(sdmmc): include sdmmc in sysdrv build-medium switches

Three places in sysdrv/ branched on the boot medium but left sdmmc out:

  - Makefile.tools.board.mk: e2fsprogs was gated on BOOT_MEDIUM=emmc, so
    the SDMMC rootfs shipped without resize2fs/e2fsck/mke2fs. mount_part's
    first-boot resize2fs call then silently failed and userdata stayed
    locked at the 256 MiB seed size, never growing to fill the card.

  - Makefile.param: the RK_BOOT_MEDIUM whitelist that propagates BOOT_MEDIUM
    omitted sdmmc, so any sub-tool Makefile included Makefile.param
    standalone (dropbear, eudev, etc.) saw BOOT_MEDIUM unset for sdmmc.
    Currently benign because no sub-tool branches on BOOT_MEDIUM, but a
    latent footgun.

  - tools/pc/toolkits/get_part_info.sh: PARTITION_FIRST_NO=0 was applied
    only for emmc. mmcblk1pN is also 1-indexed, so sdmmc would produce
    off-by-one root=/dev/mmcblk1pN values via `make env -C sysdrv`. The
    project's build.sh path computes part_num itself and isn't affected,
    but the sysdrv path was wrong.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-04-25 23:55:26 +02:00

android

…

arch

Dual storage options eMMC & TF Card (#63 )

2026-04-25 23:55:26 +02:00

block

…

certs

…

crypto

…

Documentation

…

drivers

feat(usb): gadget: f_hid: add wakeup_on_write support (#57 )

2026-04-08 12:36:08 +02:00

drv_ko/lib/modules/5.10.160

…

include

…

init

…

io_uring

…

ipc

…

kernel

…

lib

…

LICENSES

…

net

…

samples

…

scripts

…

security

…

sound

…

tools

…

usr

…

virt

…

.clang-format

…

.cocciconfig

…

.get_maintainer.ignore

…

.gitattributes

…

.gitignore

…

.mailmap

…

.scmversion

…

boot.its

…

build.config.aarch64

…

build.config.allmodconfig

…

build.config.allmodconfig.aarch64

…

build.config.allmodconfig.arm

…

build.config.allmodconfig.x86_64

…

build.config.amlogic

…

build.config.arm

…

build.config.common

…

build.config.db845c

…

build.config.gki

…

build.config.gki_kasan

…

build.config.gki_kasan.aarch64

…

build.config.gki_kasan.x86_64

…

build.config.gki_kprobes

…

build.config.gki_kprobes.aarch64

…

build.config.gki_kprobes.x86_64

…

build.config.gki-debug.aarch64

…

build.config.gki-debug.x86_64

…

build.config.gki.aarch64

…

build.config.gki.aarch64.fips140

…

build.config.gki.aarch64.fips140_eval_testing

…

build.config.gki.x86_64

…

build.config.hikey960

…

build.config.khwasan

…

build.config.rockchip

…

build.config.x86_64

…

COPYING

…

CREDITS

…

Kbuild

…

Kconfig

…

logo_kernel.bmp

…

logo.bmp

…

MAINTAINERS

…

Makefile

…

OWNERS

…

README

…

README.md

…

README.md

How do I submit patches to Android Common Kernels

BEST: Make all of your changes to upstream Linux. If appropriate, backport to the stable releases. These patches will be merged automatically in the corresponding common kernels. If the patch is already in upstream Linux, post a backport of the patch that conforms to the patch requirements below.
- Do not send patches upstream that contain only symbol exports. To be considered for upstream Linux, additions of EXPORT_SYMBOL_GPL() require an in-tree modular driver that uses the symbol -- so include the new driver or changes to an existing driver in the same patchset as the export.
- When sending patches upstream, the commit message must contain a clear case for why the patch is needed and beneficial to the community. Enabling out-of-tree drivers or functionality is not not a persuasive case.
LESS GOOD: Develop your patches out-of-tree (from an upstream Linux point-of-view). Unless these are fixing an Android-specific bug, these are very unlikely to be accepted unless they have been coordinated with kernel-team@android.com. If you want to proceed, post a patch that conforms to the patch requirements below.

Common Kernel patch requirements

All patches must conform to the Linux kernel coding standards and pass script/checkpatch.pl
Patches shall not break gki_defconfig or allmodconfig builds for arm, arm64, x86, x86_64 architectures (see https://source.android.com/setup/build/building-kernels)
If the patch is not merged from an upstream branch, the subject must be tagged with the type of patch: UPSTREAM:, BACKPORT:, FROMGIT:, FROMLIST:, or ANDROID:.
All patches must have a Change-Id: tag (see https://gerrit-review.googlesource.com/Documentation/user-changeid.html)
If an Android bug has been assigned, there must be a Bug: tag.
All patches must have a Signed-off-by: tag by the author and the submitter

Additional requirements are listed below based on patch type

Requirements for backports from mainline Linux: `UPSTREAM:`, `BACKPORT:`

If the patch is a cherry-pick from Linux mainline with no changes at all
- tag the patch subject with UPSTREAM:.
- add upstream commit information with a (cherry picked from commit ...) line
- Example:
  - if the upstream commit message is

        important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

then Joe Smith would upload the patch for the common kernel as

        UPSTREAM: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry picked from commit c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        Signed-off-by: Joe Smith <joe.smith@foo.org>

If the patch requires any changes from the upstream version, tag the patch with BACKPORT: instead of UPSTREAM:.
- use the same tags as UPSTREAM:
- add comments about the changes under the (cherry picked from commit ...) line
- Example:

        BACKPORT: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry picked from commit c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        [joe: Resolved minor conflict in drivers/foo/bar.c ]
        Signed-off-by: Joe Smith <joe.smith@foo.org>

Requirements for other backports: `FROMGIT:`, `FROMLIST:`,

If the patch has been merged into an upstream maintainer tree, but has not yet been merged into Linux mainline
- tag the patch subject with FROMGIT:
- add info on where the patch came from as (cherry picked from commit <sha1> <repo> <branch>). This must be a stable maintainer branch (not rebased, so don't use linux-next for example).
- if changes were required, use BACKPORT: FROMGIT:
- Example:
  - if the commit message in the maintainer tree is

        important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

then Joe Smith would upload the patch for the common kernel as

        FROMGIT: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        (cherry picked from commit 878a2fd9de10b03d11d2f622250285c7e63deace
         https://git.kernel.org/pub/scm/linux/kernel/git/foo/bar.git test-branch)
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>

If the patch has been submitted to LKML, but not accepted into any maintainer tree
- tag the patch subject with FROMLIST:
- add a Link: tag with a link to the submittal on lore.kernel.org
- add a Bug: tag with the Android bug (required for patches not accepted into a maintainer tree)
- if changes were required, use BACKPORT: FROMLIST:
- Example:

        FROMLIST: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Link: https://lore.kernel.org/lkml/20190619171517.GA17557@someone.com/
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>

Requirements for Android-specific patches: `ANDROID:`

If the patch is fixing a bug to Android-specific code
- tag the patch subject with ANDROID:
- add a Fixes: tag that cites the patch with the bug
- Example:

        ANDROID: fix android-specific bug in foobar.c

        This is the detailed description of the important fix

        Fixes: 1234abcd2468 ("foobar: add cool feature")
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>

If the patch is a new feature
- tag the patch subject with ANDROID:
- add a Bug: tag with the Android bug (required for android-specific features)

README.md

How do I submit patches to Android Common Kernels

Common Kernel patch requirements

Requirements for backports from mainline Linux: UPSTREAM:, BACKPORT:

Requirements for other backports: FROMGIT:, FROMLIST:,

Requirements for Android-specific patches: ANDROID:

Requirements for backports from mainline Linux: `UPSTREAM:`, `BACKPORT:`

Requirements for other backports: `FROMGIT:`, `FROMLIST:`,

Requirements for Android-specific patches: `ANDROID:`