Have done some testing - first boot the wifi doens't come up. Stopping and restarting them brings it up. However as others have reported, you can't connect on either 2.4 or 5g. If you turn off the security on 2.4 you can connect, but not 5g.
This is similar in behaviour to the VLAN issue for this router. I use VLANs and have the workaround in place and working (why I asked if others used VLANs).
I didn't try resetting the NVRAM, happy to give this a go if it'll help?
Restoring the firmware back restores full operation.
Don't do anything for now. This is a separate issue. First, I'd like to deal with this NVMEM problem so the device can boot properly. I'll let you know when it's done.
I have sent a patch to disable the NVMEM_BRCM_NVRAM driver but @rmilecki shot it down saying there's surely a better approach. They then disappeared on me without a word on what this better approach would possibly be so I'm stuck and can't make any progress.
It's been 6 months and unfortunately, I don't see a way out without Rafal bothering to reply to us peasants.
Just tested the "test4" firmware posted above.
Router boots fine, and 2.4 and 5G networks are working with/without WPA2 PSK encryption.
I have a working router! Thankyou
Been running it all morning - so far so good. Straight upgrade - wifi came up and worked without an issue. Will continue testing and report back and issues.
Thank you for sorting this out - guessing we're out of the mainstream now for upgrades and the like? Shame as the router is really useful with 8 ports
Firstly thank you for efforts on fixing this, but would it be possible to publish the patch you applied to your test4-* build? would like build my own with some of additional kmods. as 5.15.126 is not supported anymore nor from snapshot packages, nor mainstream currently
I'm sorry guys for dropping the ball on this issue. Let's try to solve it finally.
Let me start with saying that NVMEM driver for accessing NVRAM has actually a purpose:
It allows reading MAC entries (AKA cells)
It provides NVRAM content to the bcm47xx_nvram driver/library
So we can't just blindly disable NVMEM_BRCM_NVRAM because it will regress support for devices:
Some interfaces and switch ports will loose their proper MACs
Linksys devices will stop booting randomly (depending on used firmware partition)
At first I thought we could/should just disable NVMEM based access for NVRAM stored in NVRAM and I even developed a trivial code for that:
#define SI_NS_NANDFLASH 0x1c000000 /* NorthStar NAND flash base */
#define SI_NS_NORFLASH 0x1e000000 /* NorthStar NOR flash base */
if (res && (res->start & ~0xffffff) == SI_NS_NORFLASH)
return -EOPNOTSUPP;
but then I realized it would also affect Linksys devices.
So what's the case with Linksys models?
First of all I don't think they are affected by the issue reported in this thread. I added NVMEM based NVRAM access for them years ago and I believe it was tested successfully. I don't know why this bug affects ASUS devices but doesn't Linksys devices. Both have NVRAM stored in NAND flash.
So whatever workaround we come up with we should make sure it touches ASUS devices only.
I've two ideas for a workaround that doesn't regress other devices:
Modify ASUS DTS files by adding status = "disabled"; to NVMEM NVRAM devices
Modify brcm_nvram.c to skip ASUS devices
The first solution may be simpler (not much though) but I'm not sure if it's the correct thing to do semantically. That NVMEM access is there and it somehow works. I guess it may be a valid way to access NVRAM content for a bootloader (before NAND controller gets initialized).
Maybe we should just come up with a small brcm_nvram.c hack? I'll take a look at that.
Even more interesting is that @arinc9 has recently added support for ASUS RT-AC3100 and it also has NVRAM stored in NAND flash. It also seems to use NVMEM access for NVRAM content.
@arinc9: can you confirm ASUS RT-AC3100 works for you without disabling NVMEM driver?
I don't have an RT-AC3100 but @effortless and @ktmakwana do. I did supply them test images previously but I've never thought to supply one with the NVMEM drivers enabled. They also tested an official 22.03.5 RT-AC88U image on RT-AC3100 which did not cause bootloop. I assume that it doesn't cause trouble because the AC88U devicetree defines et1macaddr as the variable to retrieve the MAC address whilst the AC3100 hardware stores the MAC address on the et0macaddr variable instead.
To confirm whether AC3100 will bootloop, could you two test the official AC3100 image from here?
Edit: I just changed the RT-AC88U DT to et0macaddr then et2macaddr and tested on RT-AC88U with NVMEM_BRCM_NVRAM enabled. It boots fine. I'm going to guess @effortless and @ktmakwana will report bootloop on RT-AC3100 on the official image.
This is very helpful. It means (if I'm right) that it's only reading NVMEM cells after first init that breaks NAND controller setup. So we should be safe to init NVMEM device and even call bcm47xx_nvram_init_from_iomem().
That would also explain why we didn't have any issues with Linksys devices. They don't have any NVMEM cells defined.
Now I'm wondering if we could just read NVRAM during init and store a copy of its content. We could even read NVMEM cells content from it. That would avoid messing up NAND controller state.
It should fix ASUS booting problems and also allow them to use NVMEM cells for MACs.
I'd like to wait for confirmation from @effortless or @ktmakwana to see if official RT-AC3100 images indeed are broken for them. Let's wait a day to see if we get some feedback.
@rmilecki I'm on a trip and won't return until September.
I have used the snapshot build for 3100. It worked fine but had an older kernel and I couldn't install the SQM scripts. I am now back to using AC88U image because it works fine and I can have cake scheduler.
If you want something specific tested I can do it once I return in September.
Didn't this patch series do that? V3 was not archived anywhere for some reason but it should be in your inbox.
[PATCH v3 0/2] nvmem: brcm_nvram: use buffered nvram data for cell values
I also tested the ethernet driver getting stuck when NVMEM_BRCM_NVRAM is disabled whilst NVMEM is enabled. The driver works after the NVMEM cell definition under the the gmac node is removed.
So even though there's no driver to read from the NAND flash, the ethernet driver continuously tries to retrieve the NVMEM cell and gets stuck.
- wifi came up and worked without an issue. Will continue testing and report back and issues.