[U-Boot] [PATCH 18/20] Add Chrome OS config header

[Simon Glass]

Hi Stephen,

On 25 February 2015 at 16:28, Stephen Warren <swarren at wwwdotorg.org> wrote:
>
> On 02/17/2015 03:29 PM, Simon Glass wrote:
>>
>> From: Doug Anderson <dianders at chromium.org>
>>
>> This header includes useful scripts which can be used with any board that
>> can boot Chrome OS.
>>
>> In particular, 'run nvboot' will boot a board without verified boot enabled.
>
>
> I think this needs a bit of minification for an upstream U-Boot. In particular, many of the environment variables overlap semantically or by name with those from include/config_distro_*.h, and I'd like to see any U-Boot for the Tegra Chromebooks (at least) support booting both ChromeOS kernels and arbitrary distros using the environment from config_distro_bootcmd.h.

That would be good. I think it is possible also, although I haven't
been able to make it work so far. I can get it to find the kernel,
although not the one that it needs and the U-Boot scripts are in a
different place on the disk in Chrome OS. Also the command line args
are wrong.

So I think for now we should either apply this as it is (since it
works) or wait until someone has time to rationalise things a bit and
figure out how to support Chrome OS booting in the distro stuff.

>
>> diff --git a/include/configs/chromeos.h b/include/configs/chromeos.h
>
>
>> +/* Stringify a token */
>> +#ifndef STRINGIFY
>> +#define _STRINGIFY(x)  #x
>> +#define STRINGIFY(x)   _STRINGIFY(x)
>> +#endif
>
>
> Shouldn't that be in some common header so it isn't ever duplicated?

Yes I'll drop it since U-Boot has its own now.

>
>> +#define CONFIG_CROS_FULL
>
>
> There are a ton of macros in here without much in the way of explanation. Shouldn't everything be documented in the README?

The documentation for these is at the top of the file:

+ * In anticipation of implementing early firmware selection, these defines
+ * signal the features that are required in U-Boot.
+ *
+ * The defines munging is thus kept to one Chrome OS-specific file. The
+ * upstream boards will define all features as normal for their platform.
+ *
+ * It is possible that these will be too broad for some platforms - e.g. we
+ * may have a platform which wants to use MMC in CONFIG_CROS_RO. However,
+ * we can deal with additional needs as we come to them.
+ *
+ * While it is something of an inconvenience, it may improve boot time on
+ * some platforms also.
+ *
+ *   CONFIG_CROS_LARGE
+ *     - Full version as now with factory defined, all features enabled
+ *     - This will operate as factory build, or verified boot
+ *
+ *   CONFIG_CROS_SMALL
+ *     - Minimized for use only with verified boot
+ *     - No command line, filesystems, LCD console, etc.
+ *     - Still has all drivers enabled and can perform verified boot
+ *
+ *   CONFIG_CROS_RO
+ *     - Requires CONFIG_CROS_SMALL. Will only support running RO firmware
+ *     - Set up for running VbLoadFirmware() only
+ *     - Minimal RAM, no display, no USB, no mass storage (SPI flash only)
+ *     - Intended for running in SPL
+ *
+ *   CONFIG_CROS_RW
+ *     - Requires CONFIG_CROS_SMALL. Will only support running RW firmware
+ *     - Set up for running VbSelectAndLoadKernel() only

Regards,
Simon