Enable the Bluetooth UART and pin configuration for Linksys Velop WRT
Pro 7 (LN6001/MBE70). Describe the ISP and reset outputs through the
existing named GPIO export mechanism, holding both high at boot.
Select the generic bluetooth-uart package in DEVICE_PACKAGES so images
include kmod-hci-uart and BlueZ btattach through its dependencies.
Initialize the LN6001 UCI defaults to attach /dev/ttyMSM1 using H4 at
115200 baud. Preserve already configured UARTs, including disabled ones.
The generic package remains disabled until a board or user configures it.
The combined series passed cold-start controller initialization, LE
discovery, connection and service discovery without a userspace reset
pulse. Keep Bluetooth support separate from Wi-Fi enablement.
Signed-off-by: Satoshi Ikeuchi <satosan.ikm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25594
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add wired support and an eMMC A/B sysupgrade path for the Linksys LN6001.
Write and verify the inactive kernel/rootfs pair before changing the boot
selectors. Confirm an installed boot by clearing the s_env boot counter
and updating its checksum.
Identify the board as IPQ9554, using the shared ipq9574.dtsi and family
fallback compatible. Disable the absent UNIPHY1 block and provide the
board clocks required by eMMC, MDIO and PWM. Let U-Boot populate memory
size, use the default GPIO-key debounce and allow 10 ms for QCA8081 reset
assertion while retaining the 150 ms deassertion delay. Use decimal 28
for the QCA8081 PHY address. The assertion delay follows the QCA8081
precedent in 904aa43865.
Return to common upgrade cleanup and reboot after safe staging failures,
while stopping on uncertain boot selector state.
Hardware specification:
- SoC: Qualcomm IPQ9554
- RAM: 1 GiB DDR4
- Flash: 8 GB Samsung 8GTF4R eMMC
- Ethernet: four 1 GbE LAN ports through QCA8075 over PSGMII
- Ethernet: one 2.5 GbE WAN port through QCA8081
- LEDs: red, green, blue and white PWM status channels
- Buttons: reset and WPS GPIO keys
- UART: 115200 8N1
- Power: 12 V, 2.5 A
- Wireless and Bluetooth: not enabled
Installation:
The initial installation uses serial access and an OpenWrt RAM boot.
Keep a bootable stock slot and start with that slot selected. The updater
accepts only the observed retail GPT geometry, matching bootconfig copies,
boot_part_ready=3, auto_recovery=yes and matching Wi-Fi firmware slots.
It does not repair an inconsistent layout or selector state.
Copy this image to the TFTP server as ln6001-initramfs.itb:
openwrt-qualcommbe-ipq95xx-linksys_ln6001-initramfs-uImage.itb
Connect Ethernet to LAN4 and configure the TFTP server as 192.168.1.254/24.
Interrupt U-Boot autoboot through the serial console and run:
setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.254
setenv netmask 255.255.255.0
tftp 0x4d100000 ln6001-initramfs.itb
bootm 0x4d100000#config@1
Do not save these temporary network settings or write the initramfs FIT
to eMMC. In RAM-booted OpenWrt, transfer the following image to
/tmp/ln6001-sysupgrade.bin:
openwrt-qualcommbe-ipq95xx-linksys_ln6001-squashfs-sysupgrade.bin
Check the selected slot and validate the image, then install:
fw_printenv boot_part boot_part_ready auto_recovery
sysupgrade -T /tmp/ln6001-sysupgrade.bin
sysupgrade -n /tmp/ln6001-sysupgrade.bin
Run the last command only after validation succeeds. boot_part=1 selects
A and installation writes B; boot_part=2 selects B and installation
writes A. Do not force a failed check. The sysupgrade archive is not a
Linksys web-update image. Subsequent OpenWrt sysupgrades use the same
inactive-slot path; omit -n to request preservation of OpenWrt settings.
Recovery:
The serial TFTP/bootm procedure remains available without depending on
the installed rootfs. Before installation, resetting a RAM-only session
returns to the selected existing firmware. After installation, a normal
reboot uses the newly selected slot and does not itself return to stock.
With consistent selector copies and environment, a recovery RAM boot can
run the same checked sysupgrade path. Inconsistent selectors are rejected;
do not bypass these checks. Keep serial access and a bootable other slot.
Partition and MAC address handling:
Discover the existing GPT at runtime and require the retail partition
labels, starts and sizes before writing. Preserve the GPT, bootloader,
devinfo and both Wi-Fi firmware payloads. The upgrade writes the inactive
HLOS/rootfs pair, then updates both bootconfig selector sectors and the
boot_part environment variable. Successful installed boots clear the
boot counter and update its checksum in s_env after verifying the active
slot. A stale checksum on an already-zero counter is repaired as well.
Read hw_mac_addr from devinfo through read-only block NVMEM. Stock LAN
and WAN use the same base address; assign offset zero to all five wired
ports. Configuration persists in a per-slot F2FS overlay.
Validation:
Retail-hardware testing passed RAM boot with U-Boot supplying 1
GiB RAM, and sysupgrade -n from stock-selected A into B followed
by two successful installed boots. The boot-count record
contained a zero count and valid checksum after both boots. F2FS
remained writable and a UCI setting persisted across reboot.
Kernel/rootfs readback matched the image; full stock A hashes and
non-selector protected partition hashes were unchanged.
LAN4 linked at 1 Gbps. WAN-to-WAN testing against a stock LN6001
negotiated 2500 Mbps full duplex at both ends and recovered to
that rate after cable replug without reboot or interface reset.
Normal and full-MTU IPv6 pings passed without loss before and
after replug. Separate four-stream TCP endpoint tests measured
2.313 Gbit/s received by this image and 2.311 Gbit/s by the peer,
then 2.316 Gbit/s received after replug. These are router-local
tests, not forwarding benchmarks. One RX error at the
disconnected checkpoint did not increase during subsequent
traffic; TX and peer RX/TX error counters remained zero.
Fifteen local synthetic tests cover boot-counter checksum
validation and repair, write/readback failures, upgrade guards
and safe return versus deliberate halt. Seven temporary-file
bootcount test groups also passed on the device. Real boot
selectors were not corrupted for failure tests. Image-macro
checks confirm sysupgrade.bin only with the size guard retained.
Signed-off-by: Satoshi Ikeuchi <satosan.ikm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24736
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Charter Spectrum SBE1V1K fails to boot with the default kernel
load address. The device gets stuck early in the boot process due to
the stock bootloader encountering memory overlap or alignment issues
with the default `0x41000000` address.
Changing `KERNEL_LOADADDR` to `0x42200000` resolves the boot failure
and ensures stable operation.
Why `0x42200000` instead of `0x42000000`?
While testing showed that `0x42000000` also boots successfully,
`0x42200000` was explicitly chosen for two primary safety reasons:
1. Avoid U-Boot `loadaddr` Overlap: On many QCA/IPQ platforms,
`0x42000000` is commonly used as the default `loadaddr` to fetch
the FIT image into memory. Setting the extraction destination
(`KERNEL_LOADADDR`) to the exact same base address risks in-place
decompression overlaps.
2. Reserved Memory Buffer: The memory range below `0x42000000`
is heavily utilized by TZ, SMEM, and vendor-specific reserved
memory in newer Askey firmwares. Adding a 2MB aligned offset
(`0x200000`) provides a safer buffer against shifting vendor
memory boundaries in future OEM bootloader updates, while still
strictly satisfying the ARM64 2MB alignment requirement.
This fix and the `0x42200000` address have been successfully tested
on actual SBE1V1K hardware by community member motolav.
Link: https://forum.openwrt.org/t/spectrum-sbe1v1k-ipq9574-openwrt-support/245244/262
Tested-by: motolav <https://forum.openwrt.org/u/motolav>
Signed-off-by: Jackie Han <jackie.han@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25344
Signed-off-by: Robert Marko <robimarko@gmail.com>
askey_sbe1v1k currently sets KERNEL_LOADADDR to 0x42080000, which is not
2MB-aligned. This trips the arm64 boot code's alignment check and
prints the following warning on every boot:
[Firmware Bug]: Kernel image misaligned at boot, please fix your
bootloader!
0x42080000 is a 2MB-aligned base plus the legacy TEXT_OFFSET of
0x80000, which arm64 kernels used before v5.8. Since v5.8, TEXT_OFFSET
is fixed at 0, so the kernel now expects the load address itself to sit
on a 2MB boundary. This target runs on much newer kernels, so the old
offset is stale and only serves to trigger the FW_BUG warning.
Instead of manually shifting the address, drop the device-specific
KERNEL_LOADADDR override entirely. This allows the image to fall back
to the target's default load address (0x41000000), which is properly
2MB-aligned and cleanly resolves the alignment warning.
Verified by both TFTP-booting the .itb and flashing the generated
sysupgrade image to a physical bare-metal device. The device boots
cleanly, operates stably, and the misalignment warning no longer appears.
Signed-off-by: Jackie Han <jackie.han@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25283
Signed-off-by: Robert Marko <robimarko@gmail.com>
This commit adds support for Askey SBE1V1K.
Device specification
--------------------
SoC: Qualcomm IPQ9570
RAM: Micron (2GB)
Flash: 8GB eMMC
Ethernet: 1x 10G RTL8261BE
1x 2.5G QCA8081
2x 1G QCA8075
Wi-Fi: QCN6214 2.4GHz 4x4
QCN6274 5GHz 4x4
QCN6274 6GHz 4x4
LEDs: 1 LED, power/status
Buttons: 1 reset
USB ports: none
Bootloader: U-Boot 1.0.9 [spf12.2_CSU2] (Jun 28 2024 - 17:47:10 +0000)
Installation (serial required):
**NOTE** This procedure requires glitching the eMMC. It is very possible
that you may damage or corrupt your bootloader in doing so. Proceed with
caution, and always make a full eMMC backup!
**NOTE** If the bootloader has trouble accessing eMMC due to glitching it, any
U-Boot env updates are written directly to the start of flash, overwriting
the bootloader. For this reason, it is strongly NOT recommended to make any
persistent U-Boot env changes from U-Boot itself; do this in Linux.
- Open the chasis and connect to the serial port.
- While booting, short eMMC CLK to UART VCC during FIT image load to enter
U-Boot.
- setenv ipaddr 192.168.1.1
- setenv serverip 192.168.1.2
**NOTE** DO NOT SAVE THE ENV
- Set your PC IP address to 192.168.1.2 and host the initramfs on a tftp
server.
- tftpboot 0x44000000 initramfs.itb
- bootm 0x44000000
If you get an error and it reboots, try loading to 0x80000000.
In the initramfs:
- fw_setenv bootargs 'console=ttyMSM0,115200n8 rootwait root=/dev/mmcblk0p27'
- fw_setenv bootcmd 'echo "Hit ctrl+c for shell..."; if sleep 3; then run do_boot; else do_nothing; fi;'
- fw_setenv do_boot 'mmc read 0x44000000 0x00014022 0x3800; bootm 0x44000000'
- Install a sysupgrade
U-Boot hardcodes the bootargs to reset on each boot, which is why it is
necessary for the bootcmd to override them. Thankfully, the vendor did
not bother to secure U-Boot any further. As long as the vendor software
does not boot, the U-Boot env will stay. If a vendor image boots, the
U-Boot env will revert to default. The vendor U-Boot also ignores
bootdelay, which is why we add a dummy sleep to allow the user time to
drop into a shell without needing to glitch any more.
Co-authored-by: Kenneth Kasilag <kenneth@kasilag.me>
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21586
Signed-off-by: Robert Marko <robimarko@gmail.com>
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>
Since 6.18 RTL8261N support was added to the generic Realtek PHY driver
and was dropped from the downstream driver.
So, fix the missing RTL8261N support by including the Realtek PHY kmod
and the relevant firmware.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Commit 041ef9648d ("qualcommbe: move Device DTS to dedicated DTS
directory") introduced a dedicated DTS directory and set DEVICE_DTS_DIR
to ../dts as default. This broke the rdp433 device build since its DTS
resides in the kernel tree (applied via patches), not in the target dts
directory.
Fix this by overriding DEVICE_DTS_DIR for rdp433 to point to the kernel
DTS directory.
Fixes: 041ef9648d ("qualcommbe: move Device DTS to dedicated DTS directory")
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22096
Signed-off-by: Robert Marko <robimarko@gmail.com>
Align the qualcommbe target to the pattern already used on other devices where
the device DTS are placed in a dedicated directory separate from the files
directory.
This, while trying to enforce a common pattern for every target, also permits to
do modification to device DTS without having to trigger a recompilation of the
entire kernel (as the files directory is not touched)
Link: https://github.com/openwrt/openwrt/pull/22038
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add initial support for new target with the initial patch for ethernet
support using pending upstream patches for PCS UNIPHY, PPE and EDMA.
Only initramfs currently working as support for new SPI/NAND
implementation, USB, CPUFreq and other devices is still unfinished and
needs to be evaluated.
Link: https://github.com/openwrt/openwrt/pull/17725
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Satoshi Ikeuchi
Jackie Han
Andrew LaMarcheandKenneth Kasilag
Sven Eckelmann
Robert Marko
Ahmed Naseef
Christian Marangi
Mantas Pucka