[PATCH] imx: add imx8 support
Add imx8 support: - add a cortexa53 subtarget - move ARCH, KERNELNAME, and some FEATURES to cortexa7/cortexa9 subtargets - add a small series of backports from 6.2 to fix hang on USB init and add PCIe support No device-specific targets or firmware images are created yet. The resulting openwrt-imx-cortexa53-vmlinux-initramfs has been booted on Gateworks Venice boards and the imx8mm-evk using dtb's from $LINUX_DIR and verifying usb, pci, mmc, and fec networking work. Signed-off-by: Tim Harvey --- target/linux/imx/Makefile | 7 +- target/linux/imx/config-5.15 | 2 + target/linux/imx/cortexa53/config-default | 89 target/linux/imx/cortexa53/target.mk | 8 + target/linux/imx/cortexa7/target.mk | 3 + target/linux/imx/cortexa9/target.mk | 3 + target/linux/imx/image/cortexa53.mk | 10 + ...low-to-disable-individual-power-doma.patch | 35 ++ ...-gpcv2-Turn-domain-pgc-into-bitfield.patch | 327 + ...t-both-GPC_PGC_nCTRL-GPU_2D-GPU_3D-f.patch | 40 ++ ...soc-imx-gpcv2-add-lockdep-annotation.patch | 36 ++ ...d-domain-option-to-keep-domain-clock.patch | 60 +++ ...gpcv2-keep-i.MX8M-bus-clocks-enabled.patch | 69 +++ ...-gpcv2-support-system-suspend-resume.patch | 74 +++ .../0008-arm64-dts-imx8mm-add-GPC-node.patch | 142 ++ ...-put-USB-controllers-into-power-doma.patch | 38 ++ ...add-PGC-control-register-indirection.patch | 187 ...ie-Initialize-the-imx8-pcie-standalo.patch | 285 ...x8m-pcie-Add-iMX8MP-PCIe-PHY-support.patch | 305 ...phy-imx8-pcie-Add-binding-for-the-pa.patch | 38 ++ ...-PCI-imx-Add-the-imx8mm-pcie-support.patch | 211 + ...-dts-imx8mm-Add-the-pcie-phy-support.patch | 40 ++ ...rm64-dts-imx8mm-Add-the-pcie-support.patch | 67 +++ ...4-dts-imx8mm-venice-add-PCIe-support.patch | 437 ++ 24 files changed, 2508 insertions(+), 5 deletions(-) create mode 100644 target/linux/imx/cortexa53/config-default create mode 100644 target/linux/imx/cortexa53/target.mk create mode 100644 target/linux/imx/image/cortexa53.mk create mode 100644 target/linux/imx/patches-5.15/0001-soc-imx-gpcv2-allow-to-disable-individual-power-doma.patch create mode 100644 target/linux/imx/patches-5.15/0002-soc-imx-gpcv2-Turn-domain-pgc-into-bitfield.patch create mode 100644 target/linux/imx/patches-5.15/0003-soc-imx-gpcv2-Set-both-GPC_PGC_nCTRL-GPU_2D-GPU_3D-f.patch create mode 100644 target/linux/imx/patches-5.15/0004-soc-imx-gpcv2-add-lockdep-annotation.patch create mode 100644 target/linux/imx/patches-5.15/0005-soc-imx-gpcv2-add-domain-option-to-keep-domain-clock.patch create mode 100644 target/linux/imx/patches-5.15/0006-soc-imx-gpcv2-keep-i.MX8M-bus-clocks-enabled.patch create mode 100644 target/linux/imx/patches-5.15/0007-soc-imx-gpcv2-support-system-suspend-resume.patch create mode 100644 target/linux/imx/patches-5.15/0008-arm64-dts-imx8mm-add-GPC-node.patch create mode 100644 target/linux/imx/patches-5.15/0009-arm64-dts-imx8mm-put-USB-controllers-into-power-doma.patch create mode 100644 target/linux/imx/patches-5.15/0010-soc-imx-gpcv2-add-PGC-control-register-indirection.patch create mode 100644 target/linux/imx/patches-5.15/0011-phy-freescale-pcie-Initialize-the-imx8-pcie-standalo.patch create mode 100644 target/linux/imx/patches-5.15/0012-phy-freescale-imx8m-pcie-Add-iMX8MP-PCIe-PHY-support.patch create mode 100644 target/linux/imx/patches-5.15/0013-dt-bindings-phy-phy-imx8-pcie-Add-binding-for-the-pa.patch create mode 100644 target/linux/imx/patches-5.15/0014-PCI-imx-Add-the-imx8mm-pcie-support.patch create mode 100644 target/linux/imx/patches-5.15/0015-arm64-dts-imx8mm-Add-the-pcie-phy-support.patch create mode 100644 target/linux/imx/patches-5.15/0016-arm64-dts-imx8mm-Add-the-pcie-support.patch create mode 100644 target/linux/imx/patches-5.15/0017-arm64-dts-imx8mm-venice-add-PCIe-support.patch diff --git a/target/linux/imx/Makefile b/target/linux/imx/Makefile index 5fb7a4d339ef..1263484316c4 100644 --- a/target/linux/imx/Makefile +++ b/target/linux/imx/Makefile @@ -4,18 +4,15 @@ include $(TOPDIR)/rules.mk -ARCH:=arm BOARD:=imx BOARDNAME:=NXP i.MX -FEATURES:=audio display fpu gpio pcie rtc usb usbgadget squashfs targz nand ubifs boot-part rootfs-part -SUBTARGETS:=cortexa7 cortexa9 +FEATURES:=audio display fpu gpio pcie rtc usb usbgadget squashfs targz boot-part rootfs-part +SUBTARGETS:=cortexa7 cortexa9 cortexa53 KERNEL_PATCHVER:=5.15 include $(INCLUDE_DIR)/target.mk -KERNELNAME:=zImage dtbs - DEFAULT_PACKAGES += uboot-envtools mkf2fs e2fsprogs blkid $(eval $(call BuildTarget)) diff --git a/target/linux/imx/config-5.15 b/target/linux/imx/config-5.15 index 0c9b7d22b4e5..c45872d19c40 100644 --- a/target/linux/imx/config-5.15 +++ b/target/linux/imx/config-5.15 @@ -441,3 +441,5 @@ CONFIG_ZLIB_DEFLATE=y CONFIG_ZLIB_INFLATE=y CONFIG_ZSTD_COMPRESS=y CONFIG_ZSTD_DECOMPRESS=y
[PATCH uci 2/2] CI: Add github action
Add a github action to build uci and then execute the tests.
This first builds and installs libubox and then uses that dependency to
build and test uci.
clang 14 generates debug information in DWARF 5 format, but valgrind
19.0 does not support that. Install valgrind 20.0 from experimental
which supports it.
Signed-off-by: Hauke Mehrtens
---
I created a github pull request with these changes too:
https://github.com/openwrt/libubox/pull/2
.github/workflows/test.yml | 83 ++
1 file changed, 83 insertions(+)
create mode 100644 .github/workflows/test.yml
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
new file mode 100644
index 000..d76300d
--- /dev/null
+++ b/.github/workflows/test.yml
@@ -0,0 +1,83 @@
+name: 'Run tests'
+
+on:
+ push:
+
+jobs:
+ build_test:
+strategy:
+ matrix:
+include:
+ - compiler: "-DCMAKE_C_COMPILER=clang"
+ - compiler: "-DCMAKE_C_COMPILER=gcc"
+
+name: Build and run tests
+runs-on: ubuntu-latest
+container:
+ image: debian:bookworm
+
+steps:
+
+ - name: Add Debian experimental
+run: |
+ echo "deb http://deb.debian.org/debian/ experimental main" >>
/etc/apt/sources.list
+
+ - name: Install compiler
+run: |
+ apt update
+ apt install -y cmake build-essential lua5.1 pkgconf libjson-c-dev
liblua5.1-0-dev python3.11-venv clang libc++abi-dev libc++-dev
+ apt -t experimental install -y valgrind
+ useradd -ms /bin/bash buildbot
+
+ - name: Checkout libubox
+uses: actions/checkout@v3
+with:
+ repository: openwrt/libubox
+ path: libubox
+
+ - name: Checkout uci
+uses: actions/checkout@v3
+with:
+ path: uci
+
+ - name: Create build directory
+run: mkdir libubox-build
+
+ - name: Create build directory
+run: mkdir uci-build
+
+ - name: Create install directory
+run: mkdir install
+
+ - name: Fix permission
+run: chown -R buildbot:buildbot libubox-build libubox uci uci-build
install
+
+ - name: Run cmake (libubox)
+shell: su buildbot -c "sh -e {0}"
+working-directory: libubox-build
+run: cmake ../libubox -DCMAKE_INSTALL_PREFIX=../install
-DBUILD_LUA=false ${{ matrix.compiler }}
+
+ - name: Run build (libubox)
+shell: su buildbot -c "sh -e {0}"
+working-directory: libubox-build
+run: make
+
+ - name: Run install (libubox)
+shell: su buildbot -c "sh -e {0}"
+working-directory: libubox-build
+run: make install
+
+ - name: Run cmake (uci)
+shell: su buildbot -c "sh -e {0}"
+working-directory: uci-build
+run: cmake ../uci -DUNIT_TESTING=true
-DCMAKE_INSTALL_PREFIX=../install -DCMAKE_PREFIX_PATH=../install ${{
matrix.compiler }}
+
+ - name: Run build (uci)
+shell: su buildbot -c "sh -e {0}"
+working-directory: uci-build
+run: make
+
+ - name: Run tests (uci)
+shell: su buildbot -c "sh -e {0}"
+working-directory: uci-build
+run: make test
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uci 1/2] fuzz: Compile using libstd++
It looks like libfuzzer is compiled using libstd++ on Debian Bookworm
and not libc++. Using libc++ causes linking errors, use libstd++
instead.
Signed-off-by: Hauke Mehrtens
---
tests/fuzz/CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fuzz/CMakeLists.txt b/tests/fuzz/CMakeLists.txt
index 1533c46..f1b4a0d 100644
--- a/tests/fuzz/CMakeLists.txt
+++ b/tests/fuzz/CMakeLists.txt
@@ -4,7 +4,7 @@ MACRO(ADD_FUZZER_TEST name)
ADD_EXECUTABLE(${name} ${name}.c)
TARGET_COMPILE_OPTIONS(${name} PRIVATE -g -O1 -fno-omit-frame-pointer
-fsanitize=fuzzer,address,leak,undefined)
TARGET_INCLUDE_DIRECTORIES(${name} PRIVATE ${PROJECT_SOURCE_DIR})
- TARGET_LINK_OPTIONS(${name} PRIVATE -stdlib=libc++
-fsanitize=fuzzer,address,leak,undefined)
+ TARGET_LINK_OPTIONS(${name} PRIVATE -fsanitize=fuzzer,address,leak,undefined)
TARGET_LINK_LIBRARIES(${name} uci)
ADD_TEST(
NAME ${name}
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH libubox 1/2] fuzz: Compile using libstd++
It looks like libfuzzer is compiled using libstd++ on Debian Bookworm
and not libc++. Using libc++ causes linking errors, use libstd++
instead.
Signed-off-by: Hauke Mehrtens
---
tests/fuzz/CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fuzz/CMakeLists.txt b/tests/fuzz/CMakeLists.txt
index cca74fd..6114a7c 100644
--- a/tests/fuzz/CMakeLists.txt
+++ b/tests/fuzz/CMakeLists.txt
@@ -4,7 +4,7 @@ MACRO(ADD_FUZZER_TEST name)
ADD_EXECUTABLE(${name} ${name}.c)
TARGET_COMPILE_OPTIONS(${name} PRIVATE -g -O1 -fno-omit-frame-pointer
-fsanitize=fuzzer,address,leak,undefined)
TARGET_INCLUDE_DIRECTORIES(${name} PRIVATE ${PROJECT_SOURCE_DIR})
- TARGET_LINK_OPTIONS(${name} PRIVATE -stdlib=libc++
-fsanitize=fuzzer,address,leak,undefined)
+ TARGET_LINK_OPTIONS(${name} PRIVATE -fsanitize=fuzzer,address,leak,undefined)
TARGET_LINK_LIBRARIES(${name} ubox blobmsg_json json_script ${json})
ADD_TEST(
NAME ${name}
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH libubox 2/2] CI: Add github action
Add a github action to build libubox and then execute the tests.
clang 14 generates debug informations in DWARF 5 format, but valgrind
19.0 does not support that. Install valgrind 20.0 from experimental
which supports it.
Signed-off-by: Hauke Mehrtens
---
I created a github pull request with these changes too:
https://github.com/openwrt/libubox/pull/2
.github/workflows/test.yml | 61 ++
1 file changed, 61 insertions(+)
create mode 100644 .github/workflows/test.yml
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
new file mode 100644
index 000..c6cdf0d
--- /dev/null
+++ b/.github/workflows/test.yml
@@ -0,0 +1,61 @@
+name: 'Run tests'
+
+on:
+ push:
+
+jobs:
+ build_test:
+strategy:
+ matrix:
+include:
+ - compiler: "-DCMAKE_C_COMPILER=clang"
+ - compiler: "-DCMAKE_C_COMPILER=gcc"
+
+name: Build and run tests
+runs-on: ubuntu-latest
+container:
+ image: debian:bookworm
+
+steps:
+
+ - name: Add Debian experimental
+run: |
+ echo "deb http://deb.debian.org/debian/ experimental main" >>
/etc/apt/sources.list
+
+ - name: Install compiler
+run: |
+ apt update
+ apt install -y cmake build-essential lua5.1 pkgconf libjson-c-dev
liblua5.1-0-dev python3.11-venv clang
+ apt -t experimental install -y valgrind
+ useradd -ms /bin/bash buildbot
+
+ - name: Checkout libubox
+uses: actions/checkout@v3
+with:
+ path: libubox
+
+ - name: Create build directory
+run: mkdir build
+
+ - name: Fix permission
+run: chown -R buildbot:buildbot build libubox
+
+ - name: Run cmake
+shell: su buildbot -c "sh -e {0}"
+working-directory: build
+run: cmake ../libubox -DUNIT_TESTING=true ${{ matrix.compiler }}
+
+ - name: build
+shell: su buildbot -c "sh -e {0}"
+working-directory: build
+run: make
+
+ - name: Run tests
+shell: su buildbot -c "sh -e {0}"
+working-directory: build
+run: make test
+
+ - name: Show logs
+shell: su buildbot -c "sh -e {0}"
+working-directory: build
+run: cat Testing/Temporary/LastTest.log
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: hostapd + openssl issue
> Em 8 de mar. de 2023, à(s) 16:44, e9hack escreveu: > > Hi, > > I'm using hostapd with the radius server compiled in for wpa enterprise. This > does no longer work since the openssl upgrade to 3.0. When a wpa enterprise > client (Windows 10) tries to connect, the following error messages are shown > in the log file: > > Wed Mar 8 00:15:05 2023 daemon.notice hostapd: phy0-ap0: > CTRL-EVENT-EAP-STARTED xx:xx:xx:13:a3:xx > Wed Mar 8 00:15:05 2023 daemon.notice hostapd: phy0-ap0: > CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1 > Wed Mar 8 00:15:05 2023 daemon.notice hostapd: OpenSSL: Flushing X509 store > with ca_cert file > Wed Mar 8 00:15:05 2023 daemon.notice hostapd: phy0-ap0: > CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 > Wed Mar 8 00:15:05 2023 daemon.err hostapd: OpenSSL: DES encrypt failed Hi Hartmut I’m guessing this is occurring because DES has been moved to the legacy provider, which we are not installing. I’ll add a package for it shortly. /etc/ssl/openssl.cnf needs some attention as well. Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
hostapd + openssl issue
Hi, I'm using hostapd with the radius server compiled in for wpa enterprise. This does no longer work since the openssl upgrade to 3.0. When a wpa enterprise client (Windows 10) tries to connect, the following error messages are shown in the log file: Wed Mar 8 00:15:05 2023 daemon.notice hostapd: phy0-ap0: CTRL-EVENT-EAP-STARTED xx:xx:xx:13:a3:xx Wed Mar 8 00:15:05 2023 daemon.notice hostapd: phy0-ap0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1 Wed Mar 8 00:15:05 2023 daemon.notice hostapd: OpenSSL: Flushing X509 store with ca_cert file Wed Mar 8 00:15:05 2023 daemon.notice hostapd: phy0-ap0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 Wed Mar 8 00:15:05 2023 daemon.err hostapd: OpenSSL: DES encrypt failed Wed Mar 8 00:15:05 2023 daemon.notice hostapd: phy0-ap0: CTRL-EVENT-EAP-FAILURE xx:xx:xx:13:a3:xx When using hostapd compiled with wolfssl I don't see such problems. Since not all packages (wget, libssh2) support wolfssl I still use openssl. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] mvebu: add support for Fortinet FortiGate 50E
Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820). Specification: - SoC : Marvell Armada 385 88F6820 - RAM : DDR3 2 GiB (4x Micron MT41K512M8DA-107, "D9SGQ") - Flash: SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G) - Ethernet : 7x 10/100/1000 Mbps - LAN 1-5: Marvell 88E6176 - WAN 1, 2 : Marvell 88E1512 (2x) - LEDs/Keys: 18x/1x - UART : "CONSOLE" port (RJ-45, RS-232C level) - port : ttyS0 - settings : 9600bps 8n1 - assignment : 1:NC , 2:NC , 3:TXD, 4:GND, 5:GND, 6:RXD, 7:NC , 8:NC - note : compatible with Cisco console cable - HW Monitoring: nuvoTon NCT7802Y - Power: 12 VDC, 2 A - plug : Molex 5557-02R Flash instruction using initramfs image: 1. Power on FG-50E and interrupt to show bootmenu 2. Call "[R]: Review TFTP parameters.", check TFTP parameters and connect computer to "Image download port" in the parameters 3. Prepare TFTP server with the parameters obtained above 4. Rename OpenWrt initramfs image to "image.out" and put to TFTP directory 5. Call "[T]: Initiate TFTP firmware transfer." to download initramfs image from TFTP server 6. Type "r" key when the following message is showed, to boot initramfs image without flashing to spi-nor flash "Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?" 7. On initramfs image, backup mtd if needed minimum: - "firmware-info" - "kernel" - "rootfs" 7. On initramfs image, upload sysupgrade image to the device and perform sysupgrade 8. Wait ~200 seconds to complete flashing and rebooting. If the device is booted with stock firmware, login to bootmenu and call "[B]: Boot with backup firmware and set as default." to set the first OS image as default and boot it. Notes: - All "SPEED" LEDs(Green/Amber) of LAN and 1000M "SPEED" LEDs(Green) of WAN1/2 are connected to GPIO expander. There is no way to indicate link speed of networking device on Linux Kernel/OpenWrt, so those LEDs cannot be handled like stock firmware. On OpenWrt, use netdev(link) trigger instead. - Both colors of Bi-color LEDs on the front panel cannot be turned on at the same time. - "PWR" and "Logo" LEDs are connected to power source directly. - The following partitions are added for OpenWrt. These partitions are contained in "uboot" partition (0x0-0x1f) on stock firmware. - "firmware-info" - "dtb" - "u-boot-env" - "board-info" Image header for bootmenu tftp: 0x0 - 0xf : ? 0x10 - 0x2f : Image Name 0x30 - 0x17f: ? 0x180 - 0x183: Kernel Offset* 0x184 - 0x187: Kernel Length* 0x188 - 0x18b: RootFS Offset (ext2)* 0x18c - 0x18f: RootFS Length (ext2)* 0x190 - 0x193: DTB Offset 0x194 - 0x197: DTB Length 0x198 - 0x19b: Data Offset (jffs2) 0x19c - 0x19f: Data Length (jffs2) 0x1a0 - 0x1ff: ? *: required for initramfs image MAC addresses: (eth0): 70:4C:A5:xx:xx:7C (board-info, 0xd880 (hex)) WAN 1 : 70:4C:A5:xx:xx:7D WAN 2 : 70:4C:A5:xx:xx:7E LAN 1 : 70:4C:A5:xx:xx:7F LAN 2 : 70:4C:A5:xx:xx:80 LAN 3 : 70:4C:A5:xx:xx:81 LAN 4 : 70:4C:A5:xx:xx:82 LAN 5 : 70:4C:A5:xx:xx:83 Signed-off-by: INAGAKI Hiroshi --- v2 -> v3 - use netdev(link) trigger for all green:speed_* leds - update note in the commit message - fix typo in the commit message v1 -> v2 - fix baudrate in the commit message - add missing chip count of RAM in the commit message .../cortexa9/base-files/etc/board.d/01_leds | 9 + .../base-files/etc/board.d/02_network | 3 + .../base-files/lib/upgrade/fortinet.sh| 54 ++ .../base-files/lib/upgrade/platform.sh| 3 + .../boot/dts/armada-385-fortinet-fg-50e.dts | 491 ++ target/linux/mvebu/image/cortexa9.mk | 28 + 6 files changed, 588 insertions(+) create mode 100644 target/linux/mvebu/cortexa9/base-files/lib/upgrade/fortinet.sh create mode 100644 target/linux/mvebu/files/arch/arm/boot/dts/armada-385-fortinet-fg-50e.dts diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds index 2b045d0945..bfc589e6c0 100644 --- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds +++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds @@ -15,6 +15,15 @@ ctera,c200-v2) ucidef_set_led_usbport "usb2" "USB2" "green:usb-2" "usb1-port1" "usb2-port1" ucidef_set_led_usbport "usb3" "USB3" "green:usb-1" "usb1-port2" "usb2-port2" ;; +fortinet,fg-50e) + ucidef_set_led_netdev "wan1_link" "WAN1 Link" "green:speed_wan1" "eth1" "link" + ucidef_set_led_netdev "wan2_link" "WAN2 Link" "green:speed_wan2" "eth2" "link" + ucidef_set_led_netdev "lan1_link" "LAN1 Link" "green:speed_lan1" "lan1" "link" + ucidef_set_led_netdev "lan2_link" "LAN2 Link" "green:speed_lan2" "lan2" "link" + ucidef_set_led_netdev "lan3_link" "LAN3 Link" "green:speed_lan3" "lan3" "link" + ucidef_set_led_netdev
Re: OpenWrt @ Battlemesh
On 8.03.2023 02:25, Hauke Mehrtens wrote: Hi, Wireless Battlemesh v15 is coming up in May 8-14. https://battlemesh.org/BattleMeshV15 Battlemesh will take place this year in Calafou, Vallbona d'Anoia, Barcelona. We were thinking to do a OpenWrt meeting in parallel or before/after Battlemesh. I would like to know if it makes sense to organize an OpenWrt meeting at Battelmesh or before/after Battlemesh. I think we have 3 options. OpenWrt meetup at 7 and 8 of May. OpenWrt meetup at 14 and 15 of May. OpenWrt meetup sometime between 8 and 14 of May. I probably need to be back in Türkiye on 14th of May as the election will probably be on the 14th. So the first and last options work for me. If someone wants to do presentations or workshops we can do this also as part of the Battlemesh and offer it to everyone joining Battlemesh too. The main purpose of such a meetup would be to to align on some strategies on what to do next in OpenWrt and how to do it from my point of view. I've got some serious ideas that concerns everything about OpenWrt which I should properly discuss with you before I take it as a presentation. The advantage of doing it around Battlemesh is that we have to organize less ourselves. What do you think about this plan? Who would join such a meetup? I would. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
