Hi,
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")?
Should coreboot add an acpi function and the OS offer a UI (e.g. /sys/class/foo/feature)? Add a nvram option? (and set a acpi variable based on nvram, so we don't need SMM)
Any other idea?
Best, lynxis
Any other idea?
Kconfig? Seems to be the simplest solution to me. Is this really something that users would want to change at runtime? If you want to have it you build it in, otherwise you don't... same with all other optional features (e.g. timestamps, CBMEM console, stuff like that).
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
-
Alexander Couzens -
Julius Werner -
Nico Huber