[PATCH v2] iwinfo: add missing CIPHER_NAMES and KMGMT_NAMES
This happens while parse crypto info in Lua.
Signed-off-by: Jianhui Zhao
---
Changes v1 -> v2:
- Add description in commit message
Signed-off-by: Paul Spooren
---
iwinfo_lib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/iwinfo_lib.c b/iwinfo_lib.c
index 70b080c..7fa8133 100644
--- a/iwinfo_lib.c
+++ b/iwinfo_lib.c
@@ -31,12 +31,15 @@ const char *IWINFO_CIPHER_NAMES[] = {
"WEP104",
"AES-OCB",
"CKIP",
+ "GCMP"
};
const char *IWINFO_KMGMT_NAMES[] = {
"NONE",
"802.1X",
"PSK",
+ "SAE",
+ "OWE"
};
const char *IWINFO_AUTH_NAMES[] = {
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On Fri, Oct 1, 2021 at 3:05 PM Hauke Mehrtens wrote: > > On 9/30/21 10:40 PM, Paul Spooren wrote: > > > > On 9/30/21 10:01, Nick wrote: > >> > >> On 9/30/21 21:43, Daniel Golle wrote: > >>> On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote: > On 30/09/2021 01:19, Nick wrote: > > On 9/29/21 22:28, Hauke Mehrtens wrote: > > > >> kernel 5.10: > >> We should get all targets to kernel 5.10. All targets which are not > >> on kernel 5.10 when we branch off should get removed. > > Kernel 5.15 could be also a LTS Kernel that should be released in the > > end of October? Why not aiming for it if we plan to release in 2022? > This would undoubtedly delay the next release, as we've seen in the > past. We don't even have all targets on 5.10, which was released > roughly > 9 months ago. You do the math. If we target 5.15, I doubt we'll even > see > a release in 2022. > >>> I also believe we should do the next release based on Linux 5.10 and > >>> try branching still this year (which I believe is realistic to make all > >>> targets build with 5.10 till then), so we can target April 2022 as time > >>> of release. > > I agree with you Daniel and think this timeline is reasonable. > > >> Sounds good, so we can go on with 5.15 when it is released? > > > > Some targets already moved to 5.10 as default, feel free to add 5.15 as > > the new TESTING kernel there. > > I am against adding support for kernel 5.15 now, we should better wait > till after we branched the relase off. > > > > >> I think the most problematic thing is if we want to have DSA support > >> for all targets as requirement. Not sure if this is possible. > > > > It seems fine found a okay'ish middle ground between DSA and non-DSA, so > > I'd not make DSA blocking for the next release but continue to integrate > > it where ever possible (and stable). > > I think we will never convert all swconfig drivers to DSA. I do not > think anyone will invest the time to write a DSA driver for the ADM6996L > chip for example. It could be that we just remove support for the last > boards which still use swconfig in some years. Not that many look like they can get DSA treatment. With realtek switches, only RTL8366RB seems supported upstream. ar8216 can be replaced by qca8k currently but lots of testing is needed. I have no idea about mediatek and why it has an swconfig driver when there's a DSA one upstream. > > Hauke > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 9/30/21 3:34 AM, Rich Brown wrote: Hauke: My thanks also for writing up those note. My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in September. And so on - every six months (or whatever interval we believe we can sustain for the long term.) I would decide about the name when we branch, currently I would also target to branch end of the year and then do the release in March. This all depends on how much time people have. I would prefer to not do more then one release per year, at least I do not have the resources to manage that. If more people take over maintaining and also fixing bugs it would be nice and possible. The problem in the past was not that we didn't had the good plan to make more releases, but the lack of man power. For each release, we need to work backwards, and make the feature freeze for the March release in, say, early January so the first RC can come out in January, we can have a few RCs leading up to a final release sometime within 60-75 days. The reasons to do this: - Some people can only use stable releases because of their business needs or their personality. (Or because we tell them "Only Use Stable!") Regular releases let them use the newest features. - Contrarily, a long release cycle "traps" new stuff behind something that "isn't quite done." - We don't waste time producing and testing patched versions of the previous release. There were seven patch releases in the 19.07 series (running from January 2020 through August 2021). A regular release schedule could have avoided many of these. - Having a firm feature freeze date decreases stress. If a particular feature is done/substantially working, it goes in. If it's not quite ready, it can skip this release, and get into the next release. (The alternative is what I think happened with DSA. It was a big change: there were a large number of problems that took a long time to iron out. That kept pushing out the date...) What happens if some parts are already in master and the rest is missing? Some targets already used DSA, but the configuration was not really supported in UCI and LuCI last time. With a fixed feature freeze we would have released without Luci support to configure some switches. - Customers (our users, our industry partners) gain confidence in projects that can meet their deadlines. Imre noted that "industry is using the snapshots..." but I suspect the extended schedule just worries other vendors. Does this need a vote? Thanks. I would not do a vote about this. The problem is not coming to a decision, but finding people who execute this. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 9/30/21 10:40 PM, Paul Spooren wrote: On 9/30/21 10:01, Nick wrote: On 9/30/21 21:43, Daniel Golle wrote: On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote: On 30/09/2021 01:19, Nick wrote: On 9/29/21 22:28, Hauke Mehrtens wrote: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel 5.15 could be also a LTS Kernel that should be released in the end of October? Why not aiming for it if we plan to release in 2022? This would undoubtedly delay the next release, as we've seen in the past. We don't even have all targets on 5.10, which was released roughly 9 months ago. You do the math. If we target 5.15, I doubt we'll even see a release in 2022. I also believe we should do the next release based on Linux 5.10 and try branching still this year (which I believe is realistic to make all targets build with 5.10 till then), so we can target April 2022 as time of release. I agree with you Daniel and think this timeline is reasonable. Sounds good, so we can go on with 5.15 when it is released? Some targets already moved to 5.10 as default, feel free to add 5.15 as the new TESTING kernel there. I am against adding support for kernel 5.15 now, we should better wait till after we branched the relase off. I think the most problematic thing is if we want to have DSA support for all targets as requirement. Not sure if this is possible. It seems fine found a okay'ish middle ground between DSA and non-DSA, so I'd not make DSA blocking for the next release but continue to integrate it where ever possible (and stable). I think we will never convert all swconfig drivers to DSA. I do not think anyone will invest the time to write a DSA driver for the ADM6996L chip for example. It could be that we just remove support for the last boards which still use swconfig in some years. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] iwinfo: add missing CIPHER_NAMES and KMGMT_NAMES
Signed-off-by: Jianhui Zhao
---
iwinfo_lib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/iwinfo_lib.c b/iwinfo_lib.c
index 70b080c..7fa8133 100644
--- a/iwinfo_lib.c
+++ b/iwinfo_lib.c
@@ -31,12 +31,15 @@ const char *IWINFO_CIPHER_NAMES[] = {
"WEP104",
"AES-OCB",
"CKIP",
+ "GCMP"
};
const char *IWINFO_KMGMT_NAMES[] = {
"NONE",
"802.1X",
"PSK",
+ "SAE",
+ "OWE"
};
const char *IWINFO_AUTH_NAMES[] = {
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
cc1 execv: Exec format error, on macOS 11.6 Xcode 13.0
I just noticed that building from an empty directory fails on macOS 11.6 with Xcode 13.0. This is likely due to some build script not recognising the latest version of Xcode or clang. As a result cc1 is compiled for unknown architecture, and cannot be executed on the host: cc1:file format coff- staging_dir/toolchain-mips_24kc_gcc-11.2.0_musl/libexec/gcc/mips-openwrt-linux-musl/11.2.0/cc1 `objdump -x cc1` on the old build returns: cc1:file format mach-o 64-bit x86-64 clang --version Apple clang version 13.0.0 (clang-1300.0.29.3) Target: x86_64-apple-darwin20.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Can anyone please point me where the checks are made and how to try fixing this? I would be happy to contribute a PR, I just need a bit of help to get started. Complete build log: https://httpstorm.com/support/openwrt/2021-10-01/ Error message: checking whether C compiler works... no; compiler output follows: mips-openwrt-linux-musl-gcc: fatal error: cannot execute '/Volumes/wrt3200/openwrt/staging_dir/toolchain-mips_24kc_gcc-11.2.0_musl/libexec/gcc/mips-openwrt-linux-musl/11.2.0/cc1': execv: Exec format error Short log: make[3]: Entering directory '/Volumes/wrt3200/openwrt/toolchain/musl' mkdir -p /Volumes/wrt3200/openwrt/dl SHELL= flock /Volumes/wrt3200/openwrt/tmp/.musl-1.2.2.tar.gz.flock -c ' /Volumes/wrt3200/openwrt/scripts/download.pl "/Volumes/wrt3200/openwrt/dl" "musl-1.2.2.tar.gz" "9b969322012d796dc23dda27a35866034fa67d8fb67e0e2c45c913c3d43219dd" "" "https://musl.libc.org/releases/;' + curl -f --connect-timeout 20 --retry 5 --location --insecure https://musl.libc.org/releases/musl-1.2.2.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1030k 100 1030k0 0 497k 0 0:00:02 0:00:02 --:--:-- 497k . /Volumes/wrt3200/openwrt/include/shell.sh; gzip -dc /Volumes/wrt3200/openwrt/dl/musl-1.2.2.tar.gz | tar -C /Volumes/wrt3200/openwrt/build_dir/toolchain-mips_24kc_gcc-11.2.0_musl/musl-1.2.2/.. -xf - [ ! -d ./src/ ] || cp -fpR ./src/* /Volumes/wrt3200/openwrt/build_dir/toolchain-mips_24kc_gcc-11.2.0_musl/musl-1.2.2 Applying ./patches/110-read_timezone_from_fs.patch using plaintext: patching file src/time/__tz.c Applying ./patches/200-add_libssp_nonshared.patch using plaintext: patching file Makefile patching file libssp_nonshared/__stack_chk_fail_local.c Applying ./patches/300-relative.patch using plaintext: patching file Makefile Applying ./patches/600-nftw-support-common-gnu-extension.patch using plaintext: patching file include/ftw.h patching file src/misc/nftw.c Applying ./patches/900-iconv_size_hack.patch using plaintext: patching file src/locale/iconv.c patching file src/locale/codepages.h Applying ./patches/901-crypt_size_hack.patch using plaintext: patching file src/crypt/crypt_sha512.c patching file src/crypt/crypt_blowfish.c patching file src/crypt/crypt_sha256.c touch /Volumes/wrt3200/openwrt/build_dir/toolchain-mips_24kc_gcc-11.2.0_musl/musl-1.2.2/.prepared881524106529731ec405d68938b4abdf_6664517399ebbbc92a37c5bb081b5c53 ln -snf musl-1.2.2 /Volumes/wrt3200/openwrt/build_dir/toolchain-mips_24kc_gcc-11.2.0_musl/musl ( cd /Volumes/wrt3200/openwrt/build_dir/toolchain-mips_24kc_gcc-11.2.0_musl/musl-1.2.2; rm -f config.cache; AR="mips-openwrt-linux-musl-gcc-ar" AS="mips-openwrt-linux-musl-gcc -c -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -DCRYPT_SIZE_HACK" LD=mips-openwrt-linux-musl-ld NM="mips-openwrt-linux-musl-gcc-nm" CC="mips-openwrt-linux-musl-gcc" GCC="mips-openwrt-linux-musl-gcc" CXX="mips-openwrt-linux-musl-g++" RANLIB="mips-openwrt-linux-musl-gcc-ranlib" STRIP=mips-openwrt-linux-musl-strip OBJCOPY=mips-openwrt-linux-musl-objcopy OBJDUMP=mips-openwrt-linux-musl-objdump SIZE=mips-openwrt-linux-musl-size CFLAGS="-pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -DCRYPT_SIZE_HACK" CROSS_COMPILE="mips-openwrt-linux-musl-" /Volumes/wrt3200/openwrt/build_dir/toolchain-mips_24kc_gcc-11.2.0_musl/musl-1.2.2/configure --prefix=/ --host=x86_64-apple-darwin20.6.0 --target=mips-openwrt-linux-musl --disable-gcc-wrapper --enable-debug --enable-optimize ); checking for C compiler... mips-openwrt-linux-musl-gcc checking whether C compiler works... no; compiler output follows: mips-openwrt-linux-musl-gcc: fatal error: cannot execute
[PATCH uci] cmake: Allow overwrite of install directories
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Use the GNUInstallDirs include to allow callers to overwrite the install
directories. This is helpful when building uci in build systems like
Yocto which prefer to use /usr/lib64 for the 64 bit libraries.
Signed-off-by: Hauke Mehrtens
---
CMakeLists.txt | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 560ed65..50e7f51 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,4 +1,5 @@
cmake_minimum_required(VERSION 2.6)
+INCLUDE(GNUInstallDirs)
PROJECT(uci C)
@@ -74,12 +75,12 @@ IF(UNIT_TESTING)
ENDIF()
INSTALL(FILES uci.h uci_config.h uci_blob.h ucimap.h
- DESTINATION include
+ DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
)
INSTALL(TARGETS uci cli
- ARCHIVE DESTINATION lib
- LIBRARY DESTINATION lib
- RUNTIME DESTINATION bin
+ ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+ LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+ RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
)
--
2.17.1
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] realtek: ensure output drivers are enabled in RTL8231
The bootloader can leave the GPIO expander in a state which doesn't have
output drivers enabled so GPIOs will properly work for input but output
operations will have no effect.
To avoid disrupting the boot in case the bootloader left direction and
data registers in an inconsistent state (e.g. pulling SoC's reset to 0)
reconfigure everything as input.
Reviewed-by: Sander Vanheule
Signed-off-by: Paul Fertser
---
Notes:
Changes from v2:
- Fix 5.10 as well
Changes from v1:
- Fix comment to mention we affect two extra GPIOs
- Remove unused "v" declaration.
.../realtek/files-5.10/drivers/gpio/gpio-rtl8231.c | 12 +++-
.../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c| 12 +++-
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
b/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
index a8ffcdc31368..f4f5621e0c1b 100644
--- a/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
+++ b/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
@@ -239,8 +239,6 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned int
offset, int value)
int rtl8231_init(struct rtl8231_gpios *gpios)
{
- u32 v;
-
pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios->smi_bus_id);
gpios->reg_cached = 0;
@@ -254,11 +252,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
- /* Select GPIO functionality for pins 0-34 */
+ /* Select GPIO functionality and force input direction for pins 0-36 */
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
- v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
- rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
+
+ /* Set LED_Start to enable drivers for output mode */
+ rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);
return 0;
}
diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
index a8ffcdc31368..f4f5621e0c1b 100644
--- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
+++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
@@ -239,8 +239,6 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned int
offset, int value)
int rtl8231_init(struct rtl8231_gpios *gpios)
{
- u32 v;
-
pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios->smi_bus_id);
gpios->reg_cached = 0;
@@ -254,11 +252,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
- /* Select GPIO functionality for pins 0-34 */
+ /* Select GPIO functionality and force input direction for pins 0-36 */
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
- v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
- rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
+
+ /* Set LED_Start to enable drivers for output mode */
+ rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);
return 0;
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Hello all!! My 2 cents here... An important part of the whole project is upstreaming patcvhes as much as possible, to try to keep the maintenance burden to an acceptable level. We do so, and there have been very nice efforts. I think we might try to do so more aggressively if we think we want to release more often. I have no opinion on this actually, but I am under the impression we are accumulating a good number of patches and this might slow us down somewhat. Thanks a lot for your great work folks!! Enrico On Thu, 30 Sep 2021, Rosen Penev wrote: Date: Fri, 1 Oct 2021 02:37:08 From: Rosen Penev To: Nick Cc: OpenWrt Development List Subject: Re: Release goals for 22.XX On Thu, Sep 30, 2021 at 1:05 PM Nick wrote: On 9/30/21 21:43, Daniel Golle wrote: On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote: On 30/09/2021 01:19, Nick wrote: On 9/29/21 22:28, Hauke Mehrtens wrote: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel 5.15 could be also a LTS Kernel that should be released in the end of October? Why not aiming for it if we plan to release in 2022? This would undoubtedly delay the next release, as we've seen in the past. We don't even have all targets on 5.10, which was released roughly 9 months ago. You do the math. If we target 5.15, I doubt we'll even see a release in 2022. I also believe we should do the next release based on Linux 5.10 and try branching still this year (which I believe is realistic to make all targets build with 5.10 till then), so we can target April 2022 as time of release. Sounds good, so we can go on with 5.15 when it is released? I think the most problematic thing is if we want to have DSA support for all targets as requirement. Not sure if this is possible. Don't think so. I think some platforms will get DSA. Bests Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: initramfs for ACPI tables on x86
On 30/09/21 15:04, Daniel Golle wrote: On Thu, Sep 30, 2021 at 02:49:57PM +0200, Florian Eckert wrote: Since the update of kernel from 5.4 to 5.10 in the openwrt master branch [1], I have problems with additional hardware on the I2C (SMBus) of my APU3. The Linux upstream removed the platform data support for my I2C IO-Expander mcp23s08 [3]. Because of this change I could not use my own written platform device specification anymore. This is common for this kind of device on x86 which does not support device-tree. See for exaple the platform init on the x86 geode board.[5] If the device supports ACPI, this is now the why to do this [6]. I am still in the process of building the SSDT ACPI table for the i2c mcp23s08 device connect to the SMBus. As I now know we could load these SSTD into the kernel during operation or via an initrd on boot. you can also load tables from configfs (if you enable that on kernel compile time). See the kernel documentation about this feature https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html As far as I have seen, no initrd is loaded during normal operation [4] on OpenWrt. Is there any way to create an initrd to load the ACPI tables and then mount the initrd so the kernel can load this kind of files? What would this look like in OpenWrt? I think it should be just as fine to load them early during boot, ie. place a script in /lib/preinit/ which does that. On boards with coreboot like the apu3 the best would probably be to fix ACPI tables supplied by the BIOS (or swap SeaBIOS for an UEFI implementation like Tianocore at the same time) instead of patching things using Linux at runtime. This isn't a fix, he has added hardware on I2C that is not on standard on APU3. Although yes he could compile a custom coreboot with this ACPI table modification baked in. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
