Btw, Cudy has released today a new OpenWRT firmware that should work.
My apologies... I've tested today the updated firmware and seems to fail same way. I don't understand what Cudy is doing! @rmax can you install the latest OpenWRT from Cudy and post the serial console log? If you could test in a devices with the XM25QH128C and other with W25Q128 would be great.
How'd you tell that this firmware is new? It doesn't look new to me. The zip file was created 2022-04-07, but the firmware binary in it has a time stamp from 2020-07-16. I don't think it makes sense to test it at this point.
BTW, I cannot currently test anything on a device with XM25QH128C, because I only have the single device I converted to W25Q128 and don't plan to revert that.
Cudy wrote me an email a few days ago to notify they had fixed it and uploaded the new firmware to their website... I just trusted them. My fault. This people is not trustable at all, as we can see. I didn't see the file date. I've check it and that file is exactly the same available from Cudy about six months ago, so they probably picked the wrong one or whoever knows what happend. I give up. I have my Cudy running and you too... the best advice for other is to avoid Cudy.
I wouldn't give up on them just yet!
After all they at least try to be a good player by providing an official path from their firmware to OpenWrt and their support is very responsive and really tries to help, but it might need some insistance to get them to do what you want, as I experienced with the purpose and pinout of the two mysterious pin headers.
I've just sent them another email suggesting that they might have posted the old image by accident and asking them to check it again and provide a working image. Let's see ...
They haven't replied to me yet, but I just noticed that they changed the OpenWrt image again. The zip file now has a time stamp of last Friday and the image inside is the same from 2022-02-02 that they already had before switching back to the (initial?) one from 2020.
I had also wrote them and they answered me with that file attached asking me to try it. I saw it was the one from February. It look they also update it in the web site. Let's think it's just the nth mistake in a row but they really want to fix it. I replied them back to warn them.
I just checked their download page again, and it seems they removed the OpenWrt images for all their routers, not only the WR1300.
Update: The downloads are still reachable via a direct link, but it is not linked from the normal download page anymore.
I just saw that OpenWRT now has support for the XMC XM25QH128C which is used in the "newer" versions of the Cude WR1300 (and of course I own one of them ;-)). Therefore I compiled a new version of OpenWRT for this device myself and also tried to use OpenWRT 22.03.0-rc1(which contains support for the chip according to the changelog). But none of them made the device worked.
I tried to the flash both of the images via TFTP with wireshark running in parallel that shows that a TFTP-download was done. After a reboot of the device the stock-firmware was still in use.
Does anybody know what went wrong here or can give me some advice on how to get rid of the stock firmeware?
Hi Ilsa, are you aware that their firmware is signed and won't accept OpenWrt right away? You need to flash their OpenWrt image first (which they meanwhile retracted from the public) and from there you can sysupgrade to a current OpenWrt. But their OpenWrt images were having problems as you can read in this thread and the other one I referenced in my opening post.
A few days ago they sent me a new OpenWrt image that they claim to finally fix the problems with the new flash part, but I cannot test it on my device anymore, because I replaced the flash. They also claimed that original OpenWrt won't work with the new flash device, but I think that is not true anymore as you already found out.
I could give you the OpenWrt image they sent me, if you want to give it a try and I would be interested to hear about the results, but there is no guarantee that it will work for now. You should be prepared to end up with a soft or even hard bricked device like I did in my first attempts. I would recommend that you attach a serial console before making any attempts, so that you can see what's going on on the device, and it would also be good to save a copy of the whole file after flashing Cudy's OpenWrt image before you attempt to flash a current OpenWrt. With that copy you could either repair the flash chip that came with the device or replace it with a different one like I did.
Hi @rmax , thanks a lot for the fast response. I definitely would like to give it a try (OpenWRT was the main reason why I bought this device some time ago). Therefore it would be great if you could send me the file. I'll give you feedback as soon as I tried to flash it.
Any news on that?
ilsagold has meanwhile been able to switch to stock OpenWrt via the OpenWrt image I got from Cudy, but stock OpenWrt still fails to find the root file system when booting. I'll investigate that further, but it might take a few weeks until I get to it. If someone else wants to step in in the meantime, feel free.
@ilsagold I think it would be good if you could post the findings and log excerpts from your latest PM here, so that others can pick it up from there.
I guess that support for XM25QH128C in the kernel is still incomplete and leads to the issues with finding the root FS on the chip, whereas the initial ram disk works fine, that got loaded by U-Boot. This guess is based on the fact that current images have no issues on my WR1300 where I just replaced the flash chip with a W25Q128.
Here is a short sum-up of the findings.
Next to the image provided by @rmax I compiled an image from git-tag v22.03.0-rc2 which I reference as "compiled image" below.
Booting the image from @rmax everything worked and I got the following kernel-messages:
[ 2.530089] Creating 7 MTD partitions on "spi0.0": [ 2.534889] 0x000000000000-0x000000030000 : "u-boot" [ 2.540835] 0x000000030000-0x000000040000 : "u-boot-env" [ 2.546986] 0x000000040000-0x000000050000 : "factory" [ 2.552925] 0x000000fd0000-0x000000fe0000 : "debug" [ 2.558589] 0x000000fe0000-0x000000ff0000 : "backup" [ 2.564479] 0x000000ff0000-0x000001000000 : "bdinfo" [ 2.570306] 0x000000050000-0x000000fd0000 : "firmware" [ 2.576504] 2 uimage-fw partitions found on MTD device firmware [ 2.582443] Creating 2 MTD partitions on "firmware": [ 2.587391] 0x000000000000-0x0000001d8246 : "kernel" [ 2.593178] 0x0000001d8246-0x000000f80000 : "rootfs" [ 2.598902] mtd: device 8 (rootfs) set to be root filesystem [ 2.604688] 1 squashfs-split partitions found on MTD device rootfs [ 2.610896] 0x000000c20000-0x000000f80000 : "rootfs_data" [ 4.082370] mtk_soc_eth 1e100000.ethernet: loaded mt7530 driver
Booting the compiled image the boot failed with a:
[ 1.586751] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
The corresponding kernel-log for the compiled-image was the following:
[ 0.649528] 7 fixed-partitions partitions found on MTD device spi0.0 [ 0.655850] Creating 7 MTD partitions on "spi0.0": [ 0.660644] 0x000000000000-0x000000030000 : "u-boot" [ 0.666551] 0x000000030000-0x000000040000 : "u-boot-env" [ 0.672810] 0x000000040000-0x000000050000 : "factory" [ 0.678828] 0x000000050000-0x000000fd0000 : "firmware" [ 0.693748] 0x000000fd0000-0x000000fe0000 : "debug" [ 0.699658] 0x000000fe0000-0x000000ff0000 : "backup" [ 0.705554] 0x000000ff0000-0x000001000000 : "bdinfo" [ 0.760742] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
So it looks like the kernel- and rootfs-parts of the "firmware"-partition are not recognized which then results in the kernel-panic as no rootfs is found.
The kernel-log of the compiled-image in regards to the flash-chip is the following:
[ 0.637443] spi-nor spi0.0: Failed to parse optional parameter table: ff84 [ 0.644404] spi-nor spi0.0: XM25QH128C (16384 Kbytes)
Please don't hesitate to contact me in case you need some more logs or other stuff I can test on the device.
Do you see any similar messages about the flash chip in the boot log of the cudy image?
ff84 message indicates a failure in the
spi_nor_parse_4bait() function in
drivers/mtd/spi-nor/sfdp.c of the kernel source tree. The table that is to be parsed here is described in the datasheet of the XM25QH128C, but I haven't yet compared the documentation with the parser to find where it might be failing. We might need to add some debugging output to that function to find out if the table in the flash looks the same as in the documentation and where exactly the parser fails, and if it is the parser's or the chip's fault.
OTOH, failing to parse an optional data structure should not result in the whole device to fail, so it might even be that the device failure is totally unrelated to parser failure.
It seems like the whole message (maybe also parts of the driver?) is different. Here is a "full" snippet containing the message(s) regarding the flash-chip as well as the partition-layout from the provided Cudy-OpenWRT-image (apart from this there was no text matching "XM25" in the kernel-log):
[ 2.504903] MediaTek Nand driver init, version v2.1 Fix AHB virt2phys error [ 2.512238] spi-mt7621 1e000b00.spi: sys_freq: 220000000 [ 2.518459] m25p80 spi0.0: XM25QH128C (16384 Kbytes) [ 2.523501] 7 fixed-partitions partitions found on MTD device spi0.0 [ 2.529823] Creating 7 MTD partitions on "spi0.0": [ 2.534623] 0x000000000000-0x000000030000 : "u-boot" [ 2.540434] 0x000000030000-0x000000040000 : "u-boot-env" [ 2.546634] 0x000000040000-0x000000050000 : "factory" [ 2.552600] 0x000000fd0000-0x000000fe0000 : "debug" [ 2.558205] 0x000000fe0000-0x000000ff0000 : "backup" [ 2.564128] 0x000000ff0000-0x000001000000 : "bdinfo" [ 2.569928] 0x000000050000-0x000000fd0000 : "firmware" [ 2.576170] 2 uimage-fw partitions found on MTD device firmware [ 2.582107] Creating 2 MTD partitions on "firmware": [ 2.587056] 0x000000000000-0x0000001d8246 : "kernel" [ 2.592853] 0x0000001d8246-0x000000f80000 : "rootfs" [ 2.598577] mtd: device 8 (rootfs) set to be root filesystem [ 2.604372] 1 squashfs-split partitions found on MTD device rootfs [ 2.610581] 0x000000c20000-0x000000f80000 : "rootfs_data" [ 4.082150] mtk_soc_eth 1e100000.ethernet: loaded mt7530 driver
Could it be that the Cudy-guys implemented a driver for the flash on their own which is closed source?