sambuc/atomthreads
1
0
Fork 0
mirror of https://github.com/kelvinlawson/atomthreads.git synced 2026-05-04 17:31:30 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

dm36x: Write README file for DM365/DM368.

Browse Source
This commit is contained in:
Kelvin Lawson
2013-09-18 00:17:25 +01:00
parent e0c4cba602
commit dfe296b01b
2 changed files with 75 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

150
ports/arm/platforms/dm36x/README
View File

@@ -1,17 +1,25 @@
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
Library: Atomthreads QEMU ARM Integrator/CP (ARM926EJ-S) Platform. Library: Atomthreads DaVinci DM365/DM368 Platform.
Author: Natie van Rooyen <natie@navaro.nl> Author: Kelvin Lawson <info@atomthreads.com>
Website: http://atomthreads.com Website: http://atomthreads.com
License: BSD Revised License: BSD Revised
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
QEMU ARM Integrator/CP (ARM926EJ-S) Platform DaVinci DM36x (ARM926EJ-S) Platform
The "qemu_integratorcp" platform folder contains sources for building a The "dm36x" platform folder contains sources for building a sample
sample Atomthreads application for the ARM Integrator/CP (ARM926EJ-S) Atomthreads RTOS application for DaVinci DM365 and DM368 (ARM926EJ-S)
platform running under QEMU. platforms.
This has been tested on a DM368 Leopardboard platform, but will work on any
DM36x-based platform.
---------------------------------------------------------------------------
SOURCE LAYOUT
All of the cross-platform kernel code is contained in the top-level All of the cross-platform kernel code is contained in the top-level
'kernel' folder, while ports to specific CPU architectures are contained in 'kernel' folder, while ports to specific CPU architectures are contained in
@@ -25,7 +33,7 @@ the same common core ARM context-switching code.
This platform contains a few key platform-specific files: This platform contains a few key platform-specific files:
* startup.s: Interrupt vector table and basic startup assembly code * startup.s: Interrupt vector table and basic startup assembly code
* modules.c: Low level initialisation for this platform * atomport-private.c: Low level initialisation for this platform
* uart.c: Simple UART implementation for debug purposes * uart.c: Simple UART implementation for debug purposes
The common ARM architecture port that is used across all platforms contains The common ARM architecture port that is used across all platforms contains
@@ -47,53 +55,37 @@ A couple of additional source files are also included in the common ARM port:
* syscalls.c: Simple implementation of open/close/read/write for stdio * syscalls.c: Simple implementation of open/close/read/write for stdio
Atomthreads includes a suite of automated tests which prove the key OS Atomthreads includes a suite of automated tests which prove the key OS
functionality, and can be used with any architecture ports. This port functionality, and can be used with any architecture ports. This platform
provides an easy mechanism for building and quickly running the test suite provides an easy mechanism for building and quickly running the test suite
using QEMU to prove the OS without requiring any target hardware. using a serial port connected to real hardware to prove the OS.
This platform folder has been tested on a variety of GCC ARM toolchains,
including hosted and non-hosted.
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
GCC TOOLCHAIN GCC TOOLCHAIN
The port works out-of-the-box with the GCC tools (for building) and QEMU The port works out-of-the-box with the GCC tools (for building). It can be
(for simulation). It can be built on any OS for which GCC is available, and built on any OS for which GCC is available, and was tested using the
was tested using the CodeSourcery toolchain (2009q3 non-Linux but others CodeSourcery toolchain (2009q3 non-Linux but others should be supported).
should be supported) and self-built toolchains such as hosted toolchains Note that the Makefile for this platform assumes that your GCC binary is
built by build_arm_toolchain.sh (see http://navaro.nl for details). Note named "arm-none-eabi-gcc".
that the Makefile for this platform assumes that your GCC binary is named
"arm-none-eabi-gcc".
Currently we assume that the toolchain will provide some header files like Currently we assume that the toolchain will provide some header files like
stdint.h. Not all toolchains will include this, in which case you simply stdint.h. Not all toolchains will include this, in which case you simply
need to add definitions for int32_t and friends in atomport.h, in place of need to add definitions for int32_t and friends in atomport.h, in place of
the include declaration for stdint.h. the include declaration for stdint.h.
Some toolchains provide newlib syscalls.c which implement stdio
functionality via open, close, read, write. Hosted toolchains will
automatically provide versions of these which work with QEMU, and no UART
driver will be needed to view the stdio printf()s etc. If these are not
provided by by the compiler toolchain then backup implementations are
implemented within the common ARM port folder (see ports/arm/syscalls.c)
and a UART driver is implemented here in uart.c.
Similarly some toolchains provide startup assembly code via
_mainCRTStartup(). If this is not provided by the toolchain then a backup
version is used within modules.c.
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
OTHER PREREQUISITES OTHER PREREQUISITES
QEMU is used for simulation of the target and versions 0.14.1, 1.2.0 & Running the entire automated test suite in one command via "make tests"
1.4.0 were tested. requires the "expect" program.
Running the entire automated test suite in one command via "make qemutests" ".bin" images bootable via U-boot are created as part of the build but if
also requires the "expect" program. uImage format is preferred then the "mkimage" application is also
required.
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
@@ -102,16 +94,16 @@ BUILDING THE SOURCE
A Makefile is provided for building the kernel, port, platform and A Makefile is provided for building the kernel, port, platform and
automated tests. Make sure the ARM GCC toolchain is in the path automated tests. Make sure the ARM GCC toolchain is in the path
(e.g. "PATH=$PATH:/opt/arm-2009q3/bin && export path") as well as QEMU and (e.g. "PATH=$PATH:/opt/arm-2009q3/bin && export path") and carry out the
carry out the full build using the following: full build using the following:
* make all * make all
All objects are built into the 'build' folder under All objects are built into the 'build' folder under
ports/arm/platforms/qemu_integrator_cp. The build process builds separate ports/arm/platforms/dm36x. The build process builds separate target
target applications for each automated test, and appropriate ELF files can applications for each automated test, and appropriate ELF/BIN files can be
be found in the build folder ready for running on the target or within found in the build folder ready for running on the target. Each test is
QEMU. Each test is built and run as a separate application. built and run as a separate application.
All built objects etc can be cleaned using: All built objects etc can be cleaned using:
@@ -127,12 +119,14 @@ both the kernel and port documentation from this folder using:
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
Integrator/CP SPECIFICS PLATFORM SPECIFICS
The test applications make use of the Integrator's UART to print out This RTOS port was developed on the DM368 Leopardboard, but there is
pass/fail indications and other information. For this you should connect a currently very little board-specific code present, other than the choice of
serial debug cable to the board or when running in QEMU you will see the UART (the Leopardboard uses UART0 but many boards use UART1). The UART is
UART messages on the console when running the test applications. used to print out pass/fail indications and other information via a serial
debug cable connected to the board. For other boards using UART1 you may
simply change the UART_BASE definition in uart.c.
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
@@ -145,13 +139,12 @@ port to prove that all core functionality is working on your target.
The full set of tests can be found in the top-level 'tests' folder. Each of The full set of tests can be found in the top-level 'tests' folder. Each of
these tests is built as an independent application in the 'build' folder. these tests is built as an independent application in the 'build' folder.
These can be run on the target or within QEMU using the instructions below. These can be run on the target using the instructions below.
To view the test results, connect a serial debug cable to your target To view the test results, connect a serial debug cable to your target
platform or view the console if using QEMU. On starting, the test platform. On starting, the test applications print out "Go" on the UART.
applications print out "Go" on the UART. Once the test is complete they Once the test is complete they will print out "Pass" or "Fail", along with
will print out "Pass" or "Fail", along with other information if the test other information if the test failed.
failed.
Most of the tests complete within a few seconds, but some (particularly Most of the tests complete within a few seconds, but some (particularly
the stress tests) can take longer, so be patient. the stress tests) can take longer, so be patient.
@@ -166,46 +159,43 @@ the OS, creates a main thread, and calls out to the test modules.
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
RUNNING TESTS WITHIN THE QEMU SIMULATOR RUNNING THE FULL TEST SUITE
It is possible to run the full automated test suite in a simulator without It is possible to run the full automated test suite on the target board.
programming the test applications into real hardware. This is very useful This is very useful for quick verification of the entire test suite after
for quick verification of the entire test suite after making any software making any software changes.
changes, and is much faster than downloading each test application to a
real target.
A single command runs every single test application, and automatically A single command runs every single test application on the target, and
parses the (simulated) UART output to verify that each test case passes. automatically parses the UART output to verify that each test case passes.
This requires two applications on your development PC: expect and QEMU. This requires the "expect" application on your development PC.
To run all tests in one command, type: To run all tests in one command, type:
* make qemutests * make tests
This will run every single test application within the simulator and quit This will download every single test application to your TFTP folder one at
immediately if any one test fails. a time, ready for the target to load via U-Boot, and quit immediately if
any one test fails.
The ability to run these automated tests in one command (and without real You should set your target board to load the file "test.bin" via TFTP and
hardware) allows you to easily include the OS test suite in your nightly hit the reset button after each test has completed (when prompted).
build or continous integration system and quickly find out if any of your The U-boot "bootcmd" variable should be set as follows:
local changes have caused any of the operating system tests to fail.
* setenv 'tftpboot 0x80000000 test.bin; go 0x80000000'
* saveenv
--------------------------------------------------------------------------- Now when you run "make tests" it will copy each test application binary
into your TFTP root folder one-by-one, and request that you reset the board
to start the next test running. Passes or failures are reported, and the
test suite quits if any test suite failures are encountered.
DEBUGGING WITH QEMU The ability to run these automated tests in one command allows you to
easily include the OS test suite in your nightly build or continous
You may also use QEMU in combination with GDB to debug your built integration system and quickly find out if any of your local changes have
applications. To do this you should start QEMU with "-S -s" options e.g.: caused any of the operating system tests to fail. In order to include them
in a nightly test run you will need to set the test applications to
* qemu-system-arm -M integratorcp -semihosting -nographic -kernel app.elf automatically reset after running each test.
You can now start GDB and attach to the target:
* arm-none-eabi-gdb
* file app.elf
* target remote localhost:1234
--------------------------------------------------------------------------- ---------------------------------------------------------------------------

5
ports/arm/platforms/qemu_integratorcp/README
View File

@@ -13,6 +13,11 @@ The "qemu_integratorcp" platform folder contains sources for building a
sample Atomthreads application for the ARM Integrator/CP (ARM926EJ-S) sample Atomthreads application for the ARM Integrator/CP (ARM926EJ-S)
platform running under QEMU. platform running under QEMU.
---------------------------------------------------------------------------
SOURCE LAYOUT
All of the cross-platform kernel code is contained in the top-level All of the cross-platform kernel code is contained in the top-level
'kernel' folder, while ports to specific CPU architectures are contained in 'kernel' folder, while ports to specific CPU architectures are contained in
the 'ports' folder tree. To support multiple ARM boards/platforms using a the 'ports' folder tree. To support multiple ARM boards/platforms using a