diff options
| author | Rafał Miłecki <rafal@milecki.pl> | 2022-03-04 16:03:26 +0100 |
|---|---|---|
| committer | Rafał Miłecki <rafal@milecki.pl> | 2022-03-04 16:14:59 +0100 |
| commit | 93259e8ca261c7965618fe11c2d385638da5cfa6 (patch) | |
| tree | 48a19a9fdfba68ae369a1a97a02f53b9ddf6c37f /scripts/config/expr.c | |
| parent | 247eaa44161b0a07e2dd40ffaa181d47ca10a96b (diff) | |
| download | upstream-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 'scripts/config/expr.c')
0 files changed, 0 insertions, 0 deletions