Thanks for the cleanup Uwe! Reading it through I saw several options that I think should be in dts files instead. Please comment.
svn@coreboot.org wrote:
config K8_SCAN_PCI_BUS
Whether to scan the PCI bus in stage1.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.
We'll have to add some text about when any of these should be enabled too. Later.
config LOGICAL_CPUS
How many logical CPUs there are. FIXME.config MAX_PHYSICAL_CPUS
Maximum number of physical CPUs (sockets).
dts?
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.
config CROSS_BAR_47_56
Configure for the type of crossbar on the mainboard.
dts?
help This option is used to determine whether the mainboard has
a PIRQ table, which is the old way to set up interrupt routing.config ACPI_TABLE boolean help This option is used to determine whether the mainboard has
an ACPI table.
dts?
config SMP
depends CPU_I586 || CPU_AMD_K8 default 0 help
This option is used to enable certain functions to make corebootwork correctly on symmetric multi processor systems.
Could this be derived from the number of logical CPUs?
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?)
config K8_HT_FREQ_1G_SUPPORT
1 GHz support. Opteron E0 or later can support 1G HT,but still depends on the mainboard.
dts?
config HT_FREQ_800MHZ
Can we run HT at 800 MHz.
dts?
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?
config APIC_ID_OFFSET
This is entirely mainboard dependent.
dts?
//Peter
On Wed, Oct 1, 2008 at 12:44 PM, Peter Stuge peter@stuge.se wrote:
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.
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.
config LOGICAL_CPUS
How many logical CPUs there are. FIXME.
should always be determined dynamically by what cpus are installed.
config MAX_PHYSICAL_CPUS
Maximum number of physical CPUs (sockets).dts?
This comes down to wires. I don't see it in the dts.
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.
config CROSS_BAR_47_56
Configure for the type of crossbar on the mainboard.dts?
no. It's wires.
help This option is used to determine whether the mainboard has
a PIRQ table, which is the old way to set up interrupt routing. It is usually set in mainboard/*/Kconfig.config ACPI_TABLE boolean help This option is used to determine whether the mainboard has
an ACPI table. It is usually set in mainboard/*/Kconfig.dts?
no. it's a build option.
config SMP
depends CPU_I586 || CPU_AMD_K8 default 0 help
This option is used to enable certain functions to make corebootwork 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.
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.
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.
config HT_FREQ_800MHZ
Can we run HT at 800 MHz.dts?
same.
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.
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";
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.
ron
On 01.10.2008 23:18, ron minnich wrote:
On Wed, Oct 1, 2008 at 12:44 PM, Peter Stuge peter@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@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 corebootwork 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
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.
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 :-)
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
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
On Wed, Oct 1, 2008 at 4:09 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I have 296 coreboot mails to reply to, so this will probably take a few days.
296!?!? Yikes!
thanks, I needed that chuckle :-)
ron
-
Carl-Daniel Hailfinger -
Peter Stuge -
ron minnich