recent changes to uboot handling in snappy

[Oliver Grawert]

hi,

While researching a filesystem corruption bug of the boot partition on
uboot based systems we found several flaws in our existing
implementation of the config handling.

Our existing setup consisted of the compiled in default environment in
the uboot binary which was then merged with two txt files that were
being read from the vfat partition during boot.

The bootloader needs to know if the last boot was successful and also
needs to be able to initalize a test run of a new kernel. To achieve the
test run the loading of the default rootfs and kernel is pointed from
partition a to partition b temporary by writing the matching variable to
a file using the fatwrite function uboot ships.

This fatwrite function, while existing for a while in uboot already, is
very rarely used in production and has as a matter of fact plenty of
unfixed (or not yet found) bugs. We used to randomly end up with a
corrupted fs and/or corrupted files in the boot partition.

This is indeed not acceptable so we took a deeper look into re-designing
the whole config handling in the bootloader from the ground up. 

There is actually no need to scatter the config across multiple files,
it makes the whole thing more maintenance intensive and more susceptible
to errors.

Our first target was thus to actually merge all config options into a
single place without having to read or write multiple files.
Initially uboot was designed to boot from NAND and to read its
configuration from a NAND partition. Based on this config an opportunity
to store the content of this NAND partition in a binary file exists
along with the support to place this file ad binary blob on a vfat
partition [1].

Since the file size is fixed at creation time and since only contents of
the blob change this setup is a lot more robust and does actually not
result in any fs or file corruption at all.

The other advantage of using this model is that you can actually use the
saveenv function of uboot to have your changes stay persistent, without
writing any stamp files to the vfat directly.

Now, if you are a porter for a u-boot based system this means some
changes to you. As you can see in our beaglebone tree at [2] you need to
create a default environment as text file (we call it uboot.env.in in
this case, but indeed the name is totally up to you).
We use that file with the mkenvimage tool that u-boot ships in its tree
[3], so please make sure that when you build uboot for your device you
also build the tools to get this binary.

And indeed as mentioned before, this input file merges the default
environment (which you can get easily from your device by intercepting
the autoboot on a serial console and running printenv at the uboot
prompt or even by pulling it directly out of your board configuration in
the source tree where it is hardcoded).

Loading the boot.env blob happens as the very first action once uboot
started up and the content will completely replace the hardcoded
environment, so make sure to catch all values from the printenv
command.

If your device uses a uEnv.txt or (like the odroid) a boot.ini file,
make sure all values from there are included in your input file as well.

You will also want the contents of the snappy-system.txt file that
ubuntu-device-flash used to put in place (in [2] see the "snappy_ab,
snappy_boot, snappy_cmdline and snappy_mode variables, they are device
agnostic so you can just copy them from this merge request 1:1)

Now, to replace the touching of the stamp file via fatwrite you want to
also add the  "snappy_trial_boot" variable, this is a boolean and should
default to 0 in your setup (this variable is also used by grub in
snappy, a nice side effect is that thanks to the above changes
and to the ability to use this variable in uboot as well now, we could
drop all special casing in the snappy binary and have a completely
unified bootloader handling across all arches).

Last but not least, if you have any questions about this new setup or
need any help with porting do not hesitate to ask here on the mailing
list or find me on IRC in the #snappy channel on freenode and i will
happily help you with your port.

ciao
    oli

[1]
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=57210c7cc363cf2a2a28010658c7ea67388f8d21;hp=9b96c6b11fac3d7bcd5f9cb4d2868d06500e28db
[2] https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/264975
[3]
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a6337e6ffdea211e70dd8d6c638f6a5ec2295400;hp=0d9679e65a59fd05d9c7d554a7e304590366f390