From: "Jeff V. Merkey" <jmerkey@timpanogas.org>
To: David Lang <david.lang@digitalinsight.com>
Cc: kernel@kvack.org, Martin Josefsson <gandalf@wlug.westbo.se>,
Tigran Aivazian <tigran@veritas.com>,
Anil kumar <anils_r@yahoo.com>,
linux-kernel@vger.kernel.org
Subject: Re: Installing kernel 2.4
Date: Tue, 07 Nov 2000 16:39:29 -0700 [thread overview]
Message-ID: <3A0892B1.81396527@timpanogas.org> (raw)
In-Reply-To: <Pine.LNX.4.21.0011071606490.8417-100000@dlang.diginsite.com>
David Lang wrote:
>
> Jeff, the problem is not detecting the CPU type at runtime, the problem is
> trying to re-compile the code to take advantage of that CPU at runtime.
>
> depending on what CPU you have the kernel (and compiler) can use different
> commands/opmizations/etc, if you want to do this on boot you have two
> options.
>
> 1. re-compile the kernel
>
> 2. change all the CPU specific places from inline code to function calls
> into a table that get changed at boot to point at the correct calls.
The macros would be a problem. Some of the options, like MTRR, should
be auto-detected.
Jeff
>
> doing #2 will cost you so much performance that you would be better off
> just compiling for a 386 and not going through the autodetect hassle in
> the first place.
>
> David Lang
>
> On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
>
> > Date: Tue, 07 Nov 2000 16:10:58 -0700
> > From: Jeff V. Merkey <jmerkey@timpanogas.org>
> > To: kernel@kvack.org
> > Cc: Martin Josefsson <gandalf@wlug.westbo.se>,
> > Tigran Aivazian <tigran@veritas.com>, Anil kumar <anils_r@yahoo.com>,
> > linux-kernel@vger.kernel.org
> > Subject: Re: Installing kernel 2.4
> >
> >
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings. All of this could
> > be dynamic. Here's some code that does this, and it's similiar to
> > NetWare. It detexts CPU type, feature flags, special instructions,
> > etc. All of this on x86 could be dynamically detected.
> >
> > :-)
> >
> > ;*************************************************************************
> > ;
> > ; check current processor type and state
> > ;
> > ;*************************************************************************
> >
> > public DetectProcessorInformation
> > DetectProcessorInformation proc near
> >
> > mov ax, cs
> > mov ds, ax
> > mov es, ax
> >
> > pushf
> > call get_cpuid
> > call get_fpuid
> > call print
> > popf
> > ret
> >
> > DetectProcessorInformation endp
> >
> > get_cpuid proc near
> >
> > check_8086:
> >
> > pushf
> > pop ax
> > mov cx, ax
> > and ax, 0fffh
> > push ax
> > popf
> > pushf
> > pop ax
> > and ax, 0f000h
> > cmp ax, 0f000h ; flag bits 12-15 are always set on an 8086
> > mov CPU_TYPE, 0 ; 8086 detected
> > je end_get_cpuid
> >
> > check_80286:
> > or cx, 0f000h
> > push cx
> > popf
> > pushf
> > pop ax
> > and ax, 0f000h ; flag bits 12-15 are always clear on 80286 in
> > real mode
> > mov CPU_TYPE, 2 ; 80286 processor
> > jz end_get_cpuid
> >
> > check_80386:
> > mov bx, sp
> > and sp, not 3
> > OPND32
> > pushf
> > OPND32
> > pop ax
> > OPND32
> > mov cx, ax
> > OPND32 35h, 40000h
> > OPND32
> > push ax
> > OPND32
> > popf
> > OPND32
> > pushf
> > OPND32
> > pop ax
> > OPND32
> > xor ax, cx ; AC bit won't toggle, 80386 detected
> > mov sp, bx
> > mov CPU_TYPE, 3 ; 80386 detected
> > jz end_get_cpuid
> >
> > and sp, not 3
> > OPND32
> > push cx
> > OPND32
> > popf
> > mov sp, bx ; restore stack
> >
> >
> > check_80486:
> > mov CPU_TYPE, 4 ; default to 80486
> >
> > OPND32
> > mov ax, cx
> > OPND32 35h, 200000h ; xor ID bit
> > OPND32
> > push ax
> > OPND32
> > popf
> > OPND32
> > pushf
> > OPND32
> > pop ax
> > OPND32
> > xor ax, cx ; cant toggle ID bit
> > je end_get_cpuid
> >
> >
> > check_vendor:
> > mov ID_FLAG, 1
> > OPND32
> > xor ax, ax
> > CPUID
> > OPND32
> > mov word ptr VENDOR_ID, bx
> > OPND32
> > mov word ptr VENDOR_ID[+4], dx
> > OPND32
> > mov word ptr VENDOR_ID[+8], cx
> > mov si, offset VENDOR_ID
> > mov di, offset intel_id
> > mov cx, length intel_id
> >
> > compare:
> > repe cmpsb
> > or cx, cx
> > jnz end_get_cpuid
> >
> > intel_processor:
> > mov INTEL_PROC, 1
> >
> > cpuid_data:
> > OPND32
> > cmp ax, 1
> >
> > jl end_get_cpuid
> > OPND32
> > xor ax, ax
> > OPND32
> > inc ax
> > CPUID
> > mov byte ptr ds:STEPPING, al
> > and STEPPING, STEPPING_MASK
> >
> > and al, MODEL_MASK
> > shr al, MODEL_SHIFT
> > mov byte ptr ds:CPU_MODEL, al
> >
> > and ax, FAMILY_MASK
> > shr ax, FAMILY_SHIFT
> > mov byte ptr ds:CPU_TYPE, al
> >
> > mov dword ptr FEATURE_FLAGS, edx
> >
> > end_get_cpuid:
> > ret
> >
> > get_cpuid endp
> >
> >
> > get_fpuid proc near
> >
> > fninit
> > mov word ptr ds:FP_STATUS, 5a5ah
> >
> > fnstsw word ptr ds:FP_STATUS
> > mov ax, word ptr ds:FP_STATUS
> > cmp al, 0
> >
> > mov FPU_TYPE, 0
> > jne end_get_fpuid
> >
> > check_control_word:
> > fnstcw word ptr ds:FP_STATUS
> > mov ax, word ptr ds:FP_STATUS
> > and ax, 103fh
> > cmp ax, 3fh
> >
> > mov FPU_TYPE, 0
> > jne end_get_fpuid
> > mov FPU_TYPE, 1
> >
> >
> > check_infinity:
> > cmp CPU_TYPE, 3
> > jne end_get_fpuid
> > fld1
> > fldz
> > fdiv
> > fld st
> > fchs
> > fcompp
> > fstsw word ptr ds:FP_STATUS
> > mov ax, word ptr ds:FP_STATUS
> > mov FPU_TYPE, 2
> >
> > sahf
> > jz end_get_fpuid
> > mov FPU_TYPE, 3
> > end_get_fpuid:
> > ret
> > get_fpuid endp
> >
> >
> >
> > print proc near
> > cmp ID_FLAG, 1
> > je print_cpuid_data
> >
> > if (VERBOSE)
> > mov dx, offset id_msg
> > call OutputMessage
> > endif
> >
> > print_86:
> > cmp CPU_TYPE, 0
> > jne print_286
> >
> > if (VERBOSE)
> > mov dx, offset c8086
> > call OutputMessage
> > endif
> > cmp FPU_TYPE, 0
> > je end_print
> >
> > if (VERBOSE)
> > mov dx, offset fp_8087
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_286:
> > cmp CPU_TYPE, 2
> > jne print_386
> > if (VERBOSE)
> > mov dx, offset c286
> > call OutputMessage
> > endif
> > cmp FPU_TYPE, 0
> > je end_print
> > if (VERBOSE)
> > mov dx, offset fp_80287
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_386:
> > cmp CPU_TYPE, 3
> > jne print_486
> > if (VERBOSE)
> > mov dx, offset c386
> > call OutputMessage
> > endif
> > cmp FPU_TYPE, 0
> > je end_print
> > cmp FPU_TYPE, 2
> > jne print_387
> > if (VERBOSE)
> > mov dx, offset fp_80287
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_387:
> > if (VERBOSE)
> > mov dx, offset fp_80387
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_486:
> > cmp FPU_TYPE, 0
> > je print_Intel486sx
> > if (VERBOSE)
> > mov dx, offset c486
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_Intel486sx:
> > if (VERBOSE)
> > mov dx, offset c486nfp
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_cpuid_data:
> >
> > cmp_vendor:
> > cmp INTEL_PROC, 1
> > jne not_GenuineIntel
> >
> > cmp CPU_TYPE, 4
> > jne check_Pentium
> > if (VERBOSE)
> > mov dx, offset Intel486_msg
> > call OutputMessage
> > endif
> > jmp print_family
> >
> > check_Pentium:
> > cmp CPU_TYPE, 5
> > jne check_PentiumPro
> > if (VERBOSE)
> > mov dx, offset Pentium_msg
> > call OutputMessage
> > endif
> > jmp print_family
> >
> > check_PentiumPro:
> > cmp CPU_TYPE, 6
> > jne print_features
> > if (VERBOSE)
> > mov dx, offset PentiumPro_msg
> > call OutputMessage
> > endif
> >
> > print_family:
> >
> > IF VERBOSE
> > mov dx, offset family_msg
> > call OutputMessage
> > ENDIF
> >
> > mov al, byte ptr ds:CPU_TYPE
> > mov byte ptr dataCR, al
> > add byte ptr dataCR, 30h
> >
> > IF VERBOSE
> > mov dx, offset dataCR
> > call OutputMessage
> > ENDIF
> >
> > print_model:
> >
> > IF VERBOSE
> > mov dx, offset model_msg
> > call OutputMessage
> > ENDIF
> >
> > mov al, byte ptr ds:CPU_MODEL
> > mov byte ptr dataCR, al
> > add byte ptr dataCR, 30h
> >
> > IF VERBOSE
> > mov dx, offset dataCR
> > call OutputMessage
> > ENDIF
> >
> > print_features:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > and ax, FPU_FLAG
> > jz check_mce
> >
> > if (VERBOSE)
> > mov dx, offset fpu_msg
> > call OutputMessage
> > ENDIF
> >
> > check_mce:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > and ax, MCE_FLAG
> > jz check_wc
> >
> > IF VERBOSE
> > mov dx, offset mce_msg
> > call OutputMessage
> > ENDIF
> >
> > check_CMPXCHG8B:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > and ax, CMPXCHG8B_FLAG
> > jz check_4MB_paging
> >
> > IF VERBOSE
> > mov dx, offset cmp_msg
> > call OutputMessage
> > ENDIF
> >
> > chekc_io_break:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > test ax, 4
> > jz check_4MB_paging
> >
> > IF VERBOSE
> > mov dx, offset io_break_msg
> > call OutputMessage
> > ENDIF
> >
> > ; Enable Debugging Extensions bit in CR4
> > CR4_TO_ECX
> > or ecx, 08h
> > ECX_TO_CR4
> >
> > if (VERBOSE)
> > mov dx, offset io_break_enable
> > call OutputMessage
> > endif
> >
> > check_4MB_paging:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > test ax, 08h
> > jz check_PageExtend
> >
> > IF VERBOSE
> > mov dx, offset page_4MB_msg
> > call OutputMessage
> > ENDIF
> >
> > ; Enable page size extension bit in CR4
> > CR4_TO_ECX
> > or ecx, 10h
> > ECX_TO_CR4
> >
> > if (VERBOSE)
> > mov dx, offset p4mb_enable
> > call OutputMessage
> > endif
> >
> > check_PageExtend:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > test ax, 40h
> > jz check_wc
> >
> > ;; DEBUG DEBUG DEBUG !!!
> > ; Enable page address extension bit in CR4
> >
> > ;; CR4_TO_ECX
> > ;; or ecx, 20h
> > ;; ECX_TO_CR4
> >
> > check_wc:
> > mov dx, word ptr ds:FEATURE_FLAGS
> > test dx, 1000h ; MTRR support flag
> > jz end_print
> >
> > if (VERBOSE)
> > mov dx, offset wc_enable
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > not_GenuineIntel:
> > if (VERBOSE)
> > mov dx, offset not_Intel
> > call OutputMessage
> > endif
> >
> > end_print:
> > ret
> > print endp
> >
> >
> > kernel@kvack.org wrote:
> > >
> > > On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> > >
> > > > So how come NetWare and NT can detect this at run time, and we have to
> > > > use a .config option to specifiy it? Come on guys.....
> > >
> > > Then run a kernel compiled for i386 and suffer the poorer code quality
> > > that comes with not using newer instructions and including the
> > > workarounds for ancient hardware.
> > >
> > > -ben
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > Please read the FAQ at http://www.tux.org/lkml/
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > Please read the FAQ at http://www.tux.org/lkml/
> >
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-07 23:47 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-07 20:52 Installing kernel 2.4 Anil kumar
2000-11-07 20:59 ` Jeff V. Merkey
2000-11-07 21:39 ` Tigran Aivazian
2000-11-07 22:28 ` Martin Josefsson
2000-11-07 22:32 ` Jeff V. Merkey
2000-11-07 22:51 ` kernel
2000-11-07 23:10 ` Jeff V. Merkey
2000-11-07 23:57 ` Jeff Garzik
2000-11-08 0:01 ` Jeff V. Merkey
2000-11-08 0:10 ` Jeff Garzik
2000-11-08 0:12 ` Jeff V. Merkey
2000-12-10 8:22 ` Mark W. McClelland
2000-11-09 13:40 ` Alan Cox
2000-11-08 2:18 ` H. Peter Anvin
2000-11-08 7:35 ` Jeff V. Merkey
2000-11-08 0:54 ` Alan Cox
2000-11-08 3:31 ` Matthew Kirkwood
2000-11-08 0:11 ` David Lang
2000-11-07 23:39 ` Jeff V. Merkey [this message]
2000-11-07 23:51 ` Sven Koch
2000-11-07 23:59 ` Jeff Garzik
2000-11-08 0:18 ` David Relson
2000-11-08 0:23 ` Jeff V. Merkey
2000-11-08 0:50 ` Jeff Garzik
2000-11-08 0:52 ` Jeff V. Merkey
2000-11-08 0:49 ` Alan Cox
2000-11-08 0:47 ` Jeff V. Merkey
2000-11-08 0:57 ` Alan Cox
2000-11-08 0:54 ` Jeff V. Merkey
2000-11-07 22:52 ` J . A . Magallon
2000-11-07 22:54 ` J Sloan
-- strict thread matches above, loose matches on Subject: below --
2000-11-07 22:49 Bruce_Holzrichter
2000-11-07 23:24 davej
2000-11-07 23:37 ` Jeff V. Merkey
2000-11-07 23:47 ` Jeff V. Merkey
2000-11-07 23:59 ` Jeff V. Merkey
2000-11-08 0:51 ` David Lang
2000-11-08 0:10 ` Jeff V. Merkey
2000-11-08 3:39 ` davej
2000-11-08 4:41 ` Jeff V. Merkey
2000-11-08 3:57 ` davej
2000-11-08 12:05 ` Horst von Brand
2000-11-08 15:29 ` Eric W. Biederman
2000-11-08 16:51 ` James A. Sutherland
2000-11-08 17:36 ` George Anzinger
2000-11-08 19:43 ` James A. Sutherland
2000-11-08 20:32 ` George Anzinger
2000-11-08 22:01 ` James A. Sutherland
2000-11-09 13:25 ` David Woodhouse
2000-11-09 18:24 ` James A. Sutherland
2000-11-08 3:30 ` davej
2000-11-08 0:03 ` Jeff Garzik
2000-11-08 0:06 ` Jeff V. Merkey
2000-11-08 3:25 ` davej
2000-11-08 4:36 ` Jeff V. Merkey
2000-11-08 3:50 ` davej
2000-11-08 2:19 Marty Fouts
2000-11-08 2:25 Marty Fouts
2000-11-08 3:43 ` davej
2000-11-08 13:43 Jesse Pollard
2000-11-08 18:52 ` Jeff V. Merkey
2000-11-08 13:49 Bruce_Holzrichter
2000-11-08 15:10 ` davej
2000-11-08 19:16 ` Jeff V. Merkey
2000-11-08 19:19 David Feuer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A0892B1.81396527@timpanogas.org \
--to=jmerkey@timpanogas.org \
--cc=anils_r@yahoo.com \
--cc=david.lang@digitalinsight.com \
--cc=gandalf@wlug.westbo.se \
--cc=kernel@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tigran@veritas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox