HW wiki - User contributions [en]

MIDAM MPC5200 DB1

2010-02-11T09:03:54Z

Spinkao: /* Linux kernel */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.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/2.6.28.8 # 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.
* <tt>cd linux</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start 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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

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-2.6.26.5/_build/mpc5200_ryu/ 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 ===

TODO: How to compile IP tool for PowerPC

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

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

MIDAM MPC5200 DB1

2010-02-11T09:03:18Z

Spinkao: /* Linux kernel */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.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/2.6.28.8 // 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.
* <tt>cd linux</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start 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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

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-2.6.26.5/_build/mpc5200_ryu/ 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 ===

TODO: How to compile IP tool for PowerPC

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

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

MIDAM MPC5200 DB1

2010-02-11T09:01:02Z

Spinkao: /* Linux kernel */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.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/2.6.28.8 // 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.
* <tt>cd linux</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start compilation

'''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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

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-2.6.26.5/_build/mpc5200_ryu/ 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 ===

TODO: How to compile IP tool for PowerPC

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

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

MIDAM MPC5200 DB1

2010-02-11T08:52:48Z

Spinkao: /* From U-Boot */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.git repository]. You can clone it by:
git clone git://rtime.felk.cvut.cz/shark/linux.git

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.
* <tt>cd linux</tt>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start compilation

'''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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

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-2.6.26.5/_build/mpc5200_ryu/ 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 ===

TODO: How to compile IP tool for PowerPC

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

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

MIDAM MPC5200 DB1

2010-02-11T08:50:23Z

Spinkao: /* SocketCan */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.git repository]. You can clone it by:
git clone git://rtime.felk.cvut.cz/shark/linux.git

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.
* <tt>cd linux</tt>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start compilation

'''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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

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-2.6.26.5/_build/mpc5200_ryu/ 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 ===

TODO: How to compile IP tool for PowerPC

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

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

==== From U-Boot ====

FIXME: This section needs some tuning. It works, but there are some problems.

Note: There seem to be no problems, if you use correct erase block size, when creating the FS image, i.e. use -e 0x20000 instead of -e 0x10000 (Martin Zidek)

Prepare filesystem image in a development machine and create the filesystem image:
cd shark-root
mkfs.jffs2 -o ../shark-jffs2.img -b -e 0x10000
cp ../shark-jffs2.img /var/lib/tftpboot/ryu/

Then flash the image using the following uboot commands:
set fs_image ryu/shark-jffs2.img
set update_filesystem 'dhcp; tftp 800000 ${fs_image}; erase fc400000 ffffffff; cp.b 800000 fc400000 ${filesize}'
run update_filesystem

== 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

MIDAM MPC5200 DB1

2010-02-11T08:49:08Z

Spinkao: /* SocketCan */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.git repository]. You can clone it by:
git clone git://rtime.felk.cvut.cz/shark/linux.git

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.
* <tt>cd linux</tt>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start compilation

'''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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

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-2.6.26.5/_build/mpc5200_ryu/ 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 ===

TODO: How to compile IP tool for PowerPC

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

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

==== From U-Boot ====

FIXME: This section needs some tuning. It works, but there are some problems.

Note: There seem to be no problems, if you use correct erase block size, when creating the FS image, i.e. use -e 0x20000 instead of -e 0x10000 (Martin Zidek)

Prepare filesystem image in a development machine and create the filesystem image:
cd shark-root
mkfs.jffs2 -o ../shark-jffs2.img -b -e 0x10000
cp ../shark-jffs2.img /var/lib/tftpboot/ryu/

Then flash the image using the following uboot commands:
set fs_image ryu/shark-jffs2.img
set update_filesystem 'dhcp; tftp 800000 ${fs_image}; erase fc400000 ffffffff; cp.b 800000 fc400000 ${filesize}'
run update_filesystem

== 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

MIDAM MPC5200 DB1

2010-02-11T08:48:31Z

Spinkao: /* SocketCan */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.git repository]. You can clone it by:
git clone git://rtime.felk.cvut.cz/shark/linux.git

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.
* <tt>cd linux</tt>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start compilation

'''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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

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-2.6.26.5/_build/mpc5200_ryu/ 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 ===

TODO: How to compile IP tool for PowerPC

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

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

==== From U-Boot ====

FIXME: This section needs some tuning. It works, but there are some problems.

Note: There seem to be no problems, if you use correct erase block size, when creating the FS image, i.e. use -e 0x20000 instead of -e 0x10000 (Martin Zidek)

Prepare filesystem image in a development machine and create the filesystem image:
cd shark-root
mkfs.jffs2 -o ../shark-jffs2.img -b -e 0x10000
cp ../shark-jffs2.img /var/lib/tftpboot/ryu/

Then flash the image using the following uboot commands:
set fs_image ryu/shark-jffs2.img
set update_filesystem 'dhcp; tftp 800000 ${fs_image}; erase fc400000 ffffffff; cp.b 800000 fc400000 ${filesize}'
run update_filesystem

== 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

MIDAM MPC5200 DB1

2010-02-11T08:43:23Z

Spinkao: /* Boot loader */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.git repository]. You can clone it by:
git clone git://rtime.felk.cvut.cz/shark/linux.git

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.
* <tt>cd linux</tt>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start compilation

'''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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

make KERNELDIR=/home/marsark/src/linux-2.6.26.5/_build/mpc5200_ryu/ 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

Test the setup:

cansend can0 123#4567

=== Using ip tool ===

TODO: How to compile IP tool for PowerPC

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

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

==== From U-Boot ====

FIXME: This section needs some tuning. It works, but there are some problems.

Note: There seem to be no problems, if you use correct erase block size, when creating the FS image, i.e. use -e 0x20000 instead of -e 0x10000 (Martin Zidek)

Prepare filesystem image in a development machine and create the filesystem image:
cd shark-root
mkfs.jffs2 -o ../shark-jffs2.img -b -e 0x10000
cp ../shark-jffs2.img /var/lib/tftpboot/ryu/

Then flash the image using the following uboot commands:
set fs_image ryu/shark-jffs2.img
set update_filesystem 'dhcp; tftp 800000 ${fs_image}; erase fc400000 ffffffff; cp.b 800000 fc400000 ${filesize}'
run update_filesystem

== 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

MIDAM MPC5200 DB1

2010-02-09T14:04:11Z

Spinkao: /* Kernel from flash and root filesystem over NFS */

==Description==

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'''.

* [[Media:SHARK_V1_1_DOC_CZ.pdf|SHARK_V1_1_DOC_CZ.pdf‎]]
* [[Media:SHARK_V1_0_linux_DOC_CZ.pdf|SHARK_V1_0_linux_DOC_CZ.pdf]]

==Board overview==

[[Image: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. [http://pdfserv.maxim-ic.com/en/ds/MAX3222-MAX3241.pdf 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 [http://www.denx.de/wiki/DULG/Manual 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 upgrade u-Boot to newer version, which is able to hand over flat device tree to the kernel. Binary of u-Boot can be downloaded here: [ftp://rtime.felk.cvut.cz/shark-mpc5200/u-boot.bin 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:

dhcp
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:

saveenv

===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 [[Cross compilers|packages]] prepared by Pavel Píša.

== Linux kernel ==

It is necessary to use patched Linux sources. We maintain them in our [[Git]] [http://rtime.felk.cvut.cz/gitweb/shark/linux.git repository]. You can clone it by:
git clone git://rtime.felk.cvut.cz/shark/linux.git

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.
* <tt>cd linux</tt>
* <tt>mkdir -p _build/midam</tt>
* <tt>cd _build/midam</tt>
* Copy the following code to GNUmakefile file
<pre>
VERSION = 2
PATCHLEVEL = 6

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

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

MAKEFLAGS += --no-print-directory

ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-

TFTPBOOT=/var/lib/tftpboot/ryu

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

.PHONY: install all $(MAKECMDGOALS)

all:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT)

Makefile:;

$(filter-out all Makefile,$(MAKECMDGOALS)) %/:
$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@
</pre>
* <tt>make 52xx/midam_defconfig</tt> # or use <tt>52xx/ryu_defconfig</tt> for RYU board
* <tt>make menuconfig</tt> # if you need additional configuration
* <tt>make</tt> # start compilation

'''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==

New root file system has been built for MIDAM MPC5200 board. It's based on:
* Vanilla linux kernel v2.6.26.5
* Busybox v1.12.1
* Dropbear v0.51
* thttpd v2.25b

TODO: How to build a new root file system

== 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==

make KERNELDIR=/home/marsark/src/linux-2.6.26.5/_build/mpc5200_ryu/ 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

ifconfig can0 up
ifconfig can1 up

Test the setup:

cansend can0 123#4567

== 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 7.3.2.1 and 7.3.2.2. 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
/sys/class/gpio/gpiochip248/

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
/sys/class/gpio/gpiochip216/

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 147.32.86.30
set nfspath "/home/wsh/ppc/MPC5200/root-shark"
set imagefile ryu/uImage
set devicetreefile 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

=== Updating kernel image in flash memory ===

set serverip 10.1.1.3
set imagefile ryu/uImage
set devicetreefile 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

==== From U-Boot ====

FIXME: This section needs some tuning. It works, but there are some problems.

Note: There seem to be no problems, if you use correct erase block size, when creating the FS image, i.e. use -e 0x20000 instead of -e 0x10000 (Martin Zidek)

Prepare filesystem image in a development machine and create the filesystem image:
cd shark-root
mkfs.jffs2 -o ../shark-jffs2.img -b -e 0x10000
cp ../shark-jffs2.img /var/lib/tftpboot/ryu/

Then flash the image using the following uboot commands:
set fs_image ryu/shark-jffs2.img
set update_filesystem 'dhcp; tftp 800000 ${fs_image}; erase fc400000 ffffffff; cp.b 800000 fc400000 ${filesize}'
run update_filesystem

== 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

== Booting VxWorks ==

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

Older tests:
dhcp; set serverip 147.32.86.187; set bootfile vxWorks.bin; tftp 0x00100000; go 0x00100000

=== Compiling VxWorks ===

It is assumed that VxWorks in installed under <tt>/opt/WindRiver</tt>

/opt/WindRiver/wrenv.sh -p vxworks-6.6
cd <bsp_project>
make
... TODO ...

== RTEMS Support ==

MIDAM MPC5200 board is compatible with [http://www.rtems.org/ RTEMS] [http://www.rtems.org/wiki/index.php/Gen5200#IceCube IceCube] BSP.

The PowerPC [[Cross compilers| 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 [ftp://rtime.felk.cvut.cz/debian/pool/rtems-4.9/].

* 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.9
* gcc-powerpc-rtems4.9
* rtems4.9-common
* rtems4.9-icecube

The configurations used for above binutils, GCC and RTEMS BSP packages build are stored
in [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git local RTEMS development GIT repository]
in a [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-build/powerpc-rtems 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
[http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template RTEMS application template]
based on [http://rtime.felk.cvut.cz/omk 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}
dhcp
#set serverip 192.168.202.251
tftp 1000000 appfoo.img
bootm

The [http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/blob/HEAD:/rtems-build/powerpc-rtems/rtems-icecube/rtems-mpc5200-mkimg script rtems-mpc5200-mkimg]
to pack ELF file to U-boot image is part of development repository as well.

[[Category:Hardware]]
[[Category:MPC5200]]

Boa5200 HOWTO

2008-10-30T13:51:09Z

Spinkao: /* Socketcan */

==Introduction==
This document describes how to install and setup Linux and development environment for BOA5200 board.
Assume that you have a development machine (your PC) that you use for development and building your applications which you consequently want to get running and test on BOA5200.

==Serial line setting==
The easiest way to communicate with the board ,when there is no OS and remote shell running on it, is over serial line. Recommended serial communication program is minicom. Setup minicom as follows:

Baud Rate – 38400

Bits - 8

Parity – N

Stop Bits - 1

Hardware Flow Control:- No

Software Flow Control:- No

After the setup you will see Redboot> command prompt. Here you can enter Redboot`s commands.
Redboot is a simple boot manager bulit upon eCos real-time OS. For more details , see http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html.

==DHCP server setup==
Redboot supports BOOTP protocol which means that it is able to get network information(IP,netmask,gateway IP address,etc.) from DHCP server(provides BOOTP besides DHCP protocol). Install dhcp server (on debian: apt-get install dhcpd) on your development machine. Example of my dhcp configuration file /etc/dhcpd.conf:
# I have two ethernet interfaces:
# eth0 - Internet
# eth1 - connection to BOA5200 (IP= 192.168.10.1)
# I do not want to progate infos to 147.32.0.0 subnetwork
subnet 147.32.0.0 netmask 255.255.0.0 {
}

# private subnetwork
subnet 192.168.10.0 netmask 255.255.255.0 {
option broadcast-address 192.168.10.255;
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;

# settings for BOA5200
host BOA5200 {
hardware ethernet 00:08:f1:11:22:33;
fixed-address 192.168.10.2;
}
}

Start dhcp server and reboot the board. After booting it has assigned IP, netmask and gateway address:
+PHY0: AMD AM79C874
FEC eth0: 100Mb/Full Duplex
Ethernet eth0: MAC address 00:08:f1:11:22:33
IP: 192.168.10.2/255.255.255.0, Gateway: 192.168.10.1
Default server: 192.168.10.1

==TFTP server setup==
Redboot is able to load file from remote tftp server into memory. Tftp server is lanuched by inetd daemon when a new
connection comes.
Therefore add the following line into /etc/inetd.conf :
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd

Default tftp root directory is /tftpboot. You can change it by calling in.tftpd with specified directory as a parameter.

===Alternative way for Ubuntu based distro===

1. Install tftpd and related packages.
sudo apt-get install xinetd tftpd tftp

2. Create /etc/xinetd.d/tftp and put this entry:

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

3. Make /tftpboot directory

sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot

4. Start tftpd through xinetd

sudo /etc/init.d/xinetd start

see [[http://www.example.com Installing and setting TFTPD in Ubuntu]]

==Tool chain==
Toolchain(gcc, ld, ...) for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Unpack the archive:

cd /
tar xvzf gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz

You can also create a debian package from archive and then install the package:
alien --to-deb gcc-powerpc-603e-linux-gnu-4.1.1-bin.tar.gz
Note: If you are not root, use fakeroot to run the command.

==Getting the kernel==
'''2.4 kernel sources''' for MPC5200 can be found in ''eCos_Linux_boa5200/tgz'' directory on BOARD DOCUMENTATION CD or from ftp://rtime.felk.cvut.cz/MPC5200/kernel_2.4/linuxppc-2.4-boa5200-release_2006_05_10.tgz.

'''2.6 Kernel sources from A&M''' for MPC5200 can be downloaded from ftp://rtime.felk.cvut.cz/MPC5200/linuxppc-2.6.18-1_AM.tar.gz.
Default kernel configuration file is ftp://rtime.felk.cvut.cz/MPC5200/config-2.6.18-1_AM.

We recommend the vanilla 2.6.18 patched by patches from A&M and us. Patches can be downloaded from our [http://rtime.felk.cvut.cz/darcs/boa5200-linux Darcs repository] by
darcs get http://rtime.felk.cvut.cz/repos/boa5200-linux/
Follow the next section to apply the downloaded patches.

==Applying kernel patches==
It is recommended to use [http://linux.die.net/man/1/quilt quilt] tool to manage series of patches.

'''Mini-Howto:'''

Assuming kernel sources are in directory /usr/src/linux.

# <tt>cd /usr/src/linux</tt>
# <tt>mkdir patches</tt>
# Copy all patches you want to apply to ''patches'' subdirectory
# Create ''series'' file in ''patches'' subdirectory and write names of patch files each on separate line. The order the patches are stated in the file is significant!! The patch on the first line will be applied first followed by others.
# <tt>quilt push</tt> (<tt>quilt pop</tt>) - applies (unapplies) one patch from ''series'' file. To (un)apply all patches use <tt>quilt push -a</tt> (<tt>quilt pop -a</tt>).

==Building kernel==

Do not forget to set ARCH and CROSS_COMPILE variables to this values in Makefile:
export ARCH=ppc
export CROSS_COMPILE=powerpc-603e-linux-gnu-

After compilation a built image is placed into arch/ppc/boot/image directory.

The following commnad will install modules into ''<directory>''/lib/modules/...
make INSTALL_MOD_PATH=''<directory>'' modules_install

'''Recommendation:'''

1. Make the building directory linuxppc-2.6.18-1_AM_build, where object files will be placed, outside the origin source directory linuxppc-2.6.18-1_AM

mkdir linuxppc-2.6.18-1_AM_build

2.
cd linuxppc-2.6.18-1_AM
linuxppc-2.6.18-1_AM directory must be clean i.e. no make, make menuconfig executed from this directory
before!

3.
make O=../linuxppc-2.6.18-1_AM_build menuconfig
kernel config file (.config) will be created in linuxppc-2.6.18-1_AM_build

Next time, always run make menuconfig always from the building directory, i.e. linuxppc-2.6.18-1_AM_build

4.
cd linuxppc-2.6.18-1_AM_build

5.
Download ftp://rtime.felk.cvut.cz/MPC5200/GNUmakefile

6.
Edit GNUmakefile and change paths in KERNELSRC and KERNELOUTPUT variables

7.
make && make modules_install

If you often forget to switch to the build directory and run make in the source directory, put the following GNUmakefile into your source directory:
ifeq ($(O),)
$(error Please, run make in a different build directory (or use O= option))
else
include Makefile
endif

== Loading kernel ==

You can test your new image on the board as follows:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf

# execute image; root directory (/) is on flash memory
RedBoot> exec
If you want to load the kernel from different TFTP server than the one provided by DHCP, you can use the following command to set the IP address of your server:
RedBoot> ip_address -h 147.32.86.<xxx>

'''CAUTION:''' you must boot the kernel by RedBoot release at least 2007_02_01 otherwise it will not run! So you must load into RAM and then run the appropriate RedBoot image (or replace/update its image on flash with the new one - see
the next section) and after then you can execute kernel image.

To write the loaded kernel to FLASH memory, execute:
RedBoot> fi cr Linux

==Updating RedBoot==

You need to update RedBoot in order to boot Linux 2.6 kernel.

Download ftp://rtime.felk.cvut.cz/MPC5200/MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# load RedBoot image from tftp server into memory at the address 0x100000
RedBoot>lo -b 0x100000 MPC5200-2007.02.01-redbootROMRAM.srec

'''!!! Warning: File names are case-sensitive !!!'''

# write image in flash memory
RedBoot>fi cr RedBoot
RedBoot>reset

If upgrade fails you can fallback to ROM Redboot image by typing 'A&M:'

If image of ROMRAM version of RedBoot with name "RedBoot" (case sensitive!!) is not found in FLASH minimal version of ROM RedBoot is started. This version does not support many services like TFTP protocol and FLASH management. To download ROMRAM version of RedBoot to FLASH it is necessary to follow these steps:

Load RAM version of RedBoot to BOA using xmodem (the image file MPC5200-2006.05.10-redbootRAM.srec is placed on BOA original CD):
RedBoot> lo -m xmodem

When finished RedBoot should answer with something like that:

CEntry point: 0x00080100, address range: 0x00080000-0x000bea04
xyzModem - CRC mode, 5763(SOH)/0(STX)/0(CAN) packets, 1 retries

Then start the RedBoot:
RedBoot> go

RAM RedBoot should start now. Download the new version of ROMRAM RedBoot to FLASH according to the steps above.

==NFS-root setup==

During the development phase of application it must be tested many times. However, it is annoying to copy several application files to flash memory every time. The practical solution is to mount via NFS working directory or whole root directory from the point of OS running on the board.

You can download already prepared root directory from ftp://rtime.felk.cvut.cz/MPC5200/MPC5200_root_070321.tar.gz

To export /var/MPC5200_root directory on your PC via NFS add the following line to '''/etc/exports''':

/var/MPC5200_root 192.168.10.0/255.255.255.0(rw,sync,no_root_squash)

Then run command "'''exportfs -ra'''" so that the change take an effect.

If you want MPC5200 to be mount as root directory instead of that one in flash memory:
# load kernel image from tftp server into memory
RedBoot> load zImage.elf
# execute kernel image with information where to
# find root directory in parameter string
RedBoot> ex -c "root=/dev/nfs rw nfsroot=192.168.10.1:/var/MPC5200_root ip=dhcp"

To mount another directory from Boa use this command:
mount -t nfs <ip>:/path/to/exported/dir /path/on/boa

'''NOTE:''' exportfs is a part of knfs (Ubuntu) or nfs-kernel-server (Debian) package.

== Login with telnet ==
telnet <ip address of boa>
Log in as root, ask me for the password. --[[User:Sojka|Sojka]] 20:42, 21 March 2007 (CET)
==Setting up BOA5200==

Use 'fconfig' command (see http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html manual) to set up BOA5200 configuration. Recommended configuration:

Run script at boot: true
Boot script:
load zImage.elf
ex -c "root=/dev/nfs rw nfsroot=192.168.123.254:/var/MPC5200_root ip=dhcp"
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: true
Default server IP address: IP address of your computer
FEC Network hardware address [MAC]: choose MAC address of the unit (example: 0x00:0x00:0x00:0x00:0x00:0x02)
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y

==Socketcan==

Prior to compiling linux kernel with socketcan driver, it is necessary to [http://rtime.felk.cvut.cz/hw/index.php/HOWTO#Applying_kernel_patches apply kernel patches] , which can be found in [http://rtime.felk.cvut.cz/repos/boa5200-linux/patches/ DARCS repository]

To set up can interface, it is necessary to configure the communication speed first and then bring the interface up. Communication speed can be set up using following command (for can0 interface @ 1Mbit):

echo 660000 >/sys/class/net/can0/can_baudrate

The constant 660000 for 1Mbit speed was found experimentally, driver seems to calculate the transmission speed improperly. To bring up the can network interface, use the same command as with any other network interface, i.e.

ifconfig can0 up

The most comfortable way of setting up both can interfaces upon startup of system is to place following script to /etc/init.d/ (name it 'can', for example)

echo 660000 >/sys/class/net/can0/can_baudrate
echo 660000 >/sys/class/net/can1/can_baudrate
ifconfig can0 up
ifconfig can1 up

==CanFestival==

===Obtaining and building CanFestival===

CanFestival driver source can be downloaded from. The primary way how to do it is to check out the source directory from CanFestival CVS by these steps:
cvs -d:pserver:anonymous@lolitech.dyndns.org:/canfestival login
(type return, without entering a password)
The system will respond:
Logging in to :pserver:anonymous@lolitech.dyndns.org:2401/canfestival
Then, enter:
cvs -z3 -d:pserver:anonymous@lolitech.dyndns.org:/canfestival co -P CanFestival-3
Then insert CanFestival folder and run this commands:
./configure --timers=unix --can=socket --cc=powerpc-603e-linux-gnu-gcc --arch=ppc --os=linux --target=unix
make
make install
Building of CanFestival will produce some libraries and copy them to /usr/powerpc-603e-linux-gnu/lib folder.

===Setting up local CANopen node===

CanFestival source includes tool called ''objdictedit''. This program has graphical user interface and serves to creating configuration of the CANopen node of application we develop. It is started by command ''objdictedit''. Using this program you can create the object dictionary for the CanFestival. Mainly it is necessary to set up all SDO and PDO, the node has to send and receive. To each PDO you have to define more things - PDO receive or transmit, variable to be mapped and variable mapping. The variable will then be used in application code to exchange data between CanFestival driver and application. If you set up PDOs here they will be sent and received automatically and the values will be stored into mapped variable. Setting up SDO means that you can use it in your application, but if you want to send it, it has to be done in code.
After creating this basic configuration you have to build the dictionary which results into to files with extensions .h and .c. You have to link these files with your application.

===Initializing and starting CanFestival===

To explain how to use CanFestival I include some code examples. It supposes node configuration generated by ''objdictedit'' which name is ''canopen''. It is then used as prefix of automatically generated functions and variables (''canopen_Data'' is for example object dictionary used by CanFestival).
Header ''canfestival.h'' has to be included. For start using CanFestival it is necessary to load dynamic library with CAN bus driver API created while compiling CanFestival source. In the example SocketCan driver is used to access CAN bus.
if(!LoadCanDriver("libcanfestival_can_socket.so")) {
exit -1;
}
Then you have to open CAN device. Parameters of the communication have to be prepared in structure of type ''s_Board''. In this case CAN is set to use device ''can1'' and baudrate 1Mbps. Handler of the bus is then stored to variable of type ''CAN_HANDLE''.
/**
* CAN board definition.
* Device name can1, baudrate 1M
*/
s_BOARD canopen_board = {"1", "1000"};

CAN_HANDLE canopen_handle;

if(!(canopen_handle = canOpen(&canopen_board, &canopen_Data))) {
exit -1;
}
CanFestival implements callbacks to some events like change of state or message reception. There are pointers to callback functions in ''canopen_Data'' structure. You can assign your own functions to these pointers or leave them unused.
canopen_Data.initialisation = canopen_initialisation;
canopen_Data.preOperational = canopen_preOperational;
canopen_Data.operational = canopen_operational;
canopen_Data.post_sync = canopen_post_sync;
canopen_Data.post_TPDO = canopen_post_TPDO;
canopen_Data.stopped = canopen_stopped;
After setting up these few things you have to call function ''StartTimerLoop'' which initializes CanFestival timers. As an argument you have to insert pointer to the first function you want to proceed after starting the timers.
StartTimerLoop(&initNode);
Here is an example of such a function. It sets local node ID to 1 and bring the node to operation state. Callback functions are called after changing state if used.
void initNode(CO_Data * d, UNS32 id)
{
setNodeId(&canopen_Data, 0x01);
setState(&canopen_Data, Initialisation);
setState(&canopen_Data, Operational);
}

===Stopping CanFestival===

After finishing work with CANopen it is good to stop the communication and timers and close the device. It is done by these few functions.
setState(&canopen_Data, Stopped);
StopTimerLoop();
canClose(&canopen_Data);
canopen_handle = NULL;

===Writing to Object dictionary===

CANopen devices and all network services of each node are configured by writing to device object dictionary (OD). It is different while writing to local OD or OD of some network device.
====Writing to local OD====
Function ''WriteLocalDict'' is used for writing to OD of local node managed by CanFestival.
UNS32 writeLocalDict( CO_Data* d,
UNS16 wIndex,
UNS8 bSubindex,
void * pSourceData,
UNS8 * pExpectedSize,
UNS8 checkAccess);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''wIndex''' - the index in the object dictionary where you want to write an entry
'''bSubindex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''pbSourceData''' - pointer to the variable that holds the value that should be copied into the object dictionary
'''pExpectedSize''' - pointer to variable with size of the data to be written
'''CheckAccess''' - if other than 0, do not read if the data is Read Only or Constant

====Writing to network OD====

It is necessary to use SDO service for writing data to OD of some network device. Each CANopen device has at least one SDO server. It means that it is able to receive SDOs with one ID and answer by SDOs with another ID. It is usual that the server listen for SDOs with ID 0x600 + ID of the node and transmits SDOs of ID 0x580 + node ID. Each SDO we want to use has to be defined while creating node configuration by ''objdictedit''. Then the SDO is sent by calling appropriate function. The best is to use function ''writeNetworkDictCallBack'' which syntax is shown below.
UNS8 writeNetworkDictCallBack (CO_Data* d,
UNS8 nodeId,
UNS16 index,
UNS8 subIndex,
UNS8 count,
UNS8 dataType,
void *data,
SDOCallback_t Callback);
Meaning of function arguments:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we want to send SDO
'''index''' - the index in the object dictionary where you want to write an entry
'''subIndex''' - the subindex of the Index. e.g. mostly subindex 0 is used to tell you how many valid entries you can find in this index. Look at the canopen standard for further information
'''count''' - number of bytes to be written
'''dataType''' - type of the data, use 0 for integers, real numbers and other values
'''data''' - pointer to the data
'''Callback''' - pointer to a function which is called after finishing the transfer
The SDO service is by definition confirmed. It means that SDO server sends response with result of the transfer after each SDO reception. This response has to be read by client to be sure that the data were written correctly. The result should be read in your function which pointer is given to the function ''writeNetworkDictCallBack'' as parameter ''callback''. The result of SDO transfer in such a function is read by CanFestival function ''getWriteResultNetworkDict''. This function has to be called after each SDO transmission because it releases line used to transfer. Header of this function is:
UNS8 getWriteResultNetworkDict (CO_Data* d, UNS8 nodeId, UNS32 * abortCode);
And meaning of function arguments is:
'''d''' - pointer to local object dictionary structure
'''nodeId''' - ID of the device we have sent SDO
'''abortCode''' - pointer to the variable where error code is written in case of error
The function can return one of these values according to the SDO transfer state:
'''SDO_FINISHED''' - data is available
'''SDO_ABORTED_RCV''' - Transfer failed. (abort SDO received)
'''SDO_ABORTED_INTERNAL''' - Transfer failed. Internal abort.
'''SDO_DOWNLOAD_IN_PROGRESS''' - Data not yet available
The function can be used in cycle waiting while return value is ''SDO_DOWNLOAD_IN_PROGRESS''. But the better solution is calling it in callback function from ''writeNetworkDictCallBack''. The callback is call after finishing the transfer.

===Using PDO service===

Using PDO service for data exchange is very easy in CanFestival. The most usual transmission type of PDOs is that they are transmitted after SYNC message. In this case it just has to be set up in objdictedit configuration and then it works, reads and stores values into mapped variables. After each PDO reception or transmission ''post_TPDO'' callback is called if used.
Sometimes it is necessary to send PDO from code without SYNC message reception. This is done by calling the function ''sendPDOevent'' with this syntax:
UNS8 sendPDOevent(CO_Data* d);
where ''d'' is the pointer to local object dictionary structure. This function sends all PDOs defined by ''objdictedit'' and transmission type ''after event'' (0x255).

===Generating SYNC message===

If you want to set up local node to become the SYNC server you have to write some information to local OD. Here is an example of function which set up the SYNC messages generation:
/**
* This function initializes local canopen node to send SYNC message
* with given period.
* @param d - local object dictionary
* @param period - period of the SYNC message in us
*/
void synchro_setup(CO_Data *d, unsigned long period)
{
UNS32 SYNC_COBID = 0x40000080;
UNS32 SYNC_INTER = period;
UNS8 size = sizeof(UNS32);
writeLocalDict(d, 0x1006, 0x0, &SYNC_INTER, &size, RW);
writeLocalDict(d, 0x1005, 0x0, &SYNC_COBID, &size, RW);
}
According to CANopen specification ID of the SYNC message is 0x80.
After the setup it can be started by command ''startSYNC(CO_Data *d)'' and stopped by command ''stopSYNC(CO_Data *d)''.

===SDO and PDO example===

At the end I attach example of a function (''cpd_start()'') which starts some device communicating by CANopen. The ID of the device is given by the parameter. The other function (''cpd_checkSDO_start()'') is callback used to handle SDO transfer result. It is necessary to wait until one SDO transfer is finished before starting some other. Global variable ''cpd_init_step'' is used for counting actual step of SDO transfer. If some SDO transfer fails it is set to -1 and the startup process is terminated.
/**
* This function is given to the writeNetworkDict function as a callback.
* It checks the result of SDO transmition and after finishing the transmition
* it closes the transfer.
* @param d - local object disctionary
* @param nodeID - ID of the node which the local node is communicating with
*/
void cpd_checkSDO_start(CO_Data* d, UNS8 nodeId)
{
UNS32 abortCode;
if(getWriteResultNetworkDict (d, nodeId, &abortCode) != SDO_FINISHED) {
cpd_init_step = -1;
}
closeSDOtransfer(&canopen_Data, nodeId, SDO_CLIENT);
cpd_start(&canopen_Data, nodeId);
}

/**
* This function switch canopen device into operational state.
* @param d - local object dictionary
* @param nodeId - ID of the device
* return 0 - ok, -1 - failed
*/
int cpd_start(CO_Data *d, UNS8 nodeId)
{
UNS8 data8;
UNS16 data16;
UNS32 data32;
switch(cpd_init_step++) {
case 0:
masterSendNMTstateChange(d, nodeId, NMT_Start_Node);
cpd_controlword = 0;
sendPDOevent(d);
cpd_controlword = 6;
sendPDOevent(d);
cpd_controlword = 0x0F;
sendPDOevent(d);

// Start operational mode
data8 = 0xFC;
writeNetworkDictCallBack(d, nodeId, 0x6060, 0x00, 1, 0, &data8, cpd_checkSDO_start);
break;
case 1:
// Check operation status
readNetworkDictCallback(d, nodeId, 0x6061, 0x00, 0, cpd_checkSDO_start);
break;
case 2:
// Setpoint specification
data16 = 0x0002;
writeNetworkDictCallBack(d, nodeId, 0x301B, 0x11, 2, 0, &data16, cpd_checkSDO_start);
break;
case 3:
canopen_init_result = 0;
cpd_init_step = 0;
break;
case -1:
canopen_init_result = -1;
cpd_init_step = 0;
break;
}
return 0;
}

===Emergency message===

New version of CanFestival is extended by EMCY messages support. There is callback added which can be set to point to your own EMCY message handler.This handler has to be a function with three parameters defined in this way:
void my_post_emcy(UNS8 nodeID, UNS16 errCode, UNS8 errReg)
After reception of an EMCY message this callback is called. The parameters keep information about node ID of the EMCY producer, error code and content of the error register.
To register your handler you have to set the callback in CanFestival initialization.
my_Data.post_emcy = my_post_emcy;

H8300-boot

2007-01-22T10:20:18Z

Spinkao: /* Bootstrapping the processor */

== Getting the software ==

Actual source code can be downloaded using a [[Darcs]] tool:

darcs get http://rtime.felk.cvut.cz/repos/h8300-boot

This will create a copy of the repository on your computer. You can upgrade your repository using the command:

darcs pull

If you have an acount on the ''rtime'' server, you can use ''ssh''-based access to the repository. If an administrater gave you the right for writing to the repository, you can not only read (pull) repository but also write (push) changes to the repository.

The syntax for getting the repo is:

darcs get <login>@rtime.felk.cvut.cz:/var/repos/h8300-boot

Browsing of project sources is also possible via [http://rtime.felk.cvut.cz/darcs/darcsweb.cgi?r=h8300-boot;a=summary Darcs web interface].

If you plan to record some changes and push them back to the server, it is recomended to add the following lines to <tt>_darcs/prefs/boring</tt>:

^TAGS$
^config\.omk
^_build
^_compiled

== Compiling ==

First, you have to configure the make-system for a board you plan to use. For ''h8canusb'' execute the following command from h8300-boot directory:
ln -s board/h8canusb/config.h8canusb config.omk
make default-config
Then, you can change default configuration of what is compiled by copying <tt>config.omk-default</tt> to <tt>config.omk</tt>. In the copied file change default configuration as you want and delete other lines you want to have default value.

After typing
make
everithing is goning to compile and if the compilation is completed without errors, you can use this ''build environment'' for building your own applications.

=== Compiling one application only ===

To compile only a part of sources (e.g. your own application), change the directory to where your applications resides and run
make
This will (re)compile everithing in current directory and all subdirectories. The result of compilation can be found under the <tt>_compiled</tt> direcotry (located at root of h8300-boot directory structure). The structure of <tt>_compiled</tt> directory is as follows:

; bin : binary programs for target system
; bin-utils : binary programs for host system (PC) (note: This will probably change in future)
; include : header files which are used when compiling for target
; libs : compiled libraries for target

There is another directory called <tt>_build</tt> where intermediate products of compilation such as object files, linker maps and dependency descriptions are stored. You can delete files in <tt>_build</tt> corresponding to your application by issuing
make clean
If you want to delete both <tt>_compiled</tt> and <tt>_build</tt> directories, run
make distclean

==== Using non-default link variant ====

If your board has it's default link variant set for example to ''ram'' and you want to link your application for flash memory, you can use the following command to compile another variant of your program:

make links_VARIANTS=flash

You can use more variant at once by

make links_VARIANTS="flash ram"

=== Loading and running an application ===

To load an application to the target processor, run

make load

This load the application from current directory to either RAM or FLASH memory. Which one is selected depends on a value of <tt>DEFAULT_LD_SCRIPT_VARIANT</tt> variable. This variable can be set globaly in <tt>config.target</tt> or locally in <tt>Makefile.omk</tt> and the first word of the value of this variable determines the default memory location for loading (and running).

If you want to load an application to different memory location, use one of
make load-flash
make load-ram

If there are more programs to load in the current directory, and you want to load a non-default one, you have to run
make load-<progname>-ram
make load-<progname>-flash

After loading your application, you can run it by running one of the following
make run
make run-ram
make run-flash

You can also combine loading and running to one step and use
make load run

=== Bootstrapping the processor ===

In order to be able to load applications to the target system, there have to be a boot loader program in processor's FLASH memory. It has to be loaded through serial channel 1 (pins TxD1, RxD1). The loader program is located at <tt>app/bloader</tt> directory and you can load it to the processor by
sh bootstrap
from <tt>bloader</tt> direcotry.

== Using KDevelop for development ==

[http://www.kdevelop.org/ KDevelop] is very good IDE for developing various kind of applications. It can be easily used to develop software for H8300 processors and can be well integrated with OMK make-system.

If you want to use KDevelop for development, follow theese points:

# Import project to KDevelop (from menu choose Project -> Import existing project). Select the type of project to ''Generic C Application (Custom Makefile)'' [[Image:Kdevelop1.png]]
# (Optional) Populate your project with source files by anwering '''yes''' to the dialog. [[Image:Kdevelop2.png]]
# Open ''Project Options'' dialog (menu Project -> Project Options) and choose ''Run Options''. Select '''Run from the BUILD directory''', to Main Program editbox write '''/usr/local/bin/make''' (you may have your ''make'' in a different directory) and as ''Program Arguments'' write '''load run'''. [[Image:Kdevelop3.png]]
# Now you can compile your application by pressing ''F8'' and if there are some errors, you can quickly jump the place in source whre the error is by pressing ''F4''. [[Image:Kdevelop4.png]]
# After successfull compilation you can run your application by clicking ''Execute program'' icon. I recomend you to create shortcut key ''F9'' for this action. If you change your sources, you can booth recompile and execute your application by simply pressing ''F9''. [[Image:Kdevelop5.png]]

== Using TAGS for navigation in files ==

If you run
make TAGS
in any direcotry, the file TAGS in the toplevel directory of the project will be created. This file can be used by various editors (such as [[wikipedia:Emacs|Emacs]]) for quick searching of symbols in source files.

== Writing your own application ==

TODO:

=== Interrupts ===

Interrupts are disabled by default. If you wand to use interrupts in your application you have to enable them explicitly by
sti();

''Interrupts handling mechanisms'' are initialized by calling <tt>excptvec_initfill</tt> and particular interrupts are setup by calling <tt>excptvec_set</tt>. For example see the code bellow.

void no_isr(void) __attribute__ ((interrupt_handler));
void no_isr(void) {};

void my_isr(void)
{
/* some code */
}

int main()
{
// all the interrupts will run no_isr
excptvec_initfill(no_isr, 0);

// set the interrupt handler my_isr to the interrupt vector
// number 42
excptvec_set(42, my_isr);

/* Enable interrupts which are disabled by default. */
sti();
...
}

When linking your program you need to link it with library <tt>excptvec</tt>. So in your Makefile.omk you will need a line similar to
yourprogram_LIBS = excptvec

=== Serial Communication ===

You have to include
#include <periph/sci_rs232.h>
then initialize the needed serial ports:
/* Initialize SCI channels 0 and 1 */
sci_rs232_setmode(19200, 0, 0, 0);
sci_rs232_setmode(19200, 0, 0, 1);
Then you can use:
sci_rs232_sendch('H', 0);
to send characters.

You can also use <tt>printf()</tt> and similar functions. The output of theese will go to the serial port specified by <tt>sci_rs232_chan_default</tt> variable. Its default value is selected in <tt>system_def.h</tt> and can be different for every board.

For examples see [http://rtime.felk.cvut.cz/darcs/darcsweb.cgi?r=h8300-boot;a=tree;f=/app/rs_test app/rs_test/*.c]