TIAO USB Multiprotocol Adapter should work for serial.
But, if it works well, I think there's no need to tinker with it.
TIAO USB Multiprotocol Adapter should work for serial.
But, if it works well, I think there's no need to tinker with it.
I have a unit I believe is bricked that I'm willing to contribute. I followed the original instructions to convert the file layout to UBI and did minimal configuration. I believe it was running 23.05.0. The other day I turned it on to finish configuring it after it had sat for a while and suddenly it doesn't work... no lights, nothing.
I recovered my rt3200 using the serial method, ran the 1.1.1 ubi installer and the upgrade, then flashed a snapshot build about three weeks ago.
Yesterday I used the firmware builder to install a new snapshot but when I tried to install using Luci it I got the red warning that I had not ran the ubi installer. Is this normal?
If you're on the kernel 6.1.x snapshots and restored your old settings, you will need to run this to update your config.
uci set system.@system[0].compat_version='2.0'
uci commit system
I would suspect that maybe we’re seeing flash or memory caches not properly reset or something where after a power off, residual charges in the router board’s capacitors are still powering memory components. Waiting for the residual charges to dissipate likely resets all caches, and that also lowers the components temperature.
I don't know that I can agree with this. I can remove the power adapter entirely and flip the power switch several times, wait 4 hours, and can't boot. 30 minutes in the refrigerator, boots every time.
I think it's enjoying a cold beer while it's in there.
Having to cool any IC components down to -17C is definitely not normal.
Likely you are encountering broken solder joins?
I had two Linksys E8450 get bricked due to power outage which caused them to not power up again with no lights. They were both running OpenWrt 23.05.0 with pre v1.1.x flash layout when the brick happened. I've restored both using steps in post 4441 by @Daniel on March 13.
The only other thing I've done is set the performance governor from post 4191, I'm not sure what that does or if it will prevent future failures.
For now I'm just sticking with OpenWrt 23.05.0 with pre v1.1.x layout with the performance governor change, unless there is opinion there is a more stable configuration I should move to?
In reading this thread I didn't get the sense that there is a more stable option at this point.
23.05.03 includes commit a8f51096dd to set SPI-NAND pin driving strength to the OEM stock firmware 12mA. You might consider at least upgrading to this.
Without a root cause, it doesn't mean much, but I've been running my RT3200 dumb AP on UBI OpenWrt with a min frequency of 600 MHz since the beginning (~ 1 year) and no issues pre or post 1.1x layout conversion. I'm hopeful mine is past the first part of the bath tub curve. If and when it fails, I'll disassemble, wire up and flash a spare Reyee RG E5 to replace it though.
Thanks that did the trick!
@daniel
Installed latest snapshot SNAPSHOT (r25637-8753022aea), which i assumed having spi nand driving Va 12 as default
But it didn't help with reboot dead error
I think you will have to replace the BL2 and FIP images for the reboot error mitigation, and i dont think we are there yet without serial access
I recently struggled to debrick two routers after a power outage. It wasn't until a Reddit user pointed me to this thread that I made any progress, and even then I had to read thru a few weeks to find out all the details.
Could he wiki entry be updated to include information for uartboot, and the warnings for the new installer? I believe the wiki is the first stop for anyone with problems.
Thanx.
There's so much good info I'd like to update in the wiki, if anyone knows how to grant edit access without sitting in IRC I would be happy to help contribute.
Hi @kmitchel, I have edit access now and should have some time later today if not tomorrow. What information or steps, specifically, would you find most valuable to be included in the wiki?
Personally, I think what would be most helpful to the most people are the step-by-step instructions for someone running the then-current stable version (currently, 23.05.3) who wants to update to the next stable version that will require re-running the installer, while keeping their customizations/configurations.
A big warning explaining the new installer.
Basically the stuff in #4440 (I think). Links to the uartboot repo, the bl2 and fip binaries. Example command lines for screen on Linux and putty on windows.
Would probably help out a lot.
I think this post (further up) should provide a valuable clue that we are seeing software issue rather than hardware. Modern ICs can withstand 100C junction temp without breaking a sweat. Writing to flash memory is not intensive enough IMHO to cause any spike in IC temperature causing hardware failure. Flash are comparatively slow speed devices that uses slow clock frequency.
It looks like when it's a warm boot, boot loader could not load all it's pieces properly to boot the Linux kernel, while a cold boot seems OK. Likely there are two paths in the early stage boot loader code where I think we should study, and maybe identify the root cause.
It does look to me that this bug is likely introduced into the boot loader after v1.0.2 or v1.0.3 installer where it installs the router's boot loader.
A week later update:
It's been off and unplugged for seven days. Just tried it again, no change: no LED activity or other signs of life.
@dizdar have you had any progress after this?
Anecdote bordering on data: I have 3 RT3200 routwrs purchased in 2022 at different times, and they were all UBI flashed with version 0.65, and none have so far exhibited the rebooting problems/OKD.
This is a (potentially fatal) misunderstanding. The problem has not yet been addressed on the bootloader level. The opposite is true: If you run the installer for the very first time when the router still comes with stock firmware and bootchain, the driving strength of the SPI-NAND pins is setup by the stock bootloader at the time the new bootchain is written. If you update the bootloader later on (no matter in which way), you will use the potentially wrong lower values! So don't do it!
I've never observed OKD probably mostly for that reason: I revert to stock firmware and then run the installer for testing. I've never re-run the installer on a device which already runs OpenWrt and has been running any version of the installer before. I've also only briefly tested updating the bootloader using the U-Boot menu.
With OpenWrt 23.05.3 the driving strength values have been adapted to the values also used by the stock firmware in Linux (but not yet in TF-A and U-Boot!). I recommend users using the device in production to never touch the bootloader unless you really have to and stay with stable OpenWrt releases (currently 23.05.3).