OSDev.org

The Place to Start for Operating System Developers
It is currently Thu May 23, 2019 12:56 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: How does writing CPU's I/O ports let CPU control I/O devices
PostPosted: Fri May 17, 2019 6:41 pm 
Offline

Joined: Wed Apr 05, 2017 7:44 pm
Posts: 4
From the programmer's point of view, communicating with I/O devices is really simple and straightforward with a consistent, backward compatible interface. Usually, the way communication happens with the I/O devices is by issuing CPU instructions that write to CPU's I/O ports. Hardware device controllers have internal registers that controls them (Requesting stuff from th device, r/w stuff from/to the device ...etc.). Those internal registers, of each device controller, are mapped to the CPU's I/O ports so that writing and reading to CPU's I/O ports is actually writing and reading to the device's registers and thus controlling the device. That's an interesting way to make life easier on the programmer by abstracting all the horrible physical details and the underlying system's architecture.

However, we all know that there is more than this on the physical system level, I/O devices have different interfaces (IDE, SCSI, LPI ... etc) based on their nature and needs. And they are connected on different types of buses (AT, PCI, PCIe, IDE). CPUs gets connected by high speed, special purpose proprietary buses with the RAM. They connect on standardized high speed buses like PCIe with other high speed devices like Ethernet cards and Graphics cards and all gets linked through some kind of a north bridge that contains the PCI controller hub and other stuff. Low speed and legacy devices (Keyboards, IDE drives, BIOS ... etc) are bridged through a platform controller hub or a south bridge (Intel's terminology).

Now, the thing that i don't clearly see is how does the communication happen in real life with all those details and buses ? I mean how does writing some integer value into some CPU's I/O port by issuing a simple CPU instruction like

movb $PORT, %dh
outb %al, %dh

gets propagated through all the system's hardware components (Buses, Bridges, Controllers ... etc.) and eventually gets written to, let's say, the IDE's disk controller's commands register and thus commands the disk to perform some action (R/W a sector) ?

What puzzles me more is that the same port, the same instructions causes the same things to happen even after years of radical architectural changes (Changes in buses specifications, system architecture ... etc.) !! Does the chipset and the hardware manufacturer makes sure to forward the writes to their exact locations in hardwired manner ? For instance, an IDE command might be translated to a PCI request to traverse the PCI bus down to the south bridge than gets translated to something else until it reaches the IDE controller ?

I just want to understand how all this happens and how does the manufacturers always makes sure things are consistent and backward compatible whatever the underlying architecture looks like ?

By the way i am looking for some kind of a book or an article that explains that stuff in details, so a help in this regard will be much appreciated.


Top
 Profile  
 
 Post subject: Re: How does writing CPU's I/O ports let CPU control I/O dev
PostPosted: Fri May 17, 2019 9:27 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 958
It can be a purely hardware solution or software-assisted. Look up SMM/SMI. A port access can trigger a special kind of interrupt transparent to the OS and in the interrupt handler the CPU can simulate the I/O device in a radically different way.


Top
 Profile  
 
 Post subject: Re: How does writing CPU's I/O ports let CPU control I/O dev
PostPosted: Fri May 17, 2019 10:34 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 188
afr0ck wrote:
Now, the thing that i don't clearly see is how does the communication happen in real life with all those details and buses ? I mean how does writing some integer value into some CPU's I/O port by issuing a simple CPU instruction like

movb $PORT, %dh
outb %al, %dh

gets propagated through all the system's hardware components (Buses, Bridges, Controllers ... etc.) and eventually gets written to, let's say, the IDE's disk controller's commands register and thus commands the disk to perform some action (R/W a sector) ?


North bridge and south bridge working in tandem. The classic architecture is, you have a CPU that is connected only to the north bridge (memory controller), which connects up to the RAM, maybe a high-speed bus like PCIe, and the south bridge (I/O controller). And the south bridge connects up to all other things. You output something on a port, that is a transaction that is sent to the north bridge, which propagates it further.

afr0ck wrote:
What puzzles me more is that the same port, the same instructions causes the same things to happen even after years of radical architectural changes (Changes in buses specifications, system architecture ... etc.) !! Does the chipset and the hardware manufacturer makes sure to forward the writes to their exact locations in hardwired manner ? For instance, an IDE command might be translated to a PCI request to traverse the PCI bus down to the south bridge than gets translated to something else until it reaches the IDE controller ?


Simple: They just always kept the existing port assignments. Also, they integrated the same chips that were present in the IBM 5150 into the south bridge / PCH. Open up a 2019 gaming PC, and you'll find a PCH. Find its data sheet, and you'll find it contains the relevant parts of an Intel 8259, among other things.

There was a time when "legacy-free" PCs were all the rage. These would finally dispense with all the old stuff that has been superseded by now (no PIC, only APIC, no PIT, only HPET, etc.). Unfortunately, even these PCs would try to hold backwards compatibility, and thus emulate the hardware that is no longer present, with SMIs that would change the settings of the newer counterpart. No-one expects to have the APIC changed if they write to the PIC, but that is what happened here.


Top
 Profile  
 
 Post subject: Re: How does writing CPU's I/O ports let CPU control I/O dev
PostPosted: Sat May 18, 2019 12:47 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 570
You could take a look at the PCI spec to understand how this works on a modern bus. Memory accesses (e.g. to a framebuffer of an external graphics card or MMIO) are translated to messages that are sent on PCI's wire protocol. The same thing happens for port I/O. Devices listen for messages to their own memory regions and respond accordingly.

_________________
managarm: A microkernel-based OS that is capable of running a Wayland desktop


Top
 Profile  
 
 Post subject: Re: How does writing CPU's I/O ports let CPU control I/O dev
PostPosted: Tue May 21, 2019 4:00 pm 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 1051
It helps to remember that the CPU has a very limited interface/connection to the outside world. It can basically request a read or write on a memory bus, or request a read or write on the I/O bus.

Over time, the CPU "package" has grown, in the sense that a lot of components that used to be physically located on the motherboard are now located on the CPU package, to improve performance (shorter traces). So you can now think of the CPU "core" as the actual CPU, and all of the other stuff, like memory controllers and video adapters, as a sort of mini-motherboard that sits on top of the actual motherboard. This is what made the maker-board craze possible, because the external components needed to run a modern CPU are minimal. (power supply, networking, input controllers, storage, etc.)

So, as far as the CPU core (where your code is executed) is concerned, not much has changed over the years. Only the physical location and size of the other components have changed. The "success" of Intel over the past 40 years has been due in no small part to their strategy of maintaining backward compatibility. If they had not built their legacy on top of their 1970's era platform, there is little doubt that we wouldn't even remember the name Intel. There are plenty of companies that have tried to cut ties with their established platform, and were unable to survive the transition.

_________________
Project: OZone
Source: GitHub
Current Task: SMB Network File Sharing
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group