Supporting a new model of an already supported family

This is the simplest case: support a different model of a CPU family. Usually they differ only for RAM and Flash memory and maybe the number of peripherals; For example SAM7S128 and SAM7S256 differ only for Flash size. In this case:

• Add detect macros for your specific CPU to cpu/detect.h
• Write a linker script for your CPU (if not provided by the toolchain), specifying the correct size of RAM/Flash. Put it in cpu/<arch>/scripts/<your_cpu>.ld
• Modify the drivers to use your CPU; it's just a matter of adding a detect macro in existing code. See cpu/<arch>/drv/ files. Suggested order is the following:
  1. debug serial (kdebug)
  2. system timer (timer)
  3. UART (ser)
• Write a wizard information file, describing the CPU, linker script etc and put it into cpu/<arch>/info/<your_cpu>.cdef. Use existing common definitions whenever possible. Important values are:
  • CPU_DESC: CPU description shown in the wizard. It's a list of python strings
  • CORE_CPU: it's the flag that identifies the CPU in the compiler. For GCC it's passed to -mmcu flag.
  • MK_CPU_CPPFLAGS: the define needed to the compiler to understand for which CPU we are compiling

Adding a new family for an already supported architecture

This case happens when BeRTOS already supports the architecture, say Cortex-M3, but no processors of a specific manufacturer, say NXP LPC1xxx.

The steps are the same as the previous case, but now you have to create files from scratch. In particular:

• Create a new linker script called <cpu_name>_rom.ld (if needed). Try to reuse as much common definitions as possible.
• Create the low level drivers. You need to create both .h and .c files. The interface with the high level drivers is defined, you can look at it from any existing driver; the implementation is up to you. :)
  Files should be named <drv>_<cpu_family>.c, eg. timer_lm3s.c
• When adding support for the wizard, try to factor out most commonalities between CPUs of the same family. Important values in this phase are:
  • CPU_TAGS: indicates the CPU type to the wizard. It's used to determine which drivers are supported by this CPU.

Adding a new architecture

This is the most general case, because you can't rely on any existing BeRTOS code; an example for the current (June 2011) BeRTOS status can be creating a port for AVR32 processors.

In this case you need to:

• Find a way to flash your CPU or, alternatively, to upload a program to RAM.
• Create a linker script with the memory map for your CPU (if needed). Some toolchains provide it for you, some other don't. The files should go into cpu/<arch>/scripts/ directory.
• Add macros to let BeRTOS recognize your CPU. Have a look at
  • cpu/detect.h - Detect macros
  • cpu/attr.h - Number of registers, CPU memory model, RAM start, endianess ...
  • cpu/frame.h - Various definitions needed for context switching routines
• Create init scripts for your CPU, if they are not provided by your toolchain. These scripts should set up stack pointers, clear the bss, load the data sections and call functions to allow the user a little configuration of the initialisation phase. For example, they should call a __initX() functions (with X=1,2,3... as needed). These scripts go into the cpu/<arch>/hw/ directory. See for example cpu/cortex-m3/hw/crt_cm3.S
• Create the low level driver for serial debug and timers. You will need to implement cpu/<arch>/drv/kdebug_<family>.c and cpu/<arch>/drv/timer_<family>.c. These drivers are needed before you can implement the kernel switching routines.
• Implement the context switching routines for your architecture, these files should go into the cpu/<arch>/hw/ directory. Try to uniform as much as possible the preemptive and the cooperative kernel context switching.
  • When you're done, you can try to run the test suite for the kernel to check if everything is working.
• Now you're ready to implement other drivers.