r4534 introduced devicetree.cb in every mainboard directory, and 100% of that content was extracted from Config.lb in the same directory without eliminating the original contents.
This patch fixes the dupliaction by using include statements. So far, I only tackled amd/dbm690t because it's the only target I can run a build+boot test for. Someone needs to fix the other 110 boards in the tree.
Boot tested.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/Config.lb =================================================================== --- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/Config.lb (Revision 4605) +++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/Config.lb (Arbeitskopie) @@ -134,132 +134,4 @@ config chip.h
#The variables belong to mainboard are defined here. - -#Define gpp_configuration, A=0, B=1, C=2, D=3, E=4(default) -#Define vga_rom_address = 0xfff0000 -#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7) -#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or Dev3, -# 1: the system allows a PCIE link to be established on Dev2 or Dev3. -#Define gfx_dual_slot, 0: single slot, 1: dual slot -#Define gfx_lane_reversal, 0: disable lane reversal, 1: enable -#Define gfx_tmds, 0: didn't support TMDS, 1: support -#Define gfx_compliance, 0: didn't support compliance, 1: support -#Define gfx_reconfiguration, 0: short reconfiguration, 1(default): long reconfiguration -#Define gfx_link_width, 0: x16, 1: x1, 2: x2, 3: x4, 4: x8, 5: x12 (not supported), 6: x16 -chip northbridge/amd/amdk8/root_complex - device apic_cluster 0 on - chip cpu/amd/socket_S1G1 - device apic 0 on end - end - end - device pci_domain 0 on - chip northbridge/amd/amdk8 - device pci 18.0 on # southbridge - chip southbridge/amd/rs690 - device pci 0.0 on end # HT 0x7910 - device pci 1.0 on # Internal Graphics P2P bridge 0x7912 - chip drivers/pci/onboard - device pci 5.0 on end # Internal Graphics 0x791F - register "rom_address" = "0xfff00000" - end - end - device pci 2.0 on end # PCIE P2P bridge (external graphics) 0x7913 - device pci 3.0 off end # PCIE P2P bridge 0x791b - device pci 4.0 on end # PCIE P2P bridge 0x7914 - device pci 5.0 on end # PCIE P2P bridge 0x7915 - device pci 6.0 on end # PCIE P2P bridge 0x7916 - device pci 7.0 on end # PCIE P2P bridge 0x7917 - device pci 8.0 off end # NB/SB Link P2P bridge - register "vga_rom_address" = "0xfff00000" - register "gpp_configuration" = "4" - register "port_enable" = "0xfc" - register "gfx_dev2_dev3" = "1" - register "gfx_dual_slot" = "0" - register "gfx_lane_reversal" = "0" - register "gfx_tmds" = "0" - register "gfx_compliance" = "0" - register "gfx_reconfiguration" = "1" - register "gfx_link_width" = "0" - end - chip southbridge/amd/sb600 # it is under NB/SB Link, but on the same pri bus - device pci 12.0 on end # SATA 0x4380 - device pci 13.0 on end # USB 0x4387 - device pci 13.1 on end # USB 0x4388 - device pci 13.2 on end # USB 0x4389 - device pci 13.3 on end # USB 0x438a - device pci 13.4 on end # USB 0x438b - device pci 13.5 on end # USB 2 0x4386 - device pci 14.0 on # SM 0x4385 - chip drivers/generic/generic #dimm 0-0-0 - device i2c 50 on end - end - chip drivers/generic/generic #dimm 0-0-1 - device i2c 51 on end - end - chip drivers/generic/generic #dimm 0-1-0 - device i2c 52 on end - end - chip drivers/generic/generic #dimm 0-1-1 - device i2c 53 on end - end - end # SM - device pci 14.1 on end # IDE 0x438c - device pci 14.2 on end # HDA 0x4383 - device pci 14.3 on # LPC 0x438d - chip superio/ite/it8712f - device pnp 2e.0 off # Floppy - io 0x60 = 0x3f0 - irq 0x70 = 6 - drq 0x74 = 2 - end - device pnp 2e.1 on # Com1 - io 0x60 = 0x3f8 - irq 0x70 = 4 - end - device pnp 2e.2 off # Com2 - io 0x60 = 0x2f8 - irq 0x70 = 3 - end - device pnp 2e.3 off # Parallel Port - io 0x60 = 0x378 - irq 0x70 = 7 - end - device pnp 2e.4 off end # EC - device pnp 2e.5 on # Keyboard - io 0x60 = 0x60 - io 0x62 = 0x64 - irq 0x70 = 1 - end - device pnp 2e.6 on # Mouse - irq 0x70 = 12 - end - device pnp 2e.7 off # GPIO, must be closed for unresolved reason. - end - device pnp 2e.8 off # MIDI - io 0x60 = 0x300 - irq 0x70 = 9 - end - device pnp 2e.9 off # GAME - io 0x60 = 0x220 - end - device pnp 2e.a off end # CIR - end #superio/ite/it8712f - end #LPC - device pci 14.4 on end # PCI 0x4384 - device pci 14.5 on end # ACI 0x4382 - device pci 14.6 on end # MCI 0x438e - register "ide0_enable" = "1" - register "sata0_enable" = "1" - register "hda_viddid" = "0x10ec0882" - end #southbridge/amd/sb600 - end # device pci 18.0 - - device pci 18.0 on end - device pci 18.0 on end - device pci 18.1 on end - device pci 18.2 on end - device pci 18.3 on end - end #northbridge/amd/amdk8 - end #pci_domain -end #northbridge/amd/amdk8/root_complex - +include /mainboard/amd/dbm690t/devicetree.cb Index: LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/devicetree.cb =================================================================== --- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/devicetree.cb (Revision 4605) +++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/devicetree.cb (Arbeitskopie) @@ -1,3 +1,14 @@ +#Define gpp_configuration, A=0, B=1, C=2, D=3, E=4(default) +#Define vga_rom_address = 0xfff0000 +#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7) +#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or Dev3, +# 1: the system allows a PCIE link to be established on Dev2 or Dev3. +#Define gfx_dual_slot, 0: single slot, 1: dual slot +#Define gfx_lane_reversal, 0: disable lane reversal, 1: enable +#Define gfx_tmds, 0: didn't support TMDS, 1: support +#Define gfx_compliance, 0: didn't support compliance, 1: support +#Define gfx_reconfiguration, 0: short reconfiguration, 1(default): long reconfiguration +#Define gfx_link_width, 0: x16, 1: x1, 2: x2, 3: x4, 4: x8, 5: x12 (not supported), 6: x16 chip northbridge/amd/amdk8/root_complex device apic_cluster 0 on chip cpu/amd/socket_S1G1
On Fri, Aug 28, 2009 at 5:45 AM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@gmx.net wrote:
r4534 introduced devicetree.cb in every mainboard directory, and 100% of that content was extracted from Config.lb in the same directory without eliminating the original contents.
This patch fixes the dupliaction by using include statements. So far, I only tackled amd/dbm690t because it's the only target I can run a build+boot test for. Someone needs to fix the other 110 boards in the tree.
Boot tested.
I would like to NAK this patch.
Our intent is that the Config.lb files DIE and be removed. Their presence is only useful until such time as we make the cut to Kconfig permanent. I would rather not take this patch, as it locks us into backwards compatibiility for devicetree.cb -- if we improve sconfig in some way,and change devicetree.cb, we have to worry every time we change it that our change won't work for the old language. We thus have to change the old parser every time we change the new one! This is a lot of work for a tool we intend to remove.
This patch would lock us into a maintenance problem.
But thanks for looking.
ron
On 28.08.2009 14:51, ron minnich wrote:
On Fri, Aug 28, 2009 at 5:45 AM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@gmx.net wrote:
r4534 introduced devicetree.cb in every mainboard directory, and 100% of that content was extracted from Config.lb in the same directory without eliminating the original contents.
This patch fixes the dupliaction by using include statements. So far, I only tackled amd/dbm690t because it's the only target I can run a build+boot test for. Someone needs to fix the other 110 boards in the tree.
Boot tested.
I would like to NAK this patch.
Given that the move of device trees from Config.lb to devicetree.cb discarded all comments before the device tree definition, killing Config.lb will eliminate lots of useful board configuration info. That means someone has to go through all these files by hand and check for anything lost in the Config.lb->devicetree.cb copy. One part of my patch fixed this problem for the amd/dbm690t target. I'll resend that part of the patch.
Our intent is that the Config.lb files DIE and be removed. Their presence is only useful until such time as we make the cut to Kconfig permanent. I would rather not take this patch, as it locks us into backwards compatibiility for devicetree.cb -- if we improve sconfig in some way,and change devicetree.cb, we have to worry every time we change it that our change won't work for the old language. We thus have to change the old parser every time we change the new one! This is a lot of work for a tool we intend to remove.
Considering the vast config differences between settings of boards converted to Kconfig and the original settings, I do not think the cutover will make people so happy. Here's the diffstat for config changes of Kconfig vs. oldstyle Asus M2V-MX SE: 118 insertions(+), 112 deletions(-), 49 unchanged
Besides that, Cristi tried to convert amd/dbm690t to Kconfig, but the result did hang during RAM init. No idea why.
Please don't get me wrong: I'm all for using Kconfig, but it would be nice to keep the config settings identical during the move because the config settings are what keeps a board working or breaks it.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
ron minnich