Summary

RTEMS comes with a set of small applications designed to test various features of a Board Support Package, which implements basic hardware "hook" functions needed by RTEMS. The DAT group implements two generic BSPs, one Virtex 4 FPGAs and one for Virtex 5 FPGAs. These BSPs in their turn have "application hooks" which allow for adjustment to application specific hardware variations, e.g., number of ethernet ports. For more information on the structure of BSPs look here.

...

One seemingly basic thing that DAT BSPs fail to provide is a console allowing real-time interaction. Instead they offer a console driver that justs just writes output to a circular buffer and doesn't allow for input. Only when networking is up and the RTEMS shell is run do we have truly interactive sessions.

...

This BSP is for Virtex 4 FPGAs with PowerPC 405 processors. The programmer's interface to the protocol plugins (I/O engines) is through Plugin Interface Code (PIC) firmware blocks. Two-way communication through a plugin requires four different types of blocks though there may be sharing of blocks amonst amongst plugins. Each PIC block can raise external non-critical exceptions for four events that may occur during normal operation. (These exceptions are gnerally generally referred to as interrupts in code). There is a single control bit for each block which controls the enabling of these exceptions. Each block can also raise the critical external exception for various fault conditions.

...

The right fix is to have the firmware bring up all PIC blocks with their "exception on event" bits cleared. For some reason that never happened; instead all our applications cleared these bits in the application pre-tasking hook. Comments in the BSP code complain of RTEMS enabling the exceptions "too soon". The sample apps are of course unaware of this hook. Also, one has to know how many of each kind of PIC block are on the board which varies from application to application; there is no "grand disable" bit one can set to silence them all. For the present we modify bsp_start.c so that bsp_statrstart() calls the following function:

/* "se taire" is French for "to shut one's self up". The function will
   disable all interrupts from PPI's by clearing the appropriate mask
   bits in each PPI CSR on a COB mezzanine board with a PPC405.

   There are only two protocol plugins on a Gen 1 DPM (PPC405):
   one ethernet and one PGP. Each has one of each kind of PIC
   block: PIB, ECB, FLB and PIB.
*/

#define wdcr(dcrNum, value) \
  asm volatile("mtdcr %0,%1"::"i"(dcrNum), "r"(value))

#define MODIFY_EVENT_ENABLE 0x00080000

#define CLEAR_EVENT_ENABLE  0x00000000

void se_taire() {
  static const unsigned DISABLE_EVENTS = MODIFY_EVENT_ENABLE | CLEAR_EVENT_ENABLE;
  /* PEBs. */
  wdcr(0x300, DISABLE_EVENTS);
  wdcr(0x304, DISABLE_EVENTS);
  /*  ECBs */
  wdcr(0x340, DISABLE_EVENTS);
  wdcr(0x344, DISABLE_EVENTS);
  /* FLBs */
  wdcr(0x380, DISABLE_EVENTS);
  wdcr(0x384, DISABLE_EVENTS);
  /* PIBs */
  wdcr(0x3c0, DISABLE_EVENTS);
  wdcr(0x3c4, DISABLE_EVENTS);
}

...

Multitasking vs. console driver

Another problem, albeit a minor one, is that the console driver is neither reentrant re-entrant nor serializing. Output from mutiple multiple tasks gets scrambled as one task may overwrite what another has just written. Usually, though, it's possible to see whether the basic test failed.

Fixing this would be a bit tricky as the same circular buffer is also used for printk() before RTEMS is fully initialized. One would have to change the mechanism to reetrancy re-entrancy or serialization in the pre-tasking hook.

...