Re: [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  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.
> > [e-mail] 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