aboutsummaryrefslogtreecommitdiffstats
path: root/tools
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-04 16:14:59 +0100
commit93259e8ca261c7965618fe11c2d385638da5cfa6 (patch)
tree48a19a9fdfba68ae369a1a97a02f53b9ddf6c37f /tools
parent247eaa44161b0a07e2dd40ffaa181d47ca10a96b (diff)
downloadupstream-93259e8ca261c7965618fe11c2d385638da5cfa6.tar.gz
upstream-93259e8ca261c7965618fe11c2d385638da5cfa6.tar.bz2
upstream-93259e8ca261c7965618fe11c2d385638da5cfa6.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>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions