I wonder if anyone has done this successfully. I have an mr18 WAP but the firmware on it was too recent to do the flashing via serial so I'm attempting the JTAG route.
I'm following the guide https://openwrt.org/toh/meraki/mr18/jtag but seem to be stumbling at the point of disabling the hardware watchdog. The JTAG console comes back with a "target not halted" message, despite halting the boot sequence early on.
I've followed the guide, created the config files, edited them to match the Raspberry Pi 4 clock frequency, connected up the UART and JTAG pins, etc.
Here's what I get with openocd:
$ sudo openocd -f raspberrypi-native.cfg -f mr18.cfg -c "init; halt"
Open On-Chip Debugger 0.10.0+dev-00114-g41bcbc67d-dirty (2021-01-18-16:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
BCM2835 GPIO config: trst = 7
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Warn : Transport "jtag" was already selected
DEPRECATED! use 'adapter speed' not 'adapter_khz'
adapter speed: 1000 kHz
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 1000 kHz
Info : JTAG tap: ar9344.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
Info : starting gdb server for ar9344.cpu on 3333
Info : Listening on port 3333 for gdb connections
Error: isa info not available, failed to read cp0 config register: 0
target halted in MIPS32 mode due to debug-request, pc: 0x00000000
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'telnet' connection on tcp/4444
I can then telnet to the device and connect, but issuing the mww command fails:
$ telnet localhost 4444
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> mww 0xb8060008 0x0
target not halted
Looks like the halt part of the -c "init; halt" command has not been picked up / recognised. I think you can just type halt in either your openocd or telnet session and then try to disable the watchdog again.
I've flashed 2 MR18s a few weeks ago using an older raspberry pi. The process works but I needed to run it quite a few times before it was successful. It seems that you need to interrupt the boot process very early which can be a bit challenging. I found that it helped by plugging the 12v power supply into a wall socket with a switch such that it is easy to start the MR18 with one hand and immediately issue the command in the terminal window with the other hand.
Thanks. I'll try again.
I already tried several times at different points including very early on.
On one occasion, I did get further but then it failed to load the firmware. I'll see if I can get that far and post the exact error message.
Is that already too far? At this point, I still get the target not halted message.
Do I need to interrupt it during the Nand flash init part and before the Meraki Atheros LinuxLoader section?
Made some progress, I guess.
I've been able to interrupt and disable the watchdog. This was successful at this point of the boot:
__________________sri____________________
944x BootROM Ver. (asic) 1.0 [Nov 8 2011 13:42:57]
_________________________________________
find_hif: bootstrap = 0x31c58
Nand Flash init
hdr: [0xbd000400 : 0xbd000400 : 0x6fb4 : 0xe5c86b84]
nand_load_fw: read 13 pages
nand_load_fw: 0x10000 0x800 0xbd000bf0
nand_load_fw: 0x20000 0x800 0xbd0013f0
nand_load_fw: 0x30000 0x800 0xbd001bf0
nand_load_fw: 0x40000 0x800 0xbd0023f0
nand_load_fw: 0x50000 0x800 0xbd002bf0
nand_load_fw: 0x60000 0x800 0xbd0033f0
nand_load_fw: 0x70000 0x800 0xbd003bf0
nand_load_fw: 0x80000 0x800 0xbd0043f0
nand_load_fw: 0x90000 0x800 0xbd004bf0
nand_load_fw: 0xa0000 0x800 0xbd0053f0
nand_load_fw: 0xb0000 0x800 0xbd005bf0
nand_load_fw: 0xc0000 0x800 0xbd0063f0
nand_load_fw: 0xd0000 0x800 0xbd006bf0
f/w 0 read complete, jumping to 0xbd000400
Meraki Atheros LinuxLoader MR18 built Jan 31 2014 15:53:22
qca955x_init_ddr ok
test_memory ok
D-cache size: 64K
I-cache size: 32K
init_dram_uncached ok
init_icache ok
init_dcache ok
enable_caches ok
test_memory ok
nand_flash_init ok
loading fw at 256
hdr: [0x8e73ed8a : 0x400 : 0x15ccd8 ]
part1: Copying image to memory ... .........B..
done.
part1: Checking sha1 (from 0x80060000 length 1428696) ... match
part1: sha1 calculated: dd59e7a34e25b59bc181277e16c01ecbc96dd64b
starting stage2
decompressing embedded kernel image 0x81a024f0(0x15a7c8)
got osize 4090c4
.. <== got this far when the halt command was issued via openocd
Now I'm at the stage of being unable to load the image...
telnet localhost 4444
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> mww 0xb8060008 0x0
> load_image openwrt-ar71xx-nand-mr18-initramfs-kernel.bin 0x8005FC00
No working area available
Falling back to non-bulk write
>
I've flashed 2 more MR18s this evening following the instructions. The process is not very reliable and I had to restart the MR18 and retry maybe 10 - 20 times before I managed to flash it successfully. So the only advice I can give is just to keep trying until it works.
No I've not seen that error. That is an odd one since it should be defined in the mr18.cfg file. One thing to check is to make sure that copying the text from the webpage has not introduced any additional end of line characters especially if you use windows. That is a common issue when moving files from windows to linux.
I've used a old raspberry pi 1B so I know that one works but it does take quite a few tries.
Right, some progress I guess.
I've now tried with a RPi 3B+ instead of a 4. The results are better in that I can systematically get the mww interrupt recognised.
But I now systematically fail on the load_image with the same "No working area available
Falling back to non-bulk write" message.
I'm actually working on the Pi and have been careful in copying / pasting the config files. I will check again.
I'm wondering if the length of cable could be an issue. My hookup to the JTAG is effectively around 50cm so maybe timing or voltage drop is an issue. I will see if I can try with a shorter cable.
I'll keep on persevering, but since I can now reliably get the interrupt accepted but seem to always fail at the next hurdle, I might have something wrong.
I'm wondering if in all my attempts, I've somehow bricked the mr18 - I do get a load of error messages on the serial connection if I let it boot up normally into the Cisco firmware. But I would have hoped that interrupting the boot process at such an early stage and at such a low level would mean that you can still fix / flash.
Just to update: I can now get it to the stage of loading the firmware (I've switched to a RPi 3B+), but it fails at the point of trying to upload the kernel file with the message:
Debug: 278 11974 mips32_pracc.c:197 mips32_pracc_exec(): unexpected write at address ff20025c
Error: 279 11974 mips_m4k.c:1230 mips_m4k_bulk_write_memory(): No working area available
Warn : 280 11974 mips_m4k.c:1099 mips_m4k_write_memory(): Falling back to non-bulk write
I'm probably going to give up as debugging this is beyond me.
Is the error at the same address every time? Maybe you could try to move the working area to a slightly different location to see if you can avoid it? Just an easy thing to try. I don't know enough about jtag & hardware to understand why it doesn't work for you.
I figured it was the grinding in my case. Try to connect the Raspberry Pi's grinding directly to one of the JTAG grounds instead of just relying on the UART ground.
@konus , no, it's different! I noticed this in my numerous attempts, and not sure why it's different.
Debug: 260 16967 command.c:146 script_debug(): command - load_image openwrt-ar71xx-nand-mr18-initramfs-kernel.bin 0x8005FC00
Debug: 262 16968 configuration.c:97 find_file(): found openwrt-ar71xx-nand-mr18-initramfs-kernel.bin
Debug: 263 16968 configuration.c:97 find_file(): found openwrt-ar71xx-nand-mr18-initramfs-kernel.bin
Debug: 264 16995 target.c:2199 target_write_buffer(): writing buffer of 6353004 byte at 0x8005fc00
Debug: 265 16995 mips_m4k.c:1088 mips_m4k_write_memory(): address: 0x8005fc00, size: 0x00000004, count: 0x00183c1b
Debug: 266 16995 mips_m4k.c:1215 mips_m4k_bulk_write_memory(): address: 0x8005fc00, count: 0x00183c1b
Debug: 267 16995 target.c:1840 target_alloc_working_area_try(): MMU disabled, using physical address for working memory 0x81000000
Debug: 268 16995 target.c:1894 target_alloc_working_area_try(): allocated new working area of 128 bytes at address 0x81000000
Debug: 269 16995 mips_m4k.c:1029 mips_m4k_read_memory(): address: 0x81000000, size: 0x00000004, count: 0x00000020
Debug: 270 16996 mips32_pracc.c:227 mips32_pracc_exec(): reading at unexpected address ff200200, expected ff200208
Error: 271 16996 mips_m4k.c:1230 mips_m4k_bulk_write_memory(): No working area available
Warn : 272 16997 mips_m4k.c:1099 mips_m4k_write_memory(): Falling back to non-bulk write
Debug: 273 17049 mips32_pracc.c:227 mips32_pracc_exec(): reading at unexpected address ff200208, expected ff200200
Debug: 274 17051 mips32_pracc.c:186 mips32_pracc_exec(): restarting code
Debug: 275 17055 mips32_pracc.c:227 mips32_pracc_exec(): reading at unexpected address ff600214, expected ff200214
Debug: 276 17060 command.c:627 run_command(): Command 'load_image' failed with error code -107
Then repeat, and I get different addresses:
Debug: 398 140554 command.c:146 script_debug(): command - load_image openwrt-ar71xx-nand-mr18-initramfs-kernel.bin 0x8005FC00
Debug: 400 140554 configuration.c:97 find_file(): found openwrt-ar71xx-nand-mr18-initramfs-kernel.bin
Debug: 401 140555 configuration.c:97 find_file(): found openwrt-ar71xx-nand-mr18-initramfs-kernel.bin
Debug: 402 140583 target.c:2199 target_write_buffer(): writing buffer of 6353004 byte at 0x8005fc00
Debug: 403 140583 mips_m4k.c:1088 mips_m4k_write_memory(): address: 0x8005fc00, size: 0x00000004, count: 0x00183c1b
Debug: 404 140583 mips_m4k.c:1215 mips_m4k_bulk_write_memory(): address: 0x8005fc00, count: 0x00183c1b
Debug: 405 140583 target.c:1894 target_alloc_working_area_try(): allocated new working area of 128 bytes at address 0x81000000
Debug: 406 140583 mips_m4k.c:1029 mips_m4k_read_memory(): address: 0x81000000, size: 0x00000004, count: 0x00000020
Debug: 407 140585 mips32_pracc.c:227 mips32_pracc_exec(): reading at unexpected address ff600210, expected ff200210
Error: 408 140585 mips_m4k.c:1230 mips_m4k_bulk_write_memory(): No working area available
Warn : 409 140585 mips_m4k.c:1099 mips_m4k_write_memory(): Falling back to non-bulk write
@thomasthep thanks. I'll see if I can do that. A little tricky as I've soldered a right-angled connector so cannot get access easily to the other row of points where the ground connections are.
Hmm I'm wondering if this isn't a clue:
Debug: 291 9161 target.c:1894 target_alloc_working_area_try(): allocated new working area of 128 bytes at address 0x81000000
128 bytes? If this is the "working area", then 128 bytes isn't enough to upload a 6MB image!
@tfboy The working area thing is just a workaround to be able to fast write without addressing the space as the start address.
The errors regarding unexpected address all look like bit flips which is another hint that it could be a connection fault. Since you soldered the other connectors, this is probably most likely just a grounding issue.
I printed a small clamp with insertable pogo pins as I didn't want to have to remove the board and do any soldering for 10+ devices. This has other up and down sides.
I've checked the grounding and I think it's good. When I disconnect or make it flaky, there's loads of garbage that comes out of the serial. I've tried also connecting to the ground pins of the JTAG (it's common with the ground of the UART) and it makes no difference.
Ground is required for differential, no doubt. Weird that using JTAG ground didn't make a difference. Electrical signals are weird, timing, capacitance, differential, interference, etc. could all be a cause. In most cases they should share a ground, but not always necessarily true. I've seen circuitry where it has been isolated from the rest of the board, for good reason.
Keep the cables as short as possible, bundle them together, make sure there are no contacts and use connections available local to the connector. JTAG ground should belong to JTAG and UART to UART.
If all fails, maybe get a professional JTAG device. Black Magic Probe is pretty awesome.
Btw, you're still getting bitflips. There's a difference of 1 bit.
Are you also using the same outlet between the pi and meraki? Is the pi getting enough power?