USB Firmware update - andreoidb64/uebbi GitHub Wiki
Questo progetto nasce per superare i noti problemi di compatibilità di lettura dei supporti SD usati per fare l'aggiornamento del firmware di Uebbi (Webby).
Il sistema di avvio originale è il file Vmlinux.gz presente nel firmware “SFR Hubster” depannage.zip. Diversamente dai sistemi di avvio tradizionali di Linux, che si basano su un bootloader con parametri di avvio configurabili che indicano, tra l'altro, il nome file del kernel e quello del filesystem root iniziale (initrd), nel nostro caso il bootloader non è configurabile e il file Vmlinux.gz contiene sia il kernel che il filesystem initrd.
Attualmente, in mancanza del codice sorgente del kernel, il procedimento per realizzare il boot da USB rimane un poco laborioso. L’ideale, per completare il lavoro, sarebbe di ricompilare il file kernel+initrd in un unico file Vmlinux.gz come nel firmware originale “SFR Hubster” o, meglio ancora, riuscire a realizzare un sistema di avvio tradizionale con kernel e initrd su file.
Il progetto introduce anche alcune funzionalità importanti, sia per gli sviluppatori che per gli utilizzatori, che non erano presenti nella versione originale, tra cui:
- Aggiornamento con un solo passaggio anzichè due ("depannage" e "Firmware2.1").
- Debug log del sistema che esegue l'aggiornamento (dmesg, mount, partitions, ps ...)
- Controllo checksum preliminare del firmware: Evita di importare file corrotti.
- Modalità DRYRUN: Simula il processo di aggiornamento senza modificare nulla.
- Migliorata la messaggistica e controllo errori del processo di aggiornamento.
Il processo che esegue l'aggiornamento (update.sh) è stato completamente riscritto ed è ora molto più semplice da modificare e da mantenere.
*Ringrazio Paul Ymer e Frakbe di www.uebproject.org che mi hanno aiutato a scrivere questa sezione.
Premesso che Windows non dispone di tutti i tool necessari per la creazione di un dispositivo di boot per Webby, ho messo a disposizione degli utenti di questo sistema operativo un file raw che potete scaricare qui --> USBFirmwareUpdateSkeleton.dd.gz con cui potete clonare una chiavetta USB bootable già fatta.
Una volta scompattato il file .dd con 7zip o Winrar, potete clonare la vostra chiavetta USB utilizzando un programma che si chiama "HDD Raw Copy Tool" da http://hddguru.com/software/HDD-Raw-Copy-Tool/ disponibile sia con installer sia in versione portable.
- Inserite la chiavetta USB da utilizzare per il firmware update (attenzione si perdono tutti i dati memorizzati, fate un backup se ve ne sono).
- Avviate il programma HDD Raw Copy Tool e selezionate il file sorgente (source) e cioè USBFirmwareUpdateSkeleton.dd (ultima opzione del menu) attivando l’opzione tutti i file
*.*(menu a tendina sotto salva come:)
- Procedete con “continue” e selezionate il dispositivo di destinazione (target) e cioè la chiavetta USB (attenzione a non selezionare un disco fisso o un altro dispositivo perchè procedendo viene ‘distrutto’ tutto il contenuto).
- Avviate con start la copia del file .dd sulla chiavetta. Al termine uscite dal programma.
- Scaricate il file USBFirmwareUpdate.zip (diviso in due parti USBFirmwareUpdate.zip.001 e USBFirmwareUpdate.zip.002).
NOTA: Se il vostro programma di unzip non gestisce file compressi multivolume, potete unirli da riga di comando con un semplice:
copy USBFirmwareUpdate.zip.001 /B + USBFirmwareUpdate.zip.002 /B USBFirmwareUpdate.zip
Oppure:
type USBFirmwareUpdate.zip.001 USBFirmwareUpdate.zip.002 > USBFirmwareUpdate.zip
- Aprite ora il file USBFirmwareUpdate.zip ed estraete tutti i file il cui nome termina con "*-milano" nella cartella “flash” della chiavetta USB.
NOTA: Il setup contiene anche la "Patch per reboot.py" descritta nel wiki.
- Rimuovete la chiavetta USB (safe removal) ed inseritela nel Webby.
- Per attivare il processo di aggiornamento occorre premere contemporaneamente il primo e il quarto pulsante all’avvio finché non compare la barra di caricamento nella parte bassa dello schermo.
----------------- 2016-10-28: AGGIORNAMENTO FIRMWARE 2.2 (Vedi nota in fondo alla pagina)
Naturalmente anche gli utenti di Linux possono utilizzare il file raw che potete scaricare qui --> USBFirmwareUpdateSkeleton.dd.gz con cui potete clonare una chiavetta USB bootable già fatta.
Con Linux questa procedura è anche più semplice perché basta una riga di comando per scompattare il file direttamente sulla chiavetta USB:
# gzip -d -c /MyPath/USBFirmwareUpdateSkeleton.dd.gz | dd of=/dev/sdX dove, al posto della X dovete mettere la lettera con cui è stata riconosciuta la chiavetta.
ATTENZIONE: Il comando cancellerà i dati presenti sul supporto e, se sbagliate lettera rischiate di perdere i dati dell'hard disk!
Analogamente a quanto descritto nella sezione dedicata agli utenti di Windows, si dovranno poi aggiungere nella cartella “flash” della chiavetta USB tutti i file il cui nome termina con "*-milano" estraendoli dal file USBFirmwareUpdate.zip
----------------- 2016-10-28: AGGIORNAMENTO FIRMWARE 2.2 (Vedi nota in fondo alla pagina)
A questo punto la parte pratica è completata. Se però siete interessati a conoscere tutti i dettagli di come funziona il boot da USB per Uebbi, leggetevi il resto della guida e, eventualmente, provate anche voi ad eseguire tutti i passaggi.
Per prima cosa, bisogna creare due partizioni su una chiavetta USB. Per farlo, bisogna necessariamente utilizzare un sistema linux, dal momento che Windows non gestisce questo tipo di partizionamento. La prima partizione dev'essere una normale partizione DOS, mentre una seconda partizione linux (id=83) va preparata per ospitare il filesystem ext2 del sistema operativo di avvio che occupa circa 50MB.
Il comando linux da usare per creare le partizioni è "fdisk /dev/sdX" dove, al posto della X dovete mettere la lettera con cui è stata riconosciuta la chiavetta. ATTENZIONE: Il comando cancellerà i dati presenti sul supporto e, se sbagliate lettera rischiate di perdere i dati dell'hard disk!
Non sto a spiegare per filo e per segno come funziona il comando "fdisk". Per i meno esperti, mi limito a dire che, una volta avviato, propone una scelta dei comandi con cui procedere al partizionamento del dispositivo di storage.
I comandi principali sono:
- m per l'help
- p visualizza lo stato delle partizioni impostate
- d cancella una partizione
- n crea una partizione
- t modifica il tipo della partizione (id)
- a imposta la partizione attiva (bootable)
- q abbandona senza modificare
- w scrive le modifiche e chiude il programma
Alla fine del procedimento, e prima di confermare le modifiche con w, il comando p dovrebbe stampare un risultato tipo:
Command (m for help): p Disk /dev/sdb: 4009 MB, 4009754624 bytes 124 heads, 62 sectors/track, 1018 cylinders Units = cylinders of 7688 * 512 = 3936256 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 916 3521073 6 FAT16 /dev/sdb2 917 932 61504 83 Linux
I numeri di settori, tracce, cilindri e size ovviamente variano a seconda del dispositivo che state usando (4GB nel nostro caso) mentre il numero della partizione (/dev/sdXN), Id e boot flag devono corrispondere.
Ora che abbiamo creato le partizioni, dobbiamo formattarle in modo opportuno con il comando "mkfs".
ATTENZIONE: Anche questo comando cancella i dati presenti sul supporto e, se sbagliate lettera rischiate di perdere i dati dell'hard disk!
Nel nostro caso, per la partizione 1 il comando è:
root@box:/home/tc# mkfs.vfat /dev/sdb1
Mentre, per la partizione 2 il comando è:
root@box:/home/tc# mkfs.ext2 /dev/sdb2
Cominciamo ora ad analizzare il file Vmlinux.gz presente nel firmware “SFR Hubster” depannage.zip. Come si intuisce dall'estensione GZ, si tratta di un file compresso che contiene il file vmlinux.strip in formato ELF 32bit compilato staticamente per processori MIPS. Basta eseguire una semplice interrogazione con il comando "file" per ricavare queste informazioni.
tc@box:/mnt/HostDisk/uebbi/ReverseEng$ ls -l
total 13444
-rwxr-xr-x 1 root root 13758576 Jul 16 2008 vmlinux.strip
tc@box:/mnt/HostDisk/uebbi/ReverseEng$ file vmlinux.strip
vmlinux.strip: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
Per un'analisi più approfondita di cosa contiene il file, dobbiamo usare strumenti un po' più raffinati che non si trovano già installati nelle normali distribuzioni linux. Ad esempio, possiamo usare "binwalk", un toolkit specializzato per questo tipo di analisi.
tc@box:/mnt/HostDisk/uebbi/ReverseEng$ binwalk vmlinux.strip
DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 ELF, 32-bit LSB executable, MIPS, version 1 (SYSV) 1088404 0x109B94 LZMA compressed data, properties: 0xC0, dictionary size: 16777216 bytes, uncompressed size: 529437 bytes 3420216 0x343038 Linux kernel version "2.6.24 (root@Firm-Ser) (gcc version 3.4.4) #1388 Wed Jul 16 17:57:34 KST 2008" 3429796 0x3455A4 gzip compressed data, maximum compression, from Unix, last modified: 2008-07-16 07:29:48 3618336 0x373620 CRC32 polynomial table, little endian 3981163 0x3CBF6B Unix path: /S70/S75/505V/F505/F707/F717/P8 4035114 0x3D922A Copyright string: "Copyright (C) 2004-2005 Intel Corporation " 4259840 0x410000 gzip compressed data, maximum compression, has original file name: "tmp_ram.img", from Unix 13742080 0xD1B000 gzip compressed data, maximum compression, from Unix, last modified: 2008-07-16 02:08:03
Binwalk, con le opportune opzioni, è in grado anche di "spezzettare" un file binario identificando pattern specifici dei file che sono stati inclusi nella compilazione. Alcuni dei file che si ottengono da questo processo non sono utilizzabili, ma altri possono invece essere molto utili. Nel nostro caso troviamo:
root@box:/mnt/HostDisk/uebbi/ReverseEng/_vmlinux.strip.extracted# ls -l
total 76817 -rwxr-xr-x 1 root root 13758576 Feb 24 23:40 0.elf -rwxr-xr-x 1 root root 12670172 Feb 24 23:40 109B94.7z -rwxr-xr-x 1 root root 27928 Jul 16 2008 3455A4 -rwxr-xr-x 1 root root 512 Jul 16 2008 D1B000 -rwxr-xr-x 1 root root 33554432 Feb 25 01:00 tmp_ram.img
root@box:/mnt/HostDisk/uebbi/ReverseEng/_vmlinux.strip.extracted# file *
0.elf: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped 109B94.7z: data 3455A4: Linux make config build file (old) D1B000: ASCII cpio archive (SVR4 with no CRC) tmp_ram.img: Linux rev 1.0 ext2 filesystem data, UUID=4d932c48-f5a4-4476-aef4-f04bbf389cb4
Di questi file, gli unici che possiamo utilizzare sono "3455A4" che è il file "make.config" con i parametri di configurazione con cui è stato compilato il kernel e "tmp_ram.img" che rappresenta il filesystem in formato ext2 del sistema operativo di maintenance con cui viene eseguito l'aggiornamento.
Per quanto riguarda "make.config", non disponendo dei sorgenti del kernel, possiamo solamente dare uno sguardo alle opzioni che sono state scelte per la compilazione. Interessante ma, in termini pratici, non ci facciamo poi molto.
Il file "tmp_ram.img" invece può essere montato come filesystem, analizzato e infine modificato per ottenere nuove funzionalità.
root@box:/mnt/HostDisk/uebbi/ReverseEng/_vmlinux.strip.extracted# mkdir tmp_ram
root@box:/mnt/HostDisk/uebbi/ReverseEng/_vmlinux.strip.extracted# mount -o loop -t ext2 tmp_ram.img tmp_ram
Una volta montato, possiamo identificare lo script che esegue l'aggiornamento del firmware e modificarlo o sostistuirlo con quello che vogliamo. Nel caso in analisi, il file è "./etc/rc5.d/S99last" che ho modificato per montare il device /dev/sda1 e passare l'esecuzione dell'aggiornamento al file "/mnt/sda1/flash/update.sh", nella partizione VFAT della chiavetta USB.
#!/bin/sh mkdir /dev/fb ln -s /dev/fb0 /dev/fb/0 ## Mount SD memory #mount /media/mmc1 ## Mount USB memory mount /dev/sda1 /mnt/sda1 # Remount root filesystem readonly sync mount -o remount,ro /dev/sda2 ## NAND Update #cd /media/mmc1 cd /mnt/sda1/flash if [ "$?" != "0" ] then /usr/sbin/putfb "Directory not found:" "/mnt/sda1/flash" sleep 2 /usr/sbin/putfb "reboot ... " " " sleep 1 reboot -f fi #cp -f /usr/sbin/update_bg . #cp -f /usr/sbin/putfb . for DUMMY in dmesg "cat /proc/cmdline" "cat /proc/partitions" mount "cat /etc/fstab" ps ifconfig "netstat -an" do echo ":::::::::::: $DUMMY ::::::::::::" $DUMMY done > debug.info ./update.sh & exit
Salviamo le modifiche fatte per poi copiarle nella partizione ext2 della chiavetta USB.
root@box:/mnt/.../uebbi/ReverseEng/_vmlinux.strip.extracted# cd tmp_ram
root@box:/mnt/.../uebbi/ReverseEng/_vmlinux.strip.extracted/tmp_ram# tar -czf ../sdX2.tgz ./
Montiamo la partizione ext2 della chiavetta e scompattiamo l'archivio che abbiamo creato "sdX2.tgz". (per brevità non sto a descrivere questa operazione, eventualmente consultate la sezione 2 del file SETUP.txt)
Ora ci serve un kernel modificato per fare il boot da USB ...
Questa cosa è descritta molto bene nell'articolo http://www.mikrocontroller.net/articles/Webby (peccato sia un pò difficile da leggere se non sapete il tedesco). Fondamentalmente bisogna scaricare il kernel da qui: http://www.mikrocontroller.net/attachment/135815/vmlinux_usbroot.gz scompattare il file e modificare in modo opportuno le opzioni di boot editando il file con un editor esadecimale (puoi usare Notepad++) alla riga 20736, avendo cura di non modificare la lunghezza della riga.
Questi sono i parametri di boot che ho usato:root=/dev/sda2 rootfstype=ext2 noinitrd rev=1.0.0 rootdelay=10
Una volta modificato il file dev'essere ricompattato, sempre in formato GZ, rinominato come "vmlinux.gz" e messo nella root della partizione 1 (VFAT).
Ora avete un sistema bootable e non resta che sistemare gli altri file "*-milano" come descritto nel file "SETUP.txt" che trovate nel file USBFirmwareUpdate.zip (diviso in due parti USBFirmwareUpdate.zip.001 e USBFirmwareUpdate.zip.002).
Rimuovete la chiavetta USB (safe removal) ed inseritela nel Webby. Per attivare il processo di aggiornamento occorre premere contemporaneamente il primo e il quarto pulsante all’avvio finché non compare la barra di caricamento nella parte bassa dello schermo.
========================================
Per applicare questo aggiornamento, occorre sostituire i tre file:
flash/app.cramfs-milano flash/data.yaffs2-milano flash/root.cramfs-milano
Con quelli che trovate in 20161025_ueb_fw2.2.zip , scaricabile dal sito di "U&B Project" (solo per gli utenti registrati).
Una volta sostituiti i tre file, occorre anche aggiornare il file flash/md5sum.txt con i nuovi checksum corretti:
03a0ba78aa2577976b43ee51896317d1 app.cramfs-milano 83984dc6648a52b025f3a4fd296a302d data.yaffs2-milano 106027a1b64b658b3c3b41d8cd9fe07d root.cramfs-milano c108a648e77f1ff74859f20a4cef50c3 yboot.bin-milano 856dc9538b9fe7e2c628ea938589f6c8 zImage-milano c822237e5dec9a59621735107854fb2f putfb f0793f6771a3d75ee09dc880275bab9b update_bg
NOTA PER GLI UTENTI WINDOWS:
Anche se ha estensione TXT, il file è terminato in formato unix (LF) e non DOS (CR+LF).
Di conseguenza non potete usare Notepad o Wordpad per editarlo!
Se avete problemi ad editarlo, potete scaricarlo da qui md5sum.txt