[Solved] WRT3200ACM - Unable to flash LEDE successfully

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.

Did this. It reads from the alternate partition:

NAND read: device 0 offset 0x5a00000, size 0x600000
6291456 bytes read: OK

And its using the Linksys kernel:

[ 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)

1 Like

Gotta ask after the post by @MagicSimi above, when you are in uboot and run mtdparts, what do you see now.

Marvell>> mtdparts

device nand0 armada-nand, # parts = 11
#: name size offset mask_flags
0: uboot 0x000000200000 0x000000000000 1
1: u_env 0x000000020000 0x000000200000 0
2: s_env 0x000000040000 0x000000220000 0
3: devinfo 0x000000040000 0x0000007e0000 0
4: sysdiag 0x0000001e0000 0x000000820000 0
5: ubifs 0x00000a000000 0x000000a00000 0
6: kernel 0x000005000000 0x000000a00000 0
7: rootfs 0x000004a00000 0x000001000000 0
8: alt_kernel 0x000005000000 0x000005a00000 0
9: alt_rootfs 0x000004a00000 0x000006000000 0
10: syscfg 0x000005600000 0x00000aa00000 0

active partition: nand0,0 - (uboot) 0x000000200000 @ 0x000000000000

defaults:
mtdids : none
mtdparts: none

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.

If you are unable to flash a working OEM again:

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.

At this point, your confidence in a "working product" seems misplaced.

None of this should be necessary for a brand new router.

However, if the OP totally bricks the router with all these mental gymnastics, it will be un-returnable...and then will need to purchase a new router.

I'm sure you'll be willing to donate that brand new "still in the shrink wrap thank you router" if that happens.

It's the OP's call...

@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 =]

Not threads...just you.

I don't need to read multiple threads and wikis to know that a brand new device should not need "serial connection troubleshooting".

I know this gives you a thrill, but it puts others devices at risk.

Your condescending attitude to members here is notable, and will not go unchallenged.

Back on topic.

1 Like
  1. Are there any legal issues with storing and providing the files for download on OpenWrt servers?
  2. 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).

  1. Turn router off
  2. Turn on
  3. wait till LAN light comes on for 1/2 sec and then turn off.
  4. Turn on
  5. wait till LAN light comes on for 1/2 sec and then turn off.
  6. Turn on
  7. wait till LAN light comes on for 1/2 sec and then turn off.
  8. Turn on and wait Linksys OS has booted.
  9. Log-In to the WEB-UI -->Connectivity-->Update router-firmware -->manually
    and choose the downloaded file (i would recommend this --> https://downloads.lede-project.org/snapshots/targets/mvebu/generic/openwrt-mvebu-linksys-wrt3200acm-squashfs-factory.img) (there is no need to rename that file)
  10. After flashing and reboot connect via ssh (putty or something else) to the router (must have internet access) and run
    opkg update
    opkg install luci
  11. After that you can access the lede (luci) webinterface via browser

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.

WRT3200ACM mtd5 - mtd9 bins

  • This can be viewed in Flash Storage Layout

    • mtd5 is Layer 2 and encompasses Layer 3

      • Layer 3: The primary kernel image and mtd6
    • mtd7 is Layer 2 and encompasses Layer 3

      • Layer 3: The alternate kernel image and mtd8
    • 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'