Backport DTS/DTSI changes from linux-6.4.y to 6.1.y
Add meson64-reboot driver to all boards
Add board: ODROID N2L
Add uart_A uart_AO_B uart_B uart_C where appropriate
U-Boot v2023.07.02: ODROID N2/N2L/N2Plus/C4
Meson64-reboot driver: (source: tobetter)
While the current meson64-reboot driver is cleaner and doesn't
depend on modding other kernel sources, its functionality leaves
much to be desired. One example can be found in the ODROID C4.
Using the current driver, the board will not properly power off,
leaving the POWER LED still on. The new driver powers off the unit
completely.
Fan control: (ODROID N2L/N2PLus)
Added service and script for controlling the trip point.
fanctrl: arguments: 65 55 45 35 25 menu run
┌──┤ Fan Control ├──┐
│ │
│ 6) 65°C │
│ 5) 55°C │
│ 4) 45°C │
│ 3) 35°C │
│ 2) 25°C │
│ E) Exit .. │
│ │
│ │
│ <Ok> │
│ │
└───────────────────┘
NOTES: (N2L/HC4): I do not own the units so I can't run tests.
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Some sd cards are unable to access in uboot when using miniloader
These cards are able to access when using spl instead
Spl is not related to DDR initialization so it is unlikely to introduce
DDR problems
- 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
> tl-dr: only deploys to remote OCI if `UPLOAD_TO_OCI_ONLY=yes`; stop leaving junk behind in local cache in many situations
- simplify CLI artifact building parameters and behaviour
- `ARTIFACT_USE_CACHE` is now deprecated, and its behaviour is the default
- for _any_ uploading to OCI to occur, `UPLOAD_TO_OCI_ONLY=yes` **must** be present; in this case, reversioning is not done
- `FORCE_ARTIFACTS_DOWNLOAD` is completely removed (use `download-artifact` instead)
- `cli_obtain_complete_artifact()`'s and `build_artifact_for_image()`'s reversioning is now moved to common `obtain_complete_artifact()`
- `standard_artifact_reversion_for_deployment()`:
- check for hashed deb existence only if reversioned does not exist
- touch the reversioned file if it already exists; helps to clean up junk later
- delete hashed version after reversioning, so we don't leave trash behind
- unless in `download-artifact` mode, which `touch`es the hashed version
- we can later delete old files from packages-hashed to keep junk under control
- refactor `obtain_complete_artifact()`
- extract function `artifact_dump_json_info()` since obtain is large enough already
- when deploying to remote, always ignore all local and remote caches
- introduce `artifact_is_available_in_revisioned_local_cache()`
- if not deploying to remote, and revisioned cache exists, use it directly
- if deploying to remote, reversioned is not checked and not created
- if deploying to remote, force `DEB_COMPRESS=xz`
- if deploying to remote, completely remove the local cache base dir after upload is done (no more junk leftover)
