If device recipe has specified DEVICE_DTS variable, the dtb is built
anyway by OpenWrt buildroot image rules. Drop the patch and adjust the
location of compiled dtb.
Cc: Scott Roberts <ttocsr@gmail.com>
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Tar has ability to change current dir, so use that instead additional
command invocation. Also being here, change tar arguments to make final
archive reproducible.
Cc: Scott Roberts <ttocsr@gmail.com>
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
This device receipe selects bunch of packages which some are re-defined,
unnecessary or irrelevant. Clean them up, so only basic functionality
persist.
Cc: Scott Roberts <ttocsr@gmail.com>
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Don't rewrite global DTS_DIR, instead, use proper variable for
specifying devices dts directory. For consistency, also specify the
variable in default profile, as suggested by Adrian Schmutzler.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Align subtargets makefiles names to actual subtargets.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Acked-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This sorts the devices in image Makefiles alphabetically.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
[fixed sorting in one case, add commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This introduces the SOC variable to mvebu target to derive some of
the DEVICE_DTS variables based on the SOC prefix and the device
definition name.
Since DTS names and compatible are inconsistent also in the kernel
for this target, the scheme cannot be applied to all devices, though.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
This moves the if conditions for choosing which image Makefiles
are used to the parent image/Makefile. It seems more convenient
to have "codeflow" in the parent while the subtarget-specific
files only contain the definitions.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
There is nothing that needs bash anymore.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
[add prefix to commit title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Enables proper checking. Matches printf behavior in C.
Found with shellcheck.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
[add prefix to commit title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
let is a bashism.
Found with shellcheck.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
[add prefix to commit title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
These targets are currently using more or less same SIGNATURE variable
which provides unique partition ID/signature, so it makes sense to
refactor it out into common IMG_PART_SIGNATURE variable which could be
reused by all targets.
This is another step in the direction of reproducible OpenWrt images.
Signed-off-by: Paul Spooren <mail@aparcar.org>
[split into separate commit, renamed to IMG_PART_SIGNATURE]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
UUID of ext4 volumes generated by make_ext4fs are determined by volume
label and it will all be 57f8f4bc-abf4-655f-bf67-946fc0f9f25b when label
is empty
Labeling them does not make them unique but tools like block command
from fstools have a better chance differentiating them
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
This replaces deprecated backticks by more versatile $(...) syntax.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
[decapitalized patch subject at submitter's request]
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
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>
This adds initial support for micro-DPU (uDPU) board which is based on
Armada-3720 SoC. micro-DPU is the single-port FTTdp distribution point
unit made by Methode Electronics which offers complete modularity with
replaceable SFP modules both for uplink and downlink (G.hn over
twisted-pair, G.hn over coax, 1G and 2.5G Ethernet over Cat-5e cable).
On-board features:
- 512 MiB DDR3
- 2 x 2.5G SFP via HSGMII SERDES interface to the A3720 SoC
- USB 2.0 Type-C connector
- 4GB eMMC
- ETSI TS 101548 reverse powering via twisted pair (RJ45) or coax (F Type)
uDPU is intented to run on kernel 4.19 on newer due to the SFP and hardware support.
Signed-off-by: Vladimir Vid <vladimir.vid@sartura.hr>
Not all versions of ESPRESSObin require SD card, but can
be booted from the internal emmc flash (mmc dev 1) instead.
Add a simple check in the bootscript to see which mmc device
is detected and boot from it using mmcdev variable.
Tested-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Signed-off-by: Vladimir Vid <vladimir.vid@sartura.hr>
The driver is for the I2C mux.
Schematic available at https://doc.turris.cz/doc/_media/rtrom01-schema.pdf
Signed-off-by: Josef Schlehofer <josef.schlehofer@nic.cz>
Tested-by: Rosen Penev <rosenp@gmail.com>
This commit adds support for different iterations of ESPRESSObin.
The added variants are:
ESPRESSObin with soldered eMMC,
ESPRESSObin V7, compared to V5 some passive elements changed and ethernet
ports labels positions have been reversed,
ESPRESSObin V7 with soldered eMMC.
Please refer to:
584d7c5 ("mvebu: new subtarget cortex A53")
for instruction how to boot OpenWrt image placed on SD card. It is
advised for owners of V5 and previous with bootloader based on U-Boot
2015.01, to upgrade the latest version available at:
http://espressobin.net/tech-spec.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
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>
Add vendors in device names and also rename few device names, for easier
identyfying potential firmware to flash. The vendor and device string is
mainly derived from model/compatipble string in dts from particular
device, but since not all devices are well described, some of the renames
follow marketing names.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Use make syntax to pass the U-Boot image location and boot with root
partitions size, instead of relying on shell functions and variables.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Drop overly complex amount of defines wich are referenced in the same
devices pool and move image recipes to common define, since devices not
using them overwrite it.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
All of U-Boot scripts repeat the same pattern with only Device Tree blob
name changing for respective device. Therefore create generic scripts
which will be altered on demad by image build process, and create
BOOT_SCRIPT variable which can be added to device recipe and will allow
referencing the same script by many device recipes. This will allow to
slim down the ammount of files in buildroot tree and avoid needlessly
incrementing amount of boot scripts if new devices will be added.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
All of arm64 devices have part of variables repeatedly defined. Stack
them to common define, and reference it in each device recipe.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Even if dts is not included in upstream Makefile, it is built anyway by
recipe specified in include/image.mk. Also remove Build/dtb, it's not
used since 3f72f3a ("mvebu: clearfog: include DTB for all variants in
image").
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Currently sysupgrade overwrites whole disk and destroys partitions added
by user. Sync the sysupgrade code with the one present in x86 target to
remedy this behaviour.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Since most of devices using SD card image to boot, use ext4 as boot
files system we can drop fat fs related packages. Also move packages
which are added repeatedly across subtargets to their default packages,
with droping the ones that are enabled in target kernel configugation.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
This will allow to drop additional packages and shrink image size.
Cc: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Add out of the box support for 802.11r and 802.11w to all targets not
suffering from small flash.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Mathias did all the heavy lifting on this, but I'm the one who should
get shouted at for committing.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
We select ath10k-ct by default, but it is still possible to build
the upstream version.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John Crispin <john@phrozen.org>
Add initial support for cortex-a72 based Armada DB-88F8040-Modular and
DB-88F7040-Modular development boards.
DB-88F8040-Modular specifications:
- Quad-core ARMv8 Cortex A72 CPU (up to 2 GHz)
- DDR4 DIMM - 64 bits + ECC
- 2 x 128 Mb SPI NOR flash memory
- 2 x 1G Ethernet port via RGMII (RJ45)
- 2 x SD card ports (4 bit port on CP, 8 bit port on AP)
- 2 SERDES modules with the following interfaces each:
- 2 x SATA Rev 3.0 port (Port1 via SERDES module CON4 (active port), Port0
via SERDES Module CON2 or CON1 (optional port))
- 3 x PCI Express (PCIe) Gen 3.0 (Port2 via SERDES module CON5 (active port),
Port1 via SERDES module CON7 (optional port), Port0 via SERDES module CON6
(optional port))
- 2 x USB3 (USB 2.0 backward compatible) host (via SERDES module CON9 and
CON10)
- 1 x 10G port over SFP+ connector (via SERDES module CON8)
- 1 x MCI interface by two over USB Type C connector
- 4 x serial COM port driven by the 88F8040 UART interface and converted to
USB via FTDI IC
- I2C Master Interface
- CP I2C 2x EEPROM @ Address 0x50 and 0x57
- 1 x I/O Expander @ Address 0x21
- Sample at Reset (SatR) memory device @ Address 0x4C and 0x4E
- I2C Slave Interface (via SERDES module) - Connection to each device on the
board via an I2C multiplexer
- JTAG interface for CPU emulator
- Board dimensions: 270 mm x 240 mm (main + SERDES module)
- SERDES Module Dimensions: 70 mm x 105 mm
DB-88F7040-Modular specifications:
- Quad-core ARMv8 Cortex A72 CPU
- CPU core operating speed of up to 1.6 GHz for Dual Core, 1.4 GHz for Quad
Core
- DDR4 - 32 bit + ECC on Module - SLM1366-V1 (DB-DDR4-40B-MODULE) 4 GByte
32-bit
- 1 x 128Mb SPI NOR flash memory
- 2 x 1G Ethernet port: 1 over RGMII (RJ45) and 1 over SGMII
- SD card 4 bits port on AP
- eMMc Module on CP
- 1 SERDES Modules with the following interfaces each:
- 1 x SATA Rev 3.0 port (via SERDES module CON4)
- 1 x PCI Express (PCIe) Gen 3.0 (via SERDES module CON5)
- 2 x USB 3.0 (USB 2.0 backward compatible) host (via SERDES module CON9 and
CON10)
- 1 x 10G port over SFP+ connector (via SERDES module CON8)
- 2 x MCi interface by one over USB Type C connector
- 4 x Serial COM port driven by the 88F7040 UA
- RT interface and converted to USB via FTDI IC
- I2C Master Interface
- 2 x EEPROM at address 0x57 and 0x50 in AP and 2 x EEPROM at address 0x57
and 0x50 in CP
- 1 x I/O Expander at address 0x21
- Sample at Reset (SatR) memory device at address 0x4C and 0x4E
- I2C Slave Interface (via SERDES module) - Connection to each device on the
board via an I2C multiplexer
- JTAG interface for CPU emulator
- Board dimensions - 270 mm x 240 mm (main + SERDES module)
- SERDES Module Dimensions - 70 mm x 105 mm
Booting from USB flash drive (dd sdcard image to the flash drive):
1. reset U-Boot environment:
env default -a
saveenv
2. prepare U-Boot manually (make sure to set correct dtb file name):
setenv bootargs_root 'root=/dev/sda2 rw rootdelay=2 ip=dhcp'
setenv fdtfile armada-7040-db.dtb
setenv image_name Image
setenv bootcmd 'usb start; ext4load usb 0:1 $kernel_addr $image_name; ext4load usb 0:1 $fdt_addr $fdtfile; setenv bootargs $console $mtdparts $bootargs_root; booti $kernel_addr - $fdt_addr'
saveenv
boot
Signed-off-by: Damir Samardzic <damir.samardzic@sartura.hr>
Add initial support for Marvell Armada cortex-a53 based
DB-88F3720-DDR3-Modular development board.
Specifications:
- Dual core ARMv8 Cortex-A53 CPU (up to 1.0 GHz)
- 4Gb 16-bit DDR3/3L DRAM memory
- 128Mb SPI NOR flash memory
- 8Gb eMMC NAND flash memory
- 1 x SATA Rev 3.0 port
- 1 x PCI Express (PCIe) Gen 2.0 or 1 x mini PCI Express (PCIe) Gen 2.0
- 1 x 1G Ethernet port via RGMII (RJ45)
- 1 x SD card port
- 1 x USB3 (USB2 backward) host\device port via type C connector
- 1 x USB2 host port via type A connector
- 1 x serial COM port driven by the 88F3720 UART interface and converted to
USB via FTDI IC (option to connect the UART DB9 adapter)
- I2C Master Interface:
- 1 x EEPROM @ address 0x57
- 1 x I/O Expanders @ address 0x22
- Sample at Reset (SatR) memory device @ address 0x4C
- RTC clock generator PT7C4337AWE @ address 0x68
- USB3 switch PI5USB30213XEA @ address 0x0D
- ID component of PHY module @ address 0x24
- 1 x JTAG interface for CPU emulator
- 1 x SETM and JTAG debug interface
- 1 x power connector for HDD supply
- 1 x 12V DC jack power connector
- Board dimensions: 150 mm x 179 mm
- LED interface for system status
Booting from SD card:
1. reset U-Boot environment:
env default -a
saveenv
2. prepare U-Boot with boot script:
setenv bootcmd "load mmc 0:1 0x4d00000 boot.scr; source 0x4d00000"
saveenv
or manually:
setenv fdt_name armada-3720-db.dtb
setenv image_name Image
setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk1p2 rw rootwait; booti $kernel_addr - $fdt_addr'
saveenv
Signed-off-by: Damir Samardzic <damir.samardzic@sartura.hr>
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>
Add initial support for Marvell MACCHIATObin, cortex-a72 based Marvell
ARMADA 8040 Community board. Comes in two forms: Single Shot and Double
Shot.
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) via copper or 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
Booting from micro SD card:
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:
setenv fdt_name armada-8040-mcbin.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
Signed-off-by: Damir Samardzic <damir.samardzic@sartura.hr>
The DTB for Clearfog Pro has been renamed in mainline. However U-Boot
hasn't picked up that change yet :(, so we need to hardcode it for now.
Signed-off-by: Josua Mayer <josua.mayer97@gmail.com>
Initialise the UBOOT variable by default. Otherwise it will be
unintended inherit to following images if set and causes an uboot build
where not required.
Signed-off-by: Mathias Kresin <dev@kresin.me>
This commit introduces new subtarget for Marvell EBU Armada Cortex A53
processor based devices.
The first device is Globalscale ESPRESSObin. Some hardware specs:
SoC: Marvell Armada 3700LP (88F3720) dual core ARM Cortex A53
processor up to 1.2GHz
RAM: 512MB, 1GB or 2GB DDR3
Storage: SATA interface
µSD card slot with footprint for an optional 4GB EMMC
4MB SPI NOR flash for bootloader
Ethernet: Topaz Networking Switch (88E6341) with 3x GbE ports
Connectors: USB 3.0
USB 2.0
µUSB port connected to PL2303SA (USB to serial bridge
controller) for UART access
Expansion: 2x 46-pin GPIO headers for accessories and shields with
I2C, GPIOs, PWM, UART, SPI, MMC, etc
MiniPCIe slot
Misc: Reset button, JTAG interface
Currently booting only from µSD card is supported.
The boards depending on date of dispatch can come with various U-Boot
versions. For the newest version 2017.03-armada-17.10 no manual
intervention should be needed to boot OpenWrt image. For the older ones
it's necessary to modify default U-Boot environment:
1. Interrupt boot process to run U-Boot command line,
2. Run following commands:
(for version 2017.03-armada-17.06 and 2017.03-armada-17.08)
setenv bootcmd "load mmc 0:1 0x4d00000 boot.scr; source 0x4d00000"
saveenv
(for version 2015.01-armada-17.02 and 2015.01-armada-17.04)
setenv bootargs "console=ttyMV0,115200 root=/dev/mmcblk0p2 rw rootwait"
setenv bootcmd "ext4load mmc 0:1 ${fdt_addr} armada-3720-espressobin.dtb; ext4load mmc 0:1 ${kernel_addr} Image; booti ${kernel_addr} - ${fdt_addr}"
saveenv
3. Poweroff, insert SD card with OpenWrt image, boot and enjoy.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
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>
Unify boot.scr generation so Makefile for device image generation won't
grow without a reason. Also make boot-scr step optional.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Previously the partition signature was assigned from provided type. Now
both are corrected wherein signature is always generated from
SOURCE_DATE_EPOCH. With that the root file system can be identified
by PARTUUID string, without relying on static declaration of device node.
This commit also does some cosmetics, removing trailing whitespace and
replacing spaces with tab.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
The IMAGE_NAME redefinition causes overwriting of generated SD card
image when multiple root file system types are selected. In result only
single SD card image is generated. This commit fixes this behaviour.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
U-Boot already knows where it found the boot.scr, and
figuring out the partition UUID becomes trivial at this point.
This change allows booting OpenWrt from whatever storage it has been
flashed to: SD card, eMMC, USB disk or SATA disk.
Signed-off-by: Josua Mayer <josua.mayer97@gmail.com>
[replace lede with openwrt, redact commit message]
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
As each mvebu device only uses one of the firmwares provided by mwlwifi
package, it makes sense to put them in separate packages and only install
the one that is needed.
Current mwlwifi version's firmware sizes and usages by devices:
88W8864.bin 118776 caiman, mamba, cobra, shelby
88W8897.bin 489932 (none)
88W8964.bin 449420 rango
Changes by this commit:
* indicate in title that mwlwifi also is driver for 88W8897 and 88W8964
* remove mwlwifi package's firmware installation rules
* add 3 new individual firmware packages (all depends on kmod-mwlwifi):
- mwlwifi-firmware-88w8864
- mwlwifi-firmware-88w8897
- mwlwifi-firmware-88w8964
* add firmware package to mvebu devices' DEVICE_PACKAGES accordingly
Signed-off-by: Johnny S. Lee <_@jsl.io>
[Add the used FW files to the PACKAGES of default image]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When clearfog was renamed to clearfog pro, it broke sysupgrade from
17.04 as the new images now get rejected as incompatible. Fix this by
adding the legacy boardname to the compatible devices.
Fixes: ec4a8c6dee ("mvebu: ClearFog renamed upstream to ClearFog Pro")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Tomasz Maciej Nowak
Adrian Schmutzler
Rosen Penev
Paul Spooren
Yousong Zhou
Moritz Warning
Vladimir Vid
Josef Schlehofer
Hauke Mehrtens
Mathias Kresin
John Crispin
Damir Samardzic
Michael Gray
Josua Mayer
Hauke Mehrtens
Ryan Mounce
Johnny S. Lee
Jonas Gorski