[coreboot] Some v3 Kconfig options into dts?

[ron minnich]

On Wed, Oct 1, 2008 at 3:40 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

> My idea was that dts are pure hardware description and Kconfig should be
> pure feature and board selection.

That's a good point and I think Peter was making it as well.


>
>
>>> 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?

on re-reading this I am no longer so sure.

BUT: remember that some of this stuff is stage1 and dts is not there
in stage1. This is arguably a design problem. But after two years I am
tired of designing and want to get this thing running :-)
>
>
>>>>  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?

There probably are else it would not be in there :-)


>
>>>>  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.

yeah, good point. But the HT tree is even deeper in startup. You
can't, for example, expand FLASH decoding to large size until you've
wired up hypertransport, There is always going to be a chicken-and-egg
issue with these early bits.

>
>
>>>>  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?

I am not sure.

>
>
>>>>  config CROSS_BAR_47_56
>>>> +       Configure for the type of crossbar on the mainboard.
>>>>
>>> dts?
>>>
>>
>> no. It's wires.
>>
>
> Hardware description -> dts.

You win. (You too peter!)

>
>>>>  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.

you win again! I am losing bonus points!

>
>
>>>>  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.

yeah. Except we need to see if this comes up in stage 1.

>
> 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.

which is fine but there are going to be some variables set in kconfig
which might need to change variables in dts.

>
>
>> 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.

mainboard.h is a stopgap, I bet, until we get your idea.


>
> 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).

umm :-)

So we don't touch it unless we need to touch it? That worries me.

ron