On Wed, Oct 1, 2008 at 12:44 PM, Peter Stuge <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote: >> config K8_SCAN_PCI_BUS >> + Whether to scan the PCI bus in stage1. >> I adopted this from v2 but it would only be a mainboard issue; it should never be in dts since it's not an option anyone should ever set. >> config K8_ALLOCATE_IO_RANGE >> + Whether to allocate I/O space in stage1. >> >> config K8_ALLOCATE_MMIO_RANGE >> + Whether to allocate MMIO space in stage1. > same. >> config LOGICAL_CPUS >> + How many logical CPUs there are. FIXME. >> should always be determined dynamically by what cpus are installed. >> config MAX_PHYSICAL_CPUS >> + Maximum number of physical CPUs (sockets). > > dts? > This comes down to wires. I don't see it in the dts. > >> config MAX_PHYSICAL_CPUS_4_BUT_MORE_INSTALLED >> + Config with 4 CPUs even if more are installed. > > But I think this should stay in Kconfig. > yes. It's a bizarre variable which I hope to remove some day. > >> config CROSS_BAR_47_56 >> + Configure for the type of crossbar on the mainboard. > > dts? no. It's wires. > > >> help >> This option is used to determine whether the mainboard has >> + a PIRQ table, which is the old way to set up interrupt routing. >> It is usually set in mainboard/*/Kconfig. >> >> config ACPI_TABLE >> boolean >> help >> This option is used to determine whether the mainboard has >> + an ACPI table. >> It is usually set in mainboard/*/Kconfig. > > dts? no. it's a build option. > > >> config SMP > >> depends CPU_I586 || CPU_AMD_K8 >> default 0 >> help >> + This option is used to enable certain functions to make coreboot >> + work correctly on symmetric multi processor systems. >> It is usually set in mainboard/*/Kconfig. > > Could this be derived from the number of logical CPUs? Yes. this is not an OS, it's a BIOS, and SMP should always be enabled. > > >> config IOAPIC >> @@ -153,7 +152,7 @@ >> depends ARCH_X86 && CPU_AMD_K8 >> default 0 >> help >> + If you want to configure an IOAPIC, set this. > > Will the builder really have an opinion on this? Isn't it chip > dependent? (ie -> dts?) it's something they should never want to see or change. Not even dts. > > >> config K8_HT_FREQ_1G_SUPPORT >> + 1 GHz support. Opteron E0 or later can support 1G HT, >> + but still depends on the mainboard. > > dts? no, it's a mainboard issue. > > >> config HT_FREQ_800MHZ >> + Can we run HT at 800 MHz. > > dts? same. > > >> config USBDEBUG_DIRECT >> depends SOUTHBRIDGE_NVIDIA_MCP55 > > Chip specific and board specific so a chip dts setting that is > filtered through the board dts and can make a Kconfig option visible > that the builder can use to disabled USB debug output? Here's the big issue. There are things that can be set in Kconfig AND in dts; there are things that are settings that should not be in Kconfig OR dts, because setting them could cause Bad Things To Happen. For that latter type of variable, I just created mainboard.h. For the Kconfig/dts issue, it's a judgement call. Possibly the best thing to do is have the dts able to use Kconfig variables in some settings: baud = "CONFIG_TTYS0_BAUD"; > > >> config APIC_ID_OFFSET >> + This is entirely mainboard dependent. > > dts? no, I don't ever want a person building a bios to think this is a variable they should touch. But it really gets down to the role of the dts. I think of it as something people can change. Things that can never change don't belong in dts or Kconfig I think. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot