[coreboot] Some v3 Kconfig options into dts?

[Carl-Daniel Hailfinger]

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/