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 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>
This fixes a bunch of cosmetic issues with GL.iNet GL-MV1000:
- apply alphabetic sorting in multiple files
- use armada-3720 prefix for DTS like for other devices
- fix vendor capitalization for model in DTSes
- remove trivial comment in DTS files
- use DEVICE_VENDOR/DEVICE_MODEL
- remove redundant SUPPORTED_DEVICES
- use SOC instead of DEVICE_DTS
- remove empty line at EOF
Fixes: 050c24f05c ("mvebu: add support for GL.iNet GL-MV1000")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This patch adds sysupgrade, uboot-env and networking support
for Methode uDPU device.
Device features 4 partitions:
-----------------------------------------
| boot | recovery | rootfs | misc |
| (ext4) | (ext4) | (fsf2) | (f2fs) |
_________________________________________
Idea was to use f2fs only but the u-boot currently lacks support
so first 2 partition are ext4 to be u-boot readable, and this was
a reason why custom build and sysupgrade sections were required.
On the sysupgrade, boot and rootfs partitions are updated, firmare
image and user configuration is saved on the misc partition and if
the upgrade was successfull, recovery partition will be updated on
after the reboot from preinit script. If the sysupgrade fails for any
reason, device will fallback to recovery initramfs image.
Signed-off-by: Vladimir Vid <vladimir.vid@sartura.hr>
When targets for multiple ESPRESSObin devices were added, not all
files were updated which means any ESPRESSObin version beside generic
won't have proper networking, sysupgrade and uboot-env. This patch
fixes the issue.
* fixup network detection
* fixup uboot-env
* fixup platform.sh for sysupgrade
Signed-off-by: Vladimir Vid <vladimir.vid@sartura.hr>
Convert whole target to Device Tree based board detection instead of
identifying devices by dts file name. With this we can drop mvebu.sh
translation script and rely on common method for model detection.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Linksys WRT32X (Venom) is identical in hardware to the WRT3200ACM
with a different flash layout and boots zImage rather than uImage.
Specification:
- Marvell Armada 385 88F6820 (2x 1.8GHz)
- 256MB of Flash
- 512MB of RAM
- 2.4GHz (bgn) and 5GHz (an+ac wave 2)
- 4x 1Gbps LAN + 1x 1Gbps WAN
- 1x USB 3.0 and 1x USB 2.0/eSATA (combo port)
Flash instruction:
Apply factory image via web-gui.
Signed-off-by: Michael Gray <michael.gray@lantisproject.com>
Added for convenience. These boards can be used as dev boards running
various operating systems from different media, and this simplifies work
with U-Boot environment.
Signed-off-by: Damir Samardzic <damir.samardzic@sartura.hr>
Adds support for the Turris Omnia and builds an eMMC sysupgrade image in
the same format as the SolidRun ClearFog.
An initramfs image in the simple yet Omnia-specific 'medkit' image format
is also built in order to ease the initial flashing process.
Notable hardware support omissions are support for switching between SFP
cage and copper PHY, and RGB LED control.
Due to a current limitation of DSA, only 1/2 CPU switch uplinks are used.
Specifications:
- Marvell Armada 385 1.6GHz dual-core ARMv7 CPU
- 1GB DDR3 RAM
- 8GB eMMC Flash
- 5x Gigabit LAN via Marvell 88E6176 Switch (2x RGMII CPU ports)
- 1x switchable RJ45 (88E1514 PHY) / SFP SGMII WAN
- 2x USB 3.0
- 12x dimmable RGB LEDs controlled by independent MCU
- 3x Mini PCIe slots
- Optional Compex WLE200N2 Mini PCIe AR9287 2x2 802.11b/g/n (2.4GHz)
- Optional Compex WLE900VX Mini PCIe QCA9880 3x3 802.11ac (2.4 / 5GHz)
- Optional Quectel EC20 Mini PCIe LTE modem
Flash instructions:
If the U-Boot environment has been modified previously (likely manually via
serial console), first use serial to reset the default environment.
=> env default -a
=> saveenv
Method 1 - USB 'medkit' image w/o serial
- Copy openwrt-mvebu-turris-omnia-sysupgrade.img.gz and
omnia-medkit-openwrt-mvebu-turris-omnia-initramfs.tar.gz to the root of a
USB flash drive formatted with FAT32 / ext2/3/4 / btrfs / XFS.
Note that the medkit MUST be named omnia-medkit*.tar.gz
- Disconnect other USB devices from the Omnia and connect the flash drive
to either USB port.
- Power on the Omnia and hold down the rear reset button until 4 LEDs are
illuminated, then release.
- Wait approximately 2 minutes for the Turris Omnia to flash itself with
the temporary image, during which LEDs will change multiple times.
- Connect a computer to a LAN port of the Turris Omnia with a DHCP client
- (if necessary) ssh-keygen -R 192.168.1.1
- ssh root@192.168.1.1
$ mount /dev/sda1 /mnt
$ sysupgrade /mnt/openwrt-mvebu-turris-omnia-sysupgrade.img.gz
- Wait another minute for the final OpenWrt image to be flashed. The Turris
Omnia will reboot itself and you can remove the flash drive.
Method 2 - TFTP w/ serial
- Extract omnia-medkit-openwrt-mvebu-turris-omnia-initramfs.tar.gz and copy
dtb + zImage to your TFTP server (rename if desired)
- Connect Turris Omnia WAN port to DHCP-enabled network with TFTP server
- Connect serial console and interrupt U-Boot
=> dhcp
=> setenv serverip <tftp_server_ip_here>
=> tftpboot 0x01000000 zImage
=> tftpboot 0x02000000 dtb
=> bootz 0x01000000 - 0x02000000
- OpenWrt will now boot from ramdisk
- Download openwrt-mvebu-turris-omnia-sysupgrade.img.gz to /tmp/
$ sysupgrade /tmp/openwrt-mvebu-turris-omnia-sysupgrade.img.gz
- Wait another minute for the final OpenWrt image to be flashed. The Turris
Omnia will reboot itself.
Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
Few minor code formatting style fixes, including:
- keep one board per line
- always use "|\" (for consistency)
- remove redundant double quotes and empty lines
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Tomasz Maciej Nowak
Adrian Schmutzler
Paul Spooren
Li Zhang
Vladimir Vid
Michael Gray
Damir Samardzic
Ryan Mounce
Mathias Kresin
Piotr Dymacz
Imre Kaloz