airos
Toto je starší verze dokumentu!
Obsah
Nanostation M5
- chtěl bych na nanostation nějak dostat n2n, abych ho mohl ovládat vzdáleně
- a) udělat vlastní build firmware
- b) upravit současný
- k prozkoumání
upload fw
root@ubuntu:tftp 192.168.1.20 tftp> bin tftp> trace tftp> put XS2.ar2316.v3.4-rc.4351.090504.2146.bin Sent 1965199 bytes in 35.2 seconds tftp> exit
Oprava loco M5
- popis závady:
- fungovalo, pak prý přestalo
- podezření na poškození bleskem
- neodpovídá ani na ping
- zkoušel jsem (a nepomohlo)
- několikrát reset
- reset2factory
- přepnout do tftp režimu (přes reset) a nahrát image XM.v5.6.9.29546.160819.1157.bin
- analýza přes USB TTL
- piny pro UART jsou tam menší, ale připojit to jde
- připojil jsem
- černý na GND,
- bílý (RX) na SOUT
- zelený (TX) na SIN
- klient CuteCom, 115200, 8-N-1
- v konzoli šlo vidět, že
- startuje U-Boot 1.1.4.2-s445 (Sep 6 2010 - 14:46:33)
- následně kernel,
- a všechno se zastavilo v init.. následoval auto restart po několika sekundách
... Getty ... Done. Startup_list ...Done. Free_cfg ... Done. Ready to go. ...running /sbin/init ATHDebug: 0x0 net.ath0.debug: 0x0 U-Boot 1.1.4.2-s445 (Sep 6 2010 - 14:46:33) Board: Ubiquiti Networks XM board (rev 1.0 e8a5) DRAM: 32 MB Flash: 8 MB Net: eth0, eth1 Hit any key to stop autoboot: 1
Nahrání image přes TFTP
- zkusil jsem nahrát img znovu
- přes UART jsem spustil
urescue - na Debian jsem dal
# tftp connect 192.168.1.20 binary put XM.v5.6.9.29546.160819.1157.bin
- na konzoli se zobrazilo
Firmware Version: XM.ar7240.v5.6.9.29546.160819.1157 Setting U-Boot environment variables Un-Protected 1 sectors Erasing Flash.... done Erased 1 sectors Writing to Flash... done Protected 1 sectors Will not overwrite u-boot partition! Skipped. Copying partition 'kernel' to flash memory: \0x09erasing range 0x9F050000..0x9F14FFFF: ................ done Erased 16 sectors \0x09writing to address 0x9f050000, length 0x00100000 ... Copying partition 'rootfs' to flash memory: \0x09erasing range 0x9F150000..0x9F74FFFF: ................................................................................................ done Erased 96 sectors \0x09writing to address 0x9f150000, length 0x00600000 ... Firmware update complete.
- proč tam je pořád starý U-Boot?
- podle OpenWRT stránky má být ve firmware 5.6.9 zavaděč U-Boot 1.1.4.2-s956, ale já tam mám furt ten starej
- pro 5.6.9 má být jiné rozdělení tabulek, ale moje rozložení je pořád
ar7240> mtdparts device nor0 <ar7240-nor0>, # parts = 6 #: name\0x09\0x09\0x09size\0x09\0x09offset\0x09\0x09mask_flags 0: u-boot \0x090x00040000\0x090x00000000\0x090 1: u-boot-env \0x090x00010000\0x090x00040000\0x090 2: kernel \0x090x00100000\0x090x00050000\0x090 3: rootfs \0x090x00660000\0x090x00150000\0x090 4: cfg \0x090x00040000\0x090x007b0000\0x090 5: EEPROM \0x090x00010000\0x090x007f0000\0x090
- že by za to mohla ta hláška o protected při nahrávání img?
- ANO!! pro přepsání u-boot se musí použít speciální příkaz
urescue -f -ezdroj - už tam mám poslední verzi
Aktuální img
ar7240> mtdparts device nor0 <ar7240-nor0>, # parts = 6 #: name size offset mask_flags 0: u-boot 0x00040000 0x00000000 0 1: u-boot-env 0x00010000 0x00040000 0 2: kernel 0x00100000 0x00050000 0 3: rootfs 0x00660000 0x00150000 0 4: cfg 0x00040000 0x007b0000 0 5: EEPROM 0x00010000 0x007f0000 0 active partition: nor0,0 - (u-boot) 0x00040000 @ 0x00000000 defaults: mtdids : nor0=ar7240-nor0 mtdparts: mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM)
ar7240> version U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50)
ar7240> imls Image at 9F050000: Image Name: MIPS Ubiquiti Linux-2.6.32.68 Created: 2016-08-19 8:58:26 UTC Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size: 1008812 Bytes = 985.2 kB Load Address: 80002000 Entry Point: 80002000 Verifying Checksum ... OK
ar7240> printenv bootdelay=1 baudrate=115200 ethaddr=00:15:6d:0d:00:00 filesize=73041f fileaddr=5 serverip=192.168.1.254 ethact=eth0 mtdparts=mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM) bootcmd=bootm 0x9f050000 bootargs=console=ttyS0,115200 root=31:03 rootfstype=squashfs init=/init ipaddr=192.168.1.20 stdin=serial stdout=serial stderr=serial ubntaddr=80200020 appinitdone=true mtdids=nor0=ar7240-nor0 partition=nor0,0 mtddevnum=0 mtddevname=u-boot
dmesg
- nechápu to, ale najednou se ta krabička rozhodla, že nastartuje :D
- předcházelo tomu několik restartů
- mám příležitost kouknout do dmesg
- RAM je tedy dostupná od 0x00000000 - 0x02000000?
[ 0.000000] Determined physical RAM map: [ 0.000000] memory: 02000000 @ 00000000 (usable)
- tohle už známe dobře
[ 0.073000] 6 cmdlinepart partitions found on MTD device ar7240-nor0 [ 0.073000] Creating 6 MTD partitions on "ar7240-nor0": [ 0.073000] 0x000000000000-0x000000040000 : "u-boot" [ 0.075000] 0x000000040000-0x000000050000 : "u-boot-env" [ 0.076000] 0x000000050000-0x000000150000 : "kernel" [ 0.077000] 0x000000150000-0x0000007b0000 : "rootfs" [ 0.079000] mtd: partition "rootfs" set to be root filesystem [ 0.079000] 0x0000007b0000-0x0000007f0000 : "cfg" [ 0.080000] 0x0000007f0000-0x000000800000 : "EEPROM"
memtest
- u-boot poskytuje přímo triviální memtest
mtest [start [end [pattern [iterations]]]]
- m5 loco má 32MB RAM, tedy 0x00000000 - 0x02000000
- při spuštění mtest se ale nesmí přepsat paměť u-boot/mtest na konci adresního rozsahu paměti
- u-boot v mtd tabulce velikost 0x00050000, test by měl tedy skončit před adresou 0x01FB0000
- zkoušel jsem najít první adresu, na které test paměti selže
ar7240> mtest 0x00000000 0x01FA9709 Pattern 00000000 Writing... <0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x10>@
- poslední adresa, na které test jde spustit je
ar7240> mtest 0x00000000 0x01FA9708
- ale.. když použiji pattern 0xffffffff, tak musím adresu ještě snížit
ar7240> mtest 0x00000000 0x01FA9704 0xffffffff
- test nejspíš zapíše vzorek a pak ho zkusí přečíst
- pokud je přečtení ok, tak nejspíš zkusí invertovanou hodnotu a následně přičte jedničku
ar7240> mtest 0x00000000 0x01FA9708 Pattern 00000000 Writing... <0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08>Reading... Pattern FFFFFFFF Writing... <0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08><0x08>Reading... Pattern 00000001 Writing...
- parametrem pattern se nastavuje, od jakého vzorku začít
- parametr počet iterací se mi nepodařilo nastavit. čtvrtý argument mi to vůbec nebere. možná stará verze u-boot?
- paměť mi přijde ok, ale použitou hranicí si nejsem jistý.. co když je chyba zrovna tam?
Boot po síti z TFTP
- loco je založeno na ar7240 (https://wiki.openwrt.org/toh/ubiquiti/nanostationm5)
- podle spouštění img U-BOOT je třeba zjístit začátek memory adres
- mtdparts začíná na adrese 0x9f000000, má velikost 0x800000 (8MB), takže je namapován 0x9f000000-0x9f800000
- RAM má 32MB, tekže rozsah offsetu bude 0x00000000 - 0x02000000,
- kam je ale namapován? podle testu memtest asi na začátek adresního rozsahu
- a kolik si vzal u-boot? prý se dává na konec, tedy na poslední adresu bez velikosti u-boot
- offset 0x9f000000 je 2544 MB, takže RAM může být klidně před ním?
-
- CFG_SDRAM_BASE 0x80000000 - tady asi začíná fyzicky paměť
- tftpboot 0x80000000 XM.v5.6.9.29546.160819.1157.bin
- a nic.. bad magic :/
- podle mě ten bin obsahuje u-boot script, který provádí teprve to rozbalení atd..
- tftpboot 5 XM.v5.6.9.29546.160819.1157.bin
- nahraje na adresu 5, kterou lze vypsat přes
- md.b 0 128
Analýza img
- co ten fw img vlastně všechno obsahuje?
file XM.v5.6.9.29546.160819.1157.bin XM.v5.6.9.29546.160819.1157.bin: HIT archive data
- HIT archive je asi UBI img
- http://free-electrons.com/doc/training/embedded-linux/ zde je super pdf, komplexně vše o embedded
Co s tím tedy je?
- rozbitá RAM?
- nápad:
- co ten test paměti v u-boot?
- rozbil se flash?
- img jsem zkoušel nahrát několikrát a chovalo se to divně
- občas to hodilo „Bad Data CRC“ a kernel se vůbec nenačetl
- občas to hodilo chyby až při čtení kernelu/rootfs
- občas to nehodilo žádnou chybu, ale zaseklo se
- nápad:
- boot img po síti? tam se nepoužije flash..
airos.1478444078.txt.gz · Poslední úprava: (upraveno mimo DokuWiki)