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-07 14:48:02 +0100 |
| commit | 13c9f1f37df6d34ee5f1ba1d8f7542a1b24736fa (patch) | |
| tree | fd8c3418ad2e8a45cf3d906145e7a113ceb54a62 /include/quilt.mk | |
| parent | e12ffac02d40affd3706943a5789741a5e42d643 (diff) | |
| download | upstream-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 'include/quilt.mk')
0 files changed, 0 insertions, 0 deletions