OSDev.org

zap8600 wrote:Hi. So, how do I set up inpw() and outpw()? Also, can you explain to me how it would keep reading the sector without reading the same 2 bytes every single time?

There are plenty of examples of how to implement these two functions. It depends on your compiler, but click on the signature of almost any one who posts here and you will find source code to these functions.

As for the second question, as I stated before, the controller has a FIFO-style buffer. Read up on what a FIFO (First In, First Out) buffer is. The controller will hold the 256 words in its internal memory. When you read from the DATA register, it will read the current available word.

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

Hi. So can I use inw and outw instead of inpw and outpw?

The name of the function doesn't matter. What's important is that you have one function to read a word from an I/O port and another function to write a word to an I/O port.

Hi. Thanks for all the help! I now have an idea for a simple disk driver. I will come back to this forum if I ever need help.
Also, can someone review my filesystem? It is a really simple node graph filesystem. Thanks! Thanks!
P.S. I'm having trouble booting my OS on an actual computer. It doesn't even get to load the kernel into memory. Is it because I'm booting on a laptop?

zap8600 wrote:Hi. Thanks for all the help! I now have an idea for a simple disk driver. I will come back to this forum if I ever need help.
Also, can someone review my filesystem? It is a really simple node graph filesystem. Thanks!

Code: Select all

struct NODE {
    u32 NAME;   /* Should the file name be u64 for 8 bytes of character length? I set it as u32 because I didn't know if a 32-bit OS could read u64. Also, would u64 be unsigned long? */
    u32 SIZE;    /* Measured in kilobytes or megabytes. I haven't decided yet. It is u32 to fill as much data on the data sector. */
    u8 TYPE;   /* This is u8 because I only need about 1 byte for the type. */
    u16 GID;   /* I plan on using the GID for telling the OS which folder the file is in. It is u16 for 100 groups. 0 is the root directory. */
}
/* In the root directory, there can be 4 directories. In each directory, there can be 4 sub-directories. It can go 4 layers deep. */

Thanks!

Personally, I wouldn't bother creating a new filesystem, even one as simple and limited as what you're proposing.

I'd recommend reading up and implementing a USTAR based filesystem first, then you can generate filesystem images and load them with your kernel as an initial ram disk using multiboot modules.

Then you just need to put a disk like front end interface to your multiboot initial ram disk module, have your USTAR filesystem talk to that disk front end, then plug the USTAR module into your VFS layer.

zap8600 wrote: P.S. I'm having trouble booting my OS on an actual computer. It doesn't even get to load the kernel into memory. Is it because I'm booting on a laptop?

Impossible to say.

If you're developing with QEMU, and it appears to work on there, try booting using Bochs. Bochs is closer to real hardware behaviour wise, I understand, and may well catch errors that QEMU misses.

Check also you're setting up your GDT/IDT properly? Again, QEMU might be more forgiving of mistakes here (such as segment limits) or you may be referencing segments you've not initialized explicitly, but in QEMU, have reasonable enough default values to allow continued execution.

thewrongchristian wrote:I'd recommend reading up and implementing a USTAR based filesystem first, then you can generate filesystem images and load them with your kernel as an initial ram disk using multiboot modules.

Then you just need to put a disk like front end interface to your multiboot initial ram disk module, have your USTAR filesystem talk to that disk front end, then plug the USTAR module into your VFS layer.

+1, I also use ustar archives ramdisks these days.

Hi. I'm still going to make my own filesystem so that I can grasp a concept of making a filesystem. I'm not using USTAR because it has a lot of features I won't need because of how simple my OS is. I'm going to keep making changes to make it better. Also, I will look into using Bochs.

zap8600 wrote:I'm having trouble booting my OS on an actual computer. It doesn't even get to load the kernel into memory. Is it because I'm booting on a laptop?

There are a lot of things that can cause a bootloader to work in QEMU but fail on hardware, especially if you're using a USB flash drive. This is one of the reasons why it's good to use an existing bootloader instead of writing your own.

zap8600 wrote:Hi. I'm still going to make my own filesystem so that I can grasp a concept of making a filesystem. I'm not using USTAR because it has a lot of features I won't need because of how simple my OS is. I'm going to keep making changes to make it better. Also, I will look into using Bochs.

Many people here have their own opinion on creating your own boot loader and/or file system with most being against it, and I respect that. Everyone is entitled to their opinion, it is how we react to that opinion that makes us who we are.

With that being said, I commend you on the fact that you are making your own boot loader and file system. In my opinion, this is the best way to learn. The wheel has been invented many times, but if we use someone else's wheel, we won't know how it works.

I created my own file system (FYSOS) a while back and I will admit, it isn't really that good. It has some issues. However, I was able to learn about those issues and what makes a file system good or bad. I later had the opportunity to be a part of a different file system (LEANFS), took what I learned, and between the two of us (more him than I), we made a descent file system.

Don't get discouraged about not making your own stuff. It is a wonderful way to learn, and that is why I do it, for the learning experience.

Anyway, that is my opinion. Take it as you like.

Ben

zap8600 wrote:

Code: Select all

struct NODE {
    u32 NAME;   /* Should the file name be u64 for 8 bytes of character length? I set it as u32 because I didn't know if a 32-bit OS could read u64. Also, would u64 be unsigned long? */
    u32 SIZE;    /* Measured in kilobytes or megabytes. I haven't decided yet. It is u32 to fill as much data on the data sector. */
    u8 TYPE;   /* This is u8 because I only need about 1 byte for the type. */
    u16 GID;   /* I plan on using the GID for telling the OS which folder the file is in. It is u16 for 100 groups. 0 is the root directory. */
}
/* In the root directory, there can be 4 directories. In each directory, there can be 4 sub-directories. It can go 4 layers deep. */

That's not a filesystem -- it's just a structure. The best freely available reference on the philosophy behind and design of filesystems that I know of is this book: http://www.r-5.org/files/books/computer ... ign-EN.pdf

Hi. I have a couple of new problems. First, I'm confused when reading FYSOS Book 3. I need to find the drive number of the drive. Second, I need to put the drive into IDE Compatibility mode. Third, I'm having trouble making a filesystem and a FUSE driver.

zap6800 wrote: I need to find the drive number of the drive.

Are you talking about the BIOS drive number? If so, the BIOS sends that to your boot sector in the DL register

zap6800 wrote:Second, I need to put the drive into IDE Compatibility mode.

Look at the manual for your BIOS to know how to do that. Or, you can Google it.

Hi. I was talking about getting that in 32bit Protected Mode. Do I have to set IDE Compatibility Mode and retrieve the drive number from my boot sector? Also, how do I keep dl from being overwritten? How would I read the dl register when I'm in the C code? How would I write to the Command Register (It sort of confuses me)?

zap8600 wrote:Do I have to set IDE Compatibility Mode and retrieve the drive number from my boot sector?

IDE compatibility mode is an option in the BIOS setup. You have to open the BIOS setup and look for the SATA settings.

I don't know which "drive number" you're talking about, but if it's the BIOS drive number, the BIOS passes it to your boot sector in the DL register.

zap8600 wrote:Also, how do I keep dl from being overwritten? How would I read the dl register when I'm in the C code?

Put the value somewhere it won't get overwritten, then pass it (or a pointer to it) to your C code according to the ABI. You don't have to keep it in the DL register, it's fine to put it somewhere else.

zap8600 wrote:How would I write to the Command Register (It sort of confuses me)?

Use the x86 "out" instruction to write a byte to the port at offset 7 from the start of the command register block. In ISA compatibility mode, the command register block for the first IDE channel starts at port 0x1F0, so the command register will be at port 0x1F7. In PCI native mode, you have to use the BARs to determine where the command register block starts.

zap8600 wrote:Hi. I was talking about getting that in 32bit Protected Mode. Do I have to set IDE Compatibility Mode and retrieve the drive number from my boot sector? Also, how do I keep dl from being overwritten? How would I read the dl register when I'm in the C code? How would I write to the Command Register (It sort of confuses me)?

I am kind of getting the idea that you want to save the value in the DL register so that once you are in protected mode, you can call the BIOS and read from the drive. If this is the case, you are misunderstanding what you need to do.

Once in protected mode, (except for virtual x86 mode) you have no way of calling the BIOS. You must set up and control the (ATA)IDE controller all by yourself. The value in DL, while in real mode, has absolutely no bond to your code/drive now that you are in protected mode. It was simply a "handle" used by the BIOS, no longer accessible to you in pmode.

In my book, there is a diagram and detailed instructions on how to place a (non-SATA) controller from Native mode to IDE compatible mode. However, this only works on older PCI IDE controllers. It does not work for the newer AHCI/SATA controllers, only ATA/EDI controllers. As stated before, if you are trying to get a new SATA/AHCI drive to support EDI compatibility, first look in your CMOS settings (that's an old word), or read the chapter about AHCI where some AHCI controllers have a bit that will allow you to set a setting between AHCI and IDE.

Please note, and this is kind of the impression I am getting from you, that once you move to pmode you can no longer use any BIOS calls. The BIOS is not accessible any more.

If you are using an emulator for your tests, QEMU or Bochs for example, you can tell these emulators to use IDE drives without the need to worry about CMOS settings, or setting from Native to IDE compatibility.

Do you have a website/git page where you can post your code and QEMU command line or Bochs' bochsrc.txt file. This would help. Are you testing on real hardware? It is much easier to test on an emulator.

Ben

( Edit: Sorry, in my real job, I use the acronym EDI too many times and out of habbit said EDI instead of IDE :-) Fixed. )