Questo thread è aperto agli utenti più tecnici per discutere riguardo alle modifiche a caldo del firmware, cioé quelle modifiche che possono essere effettuate senza reinstallare il firmware ogni volta.
Questa è una discussione su Etensione del Kernel all'interno del forum Realtek RTD 1283/1073, nella categoria Processori e Hack Firmware; Questo thread è aperto agli utenti più tecnici per discutere riguardo alle modifiche a caldo del firmware, cioé quelle modifiche ...
Questo thread è aperto agli utenti più tecnici per discutere riguardo alle modifiche a caldo del firmware, cioé quelle modifiche che possono essere effettuate senza reinstallare il firmware ogni volta.
Se ti è piaciuta una discussione, ricorda di cliccare sul pulsante Google +1
che trovi in cima ad ogni discussione in parte al tasto Mi Piace di facebook. Non ti costa nulla ed aiuti 1e2
Stavo pensando alle continue modifiche che dobbiamo apportare al kernel per adeguarlo alle nostre esigenze.
Non so voi ma mediamente per effettuare le prove che mi servono utilizzo un'immagine ad hoc (generato mediante deboostrap) sulla quale eseguo (mediante chroot) i vari processi (vedi amule, transmission ecc) in modo tale da modificare minimamente la struttura interna (e lo spazio limitato della fash del 600).
In pratica quello che stavo pensando era quello di rimuovere by default dal fw originale tutte le customizzazioni fatte gestendo l'inserimento delle estensioni sftruttando il fs del timeshift.
In pratica l'idea potrebbero essere:
Creiamo delle immagini del fs aggiunto (tipo un cramfs o comunque supportato dal kernel) che vengono autopluggate allo start del sistema operativo iniziale (modifica al rc.S sotto /usr/local/etc o forzate da interfaccia web). In tal modo l'estensione delle funzionalitÃ* potrÃ* essere fatta facilmente senza il timore di bruciare qualcosa (nel caso la corrente se ne vada): (quando si aggiorna il fw di fatto di sostituisce ogni volta anche il segmento che permette di far boostrappare il sistema (se non ricordo male è il primo segmento che viene caricato)).
In questo modo potremo gestire facilmente gli aggiornamenti applicativi.
Per quanto riguarda viceversa l'estensione del kernel (aggiunto di moduli ad esempio per agganciare un dvd usb esterno ecc), purtroppo l'unica soluzione è sostituire in tutto il kernel (nel software rilasciato da Ellion non esiste il .config corretto del kernel del 600, e non è abilitato a livello di kernel il reperimento del config sotto /proc). Non dovrebbe essere un problema (sostituirlo visto che andremo a modificare solo l'immagine 2 del fs e non di fatto il bootloader).
Estensione busybox: possibile farlo a patto di ricompilarla con le modifiche apportate da Ellion all'init simulato dalla busybox (non credo sia utile se gestiamo il FS come scritto sopra).
Modifica all'interfaccia web di gestione: da modificare ovviamente la gestione utilizzando i chroot.
Che ne pensate?
L'idea di usare la partizione del timeshift è ottima, io giÃ* ci ho pensato quando ho testato l'installazione di ipkg, però mi è venuto il dubbio che occupando tale spazio (anche se con pochi MB) potrebbe risultare in errori da parte del player quando tutta la partizione si riempie di dati per il timeshift.
Se ti è piaciuta una discussione, ricorda di cliccare sul pulsante Google +1
che trovi in cima ad ogni discussione in parte al tasto Mi Piace di facebook. Non ti costa nulla ed aiuti 1e2
basta, come ho fatto ripartizionare la partizione di timeshift..................Originariamente Scritto da Galerio
penso sia meglio trattare qui quanto di seguito dato che penso possa influire sulle strategie
riporto uno stralcio di alcuni pm che ci siamo scambiati con Puffo123 riguardo alla decompilazione del "core" del firmware rappresentato nell' interfaccia eseguibile DvdPlayer e nel caso specifico si parlava del firmware Xtreamer 2.1 sull' hmr-600w che come ben sappiamo è seguito da un team di sviluppatori a parte che hanno preso la decisione di staccarsi dallo sviluppo del firmware generico che ben conosciamo.
nasoftz ha scritto:
Con la storia del dualboot cioè fare una routine per caricare un firmware o l'altro..a caldo, ottenevamo due dispositivi in 1 e magari creando una patch per applicare i controlli hmr all eseguibile xtreamer, una volta individuato, mantenere la doppia piattaforma con le nuove realese di entrambi....
Ma qui inizia a farsi troppo complicata...rispetto al tempo che ho da buttarci....
la strada per il multiboot pero' l'avevo trovata
puffo123 ha scritto:Modificando il bootloader del primo segmento?
nasoftz ha scritto:
riguardo al multiboot
no molto meno invasivo... appena ho un attimo metto il tutto online cosi' valutiamo collettivamente.. naturalmente la base Venus deve essere eventualmente allargata con un kernel esteso per ottenere uno swap completo in caso di firmware sviluppato da terzi e non sulla solita universale ma fatto questo tramite una semplice routine via interfaccia web far partire l' uno o l'altro firmware
Gli scogli sono il check del display grafico con integrato ic per i firmware playon,emtec, etc....nel quale è sempre presente nei moduli delle lib il driver ic2XXX... e ewqqq...
in alcuni è utilizzato anche come protezione, ma non penso sia difficile escluderlo.
Altro scoglio che puo' insorgere, (lo capisci subito dal tipo di telecomando utilizzato sul modello proprietario del firmware in questione) appunto la routine per il controllo remoto dal telecomando che in alcuni modelli è differente come appunto quello di Xtreamer (con questo se compri un Harmony è cmq utilizzabile su hmr)..
Superati questi due scogli per dirti sarebbe fattibile far partire anche quello del Dvico di firmware...!
Tipo per dire quello del Ryan Playon ha una protezione sull' elf di installazione (install_a) per non farlo installare, infatti prima che flashia sulla schermata blu appare "hardware non compatibile"... che ( non ho avuto pero il tempo di controllare) dovrebbe essere lo stesso trucchetto utilizzato da Xtreamer nelle versioni superiori alla 2.1 ... dopo che i crucchi si sono accorti della fattibilitÃ* di swap con l' hmr..!
tra parentesi ... basta sostituire install_a con quello del firmware dell' hmr, ricompilare e il flash a quel punto parte
I lettori non recorder sono molto piu' interfacciati col web data detta limitazione e competitivitÃ* tra di loro ... e quindi in caso di multiboot realizzabile... non perdendo le funzioni di recording ..a noi ritornerebbero utilissimi anche questi..
puffo123 ha scritto:
tu sei riuscito a ricostruire i parametri del kernel usati dal kernel running? non hanno abilitato il config sotto proc e quello presente nei sorgenti non mi quadra molto.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Torniamo a noi proseguo qui tutto quello che ho testato:]
avevo trovato due alternative.. ma questa penso sia la piu' pratica e piu' facile da implementare dato che potrebbe permettere di apportare minime modifiche al firmware HMr vero' e proprio ogni volta che viene eseguito un aggiornamento "ufficiale". L' ho pensata ragionando sul implementazione del Flash del firmware a caldo di vari dispositivi citati sopra che è eseguibile direttamente da menu' grafico e che non tocca la parte Venus linux su cui si muove il firmware ma solo eventuali modifiche fondamentali ad esso e naturalmente il Core cioè l'interfaccia DvdPlayer che è la parte che piu' a noi in questo caso interessa in fatto di swap e in fatto di tutte quelle funzioni non implementabili linkando sul kernel ma governate nel Core.
Premetto che tutti i firmware che ho avuto modo di esaminare sfruttano la medesima versione Venus di linux e quindi possono tranquillamente girare sulla nostra base kernel magari arricchita e presa a comun denominatore...
1)Prendete un firmware interessante e presumibilmente compatibile con il nostro lettore se ce n'e' piu' di una prendete la versione per "Recovery mode" cioè quella da 0 e non il minifirmware che si flasha a caldo per intenderci quello di dimensioni contenute tipo 14-16mb ma quella di 30-35mb, ad esempio l' xtreamer tipo il 2.0 o quello dell' emtec s800h, fate tutta la procedura estraete l' install.img scompressatelo, analizzatene la struttura... se è di costituzione "classica" e a noi conosciuta ...possiamo proseguire! prendete install2_1.img e trattatelo con unyaffs o similare come spiegato in altro post da Galerio
2)n.b.: si puo' anche tranquillamente sfruttare hd esterno e anche quello interno ma per non complicare la vita tratto il metodo piu' veloce e meno problematico: localizzate ora la directoriy ...usr/local/bin che contiene il Core "DvdPlayer" e le altre sottocartelle con lingua e immagini varie e copiatene il contenuto in una penna usb formattata in modo da trovarvi nella root principale di questa il file DvdPlayer, altri file e le sottocartelle citate, io solitamente rinomino l' eseguibile DvdPlayer per non confondere me e il sistema con quella di base dell' hmr.Collegatela ora all hmr.
ora la parte piu' interessante!
3)entrate in telnet e navigate in tmp usbmounts sda o sdb1 o per interderci la direttrice in cui è stata montata la penna usb. digitare il comando "stopall" il kernel butterÃ* giu' tutto compresa l' interfaccia grafica del Core in esecuzione sull hmr, se avete il tv acceso lo vedrete proprio.
4)lanciate il nuovo Core dalla direttrice della penna usb se non l'avete rinominato o se non siete nella cartella della penna .. specificate tutto il percorso per lanciarlo senno' potrebbe ripartirvi la versione originale. Potete anche vedere tramite telnet tutta la procedura e i check di avvio che fÃ* il programma e se non parte costatarne il perchè al momento, ora abbiamo il nuovo core in esecuzione!
spero di essere stato chiaro ... sono andato parecchio di fretta ma la procedura dovrebbe essere corretta!
Occhio che alcuni firmware come quello del Playon scrivono un qualcosina sulla parte tmp del disco che dopo il primo avvio del nuovo core non permettono piu' l' utilizzo ai successivi tentativi mi sembra in qualche sottocartella /tmp/ramfs/ mentre altri non accade.. per farlo rifunzionare bisogna ripristinare il tutto...
implementando quindi la procedura per buttare giu' il core in esecuzione con il comando stopall dall' interfaccia web dell hmr entrando quindi in webbrowsing con un semplice click sarebbe possibile swappare a caldo dal Core originale a al nuovo e mandarlo in esecuzione sull hmr automaticamente senza nessuna altra operazione! Ad esempio significherebbe far convivere due dispositivi in uno tipo Hmr/Xtreamer oppure utilizzare release differenti dello stesso firmware distribuito per hmr!
.....nonchè testare al volo mod del Core!
Questo mi e' chiaro (magari basta poi una semplice modifica al watchdog e qualche bella configurazione di tasti del telecomando....): non vi nascondo che mi piacerebbe riuscire ad integrare la scheda satellitare usb (anche se sinora il gruppo linuxtv non ha creato dei driver funzionanti )