My typo -- edited, thanks.
To be clear, the boot-counter reset works properly for the EA6350v3 without the patch!
My typo -- edited, thanks.
To be clear, the boot-counter reset works properly for the EA6350v3 without the patch!
I don't want to be rude but you are plain wrong.
Not all my job is merged. Since I've gone from this thread I've received 50+ PMs (which I will not answer) agking me to help them to revert bact to stock.
I've made a script which safely and easily can do that. It does a full check of the image (version, integrity, size, etc) and is an one-liner, it literally can't be easier than copying the image to the router and calling the script with the path to the image. That is a big value which is not upstream because it does not belong there.
Not to mention that all of we have a good wireless performance because @anders and I used another script that I made (for easily and safely testing calibration boards, again with full check and all the available calibration files from stock crafted with love to the right format, as they are not usable as-is) to get the best performance possible.
Also they were built using Linaro GCC and stripped using binutils's strip instead of sstrip, resulting in a objectively faster yet smaller binary. Not to mention the convenience of a binary that just works as expected for a home/small business router (with web GUI and such).
Let me tell you that the script for reverting to stock by itself is a big deal.
Hi @NoTengoBattery thanks for the reply, however: care to explain which of all my posts is plain wrong? and care to help us solve the issue here? the problem we see is that the images form instagram and other social network sites do not load when using the wifi. Wifi speeds are OK, and if using the LAN cable, images load fine, but we do not know for sure where the issue lies.
Has anyone managed to get the DLNA server running on this? I have the service installed and its showing under Services in the fw and my devices are detecting it, but no media is detected. Is it just a matter of creating a folder hierarchy on the storage device or is it something more involved than that?
Moving discussion of this specific issue to
Hi i've just noticed something weird.
I've not been able to update my maps on here maps (android) for a while. But today i disabled the wan6 IP6 DHCP client in the interfaces section. and now i am able to update my maps, before the app would complain it was offline.
My ISP does not provide IP6 addresses, could someone please try this on their setup to see if it fixes the instagram problem
I am also using OpenDNS addresses
Following the recomendations given to me in this community while seeking for a good cheap router with wifi ac support compatible with openwrt, I will buy this router.
I know I have to install the development snapshot.
Is there any drawback right now? Something that is not working or is working weird?
Something like wifi 5 GHz not working?
As long as I have read in this post it is working correctly.
If I have understood well, after installing the snapshot version provided in the router page, I will have openwrt with no luci web interface, and I will have to install luci afterwards.
If something goes wrong and the router bricks, is there an easy way to go back to stock firmware without soldering a serial interface?
I mean if there is a reset method that lets you upload the firmware via web or TFTP.
The documentation sends you the the generic debricking instructions, which does not help to know if you can debrick it without a serial interface (soldering in a new router will void warranty completly).
Thank you all for your work.
I will try to help in testing the router (I am not a low level developer, I cannot help in that).
Somebody told me therewas a pool for voting for inclusion of this router in the liist of compatibility hardware, but I don't find it.
Because such a pool does not exist.
There is still the issue with that for certain ISP:s, Instagram and similar applications may not work properly from Wifi on this router. I have not checked for the latest month or so but I guess the bug is still there.
Regarding reverting back there is a good script for this but unfortunately the author decided to shut down the repo some months ago. But being a big fan of @NoTengoBattery's work I of course had a copy of the repo so I can probably dig the script up if it's needed.
Thanks a lot.
I am afraid of jumping in this router and having problems, as you say.
I am deciding between this and the AVM friztbox 4040.
May be I would better wait a bit to see if the problem you comment gets solved.
If my daughters don't get access to photos in Instagram they will hang me.
Reverting back to oem firmware in case of problems is important too, but it seems to be solved with the script you mention.
It is a pity it seems a wonderfull router. I will see if I can debrick my tp-link 1043N v1.3 and install openwrt in it in order to wait a bit before buying.
What's the status of this?
I flashed the OpenWRT snapshot [http://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/openwrt-ipq40xx-linksys_ea6350v3-squashfs-factory.bin] as per https://openwrt.org/toh/linksys/linksys_ea6350_v3 and I'm struggling to configure the EA6350v3 like I configured my other OpenWRT devices, which is: Access point only, WAN as VLAN trunk, LAN 1 untagged to WAN VID n, LAN2/3 to WAN VID m, LAN4 untagged fallback port, SSIDs 1 to 4 to WAN VIDs a to d.
Does it not work b/c a) I don't understand how to do that properly for a eth0 + eth1 HW, b) it's not supported and a "VLAN on WAN port" not working marker is missing for the EA6350 (it's present for the FB4040), or c) the exact switch details aren't clear?
Is there a recommended way to configure such a scenario if eth1 is also available as a port of eth0?
At least as I understand the switch in the similar IPQ4019 and how it is configured in the DTS, one Ethernet interface is "hard-wired" to the "Internet" physical port, and the other to the other four ports. Packets that come in one of the hard-wired ports are sent only to the associated Ethernet interface. It is a challenge for some configurations (such as VLAN trunking over the Internet port).
I've poked at it quite a bit, but the qca8k / DSA code hasn't even settled down enough on mainline Linux (5.x) to convince me that it is worth trying to back port yet. Notably absent in the mainline code, last I checked, was being able to manage VLANs. within the virtual bridge.
Sounds like
Hi, I've just tried out your marvelous work, and generally it works like a charm.
But after a while I noticed that the space of my rootfs isn't as much as I expected:
The 128 MB gets split into smaller parts, which include two complete sets of firmware, each of which is 40 MB for kernel and file system, combined, 37 MB for the file system (split between ROM and overlay).
No flash layout on https://openwrt.org/toh/linksys/linksys_ea6350_v3
From the DTS
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
kernel@0 {
label = "kernel";
reg = <0x00000000 0x02800000>;
};
rootfs@300000 {
label = "rootfs";
reg = <0x00300000 0x02500000>;
};
alt_kernel@2800000 {
label = "alt_kernel";
reg = <0x02800000 0x02800000>;
};
alt_rootfs@2b00000 {
label = "alt_rootfs";
reg = <0x02b00000 0x02500000>;
};
sysdiag@5000000 {
label = "sysdiag";
reg = <0x05000000 0x00100000>;
};
syscfg@5100000 {
label = "syscfg";
reg = <0x05100000 0x02F00000>;
};
/* 0x00000000 - 0x08000000: 128 MiB */
};
The syscfg
partition could conceivably be used (0x02F00000 = 47 MB), but not easily combined with the firmware partition.
Thanks a lot! I later found this dts file and a more detailed flash layout of WRT1900ACS.
After about 20h's investigation, I finally made it to use the whole NAND and not recompiling the openwrt.
dd if=/dev/ubi0_0 of=/tmp/ubi0_0.img
dd if=/dev/ubi0_1 of=/tmp/ubi0_1.img
setenv auto_recovery no
save
setenv mtdids
setenv mtdparts
setenv mtdids nand1=spi0.1
mtdparts add nand1 0x8000000 kernel
mtdparts add nand1 0x7d00000@0x300000 rootfs
(note the nand1 here is from the output of nand info)
ubi part rootfs
ubi create rootfs 0x26c000
ubi create rootfs_data
You can see the following output if successful:
(EA6350v3) # ubi create rootfs 0x26c000
Creating dynamic volume rootfs of size 2539520
(EA6350v3) # ubi create rootfs_data
No size specified -> Using max size (122658816)
Creating dynamic volume rootfs_data of size 122658816
(EA6350v3) # ubi info l
UBI: volume information dump:
UBI: vol_id 0
UBI: reserved_pebs 20
UBI: alignment 1
UBI: data_pad 0
UBI: vol_type 3
UBI: name_len 6
UBI: usable_leb_size 126976
UBI: used_ebs 20
UBI: used_bytes 2539520
UBI: last_eb_bytes 126976
UBI: corrupted 0
UBI: upd_marker 0
UBI: name rootfs
UBI: volume information dump:
UBI: vol_id 1
UBI: reserved_pebs 966
UBI: alignment 1
UBI: data_pad 0
UBI: vol_type 3
UBI: name_len 11
UBI: usable_leb_size 126976
UBI: used_ebs 966
UBI: used_bytes 122658816
UBI: last_eb_bytes 126976
UBI: corrupted 0
UBI: upd_marker 0
UBI: name rootfs_data
UBI: volume information dump:
UBI: vol_id 2147479551
UBI: reserved_pebs 2
UBI: alignment 1
UBI: data_pad 0
UBI: vol_type 3
UBI: name_len 13
UBI: usable_leb_size 126976
UBI: used_ebs 2
UBI: used_bytes 253952
UBI: last_eb_bytes 2
UBI: corrupted 0
UBI: upd_marker 0
UBI: name layout volume
tftpboot 82000000 test_0_0.ubi
ubi write 82000000 rootfs 26c000
tftpboot 83000000 test_0_1.ubi
ubi write 83000000 rootfs_data 1e84000
# First we backup the old bootart
setenv partbootargs_old $partbootargs
# Then we overwrite with new one
setenv partbootargs_old "init=/sbin/init $mtdparts ubi.mtd=11,2048 ubi.block=0,0 root=/dev/ubiblock0_0 rootwait ro"
save
run bootpart1
# In failsafe console
mkdir /tmp/ubi01
mount -t ubifs /dev/ubi0_1 /tmp/ubi01
mkdir /tmp/ubi01_bak
cp -a /tmp/ubi01 /tmp/ubi01_bak
umount /tmp/ubi01
ubiupdatevol /dev/ubi0_1 -t
mount -t ubifs /dev/ubi0_1 /tmp/ubi01
cp -a /tmp/ubi01_bak/* /tmp
umount /tmp/ubi01
(I'm not that familiar with cp command and please adapt your command accordingly)
Use of dd
to copy to or from NAND flash can lead to disasters.
NAND has both "data" and "metadata" stored in its cells. Often there is a block of 2048 data bytes, then 64 or 128 metadata bytes, which include the error-correction (ECC) data and the bad block marks (BBM).
Using dd
to copy from NAND means that the ECC may not be applied to the raw bits. It is common for at least a few bits of NAND to be "flipped" and the ECC is used to correct those, typically up to 8 bit errors per block.
Overwriting the metadata can easily result in the NAND and its driver considering the flash bad. Anything other than 0xff in either of the the BBM positions will mark the block as bad. Excessive errors perceived because of corruption of the ECC can result in the driver marking the block as bad.
NAND should only be manipulated with tooling that "understands" NAND, such as mtd
and nand-utils
.
Yes, the above appears to manipulate the UBI-layer devices, but even there, UBI manages its own set of metadata (including wear monitoring and bad-block marking and reservation), which is influenced by the underlying flash's state.
Second problem is that changing the partitioning through bootargs is dangerous, at best. Many OpenWrt kernels ignore some or all of the bootargs, or "mangle" them in very specific ways.
Thirdly, you've disabled the dual-firmware feature and automated fall back. If you look at the source, you'll see that sysupgrade
flashes the "other" firmware version, autorecovery is set, and that the selected firmware is "flipped" as well. (See /lib/upgrade/linksys.sh
)
Also, at least on the similar EA8300, the U-Boot TFTP flash mechanism has limits on the size of and location of the images it flashes. This repartitioning would require further changes to the U-Boot system to be robust. It also likely makes it very difficult for anyone to "return to stock" without either a very complex process or serial access to U-Boot. U-Boot also expects the kernel and alternate kernel to be in specific locations for boot. Further, any corruption of the U-Boot environment will result in it being recreated from compiled-in defaults, likely leading to an unbootable device.
I don't have any serious qualms about properly repartitioning the device through the DTS for personal use, or someone working through all the issues of changing the partition sizes and submitting changes for review. Those issues include at least:
Obviously you know there's UBI layer, so in fact everything about the NAND should be forgotten
To some extent I believe that you also mistook something: I didn't use dd on the NAND or raw UBI device. Instead I used it on a UBI Volume.
For reference: https://linux-mtd.infradead.narkive.com/wDPUK8NR/correct-way-to-flash-an-mtd-partition-using-mtd-utils
The UBI layer is like a harddisk (or controller), the UBI volume is simply a logical volume on it. There's nothing related to the UBI volume metadata as it's an internal structure and is stored in 2 PEBs as a separate volume. Just like everyone uses dd to backup their file system on desktop computer, here we can also do so as UBI is an robust abstract layer above the fragile little NAND.
For the bootargs, I carefully reviewed the bootlog and the source code and patches of mtd partition parser in the OpenWRT source tree, which shows that the kernel is accepting cmdlineparts before the fixed-partitions, and that's why I can pass them through the bootargs.
As for the repartitioning, I've known it's quite dangerous, and considered that the sysupgrade will erase everything on the data partition, I won't needed to use this feature and will use U-Boot or mtd/ubiupdatevol instead. It's simply a trade-off. But it's really my fault not to mention it in my previous post (Sorry I forgot).
When it comes to U-Boot, there's nothing to worry. Command will fail immediately if we choose wrong nand (because the size of NAND is different). As long as we are not making too many mistakes, the U-Boot won't be affected as it's safely stored in another 2MiB NOR NAND.
When it comes to the return to stock, it is also a trade-off. In fact, if anyone can follow the instruction above, he must have a serial connection, which is a prerequisite, so that shouldn't be a problem at all.
As for the compiled default, I admit that the U-Boot hardcoded the location of kernel in its partition table, which can be seen from smeminfo. However I disabled the autorecovery. As long as we are not using the sysupgrade function, nothing dangerous will happen
PS: I assumed that the instruction above is for expert user only, as it needs a serial connection. I'll change the post to add a warning.
Thanks, greatly appreciated.
Many readers here are not experts. Many blindly follow instructions, especially when it promises "more for free" to them, resulting in bricked devices or loss of unrecoverable data (such at ART and other cal data).
The subtle difference between raw NAND, UBI device, and file system volume is one that most would miss, especially if used in a different context. (Happens all the time, "But why doesn't it boot? I saw someone with a Model X do it, so I followed what they said for a Model Y.")
NAND is particularly sensitive as its metadata is exposed through its interface. In contrast, a hard drive or "real" SSD hides it all in the controller (both media-coding level and ECC on top of that), behind the SATA, USB, ... interface that the OS generally sees.
Haha the UBI can refer to UBI layer, UBI volume and UBIFS, which is quite confusing. I'm also quite grateful for your pointing out. I'll pay more attention and add warning and reference in my future post.
Talking with you also makes me have a more thorough understanding towards UBI and NAND