Table of important things!

[OSMAN]

Hi.

I've noticed that writing a kernel needs a huge knowledge(or a table next to me) which tells me ALL the memory areas allocated by hardware. And I need to know all the device ports. (, I think I've mentioned before.)

NOW, do anyone of you have these tables of knowledge about what I mean?
(of course you do, 'cause you're writing OS:s)
Where can I get those tables? (I guess not from Mega-Tokyo.com)
(And I don't want the famous "Intel's 'billion paged' manual"!)

[Crazed123]

Well, you can get knowledge about memory areas by reading a memory map generated by the BIOS or GRUB.

For device ports the driver pretty much has to know ahead of time, so for a table I would consult your hardware specifications, or Google.

[AR]

(And I don't want the famous "Intel's 'billion paged' manual"!)

If you're referring to the Intel Systems Programming reference then that's like saying "I want to build a house during the night without lighting the worksite because I like running around in the dark and bumping into things", it might seem fun at first but it will come back to get you in the end.

[Pype.Clicker]

Hi.

I've noticed that writing a kernel needs a huge knowledge(or a table next to me) which tells me ALL the memory areas allocated by hardware. And I need to know all the device ports. (, I think I've mentioned before.)

That will be pretty hard to find, because each device / BIOS will require different size of memory. There _are_ regions that are locked on _every_ PC (see the FAQ), but for the rest, asking the BIOS is the only reliable way.

NOW, do anyone of you have these tables of knowledge about what I mean?
(of course you do, 'cause you're writing OS:s)
Where can I get those tables? (I guess not from Mega-Tokyo.com)

Afaik, there should be a list of common I/O ports in Ralf Brown's Interrrupt List (or associated documents), which you can find a pointer to in the FAQ or in the QuickLinkz. We indeed do not have a copy of that material on MT because 1) it's huge 2) it's someone else's job so we would be lamers if we just cloned it here.
(And I don't want the famous "Intel's 'billion paged' manual"!)

That being said, again, that list will only give you the list of _standard_ IO ports. It will tell you nothing about your RTL network card, your SoundBLaster Live! or your RIVA TNT graphic card.
The only way to know what's on your system on that point is to perform PCI enumeration and see what devices are there and what ports the BIOS have assigned to those devices.

[OSMAN]

Now I am confused. YOU are making OS:s ! Where have you took those what I'm looking for ? Why is it so difficult to have them here. I think those port- and memory tables shouldn't be anyone's property (open-source you know)!

Have you read the Intel's manual? Where did you get your knowledge?
If there's no other way than "just know them" or "google whith wrong results ", I WILL READ THE INTEL'S MANUAL THEN! >:(

( Could you even give me some links please? ) :-\

PS. Wasn't Ralph's Int. List just for DOS wasn't it.

[Xardfir]

Hiya,
Ralph Browns Interrupt list has been around for at least 15 years and details, bios, dos and a lot of basic hardware. It can be downloaded (not sure of the address - just google for it).
The book recommendation list also contains many good recommendations for info - that's what writing was invented for.
My recommendations - Indispendable PC hardware (Hans pieter Messmer). Try to get the third edition, the fourth IMHO has had too many edits.
Another good hardware series is from Addison Wesley. These books go into great detail about ISA/EISA\MCA, PCI, USB, Firewire, AGP, All Pentium Processors (Pentium 4 unabridged goes deep into protected mode etc). Theres even info for PowerPC programming.
Apart from the MOST EXCELLENT OSFAQ (link at top of screen) you could google for Bona-Fide OSDEV, Freebyte, OSRC and alexfru.narod.ru. The last one get's kinda slow (its cold in Sibiria!) but there's a lot of good low level stuff.
Basically whilst the WWW is good - dead trees to me are still the best way to get information.

[Solar]

I've noticed that writing a kernel needs a huge knowledge(or a table next to me) which tells me ALL the memory areas allocated by hardware.

The problem is that each part of the hardware does its own allocation. The BIOS does supervise how e.g. PCI cards do their allocations. But what is allocated is defined by the card.

And I need to know all the device ports.

That is what is commonly called a "device driver": A piece of code that "knows" about a specific device, and enables the kernel to access that device through a "standard" interface. For example, your kernel will want to read from and write to a hard drive. You will need device drivers to translate those calls into ATA or SCSI or USB commands, which means you have to get your hands on the technical documentation for the ATA / SCSI / USB controller you are using (or the one you want to support, anyway).

Some of them are pretty generic, some of them are pretty specific to the chipset used.

But that's not strictly kernel development, but driver development. You could have the world's greatest kernel, but you'd still need a large library of available device drivers to get anywhere...

NOW, do anyone of you have these tables of knowledge about what I mean?
(of course you do, 'cause you're writing OS:s)

I don't think I like your tone, here. Trust in us that we would provide that info if it were that easy.

Where can I get those tables? (I guess not from Mega-Tokyo.com)

No, from the individual device / chipset vendors. Sometimes for free from the web, sometimes only if you're a big company, pay big bucks, and sign an NDA. Sometimes not at all.

(And I don't want the famous "Intel's 'billion paged' manual"!)

Then forget about writing a real OS.

Now I am confused. YOU are making OS:s ! Where have you took those what I'm looking for ?

The thing is that you are confused about what you are looking for.

Why is it so difficult to have them here.

Because they are intelectual property of those who developed it, and some of those don't believe in sharing that property.

I think those port- and memory tables shouldn't be anyone's property (open-source you know)!

I agree (but I understand the standpoint of the HW manufacturers, too).

Have you read the Intel's manual?

Yep. It's the technical documentation of the CPU, so you basically have to read it. (Or read tons of tutorials which basically copy & paraphrase the information from the Intel docs, sometimes introducing errors and not telling the whole story of what you could do different from the tutorial author's approach.)

If there's no other way than "just know them" or "google whith wrong results ", I WILL READ THE INTEL'S MANUAL THEN! >:(

No reason to become angry. And be aware that it will tell you everything about the CPU, but nothing about the BIOS, PCI, networking devices, VGA, ...

( Could you even give me some links please? ) :-\

All we could give is in the FAQ (click the banner) and the Quick Links thread.

PS. Wasn't Ralph's Int. List just for DOS wasn't it.

Yes and no. In DOS, you had full access to the BIOS functions, so the RBIL includes all BIOS functions in addition to those provided by DOS and its applications.

As the BIOS is the central OS / hardware interface, you need the RBIL even if you never touch DOS with a stick.

[Xardfir]

Finally worked out how to reverse a bookmark!
Try here -
http://www.osdever.net/cottontail/
Cottontail archive includes just about everything PUBLIC you might need. Use the 'archived links' not the 'link to site'. This is why it's called an archive. Of course using the information effectively is a completely different proposition ......

[Pype.Clicker]

( Could you even give me some links please? ) :-\

down there
----------------------------------- \/

[Brendan]

Hi,

Some explanations might help...

Firstly, most of what you're asking for doesn't exist, and will never exist. Normally, for a list of resources (IO ports, memory areas, IRQs, etc) an OS asks the Plug & Play BIOS and/or PCI BIOS and/or ACPI BIOS and/or auto-detects.

The reason for this is that a large number of things don't use fixed/pre-defined resources. For example, a PCI device or ISA Plug & Play device is configured by the BIOS and/or operating system during boot, so it's impossible to predict which resource it will end up using without knowing exact details of the motherboard/chipset, BIOS, the device itself and all other devices plugged into the computer.

Another example is USB devices, which don't use any IO ports, memory locations, IRQs or DMA channels, but instead rely on the USB controller (which itself is a PCI device that's auto-configured during boot).

This only leaves a set of "standard hardware", which typically dates back to the "IBM PS/2" computers (over 20 years old) and are mostly obsolete. These devices are covered by Ralph Brown's lists (see below), but typically includes:

• The BIOS ROM (or part of it at least)
  Memory usage below 1 MB (with a few quirks, like the EBDA)
  The RTC/CMOS (the first 64 locations anyway)
  The PIT (being replaced by the local APIC timer)
  The ISA DMA controller chips (not used by much other than the floppy drive now)
  The PIC chips (being replaced by IO APIC chips)
  Serial ports (if any - being replaced by USB)
  Parallel ports (if any - being replaced by USB)
  
  The floppy disk controller/s (if any - being replaced by USB or made obsolete)
  The PS/2 keyboard/mouse controller chip (if any - it's being replaced by USB devices, but will probably be emulated for backwards compatability reasons)
  The "legacy" IDE hard drive interface (if any - diskless computers or SCSI are valid alternatives) - even though it's obsolete it's maintained for backwards compatability reasons
  Standard VGA might also be emulated (depending on the video card/s installed, if any), even though it's obsolete

Have you read the Intel's manual? Where did you get your knowledge?
If there's no other way than "just know them" or "google whith wrong results ", I WILL READ THE INTEL'S MANUAL THEN! >:(

Take my advice and start reading here:
http://pdos.csail.mit.edu/6.828/2004/re ... 86/toc.htm

Once you've read all of this, move on to more complex stuff like these documents:
http://developer.intel.com/design/penti ... ex_new.htm

And then perhaps check out the links at the bottom of this page:
http://developer.intel.com/technology/64bitextensions/

Of course this is only the beginning (there's other extensions) and it only covers the CPU itself. There's much more documentation like this (USB, PCI/AGP/PCI-express, ACPI, EFI, etc, etc), Then there's datasheets for smaller chips (serial, parallel, floppy, etc) and a pile of specifications (Plug & Play, boot CD, USB boot, USB device classes, etc, etc) followed by RFCs (notworking protecols, etc).

Let's be honest here, being able to find, read and understand technical documentation is one of the requirements of OS development. The "writing code" part of it should always be preceded by reasearch, design and creating your own documentation of how it your code should work. Only after all of this should code be written (and no, I'm not joking).

PS. Wasn't Ralph's Int. List just for DOS wasn't it.

The full "Ralph Brown's Interrupt List" does contain files on real mode interrupts and IRQs (just like the online HTML version), but also contains a list of standard IO ports, a list of CMOS/RTC contents, a list of memory locations and a pile of other stuff (I2C bus, MSRs, opcodes, SMM, etc).

Perhaps you might try this link:
http://www.cs.cmu.edu/afs/cs/user/ralf/ ... files.html

Of all of it, the IO ports list is the most useful (although not as useful as the technical documentation, datasheet or specification for the specific chip or device you're researching).


Cheers,

Brendan

[Pype.Clicker]

you shall love http://www.intel.com/design/chipsets/da ... 147302.pdf too. That's full of tables with ports numbers, etc. Be aware, however, that other vendors might have other number for some of the stuff... see

http://www.amd.com/us-en/assets/content ... /24674.pdf