2020-01-18 02:21:13 +01:00
|
|
|
#
|
|
|
|
|
# Copyright (C) 2014-2016 OpenWrt.org
|
|
|
|
|
# Copyright (C) 2016 LEDE-Project.org
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
RAMFS_COPY_BIN='fw_printenv fw_setenv'
|
|
|
|
|
RAMFS_COPY_DATA='/etc/fw_env.config /var/lock/fw_printenv.lock'
|
|
|
|
|
REQUIRE_IMAGE_METADATA=1
|
|
|
|
|
|
|
|
|
|
platform_check_image() {
|
|
|
|
|
case "$(board_name)" in
|
|
|
|
|
cznic,turris-omnia|\
|
2020-07-12 15:35:54 +02:00
|
|
|
kobol,helios4|\
|
2020-01-18 02:21:13 +01:00
|
|
|
solidrun,clearfog-base-a1|\
|
|
|
|
|
solidrun,clearfog-pro-a1)
|
base-files: rename 'sdcard' to 'legacy-sdcard'
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>
2021-08-07 15:30:53 +02:00
|
|
|
legacy_sdcard_check_image "$1"
|
2020-01-18 02:21:13 +01:00
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
return 0
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
platform_do_upgrade() {
|
|
|
|
|
case "$(board_name)" in
|
mvebu: add support for Buffalo LinkStation LS421DE
Buffalo LinkStation LS421DE is a dual bay NAS, based on Marvell Armada 370
Hardware:
SoC: Marvell Armada 88F6707-A1
CPU: Cortex-A9 1200 MHz, 1 core
Flash: SPI-NOR 1 MiB, NAND 512 MiB
RAM: DDR3 512 MiB
Ethernet: 1x 10/100/1000 Mbps
USB: 1x 2.0, 1x 3.0
SATA: 2x 3.0 Gbps
LEDs/Input : 5x / 2x (1x button, 1x slide-switch)
RTC: Ricoh RS5C372A, I2C, no battery
Flash instruction (UART+TFTP):
1. Downgrade the OEM firmware to 1.34 version (BUFFALO_BOOTVER=0.13)
2. Remove any hard drive from inside the bays.
3. Boot the Openwrt initramfs image using the U-Boot serial console:
tftpboot 0x1200000 buffalo_ls421de-initramfs-kernel.bin
bootm 0x1200000
4. Flash the sysupgrade image using the Openwrt console:
sysupgrade -n buffalo_ls421de-squashfs-sysupgrade.bin
5. Wait until it finish, the device will reboot with Openwrt installed
on the NAND flash.
Note:
- Device shuting down doesn't work, even if the power slide switch is
used. We must first, via MDIO, set the unused LED2 at the ethernet
phy0 to off state. Reboot works ok.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
2020-04-07 14:35:26 +02:00
|
|
|
buffalo,ls421de)
|
|
|
|
|
nand_do_upgrade "$1"
|
|
|
|
|
;;
|
2020-01-18 02:21:13 +01:00
|
|
|
cznic,turris-omnia|\
|
2020-07-12 15:35:54 +02:00
|
|
|
kobol,helios4|\
|
2020-01-18 02:21:13 +01:00
|
|
|
solidrun,clearfog-base-a1|\
|
|
|
|
|
solidrun,clearfog-pro-a1)
|
base-files: rename 'sdcard' to 'legacy-sdcard'
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>
2021-08-07 15:30:53 +02:00
|
|
|
legacy_sdcard_do_upgrade "$1"
|
2020-01-18 02:21:13 +01:00
|
|
|
;;
|
mvebu: rename Linksys devices based on their common names
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>
2020-04-10 12:14:21 +02:00
|
|
|
linksys,wrt1200ac|\
|
|
|
|
|
linksys,wrt1900ac-v1|\
|
|
|
|
|
linksys,wrt1900ac-v2|\
|
|
|
|
|
linksys,wrt1900acs|\
|
|
|
|
|
linksys,wrt3200acm|\
|
|
|
|
|
linksys,wrt32x)
|
2020-01-18 02:21:13 +01:00
|
|
|
platform_do_upgrade_linksys "$1"
|
|
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
default_do_upgrade "$1"
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
}
|
|
|
|
|
platform_copy_config() {
|
|
|
|
|
case "$(board_name)" in
|
|
|
|
|
cznic,turris-omnia|\
|
2020-07-12 15:35:54 +02:00
|
|
|
kobol,helios4|\
|
2020-01-18 02:21:13 +01:00
|
|
|
solidrun,clearfog-base-a1|\
|
|
|
|
|
solidrun,clearfog-pro-a1)
|
base-files: rename 'sdcard' to 'legacy-sdcard'
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>
2021-08-07 15:30:53 +02:00
|
|
|
legacy_sdcard_copy_config
|
2020-01-18 02:21:13 +01:00
|
|
|
;;
|
mvebu: rename Linksys devices based on their common names
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>
2020-04-10 12:14:21 +02:00
|
|
|
linksys,wrt1200ac|\
|
|
|
|
|
linksys,wrt1900ac-v1|\
|
|
|
|
|
linksys,wrt1900ac-v2|\
|
|
|
|
|
linksys,wrt1900acs|\
|
|
|
|
|
linksys,wrt3200acm|\
|
|
|
|
|
linksys,wrt32x)
|
2020-01-18 02:21:13 +01:00
|
|
|
platform_copy_config_linksys
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
}
|
