Version 20 (modified by daniel.cederman, on Jan 13, 2015 at 12:46:12 PM) (diff)



This BSP is for the LEON3/4 SPARC V8 processor developed by Cobham Gaisler. LEON3/4 is available as a synthesizable VHDL model, allowing custom implementations on FPGA and/or ASIC. The LEON3/4 BSP probes AMBA Plug&Play information for basic peripherals such as interrupt controller, timer, and UART. Probing the Plug&Play makes it possible for the BSP to supports many LEON3/4 based controllers and boards. The basic peripherals supported:


The BSP supports three network interfaces: the GRETH 10/100/1000, the Opencores Ethernet MAC and the LAN91C111 i/f.

  • Ethernet (GRETH 10/100/1000)
  • CAN, OC_CAN (Opencores CAN GRLIB wrapper)
  • 1553, 1553BRM
  • SpaceWire, GRSPW
  • PCI drivers to RASTA, Companion Chip

System Console

The LEON3/4 BSP has support for the RTEMS console interface and the debug UART interface (printk). The first UART found is by default selected as debug and system console. However, it is possible to override the default settings by declaring an integer named debug_uart_index and/or syscon_uart_index. Setting the variable to N will select the Nth UART for either debug UART or system console. Note that on a AMP system (RTEMS MP) the default is to use APBUART[0] for CPU0, APBUART[1] for CPU1 and so on.

/dev/console_a is by default renamed /dev/console and assigned minor=0, but the user can select /dev/console_['a'+N] to be renamed to /dev/console by setting syscon_uart_index=N. See table below.

0 /dev/console Default APBUART[0], user selectable through syscon_uart_index
1 /dev/console_a APBUART[0] (missing by default)
2 /dev/console_b APBUART[1]

On a MP system the console renamed to /dev/console is selected by CPU index (LEON3_Cpu_Index). /dev/console_['a' + LEON3_Cpu_Index] is renamed unless overridden. Resource sharing is performed by the user, one should not open/access a console that another OS instance uses.

The console driver can operate in polling mode or interrupt mode. Which mode is used is selected at compile time using the CONSOLE_USE_INTERRUPT configuration option. All UARTs operate in the same mode.

SMP Support

The interrupt controller, timer, and UART drivers are all SMP safe. For other drivers one need to ensure that all communication with the driver is done on the same CPU that handles interrupts for the driver. Any driver helper task need to have its affinity set to the same CPU. For the network driver tasks this can be done by setting the default network task CPU affinity in the rtems_bsdnet_config struct.

Static Interrupt Affinity

CPU affinity can be assigned to individual interrupts. By default interrupts are processed by the boot CPU, but this can be changed by defining the weakly linked table const unsigned char LEON3_irq_to_cpu[32] in the user program. This makes it possible to specify which CPU a specific interrupt should be routed to. The array index is the interrupt to be rerouted and the array[INTERRUPT] content is the CPU number relative to the boot CPU index that will be servicing the interrupts from the IRQ source.

Selecting IRQ for Inter-processor Interrupts

Inter-processor interrupts are used in the communication between CPUs. By default IRQ 14 is used, but on some systems this can conflict with an IP core using the same IRQ. Defining the weakly linked variable const unsigned char LEON3_mp_irq in the user program makes it possible to decide which IRQ should be used instead, allowing the conflict to be avoided.

The GR712 uses IRQ 14 for the GRETH Ethernet controller and needs the inter-processor IRQ to be changed for the network driver to work properly.

Console forwarding to GRMON

With the -u option to GRMON, GRMON will set one UART in "debug-mode" or loop-back (older hardware) mode in order to tunnel the UART output/input over the debug-link to the PC instead of at the physical UART connector of the PCB.

Note that it is not possible to use the interrupt mode of the driver together with the "old" APBUART and -u to GRMON. However the new APBUART core (from GRLIB 1.0.17-b2710) has the GRMON debug bit and can handle interrupts. Please see the GRMON manual.


The startup procedure for LEON BSPs is explained in SparcBSPStartup.

Test Reports

4.6.4: Jiri reports that it runs fine on the TSIM simulator, and boards from Pender Jiri reports that it runs fine on the simulator, and on boards from Pender runs on GR-XC3S-1500 board - tested with networking (greth) Daniel Sep 5 2007, Tested GRETH 10/100, B1553BRM(on RASTA over PCI, on Companion Chip over PCI, direct), GRCAN(on RASTA over PCI), OC_CAN(on Companion Chip over PCI, direct) Tested on GR712RC and GR-CPCI-LEON4-N2X