#162: Move SYSTEM_TYPE to Kconfig ----------------------------+----------------------------------------------- Reporter: oxygene | Owner: oxygene Type: enhancement | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: Dependencies: | Patchstatus: there is no patch ----------------------------+----------------------------------------------- SYSTEM_TYPE is used to tell coreboot if the board is "server", "desktop" or "laptop". It's only used for AMD for now, but could also be used elsewhere to tweak configuration (and there's a flag in some table, maybe ACPI, that tells the OS about the system type, too).
It's defined for some boards, there's a default defined somewhere in the code, that looks a lot like a good match for Kconfig.
#162: Move SYSTEM_TYPE to Kconfig ----------------------------------+------------------------ Reporter: oxygene | Owner: oxygene Type: enhancement | Status: new Priority: minor | Milestone: Component: coreboot | Resolution: Keywords: | Dependencies: Patch Status: there is no patch | ----------------------------------+------------------------
Comment (by christophg+cb@…):
AFAIK there are two spots where the system type is given to the OS: in the DMI table (chassis type) and in the ACPI FADT table (Preferred_PM_Profile)
I don't know where (or even if) coreboot writes the DMI table, and currently the FADT PM profile is hardcoded in the mainboards' fadt.c.
I also think, SYSTEM_TYPE should be moved to Kconfig, be combined with DMI chassis type (if applicable) and also an option for the preferred PM profile should be added (of course defaulting to the SYSTEM_TYPE if not changed by user)
IMHO there are various advantages: * users can change the reported system/chassis type dependant on the real usage of the board without meddling with the mainboards C code * the PM profile could be equally changed (hardcoding this for a board type IMO is absurd as it equally depends on the mainboard and the real usage) * it would be easier to maintain consistency between all these settings. Also they now are mostly set with their numerical representation (#define SYSTEM_TYPE 1; fadt->preferred_pm_profile = 1; etc.) which would change with integration in Kconfig