* main-config: fix: avoid errors when BRANCH contains a dash; convert to underscore
* rockchip64_common: shellfmt, no changes
* rockchip64_common: move SERIALCON defaulting logic to a (verbose) hook for flexibility
* config: allow to build BRANCHes not listed in KERNEL_TARGET as long as the config is valid
- useful for `collabora` and other experimental kernels, we don't want to have to add it to each individual board's KERNEL_TARGES one by one
- but we don't want to allow typos in BRANCH to emit very strange unrelated errors
* extensions: mesa-oibaf extension by @monkaBlyat - mainline mesa PPA for Ubuntu
- does nothing on Debian
* extensions: (v3) amazingfated-rk35xx, now `rk-multimedia-amazingfate` - panfork-free
- simply skips if not on Jammy
- deploys Chromium + Widevine if desktop
* rockchip-rk3588: introduce `vendor-boogie-panthor` experimental BRANCH/kernel
- original: https://github.com/hbiyik/linux-rockchip.git (branch `rk-6.1-rkr1-panthor-v6`)
- I picked the commits on top of clean armbian/linux-rockchip `6.1-rkr1` as of 2024-04-01
- At https://github.com/rpardini/armbian-linux-rockchip-rk3588/tree/armbian-rk-6.1-rkr1-plus-boogie-panthor-v6
- Diff: https://github.com/armbian/linux-rockchip/compare/rk-6.1-rkr1...rpardini:armbian-linux-rockchip-rk3588:armbian-rk-6.1-rkr1-plus-boogie-panthor-v6
- rockchip-rk3588: introduce `boogie-bsp` BRANCH
- rockchip-rk3588: copy linux-rk35xx-vendor.config into linux-rk35xx-boogie-bsp.config
- rockchip-rk3588: update linux-rk35xx-boogie-bsp.config, no changes
- rockchip-rk3588: linux-rk35xx-boogie-bsp.config: `CONFIG_DRM_PANTHOR=m`
- rockchip-rk3588: linux-rk35xx-boogie-bsp.config: convert to defconfig
- rockchip-rk3588: rename to `BRANCH=vendor-boogie-panthor` for "clarity" (lol)
- rockchip-rk3588: vendor-boogie-panthor: force SERIALCON, full firmware (for blob needed for panthor) & mesa-oibaf extension
- rockchip-rk3588: vendor-boogie-panthor: enable amazingfated-rk35xx extension sans-panfork
* using the configured volume group name
* added LVM support
* ensuring /boot never on LVM volume, created hook to setup root device
* preparing root device via extension, not assuming any particular partition for root
* using tab spacing
* using global parameter to require a boot partition
* using boot require, moving cryptroot code to extension
* adds crypt image suffix
---------
Co-authored-by: rafael <rvalle@privaz.io>
* added cloud-init support
* removed compymods, not required for our use case and not available in all distributions
* using space instead of tabs
* added template with typical use-cases and link to docs
* typo
---------
Co-authored-by: rafael <rvalle@privaz.io>
- new VHDX output format (for generic Hyper-V on Windows 10/11/2019/etc)
- it is always stored (no compression) in a .zip file, to avoid sparseness errors
- when building, transfer the .zip file over to Windows, and uncompress it there (not on WSL2 itself/Linux/other machine)
- only Azure wants the static, 1024-aligned original VHD images (and doesnt support VHDX?)
- new VHDX output format (for generic Hyper-V on Windows 10/11/2019/etc)
* Remove create_desktop_package.sh for rk3318 board from
config/optional, clearing the whole directory tree
* Add an extension to implement serverflags workaround
for X.Org and Lima driver not being autodetected
* Fix rk3318-box and rk322x family to use extension in place
of 40-serverflags.conf bsp file
- this extension is _100% optional_ and shouldn't adversely affect any builds if not enabled
- requires `UEFI_EDK2_BOARD_ID` to be set in board file, so we know which UEFI/edk2 build to use
- it finds the latest edk2 version from GitHub automatically (currently `v0.9.1`)
- it downloads (and caches) the correct edk2 build image automatically
- if forces certain aspects of the image:
- must use GPT partitioning
- must NOT use a separate /boot partition
- it _disables_ the building and deploying of u-boot _completely_ (thus blobs etc are from edk2)
- it creates a GPT `"uboot"` partition pointing to edk2's FIT, required by SPL
- this extension:
- automatically enables 'grub-with-dtb'
- automatically enable 'initramfs-usb-gadget-ums', to compensate for lack of ums/rockusb since we dont have u-boot anymore
- this optional extension adds an initramfs script that:
- enumerates and filters all block devices
- exposes each device as an UMS (USB Mass Storage) in an USB Gadget
- loops forever with info (board never boots)
- the idea here is to compensate for UEFI's lack of "ums" or "rockusb" mode that's present in u-boot
- it also allows to expose USB/NVMe devices that might or not be detected by bootloader, if the kernel works
- this should make `09_linux_with_dtb.sh` work across all RELEASE's, `sid` and `mantic` included
- extra: if `grub-mkconfig` (`update-grub`) fails, show all involved source files
- requires `KHADAS_OOWOW_BOARD_ID` set in board file (see next commit)
- always produces xz-compressed images, so this automatically disables `COMPRESS_OUTPUTIMAGE`
- uses `xze` script from Khadas, forcing `IN` and `OUT` env vars so it's not confused by fd 1
- to use, add `EXT=image-output-oowow` parameter to build
- to get into oowow:
- VIM3/VIM3L:
- download oowow SD card image from Khadas:
- VIM3: https://dl.khadas.com/products/oowow/system/vim3-oowow-latest-sd.img.gz
- VIM3L: https://dl.khadas.com/products/oowow/system/vim3l-oowow-latest-sd.img.gz
- write image to SD card, use BalenaEtcher or similar
- insert SD card into board (and remove NVMe if present and bootable)
- boot board into Upgrade mode, see https://docs.khadas.com/products/sbc/vim3/install-os/boot-into-upgrade-mode
- oowow should be running now
- recommended: go into Advanced and reset to factory defaults, so MCU, PCIe/USB3 etc is reset to defaults
- VIM4/VIM4N/VIM1S/Edge2: those have oowow in SPI from factory, check out the manual
- there's a few ways to use these images with oowow:
- Using External media
- prepare media (USB), format it with ext4 or fat, copy produced oowow.img.xz to it
- for ease of use, rename the image file, so it begins with the board-id (`vim1s-/vim4-/edge2-` etc)
- boot board into oowow (see oowow's manual)
- insert media into board
- exit wizard, use "Write image to eMMC", browse to "../"
- change from "XXXX only" to "All" if you didn't rename the image
- choose image file and write
- (remove SD card if using one) and reboot
- Via network (Ethernet or Wi-Fi)
- boot board into oowow
- plug in Ethernet cable or connect to Wi-Fi (see oowow's manual)
- set the firewall mode to "allow" in oowow's Network Settings (see oowow's manual)
- obtain the IP address of the board in oowow (usually shown on top of the screen, or see manual)
- from a remote machine, use curl to upload and write the image to oowow's eMMC, example:
- `curl -L <ip_address>/shell/write | sh -s - <image_filename>.oowow.img.xz`
- reboot board
- From the Internet (one day)
- when Khadas publishes Armbian oowow images to their HTTP server
- I thought sending the spl_loader blob puts it into "Loader" mode, but...
- ... turns out "Loader" mode is a separate (rockusb, etc) mode.
- So if in Maskrom mode, just send the loader, and _trust_ it can now WriteLba
- still keeps the timeout, for when a loader is not accepted
- notice: the rkbin repo or the bins themselves are not hashed or included in the u-boot version (yet)
- make sure to avoid caching when building with those custom git/branch (`ARTIFACT_IGNORE_CACHE=yes CLEAN_LEVEL=make-uboot`)
