Higher Half Kernel not working with Meaty Skeleton

[Bowlslaw]

Hello, I am new to osdev and am running into a problem that I do not understand.

When I use the code from this article: https://wiki.osdev.org/User:Glauxosdeve ... Bare_Bones

I copy it as the kernel., boot.S, and yes, I also change the video memory address to the correct address as defined in the Glauxosdever code.

However, when I try to run ./qemu script, the kernel seems to start up. I see the grub menu and select “myos”. However, it appears to load for around one second and then goes back to the GRUB boot menu.

Are there any known compatibility issues with Higher Half and meaty skeleton?

I can run both higher half and meaty skeleton individually just find.

[pat]

You're going to need to provide more information for people to help.

However, when I try to run ./qemu script, the kernel seems to start up. I see the grub menu and select “myos”. However, it appears to load for around one second and then goes back to the GRUB boot menu.

This sounds like a triple fault. You should modify your qemu script and add the following args: -s -no-reboot -no-shutdown. Then you can connect with gdb with "target remote localhost:1234". Add a breakpoint to _start, and start single stepping until something breaks.

[Bowlslaw]

You're going to need to provide more information for people to help.

However, when I try to run ./qemu script, the kernel seems to start up. I see the grub menu and select “myos”. However, it appears to load for around one second and then goes back to the GRUB boot menu.

This sounds like a triple fault. You should modify your qemu script and add the following args: -s -no-reboot -no-shutdown. Then you can connect with gdb with "target remote localhost:1234". Add a breakpoint to _start, and start single stepping until something breaks.

Thank you! I was not aware that I could do this. I read about the “triple fault” and it, typically, causes the CPU to reset?

Cool debug tip. I will make note of this and try to debug myself.

[pat]

Thank you! I was not aware that I could do this. I read about the “triple fault” and it, typically, causes the CPU to reset?

Yeah, basically at that point all hope is lost and the CPU commits sudoku and restarts. You can't recover from it, but you can stop QEMU from restarting to give yourself an opportunity to figure out what's going on.

[glauxosdever]

Hi,


Some time ago, a contributor to that page made some changes in the code, mostly make it easier for a beginner to understand it, use more descriptive symbols and align the code style to the regular Bare Bones. However, he overlooked that "boot_page_table1" was not defined (boot_pagetab1 was defined instead), so you maybe confused it with "boot_page_directory" or something. After these changes, it works for me. I also updated the page accordingly.


Regards,
glauxosdever

[Bowlslaw]

Hi,


Some time ago, a contributor to that page made some changes in the code, mostly make it easier for a beginner to understand it, use more descriptive symbols and align the code style to the regular Bare Bones. However, he overlooked that "boot_page_table1" was not defined (boot_pagetab1 was defined instead), so you maybe confused it with "boot_page_directory" or something. After these changes, it works for me. I also updated the page accordingly.


Regards,
glauxosdever

Thanks. I did notice that issue in the code and changed it just as you did, yesterday, but I am still receiving the same apparent triple fault. I haven't had time to debug as pat mentioned, though.

EDIT: Maybe it's something with my qemu or something.

[MichaelPetch]

It works for me. Do you have a copy of your ISO image available somewhere that I can download and try out? With your ISO I can try out what you have built to see why it may be failing. What is the command(s) inside of your shell scripts that launch QEMU.

Also be curious what Distribution/OS/Version you are using to build the kernel.

[Bowlslaw]

Ok, I figured it out.

After a while, I noticed that the only real difference was how the memory address of the VGA text buffer was set.

In 'Meaty Skeleton', it is like this:

Code: Select all

static uint16_t *const VGA_MEMORY = (uint16_t *)0xC03FF000;

...

terminal_initialize(void) {
    ...
    terminal_buffer = VGA_MEMORY;
    ...
}

This kills the crab, er, OS.

However, I was able to get it to my by simply changing the definition of 'terminal_buffer' to the address itself, without an intermediate varable, like this:

Code: Select all

terminal_buffer = (uint16_t *)0xC03FF000;

The only difference I can see is that the code that works does not have the 'const' modifier. Does anyoen know why this is?

EDIT: AH, I got it. I simply had incorrect syntax for where I placed my '*' operator.

I accidentally made it so the VGA_MEMORY was unchangeable, heh, what a noob error on my part.

I also had code in my kernel which intentionally tried to scroll offscreen so that I could test my scrolling, but, when removed, stopped causing the crash as well.

[MichaelPetch]

This sounds like a side effect of some other problem. Have you added some other code (besides the video change) or made other changes that diverge from what is in the tutorial?Are you compiling/assembling/linking the kernel with the same commands as the tutorialor have youdone things differently?

[Bowlslaw]

This sounds like aside effect of some other problem. Have you added some other code or made other changes that diverge from what is in the tutorial?

Would changing some of the libc functions, like memcpy, to use pointers, insead of arrays, do it?

[MichaelPetch]

Would changing some of the libc functions, like memcpy, to use pointers, insead of arrays, do it?

Could well be a problem if you introduced bugs. It sounds like you have added other code to this project other than what is in the tutorial you linked to. You really should consider putting your whole project on something like github/gitlab or some other service so we can take a look at it. Sounds like the issue may not be the code in the skeleton but something else that has been done beyond that.

[Bowlslaw]

Would changing some of the libc functions, like memcpy, to use pointers, insead of arrays, do it?

Could well be a problem if you introduced bugs. It sounds like you have added other code to this project other than what is in the tutorial you linked to. You really should consider putting your whole project on something like github/gitlab or some other service so we can take a look at it. Sounds like the issue may not be the code in the skeleton but something else that has been done beyond that.

I have changed some. But, I did change it to be a copy of the tutorial. Once I changed the boot.S, linker.ld, and vga address, it works fine, UNTIL I try to scroll offscreen.

https://github.com/Bowlslaw/slawOS/tree/revamp

I have made changes to the 'terminal_putchar(char c)' function in order to test scrolling. The thing that confuses me is that this bug did not exist with meaty skeleton's default tutorial code. It only started crashing once I added the alternate higher half code.

[Bowlslaw]

Ok, I hooked up the kernel to GDB like this:

Code: Select all

./build.sh
qemu-system-i386 -cdrom myos.iso -s -no-reboot -no-shutdown
gdb sysroot/boot/myos.kernel
gdb> target remote localhost:1234

I then 's' through the code, until I reach these values:

Code: Select all

0xc0100179 <_start+36>  mov    %edx,(%edi)

Where it proceeds to crash with SIGSEGV. It seems like it crashes the moment it hits _start.

I'm just trying test scrolling, and so the changes I made to tty.c are on lines 48 and 62 in the repo.

[MichaelPetch]

My apologies, I misread one of your updates and I thought you got it working somehow. Is Github updated with what you are now testing?

[Bowlslaw]

My apologies, I misread one of your updates and I thought you got it working somehow. Is Github updated with what you are now testing?

Yes, but at this moment I think I figured it out. In the repo I linked, look at (https://github.com/Bowlslaw/slawOS/blob ... /tty.c#L62), line 62-72. I removed this, and the problem vanished, even when I get the for loop in kernel.c to way beyond the VGA_WIDTH/HEIGHT.

I was getting a SIGSEGV, so...I think I was trying to write colors to areas outside of the VGA buffer?