The general workflow to make a hard disk driver

[sunnysideup]

Also, I usually emulate using qemu, and then dd onto a USB stick, to test on my Legacy BIOS machine.

Will this work for the USB too then? I'm guessing no but really hoping yes . Maybe BIOS emulates the USB as ATA??

[Octocontrabass]

Maybe BIOS emulates the USB as ATA??

Nope. If you want to access USB without using INT 0x13, you need USB drivers.

[sunnysideup]

Awwwww no...

[sunnysideup]

No matter, I'll take this opportunity to learn more about the motherboard organization on computers. Consider this picture: https://sabercomlogica.com/wp-content/u ... re-8-1.jpg

0. Can most of today's motherboards be "logically" considered as this? (I know that the northbridge, etc. has been squashed into the CPU SoC, so physically a motherboard might be way different) and all.
1. The first issue that I see with this picture is that it isn't multiprocessing. If it were, how would the diagram vary?
2. I know that OLD (very very old PCs) used something called an ISA bus. Has it been replaced? Has it been removed? Is there a bus with similar functionality in today's motherboards?
3. Where would the IOAPIC and the LAPIC be located on this board?
4. Is the ATA controller present in the disk drive or on the motherboard? You can read this question that I had:

Quote:
What the original IDE specification did was to detach the disk controller boards from the motherboard, and stick one controller onto each disk drive, permanently. When the CPU accessed a disk IO port, there was a chip that shorted the CPU's IO bus pins directly onto the IDE cable -- so the CPU could directly access the drive's controller board. The data transfer mechanism between the CPU and the controller board remained the same, and is now called PIO mode. (Nowadays, the disk controller chips just copy the electrical signals between the IO port bus and the IDE cable, until the drive goes into some other mode than PIO.)

Quoted from the wiki ^
So are disk controllers present in the disk drives? Is it the same today?
Quote:
Current disk controller chips almost always support two ATA buses per chip
Are these the same disk controllers that are present in the disk drives? What does it mean that it supports 2 buses per chip? I thought there should be 2 chips per bus (2 disk drives per bus : master/slave and if each disk has a controller, 2 chips per bus)

5. I've programmed the timer (that corresponds to port numbers 0x40 and 0x43). Where is this located?
6. Is the PCI controller (busmaster?) located in the southbridge (ICH)?

Sorry for the barrage of questions . These were just of the top of my head. Maybe I'll find more XD. I'm just curious tbh.

[nullplan]

0. Can most of today's motherboards be "logically" considered as this?

The only logical view you can have on the motherboard is the one presented to the CPU. And it is this: The CPU is directly connected to some memory. Ask BIOS (Int 15h, Function E820) or UEFI for how much and where it is. It is also directly connected to some peripherals in address space. Ask ACPI and the PCI bus about where and what. Other than the ISA devices (which are all the legacy devices like PIT, PIC, ISA DMA controller, etc., and, of course, the PCI controller), you find all your hardware on the PCI bus like it was 1995. Only difference now is, if you can support it, you can talk to PCI config space using MMIO. Ask ACPI about details.

1. The first issue that I see with this picture is that it isn't multiprocessing. If it were, how would the diagram vary?

Depends, but it is unlikely you would notice until you're getting quite deep into the architecture of things. And right now you don't even have USB drivers . There were multi-socket main boards (and they still exist and are used for servers and stuff), in which multiple CPUs (multiple physical packages) would be slotted into different sockets, often each with their own memory attached. All CPUs could still see all memory, but accessing non-local memory would require requests to be routed across the MB and thus take longer (the North Bridges would handle that, no need for software support). It is therefore advantageous to allocate memory for a CPU in the memory closest to the CPU. Such an architecture is called NUMA. These days you usually have SMP systems, in which there is only one CPU package containing multiple cores, often multiple threads in those cores. But all memory is still accessed locally, so unless there is cache contention, all memory accesses take the same time. Such an architecture is called UMA.

For your picture not much changes, except you have a battery of CPUs (instead of a single one) attached to either one (UMA) or a battery (NUMA) of North Bridges. And from the point of view of the OS running on the CPUs, you see no difference since all hardware beyond the CPU is still the same. So long as not multiple CPUs try to talk to the same hardware, everything works out the same.

2. I know that OLD (very very old PCs) used something called an ISA bus. Has it been replaced? Has it been removed? Is there a bus with similar functionality in today's motherboards?

The ISA bus is what the PC clone industry called the PC standard. It still exists. Your PCI bus will have an ISA gateway somewhere, and reading about ICHs and PCHs you might come across a thing called the LPC bus, which is just the ISA bus with fewer pins. Instead of running with 32 pins at 4MHz, they are running with 4 pins at 32MHz, but the throughput is the same. I'm oversimplifying here, obviously, but you were not making hardware for the thing, you were just looking to program it.

The PCI bus allows for a standard way for hardware to tell the OS and BIOS about the resources it needs, and otherwise, for functionality, it offers much of the same things as ISA. These things work with transactions now, but that also does not matter to the OS programmer. And the various iterations of PCI over the decades (i.e. AGP and PCIe) also don't matter to the OS programmer. Only the MMIO way of accessing the PCI config space is an innovation you might want to take on board, but is for a decently designed OS only a local optimization.

3. Where would the IOAPIC and the LAPIC be located on this board?

The IOAPIC is inside the South Bridge (low speed device). The LAPIC is inside the CPU (in each thread, really).

4. Is the ATA controller present in the disk drive or on the motherboard?

Motherboard. MB ATA controller talks to the Integrated Disk Electronics on the drive in a standard way, but that is one step removed from the CPU. The CPU only talks to the ATA controller, and then that thing works some black magic you neither know nor care about, and then your sector appears in memory somewhere.

5. I've programmed the timer (that corresponds to port numbers 0x40 and 0x43). Where is this located?

Inside the South Bridge. As is most legacy hardware. Even the RTC.

6. Is the PCI controller (busmaster?) located in the southbridge (ICH)?

What does it matter to you? You talk to a PCI device, say a RAID controller, then it does something, and then another hard disk sector appears in memory. You don't need to talk to the PCI device any more than that, and you don't need to setup the DMA transfer like you needed with ISA, so how exactly those bytes get from the disk into the memory is something you don't have to care about.

Picture this: Imagine I told you an answer, and it was wrong. How would you notice? You can't; the entire process does not concern you.

[eekee]

Maybe BIOS emulates the USB as ATA??

Nope. If you want to access USB without using INT 0x13, you need USB drivers.

I dual-boot my test machine. One of the OSs on it has a suitable network driver and Unix-like device files. In that OS, I can use netcat to write straight from the network to a disk partition. To send the data from a Unix box, I also use netcat. (To be exact, I don't actually use netcat because none of my OSs are actually Unixes at present, but that's probably irellevant detail. The things I do use happily interoperate with netcat; they all just listen for or open TCP streams.)


Regarding that diagram, I wouldn't try to understand it. I've often got stuck, even to the point of having to give up on major projects, because I tried too hard to understand stuff like that. I agree with nullplan's words: "The only logical view you can have on the motherboard is the one presented to the CPU."

[sunnysideup]

Looks like my question #0 was the most important, because it's help me clear my concepts regarding the programmer view of the system. I'm surprised I couldn't find such a description anywhere, while, clearly it is very important for newbies to get such a concept right

Or is there some article that actually describes this 'programmers' view??

[sunnysideup]

Going back to the original question. I think I must really invest in a v8086 mode driver to exploit the BIOS disk reading facilities. What should I look out for in this approach? (I know I must preserve the BIOS interrupt handling code)

I think I must do the following:

* Temporarily re-enable (a 1M??) identity map
* NEVER modify some memory locations after I boot. (Which ones exactly?)
* ......

What else?

[nullplan]

Just write the damn drivers already. At this point, what you are planning to do in order to not have to write the drivers is way more complicated than writing them. But if you insist:

You have to take care to never modify the IVT, the BDA, and the EBDA. So take care not to modify addresses below 0x600, and the EBDA is generally taken care of by the memory map (it is often but not always at 0x9fc00). BIOS code will need access to IVT, BDA and EBDA, and everything from 0xa0000 to 0x100000. Also maybe some memory in PCI space. And, of course, some conventional memory is also going to be needed to store the program for v8086 mode and to house the stack. And to house the data buffer (you are still going on about disk access, after all)

The complicated thing will be to modify your GPF handler to emulate all the weird things BIOS code will want to do. Something for which I cannot help you, for my OS is purely 64-bit, and long mode does not contain v8086 mode.

[sunnysideup]

The ATA driver seems quite simple. However, the USB driver isn't so (at least, doesn't look so). Moreover, the v8086 mode seems like an excellent way to make a temporary 'patch' driver for all devices! And honestly v8086 mode doesn't seem too complicated. Of course, over time, I would make a USB driver and so on.

WRONG!! Although it's a nice idea, BIOS is truly meant to be forgotten I think (apart from video BIOS), once one switches to pmode / long mode. The work required to make them work is just too much! I might even have to remap the PIC and so on! Not worth it

USB driver it is!