Bari Wiki

Uživatelské nástroje

Nástroje pro tento web

Historie: • airos
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ý
  • 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

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 -e zdroj
  • 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?
  • 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
  • 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?

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..
airos.1478447882.txt.gz · Poslední úprava: (upraveno mimo DokuWiki)
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki