Re: [OpenWrt-Devel] [Battlemesh] ImageBuilder frontend projects, or how to generate custom OpenWrt images
Hi, you should take look at the Freifunk Berlin firmware and the Gluon project: https://github.com/freifunk-berlin/firmware https://gluon.readthedocs.io/en/v2019.1.x/ The Freifunk Berlin firmware uses uci-defaults scripts quite a lot for setting default configuration or changing configuration on upgrades: https://github.com/freifunk-berlin/firmware-packages/tree/master/defaults Both projects are under active development and used by a lot of Freifunk communities in Germany. Best Philipp On Sun, Sep 29, 2019 at 11:55:15PM +0200, Baptiste Jonglez wrote: > Hi, > > In my community network we are changing the way we generate OpenWrt > firmware images, and I took this opportunity to look at the existing > methods based on the OpenWrt ImageBuilder and/or SDK. > > In the end, I found way more projects than I thought would exist! > > I documented everything I found here: > https://openwrt.org/docs/guide-developer/imagebuilder_frontends > > Please add any project that I may have missed, and feel free to fix or add > more > details if you don't like the description of your project. > > As a side-note, does anybody use uci-defaults scripts? > https://openwrt.org/docs/guide-developer/uci-defaults > It seems like the best way to implement customization without having to > update file templates with each OpenWrt release, but during my quick > overview tour I haven't noticed any project using this method. > > Thanks, > Baptiste > ___ > Battlemesh mailing list > battlem...@ml.ninux.org > https://ml.ninux.org/mailman/listinfo/battlemesh signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] toolchain/gcc: switch to version 8 by default
On 28.09.19 11:04, Daniel Golle wrote: Hi Paul, On Sat, Sep 28, 2019 at 10:44:48AM -1000, Paul Spooren wrote: Main motivation for this commit is the introduction of `-ffile-prefix-map=` which alows reproducible build path. Imho definitely a good reason to move forward with the switch to GCC 8. Compiling tested without errors on the following targets: * ath79 * brcm2708 * brcm63xx * ixp4xx * ramips * sunxi * x86 Signed-off-by: Paul Spooren --- Please let me know if I should compile more targets. Maybe try apm821xx and octeon as well to cover powerpc and mips64. I'll give it a shot tomorrow and run-test on ramips/mt76x8. I compiled some more I couldn't detect any compile problems, however I did not yet perform any runtime tests. The sizes for most images seems slightly smaller, I run a script to compare the sizes: - -993B /packages/mips_24kc/base/busybox_1.31.0-1_mips_24kc.ipk + 21B /packages/mips_24kc/base/dnsmasq_2.80-14_mips_24kc.ipk - -222B /packages/mips_24kc/base/dropbear_2019.78-2_mips_24kc.ipk + 196B /packages/mips_24kc/base/firewall_2019-09-18-383eb58f-1_mips_24kc.ipk + 16B /packages/mips_24kc/base/getrandom_2019-06-16-4df34a4d-3_mips_24kc.ipk + 20B /packages/mips_24kc/base/hostapd-common_2019-08-08-ca8c2bd2-1_mips_24kc.ipk + 5B /packages/mips_24kc/base/iw_5.0.1-1_mips_24kc.ipk - -16B /packages/mips_24kc/base/jshn_2019-06-16-ecf56174-1_mips_24kc.ipk - -13B /packages/mips_24kc/base/jsonfilter_2018-02-04-c7e938d6-1_mips_24kc.ipk - -16B /packages/mips_24kc/base/libblobmsg-json_2019-06-16-ecf56174-1_mips_24kc.ipk + 57B /packages/mips_24kc/base/libjson-c4_0.13.1-1_mips_24kc.ipk + 17B /packages/mips_24kc/base/libjson-script_2019-06-16-ecf56174-1_mips_24kc.ipk - -35B /packages/mips_24kc/base/libnl-tiny_0.1-5_mips_24kc.ipk + 4B /packages/mips_24kc/base/libubox20170601_2019-06-16-ecf56174-1_mips_24kc.ipk + 17B /packages/mips_24kc/base/libubus20170705_2018-10-06-221ce7e7-1_mips_24kc.ipk + 21B /packages/mips_24kc/base/libuci20130104_2019-09-01-415f9e48-3_mips_24kc.ipk - -32B /packages/mips_24kc/base/libuclient20160123_2019-05-30-3b3e368d-1_mips_24kc.ipk - -9B /packages/mips_24kc/base/logd_2019-06-16-4df34a4d-3_mips_24kc.ipk - -38B /packages/mips_24kc/base/netifd_2019-08-05-5e02f944-1_mips_24kc.ipk + 15B /packages/mips_24kc/base/odhcp6c_2019-01-11-e199804b-16_mips_24kc.ipk - -209B /packages/mips_24kc/base/odhcpd-ipv6only_2019-09-15-1d240094-3_mips_24kc.ipk + 26B /packages/mips_24kc/base/openwrt-keyring_2019-07-25-8080ef34-1_mips_24kc.ipk + 53B /packages/mips_24kc/base/opkg_2019-06-14-dcbc142e-1_mips_24kc.ipk - -57B /packages/mips_24kc/base/ppp-mod-pppoe_2.4.7.git-2019-05-25-2_mips_24kc.ipk - -56B /packages/mips_24kc/base/ppp_2.4.7.git-2019-05-25-2_mips_24kc.ipk - -80B /packages/mips_24kc/base/procd_2019-09-21-8e9fb51f-2_mips_24kc.ipk + 33B /packages/mips_24kc/base/swconfig_12_mips_24kc.ipk - -105B /packages/mips_24kc/base/ubox_2019-06-16-4df34a4d-3_mips_24kc.ipk + 14B /packages/mips_24kc/base/ubus_2018-10-06-221ce7e7-1_mips_24kc.ipk - -44B /packages/mips_24kc/base/ubusd_2018-10-06-221ce7e7-1_mips_24kc.ipk + 13B /packages/mips_24kc/base/uci_2019-09-01-415f9e48-3_mips_24kc.ipk + 10B /packages/mips_24kc/base/uclient-fetch_2019-05-30-3b3e368d-1_mips_24kc.ipk + 11B /packages/mips_24kc/base/urandom-seed_1.0-1_mips_24kc.ipk + 18B /packages/mips_24kc/base/urngd_2019-06-17-c057e177-1_mips_24kc.ipk + 86B /packages/mips_24kc/base/usign_2019-09-21-f34a383e-1_mips_24kc.ipk + 25B /packages/mips_24kc/base/wireless-regdb_2019.06.03_all.ipk - -12043B /packages/mips_24kc/base/wpad-basic_2019-08-08-ca8c2bd2-1_mips_24kc.ipk - -103656B /targets/ath79/generic/openwrt-ath79-generic-8dev_carambola2-initramfs-kernel.bin - -196110B /targets/ath79/generic/openwrt-ath79-generic-8dev_carambola2-squashfs-sysupgrade.bin - -353608B /targets/ath79/generic/openwrt-ath79-generic-adtran_bsap1800-v2-initramfs-kernel.bin - -65536B /targets/ath79/generic/openwrt-ath79-generic-adtran_bsap1800-v2-squashfs-kernel.bin - -60942B /targets/ath79/generic/openwrt-ath79-generic-adtran_bsap1800-v2-squashfs-sysupgrade.bin - -353608B /targets/ath79/generic/openwrt-ath79-generic-adtran_bsap1840-initramfs-kernel.bin - -65536B /targets/ath79/generic/openwrt-ath79-generic-adtran_bsap1840-squashfs-kernel.bin - -60942B /targets/ath79/generic/openwrt-ath79-generic-adtran_bsap1840-squashfs-sysupgrade.bin - -103654B /targets/ath79/generic/openwrt-ath79-generic-alfa-network_ap121f-initramfs-kernel.bin - -261646B /targets/ath79/generic/openwrt-ath79-generic-alfa-network_ap121f-squashfs-sysupgrade.bin - -103647B /targets/ath79/generic/openwrt-ath79-generic-aruba_ap-105-initramfs-kernel.bin - -130574B
[OpenWrt-Devel] [PATCH 19.07] ar71xx: fix sysupgrade to ath79 for wndr3700v2 and wndr3800
ar71xx has just one board name wndr3700 for wndr 3700, 3700v2 and 3800
which is causing issues with sysupgrades to ath79 as there are separate
images for every board, so fix it by using proper board name on ar71xx
as well.
Ref: FS#2510
Signed-off-by: Petr Štetiar
---
target/linux/ar71xx/base-files/etc/board.d/01_leds| 4 +++-
target/linux/ar71xx/base-files/etc/diag.sh| 2 ++
.../linux/ar71xx/base-files/etc/uci-defaults/04_led_migration | 2 ++
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++
target/linux/ar71xx/base-files/lib/upgrade/platform.sh| 2 ++
5 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 8e49cb9fe253..26e685be1cb9 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -999,7 +999,9 @@ wam250)
wndap360)
ucidef_set_led_power "power" "POWER GREEN" "netgear:green:power" "1"
;;
-wndr3700)
+wndr3700|\
+wndr3700v2|\
+wndr3800)
ucidef_set_led_default "wan" "WAN LED (green)" "netgear:green:wan" "0"
ucidef_set_led_usbport "usb" "USB" "netgear:green:usb" "usb1-port1"
;;
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 8ff75627a538..19adf8fa96a9 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -527,7 +527,9 @@ get_status_led() {
r6100|\
wndap360|\
wndr3700|\
+ wndr3700v2|\
wndr3700v4|\
+ wndr3800|\
wndr4300|\
wnr2000|\
wnr2000-v3|\
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
b/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
index 4dd224b549a3..3e2259b76e84 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
@@ -60,6 +60,8 @@ oolite-v1)
;;
wndap360|\
wndr3700|\
+wndr3700v2|\
+wndr3800|\
wnr2000|\
wnr2200)
migrate_leds "${board}:=netgear:"
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 894835b14d79..d85801956054 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -46,13 +46,16 @@ wndr3700_board_detect() {
machine="NETGEAR WNDRMAC"
else
machine="NETGEAR WNDR3700v2"
+ name="wndr3700v2"
fi
;;
'29763654+16+64'*)
machine="NETGEAR ${model_stripped:14}"
+ name="wndr3700v2"
;;
'29763654+16+128'*)
machine="NETGEAR ${model_stripped:15}"
+ name="wndr3800"
;;
*)
# Unknown ID
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 91bffcb8c1fd..86b9ab932f68 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -677,6 +677,8 @@ platform_check_image() {
return 1
;;
wndr3700|\
+ wndr3700v2|\
+ wndr3800|\
wnr1000-v2|\
wnr2000-v3|\
wnr612-v2|\
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 19.07] ar71xx: fix sysupgrade to ath79 for wndr3700v2 and wndr3800
Hi Petr, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Petr Štetiar > Sent: Montag, 30. September 2019 21:54 > To: openwrt-devel@lists.openwrt.org > Cc: Petr Štetiar > Subject: [OpenWrt-Devel] [PATCH 19.07] ar71xx: fix sysupgrade to ath79 for > wndr3700v2 and wndr3800 > > ar71xx has just one board name wndr3700 for wndr 3700, 3700v2 and 3800 > which is causing issues with sysupgrades to ath79 as there are separate > images for every board, so fix it by using proper board name on ar71xx as > well. > no offense, but do you really want to start this? ar71xx has so many similar cases like this, which nobody ever cared about, maybe it would be easier to just deal with this in ath79 by setting SUPPORTED_DEVICES? On the other hand, if you really think it's worth it, I could provide several patches for similar cases with TP-Link devices (TL-WR841, WDR3600/4300...). Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 19.07] ar71xx: fix sysupgrade to ath79 for wndr3700v2 and wndr3800
m...@adrianschmutzler.de [2019-09-30 22:58:22]: Hi, > ar71xx has so many similar cases like this, which nobody ever cared about, well this case was properly reported and I got simply interested because of the proposed `sysupgrade -F` "fix" in that bug report. > maybe it would be easier to just deal with this in ath79 by setting > SUPPORTED_DEVICES? I've looked at this option first, then seen different NETGEAR_KERNEL_MAGIC and NETGEAR_HW_ID for those device and I've thought, that fixing it with SUPPORTED_DEVICES would just make the mess worse. > On the other hand, if you really think it's worth it, I think, that we should avoid promoting `sysupgrade -F` as a standard upgrade procedure for the obvious reasons. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
