I have a r7800 that won't boot anything from 18.06 (reboot loop), but 17.01.6 and oem work. I am using tftp flash for all, but did try from oem web interface the first time, didn't work. I wonder if because of the kernel part increase that maybe the area that it expanded into is bad. Can this be tested somehow?
At least a couple commits in early 2018 that look like they were there to improve the device's usability and fix sysupgrade. You might want to carefully read the sysupgrade/install instructions.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fb8a578aa7
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7b74b40fe9
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=dc50694bd1
(This is not exhaustive!)
$ git log openwrt-18.06 -- target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8065-r7800.dts
will show you what has changed with the file that defines the hardware and partitioning for the R7800, at least for Linux 4.14.
commit 66871d9c62
Author: Stefan Lippers-Hollmann <redacted>
Date: Fri May 18 03:00:41 2018 +0200
ipq806x: increase kernel partition size for the Netgear r7800
Starting with kernel 4.14 and gcc 7, the kernel doesn't fit into the
2 MB reserved for the kernel partition by the OEM firmware anymore.
[...]
suggests that the MTD parts from 17.01.6 won't work (and aren't transferrable, in general)
Thank you Jeff, the added info should help increase my understanding anyway. However, I guess I should have been a little more clear. I am not trying any sysupgrade images, only TFTP of Netgear and OpenWRT factory images.
Booting 17.01 should show the list of bad blocks in your NAND by absolute address. Then find which partitions they are in.
2 Likes
Thank you much, it seems my guess was correct, there is a bad block at 0x000001760000 and if I'm not misunderstanding the map right after:
0x000001480000-0x000001680000 : "kernel"
0x000001680000-0x000003480000 : "ubi"
on an image with the kernel part enlarged that block would fall right in the kernel.
Now the question is, can I do anything about this or does this mean I'll never be able to use newer images?
Current kernels are larger than 2 MB, making that partition larger (as in currently 4 MB) is unavoidable, given that your badblock is even below the 3 MB mark, it's getting hard to avoid it.
Currently (master) the kernel has a size of ~2'321'168 bytes, which means you might patch your partitioning map (DTS) accordingly to avoid the bad blocks (leaving it reserved) and starting the rootfs behind the failure area, but that requires custom built/ patched firmware images - and I wouldn't quite call it a solution either.
2 Likes
That is what I thought, but I was unsure. Thank you for confirming, this stuff is still a bit new for me. Repacked and returning it.
2 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.