Firmware image signing in append-metadata/append-gl-metadata was conditional
only by the presence of the build key. Add an explicit SIGN_FIRMWARE option
(default enabled except with BUILDBOT) so appending the fwtool signature can be
toggled on its own.
It's disable on buildbot since we use a decentralized building with no
individual keys on builders. Instead, a fake key is currently used, which adds
an insecure signature.
The future of signing firmware and key distribution across the build
infrastructure should be discussed separately.
Link: https://github.com/openwrt/openwrt/pull/24291
Signed-off-by: Paul Spooren <mail@aparcar.org>
Currently assembly code of the Kernel may contain the build path, resulting in
unreproducible firmware images (and Kernels). Fix this by adding a iremap
KAFLAG.
Before:
strings "/path/to/vmlinux" | grep linux-6.18.38
/path/to/openwrt/build_dir/target-x86_64_musl/linux-x86_64/linux-6.18.38
/path/to/openwrt/build_dir/target-x86_64_musl/linux-x86_64/linux-6.18.38
After
strings "/path/to/vmlinux" | grep linux-6.18.38
target-x86_64_musl/linux-x86_64/linux-6.18.38
target-x86_64_musl/linux-x86_64/linux-6.18.38
Link: https://github.com/openwrt/openwrt/pull/24271
Signed-off-by: Paul Spooren <mail@aparcar.org>
Fix a warning interpreted as error when building the Linux kernel
on macOS host, by setting MACOSX_DEPLOYMENT_TARGET to the version
of the host. Fixes:
make[5]: Entering directory '/Volumes/test/openwrt/build_dir/target-x86_64_musl/linux-x86_64/linux-6.18.38'
HOSTCC scripts/mod/modpost.o
scripts/mod/modpost.c:1719:9: error: 'strchrnul' is only available on macOS 15.4 or newer [-Werror,-Wunguarded-availability-new]
1719 | sep = strchrnul(namespace, ',');
| ^~~~~~~~~
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24251
Signed-off-by: Robert Marko <robimarko@gmail.com>
Extend the git-src source tree override to host builds. It is opt-in via
HOST_USE_GIT_SRC, since by default the host build keeps using the tarball.
Move the git-src detection and checkout recipe into unpack.mk so both the
target and host build reuse the same code.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This commit statically sets SOURCE_DATE_EPOCH to 0, which causes `apk mkpkg` to
drop the date from generated packages. This improves reproducibility while
leaving package specific SOURCE_DATE_EPOCH untouched. The latter can be
interesting for i.e. packages like busybox, which prominently show that date on
the login shell.
Without this commit, packages that live inside feed repositories (openwrt.git,
packages.git etc) like `mtd` or `attendedsysupgrade-common` would have random
timestamps since no "full" git log was available.
Below an example with different source dates (0, 1):
│ 0755 root:wheel - - /
│ 0755 root:wheel - - lib/
│ 0755 root:wheel - - lib/apk/
│ 0755 root:wheel - - lib/apk/packages/
│ -0644 root:wheel 1970-01-01T00:00:01Z 10 lib/apk/packages/mtd.list
│ +0644 root:wheel - 10 lib/apk/packages/mtd.list
│ 0755 root:wheel - - sbin/
│ -0755 root:wheel 1970-01-01T00:00:01Z 24595 sbin/mtd
│ +0755 root:wheel - 24595 sbin/mtd
Link: https://github.com/openwrt/openwrt/pull/24005
Signed-off-by: Paul Spooren <mail@aparcar.org>
Split kmod-nf-nathelper-extra into separate helper packages
and keep the original package as a compatibility meta-package.
This allows selecting only the required protocol helpers
instead of installing all helper modules and dependencies.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/23690
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Apple g++ check is really clang in disguise. Furthermore, testing on
Linux hosts reveals that clang can sufficiently replace gcc.
Minimum version of clang is 12 because of ccache.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17259
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Published sources archives may contain a mixture of MTIMEs, so taking the time
of the first file found varies based on filesystem order. To fix this, sort all
MTIMEs and take the latest.
Since piping into a file directly creates that file, we also need to
specifically tell `find` to ignore `version.date`.
Furthermore, move this prior to the ./src copy step, since for some packages,
the OpenWrt build system ships extra ./src files, which would introduce the
wrong timestamps again.
Fix: e36c2946b7 build: derive PKG_SOURCE_DATE_EPOCH from the unpacked source tree
Link: https://github.com/openwrt/openwrt/pull/23756
Signed-off-by: Paul Spooren <mail@aparcar.org>
Commit 042996b46b ("build: stricter hash validation on download")
refactored the $(if) in wrap_mirror from a single line to multiple lines.
The else branch (used when MIRROR is empty) was moved to a new line without
a trailing backslash on the preceding line. This causes download methods
that use wrap_mirror (e.g. git) to fail when PKG_SOURCE_MIRROR is 0:
SHELL= flock ...flock -c ' ...
bash: -c: line 1: unexpected EOF while looking for matching `''
The fix is to add the missing \ to the else branch.
Signed-off-by: Karsten Sperling <ksperling@apple.com>
c3e31b6a9b (2019-07-03), 5f8e587240 (2019-10-02), and 802bfe0806
(2022-10-20) disabled kernel stack validation when the build host was
not running Linux, as the objtool kernel build tool required for stack
validation was not portable to other build host environments. This is no
longer true, and it is not necessary to attempt to disable kernel stack
validation any longer.
Signed-off-by: Mark Mentovai <mark@mentovai.com>
Link: https://github.com/openwrt/openwrt/pull/23612
Signed-off-by: Robert Marko <robimarko@gmail.com>
Previously PKG_SOURCE_DATE_EPOCH came from a git log on the OpenWrt
package directory. That fails in shallow feed clones and in the SDK
(no .git), collapsing to the script's mtime and breaking .apk
reproducibility across SDK rebuilds and between buildbot and SDK.
With this comment, PKG_UNPACK generates a version.date file, later used to
determine a reproducible SOURCE_DATE_EPOCH. Since unpack happens after
download, the evaluation of SOURCE_DATE_EPOCH is now lazy, invoking the
`get_source_date_epoch.sh` script on every use.
While at it, drop export of PKG_SOURCE_DATE_EPOCH and clean it from the
ipkg-build script.
Link: https://github.com/openwrt/openwrt/issues/21579
Link: https://github.com/openwrt/openwrt/pull/21587
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23576
Signed-off-by: Paul Spooren <mail@aparcar.org>
In commit d89cb72c23 , a new rootfs type "targz" was introduced, to correctly pack the rootfs AFTER `DEVICE_PACKAGES` installation (unlike the old simple `rootfs.tar.gz`) .
The expected release artifact shall be a single corresponding tar gz release accompanying or relacing the old simple `rootfs.tar.gz`.
However, if one take a look at the v25.12 series release download pages, e.g. [25.12.4/x86/64](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/), one could see that there're now four release artifacts related to rootfs targz:
- [generic-targz-combined-efi.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-combined-efi.img.gz)
- [generic-targz-combined.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-combined.img.gz)
- [generic-targz-rootfs.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-rootfs.img.gz)
- [rootfs.tar.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-rootfs.tar.gz)
It's obvious the new `targz` release actually reuses the same `TARGET_ROOTFS_{TYPE}` handler same as `squashfs`, `ext4` and alike. And the three `generic-targz` img.gz contains the same expected tar gz either as their second partition, or as the whole image. This could be verified by the following script:
```bash
URL_PARENT=https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-
for TYPE in combined-efi combined rootfs; do
curl -L "${URL_PARENT}generic-targz-${TYPE}.img.gz" | gzip -cd > "${TYPE}.img"
done
for TYPE in combined-efi combined; do
INFO=$(sfdisk -d "${TYPE}.img" | sed -n 's/^'"${TYPE}.img"'2 : start= \+\([0-9]\+\), size= \+\([0-9]\+\),.\+.\+$/\1 \2/p')
dd if="${TYPE}.img" of="${TYPE}.tar.gz" bs=512 skip="${INFO%% *}" count="${INFO##* }"
done
cp rootfs.img rootfs.tar.gz
sha256sum combined-efi.tar.gz combined.tar.gz rootfs.tar.gz
file rootfs.tar.gz
```
Output:
```log
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13.12M 100 13.12M 0 0 194.6M 0 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 12.93M 100 12.93M 0 0 190.9M 0 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7.13M 100 7.13M 0 0 257.6M 0 0
GPT PMBR size mismatch (246304 != 246334) will be corrected by write.
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
The backup GPT table is not on the end of the device.
212992+0 records in
212992+0 records out
109051904 bytes (109 MB, 104 MiB) copied, 0.258064 s, 423 MB/s
212992+0 records in
212992+0 records out
109051904 bytes (109 MB, 104 MiB) copied, 0.261621 s, 417 MB/s
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 combined-efi.tar.gz
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 combined.tar.gz
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 rootfs.tar.gz
rootfs.tar.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 0
```
The checksum of the extracted, actually expected .tar.gz are all same. And if we peek inside its content, it's indeed what we expected:
```
> tar -tzf rootfs.tar.gz
./
./bin/
./bin/ash
./bin/board_detect
./bin/busybox
./bin/cat
./bin/chgrp
./bin/chmod
./bin/chown
./bin/config_generate
./bin/cp
./bin/date
...
```
A disk image with a `tar.gz` as its second partiton doesn't boot anyway and I doubt if there's any mechanic to make it bootable. So `generic-targz-combined-efi.img.gz` and `generic-targz-combined.img.gz` are not needed at all, and `generic-targz-rootfs.img.gz` shall be renamed to have a `tar.gz` suffix instead.
Therefore work around this by skipping creating images for fs `targz` in the general loop, and only create the rootfs.tar.gz later for `targz` "fs"
This affects both the real builder and imagebuilder. I've tested this with multiple imagebuilders.
Tested with `openwrt-imagebuilder-25.12.4-mvebu-cortexa53.Linux-x86_64`:
```sh
rm -rf bin && make image PROFILE=generic
```
Without the fix:
```
> tree bin/
bin/
└── targets
└── x86
└── 64
├── openwrt-25.12.4-x86-64-generic.bom.cdx.json
├── openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-kernel.bin
├── openwrt-25.12.4-x86-64-generic.manifest
├── openwrt-25.12.4-x86-64-generic-rootfs.tar.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-rootfs.img.gz
├── profiles.json
└── sha256sums
```
With the fix:
```
> tree bin/
bin/
└── targets
└── x86
└── 64
├── openwrt-25.12.4-x86-64-generic.bom.cdx.json
├── openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-kernel.bin
├── openwrt-25.12.4-x86-64-generic.manifest
├── openwrt-25.12.4-x86-64-generic-rootfs.tar.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-rootfs.tar.gz
├── profiles.json
└── sha256sums
```
And with `openwrt-imagebuilder-25.12.4-mvebu-cortexa53.Linux-x86_64`:
```sh
rm -rf bin && make image PROFILE=ripe_atlas-v5
```
Without the fix:
```
> tree bin/
bin/
└── targets
└── mvebu
└── cortexa53
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.bom.cdx.json
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-ext4-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.manifest
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-rootfs.tar.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-squashfs-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-targz-sdcard.img.gz
├── profiles.json
└── sha256sums
```
With the fix:
```
> tree bin/
bin/
└── targets
└── mvebu
└── cortexa53
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.bom.cdx.json
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-ext4-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.manifest
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-rootfs.tar.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-squashfs-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-targz-rootfs.tar.gz
├── profiles.json
└── sha256sums
```
Signed-off-by: Guoxin Pu <pugokushin@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23570
Signed-off-by: Robert Marko <robimarko@gmail.com>
The wildcard combined an apk_package_files pattern of $(pkg)-*.apk with a
gen_package_wildcard that ends in [^a-z]*, so the full glob required two
dashes. Files for packages without an ABI version (e.g. ubbf-0~....apk)
only contain one dash and never matched, so ipkg-remove was never called
on them and stale .apk files accumulated in the bin directory.
Drop the explicit dash from apk_package_files. The [^a-z] in
gen_package_wildcard already serves as the dash matcher, and
scripts/ipkg-remove filters precisely by reading apk metadata.
Fixes: 642d568b0f ("build: fix ipkg-remove: add support for removing apk files")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
When using imagebuilder to create images, ROOTFS_FILESYSTEM may be
defined to create just the desired images, but the '*-rootfs.tar.gz'
and '*-rootfs.cpio.gz' images are being created unconditionally
for many targets.
By making generation of these images conditional on the state of
ROOTFS_FILESYSTEM, we can save significant space (measured 3-7 MB
depending on length of package list) and time.
Signed-off-by: Eric Fahlgren <ericfahlgren@gmail.com>
The ImageBuilder creates by default all filesystems enabled during it's own
build, which are typically squashfs and sometimes ext4.
This commit allows to set ROOTFS_FILESYSTEM to specify which specific
filesystem should be build (instead of all).
Motivation is to reduce the load on sysupgrade servers but also fix corner
cases where a squashfs filesystem results in a working image while the ext4
image fails, resulting in a ImageBuilder failure.
Signed-off-by: Paul Spooren <mail@aparcar.org>
This commit adds additional information to the apk database. This new tags
are required for SBOM generation.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
On u-boot v2026.04, we need to add PKG_CONFIG_SYSROOT_DIR flag to
fix in-tree dtc tools build without yaml[1-2]. Fixes:
/usr/bin/ld: yamltree.c:(.text+0xa7c): undefined reference to `yaml_sequence_start_event_initialize'
/usr/bin/ld: yamltree.c:(.text+0xa87): undefined reference to `yaml_emitter_emit'
/usr/bin/ld: yamltree.c:(.text+0xaa4): undefined reference to `yaml_sequence_end_event_initialize'
/usr/bin/ld: yamltree.c:(.text+0xaaf): undefined reference to `yaml_emitter_emit'
/usr/bin/ld: yamltree.c:(.text+0xac1): undefined reference to `yaml_document_end_event_initialize'
/usr/bin/ld: yamltree.c:(.text+0xacc): undefined reference to `yaml_emitter_emit'
/usr/bin/ld: yamltree.c:(.text+0xadc): undefined reference to `yaml_stream_end_event_initialize'
/usr/bin/ld: yamltree.c:(.text+0xae7): undefined reference to `yaml_emitter_emit'
/usr/bin/ld: yamltree.c:(.text+0xaf3): undefined reference to `yaml_emitter_delete'
[1] https://github.com/u-boot/u-boot/commit/0535e46d55d7423094d8b553d704a0f7f678de77
[2] https://github.com/u-boot/u-boot/commit/807bcd844afeadbfe47ac132524cc7e3b699bc46
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Specification:
The device is similar to the M30 but has only one LAN port and no WAN port.
- MT7981 CPU using 2.4GHz and 5GHz WiFi (both AX)
- 512MB RAM
- 128MB NAND flash with two UBI partitions with identical size
- 1 multi color LED (red, green, blue, white) connected via GCA230718
- 2 buttons (WPS, reset, LED)
- 1 1Gbit LAN port
Disassembly:
- There are two screws at the power connector which must be removed. Afterwards the top case can be removed (it is clipped on, so some tools are required).
Serial Interface:
- The serial interface can be connected to the 4 pin holes on the board. Do NOT connect VCC.
- The pins are labelled on the PCB (RX, TX, GND)
- Settings: 115200, 8N1
MAC addresses:
- LAN MAC is stored in partition "Odm" at offset 0x8f
- WLAN MAC (2.4 GHz and 5GHz) is LAN MAC + 1
Reverting back to OEM firmware:
- There is currently no easy way to revert back to the OEM image
- The methods from M30 and M60 doesn't seem to work anymore
- If you plan to revert back to OEM firmware later, do the following steps before flashing OpenWrt:
- Boot from initramfs as described in "Flashing via U-Boot" but don't flash anything
- Instead, make a backup of UBI and UBI1 partition
- The created dumps must be written to the initial partitions to revert back to OEM
Flashing via Recovery Web Interface:
- Set your IP address to 192.168.200.10, subnetmask 255.255.255.0
- Press the reset button while powering on the device
- Keep the reset button pressed until the LED blinks red
- Open a Chromium based and goto http://192.168.200.50/ (recovery web interface)
- Download openwrt-mediatek-filogic-dlink_aquila-pro-ai-e30-a1-squashfs-recovery.bin
- Note: The recovery web interface always reports successful flashing, even if it fails
- After flashing, the recovery web interface will try to forward the browser to 192.168.0.1 (can be ignored)
- If flashing was successful, OpenWrt is accessible via 192.168.1.1
- The recovery image boots an initramfs image, flash the sys upgrade image to get to „normal“ OpenWrt mode
Flashing via U-Boot:
- Open the case, connect to the UART console
- Set your IP address to 192.168.200.2, subnet mask 255.255.255.0. Connect to one of the LAN interfaces of the router
- Run a tftp server which provides openwrt-mediatek-filogic-dlink_aquila-pro-ai-e30-a1-initramfs-kernel.bin
- Supply the board with 12V
- Select "7. Load image" in the U-Boot menu
- Enter image file, tftp server IP and device IP (if they differ from the default).
- TFTP download to RAM will start. After a few seconds OpenWrt initramfs should start
- The initramfs is accessible via 192.168.1.1, change your IP address accordingly (or use multiple IP addresses on your interface)
- Perform a sysupgrade using openwrt-mediatek-filogic-dlink_aquila-pro-ai-e30-a1-squashfs-sysupgrade.bin
- Reboot the device. OpenWrt should start from flash now
Flashing via OEM web interface is not possible, as it will change the active partition and OpenWrt is only running on the first UBI partition.
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22776
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
ELF binaries embed the maximum page size used during linking in the
PT_LOAD segment alignment. If this value is larger than the actual
system page size, the kernel will still load the binary but wastes
memory due to over-alignment. If it is smaller, the binary may fail
to load or cause incorrect behavior with features like RELRO.
Most architectures use 4KB pages, but loongarch64 uses 16KB pages
(CONFIG_PAGE_SIZE_16KB). Explicitly pass -z max-page-size to the
linker so that binaries are built with the correct page alignment for
the target, avoiding issues with RELRO segment padding and ensuring
correct memory mapping on the target system.
Before binutils 2.39 RELRO sections were padded to common page size
which is 4K on MIPS, with binutils 3.29 the padding was changed to
max page size which is 64K on MIPS. With this change we will pad them to
4K again.
This reduces the size of user space binaries in OpenWrt.
The size of the uncompressed root file system of a mips malta be build
decreased by about 20%.
old file size:
```
$ du -s build_dir/target-mips_24kc_musl/root-malta/
15844 build_dir/target-mips_24kc_musl/root-malta/
```
New file size:
```
$ du -s build_dir/target-mips_24kc_musl/root-malta/
12564 build_dir/target-mips_24kc_musl/root-malta/
```
The size of the image did not decrease much because of the strong
compression used by OpenWrt.
Link: https://github.com/openwrt/openwrt/pull/22800
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
On Linux 6.18 the path-based symvers filter can
yield an empty tmp file for external modules.
Add a 6.18-only fallback using modules.order
to populate Module.symvers.tmp.
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://github.com/openwrt/openwrt/pull/21078
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add a build config option to sign each individual .apk package.
If individual .apk files are signed with the build key, they can be
installed with 'apk add' without '--allow-untrusted' to a firmware
compiled by the same buildhost.
Enable the option by default, but disable it for BUILDBOT.
(At the moment, since commit 084697e, only the package index is signed,
which forces users to use '--allow-untrusted' when installing
self-built .apk files.)
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
Not all targets need regulator support, so they dont enable it as its
disabled in the generic config by default.
So, in order to allow kernel modules to depend on regulator support lets
add a new feature flag "regulator" and set it automatically if target
kernel config enables CONFIG_REGULATOR.
Link: https://github.com/openwrt/openwrt/pull/22172
Signed-off-by: Robert Marko <robimarko@gmail.com>
The TARGET_CPPFLAGS contain the include paths used by OpenWrt. This also
contains the including of the fortify sources headers. If they are not
provided, the applications will not use fortify sources headers when
compiled against musl. Add them to cmake builds too. cmake does not
support a special CPPFLGS option [0], just add them to CFLAGS and
CXXFLAGS like we also do it for meson and normal make.
This should fix fortify sources support for cmake builds.
I found this explanation for the flags:
* CFLAGS: C flags, passed during compile AND link
* CXXFLAGS: C++ flags, passed during compile AND link
* CPPFLAGS: pre-processor flags, passed ONLY during compile
* LDFLAGS: linker flags, passed ONLY during link
[0]: https://gitlab.kitware.com/cmake/cmake/-/issues/12928
Link: https://github.com/openwrt/openwrt/pull/22042
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently, for targets that use the CONFIG_TARGET_ROOTFS_TARGZ a single
rootfs tarball is generated for the subtarget based of $(TARGET_DIR).
However, this means that it does not respect DEVICE_PACKAGES like other
rootfs images.
So, lets augment CONFIG_TARGET_ROOTFS_TARGZ by adding a proper targz fstype
so that per device rootfs is generated under lock.
This is required so that devices that use custom sysupgrade archives like
Methode devices, can actually include a per device rootfs so when building
for multiple devices and with CONFIG_TARGET_PER_DEVICE_ROOTFS set the built
image actually includes the listed DEVICE_PACKAGES.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Tianling Shen