User:Combuster/notepad: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
Content added Content deleted
(Added memo on PA-RISC)
(→‎HPPA: added compatibility check)
Line 115: Line 115:
make all-gcc
make all-gcc
make install-gcc
make install-gcc

works with binutils 2.17/gcc 4.2.2
fails on binutils 2.17/gcc 4.1.1


The 15 minutes spent trying to get palo (the opensource bootloader used with linux) to compile resulted in an asm error in crt0.s
The 15 minutes spent trying to get palo (the opensource bootloader used with linux) to compile resulted in an asm error in crt0.s

Revision as of 11:40, 1 December 2007

These are my notes from experience. PD code, No warranty etc (i mess up things more than once).

DIV test

originally devised to tell apart amd/intel/cyrix/whatever 486s and 386s that didn't have cpuid, this still works on current hardware. You can detect spoofs (emulators?) by verifying the div test signature with the expected one.

recent intels maintain all flags after DIV, as do bochs and qemu by default. cyrices clear most flags, AMDs set some and clear some.

PUSHFD
POP EAX
; either clear flags for first test, or set flags for second test. pick one:
; AND AX, (0xffff - 0x8D5)
; OR AX, 0x8D5
PUSH EAX
MOV AX, 5
MOV CL, 2
POPFD
DIV CL 
PUSHFD
POP EAX
AND EAX, 0x8D5
;AX contains signature

in 16-bit mode, use popf and ax instead of popfd and eax

results I've gathered:

CPU Div test with all flags clear Div test with all flags set
Intel 686 0x000 0x8D5
AMD K6-II 0x010 0x811
AMD Athlon64 0x010 0x811
Cyrix Cx6x86 / M1 0x000 0x801
Emulator Div test with all flags clear Div test with all flags set
Bochs 0x000 0x8D5
Qemu (without kqemu) 0x000 0x8D5

Still looking for information on the 386 and 486 generation...

Bochs messages

A list of messages and likely causes:

interrupt(): gate descriptor is not valid sys seg

You have not loaded an IDT, or the IDT is corrupt

interrupt(): SS selector null
  • You have no TSS
  • You haven't set SS0 / ESP0 in the TSS

HPPA

That big noisy RISC machine from HP. Oh well. Needs some patching to get a elf toolchain built.

apparently there are two file formats at work here: ELF and SOM. if you mix up those two you get no end of assembly messages (unknown pseudo-op .nsubspa etc). the following got me a successfully built gcc. I have not tested its actual operations for sanity. Just doccing it here so I can reproduce the results on a computer that's closer to my HPPA machine.

add to gcc/config.gcc

hppa-*-elf*)
	target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS"
	tm_file="${tm_file} pa/pa32-regs.h dbxelf.h elfos.h pa/elf.h \
		 pa/pa-pro-end.h libgloss.h"
	tmake_file="pa/t-pro"
	use_collect2=yes
	gas=yes
	;;

run

export PREFIX=/usr/cross
export TARGET=hppa-elf
mkdir build-gcc-hppa
mkdir build-binutils-hppa
cd build-binutils-hppa
../binutils-x.x/configure --target=$TARGET --prefix=$PREFIX --disable-nls
make
make install
cd ..
export PATH=$PATH:/usr/cross/bin
cd build-gcc-hppa
../gcc-x.x.x/configure --target=$TARGET --prefix=$PREFIX --without-headers
            --disable-nls --with-newlib --enable-languages=c
make all-gcc
make install-gcc

works with binutils 2.17/gcc 4.2.2 fails on binutils 2.17/gcc 4.1.1

The 15 minutes spent trying to get palo (the opensource bootloader used with linux) to compile resulted in an asm error in crt0.s and several missing system headers (guess what, PA-RISC + LILO = PALO. linux.h missing. d'oh).

And that was one step out of the many that need be taken...