Port to RAVPower RP-WD009

[fonix232]

Ah, my man, so sorry. Was editing my first big reply so long that I accidentally edited my response out Yes, I've moved all the relevant information out of the inbox pages, delete away!

@blocktrron

In theory, this would work. However we either need to patch the U-Boot quite a lot to enable a web-enabled conversion. Alternatively we can use TFTP. But again, we are talking about ~1.5M of flash space on a 16M device. I think (again) that this is a nice addition to a community build but for the stock OpenWrt i prefer the lighter patch and easier factory installation.

I see. I'll look into it then in the future. For now I'll focus on some LuCI additions (e.g. show battery percentage on status page, and such).

[tmomas]

@fonix232

Was editing my first big reply so long that I accidentally edited my response out Yes, I've moved all the relevant information out of the inbox pages, delete away!

Done, inbox pages for WD009 deleted.

[fonix232]

@blocktrron Just checked last night's ImageBuilder, and the ravpower-mcu package is still not included in the feeds - or anywhere at all. I've tried finding the git commit it was built from, and according to the version number, it's f496939f15 - and it points to this commit, which is after your merged change. By the looks of it, the package is being built, added to the WD009 target, then dropped instead of being added to the repository.

[arrmo]

@fonix232

show battery percentage on status page,

FYI, I submitted a PR recently for this, for some other HooToo and RAVPower devices. Feel free to start from that (actually, it may work straightaway).

[fonix232]

Oh, could you link that PR? I've been looking into injecting the battery state information into the ubus system info package, but the whole thing is somewhat of a woozy for me - coming from mobile development, the various embedded approaches are still not completely logical from my POV.

[arrmo]

@fonix232

I've been looking into injecting the battery state information into the ubus system info package

Here you go ... and yes, it's linked in to ubus .

luci-app-battstatus

[fonix232]

That's actually a pretty good start. Though IMO I'd probably make it a generic service that can receive, and publish battery data to ubus based on the device specifics.

HooToo and RAVPower devices (up until the WD007) were practically the same, with some slight changes. I've even discovered the ODM (who also belongs to the Sunvalleytek Group, but is now, if I'm not mistaken, mostly defunct). Hell, even the files in the source dump I got from RAVPower showed that they did minuscule modifications to the base system that was developed by this ODM (horribly, might I add). I'm fairly certain that pretty much all HooToo and RAVPower travel routers will use the same protocol for battery information and control (based on your code, the chip is on the same I2C port, and responds to the same protocol messages, as discovered by @blocktrron). Maybe it would be worth to rename the current ravpower-mcu to a more generic solution? You should be able to test it by building your own variant with some slight changes (IIRC most HooToo devices were MT7620, not MT7628, and ravpower-mcu right now only targets mt76x8 base).

I'd possibly also argue that while your initial changes to the UI are a good starting point, the problem is a bit deeper - maybe a framework (similar to how the status page can get populated by extra items placed in /usr/lib/lua/luci/view/admin_status/index/) that allows LuCI apps to add their own little header tidbits?

Okay, I'm going way off the rails here, trying to fix issues that don't even exist Though honestly, if you want to add battery info permanently to LuCI, I'd recommend first do it with a status page extension, as it won't introduce breaking changes into every theme out there.

[blocktrron]

Ouch, i suspect the limit to the ramips target might be the reason why this fails. I'll look into how target-agnostic the builders are.

[fonix232]

Sounds good. However I would urge @arrmo to try it first on their HooToo (05 and 06, anyway) devices - by the looks of it, it's the same PMIC MCU and probably the same instruction set. If it does work, it might be worth a bit more generalisation - though then we would probably need to find a common name for these devices (I think generally calling the whole family and its variations FileHub would be pretty straightforward).

[Balanceandpeace]

Watching this development intensely and checking in to see if there’s any updates on a community build that keeps the FileHub functionality with OpenWrt like @fonix232 is suggesting. The latest I see on image builder is from what looks like the first build on Jul 4.

Part of what I’m hoping for (beyond an upgrade from the terrible stock software) is to connect the filehub to my phone hotspot and by editing iptables, mask hotspot usage (this might be a mostly US thing) and create remote unlimited data for all my devices. Phone photo backup would be sweet as well, are there OpenWrt packages that do that?

Happy to test changes!

[arrmo]

Hi,

A friend of mine here has a new RP-WD009, and I'm trying to convince them to install this build . But before I push too hard .. does this install trash (overwrite) the u-boot env partition? In other words, is the kernel > 1.5 MB?

Thanks!

[xabolcs]

@arrmo

... does this install trash (overwrite) the u-boot env partition? In other words, is the kernel > 1.5 MB?

Port to RAVPower RP-WD009

FYI - OpenWrt support for RP-WD009 has been added with https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=e959048c128e4350b78df653be7cd7277787518e OpenWrt firmware images for RP-WD009 (Currently only snapshot support, therefore LuCI needs to be installed manually after flashing). The dataentry currently shows as unsupported functions: "WiFi 5GHz, SD card, LEDs" Can someone please verify if those are working or not and give feedback? Thanks!

It doesn't overwrite the u-boot-env partition ... as it keeps the original partition scheme with naming. So it has the original params partition name for U-Boot environment. And it doesn't configure the uboot-env package!

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.

@arrmo

But before I push too hard ..

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

[fonix232]

Based on my exploration of the various partitions' stock dumps, the partition mtd5 on the WD009 does not contain U-Boot parameters - in fact it's mostly the default setting for the stock firmware:

• handful of IP addresses between 0x00 and 0x40
• a block of device self-identification from 0x400 to 0x560, with a SHA256 hash trailing it at 0x510:
  • Manufacturer and device name
  • Firmware version
  • MAC address

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.

Also, you can easily create a dump of the flash even without telnet access - 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, something like this:

#!/bin/sh

dd if=/dev/mtd0 of=$(pwd)/backup_mtd0
dd if=/dev/mtd1 of=$(pwd)/backup_mtd1
[ repeat the same as above but for mtd2..8 ] 

In theory, $(pwd) in this context should be the volume the script is run from, but fair warning, I have not tested this at all - you might have better luck with specifying the appropriate mount point. Either way, with this script you can easily back everything up without even touching the device, just plop it on an SD card or USB flash drive, plug it in, and boot it up.

And no, overall I don't think the kernel is larger than the 1536kB size, however I did not check thoroughly, and honestly, I see no reason to go back to the original software - sure, OpenWrt needs a bit of tinkering to get to the (almost) same level of functionality as the stock firmware, but overall I found it much more stable and reliable, not to mention the massive kernel version difference (2.6.36 vs 5.4.x).

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