On 01.10.2008 23:18, ron minnich wrote: > On Wed, Oct 1, 2008 at 12:44 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: >
Forgive me for joining this discussion, but this is an area where I have tried to make the design more consistent. That doesn't mean that svn HEAD is perfect, but I have some patches on disk which I'll send real soon now. My idea was that dts are pure hardware description and Kconfig should be pure feature and board selection. >> [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. > I'm not sure I understand this completely. Do you suggest to keep mainboard settings nobody should ever touch out of the dts? >>> 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. > Are there any boards which need the option? >>> config LOGICAL_CPUS >>> + How many logical CPUs there are. FIXME. >>> >>> > > should always be determined dynamically by what cpus are installed. > Agreed. >>> config MAX_PHYSICAL_CPUS >>> + Maximum number of physical CPUs (sockets). >>> >> dts? >> >> > > This comes down to wires. I don't see it in the dts. > So it's a hardware description. In theory, we could derive the number of sockets from the dts if we ever place complete HT tree info there. >>> 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. > Should it really be user-selectable? If so, would NVRAM be a better place? >>> config CROSS_BAR_47_56 >>> + Configure for the type of crossbar on the mainboard. >>> >> dts? >> > > no. It's wires. > Hardware description -> dts. >>> 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. > OK. >>> 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. > If it is mainboard-hardware-specific and should not be changed, we should place it in the 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. > dito. >>> config HT_FREQ_800MHZ >>> + Can we run HT at 800 MHz. >>> >> dts? >> > > same. > dito. >>> 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. > I'd like to treat the dts as "don't touch" for normal users anyway. It's hardware description and users are extremely unlikely to change the board wiring. > 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"; > Hm. That's an interesting idea. Maybe we could couple it with my "dts from stage1" idea. >>> 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. > That's where our understanding about the role of the dts differs. IMO there should not be any reason why anybody would touch the dts (except maybe for configurations like a FPGA in an Opteron socket). Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
