Because of this comment I assumed the copy in RAM was meant to be always used. Also bcm47xx_nvram_getenv seems to use it.That is why I proposed a read function.
Do you have any tips on where I can start looking to find what is causing this problem?
I kept thinking about this problem.
I based all my brcm,nvram development & testing on devices with serial flash used for bootloader & NVRAM. I never tried any device with NVRAM in NAND.
FWIW:
Serial flash is mapped at 0x1e000000
NAND flash is mapped at 0x1c000000
I think there may be some unexpected NAND controller behaviour caused by using NAND flash content mapping. My guess is that reading NAND content using mem IO somehow affects NAND controller state.
I'll try to contact Broadcom / NAND controller people see if they can help.
short update. while printing the read data I noticed something.
booting: https://pastebin.com/tXEy6C1f
crashing: https://pastebin.com/hZsdZB94
Line 273 shows when crashing the data read as VID header is totally different from the booting one.
The funny thing is that it starts with some ascii stuff: nse_slope=0xFF which seems to be part of the nvram partition. (I guess it is 1:tempsense_slope=0xff at offset=2570)
I have no idea what this indicates.
I have same problem on last release 22.03.3 and last snapshot build.
Another short update: when using mtd to read the data in brcm_nvram_read the image also boots.
I used something like (as done in bcm47xx_nvram.c):
mtd = get_mtd_device_nm("nvram");
if (!IS_ERR(mtd))
err = mtd_read(mtd, offset, bytes, &bytes_read, (uint8_t *)val);
the correct data is read (the mac address) and ubi attach now works.
So whatever readb does in brcm_nvram_read it makes mtd fail. (I have still no idea what readb actually calls or does.)
2 Likes
Just checking in on the great work done here - was this submitted as a patch or fix? Has it been accepted, if so I'll flash and test again and mark as closed?
2 Likes
Still ongoing as of 22.03.4 release
I think I am going to disable this feature on the devicetree for now. It's a very subtle feature that blocks the whole device support. @rmilecki what do you think?
22.03.3, 22.03.4, and 22.03.5 are identical and all have bootloop.
Will there be any changes (i.e. fixes) in the coming future?
2 Likes
waiting for this issue to get resolved. until then, we are stuck with 22.03.2
My AC88U with HW A2 also broken in 22.03.3, and I've attached the full booting log for your reference.
I finally decided to install OpenWRT on on Asus RT-AC88U (HW:A6)... Sadly, 22.03.5 does not work either. It does not boot. I returned to the CFE dashboard and tried again. I tried 22.03.2 and that appears to have worked.
Is there any interest in fixing the underlying issue?
Do we know if this is fixed in the 23.05 RCs?
I've disabled the NVMEM driver that caused the issue. Please confirm this snapshot image works fine.
1 Like
Hello,
Don't know if it can help but I installed it successfully and wireless is present (was not the case for me with 22.03.02) :
Did not test any further, I a very newby in the world of alternative firmware.
See if wifi works. Try to connect using it.
Amazing, will test tomorrow and report back.
Not able to connect to wif. Can see devices trying
Ethernet connection seems not very stable too, loosing internet often (but could be my setup).
This is what I get too. 23.05-rc2 is affected too. 22.03.5 works fine. It seems something broke with the Broadcom wireless driver between 22.03 and 23.05, sigh.