e927456ec3
Commit 947b44d ("ipq807x: fix wrong define for LAN and WAN ess mask")
started fixing wrong switch_lan_bmp that defined lan there weren't
actually present. This displayed a fragility in the malibu phy init code
in qca-ssdk.
Add patch to fix this. Also update each DTS with the new required
property if needed.
The new binding malibu_phy_start_addr is required with devices that
place the malibu first PHY referring port1 on a different PHY addres
than 0. The most common configuration is 0 but some device (for example
Qnap 301W) place the malibu PHY at an offset to address 16.
Refer to ipq8074-ess dtsi for extensive description on how to derive
this value.
Quoting the patch detailed description:
The usage of first_phy_addr is EXTREMELY FRAGILE and results
in dangerous results if the OEM (or anyone that by chance try to
implement things in a logical manner) deviates from the default values
from the "magical template".
To be in more details. With QSDK 12.4, some tweaks were done to improve
autoneg and now on every call of port status, the phydev is tried to
add. This resulted in the call and log spam of an error with ports that
are actually not present on the system with qsdk reporting phydev is
NULL. This itself is not an error and printing the error is correct.
What is actually an error from ages is setting generic bitmap reporting
presence of port that are actually not present. This is very common on
OEM where the switch_lan_bmp is always a variant of 0x1e (that on bitmap
results in PORT1 PORT2 PORT3 PORT4 present) or 0x3e (PORT1 PORT2 PORT3
PORT4 PORT5). Reality is that many device are used as AP with one LAN
port or one WAN port. (or even exotic configuration with PORT1 not
present and PORT2 PORT3 PORT4 present (Xiaomi 3600)
With this finding one can say... ok nice, then lets update the DT and
set the correct bitmap...
Again world is a bad place and reality is that this cause wonderful
regression in some case of by extreme luck the first ever connected
port working and the rest of the switch dead.
The problem has been bisected to all the device that doesn't have the
PORT1 declared in any of the bitmap.
With this prefaction in mind, on to the REAL problem.
malibu_phy_hw_init FOR SOME REASON, set a global variable first_phy_addr
to the first detected PHY addr that coincidentally is always PORT1.
PORT1 addr is 0x0. The entire code in malibu_phy use this variable to
derive the phy addrs in some function.
Declaring a bitmap where the PORT1 is missing (or worse PORT4 the only
one connected) result in first_phy_addr set to 1 or whatever phy addr is
detected first setting wrong value all over the init stage.
To fix this, introduce a new binding malibu_first_phy_addr to manually
declare the first phy that the malibu PHY driver should use and permit
to detach it from port bmp detection. The legacy detection is kept for
compatibility reason.
Fixes: #13945
Fixes: 947b44d9ae17 ("ipq807x: fix wrong define for LAN and WAN ess mask")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Robert Marko <robimarko@gmail.com> # Qnap 301W
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
OpenWrt Project is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application. For developers, OpenWrt is the framework to build an application without having to build a complete firmware around it; for users this means the ability for full customization, to use the device in ways never envisioned.
Sunshine!
Download
Built firmware images are available for many architectures and come with a package selection to be used as WiFi home router. To quickly find a factory image usable to migrate from a vendor stock firmware to OpenWrt, try the Firmware Selector.
If your device is supported, please follow the Info link to see install instructions or consult the support resources listed below.
An advanced user may require additional or specific package. (Toolchain, SDK, ...) For everything else than simple firmware download, try the wiki download page:
Development
To build your own firmware you need a GNU/Linux, BSD or MacOSX system (case sensitive filesystem required). Cygwin is unsupported because of the lack of a case sensitive file system.
Requirements
You need the following tools to compile OpenWrt, the package names vary between distributions. A complete list with distribution specific packages is found in the Build System Setup documentation.
binutils bzip2 diff find flex gawk gcc-6+ getopt grep install libc-dev libz-dev
make4.1+ perl python3.7+ rsync subversion unzip which
Quickstart
-
Run
./scripts/feeds update -ato obtain all the latest package definitions defined in feeds.conf / feeds.conf.default -
Run
./scripts/feeds install -ato install symlinks for all obtained packages into package/feeds/ -
Run
make menuconfigto select your preferred configuration for the toolchain, target system & firmware packages. -
Run
maketo build your firmware. This will download all sources, build the cross-compile toolchain and then cross-compile the GNU/Linux kernel & all chosen applications for your target system.
Related Repositories
The main repository uses multiple sub-repositories to manage packages of
different categories. All packages are installed via the OpenWrt package
manager called opkg. If you're looking to develop the web interface or port
packages to OpenWrt, please find the fitting repository below.
-
LuCI Web Interface: Modern and modular interface to control the device via a web browser.
-
OpenWrt Packages: Community repository of ported packages.
-
OpenWrt Routing: Packages specifically focused on (mesh) routing.
-
OpenWrt Video: Packages specifically focused on display servers and clients (Xorg and Wayland).
Support Information
For a list of supported devices see the OpenWrt Hardware Database
Documentation
Support Community
- Forum: For usage, projects, discussions and hardware advise.
- Support Chat: Channel
#openwrton oftc.net.
Developer Community
- Bug Reports: Report bugs in OpenWrt
- Dev Mailing List: Send patches
- Dev Chat: Channel
#openwrt-develon oftc.net.
License
OpenWrt is licensed under GPL-2.0