Based on your bootlog, both flash partitions do get erased and flashed, lines 230-250
But the main difference is on line 415, where your device gives error and does not recognize the mtd partitions on the next step, like it does on jw0914 example
1.967011 armada-nand f10d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
1.979342 armada-nand f10d0000.nand: mvNfcInit() failed. Returned 16
@hnyman I believe I initially gave @MacKlappstuhl the wrong instructions, initially telling them once they flashed OEM firmware over LEDE to issue run nandboot / altnandboot, rather than reset, then the nandboot commands.
This (flashing & booting OEM firmware, then flashing LEDE) fixed nand corruption (which was the original issue) with a similar issue 18 months or so ago before a patch was developed.
.
After they issued the first nandboot command following the OEM firmware flash, it was trying to load the kernel for LEDE (4.4.92) rather than Linksys' (3.10.70), of which I attributed to me providing the wrong step order.
[ 0.000000] Linux version 3.10.70 (root@build-vm) (gcc version 4.6.4 (Linaro GCC branch-4.6.4. Marvell GCC Dev 201310-2126.3d181f66 64K MAXPAGESIZE ALIGN) ) #1 SMP Thu May 4 18:24:10 PDT 2017
Still the known errors:
[ 1.975748] armada-nand f10d0000.nand: mvNfcInit() failed. Returned 16
...
[ 4.573585] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Edit: Just for my understanding:
Someware on the NAND there is a faulty remain from a previous flash which now prevents a successful boot? Assumed it is possible to do this: Would it help to completely "copy" the NAND from another working router over the NAND in my router? Edit2: Funny, I think this is what you described with your following post. If you have the time and leisure to do so I would be very happy.
Depending on what @hnyman suggests, I can dd my WRT3200's partitions tonight and upload them for you to write, which will conclusively resolve the issues.
As I mentioned before, It's still new in the shrink wrap, as I haven't had a use for it since I received it as part of a Linksys thank you to 50 OpenWrt dev's and contributors back in April.
.
Prior to OpenWrt development ceasing there was discussion on the now ceased WRT1900AC thread about storing a dd backup of each WRT AC Series device on the OpenWrt servers, and it was on my master list of things still needing to be added to the wiki. I can shoot @tmomas an IRC message and see if he would approve that. If not, I'm sure @davidc502 may be open to it on his repo (depending if they have the space to spare on their web server)
Well, it was New Years last night and my noggin' be a wee bit fuzzy in the light of day, but it looks like things were rejigged somewhat, at least from what I see on my rango (which agrees with what was posted above); seems like that would lead to a lot of breakage though.
Just by way of a suggestion as to a possible resolution, and since it appears your device be borked at any rate; since @Ritty appears to have same layout / age of device, maybe a copy of the mtd partitions might be kindly exchanged. Not sure as to any regional concerns, and not a clue as to radio/antennae data being resident . iirc PM is available here abouts.
@jwoods I don't know why you insist on being argumentative in threads I post in, however I would recommend reading this thread in it's entirety (OP experienced a corrupted LEDE flash after receiving the device), the WRT AC Series wiki (as you've repeatedly posted factually inaccurate information), and why a serial connection is needed to troubleshoot...I'll just leave it at that and all further posts from you will simply be ignored =]
Are there any legal issues with storing and providing the files for download on OpenWrt servers?
How many MB are we talking about, per file and in total? Storage shouldn't be that big of an issue, but I'm thinking of download bandwidth/volume. OpenWrt servers shouldn't be the only place for the whole world (interested in OpenWrt or not) to download those files.
In case those experiencing this issue were not aware, to get some traction on a resolution you may want to open an issue on FS, also a query on the IRC channel might get you information in a more timely manner.
@jwoods@JW0914 You are both partly right. A serial connection is not needed on a brand new and functioning router, but after the failed flash it seems to be the only option to get it running again.
At the moment it is at least partly bricked and unreturnable, so if any of you has an idea on how to get it running again (preferred with LEDE of course, if thats not possible with Linksys software) I would be deeply grateful.
@MacKlappstuhl that sounds like my first steps with the wrt3200. The good thing is, i wasnt able to "really" damage that router. The best trick is the power on/off thing to get back to the linksys partition (and i think its not possible to override this).
Turn router off
Turn on
wait till LAN light comes on for 1/2 sec and then turn off.
Turn on
wait till LAN light comes on for 1/2 sec and then turn off.
Turn on
wait till LAN light comes on for 1/2 sec and then turn off.
I would suggest to try and get your hands on the (equivalent) mtd paritions, and start by reloading just the one that was failing (as per @hnyman post).
Making the necessary changes to the DTS for the rango, for what appears to be the changed partition layout, and generating a one off image is another possibility.
mtd9 is Layer 1 and encompasses the OEM syscfg partition, of which is only utilized by the OEM firmware, not LEDE (except for storing the config during the LEDE sysupgrade process [thanks@hnyman]) .
...except for storing the config during the LEDE sysupgrade process.
(but in any case, that partition should not play a role here.)
But in general, I am still rather uncertain if that error is about flash contents, or about general flash chip recognition as the log shows an error instead of a properly recognised NAND flash chip (like in jw0914's corresponding OEM log extract)
Then we are back to a flash chip change on the rango. Given the manufacture dates that would be possible I suppose, but why can OEM not be put back?
There is now a 4.14k based mvebu staging tree that could be tried. But I have seen no mention in the kernel change logs regarding an update on the flash around this device. And, I have a rango 4.14 image available if you want to try and see if at least it will flash, have not tried myself yet though(on rango, have it running on mamba).
Would one use mtdburn in uboot to write the bins, and if not, what would one utilize?
Marvell>> help mtdburn
mtdburn - Burn a Linux image and Filesystem` on the NAND/SPI flash.
Usage:
mtdburn [filename [interface [<dev[:part]> [File system]]]] [flash destination] [single file size on RAM]
interface : ram <load address>, tftp, or mmc/usb <interface_num> (default is tftp)
File system: FAT or EXT2 (default is FAT).
NAND default file-name is ubifs_arm_nand.image.
SPI default file-name is jffs2_arm.image.
Flash Destination: nand or spi (default is nand).
e.g. TFTP: 'mtdburn ubifs_arm_nand.image'
e.g. MMC: 'mtdburn ubifs_arm_nand.image mmc 0 FAT nand'
e.g. RAM: 'mtdburn ubifs_arm_nand.image ram 5000000 nand'