The current support for MikroTik NAND-based devices relies on a
gross hack that packs the kernel into a static YAFFS stub, as the
stock bootloader only supports booting a YAFFS-encapsulated kernel.
The problem with this approach is that since the kernel partition is
blindly overwritten without any kind of wear or badblock management
(due to lack of proper support for YAFFS in OpenWRT), the NAND flash
is not worn uniformly and eventually badblocks appear, leading to
unbootable devices.
This issue has been reported here [1] and discussed in more detail
here [2].
Until a proper fix is found (or the stock bootloader supports other
filesystems), we disable building these images to prevent unknowing
users from risking their devices.
Thanks to Thibaut Varène for summarizing the details above.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
treewide: use more descriptive names for concatenated partitions
A few devices in ath79 and ramips use mtd-concat to concatenate
individual partitions into a bigger "firmware" or "ubi" partition.
However, the original partitions are still present and visible,
and one can write to them directly although this might break the
actual virtual, concatenated partition.
As we cannot do much about the former, let's at least choose more
descriptive names than just "firmwareX" in order to indicate the
concatenation to the user. He might be less tempted into overwriting
a "fwconcat1" than a "firmware1", which might be perceived as an
alternate firmware for dual boot etc.
This applies the new naming consistently for all relevant devices,
i.e. fwconcatX for virtual "firmware" members and ubiconcatX for
"ubi" members.
While at it, use DT labels and label property consistently, and
also use consistent zero-based indexing.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Yousong Zhou [Thu, 24 Dec 2020 01:35:39 +0000 (09:35 +0800)]
kernel: remove target specific setting of CONFIG_TCP_CONG_ADVANCED
The option was introduced in upstream linux commit a6484045 ("[TCP]: Do
not present confusing congestion control options by default.").
The option is set to y in generic config and to the moment does not
incur additional size increment. Make it y for all so that packages
such as kmod-tcp-bbr do not have to set it on every occasion
Dongming Han [Wed, 22 Jul 2020 07:12:17 +0000 (15:12 +0800)]
ipq40xx: add support for GL.iNet GL-AP1300
Specifications:
SOC: Qualcomm IPQ4018 (DAKOTA) ARM Quad-Core
RAM: 256 MiB
FLASH1: 4 MiB NOR
FLASH2: 128 MiB NAND
ETH: Qualcomm QCA8075
WLAN1: Qualcomm Atheros QCA4018 2.4GHz 802.11b/g/n 2x2
WLAN2: Qualcomm Atheros QCA4018 5GHz 802.11n/ac W2 2x2
INPUT: Reset
LED: Power, Internet
UART1: On board pin header near to LED (3.3V, TX, RX, GND), 3.3V without pin - 115200 8N1
OTHER: On board with BLE module - by cp210x USB serial chip
On board hareware watchdog with GPIO0 high to turn on, and GPIO4 for watchdog feed
Install via uboot tftp or uboot web failsafe.
By uboot tftp:
(IPQ40xx) # tftpboot 0x84000000 openwrt-ipq40xx-generic-glinet_gl-ap1300-squashfs-nand-factory.ubi
(IPQ40xx) # run lf
By uboot web failsafe:
Push the reset button for 10 seconds util the power led flash faster,
then use broswer to access http://192.168.1.1
Afterwards upgrade can use sysupgrade image.
Signed-off-by: Dongming Han <handongming@gl-inet.com>
Sven Eckelmann [Wed, 23 Dec 2020 15:23:25 +0000 (16:23 +0100)]
ipq-wifi: Fix suffix for Plasma Cloud PA2200 QCA4019 board-2.bin
The Makefile is rejecting all files with for a given prefix (here
"board-plasmacloud_pa2200") when it didn't match a known suffix. Instead it
stops the build with an error like:
Makefile:135: *** Unrecognized board-file suffix '.ipq4019' for 'board-plasmacloud_pa2200.ipq4019'. Stop.
The correct suffix for the QCA4019/hw1.0 is qca4019 and not ipq4019.
Fixes: 4871fd2616ac ("ipq40xx: add support for Plasma Cloud PA2200") Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Wed, 23 Dec 2020 15:23:25 +0000 (16:23 +0100)]
ipq-wifi: Fix suffix for Plasma Cloud PA1200 QCA4019 board-2.bin
The Makefile is rejecting all files with for a given prefix (here
"board-plasmacloud_pa1200") when it didn't match a known suffix. Instead it
stops the build with an error like:
Makefile:135: *** Unrecognized board-file suffix '.ipq4019' for 'board-plasmacloud_pa1200.ipq4019'. Stop.
The correct suffix for the QCA4019/hw1.0 is qca4019 and not ipq4019.
Fixes: ea5bb6bbfee0 ("ipq40xx: add support for Plasma Cloud PA1200") Signed-off-by: Sven Eckelmann <sven@narfation.org>
MAC address is labeled as "MAC"
Only 1 address on label and in flash
The OEM software reports these MACs for the ifconfig
eth0 MAC *:0c art 0x0
phy0 --- *:0d ---
Installation:
2 ways to flash factory.bin from OEM:
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.10.1
username and password "admin"
Navigate to "Upgrade Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9f670000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
Return to OEM:
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
Format of OEM firmware image:
The OEM software of EAP350 is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
The OEM upgrade script is at /etc/fwupgrade.sh
Later models in the EAP series likely have a different platform
and the upgrade and image verification process differs.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1024k
and the factory.bin upgrade procedure would
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8035-A switch between
the SOC and the ethernet PHY chips.
For AR724x series, the PLL register for GMAC0
can be seen in the DTSI as 0x2c.
Therefore the PLL register can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x1805002c 1`.
uboot did not have a good value for 1 GBps
so it was taken from other similar DTS file.
Michael Pratt [Fri, 9 Oct 2020 16:28:11 +0000 (12:28 -0400)]
ath79: add support for Senao Engenius EAP600
FCC ID: A8J-EAP600
Engenius EAP600 is a wireless access point with 1 gigabit ethernet port,
dual-band wireless, external ethernet switch, 4 internal antennas
and 802.3af PoE.
MAC addresses are labeled MAC1 and MAC2
The MAC address in flash is not on the label
The OEM software reports these MACs for the ifconfig
eth0 MAC 1 *:5e ---
phy1 MAC 2 *:5f --- (2.4 GHz)
phy0 ----- *:60 art 0x0 (5 GHz)
Installation:
2 ways to flash factory.bin from OEM:
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Upgrade Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9fdf0000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
Return to OEM:
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
Format of OEM firmware image:
The OEM software of EAP600 is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
The OEM upgrade script is at /etc/fwupgrade.sh
Later models in the EAP series likely have a different platform
and the upgrade and image verification process differs.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1536k
and the factory.bin upgrade procedure would
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8035-A switch between
the SOC and the ethernet PHY chips.
For AR934x series, the PLL register for GMAC0
can be seen in the DTSI as 0x2c.
Therefore the PLL register can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x1805002c 1`.
Unfortunately uboot did not have the best values
so they were taken from other similar DTS files.
MAC addresses are labeled MAC1 and MAC2
The MAC address in flash is not on the label
The OEM software reports these MACs for the ifconfig
phy1 MAC 1 *:52 --- (2.4 GHz)
phy0 MAC 2 *:53 --- (5 GHz)
eth0 ----- *:54 art 0x0
Installation:
2 ways to flash factory.bin from OEM:
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Upgrade Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9fdf0000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
Return to OEM:
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
Format of OEM firmware image:
The OEM software of ECB600 is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
The OEM upgrade script is at /etc/fwupgrade.sh
Later models in the ECB series likely have a different platform
and the upgrade and image verification process differs.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1536k
and the factory.bin upgrade procedure would
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8035-A switch between
the SOC and the ethernet PHY chips.
For AR934x series, the PLL register for GMAC0
can be seen in the DTSI as 0x2c.
Therefore the PLL register can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x1805002c 1`.
Unfortunately uboot did not have the best values
so they were taken from other similar DTS files.
Sven Wegener [Thu, 24 Dec 2020 20:20:53 +0000 (21:20 +0100)]
ath79: update image command for Plasma Cloud PA300
Commit 5fc28ef47959 ("ath79: Add support for Plasma Cloud PA300")
added the IMAGE/sysupgrade.bin/squashfs definition, which leaks into
other devices, resulting in sysupgrade.bin images that are actually
tarballs and do not boot when directly written to flash.
We can use the normal sysupgrade.bin command variable for this device.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
[fix format, spelling] Signed-off-by: David Bauer <mail@david-bauer.net>
Hans Dedecker [Thu, 24 Dec 2020 16:21:17 +0000 (17:21 +0100)]
odhcpd: update to latest git HEAD
b75bcad dhcpv6-ia: remove assignment equal to 0 checks d1ae052 dhcpv6-ia: fix logic to include IA_PD prefix with lifetimes set to 0 9d5e379 dhcpv6-ia: fix prefix delegation behavior
Daniel Golle [Wed, 23 Dec 2020 21:00:58 +0000 (21:00 +0000)]
oxnas: now longer build KD20 factory image
The image never worked in any release and is also broken in snapshots
due to stock bootloader not loading more than 4 MiB.
Hence it's better to remove the image for now, users who want to flash
OpenWrt on new devices may build LEDE 17.01 with everything possible
disabled to get a small enough and working factory image.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Robert Marko [Thu, 26 Nov 2020 12:41:54 +0000 (13:41 +0100)]
ipq40xx: net: ethernet: edma: use generic ksettings functions
Since we now have a proper PHY driver for QCA807x and AR803x has already
been supported properly there is no need for the driver to be poking
on PHY registers for ethtool ops.
So, lets simply use the generic
phy_ethtool_ksettings_get/phy_ethtool_ksettings_set functions.
This also has the advantage of properly populating stuff other than
speeds like, transceiver type, MDI-X etc.
ethtool before:
root@OpenWrt:/# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: No
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 4
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000000 (0)
Link detected: yes
ethtool after:
root@OpenWrt:/# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 4
Transceiver: external
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000000 (0)
Link detected: yes
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Robert Marko [Mon, 19 Oct 2020 16:49:29 +0000 (18:49 +0200)]
ipq40xx: dts: convert PHY GPIO bindings
Since the new PHY driver manages each PHY individually and therefore
registers each PHY that is marked with gpio-controller; DT property as a
GPIO controller we need to convert old DT bindings to account for this.
Only 2 boards use this so its not much of an issue.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Robert Marko [Thu, 8 Oct 2020 10:20:39 +0000 (12:20 +0200)]
ipq40xx: net: phy: ar40xx: remove PHY handling
Since we now have proper PHY driver for the QCA807x PHY-s, lets remove
PHY handling from AR40xx.
This removes PHY driver, PHY GPIO driver and PHY init code.
AR40xx still needs to handle PSGMII calibration as that requires R/W
from the switch, so I am unable to move it into PHY driver.
This also converted the AR40xx driver to use OF_MDIO to find the MDIO
bus as it now cant be set through the PHY driver.
So lets depend on OF_MDIO in KConfig.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Robert Marko [Mon, 19 Oct 2020 16:50:00 +0000 (18:50 +0200)]
ipq40xx: add Qualcomm QCA807x driver
This adds driver for the Qualcomm QCA8072 and QCA8075 PHY-s.
They are 2 or 5 port IEEE 802.3 clause 22 compliant
10BASE-Te, 100BASE-TX and 1000BASE-T PHY-s.
They feature 2 SerDes, one for PSGMII or QSGMII connection with MAC,
while second one is SGMII for connection to MAC or fiber.
Both models have a combo port that supports 1000BASE-X and 100BASE-FX
fiber.
Each PHY inside of QCA807x series has 2 digitally controlled output only
pins that natively drive LED-s.
But some vendors used these to driver generic LED-s controlled by
user space, so lets enable registering each PHY as GPIO controller and
add driver for it.
This also adds the ability to specify DT properties so that 1000 Base-T
LED will also be lit up for 100 and 10 Base connections.
This is usually done by U-boot, but boards running mainline U-boot are
not configuring this yet.
These PHY-s are commonly used in Qualcomm IPQ40xx, IPQ60xx and IPQ807x
boards.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Robert Marko [Wed, 7 Oct 2020 15:27:31 +0000 (17:27 +0200)]
ipq40xx: edma: convert to of_mdio_find_bus()
With the reworked MDIO driver, EDMA will fail to get the MII BUS as it
used the MII BUS stored inside the MDIO structure private data.
This obviously does not work with the modernized driver, so lets switch
to using a purpose build of_mdio_find_bus() which will return the MII
BUS and only requires the MDIO node to be passed.
This is easy as we already have the node parsed.
Also, since we now require OF_MDIO add that as dependency.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
As of hostapd upstream commit 7d2ed8ba "Remove CONFIG_IEEE80211W build parameter"
https://w1.fi/cgit/hostap/commit?id=7d2ed8bae86a31dd2df45c24b3f7281d55315482
802.11w feature is always enabled in the build time.
It doesn't make sense to opt-in 802.11w per driver as hostapd will always
be compiled with this feature enabled.
As suggested by Hauke Mehrtens, for now keep 11w enabled in build_features.h
for compatibility reasons. This option will be dropped when LuCI is adjusted.
1. Boot WRC-1167GST2 normally
2. Access to "http://192.168.2.1/" and open firmware update page
("ファームウェア更新")
3. Select the OpenWrt factory image and click apply ("適用") button
4. Wait ~150 seconds to complete flashing
Notes:
- there is no way to configure the correct MAC address for secondary phy
(5GHz) on MT7615D
- Wi-Fi band on primary phy (2.4GHz) cannot be limitted by specifying
ieee80211-freq-limit
(fail to register secondary phy due to error)
- mtd-mac-address in the wifi node is required for using
mtd-mac-address-increment
1. Boot WRC-1167GS2-B normally
2. Access to "http://192.168.2.1/" and open firmware update page
("ファームウェア更新")
3. Select the OpenWrt factory image and click apply ("適用") button
4. Wait ~120 seconds to complete flashing
Notes:
- there is no way to configure the correct MAC address for secondary phy
(5GHz) on MT7615D
- Wi-Fi band on primary phy (2.4GHz) cannot be limitted by specifying
ieee80211-freq-limit
(fail to register secondary phy due to error)
- mtd-mac-address in the wifi node is required for using
mtd-mac-address-increment
ramips: mt7621: create DTSI for ELECOM WRC GS devices with 2 PCI
This creates a dedicated DTSI for ELECOM WRC GS devices with 2 PCI
WiFi chips in preparation for the 1 chip - dual radio devices, so
the latter can reuse part of the common definitions.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Petr Štetiar [Tue, 22 Dec 2020 19:38:13 +0000 (20:38 +0100)]
Revert "ccache: update to 4.1"
This reverts commit b1952dc259ce3eb7ac6023c9e02d5adf2546efca as it's
causing issues on the buildbot which uses some kind of ccache wrapper
and so the breakage needs to be investigated further:
bash: cmake: command not found
time: tools/ccache/compile#0.05#0.03#0.15
ERROR: tools/ccache failed to build.
To modify a retail device to run OpenWRT firmware:
1) Setup a TFTP server on IP address 192.168.0.100 and copy the OpenWRT
initramfs (initramfs-fit-uImage.itb) to the TFTP root as 'uploadfile'.
2) Power on the device while pressing the recessed reset button next to
the Ethernet ports. This causes the bootloader to retrieve and start
the initramfs.
3) Once the initramfs is booted, the device will come up with IP
192.168.1.1. You can then connect through SSH (allow some time for
the first connection).
4) On the device shell, run 'fw_printenv' to show the U-boot environment.
Backup this information since it contains device unique factory data.
5) Change the boot command to support booting OpenWRT:
# fw_setenv bootcmd 'sf probe && sf read 0x84000000 0x180000 0x400000 && bootm'
6) Change directory to /tmp, download the sysupgrade (e.g. through wget)
and install it with sysupgrade. The device will reboot into OpenWRT.
Notice that there is currently no support for booting the G.hn chip.
This requires userland software we lack the rights to share right now.
Signed-off-by: Stefan Schake <stefan.schake@devolo.de>
Nick Hainke [Wed, 9 Dec 2020 20:17:47 +0000 (21:17 +0100)]
kernel: only strip proc for small flash devices
Currently, you are not able to get statistics about IPv4 and IPv6
usage. This information can be collected via the snmp and snmp6.
However, in the current state this interface is disabled as you can
read in the "902-debloat_proc.patch":
"Strip non-essential /proc functionality to reduce code size"
Tools like netstat use the snmp/6 interface to collect interface
statistics. Some prometheus exporters also mention this:
- prometheus-collectors/netstat.lua
- prometheus-collectors/snmp6 (still a PR)
- collectd/snmp6 (still a PR)
Andy Walsh [Mon, 29 Jun 2020 22:52:25 +0000 (00:52 +0200)]
kernel: add KERNEL_IO_URING option
* add KERNEL_IO_URING option
NOTES:
Adds configurable support for the io_uring interface (CONFIG_IO_URING) via KERNEL_IO_URING option.
The kernel only zImage grows by about 5-9KB ?
I would like to enable this by default for all 5.4 kernels, so i can use the new io_uring samba-4.12.x vfs module by default.
The associated liburing was already submitted and merged.
The kernel + liburing was tested on ARM/mvebu via samba4 vfs_io_uring module and i have no issues so far.
Some extra reads on it and why we should enable it by default, since i expect more packages to use this in the future.
https://wiki.samba.org/index.php/Samba_4.12_Features_added/changed#.27io_uring.27_vfs_module
https://lwn.net/Articles/810414/
https://kernel.dk/io_uring.pdf
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-IO-uring-Tests
Signed-off-by: Andy Walsh <andy.walsh44+github@gmail.com>
Kip Porterfield [Mon, 3 Aug 2020 14:07:51 +0000 (14:07 +0000)]
kirkwood: add support for Seagate BlackArmor NAS220
The Seagate BlackArmor NAS220 is a consumer NAS
with two internal drive bays. The stock OS runs
RAID 1 over the disks via mdadm.
Device specification:
- SoC: Marvell 88F6192 800 MHz
- RAM: 128 MB
- Flash: 32 MB
- 2 x internal SATA II drives
- Ethernet: 10/100/1000 Mbps (single port, no switch)
- WLAN: None
- LED: Power, Status, Sata Activity
- Key: Power, Reset
- Serial: 10 pin header, (115200,8,N,1), 3.3V TTL
9|x - x|10
7|x - x|8
5|x - GND|6
3|x - RX|4
1|TX - x|2
front of case
- USB ports: 2 x USB 2.0
Flash instruction:
NOTE: this process uses a serial connection. It will upgrade the
bootloader and reset the bootloader environment variables
TFTP server setup
- Setup PC with TFTP server set the PC IP to 10.4.50.5 as TFTP server
- Copy these files to TFTP server location
- u-boot.kwb
- seagate_blackarmor-nas220-initramfs-uImage
- seagate_blackarmor-nas220-squashfs-sysupgrade.bin
- seagate_blackarmor-nas220-squashfs-factory.bin
Seagate NAS setup
- Connect LAN cable between PC and seagate device
- Connect to serial to seagate device
Install u-boot
- Boot seagate device and stop in bootloader by pressing any key
- run 'printenv' from u-boot and save the values
- tftpboot 0x2000000 u-boot.kwb
- nand erase.part uboot
- nand write 0x2000000 0x0 ${filesize}
- reset
Update MAC address in u-boot env
- Stop in u-boot by pressing any key
- Get your MAC address from your saved printenv. Is also on chassis
- setenv ethaddr <your MAC>
- saveenv
Option 1 (recommended) - Install OpenWrt via initramfs and sysupgrade
- tftpboot 0x2000000 seagate_blackarmor-nas220-initramfs-uImage
- bootm 0x2000000
- *OpenWrt should be running now, however it is not written to flash yet*
- From the running instance of OpenWrt use Luci's "flash image" feature
from the web site or use sysupgrade from the console to write
seagate_blackarmor-nas220-squashfs-sysupgrade.bin to flash
Option 2 - Install OpenWrt by flashing factory image from u-boot
- nand erase.part ubi
- tftpboot 0x2000000 seagate_blackarmor-nas220-squashfs-factory.bin
- nand write 0x2000000 ubi ${filesize}
- reset
The ASRock G10 is a 2.4/5 GHz band 11ac "Gaming" router,
based on Qualcomm IPQ8064.
Specifications:
SoC: Qualcomm IPQ8064
CPU: Dual-Core A15 @ (384 - 1,400 MHz, 2C2T)
DRAM: 512 MiB (~467 MiB available)
NAND: 128 MB (Micron MT29F1G08ABBEAH4)
WLAN0: 4T4R 5 GHz Wlan (QCA9980)
WLAN1: 4T4R 2.4 GHz Wlan (QCA9980)
ETH: 5x 10/100/1000 Mbps Ethernet (QCA8337)
INPUT: Reset Button, WPS 2.4G and WPS 5G Button
LEDS: 1 multicolor status LED
USB: 2x USB 3.0 Type-A
POWER: 12VDC/3A AC Adapter + dedicated Power Switch
UART: Setting is 115200-8-N-1. 1x4 .1" unpopulated header
on the PCB (J6 - very tiny silkscreen next to TX).
Pinout: 1. 3v3 (Square - best skipped!), 2. RX, 3. GND, 4. TX
WARNING: The serial port needs a TTL/RS-232 3.3v level converter!
(Depending on the serial adapter RX and TX might need to
be swapped).
Note about the IR-Remote:
There's a 8-Bit MCU (SONIX SN8F25E21SG) which is controlling the
IR-Remote and is fed by the IR-Photodiode. The SoC can talk to
the device via I2C. The vendor's GPL archive comes with the source
of the interface driver for this as a (character driver), the main
control software is however a blob.
Installation Instructions:
1. Download factory image to disk
2. Apply factory image via stock web-gui
Back to stock:
1. Login to router via ssh
2. run "asrock_g10_back_to_factory" script from /sbin
Notes:
- If something goes wrong durring sysupgrade, router will go back to
factory image.
- Asrock G10 uses partition layout from smem. So partition layout can
be normal or alternate.
- 900-arm-add-cmdline-override.patch was copied from 102-powerpc-add-cmdline-override.patch
from powerpc target.
Knowledge about BOOTCONFIG partition was based on user "jmomo" post from old
OpenWrt forum (Post #50):
https://forum.archive.openwrt.org/viewtopic.php?id=65956&p=2
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
[bump to 5.4, add factory image, fix sysupgrade, convert partition
layout to smem, remove ipq-wifi-asrock-g10 and use ART, minor fixes] Co-Authored-by: Pawel Dembicki <paweldembicki@gmail.com> Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Tested-by: Lukasz Ostapiuk <palibrzuch@gmail.com>
Michael Pratt [Mon, 5 Oct 2020 02:54:36 +0000 (22:54 -0400)]
ath79: expand factory.bin support for some Senao Engenius boards
Newer EnGenius software that still uses the tar.gz platform
instead of the custom header requires more checks for upgrading,
but their script includes a way to skip them...
the existence of a file in the tar.gz called failsafe.bin
Their upgrade script has these lines:
\#pass check when upload with full image file
[ "${errcode}" -eq "1" ] && [ -f failsafe.bin ] && errcode="0"
This overrides the script's "errcode" variable
which can be set if any of the following actions/checks fail:
- untarring of the upload
- magic number for kernel: "2705"
- magic num for rootfs: "7371" or "6873"
- md5sums for each file in the format
filename:md5
- existence of a file matching FWINFO*
that it has boardname in the name somewhere (grep)
that the 4th field of separator "-" is at least 3 (version)
Otherwise we would need to generate md5sums in this strange format
and touch a file with specific requirements in the name.
This does not effect boards where the advanced checks do not apply.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
[fixed SoB to match From:] Signed-off-by: Petr Štetiar <ynezz@true.cz>
Michael Pratt [Tue, 25 Aug 2020 04:17:28 +0000 (00:17 -0400)]
ath79: add support for Senao Engenius EnStationAC v1
FCC ID: A8J-ENSTAC
Engenius EnStationAC v1 is an outdoor wireless access point/bridge with
2 gigabit ethernet ports on 2 external ethernet switches,
5 GHz only wireless, internal antenna plates, and proprietery PoE.
MAC addresses are labeled as ETH and 5GHz
Vendor MAC addresses in flash are duplicate
eth0 ETH *:d3 art 0x0/0x6
eth1 ---- *:d4 ---
phy0 5GHz *:d5 ---
Installation:
2 ways to flash factory.bin from OEM:
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9fd70000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
Return to OEM:
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
TFTP recovery:
rename initramfs to 'vmlinux-art-ramdisk'
make available on TFTP server at 192.168.1.101
power board
hold or press reset button repeatedly
NOTE: for some Engenius boards TFTP is not reliable
try setting MTU to 600 and try many times
Format of OEM firmware image:
The OEM software of EnStationAC is a heavily modified version
of Openwrt Altitude Adjustment 12.09. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
Newer EnGenius software requires more checks but their script
includes a way to skip them, otherwise the tar must include
a text file with the version and md5sums in a deprecated format.
The OEM upgrade script is at /etc/fwupgrade.sh.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1536k
and the factory.bin upgrade procedure would otherwise
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8033 switch between
the SOC and the ethernet PHY chips.
For QCA955x series, the PLL registers for eth0 and eth1
can be see in the DTSI as 0x28 and 0x48 respectively.
Therefore the PLL registers can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x18050028 1` and `md 0x18050048 1`.
For eth0 at 1000 speed, the value returned was ae000000 but that didn't work, so following
the logical pattern from the rest of the values,
the guessed value of a3000000 works better.
later discovered that delay can be placed on the PHY end only
with phy-mode as 'rgmii-id' and set register to 0x82...
Tested from master, all link speeds functional
Signed-off-by: Michael Pratt <mcpratt@pm.me>
[fixed SoB to match From:] Signed-off-by: Petr Štetiar <ynezz@true.cz>
WNDR4700 uboot has an issue with decompressing kernel with default dictionary size (-d23 which is about 8MB).
Limiting lzma dictionary lowers memory footprint and allows device to boot the kernel.
The highest bootable dictonary size is 18, choosing 16 for an extra safety margin.
The R1 revision is identical to the A1 revision except
- No Config2 Parition, therefore
- factory partition resized to 64k from 128K
- Firmware partition offset is 0x50000 not 0x60000
- Firmware partitions size increased by 64K
- Firmware partition type is "denx,uimage", not "sge,uimage"
- Padding of image creation "uimage-padhdr 96" removed
Installation:
- Older firmware versions: put the factory image on a USB stick, turn on
the telnet console, and flash using the following cmd
"fw_updater Linux /mnt/usb_X_X/firmware.bin"
- D-Link FailsafeUI:
Power down the router, press and hold the reset button, then
re-plug it. Keep the reset button pressed until the internet LED stops
flashing, then jack into any lan port and manually assign a static IP
address in 192.168.0.0/24 other than 192.168.0.0 (e.g. 192.168.0.2)
and go to http://192.168.0.1
Flash with the factory image.
Signed-off-by: Andrew Pikler <andrew.pikler@gmail.com>
Some Russian d-link routers require that their firmware be signed with a
salted md5 checksum followed by the bytes 0x00 0xc0 0xff 0xee. This tool
signs factory images the OEM's firmware accepts them.
Signed-off-by: Andrew Pikler <andrew.pikler@gmail.com>
Installation:
* Factory Web UI is at 192.168.0.50
login with 'admin' and blank password, flash factory.bin
* Recovery Web UI is at 192.168.0.50
connect network cable, hold reset button during power-on and keep it
pressed until uploading has started (only required when checksum is ok,
e.g. for reverting back to oem firmware), flash factory.bin
After flashing factory.bin, additional free space can be reclaimed by
flashing sysupgrade.bin, since the factory image requires some padding
to be accepted for upgrading via OEM Web UI.
Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net>
The Ubiquiti Network airCube AC is a cube shaped device supporting
2.4 GHz and 5 GHz with internal 2x2 MIMO antennas.
It can be powered with either one of:
- 24v power supply with 3.0mm x 1.0mm barrel plug
- 24v passive PoE on first LAN port
There are four 10/100/1000 Mbps ports (1 * WAN + 3 * LAN).
First LAN port have optional PoE passthrough to the WAN port.
SoC: Qualcomm / Atheros AR9342
RAM: 64 MB DDR2
Flash: 16 MB SPI NOR
Ethernet: 4x 10/100/1000 Mbps (1 WAN + 3 LAN)
LEDS: 1x via a SPI controller (not yet supported)
Buttons: 1x Reset
Serial: 1x (only RX and TX); 115200 baud, 8N1
Missing features:
- LED control is not supported
Physical to internal switch port mapping:
- physical port #1 (poe in) = switchport 2
- physical port #2 = switchport 3
- physical port #3 = switchport 5
- physical port #4 (wan/poe out) = switchport 4
Factory update is tested and is the same as for Ubiquiti AirCube ISP
hence the shared configuration between that devices.
Signed-off-by: Roman Kuzmitskii <damex.pp@icloud.com>
ath79: add support for MikroTik RouterBOARD wAPR-2nD (wAP R)
This patch adds support for the MikroTik RouterBOARD wAPR-2nD (wAP R)
router, a weatherproof 2.4 GHz access point with a miniPCI-e slot and
a SIM card slot.
Marek Lindner [Fri, 14 Dec 2018 15:46:53 +0000 (23:46 +0800)]
ipq40xx: add support for Plasma Cloud PA2200
Device specifications:
* QCA IPQ4019
* 256 MB of RAM
* 32 MB of SPI NOR flash (w25q256)
- 2x 15 MB available; but one of the 15 MB regions is the recovery image
* 2T2R 2.4 GHz
- QCA4019 hw1.0 (SoC)
- requires special BDF in QCA4019/hw1.0/board-2.bin with
bus=ahb,bmi-chip-id=0,bmi-board-id=20,variant=PlasmaCloud-PA2200
* 2T2R 5 GHz (channel 36-64)
- QCA9888 hw2.0 (PCI)
- requires special BDF in QCA9888/hw2.0/board-2.bin
bus=pci,bmi-chip-id=0,bmi-board-id=16,variant=PlasmaCloud-PA2200
* 2T2R 5 GHz (channel 100-165)
- QCA4019 hw1.0 (SoC)
- requires special BDF in QCA4019/hw1.0/board-2.bin with
bus=ahb,bmi-chip-id=0,bmi-board-id=21,variant=PlasmaCloud-PA2200
* GPIO-LEDs for 2.4GHz, 5GHz-SoC and 5GHz-PCIE
* GPIO-LEDs for power (orange) and status (blue)
* 1x GPIO-button (reset)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x gigabit ethernet
- phy@mdio3:
+ Label: Ethernet 1
+ gmac0 (ethaddr) in original firmware
+ used as LAN interface
- phy@mdio4:
+ Label: Ethernet 2
+ gmac1 (eth1addr) in original firmware
+ 802.3at POE+
+ used as WAN interface
* 12V 2A DC
Flashing instructions:
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the factory image to the u-boot when the device boots up.
Signed-off-by: Marek Lindner <marek.lindner@kaiwoo.ai>
[sven@narfation.org: prepare commit message, rebase, use all LEDs, switch
to dualboot_datachk upgrade script, use eth1 as designated WAN interface] Signed-off-by: Sven Eckelmann <sven@narfation.org>
Marek Lindner [Sun, 25 Nov 2018 13:46:54 +0000 (21:46 +0800)]
ipq40xx: add support for Plasma Cloud PA1200
Device specifications:
* QCA IPQ4018
* 256 MB of RAM
* 32 MB of SPI NOR flash (w25q256)
- 2x 15 MB available; but one of the 15 MB regions is the recovery image
* 2T2R 2.4 GHz
- QCA4019 hw1.0 (SoC)
- requires special BDF in QCA4019/hw1.0/board-2.bin with
bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=PlasmaCloud-PA1200
* 2T2R 5 GHz
- QCA4019 hw1.0 (SoC)
- requires special BDF in QCA4019/hw1.0/board-2.bin with
bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=PlasmaCloud-PA1200
* 3x GPIO-LEDs for status (cyan, purple, yellow)
* 1x GPIO-button (reset)
* 1x USB (xHCI)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x gigabit ethernet
- phy@mdio4:
+ Label: Ethernet 1
+ gmac0 (ethaddr) in original firmware
+ used as LAN interface
- phy@mdio3:
+ Label: Ethernet 2
+ gmac1 (eth1addr) in original firmware
+ 802.3af/at POE(+)
+ used as WAN interface
* 12V/24V 1A DC
Flashing instructions:
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the factory image to the u-boot when the device boots up.
Signed-off-by: Marek Lindner <marek.lindner@kaiwoo.ai>
[sven@narfation.org: prepare commit message, rebase, use all LEDs, switch
to dualboot_datachk upgrade script, use eth1 as designated WAN interface] Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Sat, 21 Nov 2020 21:27:11 +0000 (22:27 +0100)]
ipq40xx: Change name for openmesh.sh to vendor-free name
Other vendors are using functionality similar to the ones OpenMesh used to
implement two areas on the flash to store the default image and a fallback
image. So just change the name to dualboot_datachk.sh to avoid duplicated
code just to have the same script for different vendors.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Mon, 23 Nov 2020 12:41:34 +0000 (13:41 +0100)]
ath79: Add support for Plasma Cloud PA300E
Device specifications:
* Qualcomm/Atheros QCA9533 v2
* 650/600/217 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash (mx25l12805d)
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 2T2R 2.4 GHz Wi-Fi
* multi-color LED (controlled via red/green/blue GPIOs)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ Label: Ethernet 1
+ 24V passive POE (mode B)
+ used as WAN interface
- eth1
+ Label: Ethernet 2
+ 802.3af POE
+ builtin switch port 2
+ used as LAN interface
* 12-24V 1A DC
* external antennas
Flashing instructions:
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the factory image to the u-boot when the device boots up.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Mon, 23 Nov 2020 12:41:34 +0000 (13:41 +0100)]
ath79: Add support for Plasma Cloud PA300
Device specifications:
* Qualcomm/Atheros QCA9533 v2
* 650/600/217 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash (mx25l12805d)
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 2T2R 2.4 GHz Wi-Fi
* multi-color LED (controlled via red/green/blue GPIOs)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ Label: Ethernet 1
+ 24V passive POE (mode B)
+ used as WAN interface
- eth1
+ Label: Ethernet 2
+ 802.3af POE
+ builtin switch port 2
+ used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the factory image to the u-boot when the device boots up.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Mon, 23 Nov 2020 15:57:31 +0000 (16:57 +0100)]
ath79: Fix fallback to bootloader cmdline on empty DT bootargs
The MIPS code is supposed to fall back to u-boots bootargs whenever the
/chosen/bootargs property is missing. But this feature was accidentally
disabled when the boot_command_line was initialized with an empty space
just to work around problems with early_init_dt_scan_chosen.
But this feature is necessary for some boards which have a dualboot
mechanism and whose u-boot is calculating the correct partition at runtime
without writing this information back to the u-boot-env.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Sun, 22 Nov 2020 12:12:09 +0000 (13:12 +0100)]
images: Fix sysupgrade.tar for devices with NOR flash
The NOR flash rootfs images stored in a sysupgrade.tar must end with the
JFFS2 marker. Otherwise, devices like OpenMesh A42/A62 are not able to
calculate the md5sum of the fixed squashfs part and store it inside the
u-boot-env.
But the commit ee76bd11bbe7 ("images: fix boot failures on NAND with small
sub pages") adds up to 1020 0x00 bytes after the 0xdead0de EOF marker. The
calculated md5sum will be wrong due do this change and u-boot will fail to
boot the newly flashed device with a message like:
Since the original change should not change the behavior of NOR images,
just check for the deadc0de marker at the end of the squashfs-jffs2 image
do avoid the problematic behavior for these images.
Fixes: ee76bd11bbe7 ("images: fix boot failures on NAND with small sub pages") Signed-off-by: Sven Eckelmann <sven@narfation.org>
MACs are labeled as WLAN and WAN
vendor MAC addresses in flash are duplicate
phy0 WLAN *:b8 ---
eth0 WAN *:b9 art 0x0/0x6
**Installation:**
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9f670000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
**Return to OEM:**
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
**TFTP recovery** (unstable / not reliable):
rename initramfs to 'vmlinux-art-ramdisk'
make available on TFTP server at 192.168.1.101
power board while holding or pressing reset button repeatedly
NOTE: for some Engenius boards TFTP is not reliable
try setting MTU to 600 and try many times
**Format of OEM firmware image:**
The OEM software of ECB350 v1 is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
The OEM upgrade script is at /etc/fwupgrade.sh.
OKLI kernel loader is required because the OEM software
expects the kernel size to be no greater than 1536k
and otherwise the factory.bin upgrade procedure would
overwrite part of the kernel when writing rootfs.
The factory upgrade script follows the original mtd partitions.
**Note on PLL-data cells:**
The default PLL register values will not work
because of the AR8035 switch between
the SOC and the ethernet port.
For AR724x series, the PLL register for GMAC0
can be seen in the DTSI as 0x2c.
Therefore the PLL register can be read from u-boot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x1805002c 1`
However the registers that u-boot sets are not ideal and sometimes wrong...
the at803x driver supports setting the RGMII clock/data delay on the PHY side.
This way the pll-data register only needs to handle invert and phase.
for this board no extra adjustements are needed on the MAC side
all link speeds functional
Chen Minqiang [Tue, 24 Nov 2020 17:53:39 +0000 (01:53 +0800)]
ath79: add support for GL.iNet GL-USB150
Add support for the ar71xx supported GL.iNet GL-USB150 to ath79.
GL.iNet GL-USB150 is an USB dongle WiFi router, based on Atheros AR9331.
Specification:
- 400/400/200 MHz (CPU/DDR/AHB)
- 64 MB of RAM (DDR2)
- 16 MB of FLASH (SPI NOR)
- Realtek RTL8152B USB to Ethernet bridge (connected with AR9331 PHY4)
- 1T1R 2.4 GHz
- 2x LED, 1x button
- UART header on PCB
Flash instruction:
Vendor software is based on openwrt so you can flash the sysupgrade
image via the vendor GUI or using command line sysupgrade utility.
Make sure to not save configuration over reflash as uci settings
differ between versions.
Michael Pratt [Fri, 27 Nov 2020 00:11:15 +0000 (19:11 -0500)]
ath79: enable factory.bin and adjust profile of ECB1750
factory.bin was not tested for ECB1750...
but it was tested on it's sister board ECB1200
The product ID for the header can be verified by inspecting
the header of OEM images, or in the u-boot environment.
Also:
- the LAN LED is controlled directly by the AR8035 switch
- the labelled (first increment) MAC for both is ethaddr (eth0)
- list packages in alphabetical order
- use default sysupgrade.bin recipe
MAC Addresses are labeled as ETH and 5GHZ
U-boot environment has the vendor MAC addresses
MAC addresses in ART do not match vendor
eth0 ETH *:5c u-boot-env ethaddr
phy0 5GHZ *:5d u-boot-env athaddr
---- ---- ???? art 0x0/0x6
**Installation:**
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
(see TFTP recovery)
perform a sysupgrade
**Serial Access:**
the RX line on the board for UART is shorted to ground by resistor R176
therefore it must be removed to use the console
but it is not necessary to remove to view boot log
optionally, R175 can be replaced with a solder bridge short
the resistors R175 and R176 are next to the UART pinout at JP1
**Return to OEM:**
If you have a serial cable, see Serial Failsafe instructions
Unlike most Engenius boards, this does not have a 'failsafe' image
the only way to return to OEM is TFTP or serial access to u-boot
**TFTP recovery:**
Unlike most Engenius boards, TFTP is reliable here
rename initramfs-kernel.bin to 'ap.bin'
make the file available on a TFTP server at 192.168.1.10
power board while holding or pressing reset button repeatedly
or with serial access:
run `tftpboot` or `run factory_boot` with initramfs-kernel.bin
then `bootm` with the load address
**Format of OEM firmware image:**
The OEM software of ECB1200 is a heavily modified version
of Openwrt Altitude Adjustment 12.09.
This Engenius board, like ECB1750, uses a proprietary header
with a unique Product ID. The header for factory.bin is
generated by the mksenaofw program included in openwrt.
**Note on PLL-data cells:**
The default PLL register values will not work
because of the AR8035 switch between
the SOC and the ethernet port.
For QCA955x series, the PLL registers for eth0 and eth1
can be see in the DTSI as 0x28 and 0x48 respectively.
Therefore the PLL registers can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x18050028 1` and `md 0x18050048 1`.
However the registers that u-boot sets are not ideal and sometimes wrong...
the at803x driver supports setting the RGMII clock/data delay on the PHY side.
This way the pll-data register only needs to handle invert and phase.
for this board clock invert is needed on the MAC side
all link speeds functional
Sven Eckelmann [Wed, 25 Nov 2020 09:48:57 +0000 (10:48 +0100)]
scripts/om-fwupgradecfg-gen.sh: Generate checksum over whole squashfs
The rootfs is padded to the full block size by padjffs2 and a 4 byte magic
value ("deadc0de") is added to the end. On first boot, the JFFS2 is
replacing the "deadc0de" marker when the rootfs_data is initialized.
The static part of the rootfs is therefore $rootfs_size - 4 and not
$rootfs_size - 262144 - 4.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
MAC Addresses are labeled as WAN and WLAN
U-boot environment has the the vendor MAC address for ethernet
MAC addresses in "factory" are part of wifi calibration data
OEM webpage at 192.168.0.1
username and password "admin"
Navigate to Network Setting --> Tools --> Firmware
Click Browse and select the factory.dlf image
Click Continue to confirm and wait 6 minutes or more...
Method 2: Serial console to load TFTP image:
(see TFTP recovery)
**Return to OEM:**
Unlike most Engenius boards, this does not have a 'failsafe' image
the only way to return to OEM is serial access to uboot
Unlike most Engenius boards, public images are not available...
so the only way to return to OEM is to have a copy
of the MTD partition "firmware" BEFORE flashing openwrt.
**TFTP recovery:**
Unlike most Engenius boards, TFTP is reliable here
however it requires serial console access
(soldering pins to the UART pinouts)
build your own image...
with 'ramdisk' selected under 'Target Images'
rename initramfs-kernel.bin to 'uImageESR-600H'
make the file available on a TFTP server at 192.168.99.8
interrupt boot by holding or pressing '4' in serial console
as soon as board is powered on
`tftpboot 0x81000000`
`bootm 0x81000000`
perform a sysupgrade
**Format of OEM firmware image:**
This Engenius board uses the Senao proprietary header
with a unique Product ID. The header for factory.bin is
generated by the mksenaofw program included in openwrt.
.dlf file extension is also required for OEM software to accept it
**Note on using OKLI:**
the kernel is now too large for the bootloader to handle
so OKLI is used via the `kernel-loader` image command
recently in master several other ramips boards have the same problem
'Kernel panic - not syncing: Failed to find ralink,rt3883-sysc node'
Rosen Penev [Sat, 12 Dec 2020 03:25:45 +0000 (19:25 -0800)]
toolchain: remove uClibc-ng
After musl was introduced, it was desired to remove uClibc-ng. As ARC
has no musl support, it was kept around. However, glibc 2.32 includes
ARC support. This makes it possible to finally remove it.
Sander Vanheule [Sat, 12 Dec 2020 16:02:00 +0000 (17:02 +0100)]
realtek: use kernel defined halt
If _machine_hang is not defined on MIPS, the kernel will check if the
CPU can enter a more power efficient sleep mode. Since the realtek
platform supports mips32_r2, this should issue a WAIT instruction
instead of a trivial infinite loop.
Nick Lowe [Sun, 13 Dec 2020 11:39:12 +0000 (11:39 +0000)]
hostapd: Use EAPOLv1 (802.1X-2001) if WPA enabled
Currently, EAPOLv2 (802.1X-2004) is used by default for legacy clients that
are not WPA2 (RSN) capable. These legacy clients are often intolerant to this
EAPOL version and fail to connect.
hostapd.conf upstream documents for eapol_version the following and that this
is a known compatibility issue with version 2:
// IEEE 802.1X/EAPOL version
// hostapd is implemented based on IEEE Std 802.1X-2004 which defines EAPOL
// version 2. However, there are many client implementations that do not handle
// the new version number correctly (they seem to drop the frames completely).
// In order to make hostapd interoperate with these clients, the version number
// can be set to the older version (1) with this configuration value.
// Note: When using MACsec, eapol_version shall be set to 3, which is
// defined in IEEE Std 802.1X-2010.
//eapol_version=2
For the wpa parameter, hostapd.conf upstream documents that this is a bitfield,
configured as follows:
// Enable WPA. Setting this variable configures the AP to require WPA (either
// WPA-PSK or WPA-RADIUS/EAP based on other configuration). For WPA-PSK, either
// wpa_psk or wpa_passphrase must be set and wpa_key_mgmt must include WPA-PSK.
// Instead of wpa_psk / wpa_passphrase, wpa_psk_radius might suffice.
// For WPA-RADIUS/EAP, ieee8021x must be set (but without dynamic WEP keys),
// RADIUS authentication server must be configured, and WPA-EAP must be included
// in wpa_key_mgmt.
// This field is a bit field that can be used to enable WPA (IEEE 802.11i/D3.0)
// and/or WPA2 (full IEEE 802.11i/RSN):
// bit0 = WPA
// bit1 = IEEE 802.11i/RSN (WPA2) (dot11RSNAEnabled)
// Note that WPA3 is also configured with bit1 since it uses RSN just like WPA2.
// In other words, for WPA3, wpa=2 is used the configuration (and
// wpa_key_mgmt=SAE for WPA3-Personal instead of wpa_key_mgmt=WPA-PSK).
//wpa=2
For client compatibility therefore:
EAPOLv1 (802.1X-2001) should be used by default where WPA is enabled.
EAPOLv2 (802.1X-2004) should be used by default where WPA is disabled.
To fix this, we can therefore change in the script:
set_default eapol_version 0
To the following:
set_default eapol_version $((wpa & 1))
This therefore:
1) Sets eapol_version to 1 where WPA has been enabled via wpa bit0 being set.
2) Sets eapol_version to 0 where WPA has been disabled via wpa bit0 being unset.
For usual configurations that only have WPA2 enabled, EAPOLv2 is then used.
INAGAKI Hiroshi [Thu, 17 Dec 2020 14:58:16 +0000 (23:58 +0900)]
ramips: unify elecom-*-factory for ELECOM WRC-GHBK2-S/GS/GST devices
Most of Build/elecom-wrc-factory and Build/elecom-wrc-gs-factory are
nearly equal, Unify those definitions by using "-N" option of mkhash and
splitting the appending text at the end of firmware image for WRC-GS/GST
devices.
The Buffalo Linkstation LS421DE comes with a Ricoh RS5C372A real time
clock. This RTC has the INTRA pin connected to the power management
circuit, allowing to wake up the device from the power off state when an
alarm is scheduled.
Add the "wakeup-source" property in the RTC dts node to allow the use
of the alarm.
Example of use, the device is powered off and it comes to life after 5
minutes:
echo $(expr $(date '+%s') + 60 * 5) > /sys/class/rtc/rtc0/wakealarm
poweroff
This feature isn't available in the stock firmware.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
The rs5c372 RTC driver has alarm support, but it can't be enabled and only
can handle 24 hours in the future spite the chip is 1 week capable. Provide
these two patches:
- Support alarms up to 1 week
- Let the wakealarm to be used as a wakeup source
This patch makes the alarm wakeup feature to be available in the Buffallo
Linkstation LS421DE (mvebu target) and should also work with any other
device if the hardware has the proper capability.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
The Buffalo Linkstation LS421DE isn't able to enable the Level 2 cache
(AKA Aurora cache). As of result of this, the throughput is about half of
the expected, e.g when doing network data transfers.
Fix it by adding the broken-idle property in the coherency fabric node.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
tegra: image: remove unnecessary assumptions from bootscript
'bootz' expects gziped kernel image anyway, so hard-code it to zImage,
and remove root path from 'load' commands, by default the files are
searched in root directory.
This will make the bootscript static, so the command which modified it
when image was created can now be removed.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
/usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Rosen Penev [Thu, 15 Oct 2020 06:03:25 +0000 (23:03 -0700)]
fs/cifs: update module dependencies
0fdfef9aa7ee68ddd508aef7c98630cfc054f8d6 upstream removed CIFS_SMB311.
Kernels 4.19 and above do not have it. Currently only kernels 4.19 and
5.4 are in the tree.
The Kconfig file in the kernel has more selection that what is in here.
Add the rest and reorder based on upstream ordering.
projects / thirdparty / openwrt.git / log
