aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/x86/legacy/config-5.4
diff options
context:
space:
mode:
authorRafał Miłecki <rafal@milecki.pl>2022-03-04 16:03:26 +0100
committerRafał Miłecki <rafal@milecki.pl>2022-03-07 14:48:02 +0100
commit13c9f1f37df6d34ee5f1ba1d8f7542a1b24736fa (patch)
treefd8c3418ad2e8a45cf3d906145e7a113ceb54a62 /target/linux/x86/legacy/config-5.4
parente12ffac02d40affd3706943a5789741a5e42d643 (diff)
downloadupstream-13c9f1f37df6d34ee5f1ba1d8f7542a1b24736fa.tar.gz
upstream-13c9f1f37df6d34ee5f1ba1d8f7542a1b24736fa.tar.bz2
upstream-13c9f1f37df6d34ee5f1ba1d8f7542a1b24736fa.zip
bcm4908: support "rootfs_data" on U-Boot devices
1. Create "rootfs_data" dynamicaly U-Boot firmware images can contain only 2 UBI volumes: bootfs (container with U-Boot + kernel + DTBs) and rootfs (e.g. squashfs). There is no way to include "rootfs_data" UBI volume or make firmware file tell U-Boot to create one. For that reason "rootfs_data" needs to be created dynamically. Use preinit script to handle that. Fire it right before "mount_root" one. 2. Relate "rootfs_data" to flashed firmware As already explained flashing new firmware with U-Boot will do nothing to the "rootfs_data". It could result in new firmware reusing old "rootfs_data" overlay UBI volume and its file. Users expect a clean state after flashing firmware (even if flashing the same one). Solve that by reading flash counter of running firmware and storing it in "rootfs_data" UBI volume. Every mismatch will result in wiping old data. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 93259e8ca261c7965618fe11c2d385638da5cfa6)
Diffstat (limited to 'target/linux/x86/legacy/config-5.4')
0 files changed, 0 insertions, 0 deletions