The WS-AP3710i does not correctly expose its label-mac on eth0 anymore
since the change to simpleLoader.
Fix this by obtaining the label-mac from the U-Boot environment.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit e321e70ddc)
The TP-Link TL-XTR8488 is silimiar to TL-XDR6088 with following changes:
* 1GB DDR4 RAM
* Addtional MT7915AN for 5.8 GHz wireless
For flash instructions, see the commit for TP-Link TL-XDR6088.
Based on An Yun's work.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
(cherry picked from commit 616be733d0)
With the introduction of the simpleImage loader, the MAC address is not
set by the bootloader anymore.
Fix this by reading the MAC address from the U-Boot environment
partition.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 22f92cce22)
On master, the bootwrapper link-address for all simpleImage targets was
relocated to 0x15000000 due to growing kernel size.
This was not done on OpenWrt 23.05, as the decompressed kernel still
fits. However, with the wrapper for the WS-AP3710i, the bootloader
attempts execute in-place with the uImage load-address of 0x1000000. As
the image is compiled without the uImage header in mind, this naturally
fails.
In order to fix this, link the WS-AP3715i simpleImage at 0x15000000 as
done in master. This will force the bootloader to relocate the code to
the proper address and skip XIP.
Signed-off-by: David Bauer <mail@david-bauer.net>
All NETGEAR EX6150v2 validate the rootfs for which OpenWrt places a
fakeheader at the position, where the bootloader expects it.
Some EX6150v2 bootloaders do however make a broken assumption about
where the rootfs starts. This is due to them calculating the rootfs
start not based upon the kernel-length but the string-offset of the
FIT-image.
We have to be compatible with both this broken as well as the valid
calculation. So we do relocate the FDT string section to a
block-boundary and enlarge the FIT image to end at this boundary +
BLOCKSIZE / 2. This way, both the broken as well as correct calculations
do expect the rootfs-header at the same position.
It is worth noting, that this is a rare edge-case in which only happens
if the image-length as well as the start of the string-section are not
placed in the same erase-block. This is an edge-case which happens very
rarely (thus it was not spotted prior).
Affected:
- U-Boot 2012.07 (Jun 16 2016 - 11:59:37)
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit de59fc4540)
The gpio is actually low active, fix it.
Fixes: 40e7fab9e4 ("mediatek: add Nokia EA0326GMP support")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/15651
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 4edde98768)
The MAC address assigned to lan/wan was reversed.
Fixes: f236c1c4f5 ("mediatek: add support for JDCloud RE-CP-03")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
The MAC address assigned to lan/wan was reversed on eMMC boards.
Fixes: d3c193525e ("mediatek: add CMCC RAX3000M support")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Hardware
--------
CPU: Freescale P1020 2xe500 PPC
RAM: 256M DDR3 (Micron MT41J64M16JT-15E:G "D9MNJ")
NAND: 128M (Micron 2CA1)
BTN: 1x Reset
LED: Power - ETH - Radio1 - Radio2
UART: RJ-45 Cisco Pinout - 115200 8N1
Installation
------------
NOTE: You can find a repo with up-to-date instructions as well as
the required files here:
https://github.com/blocktrron/msm460-flashing
Required files
==============
You need a command-files as well as a U-Boot image.
The command-file has the following content (padded to 131072 bytes).
If you copy paste these, remove the newlines!
```
U-BOOT setenv ethaddr 02:03:04:05:06:07; setenv ipaddr 192.168.1.1;
setenv serverip 192.168.1.66; tftpboot 0x3000000 msm460-uboot.bin;
nand device; nand erase 0 0xC0000; nand write 0x3000000 0x0 0xC0000; reset
```
You can download the required U-Boot from this repository:
https://github.com/blocktrron/u-boot-msm/releases
Preparation
===========
Prepare a TFTP server serving two files:
- U-Boot NAND image as `msm460-uboot.bin`.
- OpenWrt factory image as `msm460-factory.bin`
- Command-file names `commands.tftp`
You can start a TFTP server in the current directory using dnsmasq:
```bash
sudo dnsmasq --no-daemon --listen-address=0.0.0.0 \
--port=0 --enable-tftp=enxd0 --tftp-root="$(pwd)" \
--user=root --group=root
```
Replace `enxd0` with the name of your network interface.
Procedure
=========
1. Assign yourself the IP-Address 192.168.1.66/24.
3. Connect the Router to the PC while keeping the reset button
pressed.
4. The LEDs will eventually begin to flash.
They will start to flash faster after around 15 seconds.
5. Release the reset button.
6. Start a new shell
7. Make sure you are currently in the directory where the tftp server
is located.
8. Run the following command:
```bash
tftp 192.168.1.1 -m binary -c put commands.tftp nflashd.cccc9999
```
You get the message "Transfer timed out."
To find out if you have been successful, please check the
blinking LED Pattern.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit af329ec389)
Signed-off-by: David Bauer <mail@david-bauer.net>
There is a custom LED controller between the 3 SoC GPIO outputs and
the red and blue LEDs of the device. It implements a strange mapping
that includes fixed, flashing, and breathing modes.
The current DTS configuration causes OpenWrt to flash the LEDs over
the controller's own flashing, resulting in chaotic output in boot,
failsafe, and upgrade modes.
This change fixes the LEDs in the best way possible as long as each
OpenWrt running state is limited to be signaled by a single led.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15440
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit 0868268c9f)
Hardware:
- SoC: MediaTek MT7981B
- CPU: 2x 1.3 GHz Cortex-A53
- Flash: 128 MiB SPI NAND
- RAM: 512 MiB
- WLAN: 2.4 GHz, 5 GHz (MediaTek MT7976CN, 802.11ax)
- Ethernet: 1x 10/100/1000/2500 Mbps RTL8221B WAN, 1x10/100/1000 Mbps MT7981 LAN
- USB 3.0 port
- Buttons: 1 Reset button, 1 slider button
- LEDs: 1x Red, 1x White
- Serial console: internal test points, 115200 8n1
- Power: 5 VDC, 3 A
MAC addresses:
+---------+-------------------+-----------+
| | MAC | Algorithm |
+---------+-------------------+-----------+
| WAN | 80:af:ca:xx:xx:x1 | label+1 |
| LAN | 80:af:ca:xx:xx:x0 | label |
| WLAN 2g | 80:af:ca:xx:xx:x0 | label |
| WLAN 5g | 82:af:ca:xx:xx:x0 | |
+---------+-------------------+-----------+
Installation:
The installation must be done via TFTP by disassembling the router. On other occasions Cudy has distributed intermediate firmware to make installation easier, and so I recommend checking the Wiki for this device if there is a more convenient solution than the one below.
To install using TFTP:
1. Connect to UART.
2. With the router off, press the RESET button. While the router is turning on, the button should continue to be pressed for at least 5 seconds.
3. A u-boot shell will automatically open.
4. Connect to LAN and set your IP to 192.168.1.88/24. Configure a TFTP server and an OpenWrt initramfs-kernel.bin firmware file.
5. Run these steps in u-boot using the name of your file.
setenv bootfile initramfs-kernel.bin
tftpboot
bootm
6. If you can reach LuCI or SSH now, just use the sysupgrade image with the 'Keep settings' option turned off.
Signed-off-by: Luis Mita <luis@luismita.com>
(cherry picked from commit 63b8d98dd0)
The NMBM-Enabled layout did not use fit image,
it just need default process. So it was been removed in platform.sh.
It will fix sysupgrade error for xiaomi,mi-router-wr30u-112m-nmbm.
Signed-off-by: Hank Moretti <mchank9999@gmail.com>
(cherry picked from commit 02214ab8dc)
This reverts commit dcdcfc1511.
This is a firmware for third-party u-boot mod, which should not
be carried here by us.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
(cherry picked from commit 1b7e62b20b)
The patch "710-pci-pcie-mediatek-add-support-for-coherent-DMA.patch"
makes use of "syscon_regmap_lookup_by_phandle" which requires that
"syscon" be in the compatible list.
Without this patch, PCIe probe will fail with the following error:
[ 1.287467] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
[ 1.294019] mtk-pcie 1a143000.pcie: Parsing ranges property...
[ 1.299901] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff -> 0x0020000000
[ 1.307954] mtk-pcie 1a143000.pcie: missing hifsys node
[ 1.313185] mtk-pcie: probe of 1a143000.pcie failed with error -22
Fixes: 01c58a0d2a ("kernel: bump 5.15 to 5.15.158")
Signed-off-by: Rany Hany <rany_hany@riseup.net>
(cherry picked from commit 8607372b41)
Fixes: #1298
Fixes: 9744bf7093 ("rockchip: configure ETH LED for FastRhino R66S/R68S")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
(cherry picked from commit 72ccbed99c)
All three PCIe ports are reported non working on Meraki MR42/MR52 boards
since kernel 6.1 with the issue of PCIe PHY link never coming up thus
no WLAN cards are available on the boards.
After debugging it seems that PCIe worked on 5.15 and older purely by
accident as device DTS was using /delete-property/ perst-gpios; in each
of the 3 PCIe nodes but there was no "perst-gpios" property in the SoC DTSI
as it was still using the older "perst-gpio" property so it was not getting
removed from the device DTS.
However, in kernel 6.1 commit ("ARM: dts: qcom-*: replace deprecated
perst-gpio with perst-gpios") updated all Qualcomm DTS-es to use the newer
"perst-gpios" and thus once ipq806x moved to 6.1 PCIe stopped working as
now that property was being dropped from the device DTS.
So, since the removal of PERST pins seems to have been wrong from the start
lets drop the property removal from MR42/MR52.
Fixes: #15408
Link: https://github.com/openwrt/openwrt/pull/15509
Link: https://github.com/openwrt/openwrt/pull/15512
Signed-off-by: Robert Marko <robimarko@gmail.com>
Upstream now uses standard ETH LED bindings to configure LED registers.
However, we don't use the r8169 driver for rockchip, so simply remove
this outdated hack.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
(cherry picked from commit cda5cfb9d5)
The code that was there was just taking whatever was left in the
registers, which was just wrong. Set the addresses using the value from
the u-boot environment, the same way the OEM firmware does.
Signed-off-by: Corey Minyard <minyard@acm.org>
Link: https://github.com/openwrt/openwrt/pull/15358
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15402
Signed-off-by: Robert Marko <robimarko@gmail.com>
Convert the Enterasys WS-AP3710i access point to use the simpleImage
wrapper.
This is necessary, as the bootlaoder does not align the DTB correctly
(and does not support altering the FDT loadaddress). Booting images with
kernels 5.15 and later can break depending on the alignment on the DTB
within the FIT image.
Compared with the patch applied to master, this compiles the loader at
the changed offset used in OpenWrt master. This is required, as U-Boot
loads the uImage at the offset the loader is currently compiled for.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit eec18118d0)
We should setup the registers for trapping LLDP packets to the CPU.
Currently, these packets are forwarded to all ports which is not desired
behaviour.
Signed-off-by: Kevin Jilissen <info@kevinjilissen.nl>
(cherry picked from commit 5a5c52085a)
These registers control the handling of Link Layer Discovery Protocol
(LLDP) packets. This seems to be a typo in the naming.
Signed-off-by: Kevin Jilissen <info@kevinjilissen.nl>
(cherry picked from commit 81ab9ef2d1)
Change the RGB indicator LED color for the running state from green to
blue. There are various reasons for this change:
- In stock firmware, green means internet connection is up, red means it
is down, and blue means indeterminate. To track stock behavior as
closely as possible, OpenWrt should indicate blue by default.
- In the current 23.x OpenWrt releases for this router, the led glows
blue all the time -not green- because the bootloader sets it blue
and there is an OpenWrt bug that makes it unable to control the LED.
The bug is fixed in master, so without this commit there would be an
unexpected change of behavior for this device in the next release.
- The ports other closely related Linksys devices (such as EA8300 and
MR8300) get this right and use blue for the running state.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
(cherry picked from commit c2f52e42b1)
Link: https://github.com/openwrt/openwrt/pull/15438
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RGB LED should glow green in the 'running' state, but it
was glowing cyan because the blue component defaulted to 'on'.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
(cherry picked from commit fc62d66c20)
Link: https://github.com/openwrt/openwrt/pull/15438
Signed-off-by: Robert Marko <robimarko@gmail.com>
LAN Leds on Meraki MR52 are wrong and needs to be swapped to actually
reflect real ports (lan1<->lan2).
Fixes: #15388
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/15410
[ wrap commit to 80 columns and improve commit title ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit bd6852185b)
