This BSP supports a standard Intel/AMD PC on i386 and up CPUs. If run on a Pentium or above, the TSC register is used for timing calibration purposes rather than relying entirely on the i8254. Partial support is implemented for more modern PCs which do not have a complete complement of legacy peripherals.
The BSP is able to utilize up to 3 GB of available RAM and up to 16 CPUs. Hyper-threading is supported, but may not be detected by the BSP successfully.
BSP capability to detect target hardware SMP details is limited due to fact the SMP support is implemented based on Intel Multi-Processor Specification (MPS). Final version of the specification is version 1.4 which was released on July 1, 1995. On most newer machines the MPS functionality was more or less supplanted by more modern ACPI (Advanced Configuration and Power Interface). Still, on some machine SMP support may be fragile at least at the platform detection and initialization state depending on the target BIOS/ACPI/MPS compatibility implementation.
There are several BSP variants provided which differ only in the target CPU optimization. The most general is pc386 which is tuned for i386. The pc486 variant is tuned for i486, pc585 is tuned for Pentium, pc586-sse is tuned for Pentium processor supporting SSE instructions. Finally pc686 is tuned for Pentium Pro processor, but generating only instructions for Pentium and pcp4 is tuned and generating instructions for Pentium4 processor including SSE3 instructions.
22.214.171.124. Build Configuration Options¶
If defined to a non-zero value, then print a message and wait until any key is pressed before resetting board when application terminates (disabled by default).
If defined to a non-zero value, then reset the board when the application terminates (enabled by default).
If defined to a non-zero value, then print the exception context when an unexpected exception occurs (enabled by default).
If defined to a non-zero value, then print more information in case of a fatal error (enabled by default).
Enables VGA console driver (enabled by default).
Enables support of COM1 thorough COM4 (enabled by default).
Enforces usage of COM1 as a console device (disabled by default).
Enables legacy IDE driver (enabled by default).
Allows RTEMS to use storage drive(s) connected to the primary IDE interface. Disable if (i) the target hardware does not have primary IDE interface or (ii) it does not have any drive attached to the primary IDE interface or (iii) there is no need to use drive(s) attached to the primary IDE interface at all (enabled by default).
Allows RTEMS to use storage drive(s) connected to the secondary IDE interface. Enable if (i) the target hardware does have secondary IDE interface and (ii) there is at least one drive attached to the secondary IDE interface and (iii) there is a need to use drive(s) attached to the secondary IDE interface (disabled by default).
Sets the VGA display to 80x50 character mode (disabled by default).
Enforces clock driver to use TSC register available on Pentium and higher class CPUs. If disabled and
CLOCK_DRIVER_USE_8243is disabled too, then BSP will choose clock driver mechanism itself during the runtime (disabled by default).
Enforces clock driver to use 8254 chip. If disabled and
CLOCK_DRIVER_USE_TSCis disabled too, then BSP will choose clock driver mechanism itself during the runtime (disabled by default).
Defines how many descriptors in GDT may be allocated for the application or driver usage.
Enables usage of Cirrus GD5446 graphic card for RTEMS frame-buffer (disabled by default).
Enables usage of generic VGA graphic card for RTEMS frame-buffer (disabled by default).
Enables usage of graphic card implementing VESA BIOS Extensions for RTEMS frame-buffer (enabled by default).
Enables GDB support for debugging over serial port (enabled by default).
126.96.36.199. Runtime Options¶
The BSP supports several runtime options. They may be used by either setting
during boot by using target hardware bootloader or by using Qemu’s
-append command-line parameter in case BSP application is run
inside the Qemu emulator.
specifies console device. E.g.
--console=/dev/com1. COM device name may also be followed by a baud rate like
The pc386 BSP family uses 9600 as a default baud rate for console over UART (/dev/comX) with 8 data bits, no parity and 1 stop bit.
specifies target device for printk/getk calls. E.g.
If the specified console device is not present then suitable fallback device is selected based on the device order specified in Console Drivers.
specifies required video mode. The options applies only to the systems supporting VESA BIOS Extensions. Choices are
autowhich selects graphic mode automatically or
offwhich disables initialization of the graphic driver or direct specification of resolution and/or color depth by
--video=nonedisables graphic driver. Using
--video=1280x1024sets video mode to 1280x1024 pixels mode while
--video=800x600-32sets video mode to 800x600 pixels with 32bit color depth.
disables usage of COM1 thorough COM4.
specifies UART device for communication between BSP’s GDB stub and GDB running on a host system. Option accepts device and baud rate like the
--consoleoption above. E.g.
--gdb=/dev/com2,115200instructs BSP to use COM2 device for GDB stub/host communication with the speed of 115200 bauds.
The default GDB stub/host is similar to console over UART, i.e., 9600 baud rate, 8 data bits, no parity and 1 stop bit.
halts BSP execution at a break point in the BSP initialization code and waits for GDB connection.
outputs the GDB remote protocol data to printk.
188.8.131.52. Testing with Qemu¶
To test with Qemu, we need to:
Build / install Qemu (most distributions should have it available on the package manager).
184.108.40.206.1. Booting RTEMS in Qemu¶
$ qemu-system-i386 -m 128 -no-reboot -append \ "--video=off --console=/dev/com1" -nographic -kernel ./hello.exe
This command boots
hello.exe application located in current
directory and sets Qemu to provide 128MB RAM and to switch both Qemu’s
and BSP’s video off.
220.127.116.11.2. Booting RTEMS in KVM accelerated Qemu¶
When the Qemu host hardware and OS support KVM, it is possible to use it
to accelerate BSP run by using
-machine type=q35,accel=kvm Qemu option.
Depending on the Qemu host configuration it may or may not require
administrator privileges to run the command.
$ sudo qemu-system-i386 -machine type=q35,accel=kvm -m 128 -no-reboot \ -append "--video=off --console=/dev/com1" -nographic -kernel \ ./dhrystone.exe
This command boots
dhrystone.exe application and sets Qemu to use
18.104.22.168. Running on a PC hardware¶
There are several ways how to start RTEMS BSP application on the real PC hardware.
22.214.171.124.1. Booting with GRUB boot-loader¶
In case the target machine does already have Linux with GRUB boot loader installed, then the most easy way to load and boot RTEMS is to use GRUB. This may be done in following steps:
prepare RTEMS binary and save it either to Linux partition/directory accessible from GRUB or to an USB stick.
boot machine to GRUB menu.
Some Linux installations hide GRUB menu by default and quickly continues with booting default Linux option. If this is the case, then during the boot hold down ‘Shift’ key to un-hide the menu.
ckey to get into the GRUB’s command-line mode.
lscommand to observe drives and partitions on them. If unsure, use ‘ls’ command with drive/partition description to show the target file system content. E.g.
ls (hd1,msdos1)/will list files on the second drive, first partition which is formatted using fat/vfat file-system.
Use ls (hdX, partY) without a slash at the end to show information about the partition.
multibootcommand to load the RTEMS application binary for boot. E.g.
multiboot (hd1,msdos2)/rtems/ticker.exewill load ticker.exe from the second drive, second partition with fat/vfat file-system and its rtems directory.
bootcommand to boot loaded binary.
Advantage of using GRUB for booting RTEMS is the GRUB’s support for both classical BIOS and UEFI boot. This way RTEMS may be booted even on UEFI only systems.
126.96.36.199.2. Booting with PXE/iPXE¶
PXE booting is more complex than GRUB based booting and hence requires more infrastructure configuration. The booting may be done in two possible ways:
using iPXE booted from an USB stick or a hard drive
It may be done using following steps:
Download iPXE ISO image from http://boot.ipxe.org/ipxe.iso
Either record it to CD/DVD or copy it to an USB stick
boot from the medium above on the target hardware
Press Ctrl-B for the iPXE command line...prompt and once it appears press
use ‘dhcp’ command to configure network interface card
use ‘boot’ command to boot RTEMS application from specified tftp server. E.g.
boot tftp://10.0.0.5/hello.exewill boot hello.exe application from the tftp server on host with 10.0.0.5 IP address.
Whole interaction may look as:
Press Ctrl-B for the iPXE command line... iPXE> dhcp Configuring (net0 <mac address>)..... ok iPXE> boot tftp://10.0.0.5/hello.exe
using built in network card’s PXE BIOS to boot into iPXE
This way is more complex and requires network infrastructure configuration changes which description is out of the scope of this documentation. Generic steps how to achieve this are:
use target hardware BIOS/SETUP to enable PXE booting on the board
setup network router to announce tftp server and file on it as a part of the router’s BOOTP/DHCP protocol reply. You should use http://boot.ipxe.org/undionly.kpxe as a payload for non-UEFI based booting. Put that file into tftp server served/root directory.
reboot target hardware and it should run network card PXE BIOS which should obtain IP address from the network router and load undionly.kpxe file from the tftp server. Once this is done, familiar iPXE UI appears. Follow steps described in previous paragraph to boot RTEMS application.
It is not possible to use UEFI based PXE booting. Neither directly by the network card PXE BIOS nor indirectly by booting into iPXE. UEFI booting in both cases is not currently supported.
188.8.131.52. Clock Drivers¶
The BSP supports two clock drivers. If there is no build option used (see Build Configuration Options) for selecting particular clock driver, then the decision which is used is done during the runtime.
i8254 based driver. It is used on pre-Pentium CPUs by default.
TSC register based driver. It is used on Pentium and later CPUs by default.
184.108.40.206. Console Drivers¶
The BSP console supports device drivers for a variety of devices including VGA/keyboard and a number of serial ports. The default console is selected based on which devices are present in the following order of priority:
VGA with PS/2 keyboard
COM1 thorough COM4
Any COM devices on the PCI bus including IO and memory mapped
PCI-based UART devices are named
/dev/pcicom<number> as they are
probed and found. The numbers sequence starts with 1. E.g. first PCI
UART device found is accessible with
Besides supporting generic devices above, the BSP also support specific UART chips. The drivers for those are not initialized automatically, but requires initialization from the application code:
Exar 17d15x (NS16550 compatible multiport PCI UART)
220.127.116.11. Frame-Buffer Drivers¶
The BSP supports several drivers implementing RTEMS frame-buffer API. The default driver is for card(s) implementing VESA BIOS Extensions. Others may be enabled by using appropriate build option (see Build Configuration Options). Available drivers support:
generic VGA graphic card
Cirrus Logic GD5446
generic graphic card supporting VESA BIOS Extensions
18.104.22.168. Network Interface Drivers¶
The network interface drivers are provided by the libbsd.
22.214.171.124. USB Host Drivers¶
The USB host drivers are provided by the libbsd.
126.96.36.199. RTC Drivers¶
There are several real time clock devices supported by drivers in the BSP.
Mostek M48T08/M48T18 (Maxim/Dallas Semiconductor DS1643 compatible)
188.8.131.52. I2C Drivers¶
There are several drivers for various I2C bus connected peripherals supported by the BSP. Supported peripherals are:
Maxim DS1621 temperature sensor
Semtech SC620 Octal LED Driver
184.108.40.206. SPI Drivers¶
There are several devices which connect to serial peripheral interfaces supported by the BSP.
220.127.116.11. Legacy Drivers¶
The BSP source code provides legacy drivers for storage and network devices. The usage of legacy drivers is discouraged and description of such use is out of the scope of this documentation. Interested users should consult BSP source code directly but use legacy driver only when it is not possible to use similar driver provided by libbsd.
18.104.22.168.1. Storage Drivers¶
22.214.171.124.2. Network Drivers¶
3Com 3c90x (Etherlink XL family)
Western Digital WD8003
Intel EtherExpress PRO/100
Cirrus Logic CS8900
Opencores Ethernet Controller
National Semiconductor SONIC DP83932