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