Some 10G optics showed random "module transmit fault indicated" due to I2C
read errors on ONTi ONT-S508CL-8S/XikeStor SKS8300-8X switches. The same
modules work with the original firmware and on other Linux based devices.
There seems to be some differences in how we talk to those modules using
I2C in OpenWRT. To fix this this patch adds support for 50kHz I2C speed on
SFPs and enables that for XikeStor/Onti devices. Since SFPs only transmit
very few bytes this should not have any real downsides.
This patch configures I2C to use 50kHz clock in the DTS for the affected
devices. For it to work it requires a change in the RTL9300 I2C driver.
This can be safely merged without the kernel change (but will not work
in that case as it will fall back to 100kHz).
Signed-off-by: Jan Kantert <jan-openwrt@kantert.net>
Link: https://github.com/openwrt/openwrt/pull/22210
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
No functional changes intended.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/22350
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The main difference between EAP610, 623, and 625 is the device name,
support string, and the BDF package. Move the others to a common
Device/tplink_eap6xx-common in order to highlight the common aspects.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18804
Signed-off-by: Robert Marko <robimarko@gmail.com>
The EAP625 and EAP623 are extremely similar. The only difference in
the vendor's device tree is that EAP625 also enables USB and UART2.
Use the eap6xx dtsi instead of writing out a full devicetree.
The EAP623 uses the same RTL8211F as the 625 and 610. Since this is
a gigabit PHY, it is okay to change the ess mac mode from SGMII_PLUS
to SGMII. This is now consistent across all three devices.
Move the 'realtek,clkout-disable' and 'realtek,aldps-enable' PHY
properties to the common dtsi, as they work well on all three devices.
Reflect the remaining differences in the eap625 dts.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18804
Signed-off-by: Robert Marko <robimarko@gmail.com>
As I was looking at the differences between EAP610, 623, and 625
Outdoor, I realized that the quick-start guide of all of the devices
mentions a yellow and green LED. Thus rename the "amber" led to
"yellow", and adjust its color ID accordingly.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18804
Signed-off-by: Robert Marko <robimarko@gmail.com>
Originally, the .compatible string for EAP623-Outdoor HD tried to
shorten the "-outdoor" to "od". However, this naming was inconsistent
with the existing "eap610-outdoor". As "od" is not a common shorthand,
spell out the complete word: "eap623-outdoor-hd-v1".
Fixes: 5dbf93c8c5 ("ipq60xx: add support for TP-Link EAP623-Outdoor HD v1")
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18804
Signed-off-by: Robert Marko <robimarko@gmail.com>
CI is currently failing due to these four patches.
Automatically refreshed with `make target/linux/refresh`.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/22399
Signed-off-by: Robert Marko <robimarko@gmail.com>
Userspace handling is deprecated.
Since the u-boot ethaddr variable is quoted, we cannot use it.
Use mac-base instead to specify in dts.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14182
Signed-off-by: Robert Marko <robimarko@gmail.com>
Userspace handling is deprecated.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14182
Signed-off-by: Robert Marko <robimarko@gmail.com>
Userspace handling is deprecated.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14182
Signed-off-by: Robert Marko <robimarko@gmail.com>
Removes deprecated userspace handling.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14182
Signed-off-by: Robert Marko <robimarko@gmail.com>
- Fix RTL8261N 10GbE PHY `reset-deassert-us` from 100ms to 221ms to meet datasheet minimum SMI-ready timing (t7 >= 150ms), fixing intermittent boot stalls caused by MDIO bus instability
- Add missing WLAN toggle button (GPIO 34) present in stock firmware but absent from OpenWrt DTS
- Fix memory size from 1 GB to the actual 512 MB
Fix 1: The RTL8261N 10GbE PHY's `reset-deassert-us` was set to 100ms (100000us), but the **RTL8261N datasheet (Table 108, parameter t7)** specifies a minimum **SMI-ready time of 150ms** after nRESET release before the MDIO (SMI) bus can be used.
With only 100ms, the kernel attempts MDIO bus access before the RTL8261N's SMI interface is stable. Since the RTL8261N (mdio-bus:00) and the internal MT7988 2.5GbE PHY (mdio-bus:0f) share the same MDIO bus, a not-yet-ready RTL8261N disrupts all MDIO traffic, causing the 2.5GbE PHY firmware loading (`mt798x_2p5ge_phy_config_init`) to stall.
Observed symptoms on warm reboot:
- Sometimes `mt798x_2p5ge_phy_config_init` hangs for 5+ minutes or indefinitely
- RCU CPU stalls (`rcu: INFO: rcu_sched detected stalls on CPUs`)
- mt7996e WiFi chip message timeouts cascading to `chip full reset failed`
- System appears hung with only power LED blinking slowly
UART serial log evidence (warm reboot with 100ms):
```
[ 73.041756] rcu: INFO: rcu_sched self-detected stall on CPU
[ 73.048341] rcu: 2-....: (8 ticks this GP)
[ 73.061641] pc : mt798x_2p5ge_phy_config_init+0x258/0xbb0
[ 73.061653] lr : mt798x_2p5ge_phy_config_init+0x238/0xbb0
...
[ 334.771280] MediaTek MT7988 2.5GbE PHY mdio-bus:0f: Firmware date code: 2024/10/30
```
The 2.5GbE PHY firmware loading, which normally takes ~3 seconds, took **325 seconds** due to MDIO bus instability. In the worst case, the system never recovers.
GPL DTS uses 221ms (`reset-deassert-us = <221000>`), providing 71ms of margin above the 150ms datasheet minimum. All MediaTek MT7988 reference board DTS files in the GPL use this same 221ms value.
Fix 2: Missing WLAN button (GPIO 34)
The BE450 has a physical WLAN toggle button on GPIO 34, defined in the stock TP-Link GPL DTS but missing from the OpenWrt DTS. Without this definition, the button is non-functional under OpenWrt.
The pin name for GPIO 34 in the MT7988 pinctrl is `SPI2_MISO`, confirmed by the kernel pinctrl driver (`pinctrl-mt7988.c`: `MT7988_PIN(34, "SPI2_MISO")`) and the official devicetree binding (`mediatek,mt7988-pinctrl.yaml`).
Note: GPIO 34 is also used by the BE450's First U-Boot as a recovery button (web recovery 192.168.1.1). Registering it in the DTS ensures the kernel claims the pin.
Fix 3: Incorrect memory size in DTS
The OpenWrt DTS declares 1 GB (`0x40000000`) of RAM, but the BE450 has 512 MB (`0x20000000`).
Run tested.
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22386
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The current CMU setup was just copied and slightly adjusted from the
SDK, lacks functionality and logic and doesn't cover all cases we need
(same in the SDK due to multiple reasons). The existing implementation
for RTL930x covers all that and can be reused for RTL931x. Previous
patches made this generic and now we can add the remaining missing
pieces to actually use it for RTL931x. This only includes
implementations for the few variant-specific actions within the
implementation, linking them properly and calling the CMU configuration.
Drop the old CMU code for RTL931x then since it's not needed anymore.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Improve the RTL931x mapper to infer the CMU page from the hardware mode
by replace unneeded with useful comments, returning a better error code
and dropping irrelevant parts.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Do some slight improvements to the generic CMU configuration for
RTL93xx. This covers several points:
- update comments to the current reality
- add fast path to avoid issues and unneeded calls
- use cached mode value instead of register read
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Generalize the RTL930x CMU configuration to support RTL931x as well.
Both implementations differ only in minor details, allowing them to
share common code and avoid duplication.
Affected functions are moved up in the code to the 93xx common area and
slightly renamed. Existing variant-specific functions are adjusted too
and assigned to the previously added SerDes operation hooks.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add new SerDes ops for CMU management to be able to share common
behavior of CMU configuration for RTL930x and RTL931x while still
covering variant specifics.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Fix naming of several functions to better reflect what they are doing.
While at it, also improve the error handling a lot, changing the return
type from void to int and actually returning errors.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Move resetting the CMU into the PLL configuration itself where the speed
is set. Since this operation is not dependent of the target SerDes and
only needs to be called if the speed changed, it fits better there.
Though the call was guarded with a 'speed_changed' before, this also
applies to actually changing the speed. This was done before anyway,
even if the speed value hasn't really changed.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add a mapper function to infer the to-be-selected PLL speed from the
desired SerDes hardware mode. This avoids having similar logic in each
CMU implementation.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Split up PLL configuration of RTL930x in the two distinct actions of
configuring the PLL itself (aka setting its speed, etc.) and selecting
which PLL is used by a SerDes.
It was found that for both RTL930x and RTL931x, PLL configuration can be
combined while selecting the PLL a SerDes uses differs and needs to be
implemented variant-specific.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Make use of the generic PLL type definition in the current CMU/PLL
configuration code for RTL930x. Assign explicit values to the fields of
the PLL type enum to tie these fields to the values that are used in
the register fields. This allows to simplify the code a bit.
Selecting the PLL to use for a SerDes shares some similarities between
RTL930x and RTL931x. While the location of the selector in the registers
is placed different, similar underlying bit semantics are used. This
allows to reuse the same plain values for both. RTL930x uses a force bit
and a selector bit, RTL931x at least uses the selector bit with the same
values for ring and LC PLL.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Make use of the generic PLL speed definition in the current CMU/PLL
configuration code for RTL930x. Assign explicit values to the field of
the PLL speed enum to tie these fields to the values that are used in
the register fields. This allows to simplify the code a bit.
Setting the actual speed selector for RTL930x was found to be similar to
RTL931x despite of different values being used since the LSB is always 1.
According to the SDK this seems to be a force bit while the other bits
are the actual value/selector that is being forced. For RTL930x,
separate the speed selection to be able to use that as common behavior
for both variants later.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Bring the PLL definitions into a proper shape. While there was already a
definition for the PLL type, a generic PLL speed definition was missing.
Introduce such a definition and adjust the naming of the existing PLL
type definition to have a better distinction and avoid conflicts. The
definitions can and should be used to make the CMU/PLL configuration
more generic and reduce the need for variant-specific definitions.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22198
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The ethernet driver configures the SoC internal network card
on its own. There are no special serdes or other layers in
between. So there is no need for pcs handling in the driver.
Drop that.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22347
Signed-off-by: Robert Marko <robimarko@gmail.com>
These devices contain a single MAC address in the U-Boot environment.
Set it as eth0 and label MAC in device tree. To maintain the current
state, the 02_network script still sets individual port MAC addresses
and the bridge MAC address.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22302
Signed-off-by: Robert Marko <robimarko@gmail.com>
Allow to convert MAC adddresses for all devices to NVMEM in
the future.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22302
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Cudy M3000 v1/v2 seem to have mostly identical hardware.
The M3000 v1 OpenWrt images work on the M3000 v2 (excluding
the v2 parts with a different PHY). Cudy also distributes one
firmware image that supports both routers.
Rename the human-readable device variant to "v1/v2" to match this.
Don't change the compatible property as that hooks into the
attended sysupgrade process.
The recent flash and PHY changes don't seem to be related to the v1/v2
split. There exist M3000 v2 with the Realtek PHY, see e.g.
https://github.com/openwrt/openwrt/pull/21584#issuecomment-3864992555
Signed-off-by: Jakub Vaněk <linuxtardis@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22259
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The hardware is very close the the Cudy M3000 v1 (see commit
20e4a18feb). However, the Motorcomm YT8821 PHY is tricky
to support because of a MDIO address collision within the router.
Specification:
- MT7981BA CPU: dual-core ARM Cortex-A53 @ 1.3 GHz
- 256 MiB RAM
- 128 MiB SPI NAND
- Ethernet:
- 1x 1GbE LAN port driven by the internal MT7981 PHY
- 1x 2.5GbE WAN port driven by the Motorcomm YT8821
- WiFi:
- MT7981BA 2.4 GHz WiFi with 2x2:2 MIMO
- MT7981BA 5 GHz WiFi with 2x3:2 MIMO
- Buttons: Reset, WPS
- LED: 1x combined red/white
How to know if you have the a router with the YT8821 PHY:
- Boot the router into the vendor's firmware. Go to Diagnostic Tools
-> System Log. Try searching for "rtl8221b".
- If there are some matches, you have the Cudy M3000 router with
the Realtek PHY and you should NOT use the device defined in this
commit. Instead, you should use the device defined in
mt7981b-cudy-m3000-v1.dts.
- If there are no matches, try searching for "yt8821". If that
matches something, you have the Cudy M3000 with the Motorcomm PHY
and you should use this device tree
(mt7981b-cudy-m3000-v2-yt8821.dts).
- If even the yt8821 string did not match anything, then something
is wrong. Rebooting the router might help (the system log would
be refreshed).
Installation via the Cudy web UI:
- Download the signed intermediary firmware from
https://drive.google.com/drive/folders/1BKVarlwlNxf7uJUtRhuMGUqeCa5KpMnj
- Flash the intermediary firmware using the Cudy web UI
- Connect a PC/laptop to the "1Gbps LAN" port
- Open http://192.168.1.1 in your browser, log in
(the password should be empty)
- Flash your desired OpenWrt firmware via LuCI
- The router should reboot into the desired firmware
How to access UART (citing from 20e4a18feb):
- remove rubber ring on the bottom
- remove screws
- pull up the cylinder, maybe help by push on an ethernet socket
with a screwdriver
- remove the (3) screws holding the board in the frame
- remove the board from the frame to get to the screws for the
silver, flat heat shield
- remove the (3) screws holding the heat shield
- solder UART pins to the back of the board
- make sure to have the pins point out on side with the black,
finned heat spread
- the markings for the pins are going to be below the silver heat
shield
- Vcc is not needed
- the UART parameters are 115200 baud, 8n1
Installation via UART (citing from 20e4a18feb):
- attach an Ethernet cable to the "1Gbps LAN" port on the router
- hold the reset button while powering the router
- press CTRL-C or wait for the timeout to get to the U-Boot prompt
- prepare a TFTP server on the network to supply ..-initramfs-kernel.bin
- use 'tftpboot 0x46000000 ..-initramfs-kernel.bin' in the U-Boot
shell to pull the image (change the file name accordingly)
- boot the image using 'bootm 0x46000000'
- push the ..-sysupgrade to the router using your preferred method
- perform the upgrade with 'sysupgrade -n'
Signed-off-by: Jakub Vaněk <linuxtardis@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22259
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The KSZ9477 driver was added to the cortexa53 kernel to support the
Gateworks Venice product family which has a board with this switch. Now
that the kmod-dsa-ksz9477 driver is available as a package remove the
static configuration ad add the package.
This resolves an issue caused by having the switch driver static and the
PHY driver as a module such that the PHY driver was not registered early
enough to be used causing some errata to not be worked around.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Link: https://github.com/openwrt/openwrt/pull/22120
Link: https://github.com/openwrt/openwrt/pull/22257
Signed-off-by: Robert Marko <robimarko@gmail.com>
In generic, there's a backport from 6.14 that makes this change. Do so
in downstream locations as well.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21167
Signed-off-by: Robert Marko <robimarko@gmail.com>
Restore the lost band label.
Fixes: 502ac21e8f ("ipq40xx: drop redundant label with new LED color/function format")
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
SFP I2C buses for ports 1 and 3 were swapped as order changed on production
boards.
So, swap them around to fix SFP 1 and 3 failed to read EEPROM errors.
Fixes: 29b3d929a6 ("microchipsw: lan969x: add Novarq Tactical 1000")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
I wrongly added the wifi devices to the pcie nodes and not the bridge
nodes as they were not present at the time.
Fixes: 58056df ("bcm53xx: backport nvmem mac for meraki mr26")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22369
Signed-off-by: Robert Marko <robimarko@gmail.com>
Remove source-only from an7581.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17869
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Most, if not all Airoha devices will have LEDs and buttons. Add them to
default packages.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17869
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add uboot-envtools to default packages to facilitate modifying the
u-boot environment.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17869
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This commit adds support for Gemtek (Centurylink/Lumen/Quantum Fiber)
W1700K.
Device specification
--------------------
SoC Type: Airoha AN7581
RAM: ESMT M16U8G16512A (2GB)
Flash: Winbond 25N04KVZEIR (512MB)
Ethernet: 2x gigabit via AN7581, 2x 10g via RTL8261N
Wi-Fi: MT7996 - BE19000
LEDs: 1 LED, power/status
Button: Reset
USB ports: None
Bootloader: U-Boot 2014.04-rc1 (Jun 12 2024 - 08:14:34) AXON 2.0
Fan: 1x controlled by Nuvoton NCT7511Y
This device is pretty useless with the stock firmware as it requires an
account to completely set it up. Additionally, the vendor bootloader is
signed and uses Airoha/Mediatek's BBT/BMT for bad block management on
the flash. It does not support UBI, thus kernel updates are subject to
BMT/BBT which OpenWrt does not support. In turn, if a kernel update
happens and a block is marked bad in the process, the device will fail
to boot and will need to be recovered via serial.
The workaround is to chainload U-Boot in place of the kernel, as it
should not need frequent updates and thus should not cause BBT/BMT to
misbehave and soft-brick the device. Upstream U-Boot supports loading
a FIT image from UBI, so we create a UBI partition for the new u-boot
env, FIT image and factory data. This way, bad blocks are managed by UBI
instead, which will not soft-brick the device should a block be marked
bad during a normal OpenWrt update. Users wishing to update U-Boot can
do so, but should be prepared to recover if a block goes bad.
Because the device is not useful with stock firmware, this is a one-way
ticket for most users and reverting will not be documented.
The following steps can be used to install OpenWrt on the W1700K.
Connect to serial console. There is a Torx T10 screw underneath the QR
code printed onto the label. Then, pry between the gray and white
plastic, starting by the ports on the back. There are clips arount the
entire device. Starting closest to the screw next to the UART header,
TX - GND - VCC - N/A - RX. The bootloader can be interrupted by
pressing any key.
Configuring Vendor Bootloader and Installing U-Boot Chainloader:
The bootloader's default bootcmd will only run a signed image. However,
we can still bootm our own image from flash.
NOTE: The vendor's ethernet drivers are flaky. You may have to reboot
and try the tftpboot part several times for it to work.
- setenv one flash read 0x600000 0x1000000 \$loadaddr
- setenv two "; bootm"
- setenv bootcmd "$one$two"
- setenv one
- setenv two
- saveenv
- setenv serverip 192.168.1.10; setenv ipaddr 192.168.1.1; tftpboot
0x89000000 openwrt-airoha-an7581-gemtek_w1700k-ubi-chainload-uboot.itb
- flash erase 0x600000 0x100000
- flash write 0x600000 0x100000 0x89000000
- reset
The device will now reboot into the U-Boot chainloader.
Loading the W1700K UBI Installer:
The installer can be downloaded at
https://github.com/hurrian/w1700k-ubi-installer/releases
- Boot the installer via the TFTP option in the U-Boot menu. This
process is automatic, though you may be prompted to answer some
questions.
- Once it is done, you may upgrade to your preferred build.
- For more information: https://github.com/hurrian/w1700k-ubi-installer
For those wishing to explore the stock firmware:
Rooting Stock FW (for making backups, recommended):
- Boot the router and watch serial console until presented with failsafe
mode. Enter it (f + enter).
- mount_root
- Change the root password (passwd).
- Open /etc/config/axon_platform_manager and set sshServerEnable,
localAccessEnable and remoteAccessEnable to 1.
- Search for "SSH". You'll find a long string with 3 matches such as
Enabled%25252c1%25252cSSH%Drop. Change any instances of "Disabled"
preceding SSH to "Enabled" and any instances of "Drop" to "Accept"
that follow SSH. Same for "Local SSH" and "Remote SSH".
- Set /etc/config/dropbear to:
config dropbear
option PasswordAuth 'on'
option RootPasswordAuth 'on'
option Port '22'
- Reboot.
- Connect 10g WAN port to existing network and SSH in with the password
you set.
- SSH into rooted stock fw.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17869
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
In the transition to nvmem-layout and subsequent disabling of non layout
u-boot-env, this device was left out.
Transition to nvmem-layout to fix the mac address.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22263
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Userspace handling is deprecated.
These are identical to NBG6617, which was tested as working.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22263
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Userspace handling is deprecated.
UBI nvmwem has been supported for quite a while now.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22263
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
When NVMEM is not ready, of_get_mac_address fails. Handle this.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22305
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
