[coreboot] how users can control additional features?

Patrick Rudolph siro at das-labor.org
Sun Sep 23 18:38:30 CEST 2018

On 2018-09-23 12:22 PM, Nico Huber wrote:
> Hi Lynxis,
> TLDR; I would prefer NVRAM settings and reading (but not writing) NVRAM
> from ASL code directly.
> On 9/15/18 10:05 PM, Alexander Couzens wrote:
>> I would like to merge https://review.coreboot.org/c/coreboot/+/12888
>> But how the user can control this feature (and all other "special
>> features")?
> ideally at compile time, IMHO. But if you need runtime configuration
> `nvramtool` is the obvious answer.
>> Should coreboot add an acpi function and the OS offer a UI
>> (e.g. /sys/class/foo/feature)?
That'd be great.
It does not even have to be ACPI aware.

> I don't see where you would store that setting then. If it should sur-
> vive a reboot, it has to be backed by NVRAM. But no matter what that is
> (CMOS as of now or maybe flash in the future), it will be really hard
> to write from ASL code.
>> Add a nvram option? (and set a acpi variable based on nvram, so we
>> don't need SMM)
> Yes, that seems to be the right way. I agreed to do it in SMM because
> reading NVRAM seemed hard to do in ASL. I'm not convinced any more.
> Setting a variable during boot would have the downside that you always
> have to reboot before a change takes effect.
> One reason not to implement option-table reading in ASL was that the
> CMOS option table seems legacy. Though, nobody is really working on
> a replacement (some people use the flash for settings now but most
> ppl. focus on payload configuration and not coreboot).
> A hybrid solution might do it too: Instead of writing a variable for
> ACPI, coreboot could emit an ASL method that implements the NVRAM read
> (a method, to be future-proof). For the current option table, coreboot
> would simply have to translate the cmos.layout with its bit locations
> into a OperationRegion/Field definition and such ASL method would just
> return one of the entries.
Using OperationRegion/Field definition is a bad idea as the OS likes to
cache field elements. By using nvramtool the real NVRAM content could be
changed, without the OS being notified. Ofc this is not a problem with
backed NVRAM settings.

> ... thinking further about it, the cmos.layout translation could also
> be done at compile time. Heck, we would just have to add some code to
> nvramtool to output the OpRegion/Field definition. The more I think
> about it, the easier it seems to solve ;)
> OTOH, translating it at compile time would mean that we store the
> cmos.layout redundantly in the coreboot image. Well, one would have
> to replace cmos_layout.bin and cmos_layout.aml together in case (again
> something that nvramtool could learn).
> Nico
While it's possible to add those feature I would like to see a flash
solution, that also works on non x86 and is more flexible.
For example:
I don't want to hardcode the EC settings in each mainboard cmos.layout.
The same for southbridge (ahci/ide) and northbridge  (hyperthreading)
related settings.

It would be great if the build system picks up all the layout files,
a sanity check on them and then generates a board specific NV settings 
layout file.


More information about the coreboot mailing list