- this should avoid (late) patching errors that might happen during a point release bump like `6.4.5` -> `6.4.6` cos we'd be using the wrong cached drivers patch
- using the SHA1 will instead (possibly) trigger the "real patching failure", during drivers-harness when building a new driver patch cache
- also try to cleanup old caches in the old format so we've not many leftovers -- each patch is ~150mb
- `ANSI_COLOR=none` is used when we're driving compile.sh from Python
- some debugging messages had newlines in them, thus making Python mark those as `[LEAKED]`
- also avoid log archiving during individual download jobs via SKIP_LOG_ARCHIVE=yes
- I've tested with PARALLEL_DOWNLOADS_WORKERS=16 and it saturates my gigabit link, ghcr.io is great at reads
- more than ~16-ish might be too much though
> How to use:
>
> `./compile.sh inventory` - does just the board inventory; look for output in `output/info`
>
> `./compile.sh targets-dashboard` - does inventory, targets compositing, and images info; look for output in `output/info`, read the instructions output by the command if you want to load the OpenSearch dashboards.
>
> `./compile.sh targets` - does the full targets compositing and artifacts, look for output in `output/info`
>
> If you don't have a `userpatches/targets.yaml`, _one will be provided for you_ defaulting to Jammy minimal CLI
> and Jammy xfce desktop, for all boards in all branches. You can pass filters via `TARGETS_FILTER_INCLUDE=...` to narrow.
>
- board JSON inventory:
- more generic regex parsing of variables from board files:
- all top-level (non-indented) variables are parsed and included in the JSON board inventory
- this allows us to add new variables to the board files without having to update the parser
- variables can be bare, `export` or `declare -g`, but **_must_ be quoted** (single or double) and UPPER_CASE
- some special treatment for certain variables:
- `KERNEL_TARGET` is parsed as a _comma-separated_ list of valid BRANCH'es
- `BOARD_MAINTAINER` is parsed as _space-separated_ list of valid maintainer GH usernames as `BOARD_MAINTAINERS: [...]` in the JSON
- script complains if `BOARD_MAINTAINER` is not set in core boards. Empty is still allowed.
- `HAS_VIDEO_OUTPUT="no"` causes `BOARD_HAS_VIDEO: false` in the JSON (for desktop-only inventorying, see below)
- introduce `not-eos-with-video` in `items-from-inventory` at the targets compositor
- the same as `not-eos`, but with added `BOARD_HAS_VIDEO: true` filter, see above
- introduce `TARGETS_FILTER_INCLUDE` for targets compositor
- this filters the targets _after_ compositing (but before getting image info), based on the board inventory data
- it's a comma-separated list of `key:value` pairs, which are OR-ed together
- new virtual info `BOARD_SLASH_BRANCH` post-compositing inventory for filtering of a specific BOARD/BRANCH combo (e.g. `odroidhc4/edge`)
- some interesting possible filters:
- `TARGETS_FILTER_INCLUDE="BOARD:odroidhc4"`: _only_ build a single board, all branches. JIRA [AR-1806]
- `TARGETS_FILTER_INCLUDE="BOARD_SLASH_BRANCH:odroidhc4/current"`: _only_ build a single board/branch combo
- `TARGETS_FILTER_INCLUDE="BOARD:odroidhc4,BOARD:odroidn2"`: _only_ build _two_ boards, all branches.
- `TARGETS_FILTER_INCLUDE="BOARD_MAINTAINERS:rpardini"`: build all boards and branches where rpardini is a maintainer
- `TARGETS_FILTER_INCLUDE="BOARDFAMILY:rockchip64"`: build all boards and branches in the rockchip64 family
- image-info-only variables like `LINUXFAMILY` is **not** available for filtering at this stage
- rename `config/templates` `targets-all-cli.yaml` to `targets-default.yaml`
- this is used when no `userpatches/targets.yaml` is found
- new default includes all boards vs branches for non-EOS boards
- also desktop for all boards that _don't_ have `HAS_VIDEO_OUTPUT='no``
- introduce simplified `targets-dashboard` CLI:
- does only inventory, compositing, and image info, but not artifact reducing, etc.
- ignore desktop builds in the OpenSearch indexer
- update the OpenSearch Dashboards, including new information now available
- invert the logic used for `CLEAN_INFO` and `CLEAN_MATRIX`
- defaults to `yes` now, so new users/CI don't get hit by stale caches by default
- repo pipeline CLI stuff is usually run on saved/restored artifacts for `output/info`, so don't clean by default via the CLI
- `USE_TMPFS=no` disables usage of generic tmpfs mechanism (still possibly used for rootfs/image building, which is unrelated), for last-resort cases
- use better/more descriptive `temp_dir_id`'s for kernel build than `k` (now `kernel_dest_install_dir`) and `kd` (now `kernel_debs_temp_dir`)
- specific image/dtb/headers packaging already had decent names, same for other .deb's
- replace `mktemp -d` with `mktemp -d --tmpdir "${temp_dir_id}-XXXXX"` in `prepare_temp_dir_in_workdir_and_schedule_cleanup()`, so we know what's using what in tmpfs
The /dev/mapper directory created by devtmpfs lacked entry for
armbian-root thereby breaking the cryptsetup configuration generated
within initrd file. Use bind mount as that doesn't seem to suffer from
that issue.
We were not monitoring /usr/share/initramfs-tools before where most
of extra hooks gets installed. While testing builds with CRYPTROOT
I created build with dropbear ssh key unlock support first and then
went for password only, but it still used initrd image with dropbear
files and older keys. Including /usr/share/initramfs-tools fixes the
same. Also as dropbear keys were autogenerated, they needed to be
monitored as well.
* Added `shell.nix` definition for temporary development environment for Nix(OS)
* Set uuidgen and other binaries check to not rely on hard-codded paths
With this change, setting EXTRAWIFI=no will disable all wireless
patches applied within drivers_network.sh script. Also since #5265
the rtl88x2cs patches were suppose to be not applied to 6.1+ kernel
onwards, instead they were disabled entirely. As this was done by
adding EXTRAWIFI=no, its now replaced with kernel version limit.
Keeping EXTRAWIFI=no there would have made those patches to apply
which would have changed the meaning of the flag.
Cope with the fix in stable 6.3.13 bf353116d1bf and 6.5-rc1 e8c2af660ba0
"wifi: cfg80211: fix regulatory disconnect with OCB/NAN".
That is the removal of REGULATORY_IGNORE_STALE_KICKOFF
from the wireless regulator internal API to fix any driver
that allowed OCB/NAN.
Note this code will need to be expanded once and if 6.4 include the
above fixup.
Signed-off-by: Alban Browaeys <alban.browaeys@gmail.com>
Use multiple consecutive reads in rtw_sdio_read_port() to limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. This allows receiving a buffer that's larger than the hosts max_req_size (number of bytes which can be transferred in one MMC/SDIO transfer). As a result of this the skb_over_panic error is gone as the rtw88 driver is now able to receive more than 1536 bytes from the card (either because the incoming packet is larger than that or because multiple packets have been aggregated).
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
- introduced at 228354ed69
- simply creating the dir solves it
- reported to author, let's hope for an -rc2 fix.
- better logging when DEBUG=yes (don't pass "-s"(ilent) to make clean)
This brings the patch set up to 2023-06-22 wireless-next
Drivers tested;
8822CS. 8821CU and 8723DS
Notables;
Not seeing random dmesg spam `rtw_8822cs failed to get tx report from firmware` which I would see on both the CS and CU from time to time.
Signed-off-by: Patrick Yavitz <pyavitz@gmail.com>
Patch set includes a complete backport of RTW88 as it currently stands, along with extras
Extra:
Patch: RTL8723DS (SDIO)
Patch: _rtw_download_firmware() warn: missing unwind goto?
Hack: SDIO RX Aggregation Limiting
I only have two units available to me with an 8822CS module and in my testing this is only required on the BPI-CM4IO. With out LIMITING the unit will either kernel panic or not be able to send or receive.
This is currently being looked into:
https://lore.kernel.org/linux-wireless/CAFBinCBaXtebixKbjkWKW_WXc5k=NdGNaGUjVE8NCPNxOhsb2g@mail.gmail.com/T/#u
It may be possible to just set LIMITING across all builds, but that to me seems like a poor choice. This requires testing.
Signed-off-by: Patrick Yavitz <pyavitz@gmail.com>
