Hi all
Just a quick note to anyone testing the builds for this device.
As this device has two partitions i always reboot with advance-reboot to the partition i want to keep before flashing any new build.
That way my first partition is the one i use daily and the alternate one is the test one.
You are right, @imi2003.
@martin8 First of all we cannot discuss about when OpenWrt itself will be stable. That's off topic. The device running OpenWrt (my prebuilts to be precise) is performing well and even if not bug free, it's pretty stable at this point (just some minor annoyances).
Answering to @imi2003 I just want to clarify that my build includes a script for reverting back to stick at any time. The only prerequisites are a shell with root access and an original Linksys firmware image (downloadable from the device's support page).
Edit: typo, change stick with stock
And a question for all of you: Shall we change the device name to Civic?
Also an announcement: I've sent the calibration files to upstream and infradead.
Hello, all.
I just published a new prebuilt. I did this instead of waiting the next week because this has an important change that you may want to have as soon as possible. Some changes are as follows:
- New apps
- RP PPPoE ([1] disabled by default)
- Ntftables QoS ([1] disabled by default, useful for bandwidth limit if you need or want a WiFi guest network with limited throughput. Built-in because it requires two kernel modules and those are not easy to install as I don't have a server
.)
- Special thanks to @imi2003 and @anders in the release notes
- Rebuilt from scratch using the latest released Linaro Toolchain
- And the important change: synced with master, this commit: pq-wifi: update ipq-wifi for Linksys EA6350v3
- [1] Fixed minor annoyances with Dropbear and OpenSSH in Safe Mode
- Fixed uhttpd/OpenSSL (https works on Safari but not on Chrome and I don't know why)
Not a full changelog.
[1]: The files changed in the running firmware will not be updated with the versions in the image: the changes are only effective on Fail Safe mode and after the first boot.
1 Like
No.
Linksys calls it EA6350, so we call it EA6350 too.
That is false. Linksys call this device Civic.
1 Like
There's some question as to what the internal at the board level should be called (such as DTS), but, from an end-user perspective, I'm of the opinion that they should be "human readable" for someone trying to find the right firmware to flash, as well as to configure in the build tools.
Linksys, as almost all OEMs, uses code names for their devices.
I'm not saying to change the commercial/user friendly name (which is EA6350v3) to "Civic". I'm telling about changing the internal name to Civic.
As an example, take a look at Linksys Cobra.
For sake of completeness: Advanced Reboot.
That is false. 
See https://www.linksys.com/us/p/P-EA6350/
See https://www.linksys.com/us/support-product/?pid=01t80000003cgXOAAY
See https://www.linksys.com/us/support-article?articleNum=148481
The download link point to http://downloads.linksys.com/downloads/firmware/FW_EA6350v3_3.1.10.191322_prod.img
(similar for v1 + v2)
The Linksys userguide calls it EA6350
wikidevi calls it EA6350 too:
https://wikidevi.com/wiki/Linksys_EA6350_v3
Why on earth should the EA6350 be called Civic?
amazon.com does not find anything for "Linksys Civic"
amazon.de dito:
You are not understanding.
I kindly ask you to understand my statement first. Thank you.
Sorry, but I really don't understand what you want to achieve by renaming the device that is widely known as EA6350 to "Civic".
Can you please explain more detailed?
@jeff understood the point correctly.
Please take a look at both links that I provided. One thing is the commercial name (EA6350v3) and the other is the internal name (civic).
In the source code all Linksys products are called by both names. This device is the exception. The change will make the source code more consistent.
From personal communication to me in reference to the EA8300 "Dallas"
As described at [1], please don't use "linksys,ea8300", but "linksys,dallas". The ea6350 should have used linksys,civic as well -- will likely get around poking people about these again.
There are the "internal" names in the code, such as within the DTS files, and then there is the "public" name that we choose for things like the firmware name and display in menuconfig screens.
(I have not committed to one path or the other on this, nor pursued it further at this time.)
Don't feel involved, @jeff. My comment was that you understood. Nothing else.
I really think that we shall change the board name to civic (my auto-correct put that word on caps). Of course, the device will be always Linksys EA6350v3.
@chunkeey, I sorry to tag you here. Can we get your opinion?
We could have saved some postings if you had made clear that you were talking about the source.
Call it whatever you like in the source code, as long as the resulting image has EA6350 in its name.
1 Like
I think this deserves discussion on the openwrt-devel mailing list, rather than a question to the user community. I've been heads-down in getting the device I'm working on running, or I'd have gotten to that myself.
I sorry if I don't speak you language that perfect. Anyway I will wait another opinion. Thank you for your time.
Would someone with this device be able to update https://openwrt.org/toh/linksys/linksys_ea6350_v3 page with the OpenWrt boot log?
@chunkeey Thanks for fixing the imagebuilder problem I reported above with your recent commit:
commit d38789b5597fd5cab429a4708393fa8f72ffc23e
Author: Christian Lamparter <chunkeey@gmail.com>
Date: Sun Feb 17 18:11:59 2019 +0100
firmware: ipq-wifi: mark packages as nonshared
I can confirm this now works and allows building custom images from master, which also include the updated ipq-wifi package from @NoTengoBattery.
I notice the boot log still includes several error messages for firmware loading. How can I best confirm which specific files are successfully being used?
Doing that now using an image built from today's snapshot.
1 Like
For better or for worse, the athX drivers only report when they can't find an item on their prioritized list Direct firmware load for <some file> failed with error -2, not when it successfully finds one. "Falling back to use helper" or whatever it is is also "normal" in most cases.
An error of other than -2 is probably "bad" -- as an example I get a -22 when I intentionally have a zero-length file overriding the package's board-2.bin file, for testing purposes.
3 Likes
Looks like the calibration board change has been successfully merged into the "master branch".
I just tried the latest official development snapshot release dated Feb 21.
And now wireless work just fine with that release also!
1 Like