OSDev.org

Hi, while I am in real mode I use BIOS interrupts to load kernel's binary file into memory at 0x8000
After I enter protected mode I loose access to these interrupts
I would like to put some data like documents, images to flash drive and be able to read
What shall I do in this case ? Shall I write some kind of driver to use USB or does x86 give some hardware support to use it ?
Please some tips, thank you

Jane1991c wrote:Hi, while I am in real mode I use BIOS interrupts to load kernel's binary file into memory at 0x8000
After I enter protected mode I loose access to these interrupts
I would like to put some data like documents, images to flash drive and be able to read
What shall I do in this case ? Shall I write some kind of driver to use USB or does x86 give some hardware support to use it ?
Please some tips, thank you

You would need to write one or more USB divers for the one or more types of USB controller your motherboard plays host to, and then write a device drive for the flash drive, which would access the flash drive through one of the USB driver(s). Personally, it is not a project I would even think of undertaking early on in osdev development. I would boot from a floppy, a CD or a hard disk instead.

I got hold of this book, but I am not expecting to be making use of its contents any time soon:

http://www.amazon.co.uk/USB-The-Univers ... 1468151983

You have a few options. One is to keep your OS simple enough to be able to switch back to real mode to use the BIOS whenever you want to read or save data (this is what I currently do), but it won't allow you to plug in another USB drive and work with it after booting because the BIOS will simply ignore it if it wasn't plugged in right at the start. I usually work with two flash drives and one SD card plugged in before booting and I can boot from and read/write data to/from all of them.

Another option is to write a driver for the kind of hard drive in your machine so that you don't have to go through USB to work with it. If the machine has a built-in CD/DVD drive you could write a driver for that instead (or as well). This is the more usual route to go down as it allows you to get away from using the BIOS more quickly. Don't bother writing a driver for floppy drives unless you're keen to work with museum exhibits.

The ideal option is to write your own USB drivers, and the book Matematician pointed you towards is a good one which will help you make sense of all the USB specification documents. You have to be highly committed to building an operating system to want to do this though, so you need to ask yourself if it's really going to be worth the effort for what you will eventually end up with. Will anyone ever use your operating system? Will you be the only user, and will the satisfaction of using it make the cost of building it worthwhile? Life is short, and there are lots of other things you could be doing with it.

DavidCooper wrote:You have to be highly committed to building an operating system to want to do this though, so you need to ask yourself if it's really going to be worth the effort for what you will eventually end up with. Will anyone ever use your operating system? Will you be the only user, and will the satisfaction of using it make the cost of building it worthwhile? Life is short, and there are lots of other things you could be doing with it.

I highly doubt whether anybody except me will ever use my operating system. On the other hand, hobbyists are presumably only doing it in the first place because they like the technical challenge.

Then again, I may be wrong about the difficulty of writing USB drivers, so it's maybe a mistake to say anything that might put anyone off having a go at it. One major barrier which I had wrongly imagined was there was the probability of losing keyboard and mouse input as soon as the USB controller is interfered with, but I've tested this on my machine and found that they are not affected, so the PS2 ports on it must be real and not emulated. This means I don't need to write USB keyboard and mouse/HID drivers straight away, so I can just focus on EHCI and mass storage device drivers without getting bogged down in building new drivers for slow input devices first. This reduces the immediate task from writing four, five or six drivers to just two, and that feels a lot less daunting.

One major barrier which I had wrongly imagined was there was the probability of losing keyboard and mouse input as soon as the USB controller is interfered with, but I've tested this on my machine and found that they are not affected, so the PS2 ports on it must be real and not emulated. This means I don't need to write USB keyboard and mouse/HID drivers straight away, so I can just focus on EHCI and mass storage device drivers...

To clarify, and out of curiosity, was this with a pre-OS to OS handoff (ie, requesting the BIOS 'let go' of its control)? It's also worth noting that PS/2 emulation may be disabled or not present. A HID driver (that ignores mouse/joystick/not-keyboard, say) is not too complicated and is probably easier to start with than mass storage (as your testing cycle will provide very immediate feedback). That way you can get to know the fundamentals of writing the driver, and apply those fundamentals later to things like mass storage which can be a little more complicated to test.

As for the original query... it's probably best to avoid USB unless you have a good comprehension of IRQs, talking to devices, timing, and memory management. It's probably best to avoid mass storage if you don't yet know much about SCSI or haven't cut your teeth on something much simpler (and with significantly more avenues for debugging) like ATA/ATAPI.

That's my two cents worth, anyway. There's exceptions to the rule, but it's perhaps best to crawl before you walk. And then to walk before you run

pcmattman wrote: To clarify, and out of curiosity, was this with a pre-OS to OS handoff (ie, requesting the BIOS 'let go' of its control)?

I wasn't aware that there was a way to request the BIOS to do that. What I did was write 0x8F00 to 0xC0 of the configuration space of each UHCI controller to disable them all from being used for keyboard/mouse emulation. I then wrote values to various other registers of those and the EHCI controllers, while keyboard and mouse input remained unaffected. I'd better have another go though just to make absolutely sure - I didn't check that all the values I wrote actually changed as a result, so it's just possible that I failed to do the job properly. [I wrote new interrupt numbers to each controller and they definitely did change, but the BIOS doesn't necessarily use those as it may be using system management mode interrupts instead.]

Edit: my brain wasn't in gear yesterday (too many things going on) - of course it must use system management mode interrupts as the input's happening when the processor isn't in real mode. I'll check it again when I get the chance and change addresses to make sure the EHCI controllers can't find the data they need to know what work they're meant to be doing.