diff options
authorJoel Sherrill <>2016-10-27 20:01:18 -0500
committerJoel Sherrill <>2016-10-27 20:01:18 -0500
commitf29b7c1cc5dfe039752fde5556e712f1897a0df6 (patch)
parent36def9125c9adf4049a18105d48715ac8606e1ec (diff)
bsp_howto: Fix code-block markup
6 files changed, 21 insertions, 21 deletions
diff --git a/bsp_howto/initilization_code.rst b/bsp_howto/initilization_code.rst
index a082845..fb491cf 100644
--- a/bsp_howto/initilization_code.rst
+++ b/bsp_howto/initilization_code.rst
@@ -23,7 +23,7 @@ m68k/gen68340 BSP initialization code. Like most BSPs, the initialization for
these BSP is divided into two subdirectories under the BSP source directory.
The BSP source code for these BSPs is in the following directories:
-.. code:: c
+.. code-block:: shell
@@ -41,7 +41,7 @@ However, this BSP shares this code with other SPARC BSPs. Thus the
```` explicitly references the following files for this
-.. code:: c
+.. code-block:: shell
@@ -122,7 +122,7 @@ sequencing of initialization steps for the BSP, RTEMS and device drivers. All
BSPs use the same shared version of ``boot_card()`` which is located in the
following file:
-.. code:: c
+.. code-block:: shell
@@ -266,7 +266,7 @@ for opening the device ``/dev/console`` for standard input, output and error if
the application has configured the Console Device Driver. This file is located
-.. code:: c
+.. code-block:: shell
@@ -313,16 +313,16 @@ When the microprocessor accesses a memory area, address decoding is handled by
an address decoder, so that the microprocessor knows which memory chip(s) to
access. The following figure illustrates this:
-.. code::
+.. code-block::
- +-------------------+
+ +-------------------+
------------| |
------------| |------------
------------| Address |------------
------------| Decoder |------------
------------| |------------
------------| |
- +-------------------+
+ +-------------------+
CPU Bus Chip Select
The Chip Select registers must be programmed such that they match the
diff --git a/bsp_howto/linker_script.rst b/bsp_howto/linker_script.rst
index 07ecfe9..8283695 100644
--- a/bsp_howto/linker_script.rst
+++ b/bsp_howto/linker_script.rst
@@ -108,7 +108,7 @@ learned by careful examination of a well-documented example. The following is
a heavily commented version of the linker script used with the the ``gen68340``
BSP This file can be found at $BSP340_ROOT/startup/linkcmds.
-.. code:: c
+.. code-block:: c
* Specify that the output is to be coff-m68k regardless of what the
diff --git a/bsp_howto/miscellanous_support.rst b/bsp_howto/miscellanous_support.rst
index 59b1339..4a487ee 100644
--- a/bsp_howto/miscellanous_support.rst
+++ b/bsp_howto/miscellanous_support.rst
@@ -143,7 +143,7 @@ overhead constants to 0. On faster processors, this is usually the best
alternative for the BSP as the calling overhead is extremely small. This file
is located at:
-.. code:: c
+.. code-block:: c
@@ -157,7 +157,7 @@ the heap used by the C Library memory allocation routines (i.e. ``malloc``
family), then the``sbrk`` routine must be functional. The following is the
prototype for this routine:
-.. code:: c
+.. code-block:: c
void * sbrk(size_t increment)
@@ -181,7 +181,7 @@ invoked once a fatal system state is reached. Most of the BSPs use the same
shared version of ``bsp_fatal_extension()`` that does nothing or performs a
system reset. This implementation is located in the following file:
-.. code:: c
+.. code-block:: c
@@ -258,7 +258,7 @@ The ``set_vector`` routine is a central place to perform interrupt controller
manipulation and encapsulate that information. It is usually implemented as
-.. code:: c
+.. code-block:: c
rtems_isr_entry set_vector( /* returns old vector */
rtems_isr_entry handler, /* isr routine */
@@ -346,7 +346,7 @@ required to be writen by the BSP developer are :
An interrupt handler is installed or removed with the help of the following functions :
-.. code:: c
+.. code-block:: c
rtems_status_code rtems_interrupt_handler_install( /* returns status code */
rtems_vector_number vector, /* interrupt vector */
diff --git a/bsp_howto/real_time_clock.rst b/bsp_howto/real_time_clock.rst
index f66a410..457c6e0 100644
--- a/bsp_howto/real_time_clock.rst
+++ b/bsp_howto/real_time_clock.rst
@@ -42,7 +42,7 @@ on a particular board. This would be useful for a BSP supporting multiple
board models. The relevant ports of the DMV177's ``RTC_Table`` configuration
table is below:
-.. code:: c
+.. code-block:: c
#include <bsp.h>
#include <libchip/rtc.h>
@@ -195,7 +195,7 @@ checkRealTime
The ``checkRealTime`` routine returns the number of seconds difference between
the RTC TOD and the current RTEMS TOD.
-.. code:: c
+.. code-block:: c
int checkRealTime( void )
diff --git a/bsp_howto/target_dependant_files.rst b/bsp_howto/target_dependant_files.rst
index 691e706..428c6e6 100644
--- a/bsp_howto/target_dependant_files.rst
+++ b/bsp_howto/target_dependant_files.rst
@@ -124,7 +124,7 @@ CPU Dependent Executive Files
The CPU dependent files in the RTEMS executive source code are found in the
following directory:
-.. code:: c
+.. code-block:: c
@@ -143,13 +143,13 @@ may contain standard trap handlers for alignment or floating point exceptions
or device drivers for peripheral controllers found on the CPU itself.
This class of code may be found in the following directory:
-.. code:: c
+.. code-block:: c
CPU model dependent support code is found in the following directory:
-.. code:: c
+.. code-block:: c
@@ -168,7 +168,7 @@ sparc, etc.). In addition, there is source code available which may be shared
across all BSPs regardless of the CPU family or just across BSPs within a
single CPU family. This results in a BSP using the following directories:
-.. code:: c
+.. code-block:: c
@@ -221,7 +221,7 @@ structure is discussed in more detail in the `Makefiles`_ chapter.
should have a copy of the gen68340 BSP available while reading this piece of
documentation. This BSP is located in the following directory:
-.. code:: c
+.. code-block:: c
diff --git a/bsp_howto/timer.rst b/bsp_howto/timer.rst
index 9d2bd67..ec1279f 100644
--- a/bsp_howto/timer.rst
+++ b/bsp_howto/timer.rst
@@ -73,7 +73,7 @@ the overhead required to initialize and read the benchmark timer. This is used
by the ``tmoverhd`` test to determine the overhead required to initialize and
read the timer.
-.. code:: c
+.. code-block:: c
void benchmark_timer_disable_subtracting_average_overhead(bool find_flag)