Linux auf X301T - Wie jetzt?

[sony]

Moin Leute,
Also ich hab ne frage. Ich hab schon überall nach einem Tutorial für Linux gesucht, nur nirgends gibbed eins was brauchbar ist.
Kann mir hier einer helfen?
PS: Ich versuche erstmal die Festplatte im LAN freizugeben, danach das ding zu einem Server umzubauen. (Ich habe halbwegs erfahrung)
Sorry wenn ich Threds übersehen habe.. hab nix gefunden

[Hoernchen]

http://www.t-hack.com/wiki/index.php/Main_Page Unten, ganz versteckt unter dem unscheinbaren Titel "Linux"
Alternativ kannst du dir den yamonteil und die serielle Konsole sparen und direkt die Kernelparameter einkompilieren und dann einen sshd starten.
Festplatte mounten usw geht auch ganz normal, die Frage ist vielmehr "was dann", das ucodeproblem ist noch immer nicht gelöst, daher ist das Linux auf der Box momentan relativ nutzlos.

[sony]

Thx für die antwort, warten wir mal ab, wann ein Stable Linux kommt
Textbasiert reicht ja vollkommen aus^^

[Hoernchen]

Durch Warten passiert hier aber nichts. Wenn du willst das es eines Tages sinnvoll nutzbares Linux (aka popcornhour firmware..) gibt, arbeite aktiv dran.

[mce2222]

@hoernechen:   full ack

@sony:  das linux ist so stable wie es geht. die uCodes haben nichts mit dem Kernel zu tun...

[yoshi2001]

Kann man die benötigten Ucodes nicht aus der Original Firmware extrahieren ?

[mce2222]

doch klar... die ucodes sind alle da ... nur kann man sie nicht laden.
wenn du rausfindest warum, dann wären hier sicher ne menge leute glücklich

[andi]

meiner meinung nach, sind die ucodes der pch (und alle anderen mir bekannten linux boxen) nun leider mit den falschen keys signiert!!
also keys, die dem smp in der x300t sagen, diesen ucode nicht zu laden bzw. zu starten, weil geladen werden sie ja, so lange wie das dauert :-)

@mce2222: warum allerdings die von dir extrahierten "windows"-ucodes nicht wollen, ist mir auch ein rätsel ..

cheers
andi

[Hoernchen]

Um herauszufinden was da nun los ist müsste man mal verhindern das der iptv-bootloader startet, und stattdessen einen zboot oder besser yamon per jtag ins ram laden und ausführen und schauen was dann ladbar ist.
Zumindest die windows-ucodes sollten dann definitiv funktionieren, wenn nicht liegt das Problem irgendwo wo anders...
Das Laden des bootloaders zu verhindern ist aber nicht ganz einfach, den Flashchip kurzschliessen fällt schonmal weg, weil das XOS ohne xenv aus dem Flash vermutlich irgend einen Mist macht der den Chip in keinen sinnvollen Zustand bringt.

[andi]

Das Laden des bootloaders zu verhindern ist aber nicht ganz einfach, den Flashchip kurzschliessen fällt schonmal weg, weil das XOS ohne xenv aus dem Flash vermutlich irgend einen Mist macht der den Chip in keinen sinnvollen Zustand bringt.

naja, man kann ja ohne probleme den flash löschen und dann nur die par xenv parameter flaschen! dann ist nach dem laden definitiv schluss :-)
problem ist nur, wie man danach den code gestartet bekommt! ich habe es zwar nie probiert, aber mce2222 hatte probleme dabei, in den ram kopierten code zu laden!
theoretisch natürlich kein problem den pc zu verbiegen und dann weiterlaufen zu lassen! aber sind wir mal ehrlich, wenn es so einfach wäre, dann hätten sie sich den ganzen signatur quark auch sparen können ;-)

aber ich denke mce2222 äußert sich dazu noch :-)

so long ..
andi

[Hoernchen]

Selbst wenn es "so einfach" ist, das Laden des Bootloaders ins ram geht halt nur per JTAG, es sei denn jemand findet raus was man alles beim iptv-bl wegpatchen muss damit es geht..
Dank gebautem Modchip sind solche jtagspielereien nun wieder ein Problem für mich :/

[mce2222]

also das starten des bootloader zu verhindern ist sehr einfach ... da muss einfach nur 1 byte irgendwo im bootloader geändert werden, so das die signatur nicht mehr korrekt ist... dann sagt der XBOOT im XPU   "zboot: failed"  und die CPU wird dann auf ne endlosschleife bei bf800000 geschickt... (bin nich mehr 100% sicher ob die addresse richtig ist)

das mit dem PC verbiegen ist aber nicht so einfach. per JTAG kann man den PC nicht direkt ändern. es gibt nur den Umweg über DEPC. das hatte ich probiert und es schien ab und zu zu klappen... aber komischer weise nicht immer.
was aber noch mehrwürdiger war, ist das der ins ram geladene zboot trotzdem nicht funktionierte.
ich befürchte das die CPU Initialisierung durch die XPU nicht vollständig durchgeführt wird, wenn die bootloader Signatur inkorrekt ist.

ausserdem bin ich auch nicht sicher ob ich den JTAG code richtig zusammen gebaut hab.

neu im .h file

Code: [Select]

unsigned int jump_module[] = {
               // #
               // # MCE2222 jump to specified address
               // #
   //      start:
               // # Load R1 with the address of the pseudo-address register
  0x3C01FF20,  // lui $1,  0xFF20
  0x34210000,  // ori $1,  0x0000
               //
               // # Load R2 with the address to jump to
  0x8C220000,  // lw $2,  ($1)
   //
   //# store the current DEPC in R3
  0x4003C000,  // mfc0 $3, $24
               
   //# update DEPC with R2
  0x4082C000,  // mtc0 $2, $24
               
               // # Store the value into the pseudo-data register
  0xAC230004,  // sw $3, 4($1)
 
  0x00000000,  // nop
  0x1000FFF9,  // beq $0, $0, start
  0x00000000}; // nop

   unsigned int getPc_module[] = {
               // #
               // # MCE2222 jump to specified address
               // #
   //      start:
               // # Load R1 with the address of the pseudo-address register
  0x3C01FF20,  // lui $1,  0xFF20
  0x34210000,  // ori $1,  0x0000
               //
               // # Load R2 with the address to jump to
  0x8C220000,  // lw $2,  ($1)
   //
   //# store the current DEPC in R3
  0x4003C000,  // mfc0 $3, $24
               
               // # Store the value into the pseudo-data register
  0xAC230004,  // sw $3, 4($1)
 
  0x00000000,  // nop
  0x1000FFF9,  // beq $0, $0, start
  0x00000000}; // nop


und der aufruf im .c file

Code: [Select]


unsigned int ejtag_get_pc()
{
   address_register = 0x0;
   data_register    = 0x0;
   ExecuteDebugModule(getPc_module);
   return(data_register);
}

unsigned int ejtag_set_pc(unsigned int addr)
{
   address_register = addr;
   data_register    = 0x0;
   ExecuteDebugModule(jump_module);
   return(data_register);
}


das get_pc scheint immer richtig zu funktionieren.
beim set_pc und anschliessendem get_pc kam bei mir nicht immer das erwartete Ergebnis raus.

[mce2222]

angeblich sollen ja auch hardware breakpoints funktionieren... das hatte ich bisher noch nicht ausprobiert.
damit könnte man vielleicht auch das Patchen etwas vereinfachen, weil dann das timing wahrscheinlich weniger kritisch ist ??
ich bin mir nicht ganz sicher wieviel Zeit zwischen "Aktivierung des JTAG" und dem "Starten des bootloaders" liegt, aber ich vermute es ist ein grösserer Zeitraum als der zwischen  "vollständigem Kopieren des entschlüsselten bootloaders ins ram" und dem "Starten des bootloaders"

[Hoernchen]

Direkt mal eine Verständnisfrage, wieso per mtc0 / depc und wo steckt das deret ? Ich will doch eigentlich nur den PC abändern, genau das tut doch ein simples jr..
Meine Lösung wäre eher sowas Simples wie

Code: [Select]


lui $1, 0xFF20
ori $1, 0x0000
lw $2, ($1)
jr $2
nop

oder per cp0

Code: [Select]

lui $1, 0xFF20
ori $1, 0x0000
lw $2, ($1)
mtc0 $2, $24
ssnop
ssnop
deret


[mce2222]

der PC wird beim jtag-break in DEPC gesichert und beim DERET zurückgesichert... daher wirkt sich die Änderung des PC nicht auf den normalen Programmablauf aus (wär ja auch irgendwie störend)

der DERET ist in dem JTAG code nicht mit enthalten... das wird anschliessend aufgerufen... was keinen Unterschied machen sollte.

aber dein code  mit cp0 sollte genauso funktionieren. bei mir ist eben noch zusätzlich die Rückgabe des alten PC Werts mit drin.