Because some still unresolved bugs in this driver, which sprout
occasional questions what this patch works around, point to the issue
which started this. Being here, fill headers required by git am.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Let's pick a bunch of useful phylink changes which allow us to keep
drivers in sync with mainline Linux.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Initial conversion to new LED color/function format
and drop label format where possible. The same label
is composed at runtime.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Drop redundant label with new LED color/function format declared.
This was needed previously when the new format wasn't supported by
leds.sh functions script. Now that is supported this property
can be removed in favor of the new format.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The Puzzle devices come with an I2C-connected Epson RX8130 RTC.
Disable the (dysfunctional) RTC units of the SoC and add driver
kmod-rtc-ds1307 to support the Epson RX8130 instead.
Tested-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The Synology DS213j is a rather dated dual-bay SATA NAS based on on the
Marvell Armada-370 SoC. It has long been supported in vanilla Linux,
however, flash partitioning there didn't match with reality (ie. the
bootloaders expectations) and nobody cared to wrap up OpenWrt support
for the device.
CPU: Marvell Armada-370 ARMv7 SoC @ 1200 MHz
RAM: 512 MB DDR3
Flash: 8 MB (Micron Technology N25Q064)
Network: 1x 1000M/100M/10M Ethernet (Marvell 88E1510)
SATA: 2x 3.0Gbps
USB: 2x USB 2.0
As OS options are becoming limited on that still quite useful hardware,
patch the flash partitions to be able to get the most out of it when
using OpenWrt.
The vendor firmware loads kernel and initrd from fixed addresses in
the flash, not making use of a modifyable environment stored in flash
which is stored at a location right in the middle of the vendor's
zImage partition (at 0x100000).
Stock firmware flash layout:
0x000000 ~ 0x0c0000 : "RedBoot" (actually U-Boot)
0x0c0000 ~ 0x390000 : "zImage"
0x390000 ~ 0x7d0000 : "rd.gz"
0x7d0000 ~ 0x7e0000 : "vendor" (contains MAC address, serial no)
0x7e0000 ~ 0x7f0000 : "RedBoot Config" (unused? legacy left-over)
0x7f0000 ~ 0x800000 : "FIS directory" (unused? legacy left-over)
OpenWrt flash layout:
0x000000 ~ 0x0c0000 : "u-boot"
0x0c0000 ~ 0x100000 : "gap"
0x100000 ~ 0x110000 : "u-boot-env"
0x110000 ~ 0x7d0000 : "kernel"
0x7d0000 ~ 0x7e0000 : "vendor" (contains MAC address, serial no)
0x7e0000 ~ 0x800000 : "gap2"
"kernel", "gap" and "gap2" are concatenated using the mtd-concat
virtual MTD driver, resulting in a partition "firmware" used by
OpenWrt for kernel, rootfs and rootfs-overlay, 0x720000 (7296kiB) in
total.
Installation:
1. Connect to internal serial console port and Ethernet port,
providing a TFTP server at a static IPv4 address, e.g.
192.168.1.254/24.
2. Interrupt bootloader using CTRL+C
3. Configure bootloader to load OpenWrt on future boot:
setenv bootcmd "bootm f4110000"
saveenv
4. Load and boot initramfs image via TFTP:
setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.254
tftpboot openwrt-mvebu-cortexa9-synology_ds213j-initramfs-kernel.bin
bootm
5. Use sysupgrade to load final image.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Since kernel 5.11, the PXA I2C driver has been converted to generic I2C
recovery, which makes the I2C bus completely lock up if recovery pinctrl
is present in the DT and I2C recovery is enabled.
This effectively completely broke I2C on Methode uDPU and eDPU boards
as both of them rely on I2C recovery.
After a discussion upstream, it was concluded that there is no simple fix
and that the blamed upstream commit:
0b01392c18b9993a584f36ace1d61118772ad0ca ("i2c: pxa: move to generic GPIO
recovery") should be reverted.
I have sent the revert upstream, it should be merged soon so lets "fix"
OpenWrt as well.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Internet Initiative Japan Inc. (IIJ) SA-W2 is a network appliance with
11ac (Wi-Fi 5) wlan, based on 88F6810.
Specification:
- SoC : Marvell Armada 380 88F6810
- RAM : DDR3 256 MiB (Micron MT41K64M16TW-107:J x2)
- Flash : SPI-NOR 32 MiB (Winbond W25Q256JVFIQ)
- WLAN : 2.4/5 GHz, Mini PCI-E
- 2.4 GHz : Silex SX-PCEGN (Atheros AR9287 (2T2R))
- 5 GHz : Silex SX-PCEAC (Qualcomm Atheros QCA9880 (3T3R))
- Ethernet : 10/100/1000 Mbps x5
- Switch : Marvell 88E6172
- LEDs/Keys : 12x/1x
- UART : "CONSOLE" port (RJ-45, RS-232C)
- settings : 115200n8
- assignment: 1:NC, 2:NC, 3:TXD, 4:GND,
5:GND, 6:RXD, 7:NC, 8:NC
- note : compatible with Cisco console cable
- Power : DC Input or PoE
- DC Input : 12 VDC, 3 A
- PoE : 802.3af
- module : Silvertel Ag9712-2BR
- note : USB ports shouldn't be used when powered by PoE
- Bootloader : PMON2000 based
- Stock : NetBSD based
Flash instruction using sysupgrade image:
1. Prepare TFTP server with IP address 192.168.0.10 and put sysupgrade
image to TFTP directory
2. Connect PC to "GE0/PoE" port on SA-W2
3. Power on SA-W2, interrupt count-down by Esc and enter to bootloader
CLI
4. Set IP address of the device
address 192.168.0.1
5. Download sysupgrade image and flash to storage
tftpload 192.168.0.10 <image name>
firmwrite
example:
#tftpload 192.168.0.10 openwrt-mvebu-cortexa9-iij_sa-w2-squashfs-sysupgrade.bin
Loading openwrt-mvebu-cortexa9-iij_sa-w2-squashfs-sysupgrade.bin
loaded 8127268 byte(s)
#firmwrite
Erasing FLASH block 32 Done 0x00200000.
Erasing FLASH block 33 Done 0x00210000.
...
Erasing FLASH block 155 Done 0x009b0000.
Erasing FLASH block 156 Done 0x009c0000.
Programming FLASH. Done.
Verifying FLASH. No Errors found.
6. Check the flashed firmware
firmcheck
example:
#firmcheck
[Normal firmware]
ident: 'SEIL2015'
copyright: 'ARM OpenWrt Linux-5.15.93'
version format: 1
version major: 9
version minor: 99
version release: 'r22060+36-5163bb5e54'
body size: 3578524
checksum: 0x8a083cb8
[Rescue firmware]
ident: 'SEIL2015'
copyright: 'Copyright (c) 2017 Internet Initiative Japan Inc. All rights reserved.'
version format: 1
version major: 3
version minor: 70
version release: 'Release'
body size: 10152458
checksum: 0x8f9518c2
7. Boot with the flashed firmware
boot
Note:
- The bootloader on this device is not U-Boot and it's environment space
("bootloader-env") has no compatibility with U-Boot tools.
- eth1 is connected to port6 of 88E6172 switch, but multi-cpu port can't
be handled on Linux Kernel and not defined.
- Powering by PoE hasn't been tested yet.
- This device has 2x OS images on flash and they can be switched by
setting "BOOTDEV" variable on bootloader CLI.
That variable supports the following values:
- "flash" : primary image on flash ("firmware")
- "rescue": secondary image on flash ("rescue")
- "usb" : usb storage (broken?)
- "lan0/1": network
command to set:
set BOOTDEV=<dev>
example:
set BOOTDEV=rescue
This commit also supports booting from secondary partition.
- To execute initramfs image on bootloader CLI, use "go" command.
("go" command is not listed on the output of "help", but available)
example (download and execute):
address 192.168.0.1
tftpload 192.168.0.10 openwrt-mvebu-cortexa9-iij_sa-w2-initramfs-kernel.bin
go
MAC addresses:
LAN : 00:E0:4D:xx:xx:19 (none)
WAN : 00:E0:4D:xx:xx:18 (board_info, 0x6 (hex))
2.4 GHz: 84:25:3F:xx:xx:xx (Mini PCI-E card)
5 GHz : 84:25:3F:xx:xx:xx (Mini PCI-E card)
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Fortinet FortiGate 30E (FG-30E) is a UTM, based on Armada 385 (88F6820).
Specification:
- SoC : Marvell Armada 385 88F6820
- RAM : DDR3 1 GiB (4x Micron MT41K256M8DA-125, "D9PSH")
- Flash : SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- Ethernet : 5x 10/100/1000 Mbps
- Switch : Marvell 88E6176
- LEDs/Keys : 16x/1x
- UART : "CONSOLE" port (RJ-45, RS-232C level)
- port : ttyS0
- settings : 9600bps 8n1
- assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
5:GND, 6:RXD, 7:NC , 8:NC
- note : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power : 12 VDC, 2 A
- plug : Modex 5557-02R
Flash instruction using initramfs image:
1. Power on FG-30E and interrupt to show bootmenu
2. Call "[I]: System information." -> "[S]: Set serial port baudrate."
and set baudrate to 9600 bps
3. Call "[R]: Review TFTP parameters.", check TFTP parameters and
connect computer to "Image download port" in the parameters
4. Prepare TFTP server with the parameters obtained above
5. Rename OpenWrt initramfs image to "image.out" and put to TFTP
directory
6. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
image from TFTP server
7. Type "r" key when the following message is showed, to boot initramfs
image without flashing to spi-nor flash
"Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"
8. On initramfs image, backup mtd if needed
minimum:
- "firmware-info"
- "kernel"
- "rootfs"
9. On initramfs image, upload sysupgrade image to the device and perform
sysupgrade
10. Wait ~200 seconds to complete flashing and rebooting.
If the device is booted with stock firmware, login to bootmenu and
call "[B]: Boot with backup firmware and set as default." to set the
first OS image as default and boot it.
Notes:
- Both colors of Bi-color LEDs on the front panel cannot be turned on at
the same time.
- "PWR" and "Logo" LEDs are connected to power source directly.
- The following partitions are added for OpenWrt.
These partitions are contained in "uboot" partition (0x0-0x1fffff) on
stock firmware.
- "firmware-info"
- "dtb"
- "u-boot-env"
- "board-info"
Image header for bootmenu tftp:
0x0 - 0xf : ?
0x10 - 0x2f : Image Name
0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?
*: required for initramfs image
MAC addresses:
(eth0): 70:4C:A5:xx:xx:CE (board-info, 0xd880 (hex))
WAN : 70:4C:A5:xx:xx:CF
LAN 1 : 70:4C:A5:xx:xx:D0
LAN 2 : 70:4C:A5:xx:xx:D1
LAN 3 : 70:4C:A5:xx:xx:D2
LAN 4 : 70:4C:A5:xx:xx:D3
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
This backports patches
leds: turris-omnia: convert to use dev_groups
leds: turris-omnia: Use sysfs_emit() instead of sprintf()
leds: turris-omnia: Drop unnecessary mutex locking
leds: turris-omnia: Do not use SMBUS calls
leds: turris-omnia: Make set_brightness() more efficient
leds: turris-omnia: Support HW controlled mode via private trigger
leds: turris-omnia: Add support for enabling/disabling HW gamma correction
leds: turris-omnia: Fix brightness setting and trigger activating
into backport-5.15.
The above patches replace:
leds: turris-omnia: support HW controlled mode via private trigger
leds: turris-omnia: initialize multi-intensity to full
leds: turris-omnia: change max brightness from 255 to 1
from mvebu/patches-5.15.
Signed-off-by: Marek Behún <kabel@kernel.org>
This backports patches
leds: turris-omnia: Use sysfs_emit() instead of sprintf()
leds: turris-omnia: Drop unnecessary mutex locking
leds: turris-omnia: Do not use SMBUS calls
leds: turris-omnia: Make set_brightness() more efficient
leds: turris-omnia: Support HW controlled mode via private trigger
leds: turris-omnia: Add support for enabling/disabling HW gamma correction
leds: turris-omnia: Fix brightness setting and trigger activating
into backport-6.1.
The above patches replace:
leds: turris-omnia: support HW controlled mode via private trigger
leds: turris-omnia: initialize multi-intensity to full
leds: turris-omnia: change max brightness from 255 to 1
from mvebu/patches-6.1.
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
New revision of eDPU uses an Marvell MV88E6361 switch to connect the SFP
cage and G.hn IC instead of connecting them directly to the ethernet
controllers.
The same image can be used on both versions as U-Boot will enable the
switch node and disable the unused ethernet controller.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Since kernel 5.13 this is needed to enable USB ports on all devices in
subtarget. Previously TF-A and COMPHY driver might have set up this PHY,
but not anymore.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Tested-by: Robert Marko <robimarko@gmail.com>
This should be a part of kernel major bump. Fortunately it didn't stall
compilation, so no fixes tag.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
This has been a part of modified upstream patch but got lost on major
kernel bump to 5.15, so bring it back.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
[Add patch for kernel 6.1 too]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
With an initial set of patches and configs in place let's start testing
with kernel 6.1.
Run-tested on the cortexa9 subtarget (WRT1900ACS, Turris Omnia)
Tested-by: Etienne Champetier <champetier.etienne@gmail.com>
Signed-off-by: Stefan Kalscheuer <stefan@stklcode.de>
Backport Russell King's series [1]
net: mvneta: reduce size of TSO header allocation
to pending-5.15 to fix random crashes on Turris Omnia.
This also backports two patches that are dependencies to this series:
net: mvneta: Delete unused variable
net: mvneta: fix potential double-frees in mvneta_txq_sw_deinit()
[1] https://lore.kernel.org/netdev/ZCsbJ4nG+So%2Fn9qY@shell.armlinux.org.uk/
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (squashed)
The omnia-medkit (only useful for installation with U-Boot
2015.10-rc2) is not being built anymore.
Now we can be reasonably sure, that there won't be first-time OpenWrt
boots with that U-Boot version, and can get rid of a rather ugly hack.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Since August 2022, users of very old Turris Omnias have been
encouraged to update U-Boot before OpenWrt installation [1].
The omnia-medkit (only useful for installation with
U-Boot 2015.10-rc2) is not needed anymore.
[1] https://openwrt.org/toh/turris/turris_omnia#installation
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Use <mdio>:<addr>:<speed> trigger instead of netdev(link) trigger for
Fortinet FortiGate 50E, to indicate link speed on the each phys.
1000 Mbps: Green
100 Mbps : Amber
10 Mbps : (turn off)
Fixes: 102dc5a625 ("mvebu: add support for Fortinet FortiGate 50E")
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
To use <mdio>:<addr>:<speed> trigger for LEDs, enable PHY LED trigger
(CONFIG_LED_TRIGGER_PHY).
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
All targets are bumped to 5.15. Remove the old 5.10 patches, configs
and files using:
find target/linux -iname '*-5.10' -exec rm -r {} \;
Further, remove the 5.10 include.
Signed-off-by: Nick Hainke <vincent@systemli.org>
Avoid MCU getting "command reply receive timed out" message when LED
configuration setting trigger function is enabled in heartbeat mode.
Signed-off-by: Ian Chang <ianchang@ieiworld.com>
It appears that the refactor of the upgrade process for NAND devices resulted in the nand_do_upgrade_success step not being called for
devices using the linksys.sh script. As a result, configuration was
not preserved over sysupgrade steps.
This restores the preservation of configs for mvebu/cortexa9 devices using the
linksys.sh script.
Fixes: e25e6d8e54 ("base-files: fix and clean up nand sysupgrade code")
Signed-off-by: Michael Trinidad <trinidude4@hotmail.com>
Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820).
Specification:
- SoC : Marvell Armada 385 88F6820
- RAM : DDR3 2 GiB (4x Micron MT41K512M8DA-107, "D9SGQ")
- Flash : SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- Ethernet : 7x 10/100/1000 Mbps
- LAN 1-5 : Marvell 88E6176
- WAN 1, 2 : Marvell 88E1512 (2x)
- LEDs/Keys : 18x/1x
- UART : "CONSOLE" port (RJ-45, RS-232C level)
- port : ttyS0
- settings : 9600bps 8n1
- assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
5:GND, 6:RXD, 7:NC , 8:NC
- note : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power : 12 VDC, 2 A
- plug : Molex 5557-02R
Flash instruction using initramfs image:
1. Power on FG-50E and interrupt to show bootmenu
2. Call "[R]: Review TFTP parameters.", check TFTP parameters and
connect computer to "Image download port" in the parameters
3. Prepare TFTP server with the parameters obtained above
4. Rename OpenWrt initramfs image to "image.out" and put to TFTP
directory
5. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
image from TFTP server
6. Type "r" key when the following message is showed, to boot initramfs
image without flashing to spi-nor flash
"Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"
7. On initramfs image, backup mtd if needed
minimum:
- "firmware-info"
- "kernel"
- "rootfs"
7. On initramfs image, upload sysupgrade image to the device and perform
sysupgrade
8. Wait ~200 seconds to complete flashing and rebooting.
If the device is booted with stock firmware, login to bootmenu and
call "[B]: Boot with backup firmware and set as default." to set the
first OS image as default and boot it.
Notes:
- All "SPEED" LEDs(Green/Amber) of LAN and 1000M "SPEED" LEDs(Green) of
WAN1/2 are connected to GPIO expander. There is no way to indicate
link speed of networking device on Linux Kernel/OpenWrt, so those LEDs
cannot be handled like stock firmware.
On OpenWrt, use netdev(link) trigger instead.
- Both colors of Bi-color LEDs on the front panel cannot be turned on at
the same time.
- "PWR" and "Logo" LEDs are connected to power source directly.
- The following partitions are added for OpenWrt.
These partitions are contained in "uboot" partition (0x0-0x1fffff) on
stock firmware.
- "firmware-info"
- "dtb"
- "u-boot-env"
- "board-info"
Image header for bootmenu tftp:
0x0 - 0xf : ?
0x10 - 0x2f : Image Name
0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?
*: required for initramfs image
MAC addresses:
(eth0): 70:4C:A5:xx:xx:7C (board-info, 0xd880 (hex))
WAN 1 : 70:4C:A5:xx:xx:7D
WAN 2 : 70:4C:A5:xx:xx:7E
LAN 1 : 70:4C:A5:xx:xx:7F
LAN 2 : 70:4C:A5:xx:xx:80
LAN 3 : 70:4C:A5:xx:xx:81
LAN 4 : 70:4C:A5:xx:xx:82
LAN 5 : 70:4C:A5:xx:xx:83
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
The Buffalo LinkStation LS220DE is a dual bay NAS, based on Marvell
Armada 370
Hardware:
SoC: Marvell Armada 88F6707
CPU: Cortex-A9 800 MHz, 1 core
Flash 1: SPI-NOR 1 MiB (U-Boot)
Flash 2: NAND 512 MiB (OS)
RAM: DDR3 256 MiB
Ethernet: 1x 1GbE
USB: 1x 2.0
SATA: 2x 3Gb/s
LEDs/Input: 5x / 2x (1x button, 1x slide-switch)
Fan: 1x casing
Flash instructions, from hard drive:
1. Get access to the "boot" partition at the hard drive where the stock
firmware is installed. It can be done with acp-commander or by
plugging the hard drive to a computer.
2. Backup the stock uImage:
mv /boot/uImage.buffalo /boot/uImage.buffalo.bak
3. Move and rename the Openwrt initramfs image to the boot partition:
mv openwrt-initramfs-kernel.bin /boot/uImage.buffalo
4. Power on the Linkstation with the hardrive inside. Now Openwrt will
boot, but still not installed.
5. Connect via ssh to OpenWrt:
ssh root@192.168.1.1
6. Rename boot files inside boot partition
mount -t ext3 /dev/sda1 /mnt
mv /mnt/uImage.buffalo /mnt/uImage.buffalo.openwrt.bak
mv /mnt/initrd.buffalo /mnt/initrd.buffalo.bak
7. Format ubi partitions at the NAND flash ("kernel_ubi" and "ubi"):
ubiformat /dev/mtd0 -y
ubidetach -p /dev/mtd1
ubiformat /dev/mtd1 -y
8. Flash the sysupgrade image:
sysupgrade -n openwrt-squashfs-sysupgrade.bin
9. Wait until it finish, the device will reboot with OpenWrt installed
on the NAND flash.
Restore the stock firmware:
1. Take the hard drive used for the installation and restore boot backup
files to their original names:
mount -t ext3 /dev/sda1 /mnt
mv /mnt/uImage.buffalo.bak /mnt/uImage.buffalo
mv /mnt/initrd.buffalo.bak /mnt/initrd.buffalo
2. Boot from the hard drive and perform a stock firmware update using
the Buffalo utility. The NAND will be restored to the original
state.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
Assign fan with 4 active cooling levels to be used for the main CPU as
well as external SerDes units.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Several fixes for the Puzzle WT61P803 hwmon driver were needed to make
it behave well as thermal cooling device:
- wire-up cooling device with OF node in device tree
- properly parse cooling-levels (u32 with range check vs. u8)
- actually use cooling-levels
- keep current state and only write to uC if state has changed
(avoids flooding the uC with commands which will result in uC crashing)
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Armada 7040 uses a rather small 15MB memory window for every PCI adapter,
however this is not sufficient for Qualcomm QCA6390 802.11ax cards that
are shipped along with the OpenWrt WLAN model of MOCHAbin as ath11k
requires at least 16MB of memory.
So, similar to what MACCHIATOBin has been doing for years, lets move
to using the second PCIe 2 memory window and expand it to 128MB to
make it future proof.
This has been already sent upstream [1].
[1] https://lore.kernel.org/linux-arm-kernel/20230219121418.1395401-1-robert.marko@sartura.hr/
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Starting from Linux Kernel version 6.3 UBI devices will no longer be
considered virtual, but rather have an MTD device parent. Hence they
will no longer be listed under /sys/devices/virtual/ubi which is
used in multiple places in OpenWrt. Prepare for future kernels by
using /sys/class/ubi instead of /sys/devuces/virtual/ubi.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
shellcheck warns against it with SC2086. It also hides a bug that
shellcheck marks with SC2015. Fixed those with explicit if/else.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Instead of using the shell's evaluation, use grep's -q parameter.
Found with shellcheck's SC2143.
Also replaced a head call with grep's -m.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Due to upstream change in U-boot the binaries were renamed [1].
[1] 87ac4b4b4c
Fixes: 2f83369e3e ("uboot-mvebu: update to version 2023.01")
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Upstream commit [1] included in the Linux kernel version 6.2 was
backported to Linux kernels 6.1.4, 6.0.18. It should be possible that it
is going to be backported even to the 5.15 series, but before it happens,
let's include it here.
It was discovered that on SOC Marvell Armada 3720, which is using e.g.
Turris MOX, and if you are also using it with older ARM Trusted Firmware
v1.5, it is not possible to detect connected USB 3.0 devices, but they
are working just fine when connected with USB 2.0 cable. This patch
fixes it.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/phy/marvell/phy-mvebu-a3700-comphy.c?id=b01d622d76134e9401970ffd3fbbb9a7051f976a
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Michal Hrusecky <michal.hrusecky@turris.com>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
[improve commit description, added tag to the patch]
The GL-MV1000 ships with a 16MB spi-nor flash, containing a copy of the stock GL.iNet firmware.
Add the corresponding flash areas, so our view matches the one of the in-flash stock firmware.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Removed upstreamed:
pending-5.15/101-Use-stddefs.h-instead-of-compiler.h.patch[1]
ipq806x/patches-5.15/122-01-clk-qcom-clk-krait-fix-wrong-div2-functions.patch[2]
bcm27xx/patches-5.15/950-0198-drm-fourcc-Add-packed-10bit-YUV-4-2-0-format.patch[3]
Manually rebased:
ramips/patches-5.15/100-PCI-mt7621-Add-MediaTek-MT7621-PCIe-host-controller-.patch[4]
Added patch/backported:
ramips/patches-5.15/107-PCI-mt7621-Add-sentinel-to-quirks-table.patch[5]
All other patches automatically rebased.
1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.15.86&id=c160505c9b574b346031fdf2c649d19e7939ca11
2. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.15.86&id=a051e10bfc6906d29dae7a31f0773f2702edfe1b
3. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.15.86&id=ec1727f89ecd6f2252c0c75e200058819f7ce47a
4. Quilt gave this output when I applied the patch to rebase it:
% quilt push -f
Applying patch platform/100-PCI-mt7621-Add-MediaTek-MT7621-PCIe-host-controller-.patch
patching file arch/mips/ralink/Kconfig
patching file drivers/pci/controller/Kconfig
patching file drivers/pci/controller/Makefile
patching file drivers/staging/Kconfig
patching file drivers/staging/Makefile
patching file drivers/staging/mt7621-pci/Kconfig
patching file drivers/staging/mt7621-pci/Makefile
patching file drivers/staging/mt7621-pci/TODO
patching file drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt
patching file drivers/staging/mt7621-pci/pci-mt7621.c
Hunk #1 FAILED at 1.
Not deleting file drivers/staging/mt7621-pci/pci-mt7621.c as content differs from patch
1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/mt7621-pci/pci-mt7621.c.rej
patching file drivers/pci/controller/pcie-mt7621.c
Applied patch platform/100-PCI-mt7621-Add-MediaTek-MT7621-PCIe-host-controller-.patch (forced; needs refresh)
Upon inspecting drivers/staging/mt7621-pci/pci-mt7621.c.rej, it seems that
the original patch wants to delete drivers/staging/mt7621-pci/pci-mt7621.c
but upstream's version was not an exact match. I opted to delete that
file.
5. Suggestion by hauke: 19098934f9
"This patch is in upstream kernel, but it was backported to the old
staging driver in kernel 5.15."
Build system: x86_64
Build-tested: bcm2711/RPi4B, filogic/xiaomi_redmi-router-ax6000-ubootmod
Run-tested: bcm2711/RPi4B, filogic/xiaomi_redmi-router-ax6000-ubootmod
Signed-off-by: John Audia <therealgraysky@proton.me>
This reverts commit 97c77fff28 as commit
8be6350f66 ("generic: 5.15: allow MV88E6xxx built-in when PTP support
disabled") contains the fix, so lets enable kernel 5.15 on mvebu again.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This reverts commit 5429411f73 as upstream
in commit e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies") has
changed `PTP_1588_CLOCK` dependency handling in 5.15 kernel.
That currently leads to `CONFIG_NET_DSA_MV88E6XXX=m` in images produced
by buildbots due to `CONFIG_ALL_KMODS=y` config option being used in
those builds, which leads to a broken LAN bridge network on several
devices.
References: https://lists.infradead.org/pipermail/openwrt-devel/2022-December/039950.html
Signed-off-by: Petr Štetiar <ynezz@true.cz>
In light of https://github.com/openwrt/openwrt/issues/11077, switch mvebu
to 5.15 which has been the testing kernel on this target since April - over
half a year.
Run-tested on the following subtargets:
* cortexa9 (Turris Omnia - 03f41b1eb2)
* cortexa72 (MikroTik RB5009UG+S+IN)
Tested-by: Enrico Mioso <mrkiko.rs@gmail.com> [GL-MV1000]
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Endianness depends on CPU architecture. CONFIG_CPU_(BIG/LITTLE)_ENDIAN should
be enabled on target or subtarget based on SoC architecture.
Fixes warning:
$ make kernel_oldconfig CONFIG_TARGET=subtarget
...
.config:1008:warning: override: CPU_LITTLE_ENDIAN changes choice state
....
Summary:
- ARC - only the CONFIG_CPU_BIG_ENDIAN symbol is defined for this architeture.
If it is disabled then the processor operates in LITTLE_ENDIAN mode (default),
- ARM32 - CONFIG_CPU_LITTLE_ENDIAN symbol available since kernel 5.19. This
option should be enabled after OpenWRT moves to kernel 6.x. After refreshing
the kernel, the symbol disappears,
- ARM64 - enabled CONFIG_CPU_LITTLE_ENDIAN,
- MIPS - enabled relevant symbols,
- POWERPC - enabled CONFIG_CPU_BIG_ENDIAN,
- UML - Symbols are not defined for this architecture,
- X86 - always little endian. Symbols are not defined for this architecture.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
It backports this patch series, which is currently on review:
https://lore.kernel.org/linux-leds/20220704105955.15474-1-kabel@kernel.org/T/#rb89a4ca5a836f17bdcc53d65549e0b1779bb6a18
It allows being able to configure LEDs in userspace.
This fixes issue described in Turris Build repository
https://gitlab.nic.cz/turris/os/build/-/issues/354
It happens in OpenWrt as well.
- Before
```
root@turris:/# ls /sys/class/leds/
ath10k-phy0 ath9k-phy1 mmc0::
```
-After
```
root@turris:/# ls /sys/class/leds/
ath10k-phy0 rgb:indicator-2 rgb:lan-3 rgb:wlan-1
ath9k-phy1 rgb:lan-0 rgb:lan-4 rgb:wlan-2
mmc0:: rgb:lan-1 rgb:power rgb:wlan-3
rgb:indicator-1 rgb:lan-2 rgb:wan
```
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
All targets expect the malta target already activate the CONFIG_GPIOLIB
option. Move it to generic kernel configuration and also activate it for
malta.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The line trying to generate the standard sdcard.img.gz fails due to
boot.scr not being generated.
Remove the line in order to use the default sdcard.img.gz which is
exactly the same but includes generating the boot.scr file.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add support for Methode euroDPU which is based on uDPU but does not
have a second SFP cage, instead of which a Maxlinear G.hn IC is used.
PHY mode is set to 1000Base-X despite Maxlinear IC being capable of
2500Base-X since until 5.15 support for mvebu is available trying to use
2500Base-X will cause buffer overruns for which the fix is not easily
backportable.
Installation instructions:
1. Boot the FIT initramfs image (openwrt-mvebu-cortexa53-methode_edpu-initramfs.itb)
2. sysupgrade using the openwrt-mvebu-cortexa53-methode_edpu-firmware.tgz
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
uDPU DTS has pending upstream fixups, so backport those as well as split
the DTS into a DTSI and DTS in preparation for euroDPU support which
uses uDPU as the base.
Ethernet aliases have not yet been sent upstream but will be soon in order
for U-boot to set the correct MAC on both ethernet interfaces instead of
just one.
Since U-boot environment now has its own partition, update the envtools
config script to search for it instead.
Patch hardcoding PHY mode is also not applicable anymore, so drop it and
set in the uDPU DTS directly.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
This is now built-in, enable so it won't propagate on target configs.
Link: https://lkml.org/lkml/2022/1/3/168
Fixes: 79e7a2552e ("kernel: bump 5.15 to 5.15.44")
Fixes: 0ca9367069 ("kernel: bump 5.10 to 5.10.119")
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(Link to Kernel's commit taht made it built-in,
CRYPTO_LIB_BLAKE2S[_ARM|_X86] as it's selectable, 5.10 backport)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Add support for LEDs of the CZ.NIC Turris Omnia using the upstream
driver.
There is no generic way to control the LEDs in UCI manner, however
the kernel module is the first step to actually use the RGB LEDs in
custom logic.
Signed-off-by: Stefan Kalscheuer <stefan@stklcode.de>
(removed DMARC notice, added driver to Turris Omnia, moved module
recipe to target/linux/mvebu/modules.mk)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
ClearFog GT 8K is device sold by SolidRun. It is marketed as a
development board, not a consumer product. The device tree file for this board
is upstream in kernel.org.
Signed-off-by: Logan Blyth <mrbojangles3@gmail.com>
This enables armv8 crypto extensions version of AES, GHASH, SHA1,
SHA256, and SHA512 algorithms in the kernel.
The choice of algorithms match the 32-bit versions that are enabled in
the target config-5.10 file, but were only used by the cortexa9
subtarget.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This enables armv8 crypto extensions version of AES, GHASH, SHA1,
SHA256, and SHA512 algorithms in the kernel.
The choice of algorithms match the 32-bit versions that are enabled in
the target config-5.10 file, but were only used by the cortexa9
subtarget.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Remove redundant target-level entries, noting that these settings will be
configured from "Kernel build options" of Kconfig.
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[remove from new configs introduced after patch submission]
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
uDPU has 2 LM75 compatible temperature sensors, so include the driver for
them by default in order to utilize them.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
uDPU provides a FIT based initramfs, but currently gets stuck after U-boot
starts the kernel at "Starting kernel..".
It is due to the load address being too low, so increase it in order to get
the initramfs booting again.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Enable support for allocating user space page table entries in high memory [1],
for the targets which support this feature. This saves precious low memory
(permanently mapped, the only type of memory directly accessible by the kernel).
[1] https://www.kernel.org/doc/html/latest/vm/highmem.html
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Adding the feature flag automatically creates a a rootfs.tar.gz files
which can be used for Docker rootfs containers.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Enable the AP806's cpufreq driver. This driver is compatible with the
Armada 7K and 8K platforms.
Tested-by: Stijn Segers <foss@volatilesystems.org> (RB5009UG+S+IN)
Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
On this device, two of the three defined MTD partitions are
automatically set to read-only, since they do not end at an
erase/write block boundary.
In particular, the only partition remaining writable is the
one holding the u-boot bootloader.
Mark all of the partitions read-only, at least until a better
understanding of why the layout has been laid out this way is
gained.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
The option is already enabled in the target config since 9149ed4f05
("mvebu: cortexa9: Add support for Ctera C200-V2").
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Fix syntax error in the case statement
Fixes: 9149ed4f05 ("mvebu: cortexa9: Add support for Ctera C200-V2")
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Move config options
CONFIG_PHY_MVEBU_A38X_COMPHY
CONFIG_RTC_DRV_MV
to cortexa9/config-5.10.
These are not needed for arm64 targets.
Signed-off-by: Marek Behún <kabel@kernel.org>
This option includes support for watchdog timer on Marvell Armada 37xx
SoCs. [1] It is useful e.g. for Turris MOX, Marvell ESPRESSObin
Enable armada-37xx-watchdog driver as built in for mvebu cortex-a53,
so that kernel can start serving as soon as the driver is probed, until userspace takes over it.
[1] https://cateee.net/lkddb/web-lkddb/ARMADA_37XX_WATCHDOG.html
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
(improved commit message, 2nd paragraph)
Signed-off-by: Marek Behún <kabel@kernel.org>
Enabling Armada 37xx rWTM driver. This gives the kernel access to random
number generator, if provided by the rWTM firmware.
Note that the driver is called turris-mox-rwtm because it was initially
written for Turris MOX, but will also work on other Armada 37xx
platforms, if they use rWTM firmware from CZ.NIC [1].
It makes sense to have this driver built-in, so that kernel has access
to random number generator without needing to load any drivers.
[1] https://gitlab.nic.cz/turris/mox-boot-builder
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Andre Heider <a.heider@gmail.com>
CONFIG_BLK_DEV_NVME [1]:
- This is a kernel driver for SSD connected to PCI or PCIe bus [1].
By default, it is enabled for targets "ipq807x", "rockchip/armv8"
and "x86/64".
With miniPCIe adapter, there is a possibility to connect NVMe disk
to Turris Omnia (cortex-a9), Turris MOX (cortex-a53).
It allows to boot system from NVMe disk, because of that it can not
be kmod package as you can not access the disk to be able to boot from
it.
CONFIG_NVME_CORE [2]:
- This is selected by CONFIG_BLK_DEV_NVME
It does not need to be explicitly enabled, but it is done for "ipq807",
"x64_64" and rockchip/armv8", which has also enabled the previous config
option as well.
Kernel increase: ~28k KiB on mamba kernel
Reference:
[1] https://cateee.net/lkddb/web-lkddb/BLK_DEV_NVME.html
[2] https://cateee.net/lkddb/web-lkddb/NVME_CORE.html
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Fix default network configuration of the Puzzle-M902 so all LAN ports
are included in the LAN bridge.
Setup network LED to indicate WAN port link status, like vendor
firmware does as well.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Fixes Ethernet link status on all ports and makes 2.5G ports usable
in 2.5G and 1G full-duplex mode.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Wire up MCU driver for LEDs, fan and temperature sensor, and add
GPIO reset button just like on the M902 also on the Puzzle M901.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Set blinking mode using scheduled work instead of blocking which may
result in deadlocks.
Add dynamic kprintf debugging hexdumps of all MCU rx and tx.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Backport MFD driver for communicating with the on-board MCU found on
IEI World Puzzle appliances.
Improve the driver to support multiple LEDs, apply a default state and
let MCU take care of blinking if timing is within supported range.
Wire up LEDs and fan for Puzzle M902 in device tree.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Each of
- CRYPTO_AEAD2
- CRYPTO_AEAD
- CRYPTO_GF128MUL
- CRYPTO_GHASH
- CRYPTO_HASH2
- CRYPTO_HASH
- CRYPTO_MANAGER2
- CRYPTO_MANAGER
- CRYPTO_NULL2
either directly required for mac80211 crypto support, or directly
selected by such options. Support for the mac80211 crypto was enabled in
the generic config since c7182123b9 ("kernel: make cryptoapi support
needed by mac80211 built-in"). So move the above options from the target
configs to the generic config to make it clear why do we need them.
CC: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Both CLANG_VERSION and LLD_VERISON are autogenerated runtime
configuration options, so add them to the kernel configuration filter
and remove from generic and per-target configs to keep configs clean.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
The recent changes to the maximum kernel size for Mamba and Venom
highlighted the fact that the old Mamba kernel size has been
hardcoded in linksys_get_root_magic() even for devices with
a different kernel/rootfs split.
The purpose of this code seems to be to avoid issues caused
by partially overwriting an existing UBI partition, where some
of the erase counters would be reset but not the unmodified
ones. This problem has been solved in a more generic way by
the UBI EOF marker. This ensures that any old PEBs after the
marker are properly initialized. It is therefore unnecessary
to erase the whole partition before flashing a new OpenWrt
factory image.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Implement a basic MQPrio support, inserting rules in RX that translate
the TC to prio mapping into vlan prio to queues.
Signed-off-by: Kabuli Chana <newtownBuild@gmail.com>
Deleted (upstreamed):
bcm27xx/patches-5.10/950-0145-xhci-add-quirk-for-host-controllers-that-don-t-updat.patch [1]
Manually rebased:
bcm27xx/patches-5.10/950-0355-xhci-quirks-add-link-TRB-quirk-for-VL805.patch
bcm53xx/patches-5.10/180-usb-xhci-add-support-for-performing-fake-doorbell.patch
Note: although automatically rebaseable, the last patch has been edited to avoid
conflicting bit definitions.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=b6f32897af190d4716412e156ee0abcc16e4f1e5
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
LED labels got reversed by accident, so fix it to the usual color:led_name format.
Fixes: 78cf3e53b1 ("mvebu: add Globalscale MOCHAbin")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
[add Fixes:]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Globalscale MOCHAbin is a Armada 7040 based development board.
Specifications:
* Armada 7040 Quad core ARMv8 Cortex A-72 @ 1.4GHz
* 2 / 4 / 8 GB of DDR4 DRAM
* 16 GB eMMC
* 4MB SPI-NOR (Bootloader)
* 1x M.2-2280 B-key socket (for SSD expansion, SATA3 only)
* 1x M.2-2250 B-key socket (for modems, USB2.0 and I2C only)
* 1x Mini-PCIe 3.0 (x1, USB2.0 and I2C)
* 1x SATA 7+15 socket (SATA3)
* 1x 16-pin (2×8) MikroBus Connector
* 1x SIM card slot (Connected to the mini-PCIe and both M.2 slots)
* 2x USB3.0 Type-A ports via SMSC USB5434B hub
* Cortex 2x5 JTAG
* microUSB port for UART (PL2303GL/PL2303SA onboard)
* 1x 10G SFP+
* 1x 1G SFP (Connected to 88E1512 PHY)
* 1x 1G RJ45 with PoE PD (Connected to 88E1512 PHY)
* 4x 1G RJ45 ports via Topaz 88E6141 switch
* RTC with battery holder (SoC provided, requires CR2032 battery)
* 1x 12V DC IN
* 1x Power switch
* 1x 12V fan header (3-pin, power only)
* 1x mini-PCIe LED header (2x0.1" pins)
* 1x M.2-2280 LED header (2x0.1" pins)
* 6x Bootstrap jumpers
* 1x Power LED (Green)
* 3x Tri-color RGB LEDs (Controllable)
* 1x Microchip ATECC608B secure element
Note that 1G SFP and 1G WAN cannot be used at the same time as they are in
parallel connected to the same PHY.
Installation:
Copy dtb from build_dir to bin/ and run tftpserver there:
$ cp ./build_dir/target-aarch64_cortex-a72_musl/linux-mvebu_cortexa72/image-armada-7040-mochabin.dtb bin/targets/mvebu/cortexa72/
$ in.tftpd -L -s bin/targets/mvebu/cortexa72/
Connect to the device UART via microUSB port and power on the device.
Power on the device and hit any key to stop the autoboot.
Set serverip (host IP) and ipaddr (any free IP address on the same subnet), e.g:
$ setenv serverip 192.168.1.10 # Host
$ setenv ipaddr 192.168.1.15 # Device
Set the ethernet device (Example for the 1G WAN):
$ setenv ethact mvpp2-2
Ping server to confirm network is working:
$ ping $serverip
Using mvpp2-2 device
host 192.168.1.15 is alive
Tftpboot the firmware:
$ tftpboot $kernel_addr_r openwrt-mvebu-cortexa72-globalscale_mochabin-initramfs-kernel.bin
$ tftpboot $fdt_addr_r image-armada-7040-mochabin.dtb
Boot the image:
$ booti $kernel_addr_r - $fdt_addr_r
Once the initramfs is booted, transfer openwrt-mvebu-cortexa72-globalscale_mochabin-squashfs-sdcard.img.gz
to /tmp dir on the device.
Gunzip and dd the image:
$ gunzip /tmp/openwrt-mvebu-cortexa72-globalscale_mochabin-squashfs-sdcard.img.gz
$ dd if=/tmp/openwrt-mvebu-cortexa72-globalscale_mochabin-squashfs-sdcard.img of=/dev/mmcblk0 && sync
Reboot the device.
Hit any key to stop the autoboot.
Reset U-boot env and set the bootcmd:
$ env default -a
$ setenv bootcmd 'load mmc 0 ${loadaddr} boot.scr && source ${loadaddr}'
Optionally I would advise to edit the console env variable to remove earlycon as that
causes the kernel to never use the driver for the serial console.
Earlycon should be used only for debugging before the kernel can configure the console
and will otherwise cause various issues with the console.
$ setenv console 'console=ttyS0,115200'
Save and reset
$ saveenv
$ reset
OpenWrt should boot from eMMC now.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
1. Add support for Marvell CN9130 SoC
2. Add support for CP115,and create an armada-cp11x.dtsi file which will be used to instantiate both CP110 and CP115
3. Add support for AP807/AP807-quad,AP807 is a major component of CN9130 SoC series
4. Drop PCIe I/O ranges from CP11x file and externalize PCIe macros from CP11x file
Signed-off-by: Ian Chang <ianchang@ieiworld.com>
It's been brewing on my cortexa9 subtarget (Turris Omnia) for months.
Perfectly stable.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
[modify subject to match previous updates]
Signed-off-by: Paul Spooren <mail@aparcar.org>
CONFIG_RCU_{NEED_SEGCBLIST,STALL_COMMON} are set basically everywhere. Move them
to the generic kconfigs. And resort the generic kconfigs while at it.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
While an image layout based on MBR and 'bootfs' partition may be easy
to understand for users who are very used to the IBM PC and always have
the option to access the SD card outside of the device (and hence don't
really depend on other recovery methods or dual-boot), in my opinion
it's a dead end for many desirable features on embedded systems,
especially when managed remotely (and hence without an easy option to
access the SD card using another device in case things go wrong, for
example).
Let me explain:
* using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a
single corruption of the bootfs can render the system into a state
that it no longer boots at all. This makes dual-boot useless, or at
least very tedious to setup with then 2 independent boot partitions
to avoid the single point of failure on a "hot" block (the FAT index
of the boot partition, written every time a file is changed in
bootfs). And well: most targets even store the bootloader environment
in a file in that very same FAT filesystem, hence it cannot be used
to script a reliable dual-boot method (as loading the environment
itself will already fail if the filesystem is corrupted).
* loading the kernel uImage from bootfs and using rootfs inside an
additional partition means the bootloader can only validate the
kernel -- if rootfs is broken or corrupted, this can lead to a reboot
loop, which is often a quite costly thing to happen in terms of
hardware lifetime.
* imitating MBR-boot behavior with a FAT-formatted bootfs partition
(like IBM PC in the 80s and 90s) is just one of many choices on
embedded targets. There are much better options with modern U-Boot
(which is what we use and build from source for all targets booting
off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623.
Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix
functions with 'legacy_sdcard_' instead of 'sdcard_'.
Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This patch is backported from linux-arm-kernel [1] to improve situation, when
it was reported that 1.2 GHz variant is unstable with DFS.
It waits to be accepted upstream, however, it waits for Marvell people to respond.
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210630225601.6372-1-kabel@kernel.org/
Fixes: 7b868fe04a ("Revert "mvebu: 5.4 fix DVFS caused random boot crashes"")
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Based on the discussion on the mailing list [1], the patch which was
reverted, it reverts only one patch without the subsequent ones.
This leads to the SoC scaling issue not using a CPU parent clock, but
it uses DDR clock. This is done for all variants, and it's wrong because
commits (hacks) that were using the DDR clock are no longer in the mainline kernel.
If someone has stability issues on 1.2 GHz, it should not affect all
routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to
improve the situation in the kernel and not making the situation worse.
There are two solutions in cases of instability:
a) disable cpufreq
b) underclock it up to 1 GHz
This reverts commit 080a0b74e3.
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html
Fixes: d379476817 ("mvebu: armada-37xx: add patch to forbid cpufreq for 1.2 GHz")
CC: Pali Rohár <pali@kernel.org>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Based on the discussion on the mailing list [1], the patch which was
reverted, it reverts only one patch without the subsequent ones.
This leads to the SoC scaling issue not using a CPU parent clock, but
it uses DDR clock. This is done for all variants, and it's wrong because
commits (hacks) that were using the DDR clock are no longer in the mainline kernel.
If someone has stability issues on 1.2 GHz, it should not affect all
routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to
improve the situation in the kernel and not making the situation worse.
There are two solutions in cases of instability:
a) disable cpufreq
b) underclock it up to 1 GHz
This reverts commit 080a0b74e3.
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html
CC: Pali Rohár <pali@kernel.org>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Follow the recommendations stated in the Turris Omnia DTS for eth2:
"In case SFP module is present, U-Boot has to enable the sfp node above,
remove phy-handle property, and add managed = "in-band-status" property."
The boot script is written in a way, that it works for all U-Boot
versions deployed by the vendor so far (2015.10-rc2, 2019.07).
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Kernel 5.4 receives a reduced set, just to make the SFP cage work.
While we are at it, move the patches accepted upstream to the 0xx series.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
