OS porting onto MPX5200

Krishna PrakashAravind JakkaniMalhar Mehta

Agenda

• Problem Statement• Hardware• Building kernel image and board setup• TFTP• NFS• Setup procedure • Status• Trade-offs• Things we would do differently

Problem Statement

• Assist the Satellite Design Lab (SDL) of the Aerospace Engineering Department in setting up an embedded system development platform

• SDL team led by Henri Kjellberg under Dr. Lightsey's supervision

• Setup an OS on the CRX02 Platform running a FreescaleTM MPC5200 microprocessor that implements PowerPC ISA

• Provide features for compiling C code and executing the binary on the board

Problem Overview

• Long term impact – Board to be used as part of a closed loop simulation systemo Host PC to send data via MATLAB through Serial

Port to embedded systemo Flight guidance navigation and control algorithms

running on the boardo Embedded system to process the data and provide

feedback• Establish serial communication between the board and

Matlab

Hardware

• CRX02 Carrier Boardo 18V – 30V Power Supply Inputo One 100Mbit Ethernet Connectivityo Two serial portso Two CAN portso Two USB (USB 1.1) portso Compact Flash slot

• MPX5200 Moduleo MPC5200 Microcontroller – 400MHzo 64MB DDR-SDRAMo 16MB Flash Memoryo Two 208 pin MPX Connectors

• Power Supply with adapter, cables etc.

Hardware (2)

• External Requirementso RS-232C cableo Computer with a serial port and running

HyperTerminal (Windows) / Kermit (Linux) or equivalent

o A TCP-IP based Ethernet Network with 10/100 BaseT Cable Connection

o A server offering TFTP / NFS protocol with Denx ELDK installed and available through NFS

MPC5200 Processor

• Based on MPC603e PowerPC® core• Double Precision FPU• Instruction and Data MMU• 16K Instruction and 16K Data Caches• 133 MHz DDR Interface (266 MHz effective)• USB 1.1 Host• Programmable Serial Controllers• Serial Peripheral Interface (SPI)• GPIO (up to 56)• I2C, I2S• PCI Version 2.2• 10/100 Ethernet MAC

PowerPC 603e µP

• Part of PowerPC RISC Architecture Family• Lower Power Implementation• 52-bit Virtual Addressing, 32-bit Physical Addressing• 8, 16, 32 bit Integer Data Types• 32, 64 bit Floating-Point Data Types• Four S/W controllable Power-saving modes:

o Nap, Doze, Sleep – Statico Dynamic PM

• Superscalar processor – issues / retires up to 3 Instrs / cycle

• Supports OoOE

PowerPC 603e µP (2)

• Five Execution Units – IU, FPU (Pipelined), BPU, LSU, SRU

• Up to five instructions in parallel – High throughput / Performance

• Two Register Files:o 32 GPRs for integer operandso 32 FPRs for single or double precision operands

• 16K Instruction and 16K Data Cacheo Four-way set-associative, physically addressed; LRU

replacement algorithmo 64 Entry, two-way set-associative ITLB and DTLB

• Independent pipelines with feed forwarding – Reduces data dependencies

ELDK

• Embedded Linux Development Kit – From Denx Computer Systems

• Includes GNU cross development toolso Compilers, binutils, gdb etc

• Includes pre-built tools for PowerPC targets• Available as open-source• ELDK will be installed on the host machine and host the

root file system of the board• <ELDK_root>/target_cpu/ - root location for the board

ELDK (2)• install script comes with the source

o Used for initial installationo Allows parameter to specify install location and choose

targets to install foro MPC5200 – ppc6xx target

• Exporting the root fs over NFS, requires running of ELDK_MAKEDEV and ELDK_FIXOWNER scriptso Scripts require superuser privileges on the hosto MAKEDEV script creates necessary device nodes in the

ELDK_root/target_cpu/dev directoryo Some target utilities have same privileges as user who

installso Utilities like mount, su require superuser privileges to

function correctlyo FIXOWNER script fixes this if ELDK was installed by a user

without superuser privileges

Building a Kernel Image

• MAKEDEV script creates basic nodes under /dev/ of the root location• Create additional nodes as needed• Download packed linux image available from open source repository

o We have used linux-2.6.16.11 kernel• Unpack the linux image to <ELDK_path>/usr/src• There are patches available for CRX02 use for particular Kernel

versions• Download and apply the correct patch• Set the PATH, CROSS_COMPILE and ARCH variables

o PATH=<ELDK_path>/usr/bin:<ELDK_path>/bin:$PATHo export CROSS_COMPILE=ppc_6xx-o export ARCH=ppc

• Use the makefiles available to build the Kernel image - uImage• Image created in <linux_directory>/arch/ppc/boot/images• Copy the image to a location accessible from root (exposed through

NFS)

Board – Host setup

• Connect the board to the host through Serial port• Connect the board to the same n/w as the host through the

Ethernet porto For convenience we used a switch to setup a LAN

• Configure Kermit (Linux) or HyperTerminal (Windows) to communicate through the correct serial port with the boardo Baud Rate – 9600

• Power-on the board to get to the U-Boot prompt in the terminal• printenv can be used to print the current value of environment

variables• Use setenv to define / redefine variables• saveenv can be used to save the current state of variables to

flash

TFTP

• Trivial File Transfer Protocol• Simple version of FTP• Uses UDP Port 69• Very small memory usage• Reads / writes files to / from remote server• No user authentication / encryption• Doesn’t have directory listing capability• Mainly used to load a basic kernel to perform the

initial installation

TFTP Implementation• TFTP package installed through YaST• Functionality verified through localhost• Problems transferring files through remote server• Lack of root privileges on other linux hosts – unable to

install TFTP package• Windows based clients on personal laptops – unable to

communicate with server• Installed SuSE Linux on personal laptop – still couldn’t

transfer between remote locations• Verified UDP Port 69 to be open to all clients on the

host• nmap command from remote system gives Port 69 to be

Open | Filtered – Possible Issue• Solution – Attempt transfer through NFS Protocol before

further debug

NFS

• Network File System Protocol• Allows client to access files over N/W• Accesses similar to how local storage might be

accessed• NFS server setup and running on host – GUI based

application available on SuSE Linux• Names and parameters of directory to be exported

setup by Admino /etc/exports

• Need to determine the clients (IP Address range) on network that can access the files

NFS Implementation

• Problems with NFS Server when multiple directories are exposed

• File transfer works well when only single directory is added to /etc/exports for NFS

• Board mounts the remote file system using NFS protocol, as its own root

• Workaround – place the Kernel image to be downloaded in the same path as root location

• Option Parameters – rw, no_root_squash, sync• Create dummy node /dev/nfs if it doesn’t exist on host• Download kernel image through NFS protocol

Downloading image / Booting Linux• Run dhcp command from U-Boot to get the ip address for the

board and the gateway ip.• Setup the correct ip addresses

o ipaddr – IP Address of the boardo serverip – IP address of the host (having ELDK)o gatewayip – obtained through DHCP

• Specify the correct path for the boot image as well as for the root of the fs

• Use NFS protocol to download the boot image• Use bootm command to boot from a particular location in

memory• This should boot from the kernel image • If the boot is successful, a login prompt is provided• Login as root and we will be able to access the fs exported over

NFS

Current Status and Ongoing Work

• Successfully able to port Linux OS on to the CRX02 Platform• Able to access and modify the root fs exported over NFS• Verified simple C programs

o Programs were both compiled and executed on the board• Currently having to load the Kernel image through NFS after power-

ono Planning to have the image saved to Flash and autoboot on

power-ono Another option is to automate the image copy and load operation

• Plan to use both the serial portso One port connected to linux host (with ELDK) and another to

Windows host (running MATLAB)• Setup serial communication between the board and host• Once we are able to establish two-way serial communication

between the board and the host, we can provide APIs to the SDL team that they can use to talk to the board

Implementation Trade-offs

Copying the linux kernel onto the onboard flash memory• Advantages

o Kernel need not be fetched from the host o Faster bootup

• Disadvantageso Makes kernel upgrade / modification tediouso If there are many development boards, each one needs

to be changed individually A better option would be to automate the kernel copy and linux boot-up process

Things we would do differently

• Wasted a lot of time trying to set up tftpboot• Would probably skip that step, and jump directly to NFS• NFS has more features, and enables kernel copy as well as

remote directory mount

Questions?

 

Thank you!