Low I / O using outb and inb

It’s not easy for me to understand how interrupts work.

the code below initializes a programmable interrupt controller

#define PIC0_CTRL 0x20 /* Master PIC control register address. */ #define PIC0_DATA 0x21 /* Master PIC data register address. */ /* Mask all interrupts*/ outb (PIC0_DATA, 0xff); /* Initialize master. */ outb (PIC0_CTRL, 0x11); /* ICW1: single mode, edge triggered, expect ICW4. */ outb (PIC0_DATA, 0x20); /* ICW2: line IR0...7 -> irq 0x20...0x27. */ outb (PIC0_DATA, 0x04); /* ICW3: slave PIC on line IR2. */ outb (PIC0_DATA, 0x01); /* ICW4: 8086 mode, normal EOI, non-buffered. */ /* Unmask all interrupts. */ outb (PIC0_DATA, 0x00); 

can someone explain to me how this works:

- outb role (I did not understand linux man)

- addresses and their meaning

another unrelated question, I read that outb and inb are for port-mapped I / O, can we use memory I / O to input I / O messages?

thanks.

+4
source share
3 answers

outb() writes the byte specified by the second argument to the I / O port indicated by its first argument. In this context, a “port” is a means for the CPU to communicate with another chip.

The specific C code that you present relates to the 8259A Programmable Interrupt Controller (PIC).

Here you can read about PIC here and here .

If this does not provide enough details for understanding commands and bit masks, you can always refer to the archive.

+5
source

The device-specific code is best read with the appropriate technical data sheet. For example, the detailed description (8pp.sail.mit.edu/6.828/2005/readings/hardware/8259A.pdf) "8259A Programmable Interrupt Controller" clearly (but briefly) explains almost everything.

However, this description will only explain how the chip can be used (in any system), and will not explain how the chip is used in a particular system (for example, in "PC-compatible" 80x86 systems). To do this, you need to rely on “implied de facto standards” (since many of the features of PIC chips are not used on “PC compatible” 80x86 systems and may not be supported on modern / integrated chipsets).

Usually (for historical reasons) IRQ PICs are mapped to interruptions in a weird / bad way. For example, IRQ 0 maps to interrupt 8 and conflicts with the exception of a double CPU error. The specific code you posted reassigns the PICs so that IRQ0 is displayed for interrupt 0x20 (and IRQ1 for interrupt 0x21, ..., IRQ 15 displayed in IRQ 0x2F). This is what the OS usually does to avoid conflicts (for example, so that every interrupt is used for IRQ or exception and never happens).

To understand "outb ()", see the "OUT" instruction in Intel manuals. It looks like 2 address spaces - one for normal physical addresses and completely separate for I / O ports, where the usual instructions are (indirectly) accessing normal physical memory; and the I / O port instructions (IN, OUT, INSB / W / D, OUTSB / W / D) access a separate “I / O address space”.

+1
source

The traditional 8088/86 had / had a memory control signal, which is essentially another bit of the address associated directly with the instruction. A control signal sharing access to I / O and memory creates two separate address spaces. Unlike CS, DS, etc., creating separate memory cells inside the chip (before deleting the external memory space). Other processor families use the so-called memory I / O.

Nowadays, controllers / memory systems are torn inside and outside the chip in different ways, sometimes, for example, with many control signals that indicate a command with data, filling cache lines, writing via vs write back, etc. To save on the external circuit, the memory is displayed inside the chip and, for example, the dedicated rom interfaces, separate from ram, etc., are on the edge, much more complicated and separate than the I / O space against the memory space of the old 8088/86.

The output and instruction and several family members change whether you are accessing I / O or accessing memory, and traditionally the interrupt controller was a chip that decrypted the memory bus looking for I / O access with a dedicated address for this device. Decades of backward compatibility later, and you have the real code you're looking at.

If you really want to understand this, you need to find the data tables for the device containing the interrupt controller, which is likely to be combined with a bunch of other logic on a large support chip. Other tables may also be required.

+1
source

Source: https://habr.com/ru/post/1392312/


All Articles