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

Simon Glass
2015-05-13T13:19:35Z

Hi Stephen,

On 25 February 2015 at 16:28, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> On 02/17/2015 03:29 PM, Simon Glass wrote:
>>
>> From: Doug Anderson <dianders@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