The patch below tries to implement a better i386 CPU selection.
In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
on a 486 and above.
In 2.6 selecting M486 means that only the 486 is supported.
The help text for the X86_GENERIC option says it generates a generic
kernel but the implementation is that it supports CPUs of the selected
M* option and above.
There are two different needs:
1. the installation kernel of a distribution should support all CPUs
this distribution supports (perhaps starting with the 386)
2. a sysadmin might e.g. want a kernel that support both a Pentium-III
and a Pentium 4, but doesn't need to support a 386
The implementation in 2.4 was near to satisfy need 2., if X86_GENERIC in
2.6 was implemented as the help text says it would satisfy the need
of 1.
The patch below against 2.6.0-test4-mm5 does a different implementation
that lets you select all CPUs you want to support and it should
therefore suit both needs.
Changes:
- changed the i386 CPU selection from a choice to single options for
every cpu
- renamed the M* variables to CPU_*, this is needed to ask the users
upgrading from older kernels instead of silently changing the
semantics
- AMD Elan is a different subarch, you can't configure a kernel that
runs on both the AMD Elan and other i386 CPUs
- help text changes
Questions/TODO:
- @Rusty:
what's your opinion on making MODULE_PROC_FAMILY in
include/asm-i386/module.h some kind of bitmask?
- @Robert:
there were no Elan CFLAGS in arch/i386/Makefile???
- which CPUs exactly need X86_ALIGNMENT_16?
- X86_GOOD_APIC: are there really that many processors with a bad APIC?
- could someone with a deeper knowledge of i386 CPUs comment on whether
I got the CFLAGS in arch/i386/Makefile right for all possible CPU
combinations?
- Kconfig handling of no CPU selected
diffstat output:
arch/i386/Kconfig | 237 ++++++++++++++---------------------
arch/i386/Makefile | 98 +++++++++++---
arch/i386/boot/setup.S | 2
drivers/serial/8250.h | 2
include/asm-i386/processor.h | 4
include/asm-i386/timex.h | 2
6 files changed, 184 insertions(+), 161 deletions(-)
A 2.6.0-test4-mm5 kernel with this patch applied compiled and bootet on
my PC.
cu
Adrian
--- linux-2.6.0-test4-mm5/arch/i386/Kconfig.old 2003-09-05 08:34:00.000000000 +0200
+++ linux-2.6.0-test4-mm5/arch/i386/Kconfig 2003-09-05 13:02:46.000000000 +0200
@@ -43,6 +43,15 @@
help
Choose this option if your computer is a standard PC or compatible.
+config X86_ELAN
+ bool "Elan"
+ help
+ Select this for an AMD Elan processor.
+
+ Do not use this option for K6/Athlon/Opteron processors!
+
+ If unsure choose "PC-compatible" instead.
+
config X86_VOYAGER
bool "Voyager (NCR)"
help
@@ -125,48 +134,19 @@
default y
depends on SMP && X86_ES7000 && MPENTIUMIII
-choice
- prompt "Processor family"
- default M686
-config M386
- bool "386"
- ---help---
- This is the processor type of your CPU. This information is used for
- optimizing purposes. In order to compile a kernel that can run on
- all x86 CPU types (albeit not optimally fast), you can specify
- "386" here.
-
- The kernel will not necessarily run on earlier architectures than
- the one you have chosen, e.g. a Pentium optimized kernel will run on
- a PPro, but not necessarily on a i486.
-
- Here are the settings recommended for greatest speed:
- - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
- 486DLC/DLC2, UMC 486SX-S and NexGen Nx586. Only "386" kernels
- will run on a 386 class machine.
- - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
- SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.
- - "586" for generic Pentium CPUs lacking the TSC
- (time stamp counter) register.
- - "Pentium-Classic" for the Intel Pentium.
- - "Pentium-MMX" for the Intel Pentium MMX.
- - "Pentium-Pro" for the Intel Pentium Pro.
- - "Pentium-II" for the Intel Pentium II or pre-Coppermine Celeron.
- - "Pentium-III" for the Intel Pentium III or Coppermine Celeron.
- - "Pentium-4" for the Intel Pentium 4 or P4-based Celeron.
- - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
- - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
- - "Crusoe" for the Transmeta Crusoe series.
- - "Winchip-C6" for original IDT Winchip.
- - "Winchip-2" for IDT Winchip 2.
- - "Winchip-2A" for IDT Winchips with 3dNow! capabilities.
- - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
- - "VIA C3-2 for VIA C3-2 "Nehemiah" (model 9 and above).
+if !X86_ELAN
- If you don't know what to do, choose "386".
+menu "Processor support"
-config M486
+comment "Select all processors your kernel should support"
+
+config CPU_386
+ bool "386"
+ help
+ Select this for a 386 series processor.
+
+config CPU_486
bool "486"
help
Select this for a 486 series processor, either Intel or one of the
@@ -174,227 +154,210 @@
DX2, and DX4 variants; also SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or
U5S.
-config M586
+config CPU_586
bool "586/K5/5x86/6x86/6x86MX"
help
Select this for an 586 or 686 series processor such as the AMD K5,
the Intel 5x86 or 6x86, or the Intel 6x86MX. This choice does not
assume the RDTSC (Read Time Stamp Counter) instruction.
-config M586TSC
+config CPU_586TSC
bool "Pentium-Classic"
help
Select this for a Pentium Classic processor with the RDTSC (Read
- Time Stamp Counter) instruction for benchmarking.
+ Time Stamp Counter) instruction.
-config M586MMX
+config CPU_586MMX
bool "Pentium-MMX"
help
Select this for a Pentium with the MMX graphics/multimedia
extended instructions.
-config M686
+config CPU_686
bool "Pentium-Pro"
help
- Select this for Intel Pentium Pro chips. This enables the use of
- Pentium Pro extended instructions, and disables the init-time guard
- against the f00f bug found in earlier Pentiums.
+ Select this for Intel Pentium Pro chips.
-config MPENTIUMII
+config CPU_PENTIUMII
bool "Pentium-II/Celeron(pre-Coppermine)"
help
Select this for Intel chips based on the Pentium-II and
- pre-Coppermine Celeron core. This option enables an unaligned
- copy optimization, compiles the kernel with optimization flags
- tailored for the chip, and applies any applicable Pentium Pro
- optimizations.
+ pre-Coppermine Celeron core.
-config MPENTIUMIII
+config CPU_PENTIUMIII
bool "Pentium-III/Celeron(Coppermine)/Pentium-III Xeon"
help
Select this for Intel chips based on the Pentium-III and
- Celeron-Coppermine core. This option enables use of some
- extended prefetch instructions in addition to the Pentium II
- extensions.
+ Celeron-Coppermine core.
-config MPENTIUM4
+config CPU_PENTIUM4
bool "Pentium-4/Celeron(P4-based)/Xeon"
help
Select this for Intel Pentium 4 chips. This includes both
- the Pentium 4 and P4-based Celeron chips. This option
- enables compile flags optimized for the chip, uses the
- correct cache shift, and applies any applicable Pentium III
- optimizations.
+ the Pentium 4 and P4-based Celeron chips.
-config MK6
+config CPU_K6
bool "K6/K6-II/K6-III"
help
- Select this for an AMD K6-family processor. Enables use of
- some extended instructions, and passes appropriate optimization
- flags to GCC.
+ Select this for an AMD K6, K6-II or K6-III (aka K6-3D).
-config MK7
+config CPU_K7
bool "Athlon/Duron/K7"
help
- Select this for an AMD Athlon K7-family processor. Enables use of
- some extended instructions, and passes appropriate optimization
- flags to GCC.
+ Select this for an AMD Athlon K7-family processor.
-config MK8
+config CPU_K8
bool "Opteron/Athlon64/Hammer/K8"
help
- Select this for an AMD Opteron or Athlon64 Hammer-family processor. Enables
- use of some extended instructions, and passes appropriate optimization
- flags to GCC.
+ Select this for an AMD Opteron or Athlon64 Hammer-family processor.
-config MELAN
- bool "Elan"
-
-config MCRUSOE
+config CPU_CRUSOE
bool "Crusoe"
help
- Select this for a Transmeta Crusoe processor. Treats the processor
- like a 586 with TSC, and sets some GCC optimization flags (like a
- Pentium Pro with no alignment requirements).
+ Select this for a Transmeta Crusoe processor.
-config MWINCHIPC6
+config CPU_WINCHIPC6
bool "Winchip-C6"
help
- Select this for an IDT Winchip C6 chip. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment requirements.
+ Select this for an IDT Winchip C6 chip.
-config MWINCHIP2
+config CPU_WINCHIP2
bool "Winchip-2"
help
- Select this for an IDT Winchip-2. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment requirements.
+ Select this for an IDT Winchip-2.
-config MWINCHIP3D
+config CPU_WINCHIP3D
bool "Winchip-2A/Winchip-3"
help
- Select this for an IDT Winchip-2A or 3. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment reqirements. Also enable out of order memory
- stores for this CPU, which can increase performance of some
- operations.
-
-config MCYRIXIII
- bool "CyrixIII/VIA-C3"
- help
- Select this for a Cyrix III or C3 chip. Presently Linux and GCC
- treat this chip as a generic 586. Whilst the CPU is 686 class,
- it lacks the cmov extension which gcc assumes is present when
- generating 686 code.
- Note that Nehemiah (Model 9) and above will not boot with this
- kernel due to them lacking the 3DNow! instructions used in earlier
- incarnations of the CPU.
+ Select this for an IDT Winchip-2A or 3 with 3dNow!
+ capabilities.
+
+config CPU_CYRIXIII
+ bool "Cyrix III/VIA C3"
+ help
+ Select this for a Cyrix III or VIA C3 chip.
-config MVIAC3_2
+ Note that Nehemiah (Model 9) and above need the next
+ option instead.
+
+config CPU_VIAC3_2
bool "VIA C3-2 (Nehemiah)"
help
- Select this for a VIA C3 "Nehemiah". Selecting this enables usage
- of SSE and tells gcc to treat the CPU as a 686.
- Note, this kernel will not boot on older (pre model 9) C3s.
+ Select this for a VIA C3 "Nehemiah" (model 9 and above).
-endchoice
+endmenu
-config X86_GENERIC
- bool "Generic x86 support"
- help
- Including some tuning for non selected x86 CPUs too.
- when it has moderate overhead. This is intended for generic
- distributions kernels.
+endif
+
+#
+# helper options
+#
+config CPU_WINCHIP
+ bool
+ depends on CPU_WINCHIPC6 || CPU_WINCHIP2 || CPU_WINCHIP3D
+ default y
+
+config CPU_ONLY_K7
+ bool
+ depends on CPU_K7 && !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !CPU_686 && !CPU_PENTIUMII && !CPU_PENTIUMIII && !CPU_PENTIUM4 && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+
+config CPU_ONLY_K8
+ bool
+ depends on CPU_K8 && !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !CPU_686 && !CPU_PENTIUMII && !CPU_PENTIUMIII && !CPU_PENTIUM4 && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+
+config CPU_ONLY_WINCHIP
+ bool
+ depends on CPU_WINCHIP && !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !CPU_686 && !CPU_PENTIUMII && !CPU_PENTIUMIII && !CPU_PENTIUM4 && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
+ default y
#
# Define implied options from the CPU selection here
#
config X86_CMPXCHG
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_XADD
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_L1_CACHE_SHIFT
int
- default "7" if MPENTIUM4 || X86_GENERIC
- default "4" if MELAN || M486 || M386
- default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2
- default "6" if MK7 || MK8
+ default "7" if CPU_PENTIUM4
+ default "6" if CPU_K7 || CPU_K8
+ default "5" if CPU_WINCHIP || CPU_CRUSOE || CPU_CYRIXIII || CPU_K6 || CPU_PENTIUMIII || CPU_PENTIUMII || CPU_686 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_VIAC3_2
+ default "4" if X86_ELAN || CPU_486 || CPU_386
config RWSEM_GENERIC_SPINLOCK
bool
- depends on M386
+ depends on CPU_386
default y
config RWSEM_XCHGADD_ALGORITHM
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_PPRO_FENCE
bool
- depends on M686 || M586MMX || M586TSC || M586 || M486 || M386
+ depends on CPU_686
default y
config X86_F00F_BUG
bool
- depends on M586MMX || M586TSC || M586 || M486 || M386
+ depends on CPU_586MMX || CPU_586TSC
default y
config X86_WP_WORKS_OK
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_INVLPG
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_BSWAP
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_POPAD_OK
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_ALIGNMENT_16
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
+ depends on CPU_WINCHIP || CPU_CYRIXIII || X86_ELAN || CPU_K6 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_486 || CPU_VIAC3_2
default y
config X86_GOOD_APIC
bool
- depends on MK7 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8
+ depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_K6 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
default y
config X86_INTEL_USERCOPY
bool
- depends on MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7
+ depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_686 && !CPU_K6 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
default y
config X86_USE_PPRO_CHECKSUM
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2
+ depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !X86_ELAN && !CPU_CRUSOE
default y
config X86_USE_3DNOW
bool
- depends on MCYRIXIII || MK7
+ depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !CPU_686 && !CPU_PENTIUMII && !CPU_PENTIUMIII && !CPU_PENTIUM4 && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_VIAC3_2
default y
config X86_OOSTORE
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6
+ depends on CPU_ONLY_WINCHIP
default y
config X86_4G
@@ -565,7 +528,7 @@
config X86_TSC
bool
- depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ
+ depends on !X86_NUMAQ && !CPU_386 && !CPU_486 && !CPU_586 && !X86_ELAN && !CPU_WINCHIPC6
default y
config X86_MCE
--- linux-2.6.0-test4-mm5/arch/i386/Makefile.old 2003-09-05 10:22:38.000000000 +0200
+++ linux-2.6.0-test4-mm5/arch/i386/Makefile 2003-09-05 13:03:02.000000000 +0200
@@ -28,28 +28,88 @@
align := $(subst -functions=0,,$(call check_gcc,-falign-functions=0,-malign-functions=0))
-cflags-$(CONFIG_M386) += -march=i386
-cflags-$(CONFIG_M486) += -march=i486
-cflags-$(CONFIG_M586) += -march=i586
-cflags-$(CONFIG_M586TSC) += -march=i586
-cflags-$(CONFIG_M586MMX) += $(call check_gcc,-march=pentium-mmx,-march=i586)
-cflags-$(CONFIG_M686) += -march=i686
-cflags-$(CONFIG_MPENTIUMII) += $(call check_gcc,-march=pentium2,-march=i686)
-cflags-$(CONFIG_MPENTIUMIII) += $(call check_gcc,-march=pentium3,-march=i686)
-cflags-$(CONFIG_MPENTIUM4) += $(call check_gcc,-march=pentium4,-march=i686)
-cflags-$(CONFIG_MK6) += $(call check_gcc,-march=k6,-march=i586)
+ifdef CONFIG_CPU_PENTIUM4
+ CFLAGS_CPU := $(call check_gcc,-march=pentium4,-march=i686)
+endif
+
+ifdef CONFIG_CPU_PENTIUMIII
+CFLAGS_CPU := $(call check_gcc,-march=pentium3,-march=i686)
+endif
+
+ifdef CONFIG_CPU_PENTIUMII
+CFLAGS_CPU := $(call check_gcc,-march=pentium2,-march=i686)
+endif
+
+ifdef CONFIG_CPU_K8
+ CFLAGS_CPU := $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
+endif
+
# Please note, that patches that add -march=athlon-xp and friends are pointless.
# They make zero difference whatsosever to performance at this time.
-cflags-$(CONFIG_MK7) += $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
-cflags-$(CONFIG_MK8) += $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
-cflags-$(CONFIG_MCRUSOE) += -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MWINCHIPC6) += $(call check_gcc,-march=winchip-c6,-march=i586)
-cflags-$(CONFIG_MWINCHIP2) += $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MWINCHIP3D) += $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MCYRIXIII) += $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MVIAC3_2) += $(call check_gcc,-march=c3-2,-march=i686)
+ifdef CONFIG_CPU_K7
+ CFLAGS_CPU := $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
+endif
+
+ifdef CONFIG_CPU_VIAC3_2
+ CFLAGS_CPU := $(call check_gcc,-march=c3-2,-march=i686)
+endif
+
+ifdef CONFIG_CPU_CYRIXIII
+ CFLAGS_CPU := $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+endif
+
+ifdef CONFIG_CPU_CRUSOE
+ CFLAGS_CPU := -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+endif
+
+ifdef CONFIG_CPU_686
+ CFLAGS_CPU := -march=i686
+endif
+
+ifdef CONFIG_CPU_K6
+ CFLAGS_CPU := $(call check_gcc,-march=k6,-march=i586)
+endif
+
+ifdef CONFIG_CPU_586MMX
+ CFLAGS_CPU := $(call check_gcc,-march=pentium-mmx,-march=i586)
+endif
+
+ifdef CONFIG_CPU_ONLY_WINCHIP
+ ifdef CONFIG_CPU_WINCHIPC6
+ CFLAGS_CPU := $(call check_gcc,-march=winchip-c6,-march=i586)
+ else
+ ifdef CONFIG_CPU_WINCHIP2
+ CFLAGS_CPU := $(call check_gcc,-march=winchip2,-march=i586)
+ else
+ ifdef CPU_WINCHIP3D
+ CFLAGS_CPU := $(call check_gcc,-march=winchip2,-march=i586)
+ endif
+ endif
+ endif
+else
+ ifdef CPU_WINCHIP
+ CFLAGS_CPU := -march=i586
+ endif
+endif
+
+ifdef CONFIG_CPU_586TSC
+CFLAGS_CPU := -march=i586
+endif
+
+ifdef CONFIG_CPU_586
+ CFLAGS_CPU := -march=i586
+endif
+
+ifdef CONFIG_CPU_486
+ CFLAGS_CPU := -march=i486
+endif
+
+ifdef CONFIG_CPU_386
+ CFLAGS_CPU := -march=i386
+endif
+
-CFLAGS += $(cflags-y)
+CFLAGS += $(CFLAGS_CPU)
# Default subarch .c files
mcore-y := mach-default
--- linux-2.6.0-test4-mm5/include/asm-i386/processor.h.old 2003-09-05 12:46:37.000000000 +0200
+++ linux-2.6.0-test4-mm5/include/asm-i386/processor.h 2003-09-05 12:47:08.000000000 +0200
@@ -544,7 +544,7 @@
#define K7_NOP7 ".byte 0x8D,0x04,0x05,0,0,0,0\n"
#define K7_NOP8 K7_NOP7 ASM_NOP1
-#ifdef CONFIG_MK8
+#ifdef CONFIG_CPU_ONLY_K8
#define ASM_NOP1 K8_NOP1
#define ASM_NOP2 K8_NOP2
#define ASM_NOP3 K8_NOP3
@@ -553,7 +553,7 @@
#define ASM_NOP6 K8_NOP6
#define ASM_NOP7 K8_NOP7
#define ASM_NOP8 K8_NOP8
-#elif defined(CONFIG_MK7)
+#elif defined(CONFIG_CPU_ONLY_K7)
#define ASM_NOP1 K7_NOP1
#define ASM_NOP2 K7_NOP2
#define ASM_NOP3 K7_NOP3
--- linux-2.6.0-test4-mm5/drivers/serial/8250.h.old 2003-09-05 10:21:47.000000000 +0200
+++ linux-2.6.0-test4-mm5/drivers/serial/8250.h 2003-09-05 10:22:03.000000000 +0200
@@ -44,7 +44,7 @@
#undef SERIAL_DEBUG_PCI
-#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))
+#if defined(__i386__) && (defined(CONFIG_CPU_386) || defined(CONFIG_CPU_486))
#define SERIAL_INLINE
#endif
--- linux-2.6.0-test4-mm5/arch/i386/boot/setup.S.old 2003-09-05 12:35:25.000000000 +0200
+++ linux-2.6.0-test4-mm5/arch/i386/boot/setup.S 2003-09-05 12:35:38.000000000 +0200
@@ -744,7 +744,7 @@
# AMD Elan bug fix by Robert Schwebel.
#
-#if defined(CONFIG_MELAN)
+#if defined(CONFIG_X86_ELAN)
movb $0x02, %al # alternate A20 gate
outb %al, $0x92 # this works on SC410/SC520
a20_elan_wait:
--- linux-2.6.0-test4-mm5/include/asm-i386/timex.h.old 2003-09-05 12:36:47.000000000 +0200
+++ linux-2.6.0-test4-mm5/include/asm-i386/timex.h 2003-09-05 12:36:59.000000000 +0200
@@ -12,7 +12,7 @@
#ifdef CONFIG_X86_PC9800
extern int CLOCK_TICK_RATE;
#else
-#ifdef CONFIG_MELAN
+#ifdef CONFIG_X86_ELAN
# define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
#else
# define CLOCK_TICK_RATE 1193182 /* Underlying HZ */
On Sun, 2003-09-07 13:28:13 +0200, Adrian Bunk <[email protected]>
wrote in message <[email protected]>:
> There are two different needs:
> 1. the installation kernel of a distribution should support all CPUs
> this distribution supports (perhaps starting with the 386)
So far, no major distribution does support an i386. Basically, this has
leaked in by some broken patch to libstdc++ which was not observed for a
long time. To support i386, an additional emulator for additional i486
needs to be compiled-in, too. I had a short try to port Debian's patch
into 2.6.x, but it oopsed :-> If I get some time, I'll finish that.
Before we have thie i486-emu-for-i386 in, i386 support in the kernel
doesn't make *any* sense on it's own...
> Changes:
> - changed the i386 CPU selection from a choice to single options for
> every cpu
> - renamed the M* variables to CPU_*, this is needed to ask the users
> upgrading from older kernels instead of silently changing the
> semantics
> - AMD Elan is a different subarch, you can't configure a kernel that
> runs on both the AMD Elan and other i386 CPUs
Oh well, the Elan is a beasty thing:) However, I like your overall
approach, though.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
On Sun, Sep 07, 2003 at 01:28:13PM +0200, Adrian Bunk wrote:
> The patch below tries to implement a better i386 CPU selection.
Did you look at how rmk does CPU selection in the ARM tree? He has
developed a very sophisticated scheme as there are lots of completely
different cpu implementations, using a few cores. It might be an idea to
make the schemes more uniform than they are now.
> There are two different needs:
> 1. the installation kernel of a distribution should support all CPUs
> this distribution supports (perhaps starting with the 386)
Ack.
> 2. a sysadmin might e.g. want a kernel that support both a Pentium-III
> and a Pentium 4, but doesn't need to support a 386
Ack.
3. Embedded forlks might want to make a kernel which has support for
exactly the used processor and nothing more.
> Changes:
[...]
> - AMD Elan is a different subarch, you can't configure a kernel that
> runs on both the AMD Elan and other i386 CPUs
Ack. Same with for example Geode. And the subarchs might have different
implementations, like Elan SC400, Elan SC410, Elan SC520.
> - @Robert:
> there were no Elan CFLAGS in arch/i386/Makefile???
That seems to have evolved since I last touched the Elan stuff. The
Elans are more or less 486 cores with some edges, so adding -march=i486
should be ok.
> - which CPUs exactly need X86_ALIGNMENT_16?
I've just copied that from 486.
> A 2.6.0-test4-mm5 kernel with this patch applied compiled and bootet on
> my PC.
I could do some tests on an Elan board, but not earlier than end of next
week as I'm out of office for some days...
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Sun, Sep 07, 2003 at 01:28:13PM +0200, Adrian Bunk wrote:
Could you change this:
> +ifdef CONFIG_CPU_386
> + CFLAGS_CPU := -march=i386
> +endif
> +
>
> -CFLAGS += $(cflags-y)
> +CFLAGS += $(CFLAGS_CPU)
to:
cpuflags-$(CONFIG_CPU_386) := -march=i386
CFLAGS += $(cflags-y) $(cpuflags-y)
I kept cflags-y, but you may have totally eliminated that?
Sam
On Sun, Sep 07, 2003 at 02:42:37PM +0200, Sam Ravnborg wrote:
> On Sun, Sep 07, 2003 at 01:28:13PM +0200, Adrian Bunk wrote:
> Could you change this:
> > +ifdef CONFIG_CPU_386
> > + CFLAGS_CPU := -march=i386
> > +endif
> > +
> >
> > -CFLAGS += $(cflags-y)
> > +CFLAGS += $(CFLAGS_CPU)
>
> to:
> cpuflags-$(CONFIG_CPU_386) := -march=i386
> CFLAGS += $(cflags-y) $(cpuflags-y)
If I understand you correctly this doesn't change the functionality,
it's a s/CFLAGS_CPU/cpuflags-y/g ?
> I kept cflags-y, but you may have totally eliminated that?
AFAIK the cflags-y did what your proposed cpuflags-y does.
> Sam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, Sep 07, 2003 at 02:42:51PM +0200, Robert Schwebel wrote:
> On Sun, Sep 07, 2003 at 01:28:13PM +0200, Adrian Bunk wrote:
> > The patch below tries to implement a better i386 CPU selection.
>
> Did you look at how rmk does CPU selection in the ARM tree? He has
> developed a very sophisticated scheme as there are lots of completely
> different cpu implementations, using a few cores. It might be an idea to
> make the schemes more uniform than they are now.
I didn't look at the ARM Makefile. Thanks for the note, I'll have a look
at it before I'll do the revision of this patch.
>...
> > Changes:
> [...]
> > - AMD Elan is a different subarch, you can't configure a kernel that
> > runs on both the AMD Elan and other i386 CPUs
>
> Ack. Same with for example Geode. And the subarchs might have different
It seems the Geode support isn't fully merged in 2.6?
> implementations, like Elan SC400, Elan SC410, Elan SC520.
It should be no problem to add a "Processor support" menu for the Elan
that allows you to specify which Elan CPUs you plan to support.
> > - @Robert:
> > there were no Elan CFLAGS in arch/i386/Makefile???
>
> That seems to have evolved since I last touched the Elan stuff. The
> Elans are more or less 486 cores with some edges, so adding -march=i486
> should be ok.
>...
Thanks, I'll do this.
> Robert
Thanks for your comments
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, Sep 07, 2003 at 01:46:47PM +0200, Jan-Benedict Glaw wrote:
> On Sun, 2003-09-07 13:28:13 +0200, Adrian Bunk <[email protected]>
> wrote in message <[email protected]>:
> > There are two different needs:
> > 1. the installation kernel of a distribution should support all CPUs
> > this distribution supports (perhaps starting with the 386)
>
> So far, no major distribution does support an i386. Basically, this has
> leaked in by some broken patch to libstdc++ which was not observed for a
> long time. To support i386, an additional emulator for additional i486
> needs to be compiled-in, too. I had a short try to port Debian's patch
> into 2.6.x, but it oopsed :-> If I get some time, I'll finish that.
> Before we have thie i486-emu-for-i386 in, i386 support in the kernel
> doesn't make *any* sense on it's own...
>...
This is not related to the issues my patch addresses.
If you want to read my mail with a s/386/486/g and the contents should
still be valid.
> MfG, JBG
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, Sep 07, 2003 at 03:00:34PM +0200, Adrian Bunk wrote:
> I didn't look at the ARM Makefile. Thanks for the note, I'll have a
> look at it before I'll do the revision of this patch.
You should definitely discuss this with rmk. How do the PPC folks handle
CPU selection?
> > Ack. Same with for example Geode. And the subarchs might have different
>
> It seems the Geode support isn't fully merged in 2.6?
That's also my impression, although I didn't have much time to look at
the state. As far as I remember Christer Weinigel has recently done some
work in this direction.
> It should be no problem to add a "Processor support" menu for the Elan
> that allows you to specify which Elan CPUs you plan to support.
Great.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Sun, 2003-09-07 15:17:32 +0200, Adrian Bunk <[email protected]>
wrote in message <[email protected]>:
> On Sun, Sep 07, 2003 at 01:46:47PM +0200, Jan-Benedict Glaw wrote:
> > On Sun, 2003-09-07 13:28:13 +0200, Adrian Bunk <[email protected]>
> > wrote in message <[email protected]>:
> > > There are two different needs:
> > > 1. the installation kernel of a distribution should support all CPUs
> > > this distribution supports (perhaps starting with the 386)
> >
> > So far, no major distribution does support an i386. Basically, this has
> > leaked in by some broken patch to libstdc++ which was not observed for a
> > long time. To support i386, an additional emulator for additional i486
> > needs to be compiled-in, too. I had a short try to port Debian's patch
> > into 2.6.x, but it oopsed :-> If I get some time, I'll finish that.
> > Before we have thie i486-emu-for-i386 in, i386 support in the kernel
> > doesn't make *any* sense on it's own...
> >...
>
> This is not related to the issues my patch addresses.
This is why I wrote that I basically like the overall concept of your
patch.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
On Sun, 7 Sep 2003 13:28:13 +0200, Adrian Bunk wrote:
>The patch below tries to implement a better i386 CPU selection.
>
>In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
>on a 486 and above.
>
>In 2.6 selecting M486 means that only the 486 is supported.
Can you prove your claim about 2.6?
There is to the best of my knowledge nothing in 2.6.0-test4
that prevents a kernel compiled for CPU type N from working
with CPU types >N. Just to prove it, I built a CONFIG_M486
2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.
>There are two different needs:
>1. the installation kernel of a distribution should support all CPUs
> this distribution supports (perhaps starting with the 386)
>2. a sysadmin might e.g. want a kernel that support both a Pentium-III
> and a Pentium 4, but doesn't need to support a 386
How are 1 and 2 different? Both need support for CPU type N
or higher. Since a kernel configured for a lower CPU type
still works on higher CPU types, where is the problem?
(In case 2 configure for PIII and use that on PIII and P4.)
Maybe I'm missing something but I don't see any problem here.
/Mikael
This would be a good point to fix the winchip compile options properly
in 2.6 while you are at it. You should select -m486 (preferably
-m486 and then turn off the padding options)
On Sul, 2003-09-07 at 14:00, Adrian Bunk wrote:
> > Ack. Same with for example Geode. And the subarchs might have different
>
> It seems the Geode support isn't fully merged in 2.6?
Geode is just another PC, well at least in software. In hardware its
rather different and uses a lot of clever magic.
On Sun, Sep 07, 2003 at 06:31:36PM +0100, Alan Cox wrote:
> Geode is just another PC, well at least in software. In hardware its
> rather different and uses a lot of clever magic.
It seems to be similar to the Elan: the core is "just another PC", but
in several places you need to know that you have a Geode so that you can
provide the right tweaks and fixes.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Sun, Sep 07, 2003 at 06:47:51PM +0200, Mikael Pettersson wrote:
> On Sun, 7 Sep 2003 13:28:13 +0200, Adrian Bunk wrote:
> >The patch below tries to implement a better i386 CPU selection.
> >
> >In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
> >on a 486 and above.
> >
> >In 2.6 selecting M486 means that only the 486 is supported.
>
> Can you prove your claim about 2.6?
>
> There is to the best of my knowledge nothing in 2.6.0-test4
> that prevents a kernel compiled for CPU type N from working
> with CPU types >N. Just to prove it, I built a CONFIG_M486
> 2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.
Look at X86_L1_CACHE_SHIFT in arch/i386/Kconfig.
> >There are two different needs:
> >1. the installation kernel of a distribution should support all CPUs
> > this distribution supports (perhaps starting with the 386)
> >2. a sysadmin might e.g. want a kernel that support both a Pentium-III
> > and a Pentium 4, but doesn't need to support a 386
>
> How are 1 and 2 different? Both need support for CPU type N
> or higher. Since a kernel configured for a lower CPU type
> still works on higher CPU types, where is the problem?
> (In case 2 configure for PIII and use that on PIII and P4.)
>
> Maybe I'm missing something but I don't see any problem here.
In current 2.6 this is only legal with X86_GENERIC enabled.
> /Mikael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Mikael Pettersson wrote:
> There is to the best of my knowledge nothing in 2.6.0-test4
> that prevents a kernel compiled for CPU type N from working
> with CPU types >N. Just to prove it, I built a CONFIG_M486
> 2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.
You may be right, although I wonder if there are real problems like an
SMP Pentium kernel not setting up MTRRs when run on an SMP P3.
The main problems are:
1. Optimisation. A kernel optimised for P3 but compatible
with 486 needs to use 64 byte cache line alignment, and TSC
for timing, but not use any SSE instructions.
This is different from a kernel optimised for a 486.
2. The CPU types are not a total order. Say I want a kernel
that supports Athlons and a Centaur for my cluster. What
CPU setting should I use? What CPU setting will give my the best
performing kernel - and is that the same as the one for smallest
kernel?
3. Like 2, but for embedded systems. I'm (hypothetically)
selling a cable modem which was originally based on one
CPU, but we changed to a different one because it was
cheaper. I need to send out a firmware upgrade, and it is
convenient to use a kernel which can run on either model.
But I don't want to compile in support for every x86,
because space is tight, and I want it to run as fast as it
can given that it could run on either of the two chips.
> How are 1 and 2 different? Both need support for CPU type N
> or higher. Since a kernel configured for a lower CPU type
> still works on higher CPU types, where is the problem?
> (In case 2 configure for PIII and use that on PIII and P4.)
I'm not sure if an Athlon is "lower" than a PII or not.... Which do I
option do I pick, to run on either of those without including
redundant stuff for older CPUs?
-- Jamie
On Sul, 2003-09-07 at 18:48, Robert Schwebel wrote:
> It seems to be similar to the Elan: the core is "just another PC", but
> in several places you need to know that you have a Geode so that you can
> provide the right tweaks and fixes.
ELAN is "like a PC", Geode is a PC, to software. You can run a generic
386/486/586/586+MMX kernel on a Geode CPU. The Geode support just picks
the right compile options and our setup code turns on some handy CPU
features we can use
On Sul, 2003-09-07 at 18:43, Jamie Lokier wrote:
> 2. The CPU types are not a total order. Say I want a kernel
> that supports Athlons and a Centaur for my cluster. What
> CPU setting should I use? What CPU setting will give my the best
> performing kernel - and is that the same as the one for smallest
> kernel?
You'd use two kernels. There is no sane other answer to that specific
case 8)
> But I don't want to compile in support for every x86,
> because space is tight, and I want it to run as fast as it
> can given that it could run on either of the two chips.
The code size differential is noise except for FPU emulation, and thats
in part sloppy because we could have __fpuseg and eject it at boot if
not needed ;)
386 kernels are slow because of user space handling and lack of bswap
486 kernels basically work on anything just fine
> I'm not sure if an Athlon is "lower" than a PII or not.... Which do I
> option do I pick, to run on either of those without including
> redundant stuff for older CPUs?
Right now its ordered
386 - 486 - 586 - 586+TSC - 686 - PPro - PII - PIII - PIV
Geode is a branch off 586+TSC and supports 686+ too
Athlon branches off from PIII if I remember rightly
Winchip branches off from 586 and supports all later x86 too
ELAN is its own weird world
Xmeta comes off 686 somewhere depending how you handle PGE
On Sun, Sep 07, 2003 at 07:04:12PM +0100, Alan Cox wrote:
> ELAN is "like a PC", Geode is a PC, to software. You can run a generic
> 386/486/586/586+MMX kernel on a Geode CPU. The Geode support just picks
> the right compile options and our setup code turns on some handy CPU
> features we can use
Hmm, I'm not so sure. I've not much experience with Geode yet, but from
my first RTAI tests it surely has several problems which might require
an #ifdef CONFIG_MGEODE or something similar. As long as this is
possible everything's ok with me ;)
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Sul, 2003-09-07 at 19:26, Robert Schwebel wrote:
> my first RTAI tests it surely has several problems which might require
> an #ifdef CONFIG_MGEODE or something similar. As long as this is
> possible everything's ok with me ;)
Lots of the geode hardware is emulated by SMM code, it makes hard real
time on the Geode an 'interesting' world and does limit the latency you
can achieve. Its actually a lot better than say the Dell BIOS battery
SMM seems to be but its not insubstantial at times.
rdtsc before and after an inb/outb is most fascinating 8)
On Sul, 2003-09-07 at 19:26, Robert Schwebel wrote:
> my first RTAI tests it surely has several problems which might require
> an #ifdef CONFIG_MGEODE or something similar. As long as this is
> possible everything's ok with me ;)
Lots of the geode hardware is emulated by SMM code, it makes hard real
time on the Geode an 'interesting' world and does limit the latency you
can achieve. Its actually a lot better than say the Dell BIOS battery
SMM seems to be but its not insubstantial at times.
rdtsc before and after an inb/outb is most fascinating 8)
On Sun, 7 Sep 2003 18:43:41 +0100, Jamie Lokier wrote:
>> There is to the best of my knowledge nothing in 2.6.0-test4
>> that prevents a kernel compiled for CPU type N from working
>> with CPU types >N. Just to prove it, I built a CONFIG_M486
>> 2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.
>
>You may be right, although I wonder if there are real problems like an
>SMP Pentium kernel not setting up MTRRs when run on an SMP P3.
Only if you omit CONFIG_MTRR. MTRR support is independent of
which CPU type you chose to optimise for.
>The main problems are:
>
> 1. Optimisation. A kernel optimised for P3 but compatible
> with 486 needs to use 64 byte cache line alignment, and TSC
> for timing, but not use any SSE instructions.
A 486 kernel will use TSC if there is one. CONFIG_TSC (derived
from configured CPU type) allows the kernel to skip checking
for _not_ having a TSC; !CONFIG_TSC only means it has to check
before using it.
> 2. The CPU types are not a total order. Say I want a kernel
> that supports Athlons and a Centaur for my cluster. What
> CPU setting should I use? What CPU setting will give my the best
> performing kernel - and is that the same as the one for smallest
> kernel?
CONFIG_M586 supports both, with some performance loss for the K7,
but that's your choice.
> 3. Like 2, but for embedded systems. I'm (hypothetically)
> selling a cable modem which was originally based on one
> CPU, but we changed to a different one because it was
> cheaper. I need to send out a firmware upgrade, and it is
> convenient to use a kernel which can run on either model.
> But I don't want to compile in support for every x86,
> because space is tight, and I want it to run as fast as it
> can given that it could run on either of the two chips.
So configure for the lowest common denominator. As long as your
embedded system isn't SMP, L1 cache line size assumptions don't
matter much, so you only lose (a) gcc -march= optimisations that
aren't common to both CPU types you support, and (b) some features
(like TSC if it isn't common to both) may need a runtime test
and/or dynamic dispatch. Given your insistence on having a common
kernel, this is the best you can do.
>I'm not sure if an Athlon is "lower" than a PII or not.... Which do I
>option do I pick, to run on either of those without including
>redundant stuff for older CPUs?
K7 is PIII (or PII, but I don't think so) + some stuff.
Admittedly, the kernel could include some more performance-tweaking
CONFIG options (mainly for L1 cache size and gcc -mcpu= values),
but that's a simple thing to add if necessary.
/Mikael
On Sun, 7 Sep 2003 19:51:50 +0200, Adrian Bunk wrote:
>> >In 2.6 selecting M486 means that only the 486 is supported.
>>
>> Can you prove your claim about 2.6?
>>
>> There is to the best of my knowledge nothing in 2.6.0-test4
>> that prevents a kernel compiled for CPU type N from working
>> with CPU types >N. Just to prove it, I built a CONFIG_M486
>> 2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.
>
>Look at X86_L1_CACHE_SHIFT in arch/i386/Kconfig.
I have. All it does is change how much space the kernel
allocates to spinlocks and some other structures. This is
merely an optimisation primarily for SMP. This does not
prevent code from executing correctly on CPUs having a
different actual L1 cache line size.
>> (In case 2 configure for PIII and use that on PIII and P4.)
>>
>> Maybe I'm missing something but I don't see any problem here.
>
>In current 2.6 this is only legal with X86_GENERIC enabled.
No. You're over-interpreting X86_GENERIC. All it does is
change some optimisation defaults. It is not required for
correctness.
/Mikael
On Sun, Sep 07, 2003 at 11:46:58PM +0200, Mikael Pettersson wrote:
>...
> Admittedly, the kernel could include some more performance-tweaking
> CONFIG options (mainly for L1 cache size and gcc -mcpu= values),
> but that's a simple thing to add if necessary.
-march implies -mcpu.
> /Mikael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
In message <[email protected]> you write:
> - @Rusty:
> what's your opinion on making MODULE_PROC_FAMILY in
> include/asm-i386/module.h some kind of bitmask?
The current one is readable, which is good, and Linus asked for it,
which makes it kinda moot. And really, if you compile a module with
M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
for CPU seleciton, I want the poor user to have to use "modprobe -f".
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Sun, Sep 07, 2003 at 07:09:49PM +0100, Alan Cox wrote:
> On Sul, 2003-09-07 at 18:43, Jamie Lokier wrote:
> > 2. The CPU types are not a total order. Say I want a kernel
> > that supports Athlons and a Centaur for my cluster. What
> > CPU setting should I use? What CPU setting will give my the best
> > performing kernel - and is that the same as the one for smallest
> > kernel?
>
> You'd use two kernels. There is no sane other answer to that specific
> case 8)
Ehmm. In some cases, having multiple kernels is a pain in the @55.
Having the option to make a generic kernel should remain. One that
works on as much as possible CPUs. Even if it's a bit suboptimal on
some CPUs.
Also it would be nice if we can make the boot code run on anything
until the point where the CPU is detected. Then we can give a nice
message that the kernel was not compiled for this cpu instead of a
blank-screen-hang. If we have to compile printk for 386 for this
then so be it. If your printk becomes 20 or 40% slower, then so be
it. If printk is critical to your kernel performance, then youve
got a problem anyway....
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
**** "Linux is like a wigwam - no windows, no gates, apache inside!" ****
On Llu, 2003-09-08 at 09:17, Rogier Wolff wrote:
> > You'd use two kernels. There is no sane other answer to that specific
> > case 8)
>
> Ehmm. In some cases, having multiple kernels is a pain in the @55.
Right but for the winchip its 10-30% difference in performance the
others are the odd %age point (except 386)
> Also it would be nice if we can make the boot code run on anything
> until the point where the CPU is detected.
Thats hard because we run a lot of the kernel before that point. So
you'd want to write the asm checks for it in boot.S really, or export
CPU flag lists and model data and make the boot loader able to do so,
that also means grub can be taught to boot the best kernel of a set and
handle stuff itself
On Mon, Sep 08, 2003 at 10:46:30AM +1000, Rusty Russell wrote:
> In message <[email protected]> you write:
> > - @Rusty:
> > what's your opinion on making MODULE_PROC_FAMILY in
> > include/asm-i386/module.h some kind of bitmask?
>
> The current one is readable, which is good, and Linus asked for it,
> which makes it kinda moot. And really, if you compile a module with
> M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
> for CPU seleciton, I want the poor user to have to use "modprobe -f".
I agree, my thoughts go in the direction
bit 0 CPU_386
bit 1 CPU_486
bit 2 CPU_586
...
And you should need a "modprobe -f" if the bitmask in the module differs
from the bitmask in the kernel.
> Hope that clarifies,
> Rusty.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, Sep 07, 2003 at 03:14:43PM +0200, Robert Schwebel wrote:
> On Sun, Sep 07, 2003 at 03:00:34PM +0200, Adrian Bunk wrote:
> > I didn't look at the ARM Makefile. Thanks for the note, I'll have a
> > look at it before I'll do the revision of this patch.
>
> You should definitely discuss this with rmk. How do the PPC folks handle
> CPU selection?
We don't allow for one kernel to work on something outside of a
'family', nor do we (aside from MULTIPLATFORM) allow a kernel to work on
> 1 board type (maybe we'll fix that in 2.7). You can pick 8xx
(MPC8xx line), 8260 (MPC826x/MPC827x, and should be fixed up to into
classic), 6xx/7xx/74xx (aka 'classic' PPC, 40x and 44x.
--
Tom Rini
http://gate.crashing.org/~trini/
In message <[email protected]> you write:
> On Mon, Sep 08, 2003 at 10:46:30AM +1000, Rusty Russell wrote:
> > In message <[email protected]> you write:
> > > - @Rusty:
> > > what's your opinion on making MODULE_PROC_FAMILY in
> > > include/asm-i386/module.h some kind of bitmask?
> >
> > The current one is readable, which is good, and Linus asked for it,
> > which makes it kinda moot. And really, if you compile a module with
> > M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
> > for CPU seleciton, I want the poor user to have to use "modprobe -f".
>
> I agree, my thoughts go in the direction
>
> bit 0 CPU_386
> bit 1 CPU_486
> bit 2 CPU_586
We had a bitmask, which Linus said to replace with a string. We have
21 architectures, and a string works well in practice. We could have
a bitmask *and* a string, but why the complexity?
> And you should need a "modprobe -f" if the bitmask in the module differs
> from the bitmask in the kernel.
All modprobe -f knows is that it should remove/rename various sections
from the elf object before handing it to the kernel. The checking is
done in the kernel, as it should be (so we could change this whenever
we want, for example).
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Hi!
> > > 2. The CPU types are not a total order. Say I want a kernel
> > > that supports Athlons and a Centaur for my cluster. What
> > > CPU setting should I use? What CPU setting will give my the best
> > > performing kernel - and is that the same as the one for smallest
> > > kernel?
> >
> > You'd use two kernels. There is no sane other answer to that specific
> > case 8)
>
> Ehmm. In some cases, having multiple kernels is a pain in the @55.
>
> Having the option to make a generic kernel should remain. One that
> works on as much as possible CPUs. Even if it's a bit suboptimal on
> some CPUs.
>
> Also it would be nice if we can make the boot code run on anything
> until the point where the CPU is detected. Then we can give a nice
> message that the kernel was not compiled for this cpu instead of a
> blank-screen-hang. If we have to compile printk for 386 for this
Better yet do the check in i386/boot/setup.S; its assembly anyway... I
actually had check there (or somewhere near that :-) for x86-64. Not
sure where it is now.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Sun, Sep 07, 2003 at 06:25:30PM +0100, Alan Cox wrote:
> This would be a good point to fix the winchip compile options properly
> in 2.6 while you are at it. You should select -m486 (preferably
> -m486 and then turn off the padding options)
You are talking about the default for gcc versions that don't support
-march=winchip{2,-c6} ?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, Sep 07, 2003 at 07:09:49PM +0100, Alan Cox wrote:
>...
> > I'm not sure if an Athlon is "lower" than a PII or not.... Which do I
> > option do I pick, to run on either of those without including
> > redundant stuff for older CPUs?
>
> Right now its ordered
>
> 386 - 486 - 586 - 586+TSC - 686 - PPro - PII - PIII - PIV
>
> Geode is a branch off 586+TSC and supports 686+ too
> Athlon branches off from PIII if I remember rightly
> Winchip branches off from 586 and supports all later x86 too
> ELAN is its own weird world
> Xmeta comes off 686 somewhere depending how you handle PGE
x86 is a complicated family...
My current list of CPU specific questions is:
- Does the Cyrix III support 686 instructions?
- Do -march=winchip{2,-c6} and -march=c3{,-2} add anything not in
-march=i686 (except optimizations of otherwise compatible code)?
- Which CPUs exactly need X86_ALIGNMENT_16?
- X86_GOOD_APIC: Are there really that many processors with a bad APIC?
TIA
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Sep 09, 2003 at 11:11:21AM +1000, Rusty Russell wrote:
> In message <[email protected]> you write:
> > On Mon, Sep 08, 2003 at 10:46:30AM +1000, Rusty Russell wrote:
> > > In message <[email protected]> you write:
> > > > - @Rusty:
> > > > what's your opinion on making MODULE_PROC_FAMILY in
> > > > include/asm-i386/module.h some kind of bitmask?
> > >
> > > The current one is readable, which is good, and Linus asked for it,
> > > which makes it kinda moot. And really, if you compile a module with
> > > M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
> > > for CPU seleciton, I want the poor user to have to use "modprobe -f".
> >
> > I agree, my thoughts go in the direction
> >
> > bit 0 CPU_386
> > bit 1 CPU_486
> > bit 2 CPU_586
>
> We had a bitmask, which Linus said to replace with a string. We have
> 21 architectures, and a string works well in practice. We could have
> a bitmask *and* a string, but why the complexity?
>...
My intention is that the user (= person compiling the kernel) selects
all CPUs he wants to support and to move the answer to questions like
"Which CPU type should I choose to support both an AMD Athlon and a
Pentium 4?" into the Kconfig/Makefile where it's automatically selected.
> Hope that clarifies,
> Rusty.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Sep 11, 2003 at 08:28:16AM +0200, Adrian Bunk wrote:
> - Does the Cyrix III support 686 instructions?
Depends on your definition of 686. If you follow the Intel
definition (where CMOV is optional), yes. If you follow the gcc
definition (where CMOV is assumed), no.
Except for the latest Nehemiah cores (which now have CMOV).
> - Do -march=winchip{2,-c6} and -march=c3{,-2} add anything not in
> -march=i686 (except optimizations of otherwise compatible code)?
Not afaik.
> - Which CPUs exactly need X86_ALIGNMENT_16?
Unsure. This could use testing on a few systems.
> - X86_GOOD_APIC: Are there really that many processors with a bad APIC?
Mikael ?
Dave
--
Dave Jones http://www.codemonkey.org.uk
On Thu, 11 Sep 2003, Adrian Bunk wrote:
> - X86_GOOD_APIC: Are there really that many processors with a bad APIC?
Only early revisions of the P54C (75-200MHz) Pentium processors are
affected: steppings B1, B3, B5, C2 and cB1 (or 1, 2, 4, 5 and 11) as
reported by cpuid). MMX Pentia and later chips are OK as well as any
systems using external i82489DX APICs (so far i486, P5 (60/66MHz) Pentium
and P54C Pentium systems with i82489DX APICs has been found, AFAIK). Once
I proposed the option to be user-selectable as an advanced CPU option
(<asm/bugs.h> does appropriate validation), but the proposal was rejected
as incomprehesible to an average user doing a kernel build.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Iau, 2003-09-11 at 07:28, Adrian Bunk wrote:
> - Does the Cyrix III support 686 instructions?
Original Cyrix III supports the IA32 P6 definition
VIA C3 supports the IA32 P6 definition
The later ones also support cmov (the gcc i686 definition)
They run 486 scheduling better it seems because its a single issue
machine. Turn off the padding tho.
> - Do -march=winchip{2,-c6} and -march=c3{,-2} add anything not in
> -march=i686 (except optimizations of otherwise compatible code)?
Its i586 ish (but runs best with 486 code kept compact as with the C3).
It lacks some bits of Pentium (lot of profiling, appendix H type stuff)
but is 586 + optional extras in other areas.
On Thu, Sep 11, 2003 at 02:10:43PM +0200, Maciej W. Rozycki wrote:
> On Thu, 11 Sep 2003, Adrian Bunk wrote:
>
> > - X86_GOOD_APIC: Are there really that many processors with a bad APIC?
>
> Only early revisions of the P54C (75-200MHz) Pentium processors are
> affected: steppings B1, B3, B5, C2 and cB1 (or 1, 2, 4, 5 and 11) as
> reported by cpuid). MMX Pentia and later chips are OK as well as any
> systems using external i82489DX APICs (so far i486, P5 (60/66MHz) Pentium
> and P54C Pentium systems with i82489DX APICs has been found, AFAIK). Once
> I proposed the option to be user-selectable as an advanced CPU option
> (<asm/bugs.h> does appropriate validation), but the proposal was rejected
> as incomprehesible to an average user doing a kernel build.
[
My questions might sound silly - I simply don't have the x86
knowledge, but I want to get the dependencies as good as possible.
]
All Cyrix/VIA/IDT/Transmeta processors have a working APIC?
What about the original 386?
Then I can simply change it in my patch to
config X86_GOOD_APIC
bool
depends on !CPU_586TSC
default y
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, 11 Sep 2003 12:04:35 +0100, Dave Jones wrote:
>On Thu, Sep 11, 2003 at 08:28:16AM +0200, Adrian Bunk wrote:
>
> > - Does the Cyrix III support 686 instructions?
>
>Depends on your definition of 686. If you follow the Intel
>definition (where CMOV is optional), yes. If you follow the gcc
>definition (where CMOV is assumed), no.
>Except for the latest Nehemiah cores (which now have CMOV).
To be fair to gcc, no Intel P6 or above to date has shipped
without CMOV.
> > - Do -march=winchip{2,-c6} and -march=c3{,-2} add anything not in
> > -march=i686 (except optimizations of otherwise compatible code)?
>
>Not afaik.
>
> > - Which CPUs exactly need X86_ALIGNMENT_16?
>
>Unsure. This could use testing on a few systems.
K7s and P5s (and 486s too if I remember correctly) strongly prefer
code entry points and loop labels to be 16-byte aligned. This is
due to the way code is fetched from L1.
>
> > - X86_GOOD_APIC: Are there really that many processors with a bad APIC?
>
>Mikael ?
Most pre-MMX P5s have a bug which breaks back-to-back writes to
the local APIC space (P5 erratum 11AP), requiring the kernel to
insert a dummy read before each local APIC write. GOOD_APIC is
for P5MMX and above which don't have this bug.
I have a P5 chip with this erratum I sometimes use for testing
(since it's pre-MMX and thus pre-RDPMC), and I know of people
still using dual P5 boxes with these early chips.
/Mikael
On Thu, Sep 11, 2003 at 12:04:35PM +0100, Dave Jones wrote:
> On Thu, Sep 11, 2003 at 08:28:16AM +0200, Adrian Bunk wrote:
>
> > - Does the Cyrix III support 686 instructions?
>
> Depends on your definition of 686. If you follow the Intel
> definition (where CMOV is optional), yes. If you follow the gcc
> definition (where CMOV is assumed), no.
> Except for the latest Nehemiah cores (which now have CMOV).
>...
Thanks for this information.
Since I'm looking for the options to pass to gcc I have to follow the
gcc definition...
> Dave
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 12 Sep 2003 21:07:28 +0200, Adrian Bunk <[email protected]> wrote:
>[
>My questions might sound silly - I simply don't have the x86
>knowledge, but I want to get the dependencies as good as possible.
>]
>
>All Cyrix/VIA/IDT/Transmeta processors have a working APIC?
None of them do.
>What about the original 386?
Nope.
>Then I can simply change it in my patch to
>
>config X86_GOOD_APIC
> bool
> depends on !CPU_586TSC
> default y
GOOD_APIC is Intel P5MMX, Intel P6 and above, and AMD K7 and above.
Nothing else has GOOD_APIC: P5 Classic because of the bug, and the
rest because they don't have local APIC at all.
/Mikael
On Fri, Sep 12, 2003 at 10:09:20PM +0200, Mikael Pettersson wrote:
>...
> > > - Which CPUs exactly need X86_ALIGNMENT_16?
> >
> >Unsure. This could use testing on a few systems.
>
> K7s and P5s (and 486s too if I remember correctly) strongly prefer
> code entry points and loop labels to be 16-byte aligned. This is
> due to the way code is fetched from L1.
>...
Hm, that's pretty different from the definition in -test5:
config X86_ALIGNMENT_16
bool
depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII ||
MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
default y
> /Mikael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, Sep 12, 2003 at 11:38:03PM +0200, Mikael Pettersson wrote:
>...
> GOOD_APIC is Intel P5MMX, Intel P6 and above, and AMD K7 and above.
> Nothing else has GOOD_APIC: P5 Classic because of the bug, and the
> rest because they don't have local APIC at all.
Ah, thanks for this information.
Considering this, I can simply do the following in my proposal of
offering every CPU type to the user?
config X86_BAD_APIC
bool
depends on CPU_586TSC
default y
> /Mikael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Sep 11, 2003 at 03:25:10PM +0100, Alan Cox wrote:
> On Iau, 2003-09-11 at 07:28, Adrian Bunk wrote:
> > - Does the Cyrix III support 686 instructions?
>
> Original Cyrix III supports the IA32 P6 definition
> VIA C3 supports the IA32 P6 definition
> The later ones also support cmov (the gcc i686 definition)
>...
Ah, thanks.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, 13 Sep 2003 01:23:04 +0200, Adrian Bunk <[email protected]> wrote:
>Considering this, I can simply do the following in my proposal of
>offering every CPU type to the user?
>
>config X86_BAD_APIC
> bool
> depends on CPU_586TSC
> default y
That depends on your semantics for CPU_586TSC.
If it is required for support of pre-MMX P5s, then yes.
With the current semantics, where a CPU choice simply
sets a lower bound, then no.
/Mikael
On Sat, 13 Sep 2003 00:51:39 +0200, Adrian Bunk <[email protected]> wrote:
>> > > - Which CPUs exactly need X86_ALIGNMENT_16?
>> >
>> >Unsure. This could use testing on a few systems.
>>
>> K7s and P5s (and 486s too if I remember correctly) strongly prefer
>> code entry points and loop labels to be 16-byte aligned. This is
>> due to the way code is fetched from L1.
>>...
>
>Hm, that's pretty different from the definition in -test5:
>
>config X86_ALIGNMENT_16
> bool
> depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII ||
> MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
> default y
My comment referred to data from Intel and AMD code optimisation
guides.
The kernel only uses X86_ALIGNMENT_16 to derive two __ALIGN macros
for assembly code, but it doesn't use them except in one place in
the pnpbios code.
gcc -march=<cpu type> should generate appropriate alignment for
function entries and loop labels.
I suspect X86_ALIGNMENT_16 is a left-over from old code.
Perhaps its time to retire it.
/Mikael
On Sat, Sep 13, 2003 at 01:02:36PM +0200, Mikael Pettersson wrote:
> On Sat, 13 Sep 2003 01:23:04 +0200, Adrian Bunk <[email protected]> wrote:
> >Considering this, I can simply do the following in my proposal of
> >offering every CPU type to the user?
> >
> >config X86_BAD_APIC
> > bool
> > depends on CPU_586TSC
> > default y
>
> That depends on your semantics for CPU_586TSC.
> If it is required for support of pre-MMX P5s, then yes.
> With the current semantics, where a CPU choice simply
> sets a lower bound, then no.
The intention of my "better i386 CPU selection" patch is that you select
all CPUs you want to support.
The semantics is that e.g. CPU_486 doesn't enable support for Pentiums.
> /Mikael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, Sep 13, 2003 at 01:04:32PM +0200, Mikael Pettersson wrote:
> On Sat, 13 Sep 2003 00:51:39 +0200, Adrian Bunk <[email protected]> wrote:
> >> > > - Which CPUs exactly need X86_ALIGNMENT_16?
> >> >
> >> >Unsure. This could use testing on a few systems.
> >>
> >> K7s and P5s (and 486s too if I remember correctly) strongly prefer
> >> code entry points and loop labels to be 16-byte aligned. This is
> >> due to the way code is fetched from L1.
> >>...
> >
> >Hm, that's pretty different from the definition in -test5:
> >
> >config X86_ALIGNMENT_16
> > bool
> > depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII ||
> > MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
> > default y
>
> My comment referred to data from Intel and AMD code optimisation
> guides.
>
> The kernel only uses X86_ALIGNMENT_16 to derive two __ALIGN macros
> for assembly code, but it doesn't use them except in one place in
> the pnpbios code.
It seems thoe only architecture really using the __ALIGN macros is m68k.
This is irrelevant in this case since X86_ALIGNMENT_16 only affects
i386.
> gcc -march=<cpu type> should generate appropriate alignment for
> function entries and loop labels.
>
> I suspect X86_ALIGNMENT_16 is a left-over from old code.
> Perhaps its time to retire it.
Thomas, what exactly do you need __ALIGN_STR in the function
pnp_bios_callfunc in drivers/pnp/pnpbios/bioscalls.c for?
> /Mikael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 12 Sep 2003, Adrian Bunk wrote:
> What about the original 386?
The i386 is irrelevant -- it didn't have an on-chip APIC and it didn't
directly support an external one. At the time the APIC was manufactured,
i386 systems were inefficient enough not to justify designing glue logic
for the APIC.
> Then I can simply change it in my patch to
>
> config X86_GOOD_APIC
> bool
> depends on !CPU_586TSC
> default y
It's a good estimate, although Pentium systems support an external APIC
which is always good. If the on-chip APIC is used, a system suffers from
the erratum as mentioned previously, if an external one is used, a system
is good.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Fri, 12 Sep 2003, Mikael Pettersson wrote:
> GOOD_APIC is Intel P5MMX, Intel P6 and above, and AMD K7 and above.
> Nothing else has GOOD_APIC: P5 Classic because of the bug, and the
> rest because they don't have local APIC at all.
Other systems may (and do) have an external APIC. This includes i486 and
all Pentium systems. Note that the code doing a run-time check in
<asm/bugs.h> does a check for X86_FEATURE_APIC in
boot_cpu_data.x86_capability -- if the bit is reset then the local APIC is
external (there's no on-chip local APIC or it's disabled) and the test
does not panic() even if the stepping indicates the erratum is present.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +