From HW wiki
Jump to navigation Jump to search


Two sets of the MIDAM MPC5200 was delivered by the Mikroklima s.r.o. for our purposes. Each set consist of the:

  • Shark MPC52000 CPU module (pin compatible with TQ Components TQM5200 module),
  • MPC5200 v1.1 2008/02 carrier board.

Set #1 has s/n: 008770 and set #2 has s/n: 008771.

Schematics and components

Download schematics in PDF: File:Midam_expand_v1b.pdf

List of components

This list is not complete. It is just a subset of components needed for educational purpose.


C9  CAP1206 220pF
C10 CAP1206 22nF
C11 CAP1206 10uF
C12 tantal el. 330uF 6.3V D
C23 el. 470uF, 50V 
C29 CAP0805 100n
C30 CAP0805 100n
C31 CAP0805 100n
C32 CAP0805 100n
C35 CAP0805 100n
C36 47uF10V B
C37 47uF10V B
C38 47uF10V B
C39 47uF10V B
D9  LED 1206 
J10 SMD switch
L2  INDUCTOR DR127-150 
R19 RES0805 4k7
R20 RES0805 5k6
R21 RES0805 3k3
R25 RES0805 330R
U9  ST-L5973D 


R34 RES0805 10k
R35 RES0805 10k
J1  Socket 


C5  CAP0805 100nF
C26 CAP0805 100n
D3  LED 1206 
D4  LED 1206 
L7  BLM21AG601SN1D FERRITE, BEAD, 0805, 0.21OHM, 0.6A
R9  RES0805 4k7
R10 RES0805 10k
R11 RES0805 270R
R12 RES0805 270R
R48 RES0805 10k
R49 RES0805 10k
U2  FT232RL


D5  ULN2803 DIO
D11 LED 1206 
D12 LED 1206 
D13 LED 1206 
D14 LED 1206 
D15 LED 1206 
D16 LED 1206 
D17 LED 1206 
D18 LED 1206 
D19 LED 1206 
D20 LED 1206 
R13 RES0805 330R
R14 RES0805 1k
R15 RES0805 1k
R16 RES0805 1k
R17 RES0805 330R
R18 RES0805 330R
R28 RES0805 10k
R29 RES0805 10k
R30 RES0805 2k
R31 RES0805 330R
R32 RES0805 2k
R33 RES0805 330R
R38 RES0805 330R
R39 RES0805 330R
R40 RES0805 330R
R41 RES0805 330R
R42 RES0805 330R
R43 RES0805 330R
R44 RES0805 330R
U3  BSS138 ANA
U4  BSS138 ANA
U6  BSS138 ANA
U7  BSS138 ANA
U8  BSS138 ANA


C18 CAP0805 22nF
J2  TE Connectivity AMP 5-6605758-1

Mailing List

Discussion related to this board happen in a mailing list.

Board overview

Board overview.jpg

Serial line (system console)

  • Loader system console is attached to the ttyPSC0 port.
  • The ttyPSC0 port is done in the LVTTL 3.3V logic, so appropriate 3.3V to RS-232 converter (e.g. MAX3232) is required for the serial console.

Communication parameters:

  • baud rate: 115200 bps
  • bits: 8 bit
  • stop bits: 1 bit
  • Parity: none
  • Flow control: none

Module memory map

The MPC5200B is 32 bit CPU, so it has a 32 bit address space. It is able to address up to 4 294 967 295 B (0xFFFFFFFF) - 4096 MB. The Shark module has been equipped with 128 MB DDR RAM and 64 MB NOR flash memory.

  • RAM chips: Samsung K4S511632D-UC(L)75, order: 32M x 16
  • Address space BASE address is 0x00000000
  • RAM is from 0x00000000 to 0x08000000 (128 MB)

Flash memory is being mapped at the and of address space (from 3.9375 GB).

  • Flash BASE address is 0xFC000000 (last address is 0xFFFFFFFF)
  • Flash memory size is 0x04000000 (64 MB)

There are three MTD partitions in the flash (defined in shark.dts). The flat device tree file syntax uses first address and length of the partition for its definition.

  • u-Boot (1 MB) from 0x00000000 to 0x00100000, length 0x00100000
  • kernel (3 MB) from 0x00100000 to 0x00400000, length 0x00300000
  • file-system (56 MB) from 0x00400000 to 0x04000000, length 0x03C00000

All these addresses are offsets against Flash BASE.

Boot loader

These boards are preinstalled with Das u-Boot boot loader. Behaviour of the u-Boot can be handled by its environment variables. Here are some useful commands:

  • printenv [variable] - prints complete environment or only given variable.
  • saveenv - commits whole environment in flash memory

For running linux kernel >2.6.25 it's necessary to have u-Boot 1.3.2 or later, which is able to hand over flat device tree to the kernel. When older revision is present, it is necessary to upgrade. Binary of u-Boot can be downloaded here: u-boot.bin.

U-Boot upgrade howto:

During the upgrade procedure it is necessary to proceed with utmost precaution, because there is no backup image of the u-Boot in the flash for recovery purposes. Fail-flash recovery isn't possible without JTAG interface. So, you have been warned. In future builds of the u-Boot there should be a support for recovery image. Follow this commands to upgrade U-Boot's image in flash memory:

tftp 800000 u-boot.bin
protect off fc000000 fc09ffff
erase fc000000 fc09ffff
cp.b 800000 fc000000 ${filesize}
protect on fc000000 fc09ffff

Now reboot and than commit new default environment:


How to access U-Boot environment variables from Linux ?

The U-Boot environment variables is possible to read and write trough utilities ... TO DO

Cross-tool chain

Necessary cross-tool chain for PowerPC platform can be build using Crossdev tool. You can install Crossdev on your Gentoo distro very simply:

emerge -av crossdev

Some dependencies may go before. Building of tool chain itself will take some time, so let's go to take some coffee.

crossdev --b 2.18-r3 --k 2.6.23-r3 --g 4.1.2 --without-headers -t powerpc-unknown-linux-gnu

For Debian, you can use a packages prepared by Pavel Píša.

Linux kernel

Instructions for recent kernels

You need this simple patch to boot Linux on MIDAM/RYU board.

Instructions for old kernels

It is necessary to use patched Linux sources. We maintain them in our Git repository. You can clone it by:

git clone git://rtime.felk.cvut.cz/shark/linux.git

Now you can choose the kernel revision you want to compile:

git branch -r # there you can see all branches available
git checkout origin/shark/ # choose the one you desire

Note: See Linux sources for the description of the repository and patch management techniques we use.

Now let's begin with the kernel configuration and compilation. The following recipe can be used to compile the kernel out of source directory, which is helpful if you want to compile a single kernel version with several configurations.

  • cd linux
  • mkdir -p _build/midam
  • cd _build/midam
  • Copy the following code to GNUmakefile file

KERNELSRC    := $(shell cd ../..; pwd)
KERNELOUTPUT := $(patsubst $(KERNELSRC)/%,%,$(shell pwd))

KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)

MAKEFLAGS += --no-print-directory



export INSTALL_MOD_PATH=$(KERNELSRC)/../MPC5200_root

.PHONY: install all $(MAKECMDGOALS)



$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
  • make 52xx/midam_defconfig # or use 52xx/ryu_defconfig for RYU board
  • make menuconfig # if you need additional configuration
  • make # start compilation; u-boot-tools should be properly installed before compilation

The compiled image can be found in linux/_build/midam/arch/powerpc/boot It is the file uImage. Copy it to your tftpboot directory.

How to build the Flat Device Tree file

Since kernel version 2.6.25 is description of the platform hardware provided trough the Flat Device Tree. Necessary sources are now part of the kernel sources. Appropriate image could be build with this command:

make ARCH=powerpc shark.dtb DTS_FLAGS="-S65536"

If DTS_FLAGS parameter omitted than following error will occur, because there is not enough space in the file, where the u-Boot can store some additional data about buses timing, etc.:

WARNING: could not create /chosen FDT_ERR_NOSPACE.
ERROR: /chosen node create failed - must RESET the board to recover.

Root file system

Use buildroot to build one.

TO DO - UnionFS for root FS in flash

For long term usage is not really good to repeatedly overwrite block in the NOR flash chip, because memory cells are being punished. So it would be better to use jffs2 root FS only as RO file system and create RW tmpfs of same size. UnionFS than could be used to merge these two file systems and provide one RW file system. Changes in FS as a lock and log files can be made without permanent effect.


SocketCan is currently tested only with kernels 2.6.28 or lower. If you want to use Socket Can, it is currently recommended to use kernel 2.6.28. To enable SocketCan support, it is neccesary to run

make menuconfig

before building the kernel and set the following:

Networking Support / CAN bus subsystem support (yes)
Raw CAN Protocol (raw access with CAN-ID filtering) (yes)
CAN Device Drivers / Virtual Local CAN Interface (vcan) (yes)
Prompt for platform CAN drivers with sysfs support (yes)
Support for a Freescale MSCAN based chips (yes)
Freescale MPC5200 onboard CAN controller (yes)
make KERNELDIR=/home/marsark/src/linux- CONFIG_CAN_MPC52XX=m CONFIG_CAN_MSCAN=m

CAN subsystem init script:

modprobe can
modprobe mscan-mpc52xx
modprobe can-raw
echo 1000000 > /sys/class/net/can0/can_bittiming/bitrate
echo 1000000 > /sys/class/net/can1/can_bittiming/bitrate

If the above commands fail, you have a new version of socketcan and you need to use ip tool to set bitrate. See bellow.

ifconfig can0 up
ifconfig can1 up

Warning - the ip tool is not working properly yet!

Test the setup:

cansend can0 123#4567

Using ip tool

ip link set can0 type can bitrate 1000000
ip link set up dev can0
ip link set can1 type can bitrate 1000000
ip link set up dev can1


git clone git://git.kernel.org/pub/scm/network/iproute2/iproute2.git
cd iproute2
make CC=powerpc-linux-gnu-gcc

The make will probably fail but fortunately the ip/ip is already compiled.

GPIO how set pin value

In MPC5200 have two kind of GPIO. The first one have wakeup capability, the second one is standard GPIO pins. Each of this sets have its own register sets, so some PSC ports are splitted in to two parts. See MOC5200B documentation section and The availability GPIO of PSC depends on GPS Port Configuration Register settings. For RYU boards is available all GPIO in PSC3 port (HW notation).

TODO: kernel still fails to initialise GPIO drivers on our boards !!!

cat /sys/class/gpio/gpiochip248/label    //todo

Setting GPIO with wakeup capability

GPIO with wakeup using


Pin notation:

 0 -> GPIO_WKUP_7
 1 -> GPIO_WKUP_6
 2 -> PSC6_1
 3 -> PSC6_0
 4 -> ETH_17
 5 -> PSC3_9
 6 -> PSC2_4
 7 -> PSC1_4

Final value is 248 + requested pin (example for PSC2_4 248+6 => 254)

Enable PIN for GPIO:

echo 254 >/sys/class/gpio/export

Set GPIO as output or input

echo out >/sys/class/gpio/gpio254/direction
echo in >/sys/class/gpio/gpio254/direction

Set GPIO to 0 or 1 if configured as output pin

echo 0 >/sys/class/gpio/gpio254/value
echo 1 >/sys/class/gpio/gpio254/value

Setting standard GPIO not tested

Standard GPIO using


Pin notation:

0..1  > reserved
2..3  > IRDA
4..7  > ETHR
8..11 > reserved
12..15 > USB
16..17 > reserved
18..23 > PSC3
24..27 > PSC2
28..31 > PSC1 

Final value is 216 + requested pin (example for PSC3_3 216+20 => 236)

Enable PIN for GPIO:

echo 236 >/sys/class/gpio/export

Set GPIO as output or input

echo out >/sys/class/gpio/gpio236/direction
echo in >/sys/class/gpio/gpio236/direction

Set GPIO to 0 or 1 if configured as output pin

echo 0 >/sys/class/gpio/gpio236/value
echo 1 >/sys/class/gpio/gpio236/value

RS485/RS422 selection on PSC1

In MPC5200 or schematic it is PSC2. In linux is PSC numbered from 0 so it is PSC1.

Pin configuration:

echo 254 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio254/direction

Run for RS485:

echo 1 >/sys/class/gpio/gpio254/value

Run for RS422:

echo 0 >/sys/class/gpio/gpio254/value

Linux boot possibilities

PIN configuration

Bootloader is responsible for pin configuration. This is done by writing to GPS Port Configuration Register. The value written there is set by:

set psc_cfg 91551044

GPS Port Configuration Register values for our boards:

  • original Midam board: 0x90552444
  • RYU_EDU_midam v1.B: 0x91551044

Kernel and root filesystem from flash

This is the default boot command. If you want to quickly switch several boot combinations, you can store these commands to a variable and use run command to boot linux from flash quickly.

set bootcmd_linux 'set bootargs ${linux_console} ${bootargs_flash}; mw f0000b00 ${psc_cfg}; bootm fc120000 - fc100000'
set bootcmd 'run bootcmd_linux'

Kernel from flash and root filesystem over NFS

set bootcmd_nfsroot 'set bootargs ${linux_console} ${bootargs_nfs}; dhcp; mw f0000b00 ${psc_cfg}; bootm fc120000 - fc100000'
set bootargs_nfs 'root=/dev/nfs nfsroot=/midam rw ip=dhcp'
run bootcmd_nfsroot

Kernel from TFTP and root filesystem over NFS

set serverip
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile /srv/tftp/ryu/uImage
set devicetreefile /srv/tftp/ryu/shark-ryu.dtb
set bootcmd_tftpnfs 'dhcp; tftp 800000 ${imagefile}; tftp 7f0000 ${devicetreefile}; set bootargs ${linux_console} root=/dev/nfs nfsroot=${serverip}:${nfspath} rw ip=dhcp; mw f0000b00 ${psc_cfg}; bootm 800000 - 7f0000'
run bootcmd_tftpnfs

Without DHCP server (static IP configuration)

set ipaddr
set netmask
set serverip 
set imagefile ryu/uImage
set devicetreefile ryu/shark-ryu.dtb
set nfspath /srv/nfs/root-shark
set bootcmd_tftpnfs_static 'tftp 800000 ${imagefile}; tftp 7f0000 ${devicetreefile}; set bootargs ${linux_console} root=/dev/nfs nfsroot=${serverip}:${nfspath} rw ip=${ipaddr}; mw f0000b00 ${psc_cfg}; bootm 800000 - 7f0000'
set bootcmd 'run bootcmd_tftpnfs_static'

Updating kernel image in flash memory

set serverip
set imagefile /srv/tftp/ryu/uImage
set devicetreefile /srv/tftp/ryu/shark-ryu.dtb
run update_kernel

It is supposed that update_kernel is set to the following value

set update_kernel 'dhcp; tftp 800000 ${imagefile}; erase fc100000 fc3fffff; cp.b 800000 fc120000 ${filesize}; tftp 800000 ${devicetreefile}; cp.b 800000 fc100000 ${filesize};'

Updating root filesystem image in flash memory

From Linux with NFS root

Erase flash in U-Boot:

erase fc400000 ffffffff

Boot Linux with NFS root and run:

mount -t jffs2 /dev/mtdblock2 /mnt
cd /
cp -a `ls | grep -v '\(mnt\|proc\|sys\|tmp\)'` /mnt
cd /mnt; mkdir mnt proc sys tmp

Running RT kernel

cyclictest -p 80 -t5 -n
0.93 0.68 0.28 1/51 562
T: 0 (  544) P:80 I:1000 C: 354314 Min:     16 Act:   76 Avg:   69 Max:     190
T: 1 (  545) P:79 I:1500 C: 236209 Min:     17 Act:   35 Avg:   53 Max:     131
T: 2 (  546) P:78 I:2000 C: 177157 Min:     21 Act:   46 Avg:   56 Max:     123
T: 3 (  547) P:77 I:2500 C: 141726 Min:     21 Act:   41 Avg:   53 Max:     155
T: 4 (  548) P:76 I:3000 C: 118105 Min:     23 Act:   30 Avg:   56 Max:     126

Kernel shark/

root@shark ~> cyclictest -p 80 -t5 -n
policy: fifo: loadavg: 117.09 33.86 11.60 1/47 981             

T: 0 (  550) P:80 I:1000 C: 293846 Min:     26 Act:   77 Avg:   58 Max:     132
T: 1 (  551) P:79 I:1500 C: 195897 Min:     31 Act:   60 Avg:   68 Max:     170
T: 2 (  552) P:78 I:2000 C: 146924 Min:     32 Act:   78 Avg:   65 Max:     137
T: 3 (  553) P:77 I:2500 C: 117539 Min:     36 Act:   62 Avg:   60 Max:     199
T: 4 (  554) P:76 I:3000 C:  97949 Min:     32 Act:   41 Avg:   62 Max:     128

Note: hackbench was executed during the test to load the CPU.

VxWorks Support

Booting VxWorks

set ethaddr 00:04:9f:00:27:xx
set psc_cfg 91551044
set bootcmd_vxworks 'set serverip; dhcp; mw f0000b00 ${psc_cfg}; tftp 0x100000 vxworks/vxWorks-midam.bin; go 0x100000'
set bootcmd 'run bootcmd_vxworks'

Older tests:

dhcp; set serverip; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

Compiling VxWorks

It is assumed that VxWorks in installed under /opt/WindRiver

/opt/WindRiver/wrenv.sh -p vxworks-6.7
cd <bsp_project>

VxWorks BSP and kernel projects used for PSR course can be downloaded as a tarball.

RTEMS Support

MIDAM MPC5200 board is compatible with RTEMS IceCube BSP.

The PowerPC cross-compiler tool-chain for RTEMS-4.9 branch for Debian Intel 32 and 64-bit hosts can be installed from Rtime local DEB repository [1].

RTEMS-4.10 branch tools and RTEMS packages can be found at [2].

  • Add APT source:
echo deb ftp://rtime.felk.cvut.cz/debian unstable main  >/etc/apt/sources.list.d/rtime-debs.list
  • Update list of available packages
apt-get update

Next packages can be installed from cross-dev section (e.g. using apt-get, aptitude or synaptic)

  • binutils-powerpc-rtems4.10
  • gcc-powerpc-rtems4.10
  • rtems4.10-common
  • rtems4.10-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored in local RTEMS development GIT repository in a build directory for PowerPC architecture.

The short cross-tools build recipe:

 git clone git://rtime.felk.cvut.cz/rtems-devel.git
 cd rtems-devel
 mkdir src
 cd src
 tar -xjf path-to/gcc-4.3.4.tar.bz2
 ln -s gcc-4.3.4 gcc
 tar -xjf path-to/binutils-2.20
 ln -s binutils-2.20 binutils
 tar -xzf path-to/newlib-1.16.0.tar.gz
 ln -s newlib-1.16.0 newlib
 cd gcc
 ln -s ../newlib/newlib .
 ln -s ../../gcc-patches/4.3.4 patches
 quilt push -a
 cd ../newlib
 ln -s ../../newlib-patches/newlib-1.16.0 patches
 quilt push -a
 cd ../..
 ln -s src/gcc src/binutils src/rtems .
 ( cd rtems-build/powerpc-rtems/binutils && ./binutils-powerpc-rtems.cfg && make && make install )
 ( cd rtems-build/powerpc-rtems/gcc && ./gcc-powerpc-rtems.cfg && make && make install )
 ( cd rtems-build/powerpc-rtems/rtems-icecube && ./rtems-mpc5200-sys.cfg && make && make install )

Applications can be easily build by starting from RTEMS application template based on OMK rules:

 cd rtems-omk-template
 echo "RTEMS_MAKEFILE_PATH=/opt/rtems4.9/powerpc-rtems4.9/icecube" >config.target
 make default-config all

Compiled application ELF images are located in _compiled/icecube/bin directory. The ELF file needs to be be converted into U-boot image to be transferred and started on target board

powerpc-rtems4.9-objcopy -R -S -O binary appfoo appfoo.bin
cat appfoo.bin | gzip -9 >appfoo.gz
mkimage -A ppc -O rtems -T kernel -a 0x00010000 -e 0x00010000 -n RTEMS -d appfoo.gz appfoo.img

The image tranfer and boot sequence can be initiated from target board U-boot prompt

mw f0000b00 ${psc_cfg}
#set serverip
tftp 1000000 appfoo.img

The script rtems-mpc5200-mkimg to pack ELF file to U-boot image is part of development repository as well.


Following OMK based example includes configuration required to build network and NFS enabled application on RTEMS


Mounting NFS into RTEMS

mkdir /mnt
mkdir /mnt/nfs
mount -t nfs /mnt/nfs

Open Real-Time Ethernet (ORTE) on RTEMS

ORTE is an open source C implementation of the Data Distribution Service (DDS) and RTPS protocol.

ORTE project home page: http://orte.sourceforge.net/

Example fro RTEMS shell is included in ORTE code main repository


Running ORTE manager

spawn ortemanager -p -e

Running ORTE ping

spawn orteping -s
spawn orteping -p