OSDev.org

Hello,

I found that you can "communicate" with hardware using Assembly in C like here: https://wiki.osdev.org/Inline_Assembly/Examples category I/O access.

As far as I understand, for example function outb will set some value at some port. First question what is that port? I know only ports in network, is that port something like address of specific hardware?

Where can I find all ports what can I use?

Be forewarned, writing incorrect values to an I/O port can do damage to the hardware it is attached to. You should really read up on the hardware you wish to program, the types of ports it has, Port I/O or Mem-mapped I/O, are the registers Write Only, Read Only, Write Clear, Write One, etc.

Find a good resource on the hardware you wish to write to before you start writing to the I/O port(s) in question.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

Oh really inserting values into ports can damage hardware?

So if I will learn I/O in Virtual Machine like VirtualBox then it is safe, right?


Can someone tell me what does this commands do?




I know that inb is for getting values from port and outb is for putting values at specific port.

But what does that dN, a and =a mean?

(That almost sounds sarcastic )

Using an emulator is a safe and usually best practice when doing things of this sort.


This is Compiler/Assembler specific. This is part of the compiler being used to compile the inline assembly code. This particular compiler uses that syntax to let the writer tell the compiler about the instruction and registers used.

Ben

I didn't mean it as sarcastic



Yes I know that it is inline Assembly in C, and I understand that it is used to communicate with hardware ports, but I don't understand that parameters like dN, a and =a.

That question is hardly relevant to OSDev. That is about GCC's inline assembly syntax, which if you want to use inline assembly, you need to know.

You need to learn to use Google. You can find answers to your questions there; it is recommended that you do some research before posting questions here. Also, search the wiki.

@BenLunt: Could I ask you to expand on the statement that hardware can be damaged by writing to I/O ports?

I know that, at one time, careless programming of a video card could damage a CRT monitor, but I don't know of any other examples. It would be very useful to have a list of hardware that could be damaged in this way.

yes it would be useful to have a list like this. Let me start a list:

1. All of them
2. see 1

(smile)

There are few, if any, hardware devices that will watch for and catch harmful programming. That would be too expensive to implement. It is assumed that you as the programmer will read the documentation, understand the documentation, and write "unharmful" code.

Granted, writing bogus data to most hardware will simple place the hardware in an unknown state. However, there is other damage that can be done as well.

For example, the RTL8169 network card will dump its internal counters to a buffer you specify. If you write bogus data to the buffer register, then set the command byte to dump the internals, again by writing bogus data to that register, the card will write to the address specified. This address could be an address within your kernel's task management code, re-writing the task manager. What kind of damage could come of that?

The point is, to program hardware via direct access (Port I/O or mem-mapped I/O), you need to know what you are doing.

Ben

Hi,



How about, none? For this scenario the chance of permanent hardware damage is insignificant and the most likely end result is that the OS will crash.

Things that can damage hardware (that I know of) are:

• Setting a "too high frequency" video mode (either correctly or incorrectly) can cause some ancient CRT monitors to "blow up" and never work again; which is about the only good thing you can do with these old CRT monitors.
• On some cheap and nasty notebook/laptops; setting a dodgy video mode can cause the liquid crystals to overheat/boil and cause permanent damage to the screen.
• For floppy drives, if you repeatedly slam the heads against the stops (e.g. by continually sending it to "track 128") you'll eventually break the drive (might take a several hours)
• Under (typically incredibly unlikely) conditions it might be possible to "accidentally" overwrite the firmware's ROM and brick a computer.
• If you enable "ACPI mode" (to disable firmware's SMM handler) and then fail to handle ACPI events (from thermal sensors, etc) properly, for some relatively rare CPUs where the thermal shutdown is buggy you might overheat the CPU badly enough to damage it.
• For some chipsets (intended for "gamers") there's an incredibly small chance of "accidentally over-overclocking" the CPU, memory or GPU so badly that it causes damage (typically in a "higher risk of future failure" way).

Cheers,

Brendan

Hi Brendan,


And that was my point exactly. If the (RTL8169) write is where the current task manager happens to be, this will destroy the task manager, disable task switching and do who-knows-what. Yes, most likely crash, but isn't this damage?

Anyway, I think the OP gets the idea.

Ben

Hi,



"Damage" usually implies permanent hardware damage. "Crash" usually implies that software stops working but there's no permanent hardware damage and you can reset the computer and everything will be fine.

What you're really trying to do is discourage "trial and error software development" (prevent people from wasting their time trying silly things because they didn't read the datasheet or specification for a device and have no idea what they're doing), which is good (until you start trying to scare people stories about damage). The problem is that sometimes beginners will be too scared to test their code on real hardware because they've over-estimated the chance of causing permanent hardware damage (e.g. because they think that one trivial little bug anywhere will probably cost them $1234 to replace their laptop); where the reality is that being bitten by a shark while on dry land on a calm day is probably more likely accidentally causing permanent hardware damage.


Cheers,

Brendan

Yes indeed. My thoughts exactly, though you put it much better than I did.

Ben