I'll comment on a few. Carl-Daniel Hailfinger wrote: > The following config variables are tested in the code, but don't exist > in Kconfig: > CONFIG_ADDR > This is actually defined but never used in v2 or v3. Remove it. > CONFIG_AGP_PLUGIN_SUPPORT > CONFIG_BIG_ENDIAN > CONFIG_CARDBUS_PLUGIN_SUPPORT > CONFIG_CARTEST > Looks like old test code the was #if0 in v2. Remove it. This is also related to a question I have below about stage0_i586.S CAR. > CONFIG_CMD > CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT > CONFIG_MMCONF_SUPPORT > This will be needed when FAM10 support is added but I don't think it should be removed. The mmconf PCI code is there and ready to be used. > CONFIG_PCIE_PLUGIN_SUPPORT > CONFIG_PCIX_PLUGIN_SUPPORT > CONFIG_ROMSIZE > > CONFIG_STAGE0 > CONFIG_VIDEO_MB > CONFIG_VIDEO_MB is needed for Geode graphics. I will try to fix this one today. > CONFIG_XIP_ROM_BASE > CONFIG_XIP_ROM_SIZE > > XIP_ROM_ BASE and SIZE are AMD K8 and FAM10 specific. It is used to cache the ROM area while doing CAR. In K8/FAM10 the cache is always on to careful use of mtrrs keeps that cache from being flushed. Anyway, I don't understand why stage0_i586.S would be so similar AMD CAR. Is it just for emulation? I think that the emulator will ignore most cache settings and can be cleaned up. There seems to be some history here since v2 has cpu/x86/car/cache_as_ram.inc. Anyone know why? > Should we just kill the code they are protecting or should we introcude > Kconfig variables for them? > > For the most part, I think that they should be removed until code is ported that requires them but each section needs to be examined more closely. As with the XIP_ROM it may bring up questions about what the code around them is doing.
Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
