HI,
I try the new kernel 6.6.20, I would like to know if I can use my back up config from kernel 6.1 ?
thanks
1 Like
Yes, this chance is not bigger or lower than any normal reboot.
Are there fixed spots in the mtd2 where these addresses are obvious to change in a hex editor? If so, can you list the correct locations? Thanks
Recently i ordered a used e8450 and it was of average condition externally, but I'm sure it was never opened and is untouched from inside, warranty tag was still up. Setting it up, made a mistake of flashing recovery from installer version 1.1.x and so soft bricked , thanks @daniel for helping me recovery through uboot using serial and i was up with it with latest snapshot. I'm deliberately elaborating history of it.
Now i was very cautious with every update and always check if auc is missing base file or not , also set governor to Performance, so it gives performance as well as piece of mind for not bricking it any way again.
Couple of days before, i updated it and it showed no signs of led lid up and looks stuck at bl2 (i didn't check serial, just elaborating led behavior), as i was not updating bootloader or like, so i was confident i didn't brick it, after waiting few minutes in same state, i just turned of power and turned it on and it was back to life, life was normal again.
Today i updated again and it was with no light lid up rebooting, suspected same and it took me 5 power on and power off and finally it started running again. Now i was in testing mind , rebooted again and it was again with no led lid up, this time did power on off switch multiple times and finally it was up at one good try, now situation is worsened, any reboot almost is not surviving and it is going dead with every reboot, many tries switch off on and 1 lucky try, it boots up... I also checked power supply with volt meter and it is ok.
Is it my electrolyte capacitor dying? Is it suppose to act like this when capacitor will dye or dying? Electrolyte capacitor is not such a delicate thing which can't be replaced but i want to know is it capacitor?
It definitely sounds like a hardware issue, and it falls right in line with other reports. As for precisely which component it is, I can't say. None of mine had failed in this manner (yet). This seems to be the kind of thing that would need common failure analysis of multiple units. Sadly, I'm sure the manufacturer isn't going to do this given that the model is already end of life.
Yes, I'm sure too, it's some hardware component failing, and I'm not looking to manufacturer , indeed we've many experts here and i think they can direct to right solution, as I've router running up normally right now and i know it'll dye if i reboot, so I'll again on task to power it up by on off toggling, in this case, what i believe chipset is ok, both radios are ok, usb is ok, indeed functionally it's all ok
So it might be capacitor , failing to provide power for startup and in any good try when it can pull up power to soc, it boots up , am i getting it right? Looking forward to a more assertive opinion...
Anyone has pic of electrolyte capacitor inside? As from previous words from @daniel it is under heatsink, I've never removed heatsink, so curious if one needs to access under heatsink to approach capacitor? Or is it readily visible and has work capacity (approachable hands and soldering iron and etc) so...
Given that the failures typically result in a read error on the memory, my guess would also be a low quality, overheated, or otherwise leaky capacitor. A filter capacitor is a good place to start looking, but it could also very well be in other parts of the circuit.
I haven't pulled the heatsinks or shields either. If it's under the heatsink, it's probably nothing more than screws and some thermal paste. The shields will be a lot more difficult to remove and put back on. Finding the problem may be as easy as checking for unexpected shorts or unexpected hot spots. When it's intermittent, however, that is always a pain to track down unless it's made itself visibly obvious.
I don't think so. Reading in U-Boot and Linux always works fine, so my first bet was also to just introduce some delay -- and generating lots of debug output in the UART creates such a (significant) delay, and that didn't help.
I still believe we are dealing with some sort of software problem and I was wondering about something else:
Could it be that the problem is created when writing to the flash rather than reading?
While we think of these devices as digital, the physics here is a bit more probabilistic and in the end a single bit of flash memory at it's core is nothing more than a well-isolated capacitor carrying a charge, and in the end it's the amount of electrons being above or below a certain threshold which then define it as either 0 or 1 when reading.
So maybe when writing the page cache via SPI and then instructing the NAND controller built-into the die of such SPI-NAND chip to write the content of the page cache to the actual flash, can it be that not having used enough charge to transfer the bits into the page cache results in a "weaker" write?
I'm still a software person with only some limited education in digital design and even more limited when it comes to analog electronics or theoretical physics. So please correct me if I'm wrong.
The reason why this theory came to my mind is simply that I still struggle to reproduce the problem on any of my devices and that made me think now how am I using them different from most (power) users here: I'm only ever writing the bootloader parts after having reverted to stock firmware first (for testing!), ie. with the stock bootloader having setup pinconf to 12mA driving strength for the pins used for the SPI-NAND chip (as we know now thanks to @981213) rather than the 8mA driving strength which is the default and used with our replacement UBI bootchain.
And now lets attack this with empirical science! We have many people here which experience very frequent OKD events and I wonder:
- I only ever run the installer once from stock firmware and experienced OKD
- I did run the installer while running OpenWrt's UBI bootchain and experienced OKD
- I only ever run the installer once from stock firmware and never experienced OKD
- I did run the installer while running OpenWrt's UBI bootchain and never experienced OKD
0
voters
Edit: Maybe may wording wasn't so smart. I should have asked:
"I only ever run the installer once from stock firmware, never updated the bootloader in any way and experienced OKD."
I have an RT3200 that had been running 23.05.0 after switching to UBI with the V1.0.3 firmware installer from @daniel and which has run into the BL2 error.
It seems to run fine once booted via the very helpful mtk_uartboot tool.
Is there some consensus on the wisest route forward at this point to have a device that isn't reliant on a serial connection to boot?
It seems that I can leave it running 23.05.0 by rewriting the FIP, or I can update to FIP in UBI with the V1.1.1 firmware installer and then run a snapshot going forward.
Rewriting the FIP looks pretty easy, but does moving to FIP in UBI possibly help to avoid a recurrence of this boot issue?
Thanks to everyone who has been contributing to resolving this boot issue, I thought I had a totally dead device and it looks like you all have worked out a way to bring it back to life.
I should add that I am in no hurry to get this device running again and can run some test or generate some logs if that would be helpful in resolving the ultimate cause of this issue.
Interesting ideas there. I admit, my knowledge in the details of NAND memory aren't quite as deep as some other parts of electrical design, but what you're saying does have merit. It's possible the weak writes could be borderline, or at least borderline enough to occasionally be read back as the wrong state. Of course the bit flip causes a CRC fail, and with the lack of redundancy, it fails to boot. I can't help but wonder if the issue might lie instead in the CRC/checksumming process. Is it possible that Linksys and Belkin decided to not check or validate the checksums for a reason (and maybe this very issue)? Could it also be the same that convinced them to simply raise the driving current on writes in an earlier attempt to avoid the issue?
I agree that some of this looks like software. However, a few people in this topic have reported conditions that do sound a lot more like a hardware problem as well. Although we have to add the appropriate complexity penalty to it, we could very well be dealing with two completely separate problems that merely manifest in the same general outcome at approximately the same time in the boot process.
Windows OS (win11)
CP2102 chips did NOT work for me. Might of just had a bad board or bad connection but I could never get tx to light up and never got a serial tag out on but.
CH340 serial USB did work. I did reconfirm all wires before connecting to the CH340 serial usb. It worked without issues.
Putty as the serial terminal to confirm CH340 was working and I could see the failed boot.
Then command prompt in Windows using the serial restore tool (with -s COM6).
1 Like
Many approaches and all carries certain weight
As you believe it's some sort of software problem, yes i can believe it and never experienced such thing on previous installer v1.0.2, on my previous router, so how many of here faced okd with previous setup? I tried to read and search such cases and found none here in this forum, so it erupted after v 1.0.3 precisely.
So i can do testing with
-
Go to installer v1.0.3 and on 5.15.x kernel and see , as now i can reproduce issue
-
I can go stock (obv with your help) and test
First will confirm and differentiate between old to new installer approach
Second will confirm if 12v stock bootloader will fix things and so rightly 8v ubi installer screw it
All i can say is something is seriously wrong and it needs an address to the core, thank you for your efforts
1 Like
Not sure if this adds any value, but I have been daily driving my RT3200 since 22.03.0-rc1. Tried a couple of snapshots here and there but mostly stayed on the stable releases. So about 10 flashes total. Still on the old UBI layout.
I am one of the guys who turns off my computer/network stuff when I leave home, by switching the power off on a power bar. This means my RT3200 have survived at least 1000, maybe 2000 sudden power cuts.
Maybe I am just lucky but I have never experienced any problems booting it up.
3 Likes
Have a look here Best "newcomer routers" - 2024
before buying old hardware overpriced.
GL-iNet MT3000 or Cudy WR3000 look very interesting and much cheaper, and for those really needing more juice and 2.5G ports, go for GL-iNet MT6000.
5 Likes
I can second this! I just bought two MT6000s and they're pretty incredible.
my bricked log: https://easyupload.io/lvx0no
How does WiFi range compare to the RT3200's?
Significantly stronger RX capability sensitivity given the larger and external antennas. The range is much further, too. I would equate the MT6000 range to what the R7800 was, as a gold standard, for a LONG time.
4 Likes