| Message ID | 20220125135535.224061-1-grandpaul@gmail.com |
|---|---|
| Headers | show |
| Series | A/B firmware update based in eMMC boot partition. | expand |
Dear Ying-Chun Liu, In message <20220125135535.224061-1-grandpaul@gmail.com> you wrote: > > I've implemented A/B firmware update based on eMMC hw partitions. > Normally we have 2 boot partitions on eMMC. One is active and another > is inactive. We can then flash the firmware to the inactive one and > make it active. We have been doing software updates using U-Boot scripts etc. for many, many years. But during that time a large number of restrictions and shortcomings became clear. this is why projects like SWUpdate [1] came into life, and U-Boot supports this only with very basic features: - watchdog support to reset a hanging system - boot counter to switch to an alternate boot command in case of too many failed boot attempts That's all. Not more is needed, and not more should be used in U-Boot. I'm not sure if you know SWUpdate - if not, you should definitely look into it. I strongly recommend not to try to reinvent that wheel - poorly - in U-Boot. We have been there before, and got rid of this approach for a pretty long list of good reasons. [1] https://sbabic.github.io/swupdate/ Best regards, Wolfgang Denk
Hello, Am Tue, Jan 25, 2022 at 03:43:29PM +0100 schrieb Wolfgang Denk: > Dear Ying-Chun Liu, > > In message <20220125135535.224061-1-grandpaul@gmail.com> you wrote: > > > > I've implemented A/B firmware update based on eMMC hw partitions. > > Normally we have 2 boot partitions on eMMC. One is active and another > > is inactive. We can then flash the firmware to the inactive one and > > make it active. > > We have been doing software updates using U-Boot scripts etc. for > many, many years. But during that time a large number of > restrictions and shortcomings became clear. this is why projects > like SWUpdate [1] came into life, and U-Boot supports this only with > very basic features: > > - watchdog support to reset a hanging system > - boot counter to switch to an alternate boot command in case of too > many failed boot attempts > > That's all. Not more is needed, and not more should be used in > U-Boot. > > I'm not sure if you know SWUpdate - if not, you should definitely > look into it. I strongly recommend not to try to reinvent that > wheel - poorly - in U-Boot. We have been there before, and got rid > of this approach for a pretty long list of good reasons. > > > [1] https://sbabic.github.io/swupdate/ FWIW, if you don't want to reinvent the wheel and evaluate alternatives, you might also want to checkout RAUC [1]. It has builtin support for that eMMC boot partition scenario. The u-boot integration is not as sophisticated as for other bootloaders, but I got that running with u-boot last year on raw NAND flash and it's a lot better than hacking together your own A/B update scheme scripts. HTH & Greets Alex [1] https://www.rauc.io/
On Tue, Jan 25, 2022 at 03:43:29PM +0100, Wolfgang Denk wrote: > Dear Ying-Chun Liu, > > In message <20220125135535.224061-1-grandpaul@gmail.com> you wrote: > > > > I've implemented A/B firmware update based on eMMC hw partitions. > > Normally we have 2 boot partitions on eMMC. One is active and another > > is inactive. We can then flash the firmware to the inactive one and > > make it active. > > We have been doing software updates using U-Boot scripts etc. for > many, many years. But during that time a large number of > restrictions and shortcomings became clear. [snip] I just want to chime in here and agree with the overall point that Wolfgang is making. There are a number of update schemes that handle firmware (to whatever level can be safely done) and I see U-Boot's role here as to support these mechanisms as easily and cleanly as possible (so, watchdog, bootcount, etc, etc) but to not implement a specific scheme directly.
From: "Ying-Chun Liu (PaulLiu)" <paul.liu@linaro.org> Hi all, I've implemented A/B firmware update based on eMMC hw partitions. Normally we have 2 boot partitions on eMMC. One is active and another is inactive. We can then flash the firmware to the inactive one and make it active. Also when booting we can write protect the current active one. And left the inactive partition still writable. So I make 2 commits that implements the following features: 1. Write protect "active" boot area when board init. 2. flash firmware to inactive boot area. 3. Change the inactive boot area after firmware update. Thanks. Ying-Chun Liu (PaulLiu) (2): drivers: mmc: write protect active boot area after mmc init. drivers: dfu: flash firmware to inactive boot area and active it drivers/dfu/dfu_mmc.c | 32 +++++++++++++++++++++--- drivers/mmc/Kconfig | 10 ++++++++ drivers/mmc/mmc.c | 58 +++++++++++++++++++++++++++++++++++++++++++ include/dfu.h | 1 + 4 files changed, 98 insertions(+), 3 deletions(-)