recent changes to uboot handling in snappy

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