Port to RAVPower RP-WD009

[xabolcs]

@fonix232

So unless the u-boot env NVRAM format has changed significantly since I last checked, no, mtd5 / params should not contain the U-Boot env.

However mtd2 (the actual config / uboot-env partition) does contain relevant information, though it seems to me that e.g. the segment from 0x2000, and another segment at 0x6000 contain properties meant for the wireless configs. Then mtd3 contains some MAC addresses and such.

This u-boot environment partition talk is almost off-topic here, but did you try saveenving a new variable in u-boot?

I'm asking this because older FileHub devices' bootloaders (like HooToo HT-TM05, RAVPower RP-WD03) stored their environment in the params partition with offset 0x4000.

[arrmo]

@xabolcs

It also use a second stage loader, but not the LZMA Loader (in OKLI mode), but a self compiled U-Boot.
And yes, it does waste a the original kernel partition, but the device has 16 MByte flash, so no problem.

Perfect, thanks! So the TFTP install (factory.bin) is "safe" .... agreed?

@xabolcs

Before doing anything: back up the whole flash (through telnet, or any other way) to a safe place!!!

Definitely! Lesson learned ...

[xabolcs]

@arrmo

Perfect, thanks! So the TFTP install (factory.bin) is "safe" .... agreed?

From the commit message:

Installation
------------

1. Press and hold down the reset button.

2. Power up the Device. Keep pressing the reset button for 10
   more seconds until the Globe LED lights up.

3. Attach your Computer to the Ethernet port. Assign yourself the
   address 10.10.10.1/24.

4. Access the recovery page at 10.10.10.128 and upload the OpenWrt
   factory image.

5. The flashing will take around 1 minute. The device will reboot
   automatically into OpenWrt.

Looks like this isn't a TFTP, but surely a safe method of installing.

As you can see below the kernel and rootfs are splitted automatically by the Bootloader:

@blocktrron

int up_grade_fw(const ulong size)
{
	image_header_t hdr;
	int kernel_size = 0, fw_size = 0;

	memcpy(&hdr, WEBFAILSAFE_UPLOAD_RAM_ADDRESS, sizeof(image_header_t));
	kernel_size = ntohl(hdr.ih_size)+sizeof(image_header_t);
	fw_size = size - kernel_size;
	if(fw_size <= 0)
		return -1;

	raspi_erase(SPI_USRBACK_ADDR, SPI_USRBACK_SIZE);
	raspi_erase(SPI_USR_ADDR, SPI_USR_SIZE);
	if(raspi_erase_write((char *)WEBFAILSAFE_UPLOAD_RAM_ADDRESS, SPI_KERN_ADDR, kernel_size) < 0)
		return -1;
	if(raspi_erase_write((char *)(WEBFAILSAFE_UPLOAD_RAM_ADDRESS+kernel_size), SPI_ROOTFS_ADDR, fw_size) < 0)
		return -1;

	return 0;
}

This is the upgrade code from vendor U-Boot. As you can see here it writes everything after the uImage to the firmware partition.

[fonix232]

Can you show me an example of the data (preferably from a hex editor with addresses visible)? I'd love to see if there's anything similar on the WD009, possibly at other addresses.

I've quickly verified that none of the images contain anything even remotely resembling u-boot NVRAM environment data at 0x4000.

[fonix232]

That method is actually the web flash mode of uboot. Practically the same as TFTP (if I'm not mistaken, it calls the same flash method, but with easier file selection for the user).

[xabolcs]

@fonix232

Can you show me an example of the data (preferably from a hex editor with addresses visible)?

Sadly I don't own any of these devices, but there is a hexdump from a HooToo HT-TM05 in the other thread:

HooToo TM-05, Add LZMA Loader

Agreed! That's how I found the values I came up with ... LOL. Man, we are on the same page . Here it is, root@OpenWrt:/# cat /dev/mtd5ro | hexdump -C 00000000 00 00 00 00 31 39 32 2e 31 36 38 2e 31 2e 33 38 |....192.168.1.38| 00000010 00 00 00 00 32 35 35 2e 32 35 35 2e 32 35 35 2e |....255.255.255.| 00000020 30 00 00 00 31 39 32 2e 31 36 38 2e 31 2e 31 00 |0...192.168.1.1.| 00000030 00 00 00 00 31 39 32 2e 31 36 38 2e 31 2e 32 30 |....192.168.1.20| 00000040 31 00 00 00 00 0…

@fonix232

That method is actually the web flash mode of uboot. Practically the same as TFTP (if I'm not mistaken, it calls the same flash method, but with easier file selection for the user).

I didn't examine the GPL source from the opening post yet, but will do later.
The TFTP method for those older FileHubs needed two files: kernel and rootfs and was flashed accordingly.

Will check that GPL tarball later.

[arrmo]

@fonix232

the dumb stock OS will happily execute a script called EnterRouterMode.sh placed on the root of any attached storage medium, which then you can easily use to back every partition up,

Very cool! Trying this, no luck so far with USB or SD Card. Hmmm ... nothing special about this script for file?

Thanks!

[fonix232]

The web flash thingie takes multiple file formats, including the factory image format made by OpenWrt.

Thanks for the data dump, the matching bits on the WD009 are indeed on mtd5 (params, just after the kernel partition), and at 0x00, so even the smallest overflow of kernel bits would result in the overwrite of the original u-boot environment:

However since OpenWrt would be using mtd2 as uboot-env, if it was set up as such in envtools, that partition wouldn't matter - and I doubt it does much for the stock OS either. It does not match neither the running config IP addresses, nor the TFTP/webflash recovery mode network setup. To me it looks like a developer accidentally saved some testing data by accident, and the partition wasn't updated since (not the first time to happen to a Chinese manufacturer, e.g. ZTE sent out an update back in 2010, setting everyone's IMEI numbers to a test unit used in their labs). I'm more or less certain that apart from the section a bit further in the file, it is unused by the stock firmware.

And yeah, the part I'm talking about:

It contains the manufacturer name, device name, a version number, the main MAC address, and two hashes (haven't figured out what they are for, but none of the partitions, or parts of the mtd5 partition, match the hash).

@arrmo

Very cool! Trying this, no luck so far with USB or SD Card. Hmmm ... nothing special about this script for file?

Thanks!

That's interesting. It should work. Can you try generating a script with this and see if that works? Worst case scenario you get telnet access and can do the DD partition dump manually.

[xabolcs]

@fonix232

Thanks for the data dump, the matching bits on the WD009 are indeed on mtd5 ( params , just after the kernel partition), and at 0x00, so even the smallest overflow of kernel bits would result in the overwrite of the original u-boot environment:

...

However since OpenWrt would be using mtd2 as uboot-env , if it was set up as such in envtools, that partition wouldn't matter - and I doubt it does much for the stock OS either. It does not match neither the running config IP addresses, nor the TFTP/webflash recovery mode network setup. To me it looks like ...

If you are interested in this u-boot-env thread, then please read (and follow to the linked GitHub discussion - load all the comments) my answer below!

RAVPower WD-03, Add LZMA Loader

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 0001…

And if you are still interested, then please verify your device's u-boot saveenv behavior!
That would help!

Thanks!

[fonix232]

Okay, I've read through the PR comments. I think I know the reason for the confusion.

The stock u-boot indeed seems to use mtd5 as uboot-env, however the WD009 builds replace it with a mainline build. This, I believe, changes the partition being used for env stuff from stock_mtd5 to openwrt_mtd1 (which is stock_mtd2). The reason why on the WD03 builds saveenv screwed things up is most likely because parts of the kernel slipped over to that partition, and saveenv basically overwrote parts of the kernel. This shouldn't be an issue on the WD009, however I'll test this theory tomorrow.

[xabolcs]

@fonix232

The reason why on the WD03 builds saveenv screwed things up is most likely because parts of the kernel slipped over to that partition, and saveenv basically overwrote parts of the kernel. This shouldn't be an issue on the WD009,

Yeah, the RP-WD03 uses a wrong attitude: it starts the firmware partition at the stock kernel partition and doesn't care about params, config and other partitions in the middle. In turn, u-boot doesn't care about OpenWrt also.

And yeah, WD-009 uses the original partition scheme (while wasting a few KByte flash space), so no issues will arise!

[arrmo]

@fonix232

Can you try generating a script with this and see if that works?

Sorry! Already installed OpenWrt, so not running OEM now. But I did enable telnet, manually executed my script, and it worked fine (backing up the partitions). I am wondering about path issues perhaps, couldn't really check that.

[fonix232]

I think you could fix that by rolling your own u-boot, as per the WD009. I've also recommended ditching the extra partitions inbetween for the WD009, but as you can read above, it was ditched.

@arrmo

Sorry! Already installed OpenWrt, so not running OEM now. But I did enable telnet, manually executed my script, and it worked fine (backing up the partitions). I am wondering about path issues perhaps, couldn't really check that.

No worries, as long as you have the backups, everything should be fine. If it comes to that, you can even pry the case open (make sure you don't make the same mistake I did, and do it with an SD card inserted - I pretty much killed the slot on my first unit), and with a standard SOIC8 clip and serial flasher, you should be able to easily write the backup of mtd0 back onto the flash.

[arrmo]

@fonix232

you can even pry the case open

Perfect, thanks! Do you have any "instructions" for prying it open? Learn from what has been done

[fonix232]

Just work your way around the edge horizontally with a plastic pick. Watch out, because the plastic is soft, and the plastic ears are thick - it's hard to open it up without damage. Once you clicked them all out, you'll have to apply some continuous force, as the battery has a nice double sided tape sticking it both to the bottom and top part of the case, BUT also the antennae are glued to the case - make sure you don't rip them.

Hopefully you won't need to open it, though.

[arrmo]

@fonix232

Hopefully you won't need to open it, though.

Agreed! Good info though, thanks!

[offsprey]

FYI Pushing the 2.4G/5G button on my router soft-bricked the device.

The router was configured with 2.4G working, but I left 5G disabled. The button seems to have put the router in 5G only mode, as the 5G led lit up. Pushing and holding the button did not reverse the issue, and neither did rebooting the device.

The router would allow wifi connections, but would not hand out IP addresses. With SSH disabled on the Ethernet / WAN port, using the reset button was the only way to get access to the device. I will provide details when I get them, but wanted to put this warning out there.

[fonix232]

Was this with OpenWrt or stock firmware?

In OpenWrt, the 2.4 > 5G button is used for radio reset, whereas on the official firmware it is indeed used to switch between modes (IIRC you need to long press the button, this is to avoid accidental switching since the button is not recessed at all - which is why I recommended above to map it to something else, as this will most definitely happen to people who carry the device around).

[jmacul2]

Thanks for all your hard work on this guys. I've been waiting for support on this for a while. I got the snapshot installed and luci finally installed. My only issue is with the wifi. Specifically 5 GHz seems to be problematic. It says its active and openwrt allows me to connect as a client, but using 5 Ghz as an AP only, I cant get to work. Seems like Ravpower's switch config is getting in the way? Anyone having temperamental wifi issues?

[blocktrron]

Set the channel to 100 or higher. See https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ced167d72971e125825941dae22aad1d318c9dd2