OSDev.org

first step on my POSIX layer for sel4

So now I've remapped the PIC to 0x20+ and 0x28+, and written a dummy handler for IRQ 0. I've got the start of a keyboard ISR, but it still has some strange bugs. I haven't implemented translations for all the scancodes yet, and shift is still lazy. The worst thing is that it only catches every other character if you type any faster than "slow." I'm not sure if I need to reconfig the keyboard or if there is an issue in my code.

The pair of dotted boxes in the picture is a backspace, but that's a separate and probably trivial issue. There's a bunch of other problems though too. The actual code I wrote for PS/2 initialization doesn't work at all, so I just don't call it. The CD-ROM drive code is also buggy, and I'm not sure why.

I'm proud of it anyway, and I'm learning a lot as I go. I'm hoping to get it on real hardware soon.

This is EggOS on normal boot:

Uh-oh!

Also the old error screen:

I haven't committed to repo for a while, but it is at https://github.com/adrian154/eggOS.

I have been working on the UI a lot lately.
Here is the skeleton of the calculator applet:



I have also made a UI toolkit, AUI.
Here is an example of the paragraph element:

I'm writing my OS in Rust (mainly because of the strict compiler, and it has a syntax I like, and so on), and I'm following Philipp Oppermann's tutorials. I'm really enjoying it so far; Rust is playing nicely and I get to finally post some nice looking output! Here's some Multiboot info:



Edit: I also made a pretty cool panic screen.

I have my kernel running on a rPi. Now I need to get to the same level as my x86 version.
I replaced the DOS stub with an ARM PE entry point finder, and taught raspbootin to recognise an MZ.

all above screenshots are cool, nice achievement, guys.
especially pleasurable for me was seeing the last one with finally something other that x86 (no offense, I like it too, but it's for later :^)). moreover - with arm. and with PE as an executable format. this is intriguing, and honestly I am lost a little. How did you get PE executables for arm targets? Does MS compilers finally allow to build free standing images for arm? what's "raspbootin" (haha, nice pun)? I have 5 armv7/armv8 target machines but it just happenned that none of them are raspberry pi. is there "uboot" on RPi?

zaval wrote:all above screenshots are cool, nice achievement, guys.
especially pleasurable for me was seeing the last one with finally something other that x86 (no offense, I like it too, but it's for later :^)). moreover - with arm. and with PE as an executable format. this is intriguing, and honestly I am lost a little. How did you get PE executables for arm targets? Does MS compilers finally allow to build free standing images for arm? what's "raspbootin" (haha, nice pun)? I have 5 armv7/armv8 target machines but it just happenned that none of them are raspberry pi. is there "uboot" on RPi?

Thanks. I've been aiming beyond x86 for some time, so I'm glad to finally get past the architecture barrier.
PE on ARM is doable - after all, WinRT sandboxed programs still use the PE format, and Microsoft are known to use in house tools to write Windows - that includes WinRT. In particular, there's actually no limitation to producing free standing images - there's a setting. Pop those in your project file under the first configuration property groups (<Debug,Release>|<ARM and ARM64 respectively>), and Bob's your uncle. I build as a native exe with 4KB file alignment - I probably should write a better PE loader.
raspbootin is referenced on the wiki - http://wiki.osdev.org/ARM_RaspberryPi#B ... ial_kernel. It's not mine, but it's great for testing by booting over serial. It did take some love and care to make it work on the raspberry pi 2 - I commented out the model detection code (maybe a mistake), and disabled the UART init code, since it seemed to give garbage otherwise. The firmware puts the UART in a good state. I'm not too bothered about making my testing tool correct, but I'm going to be working on that same issue with the kernel, I think. I don't know about uboot, I'd imagine there is. I've just been working towards the Pi's default bootloader (raspbootin is transparent). The one issue is that the default bootloader won't recognise an MZ - but it shouldn't be too hard to find some neutral values for the header that are non-destructive of r0-r2. The signature is the only important thing, since MS LINK checks it. As it is, it works out as Which isn't an issue.

Here's mine



work in progress, but its fun

https://os64.blogspot.com/

I've been inactive recently because I was working on a major project overhaul.
I decided to get rid of GRUB and make a custom bootloader and that is what I did.
With no tutorials to follow (intentionally because they are excuse my words crap) and fragile Assembly knowledge (catching up with it along the way) I managed to pull it off.
This is one of the and maybe even the most inspiring things I've done since I started OS deving. It might be basic and it is, but it gets the job done. It is only the beginning, I still have lots of things to do (stage 2 etc).
The last message that say insert floppy blah blah is just a standard DOS VBR so ignore it, no floppies only HDDs.
Also I started using GitLab and I would recommend it to everybody. It has private repositories and it is free.

The first time I got a desktop image for my operating system.

I was working on my page allocator ... and i now i have pages enough for that.

This is how my operating system is looking like.

Here i'm working on my page allocator ... and testing the allocated space with some bmp file.

My second OS project, quack. This time I started by first making a physical memory manager, a virtual memory manager, and a small kernel heap.
I know, the name is very creative

It took me multiple attempts since registering here almost 6 years ago, but I finally got something to show.

The kernel is written in D (and compiled with -betterC), and the bootloader has a naive implementation to load an ELF image (the kernel). I'm currently implementing a proper VGA terminal and writing unit tests for it.