OTA for specific SKUs#49
Merged
adamshiervani merged 18 commits intodevfrom Jan 28, 2026
Merged
Conversation
…include system URL verification
…ieve, Update, and Delete functions
…PostgreSQL service
IDisposable
reviewed
Jan 27, 2026
…te S3 object existence checks to use HeadObjectCommand
…chema and ensure consistent defaults
…stemRecovery handlers, ensuring cached redirects and SKU-specific cache keys are correctly implemented
adamshiervani
pushed a commit
to jetkvm/rv1106-system
that referenced
this pull request
Apr 25, 2026
* 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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
jetkvm-v2