- Flashed DD-WRT 08-30-2024-r58244 onto kernel with mtd
- Switched boot partition to kernel
- No DHCP and no access to router
I did some calculations with the hex values and I believe the reg value for nvram on ipq8174-mx4200.dtsi was meant to be 0x13b80000. Hopefully we'll get some feedback about that at some point.
Thanks. I thought that using GitHub to send PRs was some sort of modern sacrilege in this project.
I still don't know what to make of this finding and whether it will be the fix that I need or it will be something else. Not being able to build your own firmware is a bit frustrating when you want to try different things and to contribute. But never mind, it's more of a hobby than anything else.
Joined: 08 May 2018 Posts: 16747 Location: Texas, USA
Posted: Fri Sep 20, 2024 14:17 Post subject:
All I can say at the moment is test today's release and report back. I don't know if the "fix typo" in driver repository log @ https://svn.dd-wrt.com/changeset/58385 was to fix the problem or not.
Hi guys. Ive also had troubles flashing the v2 (SPNMX42)
I decided to try again today after reading this post. Trying build number 08-30-2024-r58244 reported working on the post below, results in a faild boot. Led light stays BLUE.
Attached is the serial logs. Hope it can help resolve the issue.
The first log is a stock boot from factory reset.
The second was taken as the device was being flashed with ddwrt and the other is on a reboot with the failed flash.
0x000013c80000-0x000013e80000 : "sysdiag" <-- THIS ADDRESS SHOULD BE NVRAM. 13c80000
0x000013e80000-0x000013f00000 : "0:ETHPHYFW" WHICH BREAKS EVERYTHING BELOW THIS INCLUDING THE MISSING
0x000013f00000-0x00001f700000 : "syscfg" DD-WRT PARTITION
0x00001f700000-0x000020000000 : "0:WIFIFW"
So it appears all the addresses including nvram and below is just plain wrong. _________________ - Linksys EA8500: I-Gateway, WAP/VAP 5ghz only. Features: VLANs, Samba, WG, Entware - r60xxx
- Linksys EA8500: 802.11s Secondary w/VLAN Trunk over 5ghz - r60xxx
- Linksys MX4300: 802.11s Primary w/VLAN Trunk over 5ghz. 2.4ghz WAP/VAP only - r60xxx
- Linksys MX4300: (WAP/VAP (7)) Multiple VLANs over single trunk port. Entware/Samba r60xxx
- Linksys MR7350: WDS Station for extended Ethernet r60xxx
- Linksys MR7500, MX8500: None in production. Just testing. r60xxx
- OSes: Fedora 40, 10 RPis (2,3,4,5), 23 ESP8266s: Straight from Amiga to Linux in '95, never having owned a Windows PC.
- Forum member #248
Joined: 08 May 2018 Posts: 16747 Location: Texas, USA
Posted: Fri Sep 20, 2024 20:50 Post subject:
That, or altkernel and altrootfs end at the wrong point. Either way we're still waiting for word back from the top of the food chain. FWIW, this is the file for OpenWRT:
Attached is a diff file of OpenWRT's target/linux/qualcommax/files/arch/arm64/boot/dts/qcom/ipq8174-mx4200.dtsi and DD-WRT's src/linux/universal/linux-6.6-nss/arch/arm64/boot/dts/qcom/ipq8174-mx4200.dtsi
I am assuming that the builds available to download are linux-6.6-nss
Changes are:
- a new include file (ipq8074-nss.dtsi)
- different boot arguments appended
- changes on partitions as we have seen
- changes to port labels
The boot arguments could be at play here too.
@lexridge looking at the differences between the dtsi files I don't arrive at the same conclusion re the cascade errors.
The reg values of alt_kernel and alt_rootfs are originally <0xa680000 0x9600000> and <0xac80000 0x9000000> thus ending at 0x13c80000 (they overlap, that's Linksys' doing). They become <0xa680000 0x9500000> and <0xac80000 0x8f00000> thus ending at 0x13b80000. That creates 1MB of space for the nvram. Then comes what we believe is a typo and the reg value of nvram should be <0x13b80000 0x100000> instead of <0x12b80000 0x100000>.
The following partitions are the same until we arrive at syscfg. That is originally <0x13f00000 0xb800000> ending at 0x1f000000. It becomes <0x13f00000 0xb100000> ending at 0x1f000000 and freeing 7MB for the oops partition which is <0x1f000000 0x700000> ending at 0x1f700000 as it should.
So, apart from the typo in nvram, everything else seems fine to me. I don't know enough to comment on how safe it is to take space on existing partitions. I imagine that these have a lot more than it's needed and taking a small portion of their end is fine.
I opened ticket #7792 and managed to get the attention of the developer on another forum. I promise I am not stalking him, we just happened to end up commenting in the same post .
I tested the previous builds but no joy. I'll see when the next one comes out hopping that the nvram offset fix leads to a bootable router. It'd be great if someone with UART access tests the next one too. At least the spamming 'cannot open /dev/nvram' should go but we may come to the next hurdle. Hopefully not!
.