dead Kconfig variables in v3

[Carl-Daniel Hailfinger]

The following config variables are tested in the code, but don't exist
in Kconfig:
CONFIG_ADDR
CONFIG_AGP_PLUGIN_SUPPORT
CONFIG_BIG_ENDIAN
CONFIG_CARDBUS_PLUGIN_SUPPORT
CONFIG_CARTEST
CONFIG_CMD
CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT
CONFIG_MMCONF_SUPPORT
CONFIG_PCIE_PLUGIN_SUPPORT
CONFIG_PCIX_PLUGIN_SUPPORT
CONFIG_ROMSIZE
CONFIG_STAGE0
CONFIG_VIDEO_MB
CONFIG_XIP_ROM_BASE
CONFIG_XIP_ROM_SIZE

Should we just kill the code they are protecting or should we introcude
Kconfig variables for them?

Regards,
Carl-Daniel

[Marc Jones]

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

[Carl-Daniel Hailfinger]

On 14.02.2008 17:38, Marc Jones wrote:
> I'll comment on a few.

Thanks.
> 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.

We have some quite paranoid checks in v3 to make sure both compiler and
hardware don't act up. Maybe we want to really make CONFIG_CARTEST a
Kconfig variable?
> 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.

Thanks.
> > 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?

Intel processors do exist ;-)
> > 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.

Remove dead code protected by #ifdef which were never true.

Signed-off-by: Carl-Daniel Hailfinger

Index: LinuxBIOSv3-if0crud-2/include/arch/x86/pciconf.h
===================================================================
--- LinuxBIOSv3-if0crud-2/include/arch/x86/pciconf.h	(Revision 599)
+++ LinuxBIOSv3-if0crud-2/include/arch/x86/pciconf.h	(Arbeitskopie)
@@ -8,15 +8,6 @@
 #define	PCI_CONF_REG_INDEX	0xcf8
 #define	PCI_CONF_REG_DATA	0xcfc

-/* WTF for now */
-#if 0
-#if PCI_IO_CFG_EXT == 0
-#define CONFIG_ADDR(bus,devfn,where) (((bus) << 16) | ((devfn) << 8) | (where))
-#else
-#define CONFIG_ADDR(bus,devfn,where) (((bus) << 16) | ((devfn) << 8) | (where & 0xff) | ((where & 0xf00)<<16) )
 #endif
-#endif
-#define CONFIG_ADDR(bus,devfn,where) (((bus) << 16) | ((devfn) << 8) | (where))
-#endif

#endif /* ARCH_X86_PCICONF_H */
Index: LinuxBIOSv3-if0crud-2/arch/x86/stage0_i586.S
===================================================================
--- LinuxBIOSv3-if0crud-2/arch/x86/stage0_i586.S	(Revision 599)
+++ LinuxBIOSv3-if0crud-2/arch/x86/stage0_i586.S	(Arbeitskopie)
@@ -377,52 +377,6 @@
         xorl    %eax, %eax
         rep     stosl

-
-	/* TODO: make this a config variable */
-#if CONFIG_CARTEST
-	/* check the cache as ram */
-        movl  $CacheBase, %esi
-        movl    $(CacheSize>>2), %ecx
-.xin1:  
-        movl  %esi, %eax
-        movl  %eax, (%esi)
-        decl  %ecx
-        je      .xout1
-        add     $4, %esi
-        jmp     .xin1
-.xout1: 
-
-        movl  $CacheBase, %esi
-//        movl    $(CacheSize>>2), %ecx
-	movl $4, %ecx
-.xin1x:
-        movl  %esi, %eax
-
-        movl    $0x4000, %edx
-        movb    %ah, %al 
-.testx1:  
-        outb %al, $0x80
-        decl    %edx
-        jnz .testx1
-        
-        movl  (%esi), %eax
-        cmpb 0xff, %al
-        je .xin2  /* dont show */
-
-        movl    $0x4000, %edx
-.testx2:
-        outb %al, $0x80
-        decl    %edx
-        jnz .testx2
-        
-.xin2:  decl     %ecx
-        je      .xout1x
-        add     $4, %esi
-        jmp     .xin1x
-.xout1x:
-
-#endif
-
    movl	$(CacheBase+CacheSize-4), %eax
    movl    %eax, %esp

[Marc Jones]

Carl-Daniel Hailfinger wrote:
> On 14.02.2008 17:38, Marc Jones wrote:
> > > 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?
>
> Intel processors do exist ;-)

This is why I ask. From what I know of Intel CAR recommendations I 
wouldn't expert it to use CONFIG_XIP_ROM_BASE. I expect that most CPUs 
will have their own versions of CAR. So, what CPUs use the generic i586?

Marc

[Carl-Daniel Hailfinger]

On 15.02.2008 19:20, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
> > On 14.02.2008 17:38, Marc Jones wrote:
> > > > 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?
> >
> > Intel processors do exist ;-)
>
> This is why I ask. From what I know of Intel CAR recommendations I
> wouldn't expert it to use CONFIG_XIP_ROM_BASE. I expect that most CPUs
> will have their own versions of CAR. So, what CPUs use the generic i586?

The Tyan S2735 uses i586 CAR in v2. The i586 CAR code in v3 is mostly a
copy of the same thing in v2. But you're probably right about
CONFIG_XIP_ROM_BASE.

Regards,
Carl-Daniel

[Marc Jones]

Carl-Daniel Hailfinger wrote:
> Remove dead code protected by #ifdef which were never true.
>
> Signed-off-by: Carl-Daniel Hailfinger

Acked-by: Marc Jones

[Carl-Daniel Hailfinger]

On 15.02.2008 19:49, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
> > Remove dead code protected by #ifdef which were never true.
> >
> > Signed-off-by: Carl-Daniel Hailfinger
>
> Acked-by: Marc Jones

Thanks, pciconf.h CONFIG_ADDR stuff committed in r602. I'm holding off
on the CONFIG_CARTEST stuff because we may eventually want to enable it.

Regards,
Carl-Daniel