Support for Xiaomi Wifi R3P Pro?


#303

Maybe it will help?) I think maybe you'll compile the firmware with all packages preinstalled - it would be better, than install every package manualy.


#304

@andreykiselev sorry i'm the wrong person to ask about anything hardware related :wink: if you know the magic sequence (what memory address, whatever) to enable ECC for your chip, yes it can be done (presumably from the kernel)... but you'd have to find that. i'll help you with the code if you need it :wink:

but it looks like your system is freaking out in general...

Data buffer not 16 bytes aligned: 8ffe16c8
...
[    3.271742] compare signature failed 1f840.
...
[    3.280011] load_fact_bbt failed
...
[   12.660959] UBIFS error (ubi0:1 pid 491): ubifs_recover_master_node: failed to recover master node
[   12.669897] UBIFS error (ubi0:1 pid 491): ubifs_recover_master_node: dumping first master node
...
[   12.787364] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops
[   12.794761] mount_root: failed to mount -t ubifs /dev/ubi0_1 /tmp/overlay: Invalid argument
[   12.803384] mount_root: overlay filesystem has not been fully initialized yet
[   12.810868] mount_root: switching to ubifs overlay
[   12.815730] mount_root: switching to ubifs failed - fallback to ramoverlay

I guess you're rather the "exception" in that you've seriously messed around with your hardware... the average user may not have the same experience.... @souk do you think you can provide similar boot logs? your problem appears to be the same... (failure to mount ubifs partition after boot)

@andreykiselev how about stock xiaomi? any problems with that (with your hacked NAND chip i mean).... i saw the bbt messages on your log but otherwise it looks sane

could you revert to stock and try again, this time with a mtd erase of roofs0 and rootfs1 and overlay?

cd /tmp
mv openwrt-ramips-mt7621-xiaomi_mir3p-squashfs-factory.bin factory.bin
dd if=factory.bin bs=1M count=4 | mtd write - kernel1
mtd erase rootfs0
mtd erase rootfs1
mtd erase overlay
dd if=factory.bin bs=1M skip=4 | mtd write - rootfs0

@pellmen i think those mtd erases are a good idea in general...

also, @andreykiselev, if you don't mind (and especially if the mtd erase lines don't make a difference)

can you setup a tftpd server, tftp boot initramfs-kernel.bin (latest), then

ubiformat -v -y /dev/mtd9
ubiattach -p /dev/mtd9

then copy over sysupgrade.bin (to /tmp !) and:

sysupgrade sysupgrade.bin

and reboot.

I will still try to track down the "read only root" problem you're having (how annoying) but I want to see if the above give better results....

EDIT: i didn't say it very clearly, but from your boot log it's obvious that your overlay read/write partition failed to mount, so it switched to "ramoverlay" which obviously isn't persistent storage (RAM... cleared on power-off). the "why" is more interesting...

EDIT2: @andreykiselev can you also give me the output of

mtdinfo -a


#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:~#

#306

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


#307

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


#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?


#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.


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


#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?


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