> Ah yes, I/O-mapped I/O. I've read about this, but I've never actually
> seen it in action. Presumably it just means that you use a different
> op-code to access stuff in the I/O address space? (And that the same
> address can exist independently in both address spaces. And presumably
> the two addresses can be different widths...)

Just for interest the original ARMs in the Acorn machines split the 
logical address space into two. The first 32MB of address space is what 
normal user programs had access to ("user space"), and the OS mapped 
whatever was needed into this space (including the screen buffer(s)). 
Actual physical devices had addresses in the range 32MB to 64MB (the 
original ARMs although 32bit only had a 26bit address space, the other 8 
bits in the program counter were used as status and mode flags). The 
physical RAM was mapped from 32MB to 48MB, all I/O was mapped between 
48MB and 52MB, and above that if you *read* you read from the OS ROM 
chips, but if you *wrote* you wrote to various other bits of special 
hardware (video/sound controllers etc).

One pretty clever result (or reason?) of the above was that the screen 
memory was always mapped from 32MB downwards, and the physical screen 
memory was at 32MB upwards. This allowed some nifty vertical scrolling; 
code could automatically "wrap around" its graphics drawing by just 
deliberately going past the 32MB boundary into the start of physical 
RAM. Needless to say you could tell the video controller to start 
anywhere in memory (including just before the 32MB boundary) to 
physically draw the screen.

Obviously the above scheme limited physical RAM to 16MB (which wasn't an 
issue at the end of the 80s), I'll have to look up what they changed to 
overcome that. I know that somewhere between ARM3 and ARM6 they added a 
true 32bit addressing mode (which of course broke everything that 
assumed addresses were only 26 bits wide).

Post a reply to this message

>> http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf
>
> I'm not sure it answers my question, but it's certainly a very
> interesting read...
>
> Sections 8 and 9 in particular seem to be saying that there's about
> two-dozen memory-mapped registers that tell the GPU where the control
> lists are, and then it sucks those into the GPU and goes away to do it's
> thing.

As clipka said the raspberry pi gives a good opportunity to start 
tinkering around with the bare hardware without the restrictions of any 
OS. This is a good guide, in particular this page introduces 
communication with the GPU (just to create and get a pointer to a 
framebuffer):

http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/screen01.html

Post a reply to this message

>> Ah yes, I/O-mapped I/O. I've read about this, but I've never actually
>> seen it in action. Presumably it just means that you use a different
>> op-code to access stuff in the I/O address space? (And that the same
>> address can exist independently in both address spaces. And presumably
>> the two addresses can be different widths...)
>
> Exactly.
> Examples from the home computer era would be the Amstrad CPC, and
> probably the ZX Spectrum, which both feature a Z80 processor. IIRC the
> Amstrad CPC's basic even had dedicated commands for I/O access.

Although I've used all of those systems, I only ever did hardware-level 
programming with the C64. (The others all had BASIC commands for 
graphics and sound; the C64 didn't. The Commodore Plus4, but contrast, 
had *excellent* commands for graphics and sound. Weird...)

>> So I'm imagining for stuff that doesn't have many registers (e.g., the
>> keyboard controller), the whole thing is I/O-mapped. Whereas for
>> something like the sound card, you poke a bunch of (main) memory
>> addresses into I/O-mapped registers and say "have at it!"
>
> Basicaly yes. Though for memory-mapped devices like the graphics card
> you traditionally had hard-wired memory addresses so you wouldn't need
> to poke the memory addresses to any I/O address anywhere, and with PnP
> the job of poking the memory address would have been done by the BIOS or
> OS already.

Right. So by the time the OS is up and running, you just have to know 
which chunk of RAM is mapped to each device.

> As for the sound card, IIRC traditionally it was not memory-mapped. You
> see, the sound card operates sequentially on non-repeating data, which
> is exactly the mode of operation the DMA controller was designed for, so
> to save memory address space for true memory (including devices' ROMs,
> which are always memory-mapped) the card would present only two I/O
> addresses for data (one for reading, one for writing). Same for disk I/O.

Intriguing... I didn't know you could do that.

>> As I see it, a DMA controller is just another I/O device - one who's
>> only job is to copy chunks of RAM around while you're not looking. Given
>> the previous paragraph of speculation, I'd expect all the stuff for
>> controlling DMA to be I/O-mapped, but who knows?
>
> It is indeed.
> The fun fact though is that it cannot only copy RAM around, but also
> between RAM and an individual I/O address, at a pace dictated by the I/O
> device, which is great for anything involving serial data processing,
> because it means you don't necessarily have to sacrifice precious memory
> address space.

I've never done hardware-level programming on a system that actually 
supports DMA. This is a possibility I wasn't aware of. I kinda assumed 
that the I/O device itself handles reading data from RAM at the right 
speed. But for purely sequential stuff like disk or sound, it makes 
perfect sense...

> On the other hand, nowadays memory address space is plenty (even on a 32
> bit machine), while DMA channels (i.e. number of concurrent DMA
> transfers) are scarce (and increasingly complicated, due to virtual
> memory mapping), so I guess today's hardware prefers memory-mapped
> buffers over DMA.

Don't look at me. ;-)

> If you really want to go down to that level, I'd suggest getting a
> Raspberry PI and trying to write some standalone application (i.e. one
> that doesn't need an OS) to run on it. The hardware seems to be well
> enough documented to pull off that stunt.

Or just, you know, the Pi emulator, which doesn't cost money. ;-)

>> Fun fact: My PC doesn't *have* a BIOS. It has an EFI. ;-)
>
> ... which is a BIOS on steroids.

It isn't. It really isn't. That's what everybody told me, but the more I 
read about it, the more it becomes vividly clear that it's a totally 
new, different system, unrelated to what went before.

(It's actually very cool. Or, the way it's *supposed* to work is very 
cool; whether anyone will implement it correctly remains to be seen. 
Currently this stuff seem incredibly buggy...)

>>> As for the framebuffer, as a matter of fact nowadays the display memory
>>> sometimes /is/ genuine main memory.
>>
>> The latest Intel Core-i chips have an on-board GPU. I *presume* that if
>> you utilise this, everything happens in main RAM.
>
> Indeed, this feature is typical for on-chip GPUs. Though I think there
> are also external chips out there that are designed to utilize main memory.

Yeah, I would think all those motherboard with on-board graphics do 
this. (Having said that, those boards are getting rare now all the CPUs 
have the GPU on the die...)

> Well, my graphics card (an ASUS R9 280) utilizes the following resources:
>
> Obviously this is not nearly enough to access all 6 GB of the graphics
> card at once, but .25 GB is certainly large enough for a "window" to a
> portion of the graphics card's RAM; even traditional Super-VGA cards
> used such a window to access a much larger actual framebuffer, using I/O
> registers to choose which "page" of their RAM was mapped to the window,
> so I guess that's exactly the way it's done with today's graphics cards.

So the CPU can only access a limited window at a time. (Mind you, .25 GB 
should be easily enough to hold the entire frame buffer. This becomes 
more of an issue if you're trying to dump 0.8 GB of texture data into 
the card before you start rendering...) And of course, if you're doing 
3D drawing, the CPU has almost nothing to do with it, it's all the GPU.

> And no, you don't need to tell the PCIe controller anything about this -
> unless you're an OS developer and want to place the window somewhere
> else in the physical CPU address space.

So aside from assigning memory mappings, PCIe is transparent to the CPU. (?)

> My presumption is that you'd indeed build the whole ATA command packet
> in memory, but then just tell the HDD controller to transmit it to one
> particular drive. The PCIe bus is totally transparent in this respect
> (except of course for the initial setting-up at system startup). So are
> the peculiarities of the SATA bus.
>
>> or similar. I'd imaging talking to USB devices probably gets crazy.
>> (Given, you know, the arbitrary tree topology...)
>
> I'm sure it is. You don't map individual USB devices to memory
> addresses, nor even I/O addresses for that matter. All you talk to is
> the USB host controller. But again you don't need to worry whether that
> host controller is connected via PCIe, PCI, or even classic ISA.

So, again, the PCIe bus from the CPU to the PATA / SATA / USB / FireWire 
/ whatever controller is transparent, but USB itself isn't transparent, 
and you still need to know how to build ATA commands or whatever. (?)

Post a reply to this message

Am 05.02.2015 um 09:33 schrieb Orchid Win7 v1:

>> As for the sound card, IIRC traditionally it was not memory-mapped. You
>> see, the sound card operates sequentially on non-repeating data, which
>> is exactly the mode of operation the DMA controller was designed for, so
>> to save memory address space for true memory (including devices' ROMs,
>> which are always memory-mapped) the card would present only two I/O
>> addresses for data (one for reading, one for writing). Same for disk I/O.
>
> Intriguing... I didn't know you could do that.

It's actually a quite simple mechanism, at least in basic theory. The 
idea is that the CPU has an input telling it to stall any bus access for 
a moment; the DMA asserts this signal to take over the bus for one 
memory access and another I/O access, then releases the bus again. The 
DMA controller in turn has an input by which the device hardware can 
signal that it is ready to transfer the next byte.

This was great stuff especially in the times when memory could go a good 
deal faster than the CPU could make use of it.

Well, things have changed: Memory access is the biggest bottleneck of 
all now.

>> If you really want to go down to that level, I'd suggest getting a
>> Raspberry PI and trying to write some standalone application (i.e. one
>> that doesn't need an OS) to run on it. The hardware seems to be well
>> enough documented to pull off that stunt.
>
> Or just, you know, the Pi emulator, which doesn't cost money. ;-)

Because a Raspberry Pi is soooooo extraordinarily expensive, sure... :P

Drawback of the Pi emulator is that it doesn't come with all those neat 
I/O pins ;)

>> And no, you don't need to tell the PCIe controller anything about this -
>> unless you're an OS developer and want to place the window somewhere
>> else in the physical CPU address space.
>
> So aside from assigning memory mappings, PCIe is transparent to the CPU.
> (?)

Memory mappings, IRQ mappings, I/O mappings, assignment of number of 
PCIe lanes... But yes - that's the gist of it.

> So, again, the PCIe bus from the CPU to the PATA / SATA / USB / FireWire
> / whatever controller is transparent, but USB itself isn't transparent,
> and you still need to know how to build ATA commands or whatever. (?)

Yup.

Post a reply to this message

>> Or just, you know, the Pi emulator, which doesn't cost money. ;-)
>
> Because a Raspberry Pi is soooooo extraordinarily expensive, sure... :P



Presumably if you hunt far enough you can find one for available at the 


> Drawback of the Pi emulator is that it doesn't come with all those neat
> I/O pins ;)

Pffft. What would I even do with those? It's not like any high-level 
language lets you interface with them anyway. And you'd have to hook up 
a bunch of relays to use them to drive anything that takes more than 
0.3mW of power. :-P

Post a reply to this message

Am 05.02.2015 um 19:49 schrieb Orchid Win7 v1:

>>> Or just, you know, the Pi emulator, which doesn't cost money. ;-)
>>
>> Because a Raspberry Pi is soooooo extraordinarily expensive, sure... :P
>


Ah, yes... if you insist on buying yet another keyboard, mouse, USB hub, 
micro-USB power adaptor, WiFi dongle and HDMI cable with that...

If you already do have those components flying around your house 
somewhere, you /might/ however try ordering a bare Pi mainboard for 18 
to 40 GBP, depending on the model. At Maplin. No further hunting required.


>> Drawback of the Pi emulator is that it doesn't come with all those neat
>> I/O pins ;)
>
> Pffft. What would I even do with those? It's not like any high-level
> language lets you interface with them anyway.


Is Haskell a high-level enough language for your taste? :P

http://hackage.haskell.org/package/HPi


Not to mention C, C++, C#, Ruby, Perl, Python, Scratch, Java, Pascal and 
BASIC of course; you can even control them from the command shell:

http://elinux.org/RPi_Low-level_peripherals#GPIO_Code_examples


> And you'd have to hook up
> a bunch of relays to use them to drive anything that takes more than
> 0.3mW of power. :-P

Well, yeah, that's the usual way to drive anything even remotely 
power-hungry with any digital controller.

As for the 0.3mW, if you go for the Model A you can go up to 0.5mW.

Post a reply to this message

Am 02.02.2015 um 19:16 schrieb Orchid Win7 v1:
> Is it even still *possible* to map the graphics card's
> framebuffer into the CPU's address space?

On Linux (and surely other unix clones): no problem at all!

Just open /dev/fb0, making some ioctl()'s on it to get the size and the
pixel type of the frame buffer and you can call mmap() to the file
descriptor to map the whole frame buffer memory into your address space.

> Similarly, if I want to ask the harddisk to do something, do I need to
> explicitly construct ATAPI commands, or does the chipset do that for me?

just mmap() your /dev/sd* to your address space and feel free to
read/write into it.

> I'm not trying to actually *write* a device driver, I'm just curious as
> to how this stuff works these days.

It works good. And a lot of software use these interfaces today (X
server, database systems etc.)

Lars R.

Post a reply to this message

On 17/02/2015 11:15 PM, Lars R. wrote:
>> Similarly, if I want to ask the harddisk to do something, do I need to
>> explicitly construct ATAPI commands, or does the chipset do that for me?
>
> just mmap() your /dev/sd* to your address space and feel free to
> read/write into it.

Yeah, that's not quite it.

When you ask the kernel "hey, mmap() this file for me, will ya?", what's 
actually happening is that when you try to access those memory pages, 
your application gets suspended while the kernel goes and issues the 
necessary disk I/O commands to read a copy of that file into memory. 
Your application then gets resumed, making it *look like* the logical 
file is indeed mapped into the address space.

This isn't the same thing at all. This is clever software making the 
process *look* simple, which isn't at all the same as the process 
actually *being* simple.

Case in point: you can mmap() files residing on an NFS server on another 
continent. Clearly the CPU and chipset know *nothing* about TCP sliding 
windows and go-back-N acknowledgements. That's why you have a huge, 
complex operating system controlling the CPU. ;-)

What I'm asking is, can the hardware itself map the framebuffer (or 
whatever) into the address space, not whether some program can simulate 
this behaviour.

Post a reply to this message

> What I'm asking is, can the hardware itself map the framebuffer (or
> whatever) into the address space,

Even good-old ISA cards were able to do so (ok only in the first 16 MB
of physical address space *G*). With PCI they became able to tell the
chipset about the size of their "card memory" and the memory controller
in the chipset will respect these in its internal memory mapping (and
tell it to the CPU (and the operating system) so the CPU will disable
its interlal L1 caches etc. for these address ranges etc.)

Just look at /proc/iomem to see how heterogenious the physical address
space is on modern computers.

The mmap() just maps portions of this physical address space into your
logical/program/user address space.

Lars R.

Post a reply to this message

On 18/02/2015 12:15 PM, Lars Rohwedder wrote:
> Just look at /proc/iomem to see how heterogenious the physical address
> space is on modern computers.

Now *that* sounds interesting...

Post a reply to this message