Help! Reboots after "OR AL,1 MOV CR0, EAX" on some computers.

Help! Reboots after "OR AL,1 MOV CR0, EAX" on some computers.

Hi. I need some help. I think you'll be interested. I develop a little OS
that will boot from floppy. It's still under construction and has about
five thousand lines of assembly source now. I use Bochs emulator to debug
it and after that I test it on my real computer. I have all working
correctly on my compter. But I started to test it around other machines
recently and encountered a problem I can't solve. I can't figure out what
happens because on my computer I get all things well, but I can't conduct
test of this kind on other computers.

Here is the problem. My OS's boot loader (after loading the main module)
switches CPU to very limited protected mode and jumps to module's entry
point. After it, main module reloads all tables like GDT etc to make a
good free environment for initialization and further running. Shortly: ON
SOME COMPUTERS (MAYBE CPUS) I GET REBOOTING JUST ON 'JMP' INSTRUCTION
AFTER PE BIT IS ENABLED. I've got no reboots on all i386, i486, i586
computers that I tryed to boot from. I have a Pentium III Celeron
(Coppermine) 900MHz - no reboots. Also tested on some Pentium II 400MHz -
no reboots. But on other side Pentium IV (don't remember speed) gave me a
reboot. And other computer I was not able to see processor model (maybe
PentiumIV !?) gave me a reboot too. Using endless loop stop points I
figured out that reboot is before any instruction pointed by 'protected'
label and that reboot happens after setting the PE bit.

Here's very diminished boot sector code that reflects the error. It must
be compiled with nasm as a binary so that result will be a floppy disk
image file. Then it must be written to a floppy from scratch (from boot
sector). Created floppy is expected to be bootable disk.

Normal:
When you boot from the floppy you get something like black screen and
computer hangs up (but not reboots)

Abnormal:
When you boot from the floppy you get a screen splash and then back to
reboot POST procedure.

Here goes the code. PLEASE, even if you're not interested in this
'puzzle':( MAKE AND TEST IT ON YOUR COMPUTER. EMAIL ME RESULTS AND
COMPUTER MODEL.

It was HARD work to make this OS. I believe that some people understand me
and will give me a clue. From my side I'll show them the full version.

;---------------------------------------------------------------------

; Compile: %nasm thisfile.asm -o fd
; Insert a floppy
; Write (as root): #dd if=fd of=/dev/fd0

org 0x7C00 ; Expecting to be loaded at 7C00 by BIOS

bits 16

real:
cli
xor ax, ax
mov ss, ax
mov sp, 0x7C00 ; Temp stack just under myself

call real_open_A20 ; For 32 bit address space
call real_init_gdt ; Load GDTR

mov eax, cr0
or al, 0x1 ; cr0 |= PE
mov cr0, eax
; If I place 'jmp $' here all computers stop here normally
jmp 0x10: protected

real_open_A20:
.l1: in al, 0x64
test al, 0x2
jnz .l1
mov al, 0xD1
out 0x64, al
.l2: in al, 0x64
test al, 0x2
jnz .l2
mov al, 0xDF
out 0x60, al
ret

real_init_gdt:
lgdt [.gdtr]
ret
.gdt0 dw 0x0000, 0x0000, 0x0000, 0x0000
.data dw 0xFFFF, 0x0000, 0x9200, 0x00CF
.code dw 0xFFFF, 0x0000, 0x9800, 0x00CF
.gdtr dw $ - .gdt0 - 1
dd .gdt0

bits 32

protected:
; Wherever I place 'jmp $' after the 'protected' label,
; on some computer
s I get reboot to hell.
; (In that case CS:IP is never points to 'jmp $'
; - something happens before)
mov ax, 0x8
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax
mov esp, 0x7C00
jmp $

times 512 - 2 - ($ - $$) db 0 ; Fill the rest of sector
dw 0xAA55 ; Bootable sector sign

times 1474560 - ($ - $$) db 0 ; Fill the rest of floppy

;---------------------------------------------------------------------

Best regards,
Yuri Grebenkin
breath@unix.net

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

This inquiry may be outside the scope of what ourteam is able to support, but we will forward your inquiry to our engineering contacts and let you know how they respond.

Regards,

Lexi S.

IntelSoftware NetworkSupport

http://www.intel.com/software

Contact us

Message Edited by intel.software.network.support on 12-02-2005 08:29 PM

We spoke with our engineering contacts about this, and because of the age of the processors you are testing on, unfortunately our engineering team does not have resources available to assist with this.

If there are other forum participants reading this who are able to provide troubleshooting suggestions, we encourage you to do so.

Regards,

Lexi S.

IntelSoftware NetworkSupport

http://www.intel.com/software

Contact us

Message Edited by intel.software.network.support on 12-02-2005 08:29 PM

Login to leave a comment.