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ý
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
...
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
# tftp
connect 192.168.1.20
binary
put XM.v5.6.9.29546.160819.1157.bin
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.
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
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)
[ 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
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>@
ar7240> mtest 0x00000000 0x01FA9708
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
-
-
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,
offset 0x9f000000 je 2544
MB, takže RAM může být klidně před ním?
-
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..
Analýza img
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?
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
Co s tím tedy je?
rozbitá RAM?
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: