The firmware loading does not depend (solely) on the PHY id. The driver
needs to read out the vendor version id of the PHY before it can decide
which firmware file needs to be loaded.
A split in an RTL8261N and an RTL8264B firmware package is therefore
misleading. And it could even be that a product ships an RTL8264B but
switches the revision of the chip in the middle of its product lifetime. In
this case, the first identification based on the chip ID or the actual chip
ID for the OpenWrt porter might fail for another user with a later/earlier
produced device.
Shipping both files in the same package avoids this problem. Only the "low
power" firmware package is slightly misleading because there is only a
RTL8261N firmware binary for low power but no corresponding RTL8264B
version. It will ship simply the non-low power version for RTL8264B.
Suggested-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/23947
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The gmac1 is not used and doesn't have any mac address configured. The
gmac0 has the nvmem-cells set and can actually be used to retrieve the
correct mac address.
Fixes: c7c54f3134 ("ramips: add support for Plasma Cloud PAX1800-Lite")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/23441
Signed-off-by: Robert Marko <robimarko@gmail.com>
The nRESET pins of the RTL8224 PHY on the MCX3 are wired to GPIO6 of the
SoC, but this was never described in the devicetree.
Commit c99a30668d ("realtek: add RTL8224 initialization to Realtek
driver") introduced support for reinitializing RTL8224 PHYs, and commit
084da38a2e ("realtek: mdio: activate multiple busses") allowed the MDIO
bus provider load the devicetree properties to the bus, including reset
descriptors. With both in place, a bus level PHY reset via the hardware pin
is now correctly triggered before reinitialization.
Add the missing reset-gpios property so the PHY can be reset via the
hardware pin.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/22966
Signed-off-by: Robert Marko <robimarko@gmail.com>
PHY drivers might need access to NVMEM or the filesystem to load
calibration/initialization data. The driver will then return -EPROBE_DEFER
to signal to the device core that the probe should be retried multiple
times again in the 10s driver_deferred_probe_timeout.
But when the switch driver calls dsa_register_switch(), it needs to connect
the PHYs directly. As result, all PHYs without an driver will automatically
get the default driver (either `genphy_c45_driver` or `genphy_driver`)
assigned and initialized. But for PHYs with the additional initialization
data from NVMEM/fs, this will usually result in not working PHYs.
Since there are Realtek based boards with RTL826x PHYs and the new driver
loads the initialization/patch values from rootfs, it is necessary to check
in the beginning of the probe function whether the PHYs are ready and the
probing can continue.
If some driver is still without driver after the deferred probe period
ended, the loading will just continue and the generic PHY drivers will
still be used.
Closes: #22811
Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Co-authored-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/23075
Signed-off-by: Robert Marko <robimarko@gmail.com>
In the past, all the configuration of SerDes and PHYs on the realtek
switches were done using u-boot (`rtk init`). But since RTL930x switched
to SerDes configuration under Linux, the SoC side is no longer using the
Realtek-proprietary variant of USXGMII. The communication to the RTL8261N
PHYs on those switches broke because of this incompatibility.
Enabling the full initialization on `CONFIG_MACH_REALTEK_RTL` converts also
the PHY side to the standard USXGMII and therefore ensures that both sides
speak the same dialect.
Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/23076
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The PHY register patch in question is gated by `CONFIG_MACH_REALTEK_RTL`,
has no documented/expected behavior, and is in practice unreachable:
`phy_patch()` is only called from `rtkphy_config_init()`, which is exits
(too) early for `CONFIG_MACH_REALTEK_RTL` builds.
Remove it as a cleanup step before enabling standard USXGMII configuration
for these PHYs.
Fixes: b77fa45d12 ("kernel: fix rtl8261n driver for realtek")
Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/23076
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The MCU (GD32E230G8) which controls the RTL8239 POE++ PSE chips can
sometimes hang. In this case, it is necessary to to reset the chip using
the nRESET pin which is connected to the GPIO1 of the RTL8231 GPIO
expander.
For a reset, the `/sys/class/gpio/poe_mcu_reset/value` file must be set to
1 for a short period and then back to 0. After that, the poemgr must be
"restarted" to the MCU back in the expected state.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/22916
Signed-off-by: Robert Marko <robimarko@gmail.com>
The parameters must be aligned based on the last opened parenthesis
(+1). If this not a multiple of the tab size (8) then the rest
alignment must be done using spaces.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
uint(8|16|32|64)_t and int(8|16|32|64)_t types should not be used in
kernel code. The shorter s(8|16|32|64) and u(8|16|32|64) or the
endianness specific versions (le*, be*) must be used instead.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
It is preferred in the Linux kernel to use the short type name
"unsigned long" instead of "unsigned long int". The same is true
for short and the signed version of the types.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
It is not allowed in the Linux kernel to have the condition and
the actual statement(s) on the same line. This is required to
make it easier to identify the body of an if/do/while/for/..
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Global array initialization must have the open brace on the first
line and the next lines must be intended by one level. The closing
brace must be one a separate line.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
It can happen that the calculation `start + (HZ / 1000) * timeout`
overflows `unsigned long`. This must be handled correctly to avoid too long
waits. Luckily, the `time_before()` helper already does this.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
strcpy doesn't check the length of the destination buffer. And strlcpy
would not make sure to null-terminate the destination buffer.
Even when it is clear that this string will fit in the currrent buffer, it
is just best practice to avoid strcpy.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
It is preferred to have the whole quoted string on a single line to make it
easier to find these lines in the source code (while grep'ing). And since
these quotes are inside a string, they will also add unwanted whitespaces.
At the same time, add the missing newine at the end of the `pr_debug`
lines.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
There is no external component using these functions and these functions
are local to the current translation unit. These functions can therefore be
declared static.
The currently unused *_field functions were kept because they might be used
in the future.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The common declarations should not be spread around in different source
files but kept inside the header files. This is unfortunately currently not
the best place to store them because soc_info is actually from non-DSA
code. But it is at least better than having them in diffent source files.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In net code, it is preferred to have block comments which
* either are one line: `/* ... */`
* multiple lines with:
- starting with the first comment line directly: `/* ...`
- each line is intended with the first asterisk: ` * ...`
- the last line is just the end of the comment: ` */`
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In contrast to variables, functions don't need extern declarations. It is
also preferred in the kernel not to use extern in front of function
declarations.
The extern+static parts in clk-rtl83xx.c were skipped because they are a
little bit unexpected ("extern *_dram_set_rate" are never used, "static
_sram_set_rate" are used but should from the C code perspective always be
NULL). This is left for an interested reader with the correct test HW and
some interests to dig in the code from commit 4850bd887c ("realtek: add
RTL83XX clock driver") for the *_dram_set_rate -> *_sram_set_rate
relocation and how these SRAM function pointers are set in this translation
unit.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The macros will be inserted as is by the pre-compiler into places which
uses them. This can cause weird effects because this can break the syntax
or the ordering of operations. Just adding parentheses can avoid a lot of
these unexpected effects.
(for even more complex, multi-expression macros, `do {...} while (0)` is
required).
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20906
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The commit 1cfd45ae0b ("realtek: Add debugfs support for RTL9300") caused
previously an out of bounds access on the array holding the names of drop
counters (and incorrect names in the output) fur RTL839x because of a
missing comma. To avoid such situation in the future, calculate the size of
the array during compilation. And to ensure that this count matches the
actual number of counters in HW, compare this number during compile time
with the expected value.
Suggested-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20905
Signed-off-by: Robert Marko <robimarko@gmail.com>
The counter names "CFM" and "VLAN_IGR_FLTR" were not separated by a comma
in the `rtl839x_drop_cntr` array. As result, these two headers were merged
to a single header "CFMVLAN_IGR_FLTR" and everything after that was shifted
by one. The last name (for the 45th counter) was also not defined and was
therefore accessing data outside the array.
Fixes: 1cfd45ae0b ("realtek: Add debugfs support for RTL9300")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20905
Signed-off-by: Robert Marko <robimarko@gmail.com>
Sources files should used for the proper indentation:
* use tabs instead of 8 spaces
* spaces should never directly before a tab
* no whitespace characters at the end of a line
These rules were partially not followed in various source files.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20895
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Registers must not be accessed in parallel by multiple drivers.
Read-modify-write operations are not atomic, and the result of parallel
access is undefined.
The MAC_L2_GLOBAL_CTRL2 register is essentially a pin configuration
register and is represented by a pinmux node in the devicetree. Operations
on this register by the realtek,rtl838x-eth driver must therefore also be
reflected in the devicetree.
Since the MDIO sets used are board-specific, the pins must be enabled in
the board’s devicetree. This can be achieved using the pinctrl properties
for the realtek,rtl83xx-switch.
&switch0 {
pinctrl-names = "default";
pinctrl-0 = <&pinmux_enable_mdc_mdio_0>,
<&pinmux_enable_mdc_mdio_1>;
....
};
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/19815
Signed-off-by: Robert Marko <robimarko@gmail.com>
The pinmux-related registers on the RTL931X SoC family are spread across
various non-consecutive registers. It might be tempting to modify them
directly in a specific driver (SPI, LED, etc.), but this would cause issues
with parallel, non-locked read-modify-write operations, which are required
to update individual portions of these registers.
Instead, it is better to use the devicetree pinctrl properties to define
the correct configurations for the various operation modes.
One important setting here is the LED Sync bit. This allows the LED
controller to generate an additional positive edge on the `STCP`
("STore Clock Pin", also known as `RCLK`) of the LED shift register after
the actual content has already been shifted in using the normal shift
clock. The LED shift register is then expected to copy the content from the
shift register section into the storage registers, which act as the actual
LED output control. This functionality is available in, and commonly used
with, the SNx4HC595 family of shift registers.
To activate it, simply register it in the default state of the
"realtek,rtl83xx-switch" node:
&switch0 {
pinctrl-names = "default";
pinctrl-0 = <&pinmux_enable_led_sync>;
....
};
It would be nicer when this can be directly added to the led subnode. But
for this to work, `realtek,rtl9300-leds` must first be an actual driver
(known to the driver core).
[1] https://www.ti.com/lit/ds/symlink/sn74hc595.pdf
Suggested-by: Bevan Weiss <bevan.weiss@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/19815
Signed-off-by: Robert Marko <robimarko@gmail.com>
The MAC_L2_GLOBAL_CTRL2 register is primarily used for pin configuration.
It is necessary to select specific modes for pins or to free them for use
as GPIOs.
Fixes: 9dbc04785c ("realtek: add rtl8231-aux to rtl931x.dtsi")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/19815
Signed-off-by: Robert Marko <robimarko@gmail.com>
The pinmux-related registers on the RTL930X SoC family are spread across
various non-consecutive registers. It might be tempting to modify them
directly in a specific driver (SPI, LED, etc.), but this would cause issues
with parallel, non-locked read-modify-write operations, which are required
to update individual portions of these registers.
Instead, it is better to use the devicetree pinctrl properties to define
the correct configurations for the various operation modes.
One important setting here is the LED Sync bit. This allows the LED
controller to generate an additional positive edge on the `STCP`
("STore Clock Pin", also known as `RCLK`) of the LED shift register after
the actual content has already been shifted in using the normal shift
clock. The LED shift register is then expected to copy the content from the
shift register section into the storage registers, which act as the actual
LED output control. This functionality is available in, and commonly used
with, the SNx4HC595 family of shift registers.
To activate it, simply register it in the default state of the
"realtek,rtl83xx-switch" node:
&switch0 {
pinctrl-names = "default";
pinctrl-0 = <&pinmux_enable_led_sync>;
....
};
It would be nicer when this can be directly added to the led subnode. But
for this to work, `realtek,rtl9300-leds` must first be an actual driver
(known to the driver core).
[1] https://www.ti.com/lit/ds/symlink/sn74hc595.pdf
Suggested-by: Bevan Weiss <bevan.weiss@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/19815
Signed-off-by: Robert Marko <robimarko@gmail.com>
If the dnsmasq process forks to handle TCP connections, it closes the ubus
context. But instead of changing the daemon wide pointer to NULL, only the
local variable was adjusted - and this portion of the code was even dropped
(dead store) by some optimizing compilers.
It makes more sense to change the daemon->ubus pointer because various
functions are already checking it for NULL. It is also the behavior which
ubus_destroy() implements.
Fixes: d8b33dad0b ("dnsmasq: add support for monitoring and modifying dns lookup results via ubus")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
* ethernet1:
- physical port label "Ethernet 1"
- its mac address is printed on the device label
* ethernet2:
- physical port label "Ethernet 2"
- can be used to power the device
Both ports are not marked by there role (because the vendor firmware
automatically detects roles) but the "Ethernet 2" port was used in the past
for "WAN" functionality in OpenWrt.
Tested-by: Michaël BILCOT <michael.bilcot@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The calibration data and mac addresses on this device are stored in the
0:ART partition. It is therefore possible to move the code to handle them
directly to the devicetree instead of the various scripts.
But the actual relevant information about the partition layout is provided
by the bootloader via bootargs (mtdparts) and not via the devicetree
itself. Instead of using a fixed-partition template, the mtd dynamic
partitions support from the upstream kernel is used.
Reported-by: Robert Marko <robert.marko@sartura.hr>
Tested-by: Michaël BILCOT <michael.bilcot@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
* ethernet1:
- physical port label "Ethernet 1"
- its mac address is printed on the device label
* ethernet2:
- physical port label "Ethernet 2"
- can be used to power the device
Both ports are not marked by there role (because the vendor firmware
automatically detects roles) but the "Ethernet 2" port was used in the past
for "WAN" functionality in OpenWrt.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The calibration data and mac addresses on this device are stored in the
0:ART partition. It is therefore possible to move the code to handle them
directly to the devicetree instead of the various scripts.
But the actual relevant information about the partition layout is provided
by the bootloader via bootargs (mtdparts) and not via the devicetree
itself. Instead of using a fixed-partition template, the mtd dynamic
partitions support from the upstream kernel is used.
Reported-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The calibration data and mac addresses on this device are stored in the
0:ART partition. It is therefore possible to move the code to handle them
directly to the devicetree instead of the various scripts.
But the actual relevant information about the partition layout is provided
by the bootloader via bootargs (mtdparts) and not via the devicetree
itself. Instead of using a fixed-partition template, the mtd dynamic
partitions support from the upstream kernel is used.
Reported-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Tested-by: Michaël BILCOT <michael.bilcot@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The calibration data and mac addresses on this device are stored in the
0:ART partition. It is therefore possible to move the code to handle them
directly to the devicetree instead of the various scripts.
But the actual relevant information about the partition layout is provided
by the bootloader via bootargs (mtdparts) and not via the devicetree
itself. Instead of using a fixed-partition template, the mtd dynamic
partitions support from the upstream kernel is used.
Reported-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
* ethernet1:
- physical port label "Ethernet 1"
- can be used to power the device
- its mac address is printed on the device label
* ethernet2:
- physical port label "Ethernet 2"
Both ports are not marked by there role (because the vendor firmware
automatically detects roles) but the "Ethernet 1" port was used in the past
for "WAN" functionality in OpenWrt.
Reviewed-by: Robert Marko <robimarko@gmail.com>
Tested-by: Michaël BILCOT <michael.bilcot@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
* ethernet1:
- physical port label "Ethernet 1"
- can be used to power the device
- its mac address is printed on the device label
* ethernet2:
- physical port label "Ethernet 2"
Both ports are not marked by there role (because the vendor firmware
automatically detects roles) but the "Ethernet 1" port was used in the past
for "WAN" functionality in OpenWrt.
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The sector number must be stored in hex. Otherwise, the number (like 16)
will be parsed as hex and any write to the partition will end up with an
error like:
MTD erase error on /dev/mtd5: Invalid argument
Fixes: 9adfeccd84 ("uboot-envtools: Add support for IPQ806x AP148 and DB149")
Fixes: 54b275c8ed ("ipq40xx: add target")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@fungible.com>
All devices which used this package migrated to the kernel GPIO-line
watchdog driver and configure it over their DT.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The commit 04e91631e0 ("om-watchdog: add support for Teltonika RUT5xx
(ramips)") used the deprecated om-watchdog daemon to handle the GPIO-line
connected watchdog on the Teltonika RUT5xx.
But this daemon has massive problems since commit 30f61a34b4
("base-files: always use staged sysupgrade"). The process will always be
stopped on sysupgrades. If the sysupgrade takes slightly longer, the
watchdog is not triggered at the correct time and thus the sysupgrade will
interrupted hard by the watchdog sysupgrade. And this hard interrupt can
easily brick the device when there is no fallback (dual-boot, ...).
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR7240 rev 2
* 350/350/175 MHz (CPU/DDR/AHB)
* 32 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 1T1R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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
+ 18-24V passive POE (mode B)
+ used as WAN interface
- eth1
+ builtin switch port 4
+ used as LAN interface
* 12-24V 1A DC
* external antenna
The device itself requires the mtdparts from the uboot arguments to
properly boot the flashed image and to support dual-boot (primary +
recovery image). Unfortunately, the name of the mtd device in mtdparts is
still using the legacy name "ar7240-nor0" which must be supplied using the
Linux-specfic DT parameter linux,mtd-name to overwrite the generic name
"spi0.0".
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
On ar71xx, it was possible to overwrite the name of the spi-nor mtd device
identifier using the flash_platform_data which each mach-*.c could adjust
for its devices. A similar feature was introduced for mtd-physmap in
devicetree's. The property linux,mtd-name can be used to set the name and
provide a stable identifier for mtdpart from the bootloader.
But this feature is not yet available upstream for spi-nor devices which
also might receive their partition layout from the bootloader. But the
OpenWrt pistachio support for this property can simply be imported into
ath79 to gain this support.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/200 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi (11n)
* 2T2R 5 GHz Wi-Fi (11ac)
* 4x GPIO-LEDs (3x wifi, 1x power)
* 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)
* TI tmp423 (package kmod-hwmon-tmp421) for temperature monitoring
* 2x ethernet
- eth0
+ AR8035 ethernet PHY (RGMII)
+ 10/100/1000 Mbps Ethernet
+ 802.3af POE
+ used as LAN interface
- eth1
+ AR8031 ethernet PHY (RGMII)
+ 10/100/1000 Mbps Ethernet
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
This device support is based on the partially working stub from commit
53c474abbd ("ath79: add new OF only target for QCA MIPS silicon").
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi (11n)
* 2T2R 5 GHz Wi-Fi (11ac)
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* external h/w watchdog (enabled by default))
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* TI tmp423 (package kmod-hwmon-tmp421) for temperature monitoring
* 2x ethernet
- eth0
+ AR8035 ethernet PHY (RGMII)
+ 10/100/1000 Mbps Ethernet
+ 802.3af POE
+ used as LAN interface
- eth1
+ AR8035 ethernet PHY (SGMII)
+ 10/100/1000 Mbps Ethernet
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9344 rev 2
* 560/450/225 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 1T1R 2.4 GHz Wi-Fi
* 2T2R 5 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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)
* TI tmp423 (package kmod-hwmon-tmp421) for temperature monitoring
* 2x ethernet
- eth0
+ AR8035 ethernet PHY
+ 10/100/1000 Mbps Ethernet
+ 802.3af POE
+ used as LAN interface
- eth1
+ 10/100 Mbps Ethernet
+ builtin switch port 1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
ag71xx_probe is registering ag71xx_interrupt as handler for the gmac0/gmac1
interrupts. The handler is trying to use napi_schedule to handle the
processing of packets. But the netif_napi_add for this device is
called a lot later in ag71xx_probe.
It can therefore happen that a still running gmac0/gmac1 is triggering the
interrupt handler with a bit from AG71XX_INT_POLL set in
AG71XX_REG_INT_STATUS. The handler will then call napi_schedule and the
napi code will crash the system because the ag->napi is not yet
initialized:
libphy: Fixed MDIO Bus: probed
CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 81373408
Oops[#1]:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.4.152 #0
$ 0 : 00000000 00000001 00000000 8280bf28
$ 4 : 82a98cb0 00000000 81620000 00200140
$ 8 : 00000000 00000000 74657272 7570743a
$12 : 0000005b 8280bdb9 ffffffff ffffffff
$16 : 00000001 82a98cb0 00000000 8280bf27
$20 : 8280bf28 81620000 ffff8b00 8280bf30
$24 : 00000000 8125af9c
$28 : 82828000 8280bed8 81610000 81373408
Hi : 00005fff
Lo : 2e48f657
epc : 00000000 0x0
ra : 81373408 __napi_poll+0x3c/0x11c
Status: 1100dc03 KERNEL EXL IE
Cause : 00800008 (ExcCode 02)
BadVA : 00000000
PrId : 00019750 (MIPS 74Kc)
Modules linked in:
Process swapper (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=00000000)
Stack : ffff8afb ffff8afa 81620000 00200140 00000000 82a98cb0 00000008 0000012c
81625620 81373684 ffffffff ffffffff ffffffef 00000008 816153d8 81620000
815b0d60 815bbd54 00000000 81753700 8280bf28 8280bf28 8280bf30 8280bf30
81753748 00000008 00000003 00000004 0000000c 00000100 3fffffff 8175373c
816059f0 814ddb48 00000001 8160ab30 81615488 810618bc 00000006 00000000
...
Call Trace:
[<81373684>] net_rx_action+0xfc/0x26c
[<814ddb48>] __do_softirq+0x118/0x2ec
[<810618bc>] handle_percpu_irq+0x50/0x80
[<8125ab8c>] plat_irq_dispatch+0x94/0xc8
[<81004e98>] handle_int+0x138/0x144
Code: (Bad address in epc)
---[ end trace a60d797432b656b2 ]---
The gmcc0/gmac1 must be brought in a state in which it doesn't signal a
AG71XX_INT_POLL related status bits as interrupt before registering the
interrupt handler. ag71xx_hw_start will take care of re-initializing the
AG71XX_REG_INT_ENABLE.
Fixes: f529a37420 ("surprise :p")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The official Plasma Cloud firmware adjusted the BDFs to contain new
conformance test limits and target power values. These should be imported
to avoid emissions outside the allowed limits.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The ipq-wifi-netgear_wac510 package is not selected by any device and would
be empty anyway. The default board-2.bin from ath10k-board-qca4019 is
therefore used for this device and the package doesn't provide any visible
features.
Fixes: b126d9c3a3 ("ipq40xx: add netgear wac510 support")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The board data file for the Plasma Cloud PA2200 is not part of the default
board-2.bin which is shipped by ath10k-board-qca4019. A typo in the device
package name resulted in a not correctly selected package for the device
specific board-2.bin. The wifi driver has therefore loaded the wrong
calibration information into the wifi chip.
Fixes: 4871fd2616 ("ipq40xx: add support for Plasma Cloud PA2200")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The board data file for the Plasma Cloud PA1200 is not part of the default
board-2.bin which is shipped by ath10k-board-qca4019. A typo in the device
package name resulted in a not correctly selected package for the device
specific board-2.bin. The wifi driver has therefore loaded the wrong
calibration information into the wifi chip.
Fixes: ea5bb6bbfe ("ipq40xx: add support for Plasma Cloud PA1200")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The board data file for the EnGenius EMR3500 is not part of the default
board-2.bin which is shipped by ath10k-board-qca4019. As result, the wrong
calibration information will be loaded into the wifi chip.
Fixes: 3f61e5e1b9 ("ipq40xx: add support for EnGenius EMR3500")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The board data file for the EnGenius EMD1 is not part of the default
board-2.bin which is shipped by ath10k-board-qca4019. As result, the wrong
calibration information will be loaded into the wifi chip.
Fixes: 51f3035978 ("ipq40xx: add support for EnGenius EMD1")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi (11n)
* 2T2R 5 GHz Wi-Fi (11ac)
* 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 ethernet
- eth0
+ Label: Ethernet 1
+ AR8035 ethernet PHY (RGMII)
+ 10/100/1000 Mbps Ethernet
+ 802.3af POE
+ used as WAN interface
- eth1
+ Label: Ethernet 2
+ AR8035 ethernet PHY (SGMII)
+ 10/100/1000 Mbps Ethernet
+ used as LAN interface
* 1x USB
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi (11n)
* 3T3R 5 GHz Wi-Fi (11ac)
* 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 ethernet
- eth0
+ Label: Ethernet 1
+ AR8035 ethernet PHY (RGMII)
+ 10/100/1000 Mbps Ethernet
+ 802.3af POE
+ used as WAN interface
- eth1
+ Label: Ethernet 2
+ AR8031 ethernet PHY (SGMII)
+ 10/100/1000 Mbps Ethernet
+ used as LAN interface
* 1x USB
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The GL.iNet GL-MV1000 is booting from eMMC and the images for it are in
theory sysupgrade compatible. But the platform upgrade scripts were not
adjusted to select the mmcblock device as upgrade target. This resulted in
a failed sysupgrade because the mtd device (NOR flash) was instead tried to
be modified by the sysupgrade script.
Fixes: 050c24f05c ("mvebu: add support for GL.iNet GL-MV1000")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The original GL.iNet firmware has two different mac addresses in the
factory/art partition. The first one is for the WAN interface only and the
second one is for both lan0 and lan1.
But the original submission for OpenWrt didn't initialize the mac
addresses of the LAN ports for the DSA device at all. The ethernet mac
address was then used for all DSA ports.
Fixes: 050c24f05c ("mvebu: add support for GL.iNet GL-MV1000")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The original patch to support this device advertised support for the reset
button and the "switch" in the commit message. But neither were actually
integrated in the device tree or documented anywere.
The button itself is now used to trigger a reset (as described in the
official GL.iNet documentation). The switch itself is registered as BTN_0
like other devices from GL.iNet in ath79.
Fixes: 050c24f05c ("mvebu: add support for GL.iNet GL-MV1000")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi (11n)
* 3T3R 5 GHz Wi-Fi (11ac)
* 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
* 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)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[rebase, add LED migration]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi (11n)
* 3T3R 5 GHz Wi-Fi (11ac)
* 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
* 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)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[rebase, apply shared DTSI/device node, add LED migration]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The OpenMesh MR900 is a modified version of the Exx900/Exx1750 family.
These devices are shipped with an AR803x PHY and had various problems with
the delay configuration in ar71xx. These problems are now in the past [1]
and parts of the delay configuration should now be done in the PHY only.
Just switch to the configuration of the ECB1750 to have an already well
tested configuration for ath79 with the newer kernel versions.
[1] https://github.com/openwrt/openwrt/pull/3505#issuecomment-716050292
Reported-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi
* 3T3R 5 GHz Wi-Fi
* 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
* 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)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[rebase, add LED migration]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi
* 3T3R 5 GHz Wi-Fi
* 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
* 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)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[rebase, add LED migration]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The OpenMesh MR600 is a modified version of the EAP600 family. These
devices are shipped with an AR803x PHY and had various problems with the
delay configuration in ar71xx. These problems are now in the past [1] and
parts of the delay configuration should now be done in the PHY only.
Just switch to the configuration of the EAP600 to have an already well
tested configuration for ath79 with the newer kernel versions.
[1] https://github.com/openwrt/openwrt/pull/3505#issuecomment-716050292
Reported-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9344 rev 2
* 560/450/225 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi
* 2T2R 5 GHz Wi-Fi
* 8x GPIO-LEDs (6x wifi, 1x wps, 1x power)
* 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)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[rebase, add LED migration]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Device specifications:
======================
* Qualcomm/Atheros AR9344 rev 2
* 560/450/225 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi
* 2T2R 5 GHz Wi-Fi
* 4x GPIO-LEDs (2x wifi, 1x wps, 1x power)
* 1x GPIO-button (reset)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[rebase, make WLAN LEDs consistent, add LED migration]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Device specifications:
======================
* Qualcomm/Atheros AR9344 rev 2
* 560/450/225 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 2T2R 5 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
WAN/LAN LEDs appear to be wrong in ar71xx and have been swapped here.
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[add LED swap comment]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Device specifications:
======================
* Qualcomm/Atheros AR9330 rev 1
* 400/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 1T1R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* external antenna
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9330 rev 1
* 400/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 1T1R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9341 rev 1
* 535/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 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
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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
+ 802.3af POE
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9341 rev 1
* 535/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 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
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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
+ 802.3af POE
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9341 rev 1
* 535/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 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
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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
+ 802.3af POE
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[drop redundant status from eth1]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The upgrade script for the openmesh sysupgrade procedure used always an 1
byte block size. This made it easier to seek the correct position in the CE
image and to make sure the right amount of data was copied. But this also
meant that the reading/writing of data required an excessive amount of
syscalls and copy operations.
A 5.4MB big sysupgrade image on an OM2P-HS v3 needed roughly 120s for the
write operation (170s in total) during the sysupgrade.
But it is possible to reduce this overhead slightly:
* index access to read the file size can be done in single 8 byte chunk
(while doing the seek with byte granularity) because each size entry is
example 8 bytes long
* the fwupgrade.cfg can be read as one block (while seeking to its position
using its actual byte offset) because it should be rather small and fit
into the RAM easily
* the kernel can be read in 1KB blocks (while seking to its positions using
its actual byte offset) because the the size of the kernel is always a
multiple of the NOR flash block size (64KB and 256KB)
This results in a sysupgrade write time of roughly 90s (140s in total).
This could be reduced even further when also using larger chunks for the
rootfs. But the squashfs rootfs image is at the moment always
(256KB or 64KB) * block + 4 bytes
long. It would be expected that the time for the sysupgrade write could be
reduced to roughly 30s (80s in total) when busybox's dd would support
the iflag count_bytes.
Reported-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9533 v2
* 650/600/217 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 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
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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
+ 24V passive POE (mode B)
+ used as WAN interface
- eth1
+ 802.3af POE
+ builtin switch port 1
+ used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9533 v2
* 650/600/217 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 1T1R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 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)
- eth1
+ Label: Ethernet 2
+ 802.3af POE
+ builtin switch port 1
* 12-24V 1A DC
* external antenna
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[wrap two very long lines, fix typo in comment]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
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: 4871fd2616 ("ipq40xx: add support for Plasma Cloud PA2200")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
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: ea5bb6bbfe ("ipq40xx: add support for Plasma Cloud PA1200")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
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>
