Trinity V2 mit J5 Jumper Hilfe!

[Don de Deckelwech]

Hi,
zuerst mal: recht mutig, Respekt, hätte ICH ohne Rückmeldung eines Experten so nicht gemacht!

Aber: geändert hast du scheinbar diesen Teil hier, von
e0631000.flash_nand:56m@0k(root0),16m@56m(var),-(root1) zu:
e0631000.flash_nand:56m@0k(root0),32m@56m(var),-(root0)

Also was bzgl /var (also der Var-Partition von 16 auf 32MB mehr Platz eingeräumt) und das mit root0 macht afaik überhaupt keinen Sinn (so hast du 2mal root0, das KANN nur Probleme bereiten).
Probleme beim Flashen hast du doch aber vom uldr.bin (jetzt scheinbar aber nichtmehr, laut letztem Log) und vorallem u-boot.bin, dahingehend hast du aber ja garnichts in den Bootargs verändert. Nur komisch, das der uldr jetzt zu flashen ging.

Meine Vermutung wäre: du musst die env-Partition löschen und dann hoffen, dass die jetzigen uldr und u-boot mit richtigen Default-Variablen startet. Bei der Link funzte das damals nicht, weil, durch einen kleinen Fehler seitens CST, die (ohne env-part.) verwendeten Defaults nicht zur Box passten, jedenfalls hatte ich das damals so verstanden. Aber das ist nur eine Vermutung, ich steck da nicht sooo tief in der Materie).

Und nein, ich rate dir dringend nicht, da jetzt einfach so iwas auf geradewohl zu verändern, wenn du nicht ganz genau weisst, was du da machst. Warte lieber ab, bis ein Experte was dazu sagt. Es müsste jemand mit einer Trinity v1 mal die Ausgabe von "printenv" posten, damit man (also du ) das direkt vergleichen und entsprechend ändern kann...

Ich hab schon vanhofen per PN gefragt, aber der kann leider auch nicht helfen, gandharva wäre da eher gefragt oder jemand anderes...

Ciao,
DdD.

edit: mehrmals editiert, bitte unbedingt alles nochmal lesen!!!

[Joerg]

ud per se hätte die Trinity dpch nicht die kleinen Partitionen der Link, sondern
e0631000.flash_nand:256m@0k(root0),32m@256m(var),-(root1)

[tomworld]

reading u-boot.bin

347008 bytes read
CST HD2 # sfc erase u-boot.bin

SFC erase: 'u-boot.bin' is not a number

vielleicht sollte man sich diesen Fehler ergooglen, was ich noch nicht weiß, was man hier eigentlich mit Tera Term und Jumper 5 macht, es gibt genügend Beschreibungen und auch bereitgestellte Dateien für eine Wiederherstellung

[Joerg]

grunsätzlich scheint er schon recht weit, abgesehen von der falschen Partitonsgrösse zu sein
was das erasen angeht
CST HD2 # sfc erase u-boot.bin
ich denke das düfte nur heissen
CST HD2 # sfc erase u-boot (u-boot.bin gibts als Partition nicht, das ist nur die Datei/Binary, die nachher rein soll)

[Don de Deckelwech]

Hi,
@ Joerg: prinzipiell richtig (stimmen die Werte?). Aber falls man es schafft, die richtigen Dateien (uldr und u-boot) auf die Box zu bekommen sowie die env.bin löscht, dann müsste alles wieder gut sein. Nur ist da jetzt der Wurm drin...
edit: @ Joerg: das macht aber die Box, das sind keine Eingaben von ihm. Und natürlich hat u-boot sehrwohl eine eigene Partition.

Ciao,
DdD.

edit2: ich verstehe den Bootvorgang so:
Bei Strom an, wird (wie auch immer, im PC wird ja auch *iwie* das Bios gestartet) zuerst der uldr gestartet, der guckt in der Env-Partition seine ganzen Bootargs nach (vllt auch noch als zweites u-boot und der schaut dann die Bootargs nach, ist hier im Detail aber egal, es müssen immer beide zueinander und zur Box passen). Ist die Env leer, dann werden stattdessen einkompilierte Defaults verwendet, die müssen dann aber auch wirklich zur Box passen, das ist damals den Link-Boxen auf die Füsse gefallen, weil nicht der Fall.
In den Bootargs steht u.a. die Aufteilung und Grösse der einzelnen Partitionen, wenn es da einen Fehler gibt (so wie hier), dann kann die Box sich selbst nicht mehr flashen, als Symptom kommt dann das "...is not a Number".
Klappt aber alles, wird der Kernel gastartet, welcher dann iwann das Root bootet (und /var einhängt)... Naja, bestimmt nicht 100% korrekt, aber so verstehe ich das.

[Joerg]

@Don
nein, die Box schreibt nur als Antwort auf den fälschlichen Befehl, dass die Partition u--boot.bin nicht gefunden wurde, aber erstmal muss der Befehl eingegeben werden (erkennt man an dem Log auch am
CST HD2 # sfc erase u-boot.bin
SFC erase: 'u-boot.bin' is not a number (also einmal der Prompt mit der Raute vor der Eingabe und als Antwort dann direkt (entweder direkt/von alleine oder nach einem weiteren Enter drücken hat man dann wohl wieder die Raute/Eingabeaufforderung
also u-boot ist eine Partitin, u-boot.bin ist eine Datei *g*

PS: wenn man keine env.bin hat bin ich auch recht sicher, dass das Löschen der env helfen sollte, bei vielen Image-Wechsel-Problemen wird ja auch zu einer leeren Datei env.bin geraten, was dann im normalen Updateprozess einer Löschung gleich kommt. Also würde ich mit erase env geolgt von savenv versuchen.

[Don de Deckelwech]

Hi,
du hast Recht, jetzt habe ich verstanden, was du von Anfang an sagen wolltest, ich blöd...

edit: das erklärt auch, warum das Löschen und Flashen von uldr geklappt hatte! Hehe

edit2: also @ jimmy: versuch nochmal, aber diesmal nach
CST HD2 # fatload usb 0 $loadaddr u-boot.bin
dann anschl
CST HD2 # sfc erase u-boot
also mit ohne .bin !!!

Ciao,
DdD.

[Joerg]

na ich bleib jetzt mal hier um es zusammen zu halten, auch wenn es nun einen Thread dafür im db2w gibt

also eben, die Befehle erase und write beziehen sich auf die Partitionsnamen (uldr und u-boot), während vor dem jeweiligen Befehl die passenden Daten uldr.bin bzw env.bin über den fatload-Befehl in den RAM geladen werden

was mich ja wundert, dass im db2w jemand ein Printenv geschrieben hat und zumindest dort root0 auch mit 56m angegeben ist
jetzt steht aber auch nicht dabei, ob derjenige eventuell auch schon probleme hatte mit "falschem Image flashen"
Tatsache ist doch (wenn ich ins Wiki gucke), dass die Box 512MB NAND Speicher hat. Von daher sollten 256MB rot und 32MB var doch problemlos gehen (es bleiben dann der Rest = 224MB für root1 übrig)
also der von mir verlinkte Bootlog sagt ja eigentlich auch, dass es 256MB root 0 sind und nicht nur 56MB

[jimmy]

so jetzt habe ich das so gemacht
--------------------------------------------------------------------------------
| U-Boot 2009.08-00067-gebbd4b2 (Apr 03 2015 - 16:35:07) CST HDx |
|------------------------------------------------------------------------------|
| Chipset information |
| Vendor: NXP Type: Shiner-IP Revision: M1 Fuses: 00157370 |
|------------------------------------------------------------------------------|
| Clock information |
| *** not available yet *** |
|------------------------------------------------------------------------------|
| Frontpanel information |
| Vendor: CST Version: 5.1 Display: none |
|------------------------------------------------------------------------------|
| Memory configuration |
| Start | End | Type | Description |
|----------+----------+---------+----------------------------------------------|
| 00000000 | 0FFFFFFF | RAM | System main memory bank #0 (256M) |
| 20000000 | 2FFFFFFF | RAM | System main memory bank #1 (256M) |
| D0000000 | D03FFFFF | S-FLASH | Eon Silicon EN25Q32 ( 4M / 64K x 64) |
| 00000000*| 1FFFFFFF*| NAND | Toshiba NAND 512MiB 3,3V 8-bit |
|------------------------------------------------------------------------------|
| Network configuration |
| MAC: LIP 6300 address: 00-C5-5C-3B-21-E6 |
--------------------------------------------------------------------------------

Hit any key to stop autoboot: 0
CST HD2 # usb start
(Re)start USB...
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
CST HD2 # fatload usb 0 $loadaddr uldr.bin
reading uldr.bin

55560 bytes read
CST HD2 # sfc erase uldr

SFC erase: offset 0x0, size 0x40000
OK
CST HD2 # sfc write uldr

SFC write: offset 0x0, size 0x40000
262144 bytes written: OK
CST HD2 # fatload usb 0 $loadaddr u-boot.bin
reading u-boot.bin

347008 bytes read
CST HD2 # sfc erase u-boot.bin

SFC erase: 'u-boot.bin' is not a number
CST HD2 # fatload usb 0 $loadaddr u-boot.bin
reading u-boot.bin

347008 bytes read
CST HD2 # sfc erase u-boot.bin

SFC erase: 'u-boot.bin' is not a number
CST HD2 # sfc erase u-boot

SFC erase: offset 0x40000, size 0x80000
OK
CST HD2 # saveenv
Saving Environment to SFC Flash...
CST HD2 #

dann habe ich das noch eingegeben
sfc erase env.bin

CST HD2 # saveenv

ja endlich geschafft box bootet wieder geil!

[Don de Deckelwech]

Hi,
sehr schön!
Allerdings hast du das u-boot zwar erfolgreich gelöscht, aber nicht geschrieben! Aber wenns trotzdem klappt, sehr gut, Hauptsache Ziel erreicht...

Ciao,
DdD.

[Joerg]

@jimmy
wirklich sicher ?
also ich weiss nicht.... u-boot-Partition löschen und keine neue schreiben und das auch tatsächlich erfolgreich (Antwort OK im Terminal) direkt gefolgt von saveenv
Da würde ich nicht mal erwarten beim nächsten Reboot noch per Terminalprogramm auf die Box zugreifen zu können
erase env.bin müsste wieder mit einem "not a number" (= nix gelöscht) geendet sein, der Teil fehlt aber einfach "im Log" aber hier wäre ein reines löschen auch OK, die wird neu erstellt wenn sie fehlt, dazu raten andere Anleitungen sogar.
Wenn ich mir so eine u-boot.bin einer Trinity-v1 so ansehe mit einem Editor, dann stehen da auch die Partitionsgrössen mit drin, von daher dürfte die vorher manuell eingegebene Reduzierung auf 56MB rootfs0 wieder überschrieben sein mit 256MB - so man die u-boot nicht nur gelöscht hat sondern eine neue in den Speicher rein schreibt !
Hier kann jimmy ja vielleicht nochmal gucken unter Informationen > Box Informationen, was als rootfs-Grösse angegeben ist, aber sollten wieder 256MB sein.

Also ich glaube hier hat jimmy einfach den ein oder anderen Punkte vergessen, dass es hier keine Antwort (erolgreich oder nicht erstmal egal) auf die Eingabe von erase env.bin gibt vor dem saveenv zeigt auch, dass hier nicht simpel mit copy & paste das Log reinkopiert wurde, sondern Teile zusammengesetzt wurden.

Wer immer das hier später nochmal liesst zur Rettung seiner verflashten Box: sehr vorsichtig sein mit dem was da steht ! Ich würde behaupten, dass man so nur Türstopper erzeugt, wenn man die u-boot-Partition löscht ohne nachher eine neue rein zu schreiben

[annie]

sfc erase env.bin

Das hat Ihm die Bootargs wieder zurecht gerückt..

schön das du es hinbekommen hast !

[Joerg]

ist das wirklich so schwer zu verstehen, dass ein erase env.bin bestenfalls eine Datei löscht, aber keine Partition ?
also das Log ist da doch ganz eindeutig nicht vollständig, zwischem dem erase-Befehl und dem saveenv muss auf jedenfall ein Antwort erfolgt sein (erstmal unabhängig ob erfolgreich oder nicht) und nicht direkt der Prompt kommen.
Ich will ja keine Absicht unterstellen, aber es ist schon sehr schade, wenn solche halben/nicht wirklich vollständigen Logs gepostet werden und drunter auch noch steht "jau super, funzt alles wieder, echt geil", denn dann mag sich jemand der auf der Suche nach einer Lösung ist schnell motiviert fühlen es genauso zu versuchen, vorallem wenn es auch noch "positiv kommentiert wird" - aber so wie hier im Log dargestellt erzeugt es nur einen Türstopper (also da bin ich mir schon sehr sicher). Ich bin da auch kein Meister, aber ich hab schon öfters an diesen Stellen rum gefummelt, z.B. bei mehreren alten Neo-1 Geräten die u-boot getauscht, damit auch diese ohne PC und Recovery-Tool direkt vom USB Stick geflashed werden können (wie bei den neueren Geräten üblich).

[annie]

wenn man die env.bin löscht, werden die Bootargs damit gelöscht.

nach reboot schreibt die uboot dann die richtigen Standartwerte in die bootargs und alles ist gut !

[Joerg]

ich kann es nur wiederholen: env.bin ist eine Datei, welche man in die Partition env einspielen kannn
also man läd die env.BIn in den RAM via fatload und spielt diesen RAM-Bereich via write env in die vorher gelöschte Partition

und aus der u-boot kann so wie es hier steht nix mehr in die env übernommen werden, weil die wurde ja ersatzlos gestrichen - erst der Fehlversuch die u-boot.BIN zu löschen, dann ganz korrekt die u-boot-Partition erased, was das System auch mit OK bestätigt hat um dann mal eben aufzuhören (diese u-boot Bereich wird eh völlig überbewertet *kopfschüttel*)

[jimmy]

also wie gesagt erst wo ich env.bin gelöscht habe konnte ich Via USB flashen vorher ging das nicht egal was ich gemacht habe

nach erase env.bin ging es warum weis ich nicht!
aber hat geklappt!

mfg Jimmy!

[tomworld]

danke für die Rückmeldung

[Denenton]

Hab leider auch den Fehler gemacht ein Kronos Image auf die Shiner Trinity zu flashen. Nun geht nix mehr. Flashen via USB ist nicht möglich. Anschluss per Com Kabel und Putty: keine Reaktion.
Wahrscheinlich muss ich den Jumper setzen?? Aber wie öffne ich die Trinity überhaupt?!? Bei mir ist nur unten eine einzige Schraube und hinten links eine Schraube. Habe aber keine Idee wie ich das Ding nach aufschrauben der beiden Schrauben aufkriege. Muss ich das transparente Plastik irgendwie mit Gewalt wegziehen, oder gibt es da nen Trick?
Danke für eure Hilfe im voraus!

[Miky]

Ich glaube, unter den Füssen sind noch Schrauben. Bin mir da aber nicht 100% sicher.

[Denenton]

Danke für den Hinweis. Man muss die Gummiauflagen entfernen und darunter sind dann in der Tat die Schrauben. Hätte man fast selber drauf kommen können ... Nochmal Danke!!