====== 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í
* http://www.authpuppy.org/doc/Compile_Airos
* https://community.ubnt.com/t5/airOS-Software-Configuration/Done-VPN-PPTP-Client-on-AirOS/td-p/446983
* BACHA BACHA... AirOS už neposkytuje SDK, pouze GPL archív s modifikacemi GPL kódu!!
* udělat si vlastní modifikaci AirOS je tedy složitější něž dříve
===== upload fw =====
* https://help.ubnt.com/hc/en-us/articles/204911324-airMAX-How-to-reset-your-device-with-TFTP-firmware-recovery
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 [[https://wiki.openwrt.org/toh/ubiquiti/airmaxm|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 , # 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 -e'' [[https://community.ubnt.com/t5/airOS-SDK-Custom-Development/AirMAX-Device-Firmware-Recovery-Procedure/td-p/1499583|zdroj]]
* už tam mám poslední verzi
===== Aktuální img =====
ar7240> mtdparts
device 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 [[http://wiki.emacinc.com/wiki/Loading_Images_with_U-Boot|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? [[http://unix.stackexchange.com/questions/39777/how-can-i-tell-what-memory-ram-address-range-is-being-used-by-uboot|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?
* https://github.com/unwireddevices/u-boot/blob/master/u-boot/include/configs/ar7240.h
* 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
* [[http://www.denx.de/wiki/view/DULG/UBootCmdGroupFlash|man na U-BOOT]]
* [[http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/|TFTPd debian]]
* [[http://ftp1.digi.com/support/documentation/90000852_K.pdf|U-BOOT manual]]
* [[http://stackoverflow.com/questions/35336940/understand-u-boot-memory-footprint|mapování paměti u-boot]]
===== 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://www.programering.com/a/MjM5gDNwATk.html
* http://free-electrons.com/blog/creating-flashing-ubi-ubifs-images/
* zkusíme to po staru přes ghex
* pokud tam jsou nějaké u-boot skripty, musí to jít najít přes stringy!!
* dal jsem vyhledat "Setting U-Boot environment" a hele co to máme na offsetu 0003203A :D
* vypadá to ale jako stringy nějaké binárky než skript. Že by tak vypadal ten U-Boot script image?
* http://binwalk.org/
binwalk /home/djbuldog/Downloads/XM.v5.6.9.29546.160819.1157.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Ubiquiti firmware header, header size: 264 bytes, ~CRC32: 0x8DAC2BC9, version: "XM.ar7240.v5.6.9.29546.160819.1157"
260 0x104 Ubiquiti partition header, header size: 56 bytes, name: "PARTu-boot", base address: 0x00000000, data size: 0 bytes
140580 0x22524 U-Boot version string, "U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50)"
140772 0x225E4 CRC32 polynomial table, big endian
161032 0x27508 Ubiquiti firmware header, header size: 264 bytes, ~CRC32: 0x65746831, version: " APP Magic mismatch, addr=%x, magic=%x "
203044 0x31924 CRC32 polynomial table, big endian
209568 0x332A0 Ubiquiti partition header, header size: 56 bytes, name: "PARTkernel", base address: 0x00000001, data size: -2147475456 bytes
209632 0x332E0 uImage header, header size: 64 bytes, header CRC: 0x4DF2A4D3, created: 2016-08-19 08:58:26, image size: 1008812 bytes, Data Address: 0x80002000, Entry Point: 0x80002000, data CRC: 0x9788B2CA, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Ubiquiti Linux-2.6.32.68"
209696 0x33320 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2931300 bytes
1218508 0x1297CC Ubiquiti partition header, header size: 56 bytes, name: "PARTrootfs", base address: 0x00000002, data size: 0 bytes
1218572 0x12980C Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 6077311 bytes, 1372 inodes, blocksize: 131072 bytes, created: 2016-08-19 08:58:28
7510092 0x72984C gzip compressed data, from Unix, last modified: 2016-08-19 08:56:51
* https://sites.google.com/site/shihsung/rc32xxx-soc/analyze-firmware
* 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?
* podle memtest to moc nevypadá
* když mi to pak naběhlo, tak to žádné segfault neházelo
* 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
* občas mi to dokonce naběhlo :)
* nápad:
* boot img po síti? tam se nepoužije flash..