On Mon, Jul 04, 2022 at 08:04:14PM -0400, Daniel Dickman wrote:
> The patch below removes the (small) amount of code used to identify NexGen
> CPUs. I'm doubtful that these CPUs would be supported anymore and we don't
> do anything with the information once we identify a NexGen CPU.
>
> The code does a division early in the i386 boot process (in locore0) and
> checks the result of the ZF flag. Apparently ZF would have a different
> value on a NexGen vs an Intel CPU.
>
> According to my research some NexGen CPUs were:
> Nx586-P66
> Nx586-P75
> Nx586-P80
> Nx586-P90
> Nx586-P100
> Nx586-P110
> Nx586-P120
> Nx586-P133
>
> And:
> Nx586-PF100
> Nx586-PF110
>
> The models with a "P" did not include an FPU, while the models with "PF"
> did include an integrated FPU.
>
> According to this site, there were originally plans for a separate Nx587
> FPU but it was never officially released:
>
> https://www.x86-guide.net/en/fpu/NexGen-Nx587-2.html
>
> On our i386 page we state that we support:
>
> "All CPUs compatible with the Intel Pentium or later, with
> Intel-compatible hardware floating point support should work."
>
> Therefore none of the FPU-less NexGen CPUs are ones we state we support.
>
> Looking at what we implement for our recognition code, we only implement
> half of the algorithm to identify NexGen cpus that don't have the cpuid
> instruction. We ignore NexGen cpus that support the cpuid instruction
> (which would return the string "NexGenDriven"). So the ones lacking cpuid
> support probably don't have an FPU and aren't supported. While the ones
> with the FPU are likely ones that support the cpuid instruction, but our
> detection code doesn't detect them.
>
> So it looks like neither case would be supported in the current code.
>
> One thing I was not able to find out is the precise details of which of
> these CPUs do support the CPUID instruction and which ones don't. I've
> looked for these CPUs on ebay for the past few years but they seem to be
> fairly impossible to find with the last ones probably sitting in the hands
> of collectors. So the above is just a guess on my part.
>
> Finally I keep reading that the Nx586 is not actually Pentium clone, but
> rather an i386 clone. I don't have a good way to test this, but I've read
> that instructions like CMPXCHG8B (pentium), INVLPG (486), XADD (486) might
> not be directly supported by NexGen cpus. There is discussion of this
> here:
>
> https://www.cpu-world.com/forum/viewtopic.php?p=189409
>
> "...the truth is that the Nx586 is an extremely fast 386 processor. Later
> they added some 486 instructions via hypercode, which is stored in the
> BIOS EEPROM, but only the application-oriented ones. So while you can run
> most of the applications that were compiled for an 486, you can't run an
> operating system which requires a 486 or even a Pentium."
>
> Below diff tested on my transmeta notebook running i386 which continues to
> run fine and doesn't change the transmeta detection code.
>
> In the diff I left the ".Lis386" label even though it isn't needed
> anymore, but I think it's a useful comment to keep.
>
> ok?
CPU_* and CPUVENDOR_* aren't renumbered. I can't find use
where they are used as an index to an array so should be fine.
ok jsg@
>
>
> Index: i386/locore0.S
> ===================================================================
> RCS file: /cvs/src/sys/arch/i386/i386/locore0.S,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 locore0.S
> --- i386/locore0.S 31 Dec 2021 10:44:05 -0000 1.5
> +++ i386/locore0.S 3 Jul 2022 21:06:50 -0000
> @@ -132,25 +132,6 @@ start: movw $0x1234,0x472 # warm
> boot
> testl %eax,%eax
> jnz .Ltry486
>
> - /*
> - * Try the test of a NexGen CPU -- ZF will not change on a DIV
> - * instruction on a NexGen, it will on an i386. Documented in
> - * Nx586 Processor Recognition Application Note, NexGen, Inc.
> - */
> - movl $0x5555,%eax
> - xorl %edx,%edx
> - movl $2,%ecx
> - divl %ecx
> - jnz .Lis386
> -
> -.Lisnx586:
> - /*
> - * Don't try cpuid, as Nx586s reportedly don't support the
> - * PSL_ID bit.
> - */
> - movl $CPU_NX586,RELOC(_C_LABEL(cpu))
> - jmp 2f
> -
> .Lis386:
> movl $CPU_386,RELOC(_C_LABEL(cpu))
> jmp 2f
> Index: i386/machdep.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.648
> diff -u -p -u -r1.648 machdep.c
> --- i386/machdep.c 1 Feb 2022 20:29:55 -0000 1.648
> +++ i386/machdep.c 3 Jul 2022 21:06:51 -0000
> @@ -510,8 +510,6 @@ const struct cpu_nocpuid_nameclass i386_
> NULL}, /* CPU_486DLC */
> { CPUVENDOR_CYRIX, "Cyrix", "6x86", CPUCLASS_486,
> cyrix6x86_cpu_setup}, /* CPU_6x86 */
> - { CPUVENDOR_NEXGEN,"NexGen","586", CPUCLASS_386,
> - NULL}, /* CPU_NX586 */
> };
>
> const char *classnames[] = {
> Index: include/cputypes.h
> ===================================================================
> RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,v
> retrieving revision 1.10
> diff -u -p -u -r1.10 cputypes.h
> --- include/cputypes.h 29 Dec 2003 08:14:18 -0000 1.10
> +++ include/cputypes.h 3 Jul 2022 21:06:51 -0000
> @@ -48,11 +48,10 @@
> #define CPU_486 3 /* Intel 80486DX */
> #define CPU_486DLC 4 /* Cyrix 486DLC */
> #define CPU_6x86 5 /* Cyrix/IBM 6x86 */
> -#define CPU_NX586 6 /* NexGen 586 */
> #define CPU_586 7 /* Intel P.....m (I hate lawyers; it's
> TM) */
> #define CPU_AM586 8 /* AMD Am486 and Am5x86 */
> #define CPU_K5 9 /* AMD K5 */
> -#define CPU_K6 10 /* NexGen 686 aka AMD K6 */
> +#define CPU_K6 10 /* AMD K6 */
> #define CPU_686 11 /* Intel P.....m Pro */
>
> /*
> @@ -62,7 +61,6 @@
> #define CPUVENDOR_UNKNOWN -1
> #define CPUVENDOR_INTEL 0
> #define CPUVENDOR_CYRIX 1
> -#define CPUVENDOR_NEXGEN 2
> #define CPUVENDOR_AMD 3
> #define CPUVENDOR_IDT 4
> #define CPUVENDOR_RISE 5
> Index: stand/libsa/cpuprobe.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/i386/stand/libsa/cpuprobe.c,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 cpuprobe.c
> --- stand/libsa/cpuprobe.c 29 Mar 2014 18:09:29 -0000 1.2
> +++ stand/libsa/cpuprobe.c 3 Jul 2022 21:06:51 -0000
> @@ -59,17 +59,6 @@ cpuprobe(void)
> * We try to toggle bit 21 (PSL_ID) in eflags. If it works, then
> * cpuid is supported. If not, there's no cpuid, and we don't
> * try it (don't want /boot to get an invalid opcode exception).
> - *
> - * XXX The NexGen Nx586 does not support this bit, so this is not
> - * a good method to detect the presence of cpuid on this
> - * processor. That's fine: the purpose here is to detect the
> - * absence of cpuid. We don't mind if the instruction's not
> - * there - this is not intended to determine exactly what
> - * processor is there, just whether it's i386 or amd64.
> - *
> - * The only thing that would cause us grief is a processor which
> - * does not support cpuid but which does allow the PSL_ID bit
> - * in eflags to be toggled.
> */
> __asm volatile(
> "pushfl\n\t"
> Index: stand/libsa/exec_i386.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/i386/stand/libsa/exec_i386.c,v
> retrieving revision 1.51
> diff -u -p -u -r1.51 exec_i386.c
> --- stand/libsa/exec_i386.c 24 Oct 2021 17:49:19 -0000 1.51
> +++ stand/libsa/exec_i386.c 3 Jul 2022 21:06:51 -0000
> @@ -171,17 +171,6 @@ ucode_load(void)
> * We try to toggle bit 21 (PSL_ID) in eflags. If it works, then
> * cpuid is supported. If not, there's no cpuid, and we don't
> * try it (don't want /boot to get an invalid opcode exception).
> - *
> - * XXX The NexGen Nx586 does not support this bit, so this is not
> - * a good method to detect the presence of cpuid on this
> - * processor. That's fine: the purpose here is to detect the
> - * absence of cpuid. We don't mind if the instruction's not
> - * there - this is not intended to determine exactly what
> - * processor is there, just whether it's i386 or amd64.
> - *
> - * The only thing that would cause us grief is a processor which
> - * does not support cpuid but which does allow the PSL_ID bit
> - * in eflags to be toggled.
> */
> __asm volatile(
> "pushfl\n\t"
> Index: stand/libsa/machdep.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/i386/stand/libsa/machdep.c,v
> retrieving revision 1.39
> diff -u -p -u -r1.39 machdep.c
> --- stand/libsa/machdep.c 11 Jul 2018 18:08:05 -0000 1.39
> +++ stand/libsa/machdep.c 3 Jul 2022 21:06:51 -0000
> @@ -78,17 +78,6 @@ machdep(void)
> * We try to toggle bit 21 (PSL_ID) in eflags. If it works, then
> * cpuid is supported. If not, there's no cpuid, and we don't
> * try it (don't want /boot to get an invalid opcode exception).
> - *
> - * XXX The NexGen Nx586 does not support this bit, so this is not
> - * a good method to detect the presence of cpuid on this
> - * processor. That's fine: the purpose here is to detect the
> - * absence of cpuid. We don't mind if the instruction's not
> - * there - this is not intended to determine exactly what
> - * processor is there, just whether it's i386 or amd64.
> - *
> - * The only thing that would cause us grief is a processor which
> - * does not support cpuid but which does allow the PSL_ID bit
> - * in eflags to be toggled.
> */
> __asm volatile(
> "pushfl\n\t"
>
>
