Jump into protected mode is fail[solved]

[Klakap]

Thank you! I try start os.img in Bochs and output is:

Code: Select all

(0).[44978685] [0x0000000000011038] 0008:0000000000011038 (unk. ctxt): (invalid)                 ; ffff
Next at t=44978686
(0) [0x00000000fffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0

[MichaelPetch]

That doesn't tell me much. anything could have happened. It seems you are in protected mode since 0x8:0x11038 suggests the CS selector was set and it was executing code there. The output only suggests it may have run into invalid instruction of some sort. I'd set a breakpoint in BOCHs at 0x100000 and then start stepping through the code. Does it appear it is running your kernel code at all?

If you want someone to look at your project, put it on github or gitlab (or any similar service). Then we can actually look at it in its entirety and test it out.

[Klakap]

No, kernel isn`t start. Fail is with jump. Kernel hasn`t error. Please how I can start debug mode in bochs?

[MichaelPetch]

The JUMP didn't fail. It is clear that the JUMP worked or you wouldn't have even been at 0x11038. Again you are going to get no help without showing your kernel code, how you build it,and how you create your OS disk image. There are only 2 things that will have failed and I will repeat them: either the kernel was not read into memory and you started executing garbage starting at 0x10000 (and finally died at 0x11038) or there is a bug in your kernel.

[MichaelPetch]

Without the source to the kernel the only recommendation I have is emailing a copy of your OS's disk image (os.img) to me at [email protected] . I might be able to discover something or at a minimum determine if the kernel is read into memory or not and whether the jump was successful (which at this point I believe is the case)

[BenLunt]

Hi,

I'm with Michael here. I think your jump is successful, but you have garbage afterward, a wrong offset via the jump, or other.

No, kernel isn`t start. Fail is with jump. Kernel hasn`t error. Please how I can start debug mode in bochs?

The Bochs debugger is a great tool. However, you have to have Bochs compiled with the debugger compiled in, usually called BOCHSDBG.EXE on windows. Couldn't tell you on Linux.

Then tell Bochs to use the debugger via your bochsrc.txt file:

Code: Select all

#=======================================================================
# DISPLAY_LIBRARY
#
# The display library is the code that displays the Bochs VGA screen.  Bochs 
# has a selection of about 10 different display library implementations for 
# different platforms.  If you run configure with multiple --with-* options, 
# the display_library command lets you choose which one you want to run with.
# If you do not write a display_library line, Bochs will choose a default for
# you.
#
# The choices are: 
#   x              use X windows interface, cross platform
#   win32          use native win32 libraries
#   carbon         use Carbon library (for MacOS X)
#   macintosh      use MacOS pre-10
#   amigaos        use native AmigaOS libraries
#   sdl            use SDL library, cross platform
#   svga           use SVGALIB library for Linux, allows graphics without X11
#   term           text only, uses curses/ncurses library, cross platform
#   rfb            provides an interface to AT&T's VNC viewer, cross platform
#   wx             use wxWidgets library, cross platform
#   nogui          no display at all
#
# NOTE: if you use the "wx" configuration interface, you must also use
# the "wx" display library.
#
# Specific options:
# Some display libraries now support specific option to control their
# behaviour. See the examples below for currently supported options.
#=======================================================================
#display_library: amigaos
#display_library: carbon
#display_library: macintosh
#display_library: nogui
#display_library: rfb, options="timeout=60" # time to wait for client
#display_library: sdl, options="fullscreen" # startup in fullscreen mode
#display_library: term
 display_library: win32, options="gui_debug" # use Win32 debugger gui
#display_library: wx
#display_library: x, options="hideIPS" # disable IPS output in status bar
#display_library: x, options="gui_debug" # use GTK debugger gui

For Windows, I use the one above that is not commented. The one for 'win32'.

You can also tell the debugger to stop at the

Code: Select all

  xchg  bx,bx

instruction. However, please note that it also depends on which mode you are in. If you are in pmode (32-bit register defaults), that instruction will not break. You must use

Code: Select all

  xchg  ebx,ebx

At the same time, if you use the 'ebx' version in real mode (16-bit register defaults), it will not break. You need to use the form for the current mode you are in.

To get it to break at that instruction, use:

Code: Select all

#=======================================================================
# MAGIC_BREAK:
# This enables the "magic breakpoint" feature when using the debugger.
# The useless cpu instruction XCHG BX, BX causes Bochs to enter the
# debugger mode. This might be useful for software development.
#
# Example:
#   magic_break: enabled=1
#=======================================================================
magic_break: enabled=1

I remembered that I had a small tutorial on this and had to go find it. It is at http://www.fysnet.net/bochsdbg/index.htm

Ben
- http://www.fysnet.net/osdesign_book_series.htm

[Klakap]

Thank you! I found one error. I forget delete grub multiboot header from kernel . But Bochs and Qemu still isn`t start my os. Please where is bug? Here is my code from bootloader for loading:

Code: Select all

  ;LOAD KERNEL
  ;reset floppy
  mov ah, 0
  mov dl, 0
  int 13h  ;call reset

  ;read floppy
  mov ax, 1000h  ;load kernel to 1000h
  mov es, ax  ;load kernel to 1000h
  mov bx, 0  ;offset 0 

  mov ah, 0x02  ;read function
    mov al, 100  ;100 sectors
    mov ch, 0  ;track 0
    mov cl, 2  ;start sector is 2
    mov dh, 0  ;head 0
    mov dl, 00h  ;floppy A

  int 13h  ;call read

and code from kernel:

Code: Select all

bits 32

;some definitions of methods

start:
  call boot
  jmp $   ;halt the CPU

;methods for interrupts

section .bss
resb 64000		;64KB for stack
stack_space:

[MichaelPetch]

Any chance you can just email os.img to [email protected] (and/or [email protected]). Even without the source I should be able to identify the problem.

[Klakap]

I was send you os.img

[MichaelPetch]

I sent you this email (and attachment):

What I can confirm to you is that you
are properly getting into protected and your JMP 0x10000 is actually
working. In my OSDev posts to you I said I did expect JMP 0x10000 and
that is the case.

In one of my posts I had informed you that reading 100 sectors may not
work. That is the case on BOCHs and QEMU. The maximum you can read is 72
at a time (on real hardware it may even be less). In your code you have
have:

mov al, 100

Change it to:

mov al, 72

Now you may say your kernel is larger than 72 sectors. That is true, but
for test purposes at least use 72.

There are a number of issues with the KERNEL you placed in the image
starting in the sector after the bootloader. You are placing a 32-bit
ELF executable directly in the file. You need to convert it from ELF to
binary before placing it on disk.

I don't know your file names or anything like that but you will have to
do something like:

objcopy -Obinary kernel.bin kernel.bin

kernel.bin is the name of your kernel file that you are currently
placing on disk. This command converts the file kernel.bin from ELF to
binary and placing the result over top of kernel.bin. Do this before
placing the kernel on the disk image.

This isn't going to solve all your problems because I can tell there are
other issues with how you make your kernel that will cause all kinds of
problems, but making these simple changes should see you getting your
kernel to print stuff out before crashing and rebooting.

I made these changes directly to your os.img (without the source code)
and made the attached os.img . If you run it in qemu booting from floppy
drive a with:

qemu-system-i386 -fda os.img

You should find that your kernel briefly displays output and the
crashes/reboots. If you make the change to your bootloader and convert
the ELF file to binary you should get this far as well. Once you get
that far I can tell you other problems with how you build the kernel
itself that will cause issues.

What would be helpful though is for you to show me the commands you use
to build your kernel alongside a linker script if you use one. If your
commands are in a shell script show me that, or if you use Makefiles
show us the Makefiles.

Among other things I saw is your ELF executable has a VMA of 0x100000
and you are loading into physical memory at 0x10000 (you have one too
many zeroes). You are also not using a cross compiler so I noticed you
have position independent code/You will want to compile your C code with
the option -fno-PIC . It has me wondering if you passed a special
command to the linker to suppress any GOT ADDRESS errors to link your
kernel? This is the reason why I'm asking for the build/compile/assemble
commands. One other peculiarity was that there is a section called:

//.text

Almost like you created a section somewhere with the C++ comment
characters //. Did you accidentally do that somewhere in a linker script
or an assembly file?