OSDev.org

Thanks for the input, man!

This is how debugging should look like: (done with OpenWatcoms debugger running on Windows XP and the target machine on a network connection)

Here is the unpatched application code with the cursor at the gate test procedure:



A single step later the code has been patched:



Now code is traced to the SYSENTER instruction:



One trace more and in kernel with a flat CS and SS selector loaded with SYSENTER:

Did you really just paste a load of screenshots of OpenWatcom's debugger in the "what does your OS look like?" thread?!

JamesM wrote:Did you really just paste a load of screenshots of OpenWatcom's debugger in the "what does your OS look like?" thread?!

Been wondering about this for a while now..

JamesM wrote:Did you really just paste a load of screenshots of OpenWatcom's debugger in the "what does your OS look like?" thread?!

It seems he did. The screenshots show his OS executing under debugger control. Surely posting them here is correct ?

JamesM wrote:Did you really just paste a load of screenshots of OpenWatcom's debugger in the "what does your OS look like?" thread?!

I could have posted the character-mode only RDOS port of OpenWatcom's debugger doing the same thing, but I didn't since the interesting issue is remote-debugging an application and it's syscalls running on RDOS. It is the contents of the debugger-windows that are interesting, not the debugger port itself.

So it does depict what the OS looks like (the debug interface) just as much as the Bochs windows we frequently see here does.

And this was done on real hardware, not in an emulator.

gerryg400 wrote:

JamesM wrote:Did you really just paste a load of screenshots of OpenWatcom's debugger in the "what does your OS look like?" thread?!

It seems he did. The screenshots show his OS executing under debugger control. Surely posting them here is correct ?

I would think so.

Actually, the OS isn't executing under a debugger. Rather a remote debug process is started in the command-shell in RDOS. Then OpenWatcom's debugger is started on Windows XP, with some special command-line parameters (-tr=tcp;x.y.z.a sysperf). The remote debug process running in RDOS will then start the debugged program for debug. The trace operations are then done in OpenWatcom, sending the commands through a TCP/IP socket to the remote debug process.

Maybe I should have posted this screen-shot as well for completeness:



It shows how the symbolic information of a device-driver in kernel (the APIC driver), is used to show the actual source code in kernel. And this occured automatically, without specifying path to source, or loading anything in the debugger. This also works for C/C++ based drivers.

Finally got around to implementing basic termios stuff and reporting ncurses and nano. Things seem to work (there are a couple as-yet unimplemented escape sequences that make things freak out if you try to use the help feature, but I'm working on that

Arrow keys work in my OS finally!

-JL

Nice job piranha!

Pure64 loaded on a Quad AMD system (16 cores per CPU) with 128GiB of RAM. The OS failed to start due to incorrect setup of the IO-APIC.

Also had to store the memory amount as a 32-bit value instead of 16 since it was only reporting 64GiB before.

-Ian

So much about my assumption that identity mapping 64GiB of physical memory would suffice to cover pretty much all of the memory and that any reasonable system wouldn't have more than 32 CPUs... Seriosuly, how much did that monster cost? And why isn't the HDD indicator showing anything? Additionally, would you mind to elaborate on what was wrong with the IO APIC setup? Anyway, nice to see you get things working on that kind of extraordinary setup.

I was only identity mapping 64GiB as well. As it takes 256KiB to map 64GiB with 2MiB pages I will need to move the PD tables somewhere else in memory. My loader should support 256 Cores as-is. Any more than that would require using the X2APIC.

The IO-APIC issue is because I only initialize the first IO-APIC I find. Unfortunately bigger machines like this have multiple IO-APICs and the interrupts are sometimes not wired 1-1. There are some ACPI tables that need to be parsed to figure out which hardware interrupt goes to which pin on which IO-APIC.

Since we have similar goals with our loaders maybe we could team up and co-operate if you are interested.

And as for the cost I have no idea. It was a SuperMicro server that I got to play with on a business trip. The HDD indicator doesn't show anything because there was no drive installed. I booted it up via PXE.

-Ian

ReaverOS (or Rose) bootloader, stage 3: Booter, version 0.2.

Version 0.1 was already kinda working before, but I decided to rewrite it completely before starting any real work on kernel. I started that rewrite at the beginning of March and just finished it (well, I wasn't working on very regular basis... ). All three stages (including first two stages for HDD loader and Booter) were rewritten, I also added VBE support in it - handicapped to 1280x720, greater resolutions given by bochs made parts of emulator window not visible on my 1600x900 screen

http://i.imgur.com/mbDYS.png - link, not to destroy the page layout with 1280p wide screenshot.

You can track my progress on Github and code statistics and analysis on Ohloh.

i have a bootloader just loading a kernel.bin.
My OS is black screen.

Just rewrite my OS for x86_64.

In this picture:
kernel @ -2GB space (-mcmodel=kernel)
- load built-in drivers (ramdisk and tablefs/my own fs with just table of content and file payload)
- load more drivers from initrd (pci, bga, rtl8139), they are compiled as ELF64 with -fPIC
- detect hardware on pci bus
- found bga
- open a file using VFS layer
- memcpy a bmp to bga's frame buffer