Srinivas wrote:
> Hello,
>
> I have a theoretical understanding of the PC architecture and the
> details but have no idea of how things go under the hood(for a real
> computer). I think it would be very useful for me(as well as
> beginners) to know how things work real-time. Even though it is not a
> correct mailing list, I am posting this because you guys are the real
> hackers and know a lot about how things work inside.


As Jeroen said, to get any kind of useful knowledge (e.g. something you
can do real work with) you should read the books on the topics. These
topics are, from one side, very complex, and from the other, very
useless unless you're going to program device drivers and low level
kernel facilities. They are rarely (if ever) needed even for hard-core
sysadmin work and even most embedded work. If you just want a birds-eye
overview, I'll try to say something about the topics (and wait for
laughter from the really knowledgeable people ).

> I would like to know about the following. Plz add anything which you
> think will be helpful for the beginners.
> 1. Schematic diagrams of motherboards


This won't help you in any way except if you need to design
motherboards, in which case you need a multi-year education. Any high
level overview will be equally good, but the story usually goes "You
have this thing called the CPU, right, and you have these other things
called memory, the north bridge, the south bridge, the PCI slots. They
are all connected with various buses (and I mean really various). The
north bridge has the memory controller and some control of the low-level
CPU functions. The south bridge has the PCI controller and various other
integrated controllers like IDE, COM, sometimes sound, network &
graphics". Install "dmidecode" from ports/sysutils and if you're lucky
enough to have a good motherboard, you'll see what's connected to what
(and how many volts are used by it).

> 2. How a bios detects various kinds of buses


It usually asks the bus controllers what they know. It knows about the
low-level bus controllers from its own embedded data. The BIOS, of
course, knows how to communicate with the devices it contacts directly,
because it's created for the purpose of supporting them. Note that the
"BIOS" is just a software program, executed on the CPU as any other,
when the machine boots. Once a modern operating system is loaded,
everything is done by its device drivers and the BIOS is almost never
accessed after that.

> 3. How bios and os detects the different devices present in the system
> and what are their capabilities


It asks every device found on a bus, found by a bus controller, what is
it and what it does. There are really few capabilities that the devices
themselves have to say about themselves at this point - most of it is
low level stuff like electrical capabilities, what connectors and
interrupts they have. Even though devices have broad "groups" of
functionalities (like "Ethernet controller") they can report back, the
OS and the BIOS cannot really do anything with them - this is where
drivers come along. When a new device is found, internal tables are
searched to discover if there's a driver that can handle the device
(devices are identified by numbers; run "pciconf -lv" for examples). If
there is, the driver is left to do with the device as it sees fit.

> 4. How interrupts are routed inside


Some of the chips or parts of the north bridge chipset are "interrupt
controllers", which are programmed by the BIOS and the OS to map device
interrupts (i.e. "pci bus X, device Y, function Z") to CPU/software
interrupts (like "irq 18"). These interrupts are then handled by
specific drivers (run "vmstat -i" for a table which interrupts are used
by what driver).

> 5. Groups where we can communicate related information


I don't know any. Device driver writers or hardware designers would be
my best guess. This particular group is read by FreeBSD developers,
which are mostly software developers - you'll probably want to seek
direct answers someplace that's specialized for the topics.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj3YXgACgkQldnAQVacBcgL9ACg9sWHQimS1A kDUizQET6XXpA+
kqMAoIn7F+PU+sGnRSyo9Q326fA0DBfS
=NKGS
-----END PGP SIGNATURE-----