can't re-enter realmode

[DennisCGc]

jmp word segment:offset
like(if CS=0) then do:

Code: Select all

jmp word 0:real_mode

You should do that to flush the queue.

[ich_will]

if I write

Code: Select all

jmp word 0:real_mode

ld prints out:

__shutdown.o(.text+0x1e):__shutdown.o: relocation truncated to fit: 16 .text

is there something wrong in my linker skript?

[Candy]

ld prints out:

__shutdown.o(.text+0x1e):__shutdown.o: relocation truncated to fit: 16 .text

ld doesn't do 16-bit relocations. Now you're in a tough situation, but at least it's the good situation.

Other side of the summary, I personally think LD does do 16-bit relocations, but you relocate above 0xFFFF, which doesn't fit. If your segment (real-mode) ends in 000, the truncation doesn't matter. For instance, if this code is at 0x20000, the relocation would go to 0x20357, which is now truncated to 0x0357 because the 2 cannot fit in. Since you jump to 0x357:0x2000, you do get the right place. That's truncating.

[ich_will]

what should / could i do? should i convert the address of the jumpmark: real_mode, to a splittet address? Do you have a complete sample code how I can return to real mode in this situation?

[Candy]

what should / could i do? should i convert the address of the jumpmark: real_mode, to a splittet address? Do you have a complete sample code how I can return to real mode in this situation?

You're doing the right thing. The only thing is that you try to jump outside of the 16-bit realmode segment you can jump to, and LD indicates that it kicks out the upper part of the offset. If your link & load address(es) are on 64k boundaries, you are all set, but LD complains that it is still losing the top half. You can load the code to 0x0000???? where LD would not lose anything. I /THINK/ that fixes it.

[DennisCGc]

And Candy, could he use inline assembly, or not ?
He could use (because he's in p.mode) the 66h prefix, or am I missing something ?
(I don't know the code, but I THINK it works)

[ich_will]

that means if my kernel is loaded to 0x100000 than i've to load this few functions to an address between 0x0000 and 0xFFFF and jump to this address. am I right?

[ich_will]

I wrote:

ld prints out:

__shutdown.o(.text+0x1e):__shutdown.o: relocation truncated to fit: 16 .text

(ld don't link my kernel!!)

if I jump like this:

jmp word 0:real_mode

then I try all this in a single asm file (as bootloader):

1. enter pmode using my standart GDT(bootloader)
2. do some pmode operations
3. re-enter real_mode like I try it in my shutdown function.

and all works. The problem is how can I link my function in the kernel?

[Pype.Clicker]

if your 16 bits code is self-sufficient, i suggest you assemble it apart as a binary file and then include raw bits of it at the proper place in your kernel (that must be the %incbin directive of nasm, or something alike

[ich_will]

it seems that nasm have no %incbin directive.
i'm using version 0.98.38

[Pype.Clicker]

3.2 Pseudo-Instructions

Pseudo-instructions are things which, though not real x86 machine instructions, are used in the instruction field anyway because that's the most convenient place to put them. The current pseudo-instructions are DB, DW, DD, DQ and DT, their uninitialised counterparts RESB, RESW, RESD, RESQ and REST, the INCBIN command, the EQU command, and the TIMES prefix.

http://alien.dowling.edu/~rohit/nasmdoc3.html

[ich_will]

but without %

[Pype.Clicker]

hence the "or something alike" ;D

[ich_will]

if I call shutdown now Bochs prints:

Code: Select all

00027693929e[VGA  ] unsupported io write to port 0x03d6, val=0x00
00027693941i[CPU  ] BxError: instruction with op1=0xfe
00027693941i[CPU  ] nnn was 4

then whithout ending before I press power button (only the number at the beginning changes:

Code: Select all

00027693941i[CPU  ] WARNING: Encountered an unknown instruction (signalling illegal instruction):
00027707455i[CPU  ] BxError: instruction with op1=0xff
00027707455i[CPU  ] nnn was 7

after I press the power button bochs prints:

Code: Select all

00033179500i[CPU  ] real mode
00033179500i[CPU  ] CS.d_b = 16 bit <------------------  :D
00033179500i[CPU  ] SS.d_b = 32 bit
00033179500i[CPU  ] | EAX=60000000  EBX=0000f9dd  ECX=0000f4eb  EDX=0000056a
00033179500i[CPU  ] | ESP=0000e36d  EBP=00000739  ESI=0000f7f5  EDI=00000660
00033179500i[CPU  ] | IOPL=0 NV UP DI PL ZR NA PE NC
00033179500i[CPU  ] | SEG selector     base    limit G D
00033179500i[CPU  ] | SEG sltr(index|ti|rpl)     base    limit G D
00033179500i[CPU  ] |  DS:0010( 0002| 0|  0) 00000000 0000ffff 1 1
00033179500i[CPU  ] |  ES:0010( 0002| 0|  0) 00000000 0000ffff 1 1
00033179500i[CPU  ] |  FS:0008( 0001| 0|  0) 00000000 0000ffff 1 1
00033179500i[CPU  ] |  GS:0008( 0001| 0|  0) 00000000 0000ffff 1 1
00033179500i[CPU  ] |  SS:0010( 0002| 0|  0) 00000000 0000ffff 1 1
00033179500i[CPU  ] |  CS:0018( 0003| 0|  0) 00000180 0000ffff 0 0 <-------  ???
00033179500i[CPU  ] | EIP=00007213 (00007213)
00033179500i[CPU  ] | CR0=0x60000010 CR1=0x00000000 CR2=0x00000000
00033179500i[CPU  ] | CR3=0x00000000 CR4=0x00000000
00033179500i[     ] restoring default signal behavior
00033179500i[CTRL ] quit_sim called with exit code 1

[DennisCGc]

Hmm, be sure you jump correctly, because it's assigned to 0x18.
And for some reason the base is 0x180, why that ?
Do you change your IDT ? (supposed to be a GDT)
And please be sure you change the SS and SP (which isn't done by you )
<edit: There's a fault here, post the right answer /edit>