[coreboot] Some v3 Kconfig options into dts?
Carl-Daniel Hailfinger
c-d.hailfinger.devel.2006 at gmx.net
Thu Oct 2 00:40:29 CEST 2008
On 01.10.2008 23:18, ron minnich wrote:
> On Wed, Oct 1, 2008 at 12:44 PM, Peter Stuge <peter at stuge.se> 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.
>> svn at coreboot.org 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/
More information about the coreboot
mailing list