RAVPower WD-03, Add LZMA Loader

Flash Layout is:

dev:    size   ​erasesize ​ name
mtd0: 00800000 00010000 "​ALL"​
mtd1: 00030000 00010000 "​Bootloader"​
mtd2: 00010000 00010000 "​Config"​
mtd3: 00010000 00010000 "​Factory"​
mtd4: 00180000 00010000 "​Kernel_RootFS"​
mtd5: 00010000 00010000 "​params"​
mtd6: 00010000 00010000 "​user_backup"​
mtd7: 00010000 00010000 "​user"​
mtd8: 00600000 00010000 "​Rootfs"​

Config and Factory is lost, so your calibration data and MAC address is gone.
You had to find the device's MAC address on it's box or on itself.

man dd will help you! :slight_smile:

The easiest way is to replace the bootloader in the HooToo's ALL.bin and program it to RavPower, IMHO.

Funny, again we're thinking alike! Did that ... but no joy. Wondering now, do I need to "zero out" (0xFF) the unused portion of that 192kB. Hmmm. Will try that, as dd built me the file, flashed it, but still won't boot (i.e. no serial output at all).

Bootloader can be flashed by itself...and at the very least you would get serial output telling you why boot has stopped

It's possible that even though the two boards are almost the same that the bootloaders don't match

Agreed! Struggling to get the layout file working (with flashrom), so I can do just what you say - program only the bootloader.


Pulling my hair out again ... :rofl:. OK, flashrom is a bit of a PITA - even to program a section, you have to have a full sized file. NP, here is what I did - yell if you see anything wrong!

dd if=/dev/zero bs=8M count=1 | tr "\000" "\377" > u-boot.full.bin
hexdump -C u-boot.full.bin
   => yep, file is 8M, all 0xFF
dd if=u-boot.bin of=u-boot.full.bin conv=notrunc
   => bootloader at the start of the file
flashrom -l rom.layout -i u-boot -w u-boot.full.bin -p linux_spi:dev=/dev/spidev0.0,spispeed=2000

So this has only the bootloader, but won't boot ... no serial, no LED's (normal sequence I mean), no ethernet. Wondering if it needs the u-boot-env or config perhaps?

So tried replacing u-boot (only) in the HooToo image => still no joy (and no serial, no LED's like expected, no ethernet). Dang it! And no luck finding a flash image for the RAVPower (like I have for the HooToo).


@badzz, could you help out @arrmo with a full backup of WD-03?

1 Like

Yes, would appreciate if someone has the flash / backup file. Thanks!!!

FYI, I did email the vendor, but I know how that goes :rofl:

@arrmo I don't want to be "that guy" but I am anyway

do a full backup of flash for every device you work on. It can be done through LuCI on an initramfs.bin. I've done it over serial and TFTP on OEM image too.

BTW if you hate flashrom yet, feel free to install Adafruit Blinka and try my scripts. It should be an easy edit to get it working on RPi


LMAO! Too funny. And no worries, I take it the right way - 100% agree with you, very valid comments ... and lesson learned :stuck_out_tongue_winking_eye: . Thanks!

Sorry, I was thinking this was for Arduino - I misunderstood your earlier comment. Will check it out!

OK, the RAVPower is back up and running ... sort of :wink:. I stumbled on to it, but it seems that during that "large" erase, something got broken. If I leave the flash programmer connected, then it will boot. It seems to me like the power supply went, and that gets provided by the flash programmer. So a bit of a fragile setup, but I will try to continue now. And FYI, the bootloader does seem to have a (subtle?) difference ... the address in the rows below is different in the two cases,

Board: Ralink APSoC DRAM:  32 MB
relocate_code Pointer at: 81fac000


Well, I can sort of get back up ... booting from initramfs, it comes up - but no mtd partitions. Is there a way to restore them? Or DOA?


If you have some backup then you could flash it! Bootloader is there. How about Config and Factory OEM partitions? In case you don't have a WD-03 backup, then you could try from your HooToo TM-05 backup!

Did you try flashing kernel.bin and rootfs.bin through TFTP recovery from your PR?

Yep, exactly what I did! HooToo flash (from the vendor), and then replaced the bootloader. No joy, lots of errors (trying to boot OEM), like the following,

[   19.576000] SQUASHFS error: Unable to read data cache entry [1c6b18]
[   19.588000] SQUASHFS error: Unable to read page, block 1c6b18, size 9ae8
[   19.604000] SQUASHFS error: Unable to read data cache entry [1c6b18]
[   19.616000] SQUASHFS error: Unable to read page, block 1c6b18, size 9ae8

Yep, that was my next step - we're on the same page! LOL. But getting,

[    0.736420] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    0.751398] Please append a correct "root=" boot option; here are the available partitions:
[    0.768050] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    0.785388] Rebooting in 1 seconds..

And if I boot from initramfs, /proc/mtd is completely empty :frowning_face:


OK, I was wrong - it's the WP pin that I have to pull high, then the unit will boot. Huh?!?! Still messed up flash overall though.

Does the serial log from the bootloader looks good?

Does the md - memory display show the flash's content?

For reference, the flash layout is:

[    0.563276] spi spi0.0: force spi mode3
[    0.573466] m25p80 spi0.0: gd25q64 (8192 Kbytes)
[    0.582778] 8 fixed-partitions partitions found on MTD device spi0.0
[    0.595445] Creating 8 MTD partitions on "spi0.0":
[    0.605006] 0x000000000000-0x000000030000 : "u-boot"
[    0.615867] 0x000000030000-0x000000040000 : "config"
[    0.626662] 0x000000040000-0x000000050000 : "factory"
[    0.637672] 0x000000050000-0x000000051000 : "loader"
[    0.648480] 0x000000051000-0x0000001d0000 : "firmware2"
[    0.659820] 0x0000001d0000-0x0000001e0000 : "u-boot-env"
[    0.671309] 0x0000001e0000-0x000000200000 : "firmware3"
[    0.682640] 0x000000200000-0x000000800000 : "firmware1"
[    0.839575] Concatenating MTD devices:
[    0.847102] (0): "firmware1"
[    0.852826] (1): "firmware2"
[    0.858562] (2): "firmware3"
[    0.864298] into device "virtual_flash"
[    0.871966] 1 fixed-partitions partitions found on MTD device virtual_flash
[    0.885852] Creating 1 MTD partitions on "virtual_flash":
[    0.896636] 0x000000000000-0x00000079f000 : "firmware"
[    0.909574] 2 okli-fw partitions found on MTD device firmware
[    0.921088] Creating 2 MTD partitions on "firmware":
[    0.930996] 0x000000000000-0x00000019910c : "kernel"
[    0.941817] 0x00000019910c-0x00000079f000 : "rootfs"
[    0.952600] mtd: device 10 (rootfs) set to be root filesystem
[    0.965712] 1 squashfs-split partitions found on MTD device rootfs
[    0.978098] 0x00000043b000-0x00000079f000 : "rootfs_data"
[    0.997737] VFS: Mounted root (squashfs filesystem) readonly on device 31:10.

For the concatenated firmware address you have to calculate the real address.
For example, the rootfs starts at 0x00000019910c inside firmware which starts at 0x000000200000 on the flash => are there anything interesting at 0x00000039910c on the flash?

Nope, not exactly - I get this instead :frowning_face:

[    5.547840] spi spi0.0: force spi mode3
[    5.556282] m25p80 spi0.0: unrecognized JEDEC id bytes: 90, 40, 3f
[    5.568683] m25p80: probe of spi0.0 failed with error -2

Definitely some flash and power supply issues. I do see that powering off during erase (like I did) can have "undesirable side effects". Think I found that. Will keep trying though!

1 Like

Does your (or @mpratt14's) flash programming tool detect the chip?
And what is it's JEDEC id bytes? OpenWrt reads it correctly?

If you are unable to set back the JEDEC id bytes to c8, 40, 17, then you could add a temporary patch like target/linux/ramips/patches-*/302-spi-nor-add-gd25q512.patch to add a gd25q64-arrmo named flash with the current id (0x90403f)! :smiley:
To create the patch above, you could try the following:

  • build the image first
  • check build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/linux*/drivers/mtd/spi-nor/spi-nor.c for all the patches got applied
  • copy spi-nor.c to spi-nor-arrmo.c
  • add the new lines for chip support in your copy
  • diff -U8 spi-nor.c spi-nor-arrmo.c
  • create your 999-spi-nor-add-gd25q64-arrmo.patch file in target/linux/ramips/patches-*/ directories
  • rebuild

Appreciate the pointers! The issue was (is) hardware related - seems the on board 3V supply is dead. Could be due to a lot of different things - board in and out of the case (pried open, had to fully remove the board to get the flash clip on - no room in the case, bad design! :rofl:), open board with wires everywhere, etc. But when I provide an external 3V supply, to the board - I seem to be back up and running ... and booting OpenWrt!

Let me see if I can get back to the changes now - fighting with git, and harmonizing / combining the dts files.

And a big :+1: to @badzz - getting me the stock WD03 files really helped. Appreciate it!

1 Like

OK, code updated, common dtsi (almost the entire file!), built and tested on RAVPower WD-03, and also checked on the HooToo (given dts changes). All seems to be working. Commit here,

I do need to check the MAC addresses yet, that's the only non-common thing left I think. Anything else you can think of to do on this?