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
|
2020-07-10 19:35:22 +02:00
|
|
|
marvell,armada8040-mcbin-doubleshot|\
|
|
|
|
|
marvell,armada8040-mcbin-singleshot)
|
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
|
2020-07-10 19:35:22 +02:00
|
|
|
marvell,armada8040-mcbin-doubleshot|\
|
|
|
|
|
marvell,armada8040-mcbin-singleshot)
|
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
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
default_do_upgrade "$1"
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
}
|
|
|
|
|
platform_copy_config() {
|
|
|
|
|
case "$(board_name)" in
|
2020-07-10 19:35:22 +02:00
|
|
|
marvell,armada8040-mcbin-doubleshot|\
|
|
|
|
|
marvell,armada8040-mcbin-singleshot)
|
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
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
}
|
