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? 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"
