[2/4] Remove target and subtarget from filename

Submitted by Fabian Blaese on Nov. 19, 2019, 8:19 p.m.

Details

Message ID 20191119201940.70424-2-fabian@blaese.de
State Accepted
Headers show

Commit Message

Fabian Blaese Nov. 19, 2019, 8:19 p.m.
This simplifies and shortens filenames quite significantly.

A rewrite script will be installed on the update servers
to allow updating routers with older firmwares.

Signed-off-by: Fabian Bläse <fabian@blaese.de>
---
 buildscript                                          |  3 +--
 .../fff/fff-sysupgrade/files/etc/sysupgrade.sh       | 12 +-----------
 2 files changed, 2 insertions(+), 13 deletions(-)

Patch hide | download patch | download mbox

diff --git a/buildscript b/buildscript
index 0920b74..4c54aec 100755
--- a/buildscript
+++ b/buildscript
@@ -296,9 +296,8 @@  cp_firmware() {
 
     for image in ${images[@]}; do
         filename_build=${image//openwrt/fff-${version}}
-        filename_build=${filename_build//generic/g}
-        filename_build=${filename_build//tiny/t}
         filename_build=${filename_build//squashfs-/}
+        filename_build=${filename_build//${chipset}-${subtarget}-/}
         cp "$builddir/bin/targets/${chipset}/${subtarget}/$image" "./bin/$filename_build"
 
         for region in "" "-eu" "-us"; do
diff --git a/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh b/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
index b42b19a..2b749f3 100755
--- a/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
+++ b/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
@@ -14,16 +14,6 @@  fi
 
 BOARD=$(uci get board.model.name)
 
-#decide SOC
-case $BOARD in
-    tl-wdr4900-v1 )
-        SOC="mpc85xx-g"
-        ;;
-    * )
-        SOC="ar71xx-t"
-        ;;
-esac
-echo ""
 echo "Hardware: $BOARD"
 
 #rewrite BOARD
@@ -69,7 +59,7 @@  if [ "$VERSION" = "$FIRMWARE_VERSION" ]; then
   done
 fi
 
-FILE="fff-${VERSION}-${SOC}-${BOARD}-sysupgrade.bin"
+FILE="fff-${VERSION}-${BOARD}-sysupgrade.bin"
 echo "Downloading $FILE"
 echo ""
 /bin/busybox wget "${UPGRADE_PATH}/${FILE}"

Comments

Adrian Schmutzler Nov. 19, 2019, 8:26 p.m.
Hi,

ich halte das für überhaupt keine gute Idee, da wir so nicht zwischen ar71xx und ath79 unterscheiden können.

Aus meiner bisherigen Erfahrung waren alle Versuche, die Architektur rauszufischen, im Nachhinein sehr lästig.

Subtarget kann weg.

Grüße

Adrian

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf
> Of Fabian Bläse
> Sent: Dienstag, 19. November 2019 21:20
> To: franken-dev@freifunk.net
> Subject: [PATCH 2/4] Remove target and subtarget from filename
> 
> This simplifies and shortens filenames quite significantly.
> 
> A rewrite script will be installed on the update servers to allow updating
> routers with older firmwares.
> 
> Signed-off-by: Fabian Bläse <fabian@blaese.de>
> ---
>  buildscript                                          |  3 +--
>  .../fff/fff-sysupgrade/files/etc/sysupgrade.sh       | 12 +-----------
>  2 files changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/buildscript b/buildscript
> index 0920b74..4c54aec 100755
> --- a/buildscript
> +++ b/buildscript
> @@ -296,9 +296,8 @@ cp_firmware() {
> 
>      for image in ${images[@]}; do
>          filename_build=${image//openwrt/fff-${version}}
> -        filename_build=${filename_build//generic/g}
> -        filename_build=${filename_build//tiny/t}
>          filename_build=${filename_build//squashfs-/}
> +        filename_build=${filename_build//${chipset}-${subtarget}-/}
>          cp "$builddir/bin/targets/${chipset}/${subtarget}/$image"
> "./bin/$filename_build"
> 
>          for region in "" "-eu" "-us"; do diff --git a/src/packages/fff/fff-
> sysupgrade/files/etc/sysupgrade.sh b/src/packages/fff/fff-
> sysupgrade/files/etc/sysupgrade.sh
> index b42b19a..2b749f3 100755
> --- a/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
> +++ b/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
> @@ -14,16 +14,6 @@ fi
> 
>  BOARD=$(uci get board.model.name)
> 
> -#decide SOC
> -case $BOARD in
> -    tl-wdr4900-v1 )
> -        SOC="mpc85xx-g"
> -        ;;
> -    * )
> -        SOC="ar71xx-t"
> -        ;;
> -esac
> -echo ""
>  echo "Hardware: $BOARD"
> 
>  #rewrite BOARD
> @@ -69,7 +59,7 @@ if [ "$VERSION" = "$FIRMWARE_VERSION" ]; then
>    done
>  fi
> 
> -FILE="fff-${VERSION}-${SOC}-${BOARD}-sysupgrade.bin"
> +FILE="fff-${VERSION}-${BOARD}-sysupgrade.bin"
>  echo "Downloading $FILE"
>  echo ""
>  /bin/busybox wget "${UPGRADE_PATH}/${FILE}"
> --
> 2.24.0
Fabian Blaese Nov. 19, 2019, 8:36 p.m.
Hallo Adrian,

ich hab mir das so vorgestellt, dass es einfach nie ein Release mit verschiedenen Targets geben soll.
Wir nehmen dann einfach alle Geräte auf einmal mit.
Zumal wir das Target/Subtarget auch gar nicht über den Dateinamen unterscheiden.

Ich hab da jetzt einfach mal angenommen, dass man ath79 einfach über ar71xx drüber flashen kann.
Aber ich glaube, das ist auch so.

Gruß
Fabian

On 19.11.19 21:26, mail@adrianschmutzler.de wrote:
> Hi,
> 
> ich halte das für überhaupt keine gute Idee, da wir so nicht zwischen ar71xx und ath79 unterscheiden können.
> 
> Aus meiner bisherigen Erfahrung waren alle Versuche, die Architektur rauszufischen, im Nachhinein sehr lästig.
> 
> Subtarget kann weg.
> 
> Grüße
> 
> Adrian
> 
>> -----Original Message-----
>> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf
>> Of Fabian Bläse
>> Sent: Dienstag, 19. November 2019 21:20
>> To: franken-dev@freifunk.net
>> Subject: [PATCH 2/4] Remove target and subtarget from filename
>>
>> This simplifies and shortens filenames quite significantly.
>>
>> A rewrite script will be installed on the update servers to allow updating
>> routers with older firmwares.
>>
>> Signed-off-by: Fabian Bläse <fabian@blaese.de>
>> ---
>>  buildscript                                          |  3 +--
>>  .../fff/fff-sysupgrade/files/etc/sysupgrade.sh       | 12 +-----------
>>  2 files changed, 2 insertions(+), 13 deletions(-)
>>
>> diff --git a/buildscript b/buildscript
>> index 0920b74..4c54aec 100755
>> --- a/buildscript
>> +++ b/buildscript
>> @@ -296,9 +296,8 @@ cp_firmware() {
>>
>>      for image in ${images[@]}; do
>>          filename_build=${image//openwrt/fff-${version}}
>> -        filename_build=${filename_build//generic/g}
>> -        filename_build=${filename_build//tiny/t}
>>          filename_build=${filename_build//squashfs-/}
>> +        filename_build=${filename_build//${chipset}-${subtarget}-/}
>>          cp "$builddir/bin/targets/${chipset}/${subtarget}/$image"
>> "./bin/$filename_build"
>>
>>          for region in "" "-eu" "-us"; do diff --git a/src/packages/fff/fff-
>> sysupgrade/files/etc/sysupgrade.sh b/src/packages/fff/fff-
>> sysupgrade/files/etc/sysupgrade.sh
>> index b42b19a..2b749f3 100755
>> --- a/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
>> +++ b/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
>> @@ -14,16 +14,6 @@ fi
>>
>>  BOARD=$(uci get board.model.name)
>>
>> -#decide SOC
>> -case $BOARD in
>> -    tl-wdr4900-v1 )
>> -        SOC="mpc85xx-g"
>> -        ;;
>> -    * )
>> -        SOC="ar71xx-t"
>> -        ;;
>> -esac
>> -echo ""
>>  echo "Hardware: $BOARD"
>>
>>  #rewrite BOARD
>> @@ -69,7 +59,7 @@ if [ "$VERSION" = "$FIRMWARE_VERSION" ]; then
>>    done
>>  fi
>>
>> -FILE="fff-${VERSION}-${SOC}-${BOARD}-sysupgrade.bin"
>> +FILE="fff-${VERSION}-${BOARD}-sysupgrade.bin"
>>  echo "Downloading $FILE"
>>  echo ""
>>  /bin/busybox wget "${UPGRADE_PATH}/${FILE}"
>> --
>> 2.24.0
Adrian Schmutzler Nov. 19, 2019, 8:44 p.m.
Hallo Fabian,

 

das Problem ist, dass schon seit vielen Monaten kein Device-Support mehr für ar71xx akzeptiert wird.

 

D.h. wenn wir nicht bis zum Wechseln von 19.07 auf den Nachfolger (!) auf alle neuen Atheros-Geräte verzichten wollen, werden wir irgendwann parallel ar71xx und ath79 bauen müssen. Streng genommen hätten wir dann immer noch kein Device doppelt, da ja die „neuen“ ath79 und die „alten“ ar71xx sind. Aber wenn man dann eh beides hat, will man vll. schon auch mal ein Gerät doppelt haben.

 

Man verbaut sich halt eine Möglichkeit, da jetzt nur schwer absehbar ist, wie wir das mit ath79/ar71xx lösen werden.

 

Ich würde dringend darauf verzichten.

 

Aber ich hatte auch ganz vergessen, dass wir ja hier diesen Quatsch mit alle-als-tiny machen. Dann kann man die targets eigentlich auch zusammenwerfen …

 

Grüße

 

Adrian
Christian Dresel Nov. 19, 2019, 8:47 p.m.
hi

On 19.11.19 21:44, mail@adrianschmutzler.de wrote:
> Hallo Fabian,
> 
>  
> 
> das Problem ist, dass schon seit vielen Monaten kein Device-Support mehr
> für ar71xx akzeptiert wird.
> 
>  
> 
> D.h. wenn wir nicht bis zum Wechseln von 19.07 auf den Nachfolger (!)
> auf alle neuen Atheros-Geräte verzichten wollen, werden wir irgendwann
> parallel ar71xx und ath79 bauen müssen. Streng genommen hätten wir dann
> immer noch kein Device doppelt, da ja die „neuen“ ath79 und die „alten“
> ar71xx sind. Aber wenn man dann eh beides hat, will man vll. schon auch
> mal ein Gerät doppelt haben.

kann an grob auflisten welche von unseren Geräten in ath79 noch fehlen?
Wenn das sehr übersichtlich ist oder nur sehr alte 4MB Geräte oder sowas
betrifft hätte ich in diesem Fall kein Problem damit wenn sie raus fliegen.

Gruß

Christian

> 
>  
> 
> Man verbaut sich halt eine Möglichkeit, da jetzt nur schwer absehbar
> ist, wie wir das mit ath79/ar71xx lösen werden.
> 
>  
> 
> Ich würde dringend darauf verzichten.
> 
>  
> 
> Aber ich hatte auch ganz vergessen, dass wir ja hier diesen Quatsch mit
> alle-als-tiny machen. Dann kann man die targets eigentlich auch
> zusammenwerfen …
> 
>  
> 
> Grüße
> 
>  
> 
> Adrian
>
Fabian Blaese Nov. 19, 2019, 8:49 p.m.
Hey Adrian,

On 19.11.19 21:44, mail@adrianschmutzler.de wrote:
> Hallo Fabian,
> 
>  
> 
> das Problem ist, dass schon seit vielen Monaten kein Device-Support mehr für ar71xx akzeptiert wird.
> 
>  
> 
> D.h. wenn wir nicht bis zum Wechseln von 19.07 auf den Nachfolger (!) auf alle neuen Atheros-Geräte verzichten wollen, werden wir irgendwann parallel ar71xx und ath79 bauen müssen. Streng genommen hätten wir dann immer noch kein Device doppelt, da ja die „neuen“ ath79 und die „alten“ ar71xx sind. Aber wenn man dann eh beides hat, will man vll. schon auch mal ein Gerät doppelt haben.
Diesen Fall sehe ich nicht.
Da verwirrst du Leute nur, die sich die Firmware am Standardort laden, weil es mehrere Binaries fürs gleiche Gerät gibt. factory/sysupgrade ist ja teilweise schon kompliziert genug.

Ich würde für ein Gerät auch immer nur genau ein Target unterstützen. Dann wissen alle, wovon die Rede ist.
Und wenn jemand für ein anderes Target bauen will, ist das ja auch kein Problem.
Ich bin da nach wie vor der Meinung, dass wir uns da nicht mehr Support-Arbeit machen sollten, als wir eh schon haben.

> Man verbaut sich halt eine Möglichkeit, da jetzt nur schwer absehbar ist, wie wir das mit ath79/ar71xx lösen werden.
Stimmt, dann müssten wir es aber vollständig im Dateinamen behalten und dann werden die ganz schön lang.

Gruß
Fabian
Christian Dresel Nov. 19, 2019, 9:05 p.m.
ich bin im Prinzip der gleichen Meinung, ath79 und ar71xx für das
gleiche device gleichzeitig anbieten sollten wir wirklich vermeiden
sonst kommen Leute nur durcheinander und fragen ständig nach.

Selbst wenn Geräte in ath79 fehlen, dann bauen wir diese mit ar71xx, dem
Enduser wirds egal sein was drinnen steckt, Hauptsache das Ding geht.

Von daher wurde ich überzeugt das es so schon passt :)

Reviewed-by: Christian Dresel <fff@chrisi01.de>

Gruß

Christian

On 19.11.19 21:49, Fabian Bläse wrote:
> Hey Adrian,
> 
> On 19.11.19 21:44, mail@adrianschmutzler.de wrote:
>> Hallo Fabian,
>>
>>  
>>
>> das Problem ist, dass schon seit vielen Monaten kein Device-Support mehr für ar71xx akzeptiert wird.
>>
>>  
>>
>> D.h. wenn wir nicht bis zum Wechseln von 19.07 auf den Nachfolger (!) auf alle neuen Atheros-Geräte verzichten wollen, werden wir irgendwann parallel ar71xx und ath79 bauen müssen. Streng genommen hätten wir dann immer noch kein Device doppelt, da ja die „neuen“ ath79 und die „alten“ ar71xx sind. Aber wenn man dann eh beides hat, will man vll. schon auch mal ein Gerät doppelt haben.
> Diesen Fall sehe ich nicht.
> Da verwirrst du Leute nur, die sich die Firmware am Standardort laden, weil es mehrere Binaries fürs gleiche Gerät gibt. factory/sysupgrade ist ja teilweise schon kompliziert genug.
> 
> Ich würde für ein Gerät auch immer nur genau ein Target unterstützen. Dann wissen alle, wovon die Rede ist.
> Und wenn jemand für ein anderes Target bauen will, ist das ja auch kein Problem.
> Ich bin da nach wie vor der Meinung, dass wir uns da nicht mehr Support-Arbeit machen sollten, als wir eh schon haben.
> 
>> Man verbaut sich halt eine Möglichkeit, da jetzt nur schwer absehbar ist, wie wir das mit ath79/ar71xx lösen werden.
> Stimmt, dann müssten wir es aber vollständig im Dateinamen behalten und dann werden die ganz schön lang.
> 
> Gruß
> Fabian
>
Adrian Schmutzler Nov. 19, 2019, 11:26 p.m.
Hi,

zum Code unten:

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf
> Of Fabian Bläse
> Sent: Dienstag, 19. November 2019 21:20
> To: franken-dev@freifunk.net
> Subject: [PATCH 2/4] Remove target and subtarget from filename
> 
> This simplifies and shortens filenames quite significantly.
> 
> A rewrite script will be installed on the update servers to allow updating
> routers with older firmwares.
> 
> Signed-off-by: Fabian Bläse <fabian@blaese.de>
> ---
>  buildscript                                          |  3 +--
>  .../fff/fff-sysupgrade/files/etc/sysupgrade.sh       | 12 +-----------
>  2 files changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/buildscript b/buildscript
> index 0920b74..4c54aec 100755
> --- a/buildscript
> +++ b/buildscript
> @@ -296,9 +296,8 @@ cp_firmware() {
> 
>      for image in ${images[@]}; do
>          filename_build=${image//openwrt/fff-${version}}
> -        filename_build=${filename_build//generic/g}
> -        filename_build=${filename_build//tiny/t}
>          filename_build=${filename_build//squashfs-/}
> +        filename_build=${filename_build//${chipset}-${subtarget}-/}

Hier braucht man eine Unterscheidung, falls noch vor 19.07 ipq40xx oder ipq806x dazu kommen sollte. (Die haben kein Subtarget im Namen)

>          cp "$builddir/bin/targets/${chipset}/${subtarget}/$image"
> "./bin/$filename_build"
> 
>          for region in "" "-eu" "-us"; do diff --git a/src/packages/fff/fff-
> sysupgrade/files/etc/sysupgrade.sh b/src/packages/fff/fff-
> sysupgrade/files/etc/sysupgrade.sh
> index b42b19a..2b749f3 100755
> --- a/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
> +++ b/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
> @@ -14,16 +14,6 @@ fi
> 
>  BOARD=$(uci get board.model.name)
> 
> -#decide SOC
> -case $BOARD in
> -    tl-wdr4900-v1 )
> -        SOC="mpc85xx-g"
> -        ;;
> -    * )
> -        SOC="ar71xx-t"
> -        ;;
> -esac
> -echo ""

Dieses Echo macht eine Leerzeile, die mit dem Case nichts zu tun hat. Falls das Absicht war, die zu entfernen, ist es auch egal.

Ansonsten müsste es technisch funktionieren, wenn man von der neuen Firmware auf die neu-neue Firmware 2020-xx-xx updaten will.

Für die bestehende Firmware brauchen wir trotzdem ein Rewrite.

Grüße

Adrian

>  echo "Hardware: $BOARD"
> 
>  #rewrite BOARD
> @@ -69,7 +59,7 @@ if [ "$VERSION" = "$FIRMWARE_VERSION" ]; then
>    done
>  fi
> 
> -FILE="fff-${VERSION}-${SOC}-${BOARD}-sysupgrade.bin"
> +FILE="fff-${VERSION}-${BOARD}-sysupgrade.bin"
>  echo "Downloading $FILE"
>  echo ""
>  /bin/busybox wget "${UPGRADE_PATH}/${FILE}"
> --
> 2.24.0
Adrian Schmutzler Nov. 19, 2019, 11:35 p.m.
Hallo Fabian,

 

> Ich hab da jetzt einfach mal angenommen, dass man ath79 einfach über ar71xx drüber flashen kann. 

> Aber ich glaube, das ist auch so.

 

OpenWrt hat da Probleme, weil sich z.B. die Reihenfolge von eth0/eth1 etc. ändert, und die ja alle Config-Dateien behalten.

 

Für uns sollte es keine direkten Upgrade-Probleme geben, solange wir alle Änderungen in der Firmware richtig gemacht haben:

- eth0/eth1 swap für manche Geräte

- Primäre MAC-Adresse ggf. entsprechend anpassen (wenn erst mit 20.xx kommt die primäre Adresse direkt von OpenWrt)

 

Generell haben wir es hier aber recht leicht.

 

Grüße

 

Adrian
Adrian Schmutzler Nov. 19, 2019, 11:39 p.m.
Hallo Christian,

 

> kann an grob auflisten welche von unseren Geräten in ath79 noch fehlen? 

> Wenn das sehr übersichtlich ist oder nur sehr alte 4MB Geräte oder sowas 

> betrifft hätte ich in diesem Fall kein Problem damit wenn sie raus fliegen.

 

Fast alle Geräte die wir jetzt unterstützen sind auch in ath79, ich habe selbst einige portiert. Es fehlen:

- Der WDR4310, weil den niemand hat

- Die Steckdosen-Geräte WA850RE und WA860RE, weil die 4/32 sind, Steckdosen-Geräte sind, kein TFTP können und die auch sonst keiner mag.

 

Das ist aber kein Problem. Aber wir werden ja nicht die nächsten zwei Jahre nur mit den alten Geräten weiterpfuschen. Und wenn wir neue hinzufügen, kann es sein, dass die nur noch in ath79 bei OpenWrt unterstützt sind.

 

Grüße

 

Adrian
Fabian Blaese Nov. 20, 2019, 4:13 p.m.
On 20.11.19 00:26, mail@adrianschmutzler.de wrote:
> Hi,
> 
> zum Code unten:
>
>> sysupgrade/files/etc/sysupgrade.sh b/src/packages/fff/fff-
>> sysupgrade/files/etc/sysupgrade.sh
>> index b42b19a..2b749f3 100755
>> --- a/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
>> +++ b/src/packages/fff/fff-sysupgrade/files/etc/sysupgrade.sh
>> @@ -14,16 +14,6 @@ fi
>>
>>  BOARD=$(uci get board.model.name)
>>
>> -#decide SOC
>> -case $BOARD in
>> -    tl-wdr4900-v1 )
>> -        SOC="mpc85xx-g"
>> -        ;;
>> -    * )
>> -        SOC="ar71xx-t"
>> -        ;;
>> -esac
>> -echo ""
> 
> Dieses Echo macht eine Leerzeile, die mit dem Case nichts zu tun hat. Falls das Absicht war, die zu entfernen, ist es auch egal.
Das stimmt.
Das war mehr oder weniger Absicht. Vorher kommt ja nichts, dieses echo hat also dazu geführt, dass das Skript mit einer Leerzeile anfängt.

Gruß
Fabian
Fabian Blaese Nov. 20, 2019, 7:52 p.m.
applied.