[Thread Ufficiale] TP-Link TD-W8970v1 - Firmware OpenWRT

[matteo85]

Originariamente inviato da lagunarock

Perchè fa così schifo?
A differenza del Lantiq non supporta la VDSL ma è un dual core...

Il Lantiq ha una CPU MIPS 34k a 500 Mhz, il nuovo è dual core, ma ha un vecchio 24k a 400 MHz

Sul piano Wi-Fi non c'è paragone.
Il vecchio ha un Atheros AR9381 a 3 stream (Atheros è lo stato dell'arte del Wi-Fi) ed è supportato da ath9k che attualmente è l'unico driver wifi che funziona bene in modalità AP (a dire il vero è l'unico che funziona in generale)
mentre il nuovo ha una Wi-Fi Broadcom 2 stream che è mediocre (non fa schifo come Realtek e Ralink/Mediatek ma nemmeno eccelle) e soprattutto non ha un driver funzionante (divertitevi con quello opensource, haha)

Lato DSL:
Per quanto riguarda la DSL Broadcom non è messa male, anzi, fanno veramente dei buoni prodotti, ma Lantiq è comunque superiore a Broadcom perchè licenziano il chip da Aware che fa roba seria (andate a vedere che clientela serve )
Resta il fatto che il modem Broadcom NON È SUPPORTATO DA NESSUN DRIVER OPENSOURCE mentre Lantiq ha avuto la furbata di rilasciare il firmware.bin (che in realtà è il driver di Aware che gira sull'hardware) e quindi può essere utilizzaato con OS alternativi come OpenWrt

[ambrosa]

Originariamente inviato da matteo85

Interessante per le pennette, per i dischi invece mi sa che sono quasi tutti da 512b (i più nuovi da 4k)
in ogni caso non si dovrebbe mai mettere meno di 4k

Sicuramente un paio di trucchetti semplici si possono adottare da subito.

1) disattivare il journaling del filesystem per ridurre le scritture

2) opzioni per il filesystem: noatime,nodiratime in modo da non far aggiornare il timestamp con l'ultimo accesso al file/dir , e già qui si guadagna un bel pò (ma questo lo faccio già da sempre anche sui miei PC Linux)

3) questo non lo conoscevo: il parametro del kernel al boot elevator=noop che non ottimizza la scrittura in modo sequenziale pensando di avere a che fare con dischi magnetici (HDD): le flash sono ad accesso casuale e non necessitano di alcuna ottimizzazione sequenziale.

DOMANDA: qualcuno sa suggerirmi programma benchmark per dischi da compilare e lanciare sull'8970: sarei curioso di provare se e quanto si guadagna con queste ottimizzazioni.

[matteo85]

Originariamente inviato da ambrosa

Sicuramente un paio di trucchetti semplici si possono adottare da subito.

1) disattivare il journaling del filesystem per ridurre le scritture

2) opzioni per il filesystem: noatime,nodiratime in modo da non far aggiornare il timestamp con l'ultimo accesso al file/dir , e già qui si guadagna un bel pò (ma questo lo faccio già da sempre anche sui miei PC Linux)

3) questo non lo conoscevo: il parametro del kernel al boot elevator=noop che non ottimizza la scrittura in modo sequenziale pensando di avere a che fare con dischi magnetici (HDD): le flash sono ad accesso casuale e non necessitano di alcuna ottimizzazione sequenziale.

DOMANDA: qualcuno sa suggerirmi programma benchmark per dischi da compilare e lanciare sull'8970: sarei curioso di provare se e quanto si guadagna con queste ottimizzazioni.

Io non disattiverei il journal (sai, se va via la corrente o si scollega l'USB..)

per lo scheduler ci avevamo già pensato

# cat /sys/class/block/mtdblock0/queue/scheduler 
[noop]

[ambrosa]

Originariamente inviato da matteo85

Io non disattiverei il journal (sai, se va via la corrente o si scollega l'USB..)

per lo scheduler ci avevamo già pensato

# cat /sys/class/block/mtdblock0/queue/scheduler 
[noop]

1) lo so che se va via la corrente è meglio avere il journal ma .... quante scritture vuoi che vengano fatte sul disco di sistema ? al massimo si corrompe qualche log. Se il gioco vale la candela...

2) [noop] è attivo anche su eventuali USB stick ? Non posso controllare se non stasera...


Questo è interessante:
http://openbenchmarking.org/tests/pts

[matteo85]

Originariamente inviato da ambrosa

1) lo so che se va via la corrente è meglio avere il journal ma .... quante scritture vuoi che vengano fatte sul disco di sistema ? al massimo si corrompe qualche log. Se il gioco vale la candela...

2) [noop] è attivo anche su eventuali USB stick ? Non posso controllare se non stasera...


Questo è interessante:
http://openbenchmarking.org/tests/pts

proprio perchè le scritture sono poche conviene averlo, no?

[rylos]

Ciao,
ho compilato la r43483 e l'ho messa nel solito posto. (Vi ricordo che si tratta del trunk stable Barrier Breaker).
Ho riattivato anche il repository con i miei packages.

RyLoS

[sunvit]

Come sempre grazie e bentornato.

[minoltista]

Originariamente inviato da sunvit

Come sempre grazie e bentornato.

quoto :-)

[ambrosa]

Originariamente inviato da matteo85

Io non disattiverei il journal (sai, se va via la corrente o si scollega l'USB..)

per lo scheduler ci avevamo già pensato

# cat /sys/class/block/mtdblock0/queue/scheduler 
[noop]

http://www.cyberciti.biz/faq/linux-c...-for-harddisk/

MMhh ho verificato.
I miei dischi NON sono su noop ma su 'deadline'

chiavetta USB da 2 GB
root@openwrt:/# cat /sys/block/sda/queue/scheduler
noop [deadline]

HDD magnetico da 3 TB
root@openwrt:/# cat /sys/block/sdb/queue/scheduler
noop [deadline]

Quindi 'noop' NON è usato di default.
Ma posso impostarlo per sda (chiavetta USB) che conviene.

[roguewave]

@matteo86

allora, io ho messo gli ipkg di saned compilati dentro una usb montata sul router e li ho installati con opkg ma ottengo ancora problemi.

Collected errors:
 * pkg_run_script: package "saned-epson" postinst script returned status 127.
 * opkg_configure: saned-epson.postinst returned 127.
 * pkg_run_script: package "saned-epson2" postinst script returned status 127.
 * opkg_configure: saned-epson2.postinst returned 127.

tu come hai fatto ad installarli?

[matteo85]

Originariamente inviato da roguewave

@matteo86

allora, io ho messo gli ipkg di saned compilati dentro una usb montata sul router e li ho installati con opkg ma ottengo ancora problemi.

Collected errors:
 * pkg_run_script: package "saned-epson" postinst script returned status 127.
 * opkg_configure: saned-epson.postinst returned 127.
 * pkg_run_script: package "saned-epson2" postinst script returned status 127.
 * opkg_configure: saned-epson2.postinst returned 127.

tu come hai fatto ad installarli?

Io non uso opkg, lo flasho ogni volta

[roguewave]

Originariamente inviato da matteo85

Io non uso opkg, lo flasho ogni volta

ma quindi tu li metti statici nel kernel?
io comunque alla fine son riuscito ad installarli, ma scanimage non funziona.

dice command not found, eppure quei pacchetti compilati da me li ho installati correttamente.

se provo ad installare sane-backends mi dice che ci sono dei file già presenti

[roguewave]

ok, ci siamo, ed ora ho capito perchè a te saned occupava cosi poco.
Se si installa il sane-backend ti installa un sacco di pacchetti e anche il frontends.
compilando come mi hai detto tu io ho ottenuto i pacchetti e sono riuscito ad installarli.
Non riuscivo ad ottenere lo scanner semplicemente perchè, sul client, non mettevo

192.168.1.1 6566

nel file di ubuntu, /etc/sane.d/epkowa.conf

[minoltista]

Originariamente inviato da minoltista

Allora circa il problema della condivisione delle cartelle su un hd ethernet:

Ho installato smaba.
smbd avviato con file /etc/config/samba seguente

config samba
option name 'OpenWrt'
option workgroup 'WORKGROUP'
option description 'OpenWrt'
option homes '1'

config sambashare
option name 'TrasmTorrentTmp'
option path '//192.168.0.200/Public/TrasmTorrentTmp'
option users 'Michele,admin'
option read_only 'no'
option guest_ok 'yes'
option create_mask '777'
option dir_mask '777'


eseguo:
#mkdir mnt/TrasmTorrentTmp
#smbd //192.168.0.200/Public/TrasmTorrentTmp /mnt/TrasmTorrentTmp

No mi da nessun errore ma Le due cartelle TrasmTorrentTmp è come se fossero diverse, il loro contenuto non è uguale.

Qualche aiuto?

Grazie,
M

Ciao, ho risolto, ho risolto! :-D
Grazie a tutti ma soprattutto a Rylos che in PM mi ha dato un link che avevo già letto ma che mi sembrava non essere quello giusto.
E' il wiki di cifs.client :-)

Adesso ho tutto quello che mi serviva: transmission,extRoot e soprattutto NAS ethernet montato per scaricare direttamente lì.
Se posso essere di aiuto a qualcuno che si faccia vivi.
Se posso, volentieri!

Ciao,
M

[blackhole00]

Salve ragazzi, con le nuove versioni sia di ambrosa che di rylos ho sempre il problema degli errori in fase di decompressione del firmware al primo boot (OpenWrt funziona con Luci ma ho il wifi non funzionante):

[ 42.768000] SQUASHFS error: xz decompression failed, data probably corrupt
[ 42.772000] SQUASHFS error: squashfs_read_data failed to read block 0x1xxxx
......
procd: Instance odhcpd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash

1) Avrò corrotto la flash irrimediabilmente oppure i calibration data del WIFI?

2) C'è un modo da U-Boot per fare un check della flash ed eventualmente eliminare "settori" danneggiati?

3) Potreste aiutarmi a fare una pulizia della flash senza far danni? Oppure darmi un file da flashare dell'intera flash con qualche suggerimento sui comandi sw erase e sf write da impartire?

Premetto che rimettendo il firmware originale Tp-Link o la release 43085 di Rylos non ho nessun problema e tutto funziona alla perfezione.

Grazie mille

[matteo85]

Originariamente inviato da roguewave

ok, ci siamo, ed ora ho capito perchè a te saned occupava cosi poco.
Se si installa il sane-backend ti installa un sacco di pacchetti e anche il frontends.
compilando come mi hai detto tu io ho ottenuto i pacchetti e sono riuscito ad installarli.
Non riuscivo ad ottenere lo scanner semplicemente perchè, sul client, non mettevo

192.168.1.1 6566

nel file di ubuntu, /etc/sane.d/epkowa.conf

Io ho fatto diversamente, comunque ora ti funziona?

[ambrosa]

Originariamente inviato da blackhole00

Salve ragazzi, con le nuove versioni sia di ambrosa che di rylos ho sempre il problema degli errori in fase di decompressione del firmware al primo boot (OpenWrt funziona con Luci ma ho il wifi non funzionante):


1) Avrò corrotto la flash irrimediabilmente oppure i calibration data del WIFI?

2) C'è un modo da U-Boot per fare un check della flash ed eventualmente eliminare "settori" danneggiati?

3) Potreste aiutarmi a fare una pulizia della flash senza far danni? Oppure darmi un file da flashare dell'intera flash con qualche suggerimento sui comandi sw erase e sf write da impartire?

Premetto che rimettendo il firmware originale Tp-Link o la release 43085 di Rylos non ho nessun problema e tutto funziona alla perfezione.

Grazie mille

E' vero, potrebbe essere la flash corrotta. Ma se così fossi puoi buttare il router: se una o più celle di memoria della flash si fossero guastate ... non la si può certo riparare. Una sostituzione del chip sulla board è impensabile perchè il costo/beneficio è sfavorevole.
Inoltre usando il fw originale oppure un vecchio fw di Rylos, tutto sembra essere ok.

Quindi, 'speranzosi' , supponiamo che l'hardware sia a posto :-)
Cosa ci rimane ? Che da qualche parte il tuo flusso di lavoro:
1) scarico il firmare di Rylos/ambrosa da un sito remoto
2) lo carico nel router via tftp
abbia dei problemi.
Problemi forse intercorsi da poco tempo (perchè avevi già scaricato il fw originale e una vecchia versione di Rylos).

Il punto (1) lo puoi discernere scaricando la mia immagine in formato .ZIP : se nel tuo PC si decompatta normalmente senza errori, ecco che il download è OK.
Quindi ti rimarrebbe il punto (2) da indagare......

[massimo1995]

?_?

[blackhole00]

Originariamente inviato da ambrosa

Il punto (1) lo puoi discernere scaricando la mia immagine in formato .ZIP : se nel tuo PC si decompatta normalmente senza errori, ecco che il download è OK.
Quindi ti rimarrebbe il punto (2) da indagare......

Escluderei il punto 1...
Per quanto riguarda il punto 2 (area della flash danneggiata):
ricordando che il flash layout OpenWrt del w8970 è:

Creating 4 MTD partitions on "spi32766.0":
0x000000000000-0x000000020000 : "u-boot"
0x000000020000-0x0000007c0000 : "firmware"
0x00000015b7b5-0x0000007c0000 : "rootfs" 
mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
mtd: partition "rootfs" set to be root filesystem
mtdsplit: no squashfs found in "spi32766.0"
0x0000007c0000-0x0000007d0000 : "config"
0x0000007d0000-0x000000800000 : "boardconfig"

l'errore "SQUASHFS error: Unable to read page, block xxxxxx, size yyyyy" è sempre e solo su un blocco, nel caso del fw di ambrosa è "block 1971b2, size 112c8" mentre nell'ultimo fw di Rylos è differente. Quindi se ad es. il block 1971b2 corrisponde all'indirizzo 0x1971b2 sulla flash direi che ci troviamo nell'mtd "firmware" o "rootfs" e magari sulla routine di detect del chipset wireless...

Sto cercando qualche comando di check e fix della flash (anche online), usando i comandi U-Boot tra questi disponibili:

VR9 # help ? - alias for 'help'
base - print or set address offset
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
go - start application at address 'addr'
help - print command description/usage
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing address)
mtest - simple RAM read/write test
mw - memory write (fill)
nm - memory modify (constant address)
printenv - print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
setenv - set environment variables
sf - SPI flash sub-system
tftpboot - boot image via network using TFTP protocol
version - print monitor version

VR9 # printenv
bootcmd=run flash_flash
bootdelay=1 baudrate=115200
preboot=echo;echo Type \"run flash_nfs\" to mount root filesystem over NFS;echo
bootfile="uImage"
mem=63M
phym=64M
ipaddr=192.168.1.1
serverip=192.168.1.100
ethaddr=00:XX:XX:00:XX:XX
netdev=eth0 console=ttyS0
baudrate=115200
tftppath= loadaddr=0x80800000
rootpath=/mnt/full_fs rootfsmtd=/dev/mtdblock2
nfsargs= setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath)
ramargs=setenv bootargs root=/dev/ram rw
addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):on
addmisc=setenv bootargs $(bootargs) console=$(console),$(baudrate) ethaddr=$(ethaddr) phym=$(phym) mem=$(mem) panic=1 mtdparts=$(mtdparts) init=/etc/preinit vpe1_load_addr=0x82000000 vpe1_mem=1M ethwan=$(ethwan)
flash_nfs=run nfsargs addip addmisc;bootm $(kernel_addr)
net_nfs=tftp $(loadaddr) $(tftppath)$(bootfile);run nfsargs addip addmisc;bootm
net_flash=tftp $(loadaddr) $(tftppath)$(bootfile); run flashargs addip addmisc; bootm
net_ram=tftp $(loadaddr) $(tftppath)$(bootfile); run ramargs addip addmisc; bootm
u-boot=u-boot.lq
rootfs=rootfs.img
firmware=firmware.img
fullimage=fullimage.img
totalimage=totalimage.img
load=tftp $(loadaddr) $(u-boot)
update=protect off 1:0-2;era 1:0-2;cp.b $(loadaddr) B0000000 $(filesize)
flashargs=setenv bootargs root=$(rootfsmtd) rw rootfstype=squashfs
flash_flash=sf probe 3; bootm 0x80800000
update_uboot=tftp $(loadaddr) $(tftppath)$(u-boot); nand write.partial $(loadaddr) 4000 $(filesize);reset
update_kernel=tftpboot $(loadaddr) $(tftppath)$(bootfile);upgrade $(loadaddr) $(filesize)
update_rootfs=tftpboot $(loadaddr) $(tftppath)$(rootfs);upgrade $(loadaddr) $(filesize)
update_firmware=tftpboot $(loadaddr) $(tftppath)$(firmware);upgrade $(loadaddr) $(filesize)
update_fullimage=tftpboot $(loadaddr) $(tftppath)$(fullimage);upgrade $(loadaddr) $(filesize)
update_totalimage=tftpboot $(loadaddr) $(tftppath)$(totalimage);upgrade $(loadaddr) $(filesize)
stdin=serial
stdout=serial
stderr=serial
ethact=vr9 Switch

Environment size: 2040/4092 bytes

Avete suggerimenti/esperienze in tal senso?

Potete caricare un backup della vostra intera flash con l'ultimo firmware di Rylos/ambrosa? E suggerirmi i comandi per scriverla? Oppure un backup della mtd "firmware" così lo riscrivo con:
update_firmware=tftpboot $(loadaddr) $(tftppath)$(firmware);upgrade $(loadaddr) $(filesize)

Grazie

[ambrosa]

Originariamente inviato da blackhole00

Potete caricare un backup della vostra intera flash con l'ultimo firmware di Rylos/ambrosa? E suggerirmi i comandi per scriverla? Oppure un backup della mtd "firmware" così lo riscrivo con:
update_firmware=tftpboot $(loadaddr) $(tftppath)$(firmware);upgrade $(loadaddr) $(filesize)

Grazie

Posso fartelo io ma banalmente non so come fare.
Se mi dici quello che vuoi, te lo metto disponibile.