Somebody can explain, please what is, Linux point of view IO-memory and memory. How one can declare them - as far as I know Linux auto-discovers the amount of SDRAM your system has. Now what about the IO-memory?
Yes the IO devices are memory mapped and seen by the processor as memory locations. To use these registers the kernel doesn't use the MMU but rather does direct/physical access.
From what you say I understand the device drivers have these addresses hard coded in their code. There is no need for the kernel to differentiate IO and regular memory. The driver does this work.
In a sensible set-up, high order address bits select a device, and low order address bits select a part of a device. In the dim and distant past, memory and I/O devices were assigned areas of the memory map by copper traces on the PCB. The memory map included devices that might not be physically present. The only way to see if they were there was to write data to them, and check if the expected values could be read back.
The next layer of confusion was to make the memory map programmable - a device at a fixed location in memory converted the high order address bits into device select signals. The mapping from addresses to selections could be modified by writing values to that device.
The x86 had a special feature called an I/O address space. It is effectively an extra high order address bit, but it does not fit into an ordinary pointer. Instead, memory instructions select the memory address space and I/O instructions affect the I/O address space. Memory and devices can be mapped to fixed I/O addresses or to programmable I/O addresses just like they can with memory addresses.
This huge leap backwards required extra signals on the PCB, duplication of instructions (one set for the memory and another for the I/O address space), the option to get confused about whether a pointer referred to memory or I/O and extra complication for DMA chips.
PC's contain some devices mapped to memory space, some to IO, some to either and some to both. Some addresses are reserved for devices that may or may not exist. The traditional method of poking around to see what is present became risky because the required poking to detect a sound card might format a disk if a disk controller is mapped where you are looking for a sound card.
Various standards were proposed to make device detection less haphazard like plug & pray and Awful Configuration & Power Interface. Some manufacturers implemeted the standards. Some operating systems relied on bugs in the implementations. The result is the arbitrary mess you see today in PC hardware.
Linux does not just run on x86. Plenty of CPU's like 68000, ARM and MIPS derivatives do not have special instructions for an I/O space. All devices are somewhere in the memory map. The smallest amount of memory an Alpha CPU can read or modify is 64-bits. Some hardware does different things depending on whether you read/write 8, 16 or 32 bits of data. When these devices are connected to an Alpha CPU, they are mapped to multiple places - one for 8 bit access, another for 16 bit and so on.
Cross-platform peculiarities like this are hidden behind macro definitions in Linux. Now that you have read this, some of the introductory online books about Linux kernel programming will make some sense to you. Find them with google and read them.
Isn't IO are memory mapped
Isn't IO are memory mapped ?
if not, then I think respective device driver has knowledge of respective device memory.
Yes the IO devices are
Yes the IO devices are memory mapped and seen by the processor as memory locations. To use these registers the kernel doesn't use the MMU but rather does direct/physical access.
From what you say I understand the device drivers have these addresses hard coded in their code. There is no need for the kernel to differentiate IO and regular memory. The driver does this work.
Thanks.
Noddy's guide to IO
In a sensible set-up, high order address bits select a device, and low order address bits select a part of a device. In the dim and distant past, memory and I/O devices were assigned areas of the memory map by copper traces on the PCB. The memory map included devices that might not be physically present. The only way to see if they were there was to write data to them, and check if the expected values could be read back.
The next layer of confusion was to make the memory map programmable - a device at a fixed location in memory converted the high order address bits into device select signals. The mapping from addresses to selections could be modified by writing values to that device.
The x86 had a special feature called an I/O address space. It is effectively an extra high order address bit, but it does not fit into an ordinary pointer. Instead, memory instructions select the memory address space and I/O instructions affect the I/O address space. Memory and devices can be mapped to fixed I/O addresses or to programmable I/O addresses just like they can with memory addresses.
This huge leap backwards required extra signals on the PCB, duplication of instructions (one set for the memory and another for the I/O address space), the option to get confused about whether a pointer referred to memory or I/O and extra complication for DMA chips.
PC's contain some devices mapped to memory space, some to IO, some to either and some to both. Some addresses are reserved for devices that may or may not exist. The traditional method of poking around to see what is present became risky because the required poking to detect a sound card might format a disk if a disk controller is mapped where you are looking for a sound card.
Various standards were proposed to make device detection less haphazard like plug & pray and Awful Configuration & Power Interface. Some manufacturers implemeted the standards. Some operating systems relied on bugs in the implementations. The result is the arbitrary mess you see today in PC hardware.
Linux does not just run on x86. Plenty of CPU's like 68000, ARM and MIPS derivatives do not have special instructions for an I/O space. All devices are somewhere in the memory map. The smallest amount of memory an Alpha CPU can read or modify is 64-bits. Some hardware does different things depending on whether you read/write 8, 16 or 32 bits of data. When these devices are connected to an Alpha CPU, they are mapped to multiple places - one for 8 bit access, another for 16 bit and so on.
Cross-platform peculiarities like this are hidden behind macro definitions in Linux. Now that you have read this, some of the introductory online books about Linux kernel programming will make some sense to you. Find them with google and read them.