Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Picostation startet immer wieder mit leeren Einstellungen #687

Closed
FabianCernota opened this issue Mar 14, 2016 · 39 comments
Closed

Picostation startet immer wieder mit leeren Einstellungen #687

FabianCernota opened this issue Mar 14, 2016 · 39 comments
Assignees
Labels
0. type: bug This is a bug
Milestone

Comments

@FabianCernota
Copy link

Hallo zusammen,
ich habe auf eine Picostation Gluon v2016.1.2 geflasht. Wenn ich jetzt im Configmode bin und Einstellungen setze sind diese nach einem Neustart wieder weg und ich lande im Configmode.

Muss ich noch irgendetwas machen?

Gruß
Fabian

@neocturne
Copy link
Member

Dein Gluon-Image ist kaputt; es wurde beim Update von v2016.1 auf v2016.1.2 entweder make update oder make clean (oder beides) vergessen.

In diesem Zustand ist der Flash nicht beschreibbar, also auch kein normales Sysupgrade möglich. Du musst nach Erzeugen eines korrekten Images dieses per TFTP flashen.

@FabianCernota
Copy link
Author

Auch mit einem frischen Gluon kann ich es noch auf 2 verschiedenen Picostations nachstellen.

Im Forum gibts es noch jemand der auch Probleme mit der Picostation hat:
https://forum.freifunk.net/t/ubiquiti-picostation-m2-startet-nur-in-den-gluon-configmode/11361

@neocturne
Copy link
Member

@FabianCernota, wie hast du das frische Gluon aufgespielt? Wenn schon einmal ein kaputtes Gluon drauf war, muss über TFTP geflasht werden.

@FabianCernota
Copy link
Author

@NeoRaider Eine per TFTP und eine von der Stockfirmware heraus.

@neocturne
Copy link
Member

@FabianCernota Logs?

@FabianCernota
Copy link
Author

@NeoRaider Welche genau? An die Gluon Logs komme ich ja nicht.

@neocturne
Copy link
Member

@FabianCernota, warum nicht? Einfach per Telnet drauf und dmesg bzw. logread eingeben.

@FabianCernota
Copy link
Author

@neocturne
Copy link
Member

Okay, die Picostation benutzt einen Flash-Chip von einem anderen Hersteller als Macronix... ich bau nachher nen Patch.

@MPW1412
Copy link
Contributor

MPW1412 commented Mar 26, 2016

Wir haben das hier auch mehrfach schon gesehen jetzt, falls du noch Logs brauchst. Wir freuen uns auf den Patch :).

@neocturne
Copy link
Member

Im master sollte 1ccd24d das Problem beheben. Bitte einmal testen, wenn der Patch funktioniert, landet er auch in v2016.1.x.

@neocturne
Copy link
Member

Ich habe gerade einen anderen Patch und zugehörige Diskussionen gefunden, daher vermute ich, dass mein Patch mehr Probleme auslöst als er behebt.

Siehe:
http://patchwork.ozlabs.org/patch/549173/
http://patchwork.ozlabs.org/patch/553683/

@neocturne neocturne reopened this Mar 26, 2016
@neocturne
Copy link
Member

Könnte mir jemand leihweise eine entsprechende PicoStation zukommen lassen? Adresse gibt's per Mail oder IRC.

@neocturne
Copy link
Member

Hmm, CPE210 und WDR4300 benutzen denselben Flash-Chip. Ich probier erstmal, das Problem mit den Geräten zu reproduzieren.

@neocturne
Copy link
Member

Bitte doch einfach mal mit dem Patch testen (also nicht den neuesten Stand des Master, in dem ich den Patch reverted habe, sondern den davor).

@neocturne
Copy link
Member

Und könnte mal jemand eine PicoStation aufschrauben und nachschauen, was auf dem Flash-Chip steht? Laut Kernel-Log ist das ein Spansion s25fl064k, aber möglicherweise ist der Log falsch und es ist eigentlich ein Winbond w25q64.

@justelex
Copy link

Hi,
ich habe die eben mal aufgeschraubt,
es ist ein Winbond 25Q64FVIG
Danke für deine Mühe

@neocturne
Copy link
Member

Neuer Patch: d9ca449 Bitte testen!

@FabianCernota
Copy link
Author

@NeoRaider Funktioniert leider noch nicht:
http://pastebin.com/U7Q2Yzvk

@neocturne
Copy link
Member

@FabianCernota, den Kernel-Tree hast du aber gecleaned nach dem git-pull/make-update, oder?

@FabianCernota
Copy link
Author

Jap git pull , make clean, make update

@neocturne
Copy link
Member

Hmm, seltsam. Dann komme ich ohne Testgerät nicht weiter.

@FabianCernota
Copy link
Author

Ich lass dir eine zukommen alles weitere per Mail dann :)

@MPW1412
Copy link
Contributor

MPW1412 commented Mar 31, 2016

Scheinbar kann man das Problem umgehen, wenn man erst AirOS auf eine alte Version verringert.

Querverlinkung: https://forum.freifunk-muensterland.de/t/picostationm2-v2016-1-1-0-0/884/8?u=mpw

@neocturne
Copy link
Member

@MPW1412, ja, das ist allgemein bekannt. Es geht in diesem Report darum, diesen Workaround in Zukunft vermeiden zu können.

@MPW1412
Copy link
Contributor

MPW1412 commented Mar 31, 2016

Also ist das primäre Problem gar nicht der neue Flash-Chip, sondern irgendwas im Bootloader, was den Flash nicht korrekt entsperrt.

@neocturne
Copy link
Member

Es ist eigentlich nicht die Aufgabe des Bootloaders... der Kernel sollte das schon selbst können.

@SilversurferCH
Copy link

Wenn du noch beim Testen Hilfe brauchst, hab hier auch noch eine betroffen Pico liegen.

@LeSpocky
Copy link
Contributor

LeSpocky commented Apr 6, 2016

Bestätige Winbond 25Q64FVIG auf PicoStation M2 XM. U-Boot sagt dazu:

ar7240> flinfo

Bank # 1: w25q64 (Id: 0xef4017)
        Size: 8 MB in 128 sectors

@A-Kasper
Copy link
Contributor

A-Kasper commented Apr 6, 2016 via email

@neocturne
Copy link
Member

@A-Kasper, nein, der alte Bootloader entsperrt den Flash. Das Problem tritt nur mit dem neuen auf.

@ghost
Copy link

ghost commented Apr 18, 2016

Am 11. April kam eine neue Version von 5.6.x raus. Das Changelog klingt so, als wäre dort dieser Bug behoben.
Hat jemand Zeit und Gerät um das einmal zu testen?

https://www.ubnt.com/downloads/firmwares/XN-fw/v5.6.4/changelog.txt

@neocturne
Copy link
Member

@txt-file, das wäre wieder nur ein Workaround, der echte Fix muss im Kernel passieren. @FabianCernota, wie sieht's mit dem Testgerät aus?

@SilversurferCH
Copy link

Ich habe gerade mal mit der 5.6.4 getestet. Leider gleiches Ergebnis. Gluon war 2016.1.3.

@neocturne neocturne added the 0. type: bug This is a bug label May 6, 2016
@neocturne neocturne added this to the 2016.2 milestone May 6, 2016
@neocturne neocturne self-assigned this May 6, 2016
neocturne added a commit that referenced this issue May 9, 2016
@LeSpocky
Copy link
Contributor

Erfolgreich getestet mit gluon v2016.1.5: https://map.md.freifunk.net/#!v:m;n:68725142b11b 🍻

@viisauksena
Copy link
Contributor

ich habe mit unserem letzten update alle betroffenen cpe210 v1 und v1.1 abgeschossen .. symptom : Geräte tot, leuchtet nur noch power - meist nur config mode
der upgrade passierte von
v2016.1.5.u / gluon-v2016.1-183-gfb8c7a8
auf
v2016.1.6 / gluon-v2016.1-295-gc673356
mit den 841 egal welcher art gibt es keine Probleme mit der FW ... ich wüsst nicht wie ich da noch mehr Info liefern könnt.. ich Versuch nochmal ganz neue FW zu bauen und die zu flashen

@neocturne
Copy link
Member

@viisauksena

  1. Was hat das mit diesem Ticket zu tun??? Receiver-Bug in CPE210/CPE510 #796 war das einzige CPE-spezifische Ticket in letzter Zeit... und wenn du dir unsicher bist, mach lieber ein neues Ticket auf.
  2. Was sind das für Versionsnummern? v2016.1.6 kommt aus dem Stable-Branch, v2016.1-295 muss ein Master-Commit sein (im Stable-Branch gab es seit v2016.1 nur 83 Commits, keine 295)
  3. Möglicherweise kein make clean nach dem make update ausgeführt? Das würde das Problem in diesem Fall erklären.

@viisauksena
Copy link
Contributor

viisauksena commented Sep 12, 2016

das sind die bezeichnungen aus dem meshviewer, der erste Teil ist selbstgewählt (DEFAULT_GLUON_RELEASE) und der letzte ist systemintern - und korrekt, der kommt aus dem Masterbranch - da die beiden Plattformen ähnlich (so dachte ich - und das oben auch erwähnt wird) sind hab ich das mal hier mit rein genommen / aufgemacht.
aber vielleicht ist extra besser : #881

ecsv pushed a commit to FreifunkVogtland/gluon that referenced this issue Jun 9, 2017
@PolynomialDivision
Copy link

Habt ihr zufällig ähnliche Probleme mit nem 5.4 Kernel auf AR9342? Man findet diesen issue über: https://dev.archive.openwrt.org/ticket/20982

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. type: bug This is a bug
Projects
None yet
Development

No branches or pull requests

9 participants