OSDev.org

Posted: **Mon Nov 13, 2006 3:08 pm**

Brendan wrote:Yes. For most (all?) chipsets there's some interesting things to play with.

There's usually some registers in the memory host controller that allow parts of the region from 0x000A0000 and 0x000FFFFF to be set so that reads and/or writes are forwarded to the PCI bus, to RAM, etc. For example, imagine there's a PCI/AGP video card with a ROM mapped to 0x000C0000. If you disable this ROM (using the card's PCI configuration space) then you still can't access the RAM at this address until you tell the memory host controller that reads/writes for the area should both go to RAM (instead of the PCI bus).

Then there's things like the PCI IRQ router, serial port and parallel port I/O base addresses, floppy controller I/O base address, flash BIOS support, power management, hotplug RAM, hotlpug PCI devices, etc. For Intel chipsets there's a complete TCO (Total Cost of Ownership) system for monitoring the system (including watchdog timer, heartbeat, remote/ethernet monitoring, etc). For most onboard devices, the chipset has some control over which I/O APIC input the device is connected to, which can be useful for avoiding IRQ sharing (remembering that the PCI IRQ router only effects PIC connections).

Specifications (like ACPI) cover most of this, but not all of it.

The idea is to provide a way of supporting all of this (with or without ACPI), while providing somewhere where chipset bugs can be worked-around, etc. Despite this, it's very likely that most of my "chipset drivers" will do almost nothing or just use generic ACPI...

Can you get your hands (I am asking because I've yet to try) on the chipset specs? IBM used to sell the technical reference manuals, but I don't beleive most PC/motherboard vendors do, do they? I like the idea of this because it may open up "special stuff" that you can take advantage of for your own OS.

I think it is do-able, to support it without ACPI. This coming from a hardware guy (hobby software guy).

Interesting stuff! There is always something new to learn, eh?

Posted: **Mon Nov 13, 2006 3:18 pm**

AFAIK, most Intel docs on hardware are open. NVidia is keeping everything shut down tight, Ati as well, others might release more but I doubt it. You can check out Via and SiS as well, don't think they're too secluded in documenting for the open.

Posted: **Mon Nov 13, 2006 4:44 pm**

Candy wrote:AFAIK, most Intel docs on hardware are open. NVidia is keeping everything shut down tight, Ati as well, others might release more but I doubt it. You can check out Via and SiS as well, don't think they're too secluded in documenting for the open.

Thanks, I seem to recall Intel's site had a few things there. I'll have to check my MB tonight to see what the chipset is and see if I can play with it.

Do you know if NVidia will sell technical references?

Posted: **Mon Nov 13, 2006 9:42 pm**

Hi,

smiddy wrote:Thanks, I seem to recall Intel's site had a few things there. I'll have to check my MB tonight to see what the chipset is and see if I can play with it.

Do you know if NVidia will sell technical references?

For Intel almost everything can be downloaded for almost all of their products. For AMD I think the information for the memory controller (which is built into their more recent CPUs) is also available.

Information for most "system on a chip" computers is also available - Cyrix MediaGX, NSC/Geode based products (now owned by AMD), some VIA (although they're a little harder to obtain), etc. This is mostly because of the different market - it'd be fairly hard to sell these things without the "chipset" documentation.

For chipsets without publicly available documentation, you can default to generic ACPI (or disassemble their AML code and use that as a basis for a chipset driver), or treat them as generic ISA (with no power management, etc).

I would also assume that companies like NVidea would either provide information (under NDA) or supply their own chipset drivers if your OS gains a large enough market share - e.g. as big as Linux, or possibly smaller if they don't need to worry about issues like GPL (the "everything must be open source code" idea doesn't seem too attractive to companies trying to protect trade secrets). In general, unless you can show them what you've done for other manufacturers products, and they recognise your product, there's no point in asking.

Of course in practice there's problems with developer time and being able to test the chipset driver properly. It'd probably take me a month or 2 to implement each chipset driver, and out of the machines I have here I can probably only get information for 2 or 3 of them.

It's likely I'd only worry about doing an Intel 865 chipset driver (and possibly a "Bochs only" Intel 440FX chipset driver), and when I'm confident it works reliably release the full source code and then move on to other things. Later on other people can write chipset drivers for other chipsets based on the documentation for the OS, the documentation for the chipset, and the source code for the initial chipset drivers.

For me the goal is to make sure the framework is present to allow device drivers to be implemented, rather than actually implementing as many device drivers as I can. When my OS is much more complete the goals may change, but I don't expect that to happen in the next 5 years...

Cheers,

Brendan

Posted: **Tue Nov 21, 2006 1:31 pm**

How long ago does the memory need to be configured before use on the PC? Did the IBM PC worked that way?

PS: I guess LinuxBIOS can provide some information about the internals of some memory controlers...

JJ

Posted: **Tue Nov 21, 2006 3:59 pm**

Hi,

João Jerónimo wrote:How long ago does the memory need to be configured before use on the PC? Did the IBM PC worked that way?

I'd guess early 80486 based systems or maybe earlier (but that's only a guess). The oldest chipset documentation I have (Intel 440FX, for Pentiums) has chipset control for several memory holes, SMRAM access control, and the area from 0x000C0000 to 0x000FFFFF is split into 13 seperate banks (where reads and writes for each bank can be configured to go to RAM or to the PCI bus).

The original IBM PC supported between 16 KB and 640 KB of RAM - there wasn't any need for a memory controller....

Cheers,

Brendan

Posted: **Wed Nov 22, 2006 4:02 pm**

Brendan wrote:Hi,

João Jerónimo wrote:How long ago does the memory need to be configured before use on the PC? Did the IBM PC worked that way?
(...)

The original IBM PC supported between 16 KB and 640 KB of RAM - there wasn't any need for a memory controller....

So the BIOS could access RAM right from the start?
But the CPU address BUS couldn't be directly connected to the memory's one, cause that way was impossible to memory map video RAM...

JJ

Posted: **Wed Nov 22, 2006 6:52 pm**

Hi,

João Jerónimo wrote:
Brendan wrote:The original IBM PC supported between 16 KB and 640 KB of RAM - there wasn't any need for a memory controller....
So the BIOS could access RAM right from the start?
But the CPU address BUS couldn't be directly connected to the memory's one, cause that way was impossible to memory map video RAM..

Back then, there was a single bus (the ISA bus) for the entire system and every device attached to this bus (except the CPU) had a "decoder". When the CPU tries to access anything it puts the address on the bus and waits for something connected to the bus to respond. Each device decodes the address to see if it should respond, and responds if it should.

For the RAM, there was 3 little switches on the motherboard to set the address of the top of RAM, and the decoder would've been some simple logic - something like:

Code: Select all

   If( (address >> 16) < switches) then let ISA bus drive RAM chips

For the BIOS's ROM you'd have another decoder, like:

Code: Select all

   If( (address >> 16) == 0xF) then let ISA bus drive ROM chip

For the video card, you might have something like:

Code: Select all

   If( (address >> 16) == 0xB) then let ISA bus drive display memory

Cheers,

Brendan

OSDev.org

Motherboard Chipsets

Motherboard Chipsets