RAVPower WD-03, Add LZMA Loader

Similar to HooToo TM-05, Add LZMA Loader, but different devices - so creating this to avoid mixing the two.

And this one is without serial port ... for now at least :laughing:


It's going to be very difficult no matter what method is used if you don't use serial

Maybe contact whoever added support for this thing?


Also the SOC is not exactly the same? mt7620a

Maybe datasheets can tell you something?

Agree with you! I did ask the vendor before - they said they couldn't even find the source code for U-Boot :stuck_out_tongue_winking_eye:.

I'm going to re-load the image I have back on the HooToo, just to make sure it's correct / working. The RAVPower images were running on the HooToo, not sure why they wouldn't work the other way around!

Please try (and wait :rofl: ) that uImage-lzma.bin what I compiled for TM-05!

If it helps I could change the CONFIG_STEP back to 0x1000 to speed things up! :grinning:

You could also ask the vendor for a proper disassemble manual, as the OpenWrt Wiki says its almost a one way thing! :roll_eyes:

Will do! TFTP installed, powered on => off to the gym, will leave it for a couple hours this way :laughing:

What the heck, I'll ask!

Well, 3 hours later - still no ethernet interface up and running :frowning:. I admit though, when it outputs to the console (even though it's not connected), I found it to be VERY slow. Perhaps still count by 0x1, but only output to the console (for example) if the offset is % 0x10000 (modulo)?


You could apply the patch to OpenWrt master, revert the CONFIG_STEP, and skip the first two partitions with LOADER_FLASH_OFFS, delete the loader bin, and rebuild!

I could do the above for you later tonight!

Sorry? What console are you talking about?
You have some kind of console access to the Ravpower device?

Thanks! FYI, I tried my build here - checked it on the HooToo (serial port), and it is searching. So believeing it is also on the RAVPower device. Very odd.

No, sorry for confusing you! I meant before, when I saw it on the HooToo ... it just slows the search down a lot to write to the serial port. And without a serial port, remove that (somewhat / completely?), as it's not seen anyways ... LOL!

Trying here now to go back to the stock v19.07 build - as it seems to work. Wondering if there is a way to find the flash address from there. Hmm.

For example, this is in the logs,

[    0.541822] spi spi0.0: force spi mode3
[    0.548293] m25p80 spi0.0: gd25q64 (8192 Kbytes)
[    0.553053] 4 fixed-partitions partitions found on MTD device spi0.0

So then (to Linux) ... tell me where this is at! :stuck_out_tongue_winking_eye:

Here is another round:

  • it has the original step size: 0x1000
  • it skips the first three partition and start looking for magic at 0x50000

Please test it on HooToo first, and see if it's finds the OKLI magic in time!

Is it possible that the Ravpower might have more u-boot commands than the HooToo?

It's possible, but I'm guessing they didn't really go through the effort to optimize :laughing:

Thanks! OK, ran it on the HooToo ... took ~ 10-15 min, but it found it. It started to boot, but then rebooted - I can't say why, as it was not long after it switched serial port speed, so I just had garbage on the serial port screen (FYI, you may want to change the .dts file, to 57600 - the same as u-boot).

Running it on the RAVPower now, will give it a while (also remembering that the flash speed is set to 10 MHz on the RAVPower, but I have it at 40 MHz on the HooToo ... and I think it can go to 80 MHz).

Fingers crossed!

FYI, approaching 40 min - still no joy (Ethernet down, so can't be 100% sure of course. A couple thoughts, things to try - I can give these a go here, just want to get your thoughts on the sanity of them :laughing:,

  1. In case it's just ethernet, perhaps add a wireless config to the build (no security for now), another way to see if it's up?
  2. Install the stock build (v19.07, that does work), try to use spi-tools to find the flash?
  3. Build on the master, with small_flash, no loader for now ... just to make sure that there isn't something else in master that is breaking this, and it's not the loader at all?



OK, tried this one - boots and works (small_flash, no loader). At least it rules out that.

Hmmm, no /dev/spi0.0, so can't use spi-tools. Need to figure that out. But I do see,

root@OpenWrt:~# cat /proc/device-tree/palmbus@10000000/spi@b00/status

Will keep digging - tomorrow :laughing:

Take a look at dmesg to see how it identified the flash and partitions

Agreed! I have looked at that before, and it doesn't really tell me, but perhaps you get more out of this than I do?

[    0.539180] spi spi0.0: force spi mode3
[    0.545685] m25p80 spi0.0: gd25q64 (8192 Kbytes)
[    0.550506] 4 fixed-partitions partitions found on MTD device spi0.0
[    0.556987] Creating 4 MTD partitions on "spi0.0":
[    0.561905] 0x000000000000-0x000000030000 : "u-boot"
[    0.567915] 0x000000030000-0x000000040000 : "u-boot-env"
[    0.574299] 0x000000040000-0x000000050000 : "factory"
[    0.580412] 0x000000050000-0x000000800000 : "firmware"
[    0.589636] 2 uimage-fw partitions found on MTD device firmware
[    0.595690] Creating 2 MTD partitions on "firmware":
[    0.600813] 0x000000000000-0x000000146c57 : "kernel"
[    0.606815] 0x000000146c57-0x0000007b0000 : "rootfs"
[    0.612816] mtd: device 5 (rootfs) set to be root filesystem
[    0.620257] 1 squashfs-split partitions found on MTD device rootfs
[    0.626589] 0x0000003aa000-0x0000007b0000 : "rootfs_data"



The partition table is in sync with the OpenWrt device page.

I am thinking about changing halt() to reboot() in loader.c to differentiate the OKLI searching state from the error states.

@arrmo, could you show me, how the HooToo OEM u-boot restarts the device? grep "must RESET board to recover" for example!

I think you can ignore the "must RESET board to recover", that was me having addressing issues :laughing:. Had the loader overwriting itself.

But that said - no issues with the reboot(), but not sure how to detect it. It really would be nice to figure the console output to ethernet (i.e. netconsole), but not sure loader supports that, does it? I did check, and the HW is up, but it may not include the needed UDP / IP stack.


LEDs aren't doing anything at power-on?

Yes, they are - sorry if I confused you. I tried 2 different builds ... non-loader and loader. The LED's are the same for both ... flash of green, then stays blue. Not sure that's really indicating anything, is it?

I also tried 2 builds here, starting from 0xba000000, step of 1 => works on the HooToo, takes a couple minutes but gets there. No joy after ~ 10 min on the RAVPower (very odd!). So now running starting at 0xbc000000. Will let you know.

Really is painful without serial - let's see if the vendor replies, but I'm not real optimistic on that. Seems very odd to me that I can take RAVPower builds to the HooToo, but not the reverse :frowning_face:.