Gsg-linux-vt 01



Download 32.22 Kb.
Date conversion09.01.2017
Size32.22 Kb.




NIOS uC/OS-II Application Software Porting to ARM Cortex A9 LINUX

GSG-Linux-VT-2.01

User Guide



Document Revision History



Date

Version

Description

July 1, 2013

0.1

Draft Version

July 9, 2013

0.2

Added “General Consideration of Porting From uC/OS II To Linux”

July 25, 2013

0.3

Added code snippets to show Altera SoC Abstraction Layer (SOCAL) usage

July 30, 2013

0.4

1. Added “64-Bit Host Development Machine Consideration” section

2. Added a simple example of uC/OS II code to illustrate the area of porting





Contents


Overview 3

Processor Reference 4

uC/OS II Development Environment 5

Cross-Compiler toolchain 5

GCC switch - CFLAGS 5

LINUX Development Environment 6

Cross-Compiler toolchain 6

GCC switch - CFLAGS 6

64-Bit Host Development Machine Consideration 8

Generic “Makefile” Construction 9

Using HWLIB and SOCAL 10

General Consideration of Porting From uC/OS II to LINUX 12

uC/OS II Scheduling vs. LINUX Scheduling 12

Memory Management Unit 14

Miscellaneous Porting Consideration 14



Overview


uC/OS II RTOS is a hard real-time operating system where the responsiveness of application software running on top of it is critical whereas LINUX OS is a soft real-time operating system where emphasis primarily on the bandwidth sharing area; though both of this operating system operated in different nature but the application software running on top of them would not vary so much. This user guide described the different of both the OS development environment to be aware of, usage of cross-compiler and standard libraries integration for porting NIOS uC/OS II application software to ARM Cortex A9 LINUX platform.

It is not the intention of this user guide to illustrate task specific design and mimic porting them from NIOS uC/OS II to ARM Cortex A9 LINUX platform. In short, task scheduling vs. thread mapping and time tick interrupts vs. periodic signal handling are out of the scope of this document.


Processor Reference


In-depth details of NIOS II soft processor

- http://www.altera.com/devices/processor/nios2/ni2-index.html

In-depth details of ARM Cortex-A9 hard processor

- http://www.arm.com/products/processors/cortex-a/cortex-a9.php




uC/OS II Development Environment


Two types of uC/OS II development environment are supported and they are IA32 GNU/LINUX and IA32 Windows. Windows base development environment is setup using “cygwin”, a Unix-like environment and command-line interface for Microsoft Windows.

Cross-Compiler toolchain


There is only one type of cross-compiler toolchain used in NIOS uC/OS II development environment:-

Baremetal compiler toolchain : nios2-elf-xxxxxxx

The baremetal compiler toolchain is built with “NewLib” and is for producing small target footprint application software, e.g. OS independent software applications and RTOS.

GCC switch - CFLAGS


In depth reference of compiler specific switches

  • https://sourcery.mentor.com/GNUToolchain/release2498

Processor architecture specific:

-mhal


-msys-crt0=xxxxx

-msys-lib=xxxxx

General:

-g (provides the default set of debug symbols)

-O2 (normal optimization)

-MP


-MMD

Warning level:

-Wall

LINUX Development Environment


Two types of ARM Cortex A9 LINUX OS development environment are supported and they are IA32 GNU/LINUX and IA32 Windows. Windows base development environment is setup using “cygwin”, a Unix-like environment and command-line interface for Microsoft Windows.

Cross-Compiler toolchain


There are 2 types of cross-compiler toolchains in ARM Cortex-A9 LINUX development environment:-

Baremetal compiler toolchain : arm-none-eabi-xxxxxxx

Standard compiler toolchain : arm-linux-gnueabihf-xxxxxxx

The baremetal compiler toolchain is built with “NewLib” and is for producing small target footprint application software, e.g. OS independent software applications and RTOS.

The standard compiler toolchain is built with GNU “GLIBC” and is for producing application software for LINUX.

GCC switch - CFLAGS


In depth reference of compiler specific switches

  • http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc

Processor architecture specific:

-mfloat-abi=softfp

-march=armv7-a

-mtune=cortex-a9

-mcpu=cortex-a9

-mfpu=vfpv3-d16

General:

-g (provides the default set of debug symbols)

-O2 (normal optimization)

–std=c99 or gnu99 (gnu99 is GNU dialect of ISO C99)

Warning level:

-Werror


-Wall

Note: For cross-compiling involving HWLIB or SOCAL it is advisable to use “-std=gnu99” instead of “-std=c99” to solve some possible linking compatibility issue related to other GNU libraries.


64-Bit Host Development Machine Consideration


By default A 64-bit host machine can execute any 32-bit software applications without any problem but not the other way round. The only dependency a 64-bit host machine needed is the IA32 runtime libraries to be available.

If a user wants to use A 32-bit cross-compiler toolchains on a 64-bit Linux native host development machine, he needs to make sure those IA32 runtime libraries to be available on the 64-bit host development machine.

Below is the an example on how to install IA32 runtime libraries on Ubuntu 12.04.2 LTS

~$ sudo apt-get install libgl1-mesa-dri:i386

~$ sudo apt-get install ia32-libs-multiarch:i386

~$ sudo apt-get install ia32-libs


Generic “Makefile” Construction


Usually NIOS uC/OS II “Makefile” is generated automatically through Eclipse GUI, the content of the “Makefile” is standard except the “C_ARCH_FLAGS” which is processor architecture dependent.

Figure shows the generic “Makefile” example for building application software for ARM Cortex–A9 under LINUX environment. User need to be aware that “CROSS_COMPILER”, COMPILER_DIR” and “ARM_SCM_DIR” are location/tool specific and need to change accordingly.



Figure : Makefile


Using HWLIB and SOCAL


When porting application software form NIOS uC/OS II to ARM Cortex-A9 LINUX user are advisable to utilize Altera Hardware Library (HWLIB) and Altera SoC Abstraction Layer (SOCAL) as much as possible for hardware specific I/O access such as peripherals I/O, generic I/O, processor I/O etc. As both the HWLIB and SOCAL are conformed to C99 standard, the codes should compile without any problem with either Baremetal GCC cross-compiler toolchain or standard LINUX GCC cross-compiler toolchain.

Figure and Figure : code snippets illustrate the usage of generic I/O register read/write utilizing Altera SoC Abstraction Layer (SOCAL) .



Figure : Inclusion of Altera SoC Abstraction Layer (SOCAL) API header file



Figure : Memory read/write using Altera SoC Abstraction Layer (SOCAL) API

One important reminder to note here, if the porting code make use of POSIX API call, e.g. clock_gettime(…) than there are no choice but to use standard LINUX GCC cross-compiler toolchain as it is built with GNU “GLIBC”.

General Consideration of Porting From uC/OS II to LINUX


Porting from uC/OS II to LINUX is highly depended on the application or usage specific design. Generally porting from uC/OS II to LINUX will be easier as the later OS provided more complete support on scheduling mechanism, MMU, POSIX API and various GNU libraries.

uC/OS II Scheduling vs. LINUX Scheduling


uC/OS II is a preemptive real-time multitasking kernel in which the kernel is ready for operation at all times for the highest priority tasks. In the contrary, LINUX is using traditional periodic clock timer interrupt to achieve regular intervals to suspend a process. Due to uC/OS-II and LINUX are not comparable, mimic porting of uC/OS-II scheduling, timing, synchronization and inter-process communication mechanism are not encouraged. But for further reference on this topic, please refer to uC/OS-II - Port for the LINUX Operating System by Werner.Zimmermann.

Figure : Simple example of uC/OS II codeillustrated a simple example of uC/OS II codes and we need to consider application specific codes reside inside “task1” and “task2” and port them properly to ARM Cortex-A9 LINUX. The rest of the codes are uC/OS II architecture specific that not the interest of this porting guide.





Figure : Simple example of uC/OS II code


Memory Management Unit


uC/OS II does not had MMU management memory, thus the memory access is direct, e.g. all access is direct to the actual physical address and if a multi-process data protection is not implemented, this will easily lead to a system crash. Porting from NIOS uC/OS II to ARM Cortex-A9 LINUX is simpler as all the complexity of MMU management implementation is taken care by LINUX OS already. At a bare minimum all the custom codes related memory management from NIOS uC/OS II are advisable to remove accordingly when porting to ARM Cortex-A9 Linux.

Miscellaneous Porting Consideration


In summary, to port from NIOS uC/OS II to ARM Cortex-A9 LINUX is much simpler vs. the other way round. This is because the ARM Cortex-A9 architecture, timer interrupt, stack growth and process switching are well supported by LINUX OS architecture. Though the porting in this direction are simple, there are some miscellaneous definition that need to be aware, e.g. Figure : os_cpu.hFigure , data types from NIOS uC/OS II processor range must re-define properly for ARM Cortex-A9 LINUX target, Figure : stdint.h.

Figure : os_cpu.h




Figure : stdint.h




The database is protected by copyright ©ininet.org 2016
send message

    Main page