Posted: Fri Jan 10, 2025 14:57 Post subject: New Build - 01/10/2025 - r59093
Welcome to MediaTek r59093 beta release thread for reporting, feedback to developers & community benefit.
Please do not flash builds until installation is understood, risks involved and device specificrecovery methods.
Avoid discussions, create threads for questions, general problems or use search; this thread is not for support.
List router model & version or revision, operating & wireless modes & exact filename/firmware image flashed.
CLI Flash: 'cd /tmp' then 'wget {file URL}' (httponly) or 'curl -O {file URL}' (http, https, ftp) 'write {file} linux' then 'reboot'.
Issues, observations, and/or workarounds reported:
• WebUI: Clear history or use a portable. Temporary cache bypass: Ctrl+F5, Cmd+Shift+R or new private window/incognito.
• Please report findings with steps needed to reproduce, configuration, clients, output, logs and important information below!
Important:
• Detail issues & relevant configs, logs: syslog klog 'dmesg' 'cat /tmp/var/log/messages' nvram set console_debug=1, serial.
• Firewall NAT: 'iptables -vnL' 'iptables -t nat -vnL' 'iptables -t mangle -vnL' & 'cat /tmp/.ipt'. Debug Analyze: stracetcpdump.
• Gremlins: reboot. cold boot. Reset & reconfigure not restore backup. Search Trac & discuss in forum before opening tickets.
• Include operating & wireless modes (e.g. Gateway, Router, AP, SB, WDS, Mesh) and applicable configurations to reproduce.
One of two problems fixed--woohoo! Many thanks, BrainSlayer!
I am able to install r59093 on my Netgear R6220 using the "factory-to-ddwrt" file via nmrpflash and boot successfully.
However, I remain unable to install the "webflash" version of the firmware from within the DD-WRT webUI. As documented in this previous post, (to me at least) the failure signature in the log appears identical to the problem that was just fixed.
A serial log capturing the attempt to reinstall the "webflash" version of r59093 using the r59093 webUI is attached.
For convenience, here are the last lines immediately before the reboot:
Code:
[ 5.063860] NET: Registered protocol family 17
[ 5.072862] Bridge firewalling registered
[ 5.080848] 8021q: 802.1Q VLAN Support v1.8
[ 5.089922] registered taskstats version 1
[ 5.099724] searching for nvram
[ 5.106034] nvram size = 2097152
[ 5.683289] found nvram at 1E0000
[ 5.711343] no valid UBI magic found inside mtd3
[ 5.711391] hctosys: unable to open rtc device (rtc0)
[ 5.731840] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 5.746765] Please append a correct "root=" boot option; here are the available partitions:
[ 5.763407] 1f00 1024 mtdblock0
[ 5.763413] (driver?)
[ 5.776418] 1f01 1024 mtdblock1
[ 5.776424] (driver?)
[ 5.789420] 1f02 32768 mtdblock2
[ 5.789425] (driver?)
[ 5.802444] 1f03 28672 mtdblock3
[ 5.802449] (driver?)
[ 5.815451] 1f04 2048 mtdblock4
[ 5.815457] (driver?)
[ 5.828454] 1f05 1024 mtdblock5
[ 5.828459] (driver?)
[ 5.841473] 1f06 80896 mtdblock6
[ 5.841479] (driver?)
[ 5.854479] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 5.870942] Rebooting in 1 seconds..
FWIW, I'm trying to flash via the command line but I'm not having success. Following the guide here, I've been using
Code:
tftp -i 192.168.2.1 put <webflash image filename here>
but I can't get it to "take".
I tried starting the TFTP just before power-on, I tried watching the boot sequence on PuTTY until it gets to the line where it's listening for an NMRP server (which I don't think is applicable, but I was straw-grasping) and then starting TFTP, and I tried some combinations of Reset button and TFTP launch timing, but no joy with any of it.
Joined: 06 Jun 2006 Posts: 7711 Location: Dresden, Germany
Posted: Fri Jan 10, 2025 18:37 Post subject:
MysticCobra wrote:
One of two problems fixed--woohoo! Many thanks, BrainSlayer!
I am able to install r59093 on my Netgear R6220 using the "factory-to-ddwrt" file via nmrpflash and boot successfully.
However, I remain unable to install the "webflash" version of the firmware from within the DD-WRT webUI. As documented in this previous post, (to me at least) the failure signature in the log appears identical to the problem that was just fixed.
A serial log capturing the attempt to reinstall the "webflash" version of r59093 using the r59093 webUI is attached.
For convenience, here are the last lines immediately before the reboot:
Code:
[ 5.063860] NET: Registered protocol family 17
[ 5.072862] Bridge firewalling registered
[ 5.080848] 8021q: 802.1Q VLAN Support v1.8
[ 5.089922] registered taskstats version 1
[ 5.099724] searching for nvram
[ 5.106034] nvram size = 2097152
[ 5.683289] found nvram at 1E0000
[ 5.711343] no valid UBI magic found inside mtd3
[ 5.711391] hctosys: unable to open rtc device (rtc0)
[ 5.731840] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 5.746765] Please append a correct "root=" boot option; here are the available partitions:
[ 5.763407] 1f00 1024 mtdblock0
[ 5.763413] (driver?)
[ 5.776418] 1f01 1024 mtdblock1
[ 5.776424] (driver?)
[ 5.789420] 1f02 32768 mtdblock2
[ 5.789425] (driver?)
[ 5.802444] 1f03 28672 mtdblock3
[ 5.802449] (driver?)
[ 5.815451] 1f04 2048 mtdblock4
[ 5.815457] (driver?)
[ 5.828454] 1f05 1024 mtdblock5
[ 5.828459] (driver?)
[ 5.841473] 1f06 80896 mtdblock6
[ 5.841479] (driver?)
[ 5.854479] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 5.870942] Rebooting in 1 seconds..
ahm the problem is this "Bad eraseblock 44 at 0x000000580000"
the firmware itself is correct any bad sector before 0x600000 is a big no no. i can just try to find a workaround for that shit. but a bad sector means that the sector is skipped and the block is flashed at the next erase block. which means the offsets are shifted _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
ahm the problem is this "Bad eraseblock 44 at 0x000000580000"
the firmware itself is correct any bad sector before 0x600000 is a big no no. i can just try to find a workaround for that shit. but a bad sector means that the sector is skipped and the block is flashed at the next erase block. which means the offsets are shifted
As a dumb user, I'm not certain what this means. I think it means my router has some bad areas of flash memory and that's causing or contributing to the problem. Is that correct?
What I _do_ know is that those same errors were also reported when the nmrpflash process was used. However, r59093 now flashes successfully using nmrpflash. Did you maybe make a tweak to the code that addresses the problem for my specific router with its unique defect?
From the r59093 nmrpflash serial log:
Code:
[ 2.975019] Scanning device for bad blocks
[ 2.993520] Bad eraseblock 44 at 0x000000580000
[ 3.027489] Bad eraseblock 152 at 0x000001300000
[ 3.129883] Bad eraseblock 554 at 0x000004540000
