[coreboot] how users can control additional features?

[Nico Huber]

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)?

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.

... 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