To the above point regarding the C7V2, iirc it was ~2-3 months from units manufactured with the changed flash device, and a kernel push that supported the device; check the changelog
I just noticed that official Linksys firmware release notes say that support for Winbond has been added with a recent fimware, so there has likely indeed been a change:
Firmware version: 184.108.40.206351
Release date: October 27, 2017
- Integrated WLAN driver v220.127.116.11 and FW v18.104.22.168
- Added support for Winbond and MXIC flash
The most recent firmware is 22.214.171.124168 and that has apparently fixed the problems that people had with 126.96.36.199351. Linksys forum has threads about downgrade problems. for example https://community.linksys.com/t5/Wireless-Routers/WRT3200ACM-1-0-6-184351-Firmware-and-Wireless-Lockups-5ghz-radio/td-p/1237411
The download page used to have downgrade instructions to 188.8.131.52063 still last week, but apparently 184.108.40.206168 is seen as good enough, so that those have been removed.
The similar problem that @MacKlappstuhl describes in [Solved] WRT3200ACM - Unable to flash LEDE successfully is likely related. His bootlog contained the same item.
I messed up my kernel and the recovery uboot I don't think is compatible with this Winbond chip.
When I flash it with kwboot it gets to 100% then gets stuck in a loop of outputting this:
U-Boot 2013.01 (Apr 08 2016 - 15:47:50) Marvell version: 2015_T1.QA.0p16 Boot version : v0.0.4 Board: RD-NAS-88F6820-DDR3 SoC: MV88F6820 Rev A0 running 2 CPUs CPU: ARM Cortex A9 MPCore (Rev 1) LE CPU 0 CPU @ 1866 [MHz] L2 @ 933 [MHz] TClock @ 200 [MHz] DDR3 @ 933 [MHz] DDR3 32 Bit Width,FastPath Memory Access, DLB Enabled, ECC Disabled DRAM: 512 MiB NAND: mvNfcInit() failed. 0 MiB MMC: mv_sdh: 0 raise: Signal # 8 caught DEVINFO offset == 0x7e0000 *** Warning - readdevinfo() failed, using default devinfo raise: Signal # 8 caught U-ENV offset == 0x200000 *** Warning - readenv() failed, using default environment raise: Signal # 8 caught S-ENV offset == 0x220000 *** Warning - readsenv() failed, using default senv #### auto_recovery #### [u_env] get auto_recovery == yes [u_env] get auto_recovery == yes [u_env] get boot_part == 1 [u_env] get boot_part_ready == 3 auto_recovery enabled:1, boot_part:1, boot_part_ready:3 raise: Signal # 8 caught S-ENV offset == 0x220000 [boot_count_read] block:0x220000, size:128KB, records:64
Hopefully someone can send me the kernel from the latest WRT3200ACM which is Boot version : v1.0.0 not v0.0.4.
Either that I return it...
This commit might be of interest. It was just committed to master:
Nice find. Would this commit fix the issue of it not booting the firmware. Or is there more to it?
Might explain this
I'll try another build with this patch and see how it goes. I never had serial connected so i wouldn't have spotted this change if it applies to WRT32X as well.
There is likely more to it:
There was already something similar in ipq806x and the common parts were removed from ipq806x with https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4d649ba949752f8e2fe4a4ff0c79ae3ab3124f48
But that modified ipq806x patch shows that the original patch from @chunkeey includes also specs for W25N01GV.
I guess that mvebu would also need similar specs for W29N02GV for mtd to fully work ok. (but of course, modified to match the specs of W29N02GV)
I think that in general these flash chip support patches should be in the generic patches, not per target.
I saw that but was not convinced that was the right bit, and seems you feel same from exchange and posts. I seems this would just find its way into a kernel push, rather than having to be backported. But if things are there in 4.11k, it would be easy enough for those with the issue to try out a 4.14k image.
I could try it out as well but have a corrupted bootloader
So, I assume no respite from the exchange in the other thread? Was just looking through the wiki page for the wrtpac devices and I see no mention of advising people to back-up mtd bits. Until this recent event that has not proven to be an issue(except for the early days on the mamba), but still..., and then of course there is the questionable advice to flash the same thing to both partitions.
Well I've opened an issue with ValCher1961 on GitHub
So will see if that goes anywhere.
The reason my boot loader is corrupt is because I rolled back to the previous WRT3200ACM boot loader to see if this would solve the firmware issue. I didn't know about the Winbond change at this point . So didn't think it would have been that big a of a deal.
As for flashing both partitions with the firmware I don't see any harm as you still have access to the boot loader to make any further changes.
Also not really sure how one goes about backing up the mtd data as that would have been useful.
My new WRT3200ACM was manufactured on 2017/12/26. I have compiled OpenWRT 4.9.77 from source code – not working. The official images do not work either. I see comments that in the new kernel 4.14, there should be support for the new flash chip.
- How do I compile OpenWRT with the new kernel or how do I integrate the required patches to compile and test?
- Can I compile a RAM image, then upload and boot it? How? If yes, then I will be able to extract the u-boot that @GaZaai needs.
- If anyone has ideas to test, we can experiment on my device. Serial logs will be provided as a feedback.
With the image I compiled, OpenWRT flashes successfully, then it fails to boot three times in a row and I'm back to factory. I have attached to the UART header, here are some logs:
2018-02-06 WRT3200ACM OpenWRT 4.9.77 flash and boot
2018-02-06 WRT3200ACM sysinfo.cgi
BTW when I open the case, the front part slides easily so attaching to the UART was easy, but I can't disassemble the back of the case. I bought this device for software development and I might want to solder a jTAG header one day. How do I open that?
The u-boot images were given to us two weeks ago
Found here: https://github.com/ValCher1961/McDebian_WRT3200ACM/tree/master/recovery-uboot
I just received my brand new wrt3200acm today, and it is impossible to install openwrt on it, probably this flash problem.
I have opened a bug in the tracker : (https://bugs.lede-project.org/index.php?do=details&task_id=1392).
Issue has been resolved, commit has not been pushed to master yet.
7ae59a2f288ba1cef23b20e1d36e199e8c646245 working fine!
Where is the link to the new build that fixes the winbond issue?
If you mean a snapshot image, there isn't one as the above commit has not yet been pushed to master. So currently, you either have to build an image with the commit applied, or take one from a community member. There are builds to be had by following the Stuff link found by clicking my avatar.
Does anyone know when there will be a snapshot image available for the winbond issue? Thanks.
When that commit finds its way into master. Best to ask the owner of that github/staging tree when it might get pushed.