Possible issue with mt7621_netgear_sercomm_bzv.dtsi

I've decided to make a post here rather than the issue tracker because I'm new to this and I'm not sure I'm right.

Anyways, here's what's been going on. I have a NETGEAR Nighthawk AC2400, which according to this commit, is equivalent to the NETGEAR R6700 V2. So I went and tried to flash the factory image, but all I got was a bootloop. Using nmrpflash, I recovered my router and found that all my settings had remained unchanged (not sure if this is normal). Now, using telnet on the stock firmware, I took a look at my routers partition table and found that the kernel partition is a different size than what is listed in mt7621_netgear_sercomm_bzv.dtsi.

So I see two different possibilities. The first is that not all of these routers have the same partition sizes for whatever reason, which seems plausible after reading this thread. The other possibility is that my router is not actually equivalent to the R6700 V2.

I haven't actually confirmed that the partition size is what caused my router to be unable to boot OpenWRT, but it seems highly likely. If it turns out to be the case that my router is equivalent to the R6700 V2, I've been looking at these two patches which might fix the issue (1 and 2).

If anyone more knowledgeable could chime in that would be great!

edit: forgot to post the picture of the parition table.

That shouldn't matter. I think MT7621 uses a dynamic kernel/rootfs splitter on OpenWrt. OpenWrt only touches the parts of the flash that the OEM usually allocates to the actual firmware, and it doesn't touch any configuration partitions and whatnot to make it possible to revert to OEM. The way OpenWrt looks at the usable space is e.g. 8 MiB for OpenWrt, and it splits that into kernel + rootfs + writable overlay at its own discretion, as long as it can squeeze that into those 8 MiB.

You'll need serial to see what's going wrong with the OpenWrt boot process.

Hmm, well that would explain that.

I want to try to adjust the partition location and make a build myself before I try serial (I hate serial lol). Is it just a matter of downloading the latest RC ImageBuilder, making changes, and then building? Or do I need to add packages and things like that?

Better get serial first instead of hacking the DTS. There's no added value in hacking partition sizes if you aren't sure that's the issue. You might be seeing bad blocks as well, it being NAND.

You can still load a ramdisk image from serial if you'd like, boot that and see if the same issue pops up, before trying to actually flash.

1 Like

Yeah I guess, that'd be best. I actually did just try adjusting the DTS, but it didn't resolve the issue. So rather than just try and figure out what the issue is blind, I'll get the serial out.

Okay, so I tried my best to get serial working, but it just wouldn't. I'm sure I have the pinout correct (checked with multimeter), but no matter what I do, I get nothing from the TX. I'm only supposed to connect RX, TX, and ground right? The TX hole seemed to already have some solder filling it up, so maybe that's the problem?

Anyways, I gave up on that and decided to try those patches I linked in my first post. It did end up booting and it's currently running stable, so it seems the issue might have to do with bad blocks. The only remaining issue is that I don't think I built the image correctly, as it came out a little more than a megabyte smaller than the official build, and it's missing the wireless section in Luci...

Is there any official way to get around bad blocks?

You're right, you shouldn't connect VCC. Maybe there's some connection that isn't fully soldered (intentionally by the ODM to make serial access more difficult). Wouldn't be the first time.

The patch set you used is the only way I know of to make use of the bad block table. I think changes were requested from the author before it could be accepted, so it's been in limbo since.

Right, I see now those changes that were requested. Is there any way I can make those changes? Or does it have to be the original author? And on that note, would it be considered rude to ping the author here?

Regarding the serial console not being fully soldered, is that something I can take care of too?

Sure, you can. There's no monopoly on the code. And it's not considered rude to ping the author, just give/keep credit when you're sending in revised patches.

Maybe @svanheule can comment on the serial, he has a R6800 as well.

Looking at my R6800, I see that I had to bridge R24 and R26.


Oh I see, so it's quite literally not connected. Well that's a first for me. I see now that it's on the wiki page for the R6800. Would it be silly to think that it'd be the same for the R6700 V2?

Also, pinging @janh. I want to get your patch set moving (the Netgear/Sercomm partition parser). I see that it was requested for you to upstream the parser. Have you made any progress on that? I've never actually contributed to Linux before, but I can try to do it if you're not able to.

No, I didn't make any progress on that, and I don't think I'll do so in the near future. If you want to work on this, feel free to do so!

If you aren't aware, there are also others who want to use the partition parser for a new device: https://github.com/openwrt/openwrt/pull/4108

Going from the (low resolution) pictures in the FCC documents, it seems likely that it will be the same for both devices. If you are unsure, you can always post a picture of the PCB around the serial header.

1 Like

Thought I would just let you know, I just installed the snapshot on an NETGEAR AC2400 R7350 with zero problems. Used nmrpflash, had to reboot more than once, but interface came up straightaway, ssh worked the first time and luci installed first try.