OSDev.org

Hello everybody,

I'm pleased to announce the release of Fiwix kernel v0.9.0 (almost self-hosting).

Fiwix is an operating system kernel written from scratch by me, based on the UNIX architecture and fully focused on being POSIX compatible. All my efforts have been focused on kernel only, I pretend to use GNU applications (mostly) for the user space. It runs on the 32-bit x86 hardware platform and is compatible with a good base of existing GNU applications.

Download the live floppy image and play with it. And if you feel the floppy image is not enough to have a good experience, please, download the live hard disk Minix v1 filesystem (200MB) from the Fiwix web site.

I plan to put the Fiwix kernel source code in Github when it reaches the 1.0 version (self-hosting).
Keep in mind that it is in its early stages, no network, no USB, no PCI ... it's just a hobby OS, so please, don't be so hard with it!

Features
Mostly written in C language (Assembler only used in the needed parts).
GRUB Multiboot Specification v1 compliant.
Full 32bit protected mode non-preemptive kernel.
For Intel 80386 processors and higher.
Preemptive multitasking.
Protected task environment (independent memory address per process).
Interrupt and exception handling.
POSIX-compliant (mostly).
Process groups, sessions and job control.
Interprocess communication with pipes and signals.
BSD file locking mechanism (POSIX restricted to whole file and advisory only).
Virtual memory management up to 4GB (no swapping yet).
Demand paging with Copy-On-Write feature.
Linux 2.0 ABI system calls compatibility (mostly).
ELF-386 executable format support (statically and dynamically linked).
Round Robin based scheduler algorithm (no priorities yet).
VFS abstraction layer.
Minix v1 filesystem support.
Linux EXT2 filesystem support (read only) with 1KB, 2KB and 4KB block sizes.
Linux PROC filesystem support.
PIPE pseudo-filesystem support.
ISO9660 filesystem support with Rock Ridge extensions.
RAMdisk device support.
SVGAlib based applications support.
Keyboard driver with Linux keymaps support.
Parallel port printer driver support.
Floppy disk device driver and DMA management.
IDE/ATA hard disk device driver.
IDE/ATA ATAPI CDROM device driver.

Minimum Hardware Requirements
Standard PC-AT ISA architecture.
x86 32bit processors (i386 and higher).
2MB of RAM memory.
Floppy disk (3.5", 1.44MB).

For more information go to http://www.fiwix.org
Thanks!

I tried it on a 386. It got stuck here.



It looks like this is where you configure the keyboard. If I reboot this machine, the keyboard remains unresponsive until the BIOS resets it. On other machines, I see the keyboard reset here.

I tried it on a different 386 and it works fine, though it does spend a long time trying to detect the (dead) hard disk.

Thanks a lot for your feedback!

Octocontrabass wrote:I tried it on a 386. It got stuck here.

It looks like this is where you configure the keyboard. If I reboot this machine, the keyboard remains unresponsive until the BIOS resets it. On other machines, I see the keyboard reset here.

You're right, this is where I reset the keyboard. I've seen this problem only in some keyboards connected to a KVM switch. Just press any dead key (shift, control or whatever) and you should see it working.

Octocontrabass wrote:I tried it on a different 386 and it works fine, though it does spend a long time trying to detect the (dead) hard disk.

Yes, the IDE drive detection is pretty slow in very old systems.

Mikaku wrote:I've seen this problem only in some keyboards connected to a KVM switch.

There's no KVM here, just an old keyboard connected to an even older PC.

Mikaku wrote:Just press any dead key (shift, control or whatever) and you should see it working.

I've tried that (and many other keys as well), but it remains frozen.

OK, let's try to fix it since it seems you are able to reproduce this all the time. In my case this problem comes only from time to time, so it makes it harder to fix it.

Unfortunately I'm unable to send you a patched binary kernel because (even compressed) it takes 90KiB, and the maximum allowed size in the attachment is 64KiB. So, please send me an email (taking my address from the Fiwix web site) and I'll reply you with the kernel patched.

Thanks!

can it output svga?

Mikaku wrote:OK, let's try to fix it since it seems you are able to reproduce this all the time.

It looks like you aren't waiting for the keyboard controller's input and output buffers correctly. In your keyboard_wait() function, you're checking the input buffer status but emptying the output buffer. I patched it to check the output buffer status and it seems to work now, but I'm not sure if that's the intended behavior. There might also be other issues with it that I haven't found.

Mikaku wrote:Unfortunately I'm unable to send you a patched binary kernel because (even compressed) it takes 90KiB, and the maximum allowed size in the attachment is 64KiB.

Couldn't you upload it to your website? (I'd appreciate complete floppy disk images, since I don't have any convenient way to install a patched kernel.)

Geri wrote:can it output svga?

Fiwix kernel has the '/dev/mem' interface to let user-space programs have direct access to video memory. This permits the SVGAlib-based programs to work without any problem. This includes XFree86, and probably Doom, Quake and Xorg (not tested yet).

Octocontrabass wrote:It looks like you aren't waiting for the keyboard controller's input and output buffers correctly. In your keyboard_wait() function, you're checking the input buffer status but emptying the output buffer. I patched it to check the output buffer status and it seems to work now, but I'm not sure if that's the intended behavior. There might also be other issues with it that I haven't found.

I just sent a RESET command (0xFF) and then there was an infinite 'while()' waiting for the byte 0xAA (RESET OK). This seemed to work in all keyboards I have, and as I said before, just some intermittent problems in a keyboard under a KVM switch.

Now, I've changed the code and created the function 'keyboard_reset()' which also checks for 0xFA (KB ACK), and there is no longer an infinite 'while()', so after 3 retries it will just give it up.

Octocontrabass wrote:Couldn't you upload it to your website? (I'd appreciate complete floppy disk images, since I don't have any convenient way to install a patched kernel.)

Of course, that makes more sense indeed. Just download the latest patched 0.9.0p1 floppy image you'll see just below the table of downloads in the Download page of the web site.

Thanks again for your interest on this.

I must say I'm very impressed, and I see a lot of potential with this project. I tested the hard disk image on QEMU, but haven't got around to testing it on real hardware. Are the applications on the hard disk itself or on the INITRD?

What are your long-term goals for it?

omarrx024 wrote:I must say I'm very impressed, and I see a lot of potential with this project. I tested the hard disk image on QEMU, but haven't got around to testing it on real hardware. Are the applications on the hard disk itself or on the INITRD?

No, I don't use initrd at all.

The 200MB hard disk has 3 partitions: /boot, / and /home. All they are formatted using the Minix filesystem v1 which means that the maximum size of each filesystem is 64MB. In the next version I plan to include support for the Minix FS v2 which will have a maximum size of 1GB. I'll keep the /boot filesystem using Minix FS v1 because GRUB v1 doesn't support the Minix FS v2. Anyway, the /boot filesystem doesn't need much space since it only holds kernel binary files.

omarrx024 wrote:What are your long-term goals for it?

The main objective is version 1.0. After that ... I don't know. I guess PCI and USB are good candidates for the first versions.

Thanks for your interest.
Regards.

Mikaku wrote:The 200MB hard disk has 3 partitions: /boot, / and /home. All they are formatted using the Minix filesystem v1 which means that the maximum size of each filesystem is 64MB. In the next version I plan to include support for the Minix FS v2 which will have a maximum size of 1GB. I'll keep the /boot filesystem using Minix FS v1 because GRUB v1 doesn't support the Minix FS v2.

Those are some awful, impractical size limits. Why not use ext2? I never dealed with it myself in low-level code, but I guess it should be simplest practical file system suitable for use with Unixes. If someone can confirm this, I think at least portions of ext2 code can be reused for ext3/ext4.

Mikaku wrote:Just download the latest patched 0.9.0p1 floppy image you'll see just below the table of downloads in the Download page of the web site.

It doesn't hang anymore, but it still does something that makes the keyboard completely unresponsive until the BIOS resets it. Since the keyboard is unresponsive, I can't do anything after the OS boots. The same keyboard on the other 386 has no issues.

On both machines, I see floppy disk seek errors near the end of boot. This doesn't happen in Bochs, so it might just be a problem with the disk I'm using.

omarrx024 wrote:

Mikaku wrote:The 200MB hard disk has 3 partitions: /boot, / and /home. All they are formatted using the Minix filesystem v1 which means that the maximum size of each filesystem is 64MB. In the next version I plan to include support for the Minix FS v2 which will have a maximum size of 1GB. I'll keep the /boot filesystem using Minix FS v1 because GRUB v1 doesn't support the Minix FS v2.

Those are some awful, impractical size limits. Why not use ext2? I never dealed with it myself in low-level code, but I guess it should be simplest practical file system suitable for use with Unixes. If someone can confirm this, I think at least portions of ext2 code can be reused for ext3/ext4.

i think it's just a taste and personal preference. if it was driven by the logic, the first ultimate FS to choose for this kind of stuff, would be ... the FAT family of course! it's interoperable AF, it's simple, it's fast, it's easy to implement. For every intelligent being in the whole Universe. not only for the weird "unix" world.

omarrx024 wrote:Those are some awful, impractical size limits. Why not use ext2? I never dealed with it myself in low-level code, but I guess it should be simplest practical file system suitable for use with Unixes. If someone can confirm this, I think at least portions of ext2 code can be reused for ext3/ext4.

Yeah, Minix filesystem v1 and v2 are old, but it's one of the most simple to code UNIX-like filesystem. In my case, the complete support occupies only 1900 LOC.

In the future, it's clear that Fiwix will need something with higher values, and EXT2 is for sure a good candidate.