Support for Xiaomi Wifi R3P Pro?

For Developers
305

@ilyas Thanks for looking at this! Regarding the NAND, well, I had to bitbang a little to flash it, so I think I have pretty good idea of its command set. I found that there should be MTD API in 4.14 kernel: https://www.kernel.org/doc/html/v4.14/driver-api/mtdnand.html, but I did not use kernel API before. Do you have any idea how to link a small C program with this API?
I don't have a router with me now, so will follow your instructions tomorrow...

[UPDATE 2019-03-14]
So, just reverted back to dev firmware and everything looks good with the persistence. Here is the boot log: https://ufile.io/zd72r. The /root is ro, so I cloned mtd1 partition into etc and it was still there after reboot. Trying to re-flash OpenWRT now...

[UPDATE]
No luck with mtd erase :frowning: No persistence between reboots. Will do sysupgrade later...

[UPDATE]

root@OpenWrt:~# mtdinfo -a
Count of MTD devices:           10
Present MTD devices:            mtd0, mtd1, mtd2, mtd3, mtd4, mtd5, mtd6, mtd7, mtd8, mtd9
Sysfs interface supported:      yes

mtd0
Name:                           Bootloader
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             false

mtd1
Name:                           Config
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:2
Bad blocks are allowed:         true
Device is writable:             true

mtd2
Name:                           Bdata
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:4
Bad blocks are allowed:         true
Device is writable:             false

mtd3
Name:                           Factory
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:6
Bad blocks are allowed:         true
Device is writable:             false

mtd4
Name:                           crash
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:8
Bad blocks are allowed:         true
Device is writable:             true

mtd5
Name:                           crash_syslog
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:10
Bad blocks are allowed:         true
Device is writable:             true

mtd6
Name:                           reserved0
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:12
Bad blocks are allowed:         true
Device is writable:             false

mtd7
Name:                           kernel_stock
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          32 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:14
Bad blocks are allowed:         true
Device is writable:             true

mtd8
Name:                           kernel
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          32 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:16
Bad blocks are allowed:         true
Device is writable:             true

mtd9
Name:                           ubi
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          1964 (257425408 bytes, 245.5 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:18
Bad blocks are allowed:         true
Device is writable:             true

root@OpenWrt:~#
1 Like
306

On the last release there's no problems with it. I've tried it many times.

1 Like
307

At work at the moment, will upload them when I'm home. @ilyas

1 Like
308

@andreykiselev

ubinfo -a

?

and, if it wouldn't be too much trouble, could you send me your ubi partition (PM is fine)

dd if=/dev/mtd9 of=ubi.img

maybe by comparing it to mine I can see what's going wrong (hacking, really, but it might work...)

309

I'll ask my friend with micron do this too. Maybe something more?

1 Like
310

@ilyas Hm... it seems to work after sysupgrade... Here is the bootlog: https://ufile.io/gps1x. And here is the output of ubiinfo, but I'm not sure if there is any use of it now since everything seems to be okay:

root@OpenWrt:/# ubinfo -a
UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:59
Present UBI devices:            ubi0

ubi0
Volumes count:                           2
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     1964 (249380864 bytes, 237.8 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  40
Current maximum erase counter value:     3
Minimum input/output unit size:          2048 bytes
Character device major/minor:            251:0
Present volumes:                         0, 1

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        45 LEBs (5713920 bytes, 5.4 MiB)
State:       OK
Name:        rootfs
Character device major/minor: 251:1
-----------------------------------
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        1875 LEBs (238080000 bytes, 227.0 MiB)
State:       OK
Name:        rootfs_data
Character device major/minor: 251:2

[UPDATE] Just checked couple of times, and the files created on /root stay after reboot. Also, changes made with the interface are now persistent. Is there anything special with sysupgrade or flashing with tftp? I can keep testing if needed.

1 Like
311

crap....

did you tftpboot to do sysupgrade? or just sysupgrade from the (flash booted) system that wasn't working? did you do ubiformat first?

i want the broken system! :slight_smile: if we assume that something about the installation is broken we can just have it run "ubiformat" on first boot, but that's not the same as fixing it (it's a hack)... need to figure out what's going wrong in the installation...

could you re-install (mtd erase and all) and give me ubinfo -a and your mtd9? in fact, can you give me your current (working, hopefully clean, no new data) 'mtd9' and your 'broken' (fails to mount) mtd9? (please? :slight_smile: )

[EDIT in response to UPDATE|: yeah well now that you're properly mounting ubifs as root (not RAM-backed anymore) your changes would be persistent, and you'd be a happy customer :wink: i'm still in the process of figuring out just exactly what's going on during installation (my initial impulse is to always copy/paste code or treat it as a black box... sometimes unfortunately that doesn't work out so well ;))... but it's probably that the way we're laying down the bits initially (mtd write etc) isn't really such a good idea... and it works sometimes and doesn't work all the time (at least so far i know that "ubiformat" is the recommended way of laying down UBIFS systems... we directly write the headers and expect it to fix things up by itself later...)

anyway, i don't want to speak too soon, but it looks like we're getting somewhere (finally... i hope...)

thanks!

2 Likes
312

@ilyas Will test it as soon as I can!
Side note: Because I used raw flash image from other guy, I want to flash a tx calibration table (originally mtd4, now it's Factory) from my recovered image. How can I set Factory block writable to flash it?

1 Like
313

@andreykiselev i'll send you a kernel module to make read-only partitions writable... (in a bit...)

[UPDATED] here's the kernel module https://github.com/iscilyas/openwrt-r3p/releases/download/v0.1-rc1%2Bmt7615e-5/kmod-mtd-rw_4.14.104+git-20160214-1_mipsel_24kc.ipk

and here's how to use it:

PS: obviously I didn't test it... but it's a standard part of openwrt so it probably works :wink:

314

@pellmen if you could get your friend with Micron to install stock/install openwrt (using the instructions on the TOH), give full bootlogs, reboot, (full logs) then do sysupgrade and reboot (again full logs)... and possibly (depending on how much time he wants to invest) tftpboot and ubiformat and sysupgrade... that would give me at least 2 data points to work with... since @andreykiselev 's NAND is known to be in a rather strange state, it would be unsafe to draw general conclusions from only his experiences...

PS: i could swear there was someone on 4pda who was saying his configuration changes were disappearing after reboot (or was that here....) ... if that person reads this post, please also give me full bootlogs (at least)

315

Sorry, reached the limit of replies...

Here is ubinfo of a good block:

UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:59
Present UBI devices:            ubi0

ubi0
Volumes count:                           2
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     1964 (249380864 bytes, 237.8 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  40
Current maximum erase counter value:     3
Minimum input/output unit size:          2048 bytes
Character device major/minor:            251:0
Present volumes:                         0, 1

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        45 LEBs (5713920 bytes, 5.4 MiB)
State:       OK
Name:        rootfs
Character device major/minor: 251:1
-----------------------------------
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        1875 LEBs (238080000 bytes, 227.0 MiB)
State:       OK
Name:        rootfs_data
Character device major/minor: 251:2

And here is the block itself: https://ufile.io/d9rn3
Now the problem is that I cannot revert back to stock firmware to replicate standard failing installation... I run:

fw_setenv flag_try_sys1_failed 0
fw_setenv flag_try_sys2_failed 1
reboot

with dev firmware on a usb drive, but then it just reboots into OpenWRT and there is no red led when reset should be pressed... Is there anything I do wrong to recover stock?
P.S. Thanks for the write-enabler!

316

perhaps you accidentally write openwrt kernel to kernel_stock(kernel0) ??
& try setenv via uboot

317

@lolyinseo Just recovered stock with tftp... Bulletproof way :slight_smile:
@ilyas So, after recovering original dev and then flashing OpenWRT in an easy way, the symptom is back again! :slight_smile: Here is the ubinfo:

UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:59
Present UBI devices:            ubi0

ubi0
Volumes count:                           2
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     1964 (249380864 bytes, 237.8 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  40
Current maximum erase counter value:     1
Minimum input/output unit size:          2048 bytes
Character device major/minor:            251:0
Present volumes:                         0, 1

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        45 LEBs (5713920 bytes, 5.4 MiB)
State:       OK
Name:        rootfs
Character device major/minor: 251:1
-----------------------------------
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        1875 LEBs (238080000 bytes, 227.0 MiB)
State:       OK
Name:        rootfs_data
Character device major/minor: 251:2

And here is the bad ubi block: https://ufile.io/v5azb
So, no persistence, as it used to be. Should I keep it running for now?
Also, here is a boot log of the latest (bad) system: https://ufile.io/19pgx
P.S. Write enabler worked like a charm and I got my serial and MACs back! :slight_smile:

318

@andreykiselev about reverting to stock firmware: are you using pb-boot? if so, the hack was to overwrite kernel0 anyhow... so you'll have to write kernel0 back into kernel_stock partition...

319

@ilyas No, I am on stock u-boot.

320

@andreykiselev so what happens when you try to boot from stock xiaomi? still boots from openwrt? are you sure you didn't overwrite kernel_stock by accident?

if you did, re-flash it... download https://github.com/iscilyas/openwrt-r3p/releases/download/v0.1-rc1%2Bmt7615e-3/kernel0

and

mtd write kernel0 kernel_stock

PS: i'm glad the "rw" thing worked... hadn't tried it myself :wink: also, thanks (a whole lot) for uploading 245MB! (it would have taken hours on my POS 0.8mbit upload connection...)

321

@andreykiselev no, probably not much point in keeping "ro-root" openwrt (since you already sent me the partition...)

BTW, when re-flashing this (the mtd partition you sent me), you're sure you first did mtd erase of rootfs0 rootfs1 and overlay?

322

Have you seen my last pm? I've gave you the sources of bootloader (unfortunatly not from pandora creator, but it works with our router, micron compatible)

1 Like
323

Well, I didn't even try. I'm not very interested in running stock Xiaomi firmware, but thanks for the link! I'll flash it just to keep things in a good order :slight_smile: And no worries, I have a good uplink :wink:

Oops... You'r right, it completely swiped out of my mind... Should we try it again then?

1 Like
324

@andreykiselev.... if you don't mind. also, can you give it some time (after you install openwrt) just in case it's erasing the mtd in the background and didn't get around to finishing it before you reboot...

maybe 5 minutes should be more than enough....

EDIT: the message about kernel_stock was because you posted about not being able to revert to stock xiaomi :wink: