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>
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>
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>
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>
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>
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>
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>
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>
venom has a 3MB kernel partition as specified by the DTS.
3MB is not sufficient for building with many kernel modules or newer
kernel versions.
venom uboot however as set from factory will load up to 6MB.
This can be observed by looking a uboot log:
NAND read: device 0 offset 0x900000, size 0x600000
6291456 bytes read: OK
and from uboot environment variables:
$ fw_printenv | grep "priKernSize";
priKernSize=0x0600000
Resize the root partitions from 120MB to 117MB to let kernel expand
into it another 3MB.
And set kernel target size to 6MB.
Lastly set the kernel-size-migration compatibility version on venom to
prevent sysupgrading without first reinstalling from a factory image.
Signed-off-by: Tad Davanzo <tad@spotco.us>
mamba has a 3MB kernel partition as specified by the DTS.
3MB is not sufficient for building with many kernel modules or newer
kernel versions.
mamba uboot however as set from factory will load up to 4MB.
This can be observed by looking a uboot log:
NAND read: device 0 offset 0xa00000, size 0x400000
4194304 bytes read: OK
and from uboot environment variables:
$ fw_printenv | grep "pri_kern_size";
pri_kern_size=0x400000
Resize the root partitions from 37MB to 36MB to let kernel expand
into it another 1MB.
And set kernel target size to 4MB.
Lastly add a compatibility version message: kernel-size-migration.
And set it on mamba to prevent sysupgrading without first reinstalling from
a factory image.
Signed-off-by: Tad Davanzo <tad@spotco.us>
We so far had two variables IMG_PREFIX and IMAGE_PREFIX with
different content. Since these names are obviously quite
confusing, this patch renames the latter to DEVICE_IMG_PREFIX,
as it's a device-dependent variable, while IMG_PREFIX is only
(sub)target-dependent.
For consistency, also rename IMAGE_NAME to DEVICE_IMG_NAME, as
that's a device-dependent variable as well.
Cc: Paul Spooren <mail@aparcar.org>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Currently it's not possible to boot the device with just initramfs image
without additional effort as the initramfs image doesn't contain device
tree. Fix it by producing FIT based image which could be booted with
following commands:
setenv bootargs earlyprintk console=ttyS0,115200
tftpboot ${kernel_addr_r} openwrt-mvebu-cortexa9-cznic_turris-omnia-initramfs-kernel.bin
bootm ${kernel_addr_r}
Acked-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The majority of our targets provide a default value for the variable
SUPPORTED_DEVICES, which is used in images to check against the
compatible on a running device:
SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
At the moment, this is implemented in the Device/Default block of
the individual targets or even subtargets. However, since we
standardized device names and compatible in the recent past, almost
all targets are following the same scheme now:
device/image name: vendor_model
compatible: vendor,model
The equal redundant definitions are a symptom of this process.
Consequently, this patch moves the definition to image.mk making it
a global default. For the few targets not using the scheme above,
SUPPORTED_DEVICES will be defined to a different value in
Device/Default anyway, overwriting the default. In other words:
This change is supposed to be cosmetic.
This can be used as a global measure to get the current compatible
with: $(firstword $(SUPPORTED_DEVICES))
(Though this is not precisely an achievement of this commit.)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The following four led triggers are enabled in generic config.
* kmod-ledtrig-default-on
* kmod-ledtrig-heartbeat
* kmod-ledtrig-netdev
* kmod-ledtrig-timer
Drop the packages and remove them from DEVICE_PACKAGES.
There's no other package depending on them in this repo.
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
This adds DTB to kernel and that way makes it possible to easily boot
initramfs image and also kernel.
The sequence to boot initramfs on Omnia is then just:
env set bootargs earlyprintk console=ttyS0,115200
dhcp 0x1000000 192.168.1.1:openwrt-mvebu-cortexa9-cznic_turris-omnia-initramfs-kernel.bin
bootz 0x1000000
Without this change kernel boot won't proceed and is stuck on "Starting
kernel".
Signed-off-by: Karel Kočí <karel.koci@nic.cz>
[fixed From: to match with SoB:]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
In contrast to the U-Boot version shipped with older versions of Turris
Omnia (CZ11NIC13, CZ11NIC20), the version shipped with Turris Omnia 2019
(CZ11NIC23) relies on the existence of /boot.scr.
Consequently, add a suitable boot script to the sysupgrade image.
Flash instructions for Turris Omnia 2019:
- Download openwrt-...-sysupgrade.img.gz, gunzip it, and copy the resulting
.img file to the root of a USB flash drive (FAT32 or ext2/3/4).
- Enter a rescue shell: Either via 5-LED reset and ssh root@192.168.1.1
on LAN port 4, or via 7-LED reset and the serial console.
- Insert the USB drive and mount it:
mkdir /mnt; mount /dev/sda1 /mnt
- Flash the OpenWrt image to eMMC:
dd if=/mnt/openwrt-...-sysupgrade.img of=/dev/mmcblk0 bs=4096 conv=fsync
- Reboot.
Flash instructions using a temporary "medkit" installation were written for
the older versions of Turris Omnia, and will *not* work on the Turris Omnia
2019.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020")
This patch adds support for Globalscale ESPRESSObin-Ultra. Device uses
the same Armada-3720 SoC with extended hardware support.
- SoC: Armada-3720
- RAM: 1 GB DDR4
- Flash: 4MB SPI NOR (mx25u3235f) + 8 GB eMMC
- Ethernet: Topaz 6341 88e6341 (4x GB LAN + 1x WAN with 30W PoE)
- WiFI: 2x2 802.11ac Wi-Fi marvell (88w8997 PCIe+USB)
- 1x USB 2.0 port
- 1x USB 3.0 port
- 1x microSD slot
- 1x mini-PCIe slot (USB [with nano-sim slot])
- 1x mini-USB debug UART
- 1x RTC Clock and battery
- 1x reset button
- 1x power button
- 4x LED (RGBY)
- Optional 1x M.2 2280 slot
** Installation **
Copy dtb from build_dir to bin/ and run tftpserver there:
$ cp ./build_dir/target-aarch64_cortex-a53_musl/linux-mvebu_cortexa53/
linux-5.4.65/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dtb
bin/targets/mvebu/cortexa53/
$ in.tftpd -L -s bin/targets/mvebu/cortexa53/
Connect to the device UART via microUSB port on the back side 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
Ping server to confirm network is working:
$ ping $serverip
Using neta@30000 device
host 192.168.1.15 is alive
Tftpboot the firmware:
$ tftpboot $kernel_addr_r openwrt-mvebu-cortexa53-globalscale_espressobin-ultra-initramfs-kernel.bin
$ tftpboot $fdt_addr_r armada-3720-espressobin-ultra.dtb
Set the console and boot the image:
$ setenv bootargs $console
$ booti $kernel_addr_r - $fdt_addr_r
Once the initramfs is booted, transfer openwrt-mvebu-cortexa53-globalscale_espressobin-ultra-squashfs-sdcard.img.gz
to /tmp dir on the device.
Gunzip and dd the image:
$ gunzip /tmp/openwrt-mvebu-cortexa53-globalscale_espressobin-ultra-squashfs-sdcard.img.gz
$ dd if=/tmp/openwrt-mvebu-cortexa53-globalscale_espressobin-ultra-squashfs-sdcard.img of=/dev/mmcblk0 && sync
Reboot the device.
Signed-off-by: Vladimir Vid <vladimir.vid@sartura.hr>
The generic bootscript is tailored around a downstream firmware and
doesn't work on a firmware built from mainline components.
Add a bootscript which:
* sets $console since mainline u-boot doesn't do that
* uses distro boot variables, so OpenWRT can be booted off any supported
device when using a mainline firmware
* sets missing distro boot variables for the downstream firmware
Booting with a downstream firmware is unchanged.
Booting with a mainline firmware now works.
Signed-off-by: Andre Heider <a.heider@gmail.com>
fdt_addr and kernel_addr variables are getting obsolete in the mainline
u-boot in favor of fdt_addr_r and kernel_addr_r.
By checking if the new variables exist, we can make sure that devices with newer
version of u-boot will work while not breaking support for the existing ones.
Signed-off-by: Vladimir Vid <vladimir.vid@sartura.hr>
Acked-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
This reverts commit e81e625ca3.
This was meant just for early DSA-adopters. Those should have
updated by now, remove it so future updaters get the intended
experience.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Compile the Linkstation poweroff module for the Buffalo LS421DE.
Without this driver the device remains forever halted if a power off
command is executed.
The driver will also allow to use the WoL feature, which wasn't availabe
in the stock firmware.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
In order to support SAE/WPA3-Personal in default images. Replace almost
all occurencies of wpad-basic and wpad-mini with wpad-basic-wolfssl for
consistency. Keep out ar71xx from the list as it won't be in the next
release and would only make backports harder.
Build-tested (build-bot settings):
ath79: generic, ramips: mt7620/mt76x8/rt305x, lantiq: xrx200/xway,
sunxi: a53
Signed-off-by: Petr Štetiar <ynezz@true.cz>
[rebase, extend commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Add a specific comment for early DSA-adopters that they can keep
their config when prompted due to compat-version increase.
This is a temporary solution, the patch should be simply reverted
before any release.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
When changing the Pro variant to DSA, the ethernet interface rename
script was dropped by all devices to keep them in sync:
be309bfd74 ("mvebu: drop 06_set_iface_mac preinit script")
Therefore, network config will be broken after upgrade for the
Base variant as well. Increase the compat version and provide a
message to signal that to the users.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This implements the newly introduced compat-version to prevent
upgrade between swconfig and DSA for mvebu.
Just define a compat version with minor increment and an appropriate
message for both image (in Makefile) and device (in base-files).
Having taken care of sysupgrade, we can put back the SUPPORTED_DEVICES
that have been removed in previous patches to prevent broken config.
Attention:
All users that already updated to the DSA versions in master will
receive the same incompatibility warning since their devices are still
"1.0" as far as fwtool can tell.
Those, and only those, can bypass the upgrade check by using force (-F)
without having to reset config again. In addition, the new version
string needs to be put into uci config manually, so the new fwtool
knows that it actually deals with a "1.1":
uci set "system.@system[-1].compat_version=1.1"
uci commit system
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Use "DEFAULT := n" to only disable devices for buildbots, but
keep them available for manual build.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The kernel appears to have grown too large, breaking the build for the
entire target.
Disable the affected images for now until the situation is dealt with.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
The Helios 4 is a NAS from Kobol
that is powered by an Armada 38x
MicroSOM from Solidrun, similarly
to Clearfog.
This device has:
-Armada 38x CPU
(dual core ARMv7 1.6 Ghz)
-2 GB of ECC RAM
-Gigabit ethernet (Marvell)
-2x USB 3.0 ports
-4x Sata 3.0 ports
-i2c header (J9 |>GND|SDA|SCL|VCC)
-2x 3-pin fan headers with PWM
-micro-usb port is a TTL/UART to
USB converter connected to TTL
-MicroSD card slot
-System, 4xSata and 1xUSB LEDs
NOT WORKING: fan control
Fan Control requires a kernel patch
that is available in the Armbian
project (the "default firmware"
of this device) and named
mvebu-gpio-remove-hardcoded
-timer-assignment
This patch isn't acceptable
by OpenWrt, it should be upstreamed.
I also have that patch in my own
local OpenWrt builds,
in case you want a more
clean and less confusing patch
for upstreaming.
To install, write the disk image
on a micro SD card with dd or
win32 disk imager, insert the
card in the slot.
Check that the dip switch battery
for boot selection is as follows
Switch 1 and 2 down/off, switches
3, 4, 5 up/on.
Signed-off-by: Alberto Bursi <bobafetthotmail@gmail.com>
Add support for Marvell MACCHIATObin Single Shot, cortex-a72 based
Marvell ARMADA 8040 Community board. Single Shot was broken as the
device tree is different on the Double Shot Board.
Specifications:
- Quad core Cortex-A72 (up to 2GHz)
- DDR4 DIMM slot with optional ECC and single/dual chip select support
- Dual 10GbE (1/2.5/10GbE) SFP+
2.5GbE (1/2.5GbE) via SFP
1GbE via copper
- SPI Flash
- 3 X SATA 3.0 connectors
- MicroSD connector
- eMMC
- PCI x4 3.0 slot
- USB 2.0 Headers (Internal)
- USB 3.0 connector
- Console port (UART) over microUSB connector
- 20-pin Connector for CPU JTAG debugger
- 2 X UART Headers
- 12V input via DC Jack
- ATX type power connector
- Form Factor: Mini-ITX (170 mm x 170 mm)
More details at http://macchiatobin.net
Installation:
Write the Image to your Micro SD Card and insert it in the
MACCHIATObin Single Shot SD Card Slot.
In the U-Boot Environment:
1. reset U-Boot environment:
env default -a
saveenv
2. prepare U-Boot with boot script:
setenv bootcmd "load mmc 1:1 0x4d00000 boot.scr; source 0x4d00000"
saveenv
or manually (hanging lines indicate wrapped one-line command):
setenv fdt_name armada-8040-mcbin-singleshot.dtb
setenv image_name Image
setenv bootcmd 'mmc dev 1; ext4load mmc 1:1 $kernel_addr
$image_name;ext4load mmc 1:1 $fdt_addr $fdt_name;setenv
bootargs $console root=/dev/mmcblk1p2 rw rootwait; booti
$kernel_addr - $fdt_addr'
saveenv
On newer Bootloaders (18.12) the Variables have been changed, use:
setenv fdt_name armada-8040-mcbin-singleshot.dtb
setenv image_name Image
setenv bootcmd 'mmc dev 1; ext4load mmc 1:1 $kernel_addr_r
$image_name;ext4load mmc 1:1 $fdt_addr_r $fdt_name;setenv
bootargs $console root=/dev/mmcblk1p2 rw rootwait; booti
$kernel_addr_r - $fdt_addr_r'
Reported-by: Alexandra Alth <alexandra@alth.de>
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Tested-by: Alexandra Alth <alexandra@alth.de>
[add specs and installation as provided by Alexandra Alth]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Between kernels 4.20 and 5.0, a new variant of this board has been
introduced ("Single Shot"), and the existing one has been renamed
with the appendix "Double Shot". [1]
This also adjusted the first compatible in the list:
marvell,armada8040-mcbin -> marvell,armada8040-mcbin-doubleshot
This patch updates the OpenWrt implementation of this device by
adjusting the relevant references to that compatible (i.e., our
board name).
To still provide support for 4.19 with our setup, this adds a
small patch to change the compatible there as well.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b1f0bbe2700051886b954192b6c1751233fe0f52
Cc: Tomasz Maciej Nowak <tomek_n@o2.pl>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
The Buffalo Linkstation LS421DE has a chassis fan for cooling two internal
hard drives. Currently there is no control over this fan, running always
at fixed medium speed.
With the recent jump to the kernel 5.4, now we can monitor the hard drive
temperature and control the fan with thermal zones.
Install the kmod-hwmon-drivetemp module and wire up a thermal zone on the
dts file to allow automatic fan control by the kernel.
Tested succesfully using a single Crucial BX500 SSD drive.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
The Device/Default definition in mvebu defines an IMAGE/factory.img
which is not included in IMAGES, and only used twice in the
individual definitions. Move it out of the default definition
to keep it closer to the reassignment of IMAGES and make it more
consistent with respect to other values of IMAGE/factory.img
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Many target use a repetitive if-include scheme for their subtarget
image files, though their names are consistent with the subtarget
names.
This patch removes these redundant conditions and just uses the
variable for the include where the target setup allows it.
For sunxi, this includes a trivial rename of the subtarget image
Makefiles.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
A direct upgrade from previous swconfig version with
incompatible settings to DSA will break the internet.
Remove SUPPORTED_DEVICES so users cannot upgrade directly.
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
[rebase after Linksys rename, adjust title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The Linksys devices in mvebu target feature a mixed naming,
where parts are based on the official product name (device
node, image; e.g. WRT3200ACM) and parts are based on the
internal code name (DTS file name, compatible, LED labels;
e.g. rango). This inconsistent naming has been perceived
as quite confusing.
A recent attempt by Paul Spooren to harmonize this naming
in kernel has been declined there. However, for us it still
makes sense to apply at least a part of these changes
locally.
Primarily, this patch changes the compatible in DTS and thus
the board name used in various scripts to have them in line
with the device, model and image names. Due to the recent
switch from swconfig to DSA, this allows us to drop
SUPPORTED_DEVICES and thus prevent seamless upgrade between
these incompatible setups.
However, this does not include the LED label rename from
Paul's initial patch: I don't think it's worth keeping the
enormous diff locally for this case, as we can implement
this much easier in 01_leds if we have to live with the
inconsistency anyway.
Signed-off-by: Paul Spooren <mail@aparcar.org>
[rebase, extend to all devices, drop DT LED changes]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
