On 02.10.2008 00:48, ron minnich wrote: > On Wed, Oct 1, 2008 at 3:40 PM, Carl-Daniel Hailfinger > <[EMAIL PROTECTED]> 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. >>>> [EMAIL PROTECTED] 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/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
