Bootlooped again. Here's what I see once out of ATF:
Init_DRAM:2480: init PCDDR4 dram End
EMI: complex real chip dram calibration
Verify pattern 1 (0x00~0xff)...
EMI: mem8_base[0] = pattern8 = 0x0
Verify pattern 2 (0x00~0xffff)...
EMI: mem16_base[0] = pattern16 = 0x0
Verify pattern 3 (0x00~0xffffffff)...
detect button reset released!
Reading from 0x0 to 0x5f7fdd8c, size 0x4 ... OK
Boot failure detected on both systems
Reading from 0x0 to 0x5f7fdd8c, size 0x4 ... OK
Saving Environment to MTD... Erasing on MTD device 'nmbm0'... OK
Writing to MTD device 'nmbm0'... OK
OK
Booting System 1
resetting ...
Dunno if this will hold though, because setting boot_fw1 and boot_rd_img2 as above didn't kick it out of boot loop. U-boot replacement might be a better option.
There’s preliminary support in a pull request up on OpenWrt GitHub. I think anyone who is willing to build it themselves and test it are simply still testing it.
I myself have been testing it and have found a few issues that don’t have a perfect solution yet, but it’s being worked on. Some of the discussion is in the PR.
Okay seems like this is working perfectly now. Just pending approval to get merged in. Awesome job @remittor finding that bug and everyone else involved!
This sounds great, thanks everyone for their hard work on this. By "working perfectly" do you mean to say that OpenWrt is working with all features (subject to the usual disclaimers regarding the very bleeding edge nature and limited testing of the current builds course), or just that the basics are working well, but there's still additional known issues/features that will need to be fixed before OpenWrt is running well on this router?
I ask because I need to order a new router quite soon and am now very tempted by this one, assuming there doesn't appear to be any big/obvious hurdles preventing a release OpenWrt build from appearing in the next few months or so. I came close to ordering an AX3200 but was put off by the slow AX performance as well as the longstanding squashfs bug.
Note that I'm new to OpenWrt but am a software dev with reverse engineering experience so aren't afraid to get my hands dirty with gaining ssh, compiling test/beta builds, appreciate there's still likely to be bugs etc.
LED on top doesn't work, just stays solid blue as theres no driver for it.
802.11ax performance on Apple (maybe more generally Broadcom devices) still sucks, but I don't think it's specific to MT76. See 802.11ax worse than 802.11ac with mt76 driver? - #110 by soxrok2212
For reference, I did a iperf3 test between my Q-Hora 301w and a Redmi AX6000 connected via WDS and achieved just over 1gbit/s. I did also send Apple a bug report but it's not likely they're going to do anything about it.
Otherwise, yes outside of bleeding edge nature all appears to work well.
I haven't tried the SSH flashing method, only UART/tftpboot but the u-boot env options are very important so u-boot doesn't randomly break itself and require you to open up the case.
Some change may come later on to move the partitions around and keep Xiaomi scheme for easy reverting, but I don't plan on going back to a firmware that calls back home so I reclaimed all that space for myself.
Thanks, will do, I'm keeping an eye on that pull request already quite closely. I'm ordering from AliExpress to the UK so by the time it finally arrives the install process no doubt will have changed a bit anyway Like you I'm unlikely to want to revert to stock firmware.
For the second point, I have seen a similar low performance problem with the updated firmware of TP-link 6088 with the same chip, but they are finally solved (not sure, I do not have the machine)
Like you I'm unlikely to want to revert to stock firmware.