In the following, the three kernel drivers will be described. During the description of the driver interfaces the expression “from the kernel users point of view” is used. By this is meant, the functions in the interface that are of relevance for the kernel user e.g. a person implementing processes to run on the nano-kernel.
10.7.1 Timer driver
On Intel based architectures it is normal to create a timer using the 8253A chip, which is placed on almost all Intel based motherboards. In the
10.7 Kernel drivers 77 MIPS64 CPU there are two registers, which are very useful when creating a timer, namely thecount andcompare registers. These two registers will be used for the timer implementation instead of the usual timer hardware.
Thecount register acts as a timer, incrementing by one every other clock cycle, whether or not an instruction executed. The count register can be written for diagnostic purposes as it is during boot in this kernel. This register is 32 bits long.
Thecompare register is used in conjunction with the count register. The compare register contains a value, which does not change unless explicitly updated by software. When the value of the count register is equal to the value of thecompare register, hardware interrupt 5 is asserted and the interrupt pending bit is raised in thecause register. Hardware interrupt 5 is asserted and continues to be asserted, until the compare register is written to by software. This register is also 32 bits long.
From the kernel users point of view, the interface to the timer driver consists of four functions, which are implemented in the filetimer.c:
timer_setup This function initializes a timer structure.
timer_start This function starts the timer.
timer_waitfor This function blocks the process until the time is up.
timer_cancel This function cancels a timer. This function must be used if the timer is no longer in use.
Table 10.5: Timer interface
10.7.2 LCD driver
The LCD display is a small 1x8 characters wide LCD display mounted on the Malta board. The LCD display can be used for debugging purposes or just to show off. The driver is extremely simple, and is used for writing characters or numbers on the LCD display mounted on the MALTA board.
The LCD display works by writing to the addresses listed in table 10.6.
The interface to the driver consists of the two functions listed in table 10.7.
Name Offset Function
ASCIIWORD 0x000.0010 Writing a 32-bit number to this address will cause the LCD display to show the number in hex on the display
ASCIIPOS0 0x000.0018 Writing an ASCII value to this address updates position 0 on the LCD display ASCIIPOS1 0x000.0020 Writing an ASCII value to this address
updates position 1 on the LCD display ASCIIPOS2 0x000.0028 Writing an ASCII value to this address
updates position 2 on the LCD display ASCIIPOS3 0x000.0030 Writing an ASCII value to this address
updates position 3 on the LCD display ASCIIPOS4 0x000.0038 Writing an ASCII value to this address
updates position 4 on the LCD display ASCIIPOS5 0x000.0040 Writing an ASCII value to this address
updates position 5 on the LCD display ASCIIPOS6 0x000.0048 Writing an ASCII value to this address
updates position 6 on the LCD display ASCIIPOS7 0x000.0050 Writing an ASCII value to this address
updates position 7 on the LCD display Table 10.6: LCD display addresses. Base address is 0x1f00.0400
lcd_int Takes an integer as argument an prints it in hex on the LCD display.
lcd_message Takes a string as argument and displays the eight first characters on the LCD display.
Table 10.7: LCD driver interface
10.7 Kernel drivers 79
10.7.3 Serial terminal driver
This driver controls the serial VT220 terminal connected to the Malta system’s serial port.
The serial port on the MALTA board is controlled by a Super I/O Con-troller from SMcS and incorporates two full function UARTs. The file serial.hdefines all the register addresses in the UART and most of the register settings.
As of this writing, input on the serial line is not supported, but it should be fairly simple to implement, as the interrupt handler is already registered to receive the data from the UART. Since, DMA is not supported by the Super I/O Controller, the data should simply be read from directly from the memory mapped serial buffer.
Initialization
The VT220 terminal is configured to run at 19.200 baud, with 8 bit data, one stop bit and no parity, so the serial port in the Super I/O Controller has to be initialized the same way.
The serial port contains a programmable Baud Rate Generator that is capable of dividing the internal UART clock by any divisor from 1 to 65535.
The clock runs at 1.8462Mhz and the output from the Baud Rate Generator is 16 times the baud rate, therefore, to set the desirable baud rate, the divisor is calculated like this:
Baud rate divisor=U ART clock speed 16×bps
Inserting the numbers in question the resulting baud rate divisor is:
1846200Hz 16×19200bps = 6
The baud rate divisor is therefore 6, when a baud rate of 19200 is desired.
This value should be written to the divisor registers. The high register with the value 0 and the low with the value 6. These registers are the same as
the transmitter and receiver registers, so a special bit (DLAB) has to be set high to tell the serial port that the baud rate is going to be set.
The rest of the configuration of the serial port is done by writing to the Line Control Register.
The interrupt is not initialized, since the input is not read anyway. Initial-ization of this interrupt should be located in the functionserial_init along with the rest of the serial terminal initialization.
Serial terminal driver interface
From the kernel users point of view the interface to the serial terminal driver consists of two functions, see table 10.8. Through these functions special control characters can be sent to the serial terminal to control cur-sor position and to print characters an the terminal. These functions are implemented in the fileserial.c.
serial_putchar Prints a character on the terminal.
serial_print Prints a string on the terminal.
Table 10.8: Serial terminal interface
In future development this driver should be split into two, one for the UART itself and one for the VT220 terminal using the UART, but during the kernel development this implementation has been sufficient.