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>
EDMA maps RX fill buffers with DMA_TO_DEVICE but unmaps them with DMA_FROM_DEVICE. Use DMA_FROM_DEVICE consistently, release mappings left on RX rings during teardown, and flush ring-disable writes before descriptor cleanup.
Signed-off-by: krava <igor.kravchenko05@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24218
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>
It showed up after a kernel refresh on qualcommax, as it only shows up
with ALL_KMODS.
So, to avoid dropping it again from target config, move it to generic.
Fixes: 4f9740c734 ("qualcommax: refresh config")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport v7.3 phylink patches to the generic target required for the
latest fwnode phylink PCS patches which support multiple (sub-)targets,
including MTK and qualcommax.
This update includes better PCS release logic, switch to full notifier
add/release PCS handling, devres managed PCS provider variant and
general code improvements.
In addition, update every user to the latest fwnode phylink PCS API.
In the latest API, fwnode_pcs_add_provider() returns a pointer to
the provider or the error code instead of the previous plain return
value. As such, update error handling and add a descriptive error
message upon failure. Also the provider remove logic changed and with
the support of devres API, switch every user to devm_ variant.
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
[ improve commit description, refresh patch, update any driver to new API]
Co-Developed-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24973
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Update the existing 0342-net-qualcomm-Update-IPQ9574-PPE-driver.patch
to fix an oversight in the out-of-tree qcom_ppe driver where
PHY_INTERFACE_MODE_1000BASEX was missing from the MAC speed clock rate
configuration switch statement.
Without this fix, inserting a 1G fiber SFP module into the 10G MAC throws
an -EOPNOTSUPP (-95) error during phylink negotiation, preventing the link
from coming up. Routing 1000BASE-X to the GMII clock helper restores native
1G SFP module hot-swapping on IPQ9574 boards like the 8devices Kiwi-DVK.
Signed-off-by: Balsam CHIHI <balsam.chihi@moment.tech>
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>
This target currently uses cpu erratums for Cortex-A76, Cortex-A510,
Cortex-A710, and Neoverse-N2. The commit 0b25cef also added erratums
for Ampere AmpereOne and Rockchip RK3568. Remove these useless items.
Fixes: 0b25cef ("qualcommbe: enable 6.18 testing kernel")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://github.com/openwrt/openwrt/pull/24770
Signed-off-by: Robert Marko <robimarko@gmail.com>
Commit ce120be361 ("kernel: disable qualcomm crypto") dropped the
CRYPTO_DEV_QCE kernel configs, so crypto@73a000 and its BAM no longer
have a driver. Unlike ipq8074, mainline ipq9574.dtsi ships both nodes
enabled by default, and gcc-ipq9574 registers its interconnect provider
with icc_sync_state; an enabled consumer that can never probe defers
that callback forever, so every boot logs
sync_state() pending due to 73a000.crypto
and the interconnect bandwidth votes are never allowed to drop from
their boot-time maximum. Disable both nodes explicitly in the board
device tree.
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24379
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add kmod packages to support accessing the fTPM (in-firmware TPM) which
can be implemented in the boot firmware of most modern platforms.
- kmod-optee: Open Portable Trusted Execution Environment
- kmod-optee-rng: OP-TEE random number generator client
- kmod-rtc-optee: OP-TEE real-time clock client
- kmod-scmi-transport-optee: SCMI OP-TEE transport
- kmod-tee: Generic Trusted Execution Environment
- kmod-tee-stmm-efi: EFI variable service Trusted Application
- kmod-tpm-ftpm-tee: Microsoft fTPM Trusted Application
Using the TPM 2.0 can be useful for various security applications,
such as encrypting on-disk credentials. OP-TEE itself alone is also
useful as it can provide a PKCS#11 token for authentication (eg. to
connect to a VPN) and significantly lower the risk of leaking secrets
used for authentication. Also, on some platforms RNG and RTC can only be
accessed via OP-TEE, and some ARM SystemReady platforms require EFI
variables to be access via a TA.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Upstream has marked it as BROKEN. Quote:
This driver is harmful:
- It is much slower than the CPU.
- It Has a history of bugs.
- It does not have exclusive access to the hardware, causing races
with the secure world.
- It register its implementations with too low a cra_priority for them
to be actually used.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24326
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Align the USXGMII configuration sequence with the vendor SSDK:
- Reset the PCS PLL by programming the whole reset register with the
documented assert and release values and 100ms holds, instead of
toggling a single bit for 1ms and relying on the power-on state of
the remaining analog enables.
- Keep the uniphy port clocks disabled across the reconfiguration and
re-enable them after calibration, before releasing the XPCS reset.
- Select in-band link detection explicitly rather than the SFP
loss-of-signal input, which does not exist on non-SFP ports.
- Wait for the 10GBASE-R receiver to link before enabling the USXGMII
adaptation layer. Best-effort, since the PHY SerDes may only come
up later.
Other interface modes keep the previous behaviour.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
The MISC2 phy mode field is modelled as two bits at the wrong offset:
the hardware field is three bits wide and starts one bit lower. The
SGMII and 2500BASE-X values only come out right because the power-on
default happens to keep the missed bit set, and USXGMII is not
programmed at all, leaving the uniphy in its power-on SGMII
personality.
Model the field at its documented position, add the USXGMII mode
value and write the rate field explicitly instead of relying on its
power-on default, matching the values the vendor SSDK programs.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
The uniphy never receives a software reset pulse during interface mode
configuration. The vendor SSDK asserts the GCC system reset and the
NSSCC soft reset together for 100ms on every uniphy mode change;
without the pulse, parts of the uniphy analog block can remain in
their power-on state.
Pulse both resets, when the devicetree provides them, after the mode
is programmed. Both resets are optional so existing devicetrees keep
working.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
Some board designs feed an external PHY its reference clock from the
uniphy 25MHz clock output instead of a local crystal. Enable the
output when the devicetree opts in with "qcom,uniphy-clkout-25mhz".
The clock output register only becomes writable once the PLL reset
and calibration have completed, so program it at the end of the mode
configuration rather than at probe time.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
The XPCS signals USXGMII in-band autonegotiation completion through an
interrupt that is never enabled, waited for or acknowledged, so rate
adaptation never starts and the MAC receives nothing even though the
SerDes achieves block lock. The advertised speed and duplex are also
left at their reset values while autonegotiation runs.
Follow the vendor SSDK sequence: enable the completion interrupt and
advertise 10G/full duplex when configuring the PCS, and on link-up
restart the in-band autonegotiation, wait for completion and
acknowledge it before programming the negotiated speed. The wait is
best-effort, as in the vendor driver.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
Each uniphy has, besides the XPCS reset, a system reset in the GCC and
a soft reset in the NSSCC. The vendor driver pulses both on every
interface mode change as part of the uniphy bring-up. Describe them,
and name the resets while at it, so the PCS driver can pick them up.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
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>
Move the QCA8084 XPCS channel lookup fix into the SerDes speed config
patch, so qca8084_qxgmii_set_speed() walks the channel table with the
loop index from the start.
Move the PPE port reset loop fix into the PPE driver update patch, so
ppe_port_mac_reset() asserts and deasserts each reset control instead of
reusing the MAC reset for every iteration.
Signed-off-by: Igor Kravchenko <igor.kravchenko05@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23900
Signed-off-by: Robert Marko <robimarko@gmail.com>
Switch the qualcommbe target to use kernel 6.18 and drop 6.12.
Kernel 6.18 for qualcommbe resolves some issues regarding
PCS support and reduces maintenance load maintaining two
kernel branches.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/23908
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
During testing on the Askey SBE1V1K, it was noticed that only very low
PWM frequencies would work, and 100% duty cycles also did not work.
Comparing the proposed upstream pwm-ipq driver to the downstream vendor
driver, `ipq_pwm_apply()` fixed pwm_div at its maximum and derived only
pre_div from the requested period. Since the period spans
`(pre_div + 1) * (pwm_div + 1)` input clocks, pinning pwm_div near its
maximum forces pre_div towards zero for short periods: once pre_div
rounds to 0 the shortest representable period is
`(pwm_div + 1) / clk_rate` (~2.7 ms, i.e. ~366 Hz, at a 24 MHz clock),
and any shorter request is silently stretched to that. The high
duration then truncates to 0, so the output collapses to ~0% duty.
Since 4-wire fans commonly expect a ~25kHz PWM, it was effectively
unusable, since every duty cycle programs a ~zero high time.
Search for the (pre_div, pwm_div) pair whose period best approximates
the request instead of fixing pwm_div. Starting pre_div at the smallest
value that keeps pwm_div within its field and stopping once pre_div
exceeds pwm_div bounds the loop and keeps pwm_div as large as possible
for fine duty resolution. For a 25 kHz request at 24 MHz this selects
pre_div = 0, pwm_div = 959, giving full 0..960 duty resolution.
While reworking the high-duration computation, round it to nearest
rather than truncating, so mid-range duty cycles are not biased low, and
clamp it to pwm_div + 1. Rounding, or a 100% duty request, could
otherwise push hi_dur past the period length and overflow the 16-bit
HI_DURATION field.
Also compute hi_div in `get_state()` in 64-bit; `hi_dur * (pre_div + 1)`
can exceed 32 bits before the existing promotion.
Fixes: 01fb4a6daa ("qualcommbe: update pwm patches and add missing symbol")
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/23916
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
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>
Lets refresh the config as generic config was wastly updated, and we
need the CONFIG_PAGE_BLOCK_MAX_ORDER to be defined.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
I generate patches form git, so maintaining an old numbering scheme
does not integrate well with my workflow. renumber the pacthes here so
that the commit shows only the changes to the patches.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Create the config and relevant patches for 6.18 from 6.12. The
"standard" openwrt devel process seems to be to move the files and
restore the old ones. I find this process confusing, and I don't see
any git benefits for doing things this way. So just copy the files.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
The lastest ethernet PPE driver, uses "mac", "rx", and "tx", without
the "port_" prefix for the port clocks and resets. The PPE ports are
declared by the device dts. In order to support v6.12 and v6.18
kernels simultaneously, update the kernel patches and kiwi-dvk
devicetree to use the newer naming scheme.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Satoshi Ikeuchi
krava
Robert Marko
Jackie Han
Robert Marko
John Audia
George Moussalem
Balsam CHIHI
Andrew LaMarche
Chukun Pan
Shiji Yang
Julius Bairaktaris
Daniel Golle
Rosen Penev
Sven Eckelmann
Alexandru Gagniuc