| Message ID | 1458907015-16685-1-git-send-email-fff@chrisi01.de |
|---|---|
| State | Accepted, archived |
| Commit | c795ffad5fe7a824369848a99ef1e2c78a1dbfcf |
| Headers | show |
diff --git a/build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch b/build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch new file mode 100644 index 0000000..ada44bc --- /dev/null +++ b/build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch @@ -0,0 +1,86 @@ +From: Matthias Schiffer <mschiffer@universe-factory.net> +Date: Thu, 24 Mar 2016 18:30:26 +0100 +Subject: ar71xx: make bootconsole wait for both THRE and TEMT + +Original commit message: + + MIPS: ath79: make bootconsole wait for both THRE and TEMT + + This makes the ath79 bootconsole behave the same way as the generic 8250 + bootconsole. + + Also waiting for TEMT (transmit buffer is empty) instead of just THRE + (transmit buffer is not full) ensures that all characters have been + transmitted before the real serial driver starts reconfiguring the serial + controller (which would sometimes result in garbage being transmitted.) + This change does not cause a visible performance loss. + + In addition, this seems to fix a hang observed in certain configurations on + many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver. + + A more complete follow-up patch will disable 8250 autoconfig for ath79 + altogether (the serial controller is detected as a 16550A, which is not + fully compatible with the ath79 serial, and the autoconfig may lead to + undefined behavior on ath79.) + +diff --git a/target/linux/ar71xx/patches-3.18/103-MIPS-ath79-make-bootconsole-wait-for-both-THRE-and-T.patch b/target/linux/ar71xx/patches-3.18/103-MIPS-ath79-make-bootconsole-wait-for-both-THRE-and-T.patch +new file mode 100644 +index 0000000..7be14ab +--- /dev/null ++++ b/target/linux/ar71xx/patches-3.18/103-MIPS-ath79-make-bootconsole-wait-for-both-THRE-and-T.patch +@@ -0,0 +1,54 @@ ++From f1ba020af5076172c9d29006a747ccf40027fedc Mon Sep 17 00:00:00 2001 ++Message-Id: <f1ba020af5076172c9d29006a747ccf40027fedc.1458840219.git.mschiffer@universe-factory.net> ++From: Matthias Schiffer <mschiffer@universe-factory.net> ++Date: Thu, 24 Mar 2016 15:34:05 +0100 ++Subject: [PATCH] MIPS: ath79: make bootconsole wait for both THRE and TEMT ++ ++This makes the ath79 bootconsole behave the same way as the generic 8250 ++bootconsole. ++ ++Also waiting for TEMT (transmit buffer is empty) instead of just THRE ++(transmit buffer is not full) ensures that all characters have been ++transmitted before the real serial driver starts reconfiguring the serial ++controller (which would sometimes result in garbage being transmitted.) ++This change does not cause a visible performance loss. ++ ++In addition, this seems to fix a hang observed in certain configurations on ++many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver. ++ ++A more complete follow-up patch will disable 8250 autoconfig for ath79 ++altogether (the serial controller is detected as a 16550A, which is not ++fully compatible with the ath79 serial, and the autoconfig may lead to ++undefined behavior on ath79.) ++ ++Cc: <stable@vger.kernel.org> ++Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net> ++--- ++ arch/mips/ath79/early_printk.c | 6 ++++-- ++ 1 file changed, 4 insertions(+), 2 deletions(-) ++ ++diff --git a/arch/mips/ath79/early_printk.c b/arch/mips/ath79/early_printk.c ++index b955faf..d1adc59 100644 ++--- a/arch/mips/ath79/early_printk.c +++++ b/arch/mips/ath79/early_printk.c ++@@ -31,13 +31,15 @@ static inline void prom_putchar_wait(void __iomem *reg, u32 mask, u32 val) ++ } while (1); ++ } ++ +++#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE) +++ ++ static void prom_putchar_ar71xx(unsigned char ch) ++ { ++ void __iomem *base = (void __iomem *)(KSEG1ADDR(AR71XX_UART_BASE)); ++ ++- prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE); +++ prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY); ++ __raw_writel(ch, base + UART_TX * 4); ++- prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE); +++ prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY); ++ } ++ ++ static void prom_putchar_ar933x(unsigned char ch) ++-- ++2.7.4 ++ +
Am Freitag, den 25.03.2016, 12:56 +0100 schrieb Christian Dresel: > Fix the Race Condition on boot Reviewed und applied. Danke Tim > > > > Signed-off-by: Christian Dresel <fff@chrisi01.de> > > new file: build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch > --- > ...e-bootconsole-wait-for-both-THRE-and-TEMT.patch | 86 ++++++++++++++++++++++ > 1 file changed, 86 insertions(+) > create mode 100644 build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch > > diff --git a/build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch b/build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch > new file mode 100644 > index 0000000..ada44bc > --- /dev/null > +++ b/build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch > @@ -0,0 +1,86 @@ > +From: Matthias Schiffer <mschiffer@universe-factory.net> > +Date: Thu, 24 Mar 2016 18:30:26 +0100 > +Subject: ar71xx: make bootconsole wait for both THRE and TEMT > + > +Original commit message: > + > + MIPS: ath79: make bootconsole wait for both THRE and TEMT > + > + This makes the ath79 bootconsole behave the same way as the generic 8250 > + bootconsole. > + > + Also waiting for TEMT (transmit buffer is empty) instead of just THRE > + (transmit buffer is not full) ensures that all characters have been > + transmitted before the real serial driver starts reconfiguring the serial > + controller (which would sometimes result in garbage being transmitted.) > + This change does not cause a visible performance loss. > + > + In addition, this seems to fix a hang observed in certain configurations on > + many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver. > + > + A more complete follow-up patch will disable 8250 autoconfig for ath79 > + altogether (the serial controller is detected as a 16550A, which is not > + fully compatible with the ath79 serial, and the autoconfig may lead to > + undefined behavior on ath79.) > + > +diff --git a/target/linux/ar71xx/patches-3.18/103-MIPS-ath79-make-bootconsole-wait-for-both-THRE-and-T.patch b/target/linux/ar71xx/patches-3.18/103-MIPS-ath79-make-bootconsole-wait-for-both-THRE-and-T.patch > +new file mode 100644 > +index 0000000..7be14ab > +--- /dev/null > ++++ b/target/linux/ar71xx/patches-3.18/103-MIPS-ath79-make-bootconsole-wait-for-both-THRE-and-T.patch > +@@ -0,0 +1,54 @@ > ++From f1ba020af5076172c9d29006a747ccf40027fedc Mon Sep 17 00:00:00 2001 > ++Message-Id: <f1ba020af5076172c9d29006a747ccf40027fedc.1458840219.git.mschiffer@universe-factory.net> > ++From: Matthias Schiffer <mschiffer@universe-factory.net> > ++Date: Thu, 24 Mar 2016 15:34:05 +0100 > ++Subject: [PATCH] MIPS: ath79: make bootconsole wait for both THRE and TEMT > ++ > ++This makes the ath79 bootconsole behave the same way as the generic 8250 > ++bootconsole. > ++ > ++Also waiting for TEMT (transmit buffer is empty) instead of just THRE > ++(transmit buffer is not full) ensures that all characters have been > ++transmitted before the real serial driver starts reconfiguring the serial > ++controller (which would sometimes result in garbage being transmitted.) > ++This change does not cause a visible performance loss. > ++ > ++In addition, this seems to fix a hang observed in certain configurations on > ++many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver. > ++ > ++A more complete follow-up patch will disable 8250 autoconfig for ath79 > ++altogether (the serial controller is detected as a 16550A, which is not > ++fully compatible with the ath79 serial, and the autoconfig may lead to > ++undefined behavior on ath79.) > ++ > ++Cc: <stable@vger.kernel.org> > ++Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net> > ++--- > ++ arch/mips/ath79/early_printk.c | 6 ++++-- > ++ 1 file changed, 4 insertions(+), 2 deletions(-) > ++ > ++diff --git a/arch/mips/ath79/early_printk.c b/arch/mips/ath79/early_printk.c > ++index b955faf..d1adc59 100644 > ++--- a/arch/mips/ath79/early_printk.c > +++++ b/arch/mips/ath79/early_printk.c > ++@@ -31,13 +31,15 @@ static inline void prom_putchar_wait(void __iomem *reg, u32 mask, u32 val) > ++ } while (1); > ++ } > ++ > +++#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE) > +++ > ++ static void prom_putchar_ar71xx(unsigned char ch) > ++ { > ++ void __iomem *base = (void __iomem *)(KSEG1ADDR(AR71XX_UART_BASE)); > ++ > ++- prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE); > +++ prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY); > ++ __raw_writel(ch, base + UART_TX * 4); > ++- prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE); > +++ prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY); > ++ } > ++ > ++ static void prom_putchar_ar933x(unsigned char ch) > ++-- > ++2.7.4 > ++ > + > -- > 2.1.4 >
Tim Niemeyer: > Reviewed und applied. >> Signed-off-by: Christian Dresel <fff@chrisi01.de> >> >> new file: >> build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch Hi, nach einem "git pull" hatte ich lokal die entsprechende Patchdatei. also: ./buildscript prepare; ./buildscript build und das Binary auf meinen wr841n-v8 installiert. Aber der hat immernoch "einmal Poweroff" gebraucht, um nach dem Update neu zu starten. Ist meine Erwartungshaltung falsch? Andreas
Am 27.03.2016 um 23:38 schrieb A. Schulze: > > Tim Niemeyer: > >> Reviewed und applied. > >>> Signed-off-by: Christian Dresel <fff@chrisi01.de> >>> >>> new file: >>> build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch >>> > > Hi, > > nach einem "git pull" hatte ich lokal die entsprechende Patchdatei. > also: ./buildscript prepare; ./buildscript build und das Binary auf > meinen wr841n-v8 > installiert. Aber der hat immernoch "einmal Poweroff" gebraucht, um nach > dem Update neu zu starten. hi wo ist er denn genau hängen geblieben oder was ist beim ersten boot passiert? Hast du ein Bootlog (serielle Konsole)? Bootet er danach jedes mal normal? > Ist meine Erwartungshaltung falsch? hm eher nein, er sollte nun zumindest nicht mehr in diese Race Condition rennen, allerdings hatte ich persönlich die Probleme bei den 841ern eigentlich nie. mfg Christian > > Andreas >
Moin, >> nach einem "git pull" hatte ich lokal die entsprechende Patchdatei. >> also: ./buildscript prepare; ./buildscript build und das Binary auf >> meinen wr841n-v8 installiert. Aber der hat immernoch "einmal Poweroff" >> gebraucht, um nach dem Update neu zu starten. > >hi > >wo ist er denn genau hängen geblieben oder was ist beim ersten boot passiert? >Hast du ein Bootlog (serielle Konsole)? Bootet er danach jedes mal normal? Ich habe auch den Eindruck, daß direkjt nach dem update gerne nochmal ein Reset nötig ist, und auch frisch aktualisierte Geräte noch nicht ganz boot-fest sind, was sich dann mit etwas Laufzeit zu geben scheint. Das Verhalten hatte ich schon mit 0.4.x-Firmware mit den 741er/1043ern. Machen die Geräte denn noch irgendwas im Hintergrund nach einem update bzw. nach dem ersten Start? >> Ist meine Erwartungshaltung falsch? >mfg > >Christian Viele Grüße Ralph.
Christian Dresel: > wo ist er denn genau hängen geblieben oder was ist beim ersten boot > passiert? Hast du ein Bootlog (serielle Konsole)? da ich keine serielle Konsole habe, kann ich keine Details sehen. > Bootet er danach jedes mal normal? jep, zuverlässig. Ich habe heute die gleiche Prozedur bei einem wr1043nd-v1 wiederholt. Der kam sofort wieder online. Und dort hatte ich auch noch nie ( 4-5 Updates ) die Notwendigkeit, nach einem Update das Gerät stromlos zu schalten. Ich werde das beim nächsten Update im Auge behalten und wieder berichten. Andreas
Christian Dresel: > wo ist er denn genau hängen geblieben oder was ist beim ersten boot > passiert? Hast du ein Bootlog (serielle Konsole)? Christian, hattest Du letztens nicht einige 'alt' Systeme von Dir angeboten? Ist da ev. ein 841er /mit/ serieller Konsole dabei und noch da? Wenn ja, mach mal bitten einen Preis. Oder kannst Du eine zuverlässige Anleitung empfehlen? Dann hole ich meinen Lötkolben raus... Andreas
Lasst euch die Logs doch einfach in eine Datei schreiben.... On 28.03.2016 12:18, A. Schulze wrote: > > Christian Dresel: > >> wo ist er denn genau hängen geblieben oder was ist beim ersten boot >> passiert? Hast du ein Bootlog (serielle Konsole)? > > Christian, > > hattest Du letztens nicht einige 'alt' Systeme von Dir angeboten? > Ist da ev. ein 841er /mit/ serieller Konsole dabei und noch da? > Wenn ja, mach mal bitten einen Preis. > > Oder kannst Du eine zuverlässige Anleitung empfehlen? > Dann hole ich meinen Lötkolben raus... > > Andreas > > >
vergiss es. ist unfug, wenn er schon beim booten stockt On 28.03.2016 12:39, A. Schulze wrote: > > Tom Green: > >> Lasst euch die Logs doch einfach in eine Datei schreiben.... > > ???? Bahnhof... > kannst Du das genauer erklären? > >
Fix the Race Condition on boot Signed-off-by: Christian Dresel <fff@chrisi01.de> new file: build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch --- ...e-bootconsole-wait-for-both-THRE-and-TEMT.patch | 86 ++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 build_patches/openwrt/0005-ar71xx-make-bootconsole-wait-for-both-THRE-and-TEMT.patch