RAVPower WD-03, Add LZMA Loader

xabolcs · July 21, 2020, 6:17am

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?

arrmo · July 21, 2020, 11:25am

Nope, not exactly - I get this instead

[    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!

xabolcs · July 21, 2020, 12:10pm

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)!
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

arrmo · July 21, 2020, 4:32pm

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! ), 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.

arrmo · July 21, 2020, 5:29pm

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

arrmo · July 23, 2020, 12:57am

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?

Thanks!

arrmo · July 23, 2020, 1:08am

Confirmed ... MAC address (WD-03, OEM install) is at 0x28, not 0x4000 => one more common item. LOL!

Will update, amend push

xabolcs · July 23, 2020, 7:35am

Missed it.

And here are my additions!

Did you think about my proposals?

More examples about DTS and image definition consolidation:

arrmo · July 23, 2020, 10:57am

No worries! Just made the ethernet mac address common also.

So a single recipe then, right? I like it! Will incorporate it.

No big issue here. Should I also change HooToo to ht-tm05 (https://openwrt.org/toh/hootoo/hootoo_ht-tm05)? If so, will do this on this new branch (and coming PR) ... rather than mess with the existing one, trying to get that one closed out, it's been going a long time

In the commit message you mean?

On the check marks, I think you mean that you agree, those ones are done and look good ... do I have that right?

Thanks!

xabolcs · July 23, 2020, 11:53am

Single recipe is another, but yeah.
I meant the compatible, model and others - see my quoted comment!

It would be nice to check how does sysupgrade from older OpenWrt releases (19.xx, 18.xx) to this PR work.
If it soft-bricks, then it would be nice to re-test with changed compatible strings: does it refuse to upgrade?

Keep it as is, for now ...
There is another HooToo page on OpenWrt Wiki which also need a rework: HooToo TM02

I hope not just that PR but this PR lands before 20.xx branches off.

I mean changing the model in the DTS file.

Those check marks are done with your latest commit.

tmomas · July 23, 2020, 4:58pm

What's wrong with those pages?

xabolcs · July 23, 2020, 5:57pm

All these devices think that the mtd2, Config partition is the u-boot-env partition, but it isn't.
And if someone got a serial connection and do a saveenv it will destroy the OpenWrt installation.
Because the real u-boot-env partition is the params partition:

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"

See discussion at the HooToo TM05 PR!

Another bad thing that these HooToo / RAVPower devices are limited to 1536 K kernel size: the u-boot reads only 0x180000 bytes at start and bad crc occurs when OpenWrt kernel exceeds this.
For example: Ravpower wd03 does not start with openwrt master - #9 by jeff

arrmo · July 23, 2020, 6:10pm

But we have a fix for these issues now

arrmo · July 23, 2020, 7:55pm

Right, so the recipe update (consolidation), and the name change - did get that. Let me make those changes, push a new commit for you to look at.

I can check that - but I know you can force, to ignore the results of that check. That's how I put HooToo firmware on RAVPower (and vice versa).

Will do.

Me too! No idea how to get the HooToo one in place . Then this one on top of course, but it should be easier.

tmomas · July 23, 2020, 8:23pm

OK, understood!

arrmo · July 24, 2020, 2:56am

OK, @xabolcs, I think your proposed changes are all incorporated, and pushed to my branch. Please look at let me know if you agree! And FYI, I had to force the sysupgrade, the metadata check worked, and complained about the new name ... .

The .patch trick in GitHub is very cool, thanks!

xabolcs · July 24, 2020, 8:04am

I meant check sysupgrade-ing from the latest bootable OpenWrt release, one of 19.07.x or 18.06.x to your image from this pull request.

Your sysupgrade.bin doesn't contain the LZMA Loader just the OKLI magic, I'm expecting soft-brick after forcing with sysupgrade -F.

arrmo · July 24, 2020, 12:10pm

Yep, agreed! And I have seen that happen before, so is there a reason to do it again? . Asking because after that cycle I have go to all the way back to OEM flash (programmer) again, so there is some pain involved .

Thanks!

xabolcs · July 24, 2020, 12:36pm

If you confirm the following, then no need to re-test:

simple sysupgrade stops from upgrading
sysupgrade -F soft-bricks the device:
- some sort of missing or bad magic
- it can be recovered with the TFTP recovery with kernel (rootfs isn't exercised by the current OpenWrt releases)

Are you saying that using for TFTP recovery the kernel and rootfs files extracted from OEM firmware binary (fw-7620-WiFiDGRJ-RAVPower-RP-WD03-2.000.074) hard-bricks the device?

xabolcs · July 24, 2020, 6:34pm

Review incoming.

In target/linux/ramips/dts/mt7620n_sunvalley.dtsi:

@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
 /dts-v1/;

 #include "mt7620n.dtsi"

From the diff it looks like that you "re-licenced" the mt7620n_ravpower_wd03.dts file.

In target/linux/ramips/dts/mt7620n_sunvalley.dtsi:

        leds {
                compatible = "gpio-leds";

-               green-wifi {
-                       label = "wd03:green:wifi";
-                       gpios = <&gpio2 0 GPIO_ACTIVE_HIGH>;
+               led_power: power {
+                       label = "tm05:blue:power";
+                       gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+                       default-state = "on";
                };

-               blue-wifi {
-                       label = "wd03:blue:wifi";
-                       gpios = <&gpio3 0 GPIO_ACTIVE_HIGH>;
+               wifi {
+                       label = "tm05:green:wifi";
+                       gpios = <&gpio2 0 GPIO_ACTIVE_HIGH>;
+                       linux,default-trigger = "phy0tpt";
                };
        };

Those tm05 names in the wifi labels look weird in a DTSI.
How about rename the dtsi to mt7620n_sunvalley_filehub.dtsi and use filehub:blue:power, filehub:green:wifi, ... as LED alias?
That would be non-sense, as the ongoing HooToo PR uses tm05 as label.

Are you able to define here the LEDs without labels and define with labels only int dts?
I know nothing about DTS include.

In file target/linux/ramips/image/lzma-loader/Makefile:

@@ -8,7 +8,7 @@

 include $(TOPDIR)/rules.mk

-LZMA_TEXT_START        := 0x80a00000
+LZMA_TEXT_START        :=
 LOADER         := loader.bin
 LOADER_NAME    := $(basename $(notdir $(LOADER)))
 LOADER_DATA    :=

This change is needless, just confuses the reviewer.

@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620n_sunvalley.dtsi"
+
+/ {
+       compatible = "ravpower,rp-wd03", "ralink,mt7620n-soc";
+       model = "Ravpower RP-WD03 FileHub N300";
+};

Please use RAVPower in model!
Including the "N300" prefix is a nice addition!

In file target/linux/ramips/image/mt7620.mk:

@@ -908,14 +897,14 @@ define Device/ralink_mt7620a-v22sg-evb
 endef
 TARGET_DEVICES += ralink_mt7620a-v22sg-evb

-define Device/ravpower_wd03
+define Device/ravpower_rp-wd03
+  $(Device/sunvalley_filehub)
   SOC := mt7620n
-  IMAGE_SIZE := 7872k
   DEVICE_VENDOR := Ravpower
-  DEVICE_MODEL := WD03
-  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci
+  DEVICE_MODEL := RP-WD03
+  LZMA_TEXT_START := 0x81800000
 endef
-TARGET_DEVICES += ravpower_wd03
+TARGET_DEVICES += ravpower_rp-wd03

 define Device/sanlinking_d240
   SOC := mt7620a

Please update DEVICE_VENDOR too!