This is a RFC only to show what we could do. Basically, the DTS is now the only source of hardware description and a converter creates Kconfig variables from each mainboard DTS.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: corebootv3-Kconfig_from_dts/Kconfig =================================================================== --- corebootv3-Kconfig_from_dts/Kconfig (Revision 794) +++ corebootv3-Kconfig_from_dts/Kconfig (Arbeitskopie) @@ -62,39 +62,16 @@
endmenu
+# Source all northbridge/southbridge/superio Kconfig files: + source mainboard/Kconfig source arch/x86/Kconfig source lib/Kconfig source device/Kconfig
# These are used for internal purposes only: +source build/Kconfig
-# Northbridges: -config NORTHBRIDGE_AMD_GEODELX - boolean -config NORTHBRIDGE_AMD_K8 - boolean -config NORTHBRIDGE_INTEL_I440BXEMULATION - boolean - -# Southbridges: -config SOUTHBRIDGE_AMD_CS5536 - boolean -config SOUTHBRIDGE_INTEL_I82371EB - boolean -config SOUTHBRIDGE_NVIDIA_MCP55 - boolean - -# Super I/Os: -config SUPERIO_WINBOND_W83627HF - boolean -config SUPERIO_FINTEK_F71805F - boolean -config SUPERIO_ITE_IT8716F - boolean - -# Source all northbridge/southbridge/superio Kconfig files: - menu "Payload"
config PAYLOAD_ELF_LOADER Index: corebootv3-Kconfig_from_dts/mainboard/adl/Kconfig =================================================================== --- corebootv3-Kconfig_from_dts/mainboard/adl/Kconfig (Revision 794) +++ corebootv3-Kconfig_from_dts/mainboard/adl/Kconfig (Arbeitskopie) @@ -28,9 +28,6 @@ select ARCH_X86 select CPU_AMD_GEODELX select OPTION_TABLE - select NORTHBRIDGE_AMD_GEODELX - select SOUTHBRIDGE_AMD_CS5536 - select SUPERIO_WINBOND_W83627HF help Advanced Digital Logic MSM800SEV mainboard.
Index: corebootv3-Kconfig_from_dts/mainboard/amd/Kconfig =================================================================== --- corebootv3-Kconfig_from_dts/mainboard/amd/Kconfig (Revision 794) +++ corebootv3-Kconfig_from_dts/mainboard/amd/Kconfig (Arbeitskopie) @@ -28,9 +28,6 @@ select ARCH_X86 select CPU_AMD_GEODELX select OPTION_TABLE - select NORTHBRIDGE_AMD_GEODELX - select SOUTHBRIDGE_AMD_CS5536 - select SUPERIO_WINBOND_W83627HF select PIRQ_TABLE help AMD DB800 Geode LX development board. @@ -40,8 +37,6 @@ select ARCH_X86 select CPU_AMD_GEODELX select OPTION_TABLE - select NORTHBRIDGE_AMD_GEODELX - select SOUTHBRIDGE_AMD_CS5536 select PIRQ_TABLE help AMD Norwich Geode LX development board. @@ -51,7 +46,6 @@ select ARCH_X86 select OPTION_TABLE select CPU_AMD_K8 - select NORTHBRIDGE_AMD_K8 select IOAPIC help AMD Serengeti Index: corebootv3-Kconfig_from_dts/mainboard/artecgroup/Kconfig =================================================================== --- corebootv3-Kconfig_from_dts/mainboard/artecgroup/Kconfig (Revision 794) +++ corebootv3-Kconfig_from_dts/mainboard/artecgroup/Kconfig (Arbeitskopie) @@ -28,8 +28,6 @@ select ARCH_X86 select CPU_AMD_GEODELX select OPTION_TABLE - select NORTHBRIDGE_AMD_GEODELX - select SOUTHBRIDGE_AMD_CS5536 select PIRQ_TABLE help Artec Group DBE61 ThinCan, also known as Linutop 1. @@ -39,8 +37,6 @@ select ARCH_X86 select CPU_AMD_GEODELX select OPTION_TABLE - select NORTHBRIDGE_AMD_GEODELX - select SOUTHBRIDGE_AMD_CS5536 select PIRQ_TABLE help Artec Group DBE62 ThinCan. Index: corebootv3-Kconfig_from_dts/mainboard/pcengines/Kconfig =================================================================== --- corebootv3-Kconfig_from_dts/mainboard/pcengines/Kconfig (Revision 794) +++ corebootv3-Kconfig_from_dts/mainboard/pcengines/Kconfig (Arbeitskopie) @@ -28,9 +28,6 @@ select ARCH_X86 select CPU_AMD_GEODELX select OPTION_TABLE - select NORTHBRIDGE_AMD_GEODELX - select SOUTHBRIDGE_AMD_CS5536 - select SUPERIO_WINBOND_W83627HF select PIRQ_TABLE help PC Engines ALIX1.C. @@ -40,8 +37,6 @@ select ARCH_X86 select CPU_AMD_GEODELX select OPTION_TABLE - select NORTHBRIDGE_AMD_GEODELX - select SOUTHBRIDGE_AMD_CS5536 select PIRQ_TABLE help PC Engines ALIX.2C3. Index: corebootv3-Kconfig_from_dts/mainboard/gigabyte/Kconfig =================================================================== --- corebootv3-Kconfig_from_dts/mainboard/gigabyte/Kconfig (Revision 794) +++ corebootv3-Kconfig_from_dts/mainboard/gigabyte/Kconfig (Arbeitskopie) @@ -28,9 +28,6 @@ select ARCH_X86 select OPTION_TABLE select CPU_AMD_K8 - select NORTHBRIDGE_AMD_K8 - select SOUTHBRIDGE_NVIDIA_MCP55 - select SUPERIO_ITE_IT8716F select IOAPIC help Gigabyte M57SLI Index: corebootv3-Kconfig_from_dts/mainboard/emulation/Kconfig =================================================================== --- corebootv3-Kconfig_from_dts/mainboard/emulation/Kconfig (Revision 794) +++ corebootv3-Kconfig_from_dts/mainboard/emulation/Kconfig (Arbeitskopie) @@ -29,9 +29,6 @@ select ARCH_X86 select CPU_I586 select OPTION_TABLE - select NORTHBRIDGE_INTEL_I440BXEMULATION - select SOUTHBRIDGE_INTEL_I82371EB - select SUPERIO_WINBOND_W83627HF help x86 QEMU variant.
Index: corebootv3-Kconfig_from_dts/create_Kconfig_from_dts =================================================================== --- corebootv3-Kconfig_from_dts/create_Kconfig_from_dts (Revision 0) +++ corebootv3-Kconfig_from_dts/create_Kconfig_from_dts (Revision 0) @@ -0,0 +1,28 @@ +#!/bin/bash +for a in mainboard/*/*/; do + c=`echo $a|tr [[:lower:]]/- [[:upper:]]__|sed "s/^MAIN//;s/_$//"` + grep /config/ $a/dts| + cut -f 2 -d'"'| + sed 's_/[^/]*$__'| + tr [[:lower:]]/ [[:upper:]]_| + sort -u| + while read b; do + echo $b $c + done + done| + sort| + while read d e; do + if [[ x$d != x$oldd ]]; then + echo -n " + +config $d + bool + default y + depends " + else + echo -n " || " + fi + echo -n $e + oldd=$d + done >$* +echo >>$*
Property changes: corebootv3-Kconfig_from_dts/create_Kconfig_from_dts ___________________________________________________________________ Name: svn:executable + *
Index: corebootv3-Kconfig_from_dts/Makefile =================================================================== --- corebootv3-Kconfig_from_dts/Makefile (Revision 794) +++ corebootv3-Kconfig_from_dts/Makefile (Arbeitskopie) @@ -130,6 +130,8 @@
prepare: $(Q)mkdir -p $(obj) + $(Q)printf "waaah\n" + $(Q)./create_Kconfig_from_dts $(obj)/Kconfig
# FIXME: If .config changed, a rebuild is required.
On Thu, Aug 21, 2008 at 6:40 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
This is a RFC only to show what we could do. Basically, the DTS is now the only source of hardware description and a converter creates Kconfig variables from each mainboard DTS.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
This is kind of interesting. Note that you are creating the mainboard Kconfig from dts; it's not like Kconfig just disappears, right?
At first glance I like it but I'd like to see other comments.
thanks
ron
ron minnich wrote:
On Thu, Aug 21, 2008 at 6:40 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
This is a RFC only to show what we could do. Basically, the DTS is now the only source of hardware description and a converter creates Kconfig variables from each mainboard DTS.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
This is kind of interesting. Note that you are creating the mainboard Kconfig from dts; it's not like Kconfig just disappears, right?
At first glance I like it but I'd like to see other comments.
thanks
ron
I like the idea, but the script should create .tree and tree.h (like .config and config.h) that can be included by the Makefile and the code. Actually running the produced stuff through Kconfig is wrong, because it has nothing to do with user configuration. Instead both Kconfig and the tree parser should produce similar output for the data each of them collects.
On Thu, Aug 21, 2008 at 11:24 PM, Stefan Reinauer stepan@coresystems.de wrote:
Actually running the produced stuff through Kconfig is wrong, because it has nothing to do with user configuration. Instead both Kconfig and the tree parser should produce similar output for the data each of them collects.
That's a key point. I agree.
ron
On 22.08.2008 08:54, ron minnich wrote:
On Thu, Aug 21, 2008 at 11:24 PM, Stefan Reinauer stepan@coresystems.de wrote:
Actually running the produced stuff through Kconfig is wrong, because it has nothing to do with user configuration. Instead both Kconfig and the tree parser should produce similar output for the data each of them collects.
That's a key point. I agree.
I had something like that in an earlier iteration, but I threw it away. The big problem here are configuration options which are available only for some targets. Look at USBDEBUG: - Some chipsets simply don't support it, so there's no point in offering it in Kconfig. - For the chipsets which support USBDEBUG, we may not want to enable it. - It is conceptually the same as serial console support, so enabling it unconditionally is bad.
Feeding the dts-produced config variables into Kconfig solves that problem nicely.
The only other alternative would be to handle this in the dts, but enabling a certain sort of console is definitely not hardware description and does not belong in the dts.
One possible cop-out would be to offer all options in Kconfig even if they are unavailable on the selected hardware. That would allow us to keep Kconfig and DTS separate.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 22.08.2008 08:54, ron minnich wrote:
On Thu, Aug 21, 2008 at 11:24 PM, Stefan Reinauer stepan@coresystems.de wrote:
Actually running the produced stuff through Kconfig is wrong, because it has nothing to do with user configuration. Instead both Kconfig and the tree parser should produce similar output for the data each of them collects.
That's a key point. I agree.
I had something like that in an earlier iteration, but I threw it away. The big problem here are configuration options which are available only for some targets. Look at USBDEBUG:
- Some chipsets simply don't support it, so there's no point in offering
it in Kconfig.
- For the chipsets which support USBDEBUG, we may not want to enable it.
Why would _we_ want to decide, not the user?
- It is conceptually the same as serial console support, so enabling it
unconditionally is bad.
what do you mean with this sentence?
....
And now imagine, someone plugs a PCI USB 2.0 card with debug support into the system. Are you saying this user should not get the option of using usb debug, because her onboard chipset can't do it?
I think the best way to solve the problem you bring up here is if you add a good help text to the USB Debug console switch a la "If your onboard USB controller has no debug port support, you need to plug a PCI USB adapter in order to use this feature."
On 22.08.2008 15:18, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 22.08.2008 08:54, ron minnich wrote:
On Thu, Aug 21, 2008 at 11:24 PM, Stefan Reinauer stepan@coresystems.de wrote:
Actually running the produced stuff through Kconfig is wrong, because it has nothing to do with user configuration. Instead both Kconfig and the tree parser should produce similar output for the data each of them collects.
That's a key point. I agree.
I had something like that in an earlier iteration, but I threw it away. The big problem here are configuration options which are available only for some targets. Look at USBDEBUG:
- Some chipsets simply don't support it, so there's no point in offering
it in Kconfig.
- For the chipsets which support USBDEBUG, we may not want to enable it.
Why would _we_ want to decide, not the user?
To make sure the user is not disappointed if a selectable feature does not work.
- It is conceptually the same as serial console support, so enabling it
unconditionally is bad.
what do you mean with this sentence?
It should be an option the user can set via the config interface.
And now imagine, someone plugs a PCI USB 2.0 card with debug support into the system. Are you saying this user should not get the option of using usb debug, because her onboard chipset can't do it?
You have a point. However, looking for USB debug capable devices in PCI slots will require PCI enumeration and will sort of depend on the device tree and thus depend on stage2. Early USB debug code for builtin devices can be available in stage1.
I think the best way to solve the problem you bring up here is if you add a good help text to the USB Debug console switch a la "If your onboard USB controller has no debug port support, you need to plug a PCI USB adapter in order to use this feature."
Agreed. Do you know of any PCI USB adapter which has this feature? It would be nice for testing.
Regards, Carl-Daniel
I just realized my misgiving. You just created a new dts parser in a shell script. We now have 2 dts parsers. So the idea is interesting, the implementation concerns me. Could we get dtc, as part of dts parsing, to generate this? Or, could we have an option to dtc to generate this? We should really only have one dts parser.
Thanks
ron
On 22.08.2008 05:41, ron minnich wrote:
I just realized my misgiving. You just created a new dts parser in a shell script. We now have 2 dts parsers. So the idea is interesting, the implementation concerns me. Could we get dtc, as part of dts parsing, to generate this? Or, could we have an option to dtc to generate this? We should really only have one dts parser.
Yes, absolutely.
However, the dtc code is horrible. I have sprinkled annotations all over the dtc code and I still have not figured out everything. Segher says that the current dtc upstream has better code quality, however our changes are extensive and merging will be a pain. He suggests to use plain upstream dtc and parse its output into our own formats. I have no opinion on dtc changes.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 22.08.2008 05:41, ron minnich wrote:
I just realized my misgiving. You just created a new dts parser in a shell script. We now have 2 dts parsers. So the idea is interesting, the implementation concerns me. Could we get dtc, as part of dts parsing, to generate this? Or, could we have an option to dtc to generate this? We should really only have one dts parser.
Yes, absolutely.
However, the dtc code is horrible. I have sprinkled annotations all over the dtc code and I still have not figured out everything. Segher says that the current dtc upstream has better code quality, however our changes are extensive and merging will be a pain. He suggests to use plain upstream dtc and parse its output into our own formats.
Makes sense. Patches welcome.
On Fri, Aug 22, 2008 at 4:37 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
However, the dtc code is horrible. I have sprinkled annotations all over the dtc code and I still have not figured out everything. Segher says that the current dtc upstream has better code quality, however our changes are extensive and merging will be a pain.
Our changes mostly live in the flatten tree code and the use of a new command, /config/. It would not be impossibly hard to fix.
The v3 decision is to use dts. There should only be one dts parser. So if we want to extend the use of the dts code, we modify the current parser or bring in the new one and use it. But we should not create two parsers in v3. I think that's a hard rule we can stick to.
If we brought in the new upstream, now that we know how things should work, we could do a better job. But we need volunteers. Until then, I think this interesting but far-reaching change must wait. My top priority is K8. The config system is good enough for now.
ron
-
Carl-Daniel Hailfinger -
ron minnich -
Stefan Reinauer