aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/mpc85xx/patches-5.10
Commit message (Collapse)AuthorAgeFilesLines
* kernel: bump 5.10 to 5.10.145John Audia2022-10-041-42/+0
| | | | | | | | | | | | | | | Manually rebased: hack-5.10/780-usb-net-MeigLink_modem_support.patch Removed upstreamed: patches-5.10/110-gpio-mpc8xxx-Fix-support-for-IRQ_TYPE_LEVEL_LOW-flow.patch[1] All other patches automatically rebased. 1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.145&id=24196210b198e8e39296e277bb93b362aa207775 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 8fe67fae1d619467b2b3300178d4309f17cfdb54)
* mpc85xx: add patch to fix gpio mpc8xxxJosef Schlehofer2022-09-241-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backports Linux kernel patch [1] for kernel 5.10 where it applies cleanly. This was tested on CZ.NIC Turris 1.1 router running OpenWrt 22.03 release. Before: - In /var/log/messages: ``` [ 16.392988] lm90 0-004c: cannot request IRQ 48 [ 16.398280] lm90: probe of 0-004c failed with error -22 ``` - Sensors does not work: ``` root@turris:~# sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. ``` After: ``` root@turris:/# sensors sa56004-i2c-0-4c Adapter: MPC adapter (i2c@3000) temp1: +44.0°C (low = +0.0°C, high = +70.0°C) (crit = +85.0°C, hyst = +75.0°C) temp2: +73.8°C (low = +0.0°C, high = +70.0°C) ALARM (HIGH) (crit = +85.0°C, hyst = +75.0°C) ``` [1] https://lore.kernel.org/linux-gpio/20220906105431.30911-1-pali@kernel.org/ Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> (cherry picked from commit 2f496c34b6dfbedbfbff8d2ade5d629f096e40bd) (c&p commit ID from openwrt's master) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* kernel: bump 5.10 to 5.10.122John Audia2022-06-271-1/+1
| | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 9edc514e3dafcc36db69046a37daab818cfc1a07)
* kernel: bump 5.10 to 5.10.107John Audia2022-03-191-7/+0
| | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: bcm2711/RPi4B, mt7622/RT3200 Run-tested: bcm2711/RPi4B, mt7622/RT3200 Signed-off-by: John Audia <graysky@archlinux.us>
* mpc85xx: add support for Extreme Networks WS-AP3825iMartin Kennedy2022-03-161-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware: - SoC: Freescale P1020 - CPU: 2x e500v2 @ 800MHz - Flash: 64MiB NOR (1x Intel JS28F512) - Memory: 256MiB (2x ProMOS DDR3 V73CAG01168RBJ-I9H 1Gb) - WiFi1: 2.4+5GHz abgn 3x3 (Atheros AR9590) - Wifi2: 5GHz an+ac 3x3 (Qualcomm Atheros QCA9890) - ETH: 2x PoE Gigabit Ethernet (2x Atheros AR8035) - Power: 12V (center-positive barrel) or 48V PoE (active or passive) - Serial: Cisco-compatible RJ45 next to 12V power socket (115200 baud) - LED Driver: TI LV164A - LEDs: (not functioning) - 2x Power (Green + Orange) - 4x ETH (ETH1 + ETH2) x (Green + Orange) - 2x WiFi (WiFi2 + WiFi1) Installation: 1. Grab the OpenWrt initramfs <openwrt-initramfs-bin>, e.g. openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-initramfs-kernel.bin. Place it in the root directory of a DHCP+TFTP server, e.g. OpenWrt `dnsmasq` with configuration `dhcp.server.enable_tftp='1'`. 2. Connect to the serial port and boot the AP with options e.g. 115200,N,8. Stop autoboot in U-Boot by pressing Enter after 'Scanning JFFS2 FS:' begins, then waiting for the prompt to be interrupted. Credentials are identical to the one in the APs interface. By default it is admin / new2day: if these do not work, follow the OEM's reset procedure using the reset button. 3. Set the bootcmd so the AP can boot OpenWrt by executing: ```uboot setenv boot_openwrt "cp.b 0xEC000000 0x2000000 0x2000000; interrupts off; bootm start 0x2000000; bootm loados; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go;" setenv bootcmd "run boot_openwrt" saveenv ``` If you plan on going back to the vendor firmware - the bootcmd for it is stored in the boot_flash variable. 4. Load the initramfs image to RAM and boot by executing ```uboot setenv ipaddr <ipv4 client address>; setenv serverip <tftp server address>; tftpboot 0x2000000 <openwrt-initramfs-bin>; interrupts off; bootm start 0x2000000; bootm loados; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go; ``` 5. Make a backup of the "firmware" partition if you ever wish to go back to the vendor firmware. 6. Upload the OpenWrt sysupgrade image via SCP to the devices /tmp folder. 7. Flash OpenWrt using sysupgrade. ```ash sysupgrade /tmp/<openwrt-sysupgrade-bin> ``` Notes: - We must step through the `bootm` process manually to avoid fdt relocation. To explain: the stock U-boot (and stock Linux) are configured with a very large CONFIG_SYS_BOOTMAPSZ (and the device's stock Linux kernel is configured to be able to handle it). The U-boot version predates the check for the `fdt_high` variable, meaning that upon fdt relocation, the fdt can (and will) be moved to a very high address; the default appears to be 0x9ffa000. This address is so high that when the Linux kernel starts reading the fdt at the beginning of the boot process, it encounters a memory access exception and panics[5]. While it is possible to reduce the highest address the fdt will be relocated to by setting `bootm_size`, this also has the side effect of limiting the amount of RAM the kernel can use[3]. - Because it is not relocated, the flattened device tree needs to be padded in the build process to guarantee that `fdt resize` has enough space. - The primary ethernet MAC address is stored (and set) in U-boot; they are shimmed into the device tree by 'fdt boardsetup' through the 'local-mac-address' property of the respective ethernet node, so OpenWrt does not need to set this at runtime. Note that U-boot indexes the ethernet nodes by alias, which is why the device tree explicitly aliases ethernet1 to enet2. - LEDs do not function under OpenWrt. Each of 8 LEDs is connected to an output of a TI LV164A shift register, which is wired to GPIO lines and operates through bit-banged SPI. Unfortunately, I am unable to get the spi-gpio driver to recognize the `led_spi` device tree node at all, as confirmed by patching in printk messages demonstrating spi-gpio.c::spi_gpio_probe never runs. It is possible to manually articulate the shift register by exporting the GPIO lines and stepping their values through the sysfs. - Though they do not function under OpenWrt, I have left the pinout details of the LEDs and shift register in the device tree to represent real hardware. - An archive of the u-boot and Linux source for the AP3825i (which is one device of a range of devices code-named 'CHANTRY') be found here[1]. - The device has an identical case to both the Enterasys WS-AP3725i and Adtran BSAP-2030[2] (and potentially other Adtran BSAPs). Given that there is no FCC ID for the board itself (only its WLAN modules), it's likely these are generic boards, and even that the WS-AP3725i is identical, with only a change in WLAN card. I have ordered one to confirm this. - For additional information: the process of porting the board is documented in an OpenWrt forum thread[4]. [1]: magnet:?xt=urn:btih:f5306a5dfd06d42319e4554565429f84dde96bbc [2]: https://forum.openwrt.org/t/support-for-adtran-bluesocket-bsap-2030/48538 [3]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168/29 [4]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168 [5]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168/26 Tested-by: Martin Kennedy <hurricos@gmail.com> Signed-off-by: Martin Kennedy <hurricos@gmail.com>
* kernel: move bootargs-append patch to genericSungbo Eo2022-01-291-2/+2
| | | | | | | | | | This moves bootargs-append support patch from ipq40xx and ipq806x to generic. This way we can append additional boot arguments from DTS instead of only being able to overwrite them. This is a preparation for kirkwood support of ipTIME NAS1. Signed-off-by: Sungbo Eo <mans0n@gorani.run>
* kernel: bump 5.10 to 5.10.88Rui Salvaterra2021-12-271-55/+0
| | | | | | | | | Deleted (upstreamed): mpc85xx/patches-5.10/002-powerpc-85xx-fix-oops-when-CONFIG_FSL_PMC-n.patch [1] [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.88&id=151ffac3ac277ad7c2a5f201b566b56d97ed3a99 Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* mpc85xx: backport "fix oops when CONFIG_FSL_PMC=n"Christian Lamparter2021-11-281-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Martin Kennedy reported: |Presently, I get this kernel panic on mpc85xx (Aerohive HiveAP 370) |on OpenWrt 'master' which occurs right as the second processor is |initialized: | |[ 0.478804] rcu: Hierarchical SRCU implementation. |[ 0.535569] dyndbg: Ignore empty _ddebug table in a CONFIG_DYNAMIC_DEBUG_CORE build |[ 0.627233] smp: Bringing up secondary CPUs ... |[ 0.681659] kernel tried to execute user page (0) - exploit attempt? (uid: 0) |[ 0.766618] BUG: Unable to handle kernel instruction fetch (NULL pointer?) |[ 0.848899] Faulting instruction address: 0x00000000 |[ 0.908273] Oops: Kernel access of bad area, sig: 11 [#1] |[ 0.972851] BE PAGE_SIZE=4K SMP NR_CPUS=2 P1020 RDB |[ 1.031179] Modules linked in: |[ 1.067640] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.80 #0 |[ 1.139507] NIP: 00000000 LR: c0021d2c CTR: 00000000 |[ 1.199921] REGS: c1051cf0 TRAP: 0400 Not tainted (5.10.80) |[...] |[ 1.758220] NIP [00000000] 0x0 |[ 1.794688] LR [c0021d2c] smp_85xx_kick_cpu+0xe8/0x568 |[ 1.856126] Call Trace: |[ 1.885295] [c1051da8] [c0021cb8] smp_85xx_kick_cpu+0x74/0x568 (unreliable) |[ 1.968633] [c1051de8] [c0011460] __cpu_up+0xc0/0x228 |[ 2.029038] [c1051e18] [c0031bbc] bringup_cpu+0x30/0x224 |[ 2.092572] [c1051e48] [c0031f3c] cpu_up.constprop.0+0x180/0x33c |[..] |[ 2.727952] ---[ end trace 9b796a4bafb6bc14 ]--- |[ 3.800879] Kernel panic - not syncing: Fatal exception |[ 3.862353] Rebooting in 1 seconds.. |[ 5.905097] System Halted, OK to turn off power | |I bisected this down to commit 3ae5da5adce9 ("kernel: bump 5.10 to 5.10.80"); |that is, I don't get the panic right before this commit, but I do after. He reported the issue upstream and Xiaoming Ni from huawei came up with the patch (that is on it's way to upstream). While the AP370 is not in Openwrt, this will likely affect other SMP P1020 devices OpenWrt ships with: like the AP330, Enterasys WS-AP3710i, etc. Reported-by: Martin Kennedy <hurricos@gmail.com> Tested-by: Martin Kennedy <hurricos@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* kernel: bump 5.10 to 5.10.80Rui Salvaterra2021-11-195-5/+5
| | | | | | | | | | | | | | | | | | | | | | Deleted (upstreamed): ath79/patches-5.10/921-serial-core-add-support-for-boot-console-with-arbitr.patch [1] bcm53xx/patches-5.10/033-v5.15-0012-ARM-dts-BCM5301X-Fix-memory-nodes-names.patch [2] lantiq/patches-5.10/0016-mtd-rawnand-xway-Keep-the-driver-compatible-with-on-.patch [3] lantiq/patches-5.10/0110-MIPS-lantiq-dma-add-small-delay-after-reset.patch [4] lantiq/patches-5.10/0111-MIPS-lantiq-dma-reset-correct-number-of-channel.patch [5] lantiq/patches-5.10/0112-MIPS-lantiq-dma-fix-burst-length-for-DEU.patch [6] Manually rebased: ipq806x/patches-5.10/0065-arm-override-compiler-flags.patch [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.80&id=47462c5e600fbaffd755cd13dedd80d04e41ff83 [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.80&id=2fde76df1885a6bec04317e457121326070450eb [3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.80&id=9b366f5221d8aa64b22f35be137a5749326444ce [4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.80&id=5af57ce8a6155fe3e4270d28d171abf8903bebc0 [5] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.80&id=b92a5df2c7adc79a57481445f67de0c1c716581f [6] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.80&id=6b72caabc47011d03f44064452b2c65e8ed18326 Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* kernel: bump 5.10 to 5.10.20Rui Salvaterra2021-03-051-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | Also add a new kconfig symbol (CONFIG_KCMP) to the generic config, disabling the SYS_kcmp syscall (it was split from CONFIG_CHECKPOINT_RESTORE, which is disabled by default, so the previous behaviour is kept). Removed (upstreamed) patches: 070-net-icmp-pass-zeroed-opts-from-icmp-v6-_ndo_send-bef.patch 081-wireguard-device-do-not-generate-ICMP-for-non-IP-pac.patch 082-wireguard-queueing-get-rid-of-per-peer-ring-buffers.patch 083-wireguard-kconfig-use-arm-chacha-even-with-no-neon.patch 830-v5.12-0002-usb-serial-option-update-interface-mapping-for-ZTE-P685M.patch Manually rebased patches: 313-helios4-dts-status-led-alias.patch 104-powerpc-mpc85xx-change-P2020RDB-dts-file-for-OpenWRT.patch Run tested: ath79 (TL-WDR3600) mvebu (Turris Omnia) Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* mpc85xx: p2020: Fix nand driver probePawel Dembicki2021-03-011-1/+9
| | | | | | | | | | | | | | | At this moment driver start fail with error: [ 3.771991] fsl,elbc-fcm-nand: probe of ffa00000.nand failed with error -22 elbc-fcm-nand driver use legacy method of ecc mode detection. It detect hw/sw ecc mode when system configure it to "none". [1] This patch adds 'nand-ecc-mode = "none"' propoerty to use generic driver ecc mode detection. [1] https://elixir.bootlin.com/linux/v5.10.18/source/drivers/mtd/nand/raw/fsl_elbc_nand.c#L730 Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
* kernel: bump version 5.10 to 5.10.18Kabuli Chana2021-02-242-5/+5
| | | | | | | | update kernel version, refresh current patchset Signed-off-by: Kabuli Chana <newtownBuild@gmail.com> [rebase/refresh] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mpc85xx-p1010: add Kernel 5.10 supportDavid Bauer2021-02-209-0/+453
Tested on: Sophos RED 15W The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the default kernel. When building with all kmods enabled, the resulting kernel image exceeds the maximum size the bootloader reads from the flash. For more information, see GitHub issue #1773 Signed-off-by: David Bauer <mail@david-bauer.net>