[coreboot] Some v3 Kconfig options into dts?

[Carl-Daniel Hailfinger]

On 02.10.2008 00:48, ron minnich wrote:
> 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.
>   

Well, your point is good 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 :-)
>   

Absolutely. How about you get/keep it working and from time to time I
send patches to make the design a bit cleaner?

I really really want you to go ahead without considering these design
things. v3 already has a really good design and making the design
perfect shouldn't be in the way of getting hardware running.
Once we have a few boards in v3 which are also available on the market
for reasonable prices, we can attract more developers.


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

I believe I saw quite a few always-unused chunks of code in v2, so I
asked. But you're right ;-)


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

I see. I'll try to make my stage1-dts design capable of handling this.


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

We'll probably have this variable killed a year from now, so I wouldn't
invest too much brainpower in it.


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

Your score is still at +infinity. I doubt that's going to make a dent in
it. ;-)


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

OK, stays in Kconfig until stage1-dts is done.


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

That's tricky but doable.


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

Go ahead with the stopgap.


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

Like we specify CPU type right now, I'd like to argue that replacing a
CPU with a FPGA is changing the hardware, so a dts modification would be
appropriate. But I see your concerns and I'll try to address them in a
later proposal.

I have 296 coreboot mails to reply to, so this will probably take a few
days.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/