OSDev.org

Hi,

i am creating my own Os 100% assembly, i would like to know is if embedded clock generator in "standard" motherboard needs a driver to work.

Thank you in advance.

i am on x86-64 in protected mode.

That depends, what a driver is for you.

A program which controls a component. Being in protected mode i can not use the bios, i have to write all from scratch, so must i write that one of clock generator ?

There are several "clocks" on the motherboard, and you'll eventually need to support communicating with all of them, for various reasons.

The CMOS Real Time Clock is the only one that works when the machine is turned off, so it's essential that you be able to read this one. Since all PC-compatible systems have had the same CMOS Real Time Clock support since the 70's, you probably won't need a "driver" that can be dynamically loaded/unloaded, though. You can just have a kernel API method that reads the clock and returns the date/time information in some standardized format.

If you want your OS to run on more than just PC compatible machines, however, then you'll probably want this logic in a separate driver so that it won't be loaded unless you are running on a PC compatible machine.

Hopefully, that all makes sense. Let us know if you have any other questions.

Thank you a lot for this explanation. If i understood correctly, CMOS clock does not need a driver and this only send data and is not settable ? I did not see this section "Clocks, Timers and Counters" i am going to read it and may be i will come back here for other questions.

Ok, i quickly read but i do no understand if all these clocks are in my motherboard, which different clocks are present in "modern standard" motherboards ?

PIT, CMOS Timer, APIC Timer

Ch4ozz wrote:PIT, CMOS Timer, APIC Timer

I'd rather use the CMOS as a clock and not a timer. You forgot to mention HPET, by the way. It's also very common on modern motherboards, but it needs to be detected. For the OP, it'd be easiest to use PIT in this stage, and when you have SMP or something, then use the local APIC timer.
P.S.: OP, the fact that your OS is written in assembly is irrelevant.

Hi,

Factorisable wrote:Ok, i quickly read but i do no understand if all these clocks are in my motherboard, which different clocks are present in "modern standard" motherboards ?

For a quick summary:

• PIT is the oldest. On "bleeding edge" new hardware it may not exist (replaced by HPET, and potentially emulated in SMM/firmware for legacy OSs).
• RTC is almost as old as the PIT. It can be thought of a 2 pieces - the time and date (and update in progress interrupt and alarm interrupt), and a periodic IRQ that can be set to a fixed frequency (from 2 Hz to about 8192 Hz). Like the PIT, the periodic IRQ part might not actually exist and can be emulated by SMM/firmware using HPET instead.
• The CPU's time stamp counter is about 20 years (Pentium and later); but it was originally just a counter and couldn't generate an IRQ.
• Local APIC timer has been present on multi-CPU systems since the 80486; and became common on single-CPU about 15 years ago. You can assume it exists for anything modern. Recent CPUs added a "TSC deadline mode" which might not exist on CPUs that are about 5 years old or older (which gives you a way to use the extremely precise TSC to generate an interrupt).
• ACPI timer is probably about 20 years old now. It exists on anything that supports ACPI; but it's just a counter (intended to be used for measuring how long things have been idle) and can't generate an IRQ.
• HPET started existing (and becoming relatively common) about 15 years ago. It might or might not exist and you should check ACPI to determine if it does.

Note that normally you need different timers for different purposes (e.g. something to keep track of "wall clock time", something for scheduler to use for preempting tasks that have had enough CPU time, something for measuring how long things have been idle, etc). I'd recommend detecting what kinds of timers exist and their capabilities during boot, then (dynamically, during boot) deciding which timers to use for each of the different purposes. That way (with nice enough abstractions) the OS can auto-configure itself to use the best timers that happen to be available on any computer.


Cheers,

Brendan

Factorisable wrote:Hi,

i am creating my own Os 100% assembly, i would like to know is if embedded clock generator in "standard" motherboard needs a driver to work.

Thank you in advance.

Everything needs a driver, codec or subsystem in a system, no matter if it's just a small function or a tiny template. It could change or expand in the future, so it's better to keep things clean and encapsulated.

Thank you very much all.

It depends on the structure of your operating system:

If you're writing a monolithic kernel, you'll probably want to integrate the code for operating the clock chip directly into the kernel, and then it's up to you to decide which "code for doing stuff with hardware" in your kernel is "drivers" and which is just "code for doing stuff with simple hardware that doesn't need a separate driver" - for example, a lot of people who write monolithic kernels integrate PS/2 keyboard functionality directly into their kernel: some call it a "PS/2 keyboard driver" and some just call it a "blob of code for reading from the keyboard"; with a monolithic kernel the distinctions between these parts of the system are up to the developer and are purely semantic, and don't really have any effect on the actual design of the kernel (which is one of many reasons why I think that monolithic kernels are very inelegant, by the way).

If you're writing a modular kernel, you'll probably want to separate all of the "code for doing stuff with hardware" into separate modules based on the hardware that it works with and/or the function that it performs - in that case, you'll probably call each "module that does stuff with hardware" a driver. (It's up to you which modules are built directly into the kernel and which are loaded from disk, but an important part of a modular kernel is that each module is isolated from the rest and will work equally well no matter how it gets into the kernel; as long as it's available in memory at runtime then it can perform whatever task it is supposed to perform.)

If you're writing a microkernel, you'll probably have a subsystem for each group of hardware based on the function that it performs. Those subsystems will be responsible for interfacing with the hardware or passing requests to lower subsystems. Should a subsystem need to interface with hardware, you might design the subsystem with "built-in" support for the related hardware, or you might design the subsystem to load a driver for the hardware (where the driver may take the form of a dynamically-loaded library, for example, that the subsystem can call into to perform operations on the hardware). Again the distinction is up to you to decide which hardware support should be built into subsystems and which hardware support should be loaded via drivers - generally you'll put support for generic/standard hardware (hardware that's the same throughout all supported computer systems - such as PS/2, FDC, PCI bus, clocks, timers, etc.) directly in the subsystem, and support for hardware that might differ and require different drivers would be put in a dynamically-loaded library (so that the library appropriate for the hardware detected by the subsystem can be loaded by the subsystem and the subsystem can treat the hardware abstractly from then on - e.g. one network card vs another where the cards are operated differently but the library provides a standard "send ethernet frame" function that the networking subsystem can call).

In short:

• Monolithic kernel: The decision to make something a driver is purely semantic and it doesn't really matter what you call a blob of code that interfaces with hardware. In the case of a clock chip, it's up to you whether or not you choose to call your code a driver.
• Modular kernel: Anything that isn't part of the core functionality of the kernel is put in a module, and this includes support for hardware. Therefore, any hardware will need a kernel module to support it, and this module is typically called a driver. In the case of a clock chip, you'll probably write a module for it and call it a driver.
• Microkernel: If the hardware is common to all supported computer systems, the code to interface with it will probably be part of the subsystem that uses the hardware, otherwise it's typically put in a dynamically-loaded library to abstract differences between hardware that performs the same function. In the case of a clock chip, you'll probably include the code to interface with the clock chip as part of the subsystem that manages clocks, calendars, timers, alarms, and so on.