The DFI ADN553 is a 3.5" SBC based on Intel Atom Alder Lake-N
processors with three Intel I226V 2.5GbE ports.
Specs:
* CPU: Intel Atom x7425E (4C, 12W) / x7213E (2C, 10W) /
x7211E (2C, 6W)
* RAM: 1x DDR5 SO-DIMM, up to 16GB
* Storage: 1x M.2 M key 2242/2280 (PCIe Gen3 x1/SATA3),
1x SATA 3.0
* Ethernet: 3x 2.5GbE RJ-45 (Intel I226V)
* USB: 4x USB 3.2 (rear), 2x USB 2.0 (internal)
* Expansion: 1x M.2 B key 3052 (USB3/USB2, opt. PCIe x1, SIM),
1x M.2 E key 2230 (USB/PCIe x1, CNVi)
* Display: 1x HDMI, 1x Type-C DP Alt. Mode, 1x LVDS/eDP
* Power: 9-36V DC wide range input
* TPM: dTPM 2.0 (NPCT750AADYX)
* Form factor: 3.5" SBC (146mm x 102mm)
Installation:
1. Write the combined-efi.img to a USB drive:
dd if=combined-efi.img of=/dev/sdX conv=fdatasync
2. Boot the ADN553 from the USB drive via the UEFI boot menu.
3. For permanent installation, write the image to the M.2 or
SATA storage device.
The board uses "Default string" as DMI sys_vendor and product_name
placeholders, so board detection is fixed by filtering these out and
falling through to board_vendor (DFI Inc.) and board_name (ADN553).
The three I226V NICs are pinned to their PCIe paths to ensure
consistent interface ordering matching the physical left-to-right
port layout. eth0 is assigned as WAN and eth1/eth2 as LAN.
Link: https://github.com/openwrt/openwrt/pull/22980
Signed-off-by: Nick Hainke <vincent@systemli.org>
Now that we have a proper driver support for the onboard EMC2301 lets
wire up the fan as a cooling device on the Xiaomi AX9000.
Link: https://github.com/openwrt/openwrt/pull/22942
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that 6.12 EMC2305 driver is backported to 7.0 code, lets do the same
for 6.18 so they dont diverge.
Link: https://github.com/openwrt/openwrt/pull/22942
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport the Microchip EMC2305 driver changes up to current linux-next.
These are required in order to actually be able to use the driver with
DTS support to drive fans as cooling devices.
Replace the bcm27xx RPi patch with the one from RPi kernel 7.0 that was
already adapted to all of these backports.
Link: https://github.com/openwrt/openwrt/pull/22942
Signed-off-by: Robert Marko <robimarko@gmail.com>
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Drop the old kernel and move over to the latest. We hardly
have any patches so this is a swift change.
Link: https://github.com/openwrt/openwrt/pull/22932
Signed-off-by: Linus Walleij <linusw@kernel.org>
Adapt kernel configuration of the mt7629 subtarget for Linux 6.18.
This was only compile-tested as I don't have the hardward.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The by-now-upstream driver for the built-in 2.5GE PHY of the MediaTek
MT7988 and MT7987 SoC loads firmware at probe time.
Build the driver as a module in order to make sure the driver only
attempts to load the firmware by the time the rootfs with the firmware
file has become available.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Upstream changes to phylink require to make some small changes to our
downstream Airoha AN8855 DSA driver, so it build with Linux 6.18.
The efuse driver is upstream by now and can be dropped.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Delete patches merged upstream and refresh the remaining patches.
Import pending patchset to fix read-out-of-bounds bug in clk driver
while at it, as it makes maintaining the downstream clk driver for
MT7987 easier.
Replace downstream patch for Fidelix FM35X1GA SPI-NAND chip with
upstream commit replacing it (Dosilicon DS35Q1GA is indentical).
Several additional fixes were needed for MT7623N, especially to get
HDMI and the Mali-450 GPU working again...
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Our downstream patch for the new SerDes paths on MT7988 wasn't
correctly ported to Linux 6.18 which already got most of the XPCS
support upstream.
Fix (ie. reduce) the patch to make the built-in 2.5G PHY on MT7988 and
MT7987 work again.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Our USXGMII config only covers one single register of which kind there
are actually more. We only set a value for 'CFG_QHSG_TXCFG_MAC_CH0' but
there are additional registers for CH1-CH3. Those refer to the 4
USXGMII 'channels'. While the RTL930x part of the SDK doesn't set them
explicitly, from RTK setup SerDes dumps we can see they are usually
similarly set.
The RTL931x part of the SDK actually writes those register explicitly
during USXGMII. We just haven't implemented that so far. Thus, add this
to the USXGMII config for both RTL93xx.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22939
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since the USXGMII config was made generic before, we can use it now for
the RTL931x setup too. This brings it closer to what the SDK configures
(see _dal_mango_construct_init_usxgmii), fixes some deviations in our
previous settings and makes clearer what is actually done.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22939
Signed-off-by: Robert Marko <robimarko@gmail.com>
The USXGMII config setting specific options currently is only
implemented for RTL930x. Looking at the SDK one can see that RTL931x
shares a lot of these configuration options. Additionally, several dumps
from RTK setups have shown that values which aren't set yet by us for
RTL930x but for RTL931x, also apply for RTL930x. Thus, both can be
merged. Start this by making the current function generic for RTL93xx.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22939
Signed-off-by: Robert Marko <robimarko@gmail.com>
USXGMII autoneg setting is currently hardcoded for RTL930x and not even
handled explicitly for RTL931x. This should be handled via neg_mode from
phylink subsystem too. Thus, move it over to rtpcs_93xx_sds_set_autoneg
as generic implementation for RTL93xx and set it depending on the
provided negotiation mode.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22939
Signed-off-by: Robert Marko <robimarko@gmail.com>
BUFFALO WSR-3000AX4P is a 2.4/5 GHz band 11ax (Wi-Fi 6) router, based on
MT7981B.
Specification:
- SoC : MediaTek MT7981B
- RAM : DDR4 512 MiB (ESMT M16U4G16256A-KJBG)
- Flash : SPI-NAND 128 MiB (Winbond W25N01GVZEIG)
- WLAN : 2.4/5 GHz 2T2R (MediaTek MT7981B (SoC))
- Ethernet : 4x 10/100/1000 Mbps
- switch : MediaTek MT7531A
- LEDs/Keys (GPIO): 6x/4x
- UART : through-hole on PCB (J1)
- assignment : 3.3V, GND, TX, RX from tri-angle marking
- settings : 115200n8
- Power : 12 VDC, 1.5 A (Max. 14.4 W)
Flash instruction using initramfs image:
1. Prepare a TFTP server with 192.168.11.2
2. Rename initramfs image to "linux.ubi-recovery" and put it to the TFTP
directory
3. Hold the "AOSS" button and power on WSR-3000AX4P, release after 7~
seconds
4. The bootloader automatically downloads the initramfs image and boots
with it
5. After booting, upload a sysupgrade image to the device and perform
sysupgrade with it
6. Wait ~100 seconds to complete flashing
Reverting to stock image:
1. Download a official firmware and decrypt it by buffalo-enc
example:
buffalo-enc -i <official .bin> -o fw.dec -d -O 0xC8 -l
2. Upload the decrypted image to the device
3. Flash the image to the UBI in "ubi_kernel" partition on the device
example:
. /lib/upgrade/common.sh
. /lib/upgrade/nand.sh
CI_UBIPART="ubi_kernel" nand_do_flash_file fw.dec
4. Reboot the device
reboot
Notes:
- WSR-3000AX4P has 2x OS images ("ubi"/"Kernel2"), but the second one
is only for backup and not used for booting.
image handling on the bootloader:
- "ubi" is broken : "Kernel2" --(copy)--> "ubi"
- "Kernel2" is broken : "ubi" --(copy)--> "Kernel2"
- "ubi" != "Kernel2" :
- boot_select=0: "ubi" --(copy)--> "Kernel2"
- boot_select=1: "Kernel2" --(copy)--> "ubi", set boot_select to '0'
MAC Addresses:
LAN : EC:5A:31:xx:xx:50 (board_data, "mac" (text))
WAN : EC:5A:31:xx:xx:50
2.4GHz: EC:5A:31:xx:xx:52
5GHz : EC:5A:31:xx:xx:59
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22587
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Enable ascii-env NVMEM driver (CONFIG_NVMEM_LAYOUT_ASCII_ENV) on
mediatek/filogic subtarget, to handle ascii-based MAC addresses
in key-value format stored to the mtd partition.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22587
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Device support for zbt-z8106ax-t
Vendor Zbtlink advertizes this device as model Z8106AX-M2-T
on their website www.zbtlink.com. Device label sticked on
enclosure however states this is model Z8106AX version -T.
I made firmware selector to show this device as
- ZBT-Z8106AX-T to match information printed on the label and
- ZBT-Z8106AX-M2-T to match information found on vendors web pages.
Specifications:
SoC: MediaTek MT7981B
RAM: 256MiB
Flash: Winbond SPI-NAND 128 MiB
Switch: 1 WAN, 4 LAN (Gigabit) MediaTek MT7531
Buttons: Reset
Power: DC 12V-32V 1A
WiFi: MT7981B 2.4Ghz & 5Ghz
USB 3
M2 slot to hold LTE modem
2x nano SIM slots (user controllable)
Router comes in a flat metal box with all antennas detachable.
- 4 antennas for LTE 4G/5G communication
- 2 antennas for Wifi 2.4 GHz
- 2 antennas for Wifi 5 GHz
Power supply could be between 12V and 32V.
This serves both cars equipped with 12V batteries
and trucks equipped with 24V batteries.
Led Layout:
Power (green, user controllable, default set to OpenWrt Status)
Mobile (green, user controllable)
WLAN 2.4G (green, user controllable)
WLAN 5G (green, user controllable)
WAN (amber, user controllable, set to show eth1)
LAN1 (amber, hardware controlled)
LAN2 (amber, hardware controlled)
LAN3 (amber, hardware controlled)
LAN4 (amber, hardware controlled)
SIM Slots:
Controlled via exported GPIO named SIM.
echo "0" > /sys/class/gpio/sim/value
- selects upper sim slot labelled SIM1
echo "1" > /sys/class/gpio/sim/value
- selects lower sim slot labelled SIM2
Slot SIM2 is set as default and matches label on Router enclosure
---
Installation:
A. Through U-Boot menu:
- Prepare your connecting computer to use a static IP in
network 192.168.1.0/24 like
a) 192.168.1.10 netmask 255.255.255.0 (legacy notation)
b) 192.168.1.10/24 (CIDR notation)
- Power down the router and hold in the Reset button.
- While holding in the button power up the router again.
- Hold the button in for 10 seconds and then release.
- Use your browser to go to 192.168.1.1
- If you see a GUI allowing for flashing firmware then you got the right spot.
- Upload the **Factory** image file.
Note: U-Boot GUI it can be used to recover from an incorrect firmware flash.
B. Through OpenWrt Dashboard:
If your router comes with OpenWrt preinstalled (modified by vendor),
you can easily upgrade by going to the dashboard (192.168.1.1) and
then navigate to "System" -> "Backup/Flash firmware"
Flash OpenWRT firmware and take care to deselect (untick) option
"keep settings". Settings done by vendor are incompatible with
versions 24.10 or 25.12.
MAC Addresses:
MAC Addresses were found in Factory partition:
offset 0x4 F8:5E:3C:xx:xx:aa --> Router Label -2
offset 0xa F8:5E:3C:xx:xx:bb --> Router Label -1
offset 0x24 F8:5E:3C:xx:xx:cc --> Router Label +1
offset 0x2a F8:5E:3C:xx:xx:yy --> printed on Router Label
Hardware Watchdog:
Device features a GPIO controlled hardware watchdog.
Verfied by removing procd controlled watchdog and
seeing device rebooting.
---
Notes:
The zbt-z8106ax-t could be ordered from vendor with a variety of modems.
Mine came with a Quectel RM520N-GL. Quectel firmware was at RM520NGLAAR01A07M4G.
This level of firmware made some trouble connecting with some of my
SIM cardproviders.
Newer firmware level RM520NGLAAR01A08M4G_01.205.01.205 was available searching
github repositories. Upgrading my RM520-GL allowed to get successful connects
that did fail with older Quectel firmware.
Modem communication is set to ethernet control mode (ECM) by vendor.
Vendor takes advantage of ECM by wiring modem to internal switch port WWAN.
OpenWRT network configuration wants to define two network interfaces
- Network interface covering USB0 set with high metric
- Network interface covering WWAN set with low metric
Network interface covering WWAN would be preferred default route.
Please take note that internal switch port wired to LTE modem is named LAN5
in vendor provided firmwares. OpenWRT however names port as WWAN to better
describe purpose of port. WWAN is suggested to be assigned to firewall zone WAN.
Did use package qmodem from github repository FUjR/QModem to manage RM520N-GL LTE modem.
Signed-off-by: Jörg Seitz <github.joeterminal@xoxy.net>
Link: https://github.com/openwrt/openwrt/pull/21834
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This is apparently a redundant u-boot config split between cfg1 and
cfg2. The size is also 0x10000 instead of the full amount.
This is needed in order to fix ethernet probing.
Fixes: 3faa3a04bb ("ath79: enterasys,ws-ap3805i: use nvmem")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22882
Signed-off-by: Robert Marko <robimarko@gmail.com>
The profiles.json[1] in generated and used during ASU sysupgrades takes
DEVICE_NAME as profile name which break ASU sysupgrades, use BOARD_NAME
which serves the same goal as overwriting DEVICE_NAME, allowing
sysupgrade-tar's checks be succesfully passed using the old name used in
older installations. Without affecting the generated profiles.json, thus
recovering ASU support.
*Keep the non-stardand device name with suffix "-mtd"(replaced underscore
by hyphen) to remark that this device is also supported in the armsr
(armvirt) target as originally intented[2].
*I think I have fully checked the sysupgrade path to confirm this change
does not have side effects.
[1]: https://downloads.openwrt.org/releases/25.12.0/targets/layerscape/armv8_64b/profiles.json
[2]: https://github.com/openwrt/openwrt/pull/12828
Fixes: af0546da34 ("layerscape: armv8_64b: add Traverse Ten64 NAND variant")
Fixes: https://github.com/openwrt/asu/issues/1583
Reported-by: DanaGoyette (github)
Co-developed-by: Eric Fahlgren <ericfahlgren@gmail.com>
Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/22359
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add missing patch description, so all patches of the mediatek target can
be applied to a kernel tree using 'git am'.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add missing patch description, so all generic patches can be applied
to a kernel tree using 'git am'.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The XMG1915-10E is a switch with 8 copper ports and 2 SFP+ cages.
Specifications:
---------------
* SoC: RTL9302C
* Flash: 32 MiB SPI NOR flash
* RAM: 256 MiB
* Ethernet: 8x 10/100/1000/2500 Mbps (RTL8224)
* SFP: 2x SFP+ cages
* UART: 1x 4 pins serial header, 115200 bauds, 8n1, 3.3v logic levels,
pinout: unused (top), TX, RX, GND (bottom)
* Buttons: 1x "Reset" button
Works:
------
- 2 SFP+ cages either 1G/10G or 2.5G
- 8*2.5G Ethernet ports
- Switch function
- LEDs
- Boot from flash
- Assigning MAC addresses from flash
Ethernet ports:
---------------
The 8x 2.5Gbps ethernet ports are provided by two RTL8224 chips. The
ports are supported by the upstream realtek PHY driver plus a local
initialization patch for the 10g-qxgmii mode.
Installation:
-------------
This device uses ZyNOS instead of Linux which makes the installation a
bit cumbersome. OpenWRT will be installed on the slot of the second
firmware image, thus the switch original firmware can be booted with a
little change. The serial console is required.
1. Set the switch to boot from the first image. This is required to
be sure not to be blocked in the middle of the installation
procedure.
2. Connect to the switch using the serial adapter and interrupt the boot
process by pressing "Enter" repeatedly.
3. Load the OpenWRT initramfs image using xmodem. From bootext console
(use ATHE to get the list of commands):
> ATUP 81800000,file_length
> ATGO 81800000
4. Wait for OpenWRT to boot, once this is done transfer the loader
binary and the sysupgrade image to /tmp using scp.
5. Install OpenWRT permanently by writing the images on the flash:
> mtd write /tmp/loader.bin loader
> mtd write /tmp/sysupgrade.bin firmware
6. Reboot the switch and from the stock firmware set the configuration
to boot from the second image (Maintenance > Firmware upgrade > Boot
image).
7. Reboot again and enjoy OpenWRT.
Recovery/Return to stock:
-------------------------
1. Connect the switch using the serial adapter and interrupt the boot
process during the "DRAM POST: Testing:" sequence by pressing '$'
until the "XMG1915$" prompt appears.
2. Start an ymodem upgrade using the following command and use an xmodem
upload tool to send the .bin file provided in an OEM upgrade package.
XMG1915$ upgradeY image2 81000000 115200
## Ready for binary (ymodem) download to 0x081000000 at 115200 bps...
3. Wait for the upgrade process to finish and reboot the switch.
Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21341
Signed-off-by: Robert Marko <robimarko@gmail.com>
This refactoring is a little bit of all ...
For access to the ring counter and size registers there exist currently
separate helpers. These are only for the register number but not the
bit position inside the register. Register definitions still use the
old prefix. Resolve this mix by
- Changing the prefixes of the register defines
- replacing the helpers with the register addresses
- just calculating register & offset manually where needed.
This might be a little step back but at least aligns with the rest of
the register access code. A future commit might bring an even better
version.
While we are here convert the main consumer rteth_93xx_hw_reset() to
regmap and fix a bug. Until now this function only clears the first
counter in a register because of a missing bit shift during writeback.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22920
Signed-off-by: Robert Marko <robimarko@gmail.com>
Commit b4d7263bc3 ("kernel: of: avoid some unnecessary bad cell count
warnings") backported Linux commit 6e5773d52f4a ("of/address: Fix WARN
when attempting translating non-translatable addresses"), which started
requiring #address-cells for a device's parent if we want to use the
reg resource in a device node.
Many Chromium devices use a /firmware/coreboot device node that is
patched in by the boot firmware. These structures look something like:
# find /sys/firmware/devicetree/base/firmware/
/sys/firmware/devicetree/base/firmware/
/sys/firmware/devicetree/base/firmware/scm
/sys/firmware/devicetree/base/firmware/scm/compatible
/sys/firmware/devicetree/base/firmware/scm/name
/sys/firmware/devicetree/base/firmware/ranges
/sys/firmware/devicetree/base/firmware/chromeos
/sys/firmware/devicetree/base/firmware/chromeos/fmap-offset
/sys/firmware/devicetree/base/firmware/chromeos/compatible
/sys/firmware/devicetree/base/firmware/chromeos/readonly-firmware-version
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-storage
/sys/firmware/devicetree/base/firmware/chromeos/hardware-id
/sys/firmware/devicetree/base/firmware/chromeos/firmware-type
/sys/firmware/devicetree/base/firmware/chromeos/vboot-shared-data
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-offset
/sys/firmware/devicetree/base/firmware/chromeos/firmware-version
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-size
/sys/firmware/devicetree/base/firmware/chromeos/name
/sys/firmware/devicetree/base/firmware/coreboot
/sys/firmware/devicetree/base/firmware/coreboot/compatible
/sys/firmware/devicetree/base/firmware/coreboot/board-id
/sys/firmware/devicetree/base/firmware/coreboot/reg
/sys/firmware/devicetree/base/firmware/coreboot/name
/sys/firmware/devicetree/base/firmware/name
Notably, there is no #{address,size}-cells in /firmware.
This breaks any driver relying on a device under /firmware, such as the
coreboot_table driver.
This is technically an ill-formatted FDT, and so we might as well just
add the properties ourselves.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22951
Signed-off-by: Robert Marko <robimarko@gmail.com>
The rtl838x.h header is needed for all targets and not only RTL838x
specific. Rename it to rtl-otto.h to make clear that this is a
generic include.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22931
Signed-off-by: Robert Marko <robimarko@gmail.com>
There are currently two header files for the dsa driver. rtl83xx.h
and rtl838x.h. It is unclear for what reason they are separated.
Especially as one always includes the other. Merge those two files
into one.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22931
Signed-off-by: Robert Marko <robimarko@gmail.com>
