can't re-enter realmode

[ich_will]

I don't know? I simply halt after the jump.

Do you change your IDT ?

before or after the jump?
i set it up in my kernel, yes.

[DennisCGc]

Oops :-[ :-[
I mean GDT

[ich_will]

no

[Pype.Clicker]

probably you should try to locate where that EIP is first ... IIrc, you managed to return to real mode, right ? so the very first thing you should do there is reloading realmode values to every data segment ... or strange things could occur.

[ich_will]

also if i just halt?

[ich_will]

my code(perhaps it might help):

Code: Select all

;---------- _shutdown.asm ----------
[BITS 32]
[global __shutdown]
[global __shutdownend]

__shutdown:
   incbin 'shutdown.bin'
__shutdownend:

;------------------ shutdown.asm ------------
[BITS 32]
        cli      ; disable interrupts

   ;------ clear the PG bit ------
   mov eax, cr0
   xor eax, 0x80000000
   mov cr0, eax

   ;------ clear the paging cache ------
   xor eax, eax
   mov cr3, eax

   ;------ clear the PE bit ------   
   mov eax, cr0
   xor eax, 1
   mov cr0, eax

   ;------ do a far jump to a 16-bit code segment ------
   jmp word 0x00:real_mode
[BITS 16]
    real_mode:
   xor ax,ax
   mov ds, ax
   mov es, ax
   mov fs, ax
   mov gs, ax

   mov ax, 0x9000
   mov ss, ax
   mov esp, 0x8000

   hlt
   jmp $-1

[Pype.Clicker]

well, if it's just for a "hlt" loop, you don't need to switch to realmode at all !
does the previously submitted bochs panic come from that very code ? it looks like you tried to reload CS with 16_BITS_SELECTOR while you were already in realmode, which made the base loaded with 0x18 (assumed to be 16BITS) * 16 ...

are you calling "shutdown" or "shutdownend" ? what does the piece of code located in "shutdown.bin" exactly do ? is it real mode or pmode ?

if it's realmode, why not having it included right after pmode is restored, instead of ahead the 32 bits part ?

[ich_will]

well, if it's just for a "hlt" loop, you don't need to switch to realmode at all !

i know, but I want to get this working first, then make the other things (call in 0x15)

does the previously submitted bochs panic come from that very code ?

not realy, directly after real_mode stands only hlt in the old code, but i try that what you say. (so the very first thing you should do there is reloading realmode values to every data segment )

are you calling "shutdown" or "shutdownend" ?

i call shutdown

what does the piece of code located in "shutdown.bin" exactly do

see above (shutdown.asm), the code mark includes two files.

[Candy]

can you send me a tarball of your bochs test image+config ? I'll go for a check in a debugging-mode bochs

ps, can you include a map of the kernel?

[Pype.Clicker]

hmm ... agree. What may cause troubles here is that the 'jmp 00:realmode within shutdown.asm is actually assembled as an 'absolute' jump, but it doesn't know the 'correct' address of the target as that is relative to the location of the kernel in memory and the location of shutdown in the kernel.

If those two things were known, you could simply issue an "ORG" directive to patch the offset manually ...

a more clever way to handle it is to define the jump target at runtime:

Code: Select all

;; --- new shutdown.asm ---
[BITS 32]
[ORG 0]
       call tell_location
adjust:
       add word [jump+1],dx
       cli      ; disable interrupts

   ;------ clear the PG bit ------
   mov eax, cr0
   and eax, 0x7FFFFFFF
   mov cr0, eax

   ;------ clear the PE bit ------   
   mov eax, cr0
   and al,0xFE
   mov cr0, eax

   ;------ do a far jump to a 16-bit code segment ------
jump:
   jmp word 0x00:real_mode

; the run-time address of 'adjust' is now on the top of the stack [esp]
; we just retrieve it and substract the offset of adjust in the file to get
; the run-time address of the file itself.
tell_location:
   mov edx,[esp]
   sub edx,adjust
   ret


[BITS 16]
    real_mode:
   xor ax,ax
   mov ds, ax
   mov es, ax
   mov fs, ax
   mov gs, ax

   mov ax, 0x9000
   mov ss, ax
   mov esp, 0x8000

   hlt
   jmp $-1

Note that this has a flaw: the 'jump word 0x00:realmode' contains a 16 bits offset while nothing guarantees (unless we take care of it somewhere else) that the 'run-time' address of the code will be within the first 64KB of the system.

That's precisely the kind of things your linker was complaining about ...

Fortunately enough, with the run-time trick we used, it's now possible to move the shutdown code into the first 64KB just before you summon it. 'tell_location' will reveal the correct place and will perform the adjustments to the code at will

The 'mov cr0,eax' enforces pipeline to wait, so we shouldn't require an additionnal jump (to force the now-changed instructions to be reinterpreted)

[ich_will]

the same problem again! Also if I copy my function to 0x500
and jump there.

can you send me a tarball of your bochs test image+config ?

whats a tarball?

if send an memory map and a floppy image (cut after the kernel works), the first 512 byte is my bootloader. its my newest. but the error is like the first.

[attachment deleted by admin]

[distantvoices]

a tarball is that kind of archive we unixers use to exchange/store data. It is usually a file with the ending *.tar.gz, created with the program tar and filtered throu' the program gzip.

I don't know exactly by heart but you 'd say

tar -cz directory>tarballname.tar.gz

I'm used to tar -cj directory>tarballname.tar.bz2.

I reckon you better do a google search for "tar" or issue "man tar" at your favourite command line shell.

[ich_will]

I know how to create a .tar.gz, thanks. but i don't know that a tarball is a .tar.gz archive.

[ich_will]

@Candy: i've send it to your mail address: [email protected].

why can't i load up .tar.gz files, isn't it a often used file format?

[distantvoices]

@ich_will: your question permits the special assumption preceding the act of explaining.

[sorta candybot - not a sweet one] tarballs are widely used. f. ex. The actual source code of the linux kernel you retrieve as a *.tar.gz from kernel.org. *gg*