Mediabox Realtek - Hack e modifiche del firmware

[stedrum]

si, esiste il DvdPlayer per il 351H.
Ci ho smanettato parecchio ma purtroppo il 351h usava il chip 1262 cehe non è compatibile con il 1283. L'unica cosa che si può fare con quei sorgenti è prendere le librerie , studiarsele bene, prendere il kernel per 1283 e modificare i sorgenti in modo da adattarli.
Oppure prendere le librerie giÃ* compilate per un player 1283 tipo l'asus o-play e usarle per sviluppare altre applicazioni(vedi progetto ketlaer).
In ogni caso è un casino unico....ci vuole tempo, conoscenze approfondite ecc...considerando che il 1283 è pure vecchio forse non vale la pena spendere tempo e risorse su di lui.
Tuttavia, siccome sono testardo, proverò a fare altri smanettamenti col kernel (tempo libero permettendo)

[Hammarby]

Hey ragazzi ho pensato una cosa: l'applicativo DvdPlayer è closed-source ma sappiamo che gestisce tutte le funzioni del player. In modo molto sintetico funziona così: - inizializza l'hardware - inizializza le strutture - monta i devices - sincronizza RTC - scrive a video - prende l'input del telecomando tramite /dev/ir_venus ora: il motivo per cui non possiamo far girare altro software è che non conosciamo il chip, quindi non possiamo scrivere codice. I sorgenti del kernel però li abbiamo, completi di drivers! Dunque: se ad esempio provassimo a compilare il DirectFrameBuffer potremmo provare a scrivere a video direttamente da console. Nel caso funzionasse potremmo compilare un server grafico e farci girare "qualsiasi" cosa. che ne dite? potrebbe funzionare o sto dimenticando/tralasciando qualcosa?

Il kernel contiene soltanto l'interfaccia generica verso i moduli, e la parte closed-source viene rilasciata appunto come modulo. L'unica cosa che puoi ricavare è l'API, ma in Linux questa è abbastanza standard. I drivers che vengono rilasciati come moduli sono diversi, e tutti quelli closed source sono rilasciati come moduli, come dire che il kernel è completamente disponibile, ma dei drivers non si riesce a sapere nulla. Mi dispiace per chi ci sperava...

[stedrum]

Però avendo a disposizione i sorgenti completi del 351 e il kernel del 1283 si potrebbe provare ad adattare i moduli del 351, no?

[Hammarby]

Però avendo a disposizione i sorgenti completi del 351 e il kernel del 1283 si potrebbe provare ad adattare i moduli del 351, no?

No (ahimé)
A meno che tu non abbia il manuale di riferimento dell'HW.

[Hammarby]

Un link, ed un tool, particolarmente utili ed interessanti
Buildroot

[bovirus]

Peccato che non abbai le opzioni per mipsel (processore Realtek).

[Hammarby]

Peccato che non abbai le opzioni per mipsel (processore Realtek).

Beh, in realtÃ* MIPS c'è, e mipsel è solo la variante little endian, ma comunque manca sempre la documentazione realtek, o (sarebbe ancora meglio) tutti i driver per Linux giÃ* fatti.

[bovirus]

Il problema che purtroppo mips e mipèsel sono due mondi differenti....

[stedrum]

ma buildroot non ci serve: abbiamo giÃ* la toolchain per cross-compilare.

Vi aggiorno sulle ultime scoperte:
Prima di tutto: ho praticamente abbandonato lo sviluppo sul medley perchè ormai è un prodotto datato e il fatto di essere così "closed-source" non aiuta.
Sono comunque riuscito a smanettare un pò con il bootloader, che è lo YAMON ma modificato da REALTEK.
E' possibile caricare un immagine kernel e avviarla al boot, ecco come fare:
PER I SUCCESSIVI PASSI E' NECESSARIO AVERE LA TOOLCHAIN INSTALLATA NEL SISTEMA
- procurarsi il kernel da compilare (io ho usato quello originale del medley e ho attivato alcuni moduli che nella versione orginale sono disattivati)
- cross-compilare il kernel con la toolchain
- alla fine della compilazione avrete due file fondamentali: vmlinux e vmlinux.develop.avhdd.mars.nand.bin.
Il primo è l'eseguibile, linkato staticamente, che contiene il kernel in formato ELF (compatibile con la macchina per cui è stato compilato, in questo caso MIPSEL) e il secondo è sempre il kernel ma in formato binario.
Lo yamon bootloader può caricare un kernel in formato srec quindi dobbiamo convertire l'eseguibile vmlinux con il comando:

objcopy -O srec vmlinux vmlinux.srec"

; otteremo così un kernel caricabile via YAMON.
Ora bisogna connettersia via convertitore seriale-ttl-usb al medley e premere "ESC" per entrare nella modalitÃ* recovery.
A questo punto digitare:

load asc://tty0

che serve per caricare un file di testo via seriale.
A lato HOST, quindi aprendo un terminale dalla nostra distro, bisogna inviare il file vmlinux.srec alla seriale facendo

cat vmlinux.srec > /dev/NOME_DEL_DISPOSITIVO

.
NOME_DEL_DISPOSITIVO dipende da che tipo di convertitore usate, nel mio caso essendo USB il device da usare è /dev/ttyUSB0.
A questo punto il kernel viene inviato al medley e il bootloader lo carica temporaneamente(al riavvio verrÃ* caricato quello sulla flash memory), permettendovi di usarlo.
Se invece volete caricarlo sulla flash memory dovete usare il comando:

fread: tftp://IP_DEL_SERVER_TFTP

in questo caso però non potete usare la console seriale,inoltre bisogna caricare l'immagine in formato bin.
Dovete quindi aprirvi un server TFTP sulla distro, caricarci il kernel e poi dal medley leggere il tutto.
Altrimenti potete provarlo con il primo metodo e poi caricarlo nell'immagine install.img così da installarlo con il metodo "TASTO retro+HOME".

[bovirus]

Che moduli hai attivato nella compialzione del kernel che non sono inclusi nel firmware base del medley?