HW wiki - User contributions [en]

FPGA simulace

2010-11-01T23:26:39Z

Pecam1: /* Zkouseny a zkusebni VHDL kod */

==== Zkouseny a zkusebni VHDL kod ====

Chceme simulovat odezvu vlastnich bloku, napsanych ve [[VHDL]]. Prikladem budiz ctyrbitovy citac [[File:citac.vhdl]]:

<pre>
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;

entity citac is
port (
clock: in std_logic;
qcount: out std_logic_vector (3 downto 0)
);
end citac;

architecture behavioral of citac is
signal counter: std_logic_vector (3 downto 0) := "0000";
begin

qcount <= counter;

seq: process
begin
wait until clock'event and clock = '1';
counter <= counter + 1;
end process;

end behavioral;
</pre>

Je treba vyplnit u registru pocatecni podminky (<code>signal counter: std_logic_vector (3 downto 0) := "0000";</code>). Uvedeny citac ma vyvedeny signaly <code>clock</code> (vstup hodin) a <code>qcount</code> (4bit vystup). Nyni je treba vytvorit (opet ve VHDL) ''zkusebni nastroj'' (testbench), do nehoz bude citac (a pripadne i vice bloku) zapojen a ktery bude generovat zkusebni vstupni signaly. V tomto pripade je zkusebni signal jednoduchy, staci periodicke hodiny na signal <code>clock</code>.

Zde je kod zkusebniho nastroje [[File:citac_tb.vhdl]]:

<pre>
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;

entity citac_tb is
end citac_tb;

architecture behavioral of citac_tb is
component citac
port (
clock: in std_logic;
qcount: out std_logic_vector (3 downto 0)
);
end component;
for citac_0: citac use entity work.citac;
--
signal clock: std_logic;
signal qcount: std_logic_vector (3 downto 0);
begin
citac_0: citac
port map (
clock => clock,
qcount => qcount
);

--
process
begin
clock <= '0';
wait for 1 us;
clock <= '1';
wait for 1 us;
end process;

end behavioral;
</pre>

Entita nahore je prazdna, protoze zkusebni nastroj nema ven vyvedeny zadne signaly, neni to potreba. Nize je pak instanciovan citac a v tele nastroje je nekonecne dlouho bezici proces, ktery periodicky strida urovne na signalu <code>clock</code>. Je samozrejme mozne utvorit i konecne dlouho bezici zkusebni nastroje. Cas 1us jsem zvolil libovolne.

==== Simulace v GHDL ====

VHDL soubory je nyni mozne zkompilovat simulatorem GHDL

<pre>
ghdl -a --ieee=synopsys citac.vhdl
ghdl -a --ieee=synopsys citac_tb.vhdl
</pre>

a slinkovat do spustitelneho souboru:

<pre>
ghdl -e --ieee=synopsys citac_tb
</pre>

Volba <code>--ieee=synopsys</code> je pouzita proto, ze jsem v prikladu pouzil nestandardni datove typy, obvykle ve svete FPGA, ale nestandardni vzhledem k IEEE VHDL. (Nerikam, ze je to dobre, chce to zjistit, zda se standardem budeme schopni vystacit.)

Nasledne spustime simulaci

<pre>
ghdl -r citac_tb --vcd=citac.vcd
</pre>

...ta bezi nekonecne, takze ji prerusime Ctrl-c. Byl zadan vystup do souboru ve formatu VCD, kde by se mely objevit prubehy vsech signalu.

==== Prohlizeni prubehu ====

===== GtkWave =====

Soubor <code>citac.vcd</code> prohledneme pomoci GtkWave:

<pre>
gtkwave citac.vcd
</pre>

Pokud nas udivi, ze vidime jen casovou osu a zadne signaly, je treba v menu Search / Signal search hierarchy.. pridat signaly, ktere nas zajimaji, tedy <code>clock</code> a <code>qcount</code>.

[[Image:citac_gtkwave.png|frame|Simulovane prubehy zobrazene v GtkWave]]

===== Dinotrace =====

Nekomu muze vice vyhovovat program [http://www.veripool.org/wiki/dinotrace Dinotrace]. Mj. nacita rovnez format <code>.vcd</code>. Priklad zobrazeni signalu z mirne slozitejsiho obvodu je zde:

[[Image:dinotrace.png|frame|Simulovane prubehy zobrazene v Dinotrace]]

File:Dinotrace.png

2010-11-01T23:25:35Z

Pecam1:

File:Citac gtkwave.png

2010-11-01T23:25:04Z

Pecam1:

UrJTAG

2010-11-01T23:23:48Z

Pecam1: New page: ==== Program UrJTAG ==== Ke stazeni na [http://urjtag.org/] (nebo <code>apt-get install urjtag</code>). Verze 0.9 uspesne zkompilovana po konfiguraci <pre> ./configure --enable-cable --...

==== Program UrJTAG ====

Ke stazeni na [http://urjtag.org/] (nebo <code>apt-get install urjtag</code>).

Verze 0.9 uspesne zkompilovana po konfiguraci
<pre>
./configure --enable-cable --enable-bus --disable-nls --with-libftdi
</pre>

Verze 0.10 zkompilovana po
<pre>
./configure --without-ftd2xx
</pre>
(tj. pro praci s FTDI brouky nebudeme pouzivat binarni knihovnu ftd2xx)

==== Zavedeni nove soucastky do programu UrJTAG ====

UrJTAG je mozne naucit pracovat s libovolnou soucastkou, k niz je k dispozici [[BSDL]] popis (vetsina vyrobcu tyto soubory poskytuje). Pokud mame novou soucastku, s kterou UrJTAG jeste neumi, musime popis vytvorit. Prikladem budiz FPGA Actel A3PE1500. Musime

* sehnat BSDL popis, tj. stahnout u vyrobce [http://www.actel.com/documents/bsdl/A3PE1500_PQ208.bsd A3PE1500_PQ208.bsd]
* zjistit identifikacni cislo soucastky (''id-code'')

Identifikacni cislo vycteme primo JTAGem. Pripojime desku se soucastkou k rozhrani JTAG a vypiseme cislo UrJTAGem:
<pre>
jtag> cable usbblaster
Connected to libftdi driver.
jtag> detect
</pre>
(<code>usbblaster</code> je jmeno pouziteho ovladace, v tomto pripade jsem pouzil zarizeni Altera USB Blaster). UrJTAG vypise, co nasel v JTAGovem retezci. V nejjednodussim pripade, kdy je v JTAG retezci pouze jedina soucastka, tj. ta, kterou hledame, bude vypis vypadat takto:
<pre>
IR length: 8
Chain length: 1
Device Id: 00010010010100111010000111001111 (0x000000001253A1CF)
Unknown manufacturer!
</pre>
Z tohoto vycteme ''id-code'' v hodnote <code>...</code>

Nyni jiz muzeme vytvorit soubory pro podporu soucastky. Tyto soubory UrJTAG skladuje v <code>/usr/share/urjtag</code> (popr. <code>/usr/local/share/urjtag</code>). Podadresare odpovidaji vyrobcum soucastek, jejichz seznam, trideny podle casti ''id-code'', je v souboru <code>MANUFACTURERS</code>. Vzhledem k tomu, ze Actel jeste v seznamu neni, pridame do <code>MANUFACTURERS</code> radku:
<pre>
00011100111 actel Actel
</pre>
cislo jsou bity 11..1 z ''id-code'' (pocitaji se zleva od nuly, jak je zvykem). Vytvorime podadresar <code>actel</code> a v nem soubor <code>PARTS</code>:
<pre>
# bits 27-12 of the Device Identification Register
0010010100111010 A3PE1500_PQ208 A3PE1500_PQ208
</pre>
Nasledne vytvorime dalsi podadresar <code>actel/A3PE1500_PQ208</code> a v nem soubor <code>STEPPINGS</code>:
<pre>
# bits 31-28 of the Device Identification Register
0001 A3PE1500_PQ208 1
</pre>
(tomuhle moc nerozumim, asi jde o nejakou podvariantu soucastky, zrejme nejake poradove cislo). Soubor <code>actel/A3PE1500_PQ208/A3PE1500_PQ208</code> pak bude obsahovat samotny popis soucastky.

Tento popis ziskame z BSDL souboru prikazem
<pre>
bsdl2jtag < A3PE1500_PQ208.bsd > actel/A3PE1500_PQ208/A3PE1500_PQ208
</pre>

Od teto chvile by mel jiz UrJTAG poznat tuto soucastku:
<pre>
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00010010010100111010000111001111 (0x000000001253A1CF)
Manufacturer: Actel
Part(0): A3PE1500_PQ208
Stepping: 1
Filename: /usr/local/share/urjtag/actel/A3PE1500_PQ208/A3PE1500_PQ208
jtag>
</pre>

FPGA simulace

2010-11-01T23:22:16Z

Pecam1: New page: ==== Zkouseny a zkusebni VHDL kod ==== Chceme simulovat odezvu vlastnich bloku, napsanych ve VHDL. Prikladem budiz ctyrbitovy citac Soubor:citac.vhdl: <pre> library ieee; use iee...

==== Zkouseny a zkusebni VHDL kod ====

Chceme simulovat odezvu vlastnich bloku, napsanych ve [[VHDL]]. Prikladem budiz ctyrbitovy citac [[Soubor:citac.vhdl]]:

<pre>
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;

entity citac is
port (
clock: in std_logic;
qcount: out std_logic_vector (3 downto 0)
);
end citac;

architecture behavioral of citac is
signal counter: std_logic_vector (3 downto 0) := "0000";
begin

qcount <= counter;

seq: process
begin
wait until clock'event and clock = '1';
counter <= counter + 1;
end process;

end behavioral;
</pre>

Je treba vyplnit u registru pocatecni podminky (<code>signal counter: std_logic_vector (3 downto 0) := "0000";</code>). Uvedeny citac ma vyvedeny signaly <code>clock</code> (vstup hodin) a <code>qcount</code> (4bit vystup). Nyni je treba vytvorit (opet ve VHDL) ''zkusebni nastroj'' (testbench), do nehoz bude citac (a pripadne i vice bloku) zapojen a ktery bude generovat zkusebni vstupni signaly. V tomto pripade je zkusebni signal jednoduchy, staci periodicke hodiny na signal <code>clock</code>.

Zde je kod zkusebniho nastroje [[Soubor:citac_tb.vhdl]]:

<pre>
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;

entity citac_tb is
end citac_tb;

architecture behavioral of citac_tb is
component citac
port (
clock: in std_logic;
qcount: out std_logic_vector (3 downto 0)
);
end component;
for citac_0: citac use entity work.citac;
--
signal clock: std_logic;
signal qcount: std_logic_vector (3 downto 0);
begin
citac_0: citac
port map (
clock => clock,
qcount => qcount
);

--
process
begin
clock <= '0';
wait for 1 us;
clock <= '1';
wait for 1 us;
end process;

end behavioral;
</pre>

Entita nahore je prazdna, protoze zkusebni nastroj nema ven vyvedeny zadne signaly, neni to potreba. Nize je pak instanciovan citac a v tele nastroje je nekonecne dlouho bezici proces, ktery periodicky strida urovne na signalu <code>clock</code>. Je samozrejme mozne utvorit i konecne dlouho bezici zkusebni nastroje. Cas 1us jsem zvolil libovolne.

==== Simulace v GHDL ====

VHDL soubory je nyni mozne zkompilovat simulatorem GHDL

<pre>
ghdl -a --ieee=synopsys citac.vhdl
ghdl -a --ieee=synopsys citac_tb.vhdl
</pre>

a slinkovat do spustitelneho souboru:

<pre>
ghdl -e --ieee=synopsys citac_tb
</pre>

Volba <code>--ieee=synopsys</code> je pouzita proto, ze jsem v prikladu pouzil nestandardni datove typy, obvykle ve svete FPGA, ale nestandardni vzhledem k IEEE VHDL. (Nerikam, ze je to dobre, chce to zjistit, zda se standardem budeme schopni vystacit.)

Nasledne spustime simulaci

<pre>
ghdl -r citac_tb --vcd=citac.vcd
</pre>

...ta bezi nekonecne, takze ji prerusime Ctrl-c. Byl zadan vystup do souboru ve formatu VCD, kde by se mely objevit prubehy vsech signalu.

==== Prohlizeni prubehu ====

===== GtkWave =====

Soubor <code>citac.vcd</code> prohledneme pomoci GtkWave:

<pre>
gtkwave citac.vcd
</pre>

Pokud nas udivi, ze vidime jen casovou osu a zadne signaly, je treba v menu Search / Signal search hierarchy.. pridat signaly, ktere nas zajimaji, tedy <code>clock</code> a <code>qcount</code>.

[[Image:citac_gtkwave.png|frame|Simulovane prubehy zobrazene v GtkWave]]

===== Dinotrace =====

Nekomu muze vice vyhovovat program [http://www.veripool.org/wiki/dinotrace Dinotrace]. Mj. nacita rovnez format <code>.vcd</code>. Priklad zobrazeni signalu z mirne slozitejsiho obvodu je zde:

[[Image:dinotrace.png|frame|Simulovane prubehy zobrazene v Dinotrace]]

FPGA

2010-11-01T23:21:33Z

Pecam1: New page: * navod na simulaci FPGA bloku napsanych ve VHDL * prace s programem UrJTAG

* navod na [[FPGA simulace|simulaci FPGA]] bloku napsanych ve [[VHDL]]
* prace s programem [[UrJTAG]]

Template:Main Page/Hardware

2010-11-01T23:20:45Z

Pecam1: /* Hardware */

== Hardware ==

* [[Boa5200]]
* [[ColdFire_DEMO52233 | ColdFire DEMO52233 (Board from Freescale)]]
* [[MIDAM MPC5200 DB1]] (Mikroklima)
* [[H8S/2638]]
* [[HC12 | Motorola HC12]]
* [[LPC21xx]]
* [[AT91SAM7X256]]
* [[PiMX1]] i.MX1 processor based board
* [[Wireless_Sensor_Networks | Wireless Sensor Networks (WSNs)]]
* [[ML403 | ML403 Xilinx Virtex-4]]
* [[FPGA]]
* [[Humusoft MF6xx]]
* [[OJ10 - welding robot]]

Boa5200 HOWTO

2009-02-16T12:27:36Z

Pecam1: /* Updating root filesystem on BOA */

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

==IP address setting in Redboot==
You can set ip address in Redboot using command
[http://ecos.sourceware.org/ecos/docs-latest/redboot/ip-address-command.html ip_address] instead of obtaing it
from DHCP server(see next section).

ip_address [-b] [-l] local_IP_address [/netmask_length] ] [-h server_IP_address] [-d DNS_server_IP_address]

Example:

ip_address -l 192.168.100.1/24 -h 192.168.100.2

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

If you do not have a DHCP server on you network, you can install one on your development box: (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==

Linux kernel sources patched for the board are maintained in a [http://rtime.felk.cvut.cz/gitweb/boa5200/linux.git separate git tree]. Use
git clone git://rtime.felk.cvut.cz/boa5200/linux.git linux-boa5200
to download it.

You can also download the [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/.config;hb=HEAD default kernel .config].

==Building kernel==

The simples way to build the kernel is putting the .config file (see the previous section) to the directory with sources and running:
make ARCH=ppc 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:'''

Instead of building the kernel in the sources directory, we recommend using of a separate build directory:

1. Make the build directory under the linux sources
mkdir _build
cd _build

2. Put the [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/.config;hb=HEAD default .config] and [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/GNUmakefile;hb=HEAD GNUmakefile] into this directory

3. Optionally update the kernel configuration
make menuconfig
kernel config file (.config) will be updated

Next time, always run <tt>make menuconfig</tt> from the _build directory

4. Compile the kenrel and install modules
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

==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 [http://ecos.sourceware.org/ecos/docs-latest/redboot/startup-mode.html 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.

== Loading kernel ==

Place the compiled kernel to the tftpboot directory. Then 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 command
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-create-command.html fis create]:
Example:
RedBoot> fis cr Linux -b 0x00800000 -r 0x00100000 -e 0x00100000 -l 0x116000

To load the kernel from the FLASH are later, execute
RedBoot> fis load Linux
(Then, you can perform exec -c "..." cmd.)

To find out paramter values execute [http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-list-command.html fis list].

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

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

Create jffs2 image:
mkfs.jffs2 -r MPC5200_root -o jffs2.img -b -e 0x10000

On BOA:

Delete old image:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-delete-command.html fis delete] jffs2

Fill memory area at address 0x100000 of size 0xD00000 (size of root image + free space wanted) using
[http://ecos.sourceware.org/ecos/docs-latest/redboot/mfill-command.html mfill] command:

mfi -b 0x100000 -l 0xD00000 -p 0xffffffff

Load root image to that memory area:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/download-command.html load] -r -b 0x100000 jffs2.img

Write image to flash:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-create-command.html fis cr] -b 0x100000 jffs2 -l 0xD00000

Root filesystem is mounted as read-only in Linux. To enable writting:
mount -o remount,rw /

--[[User:Molnam1|Molnam1]] 17:35, 15 December 2008 (CET)

'''Remark:''' I have been unsuccessful doing these steps, maybe the filesystem has not been prepared correctly. However, there is another way to set up the JFFS2 filesystem in FLASH. If you mount a clean (0xff, 0xff,...) FLASH block device as -tjffs2, Linux will create the JFFS2 fs itself.

Procedue (on BOA):
* fis create ...
* fis erase ...
* boot Linux with a root elsewhere (NFS)
* in Linux: mount -tjffs2 /dev/mtdblock2 /mnt
* voila, the fs is created; now, you can untar or cp -a root contents to /mnt

--[[User:Pecam1|Pecam1]] 13:22, 16 February 2009 (CET)

Linux kernel commandline to boot using root in FLASH block device is following:
ex -c "root=/dev/mtdblock2 ro rootfstype=jffs2"
The number 2 of memory tech. device is a number of "jffs2" block in FLASH partitions list, example (0: (reserved), 1: RedBoot, 2: jffs,...):
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
(reserved) 0xF0000000 0xF0000000 0x00010000 0x00000000
RedBoot 0xF0010000 0xF0010000 0x00050000 0x00000000
jffs2 0xF0060000 0x00100000 0x00FF0000 0x00100000
Linux 0xF1050000 0x00800000 0x00110000 0x00800000
FIS directory 0xF1FF0000 0xF1FF0000 0x0000F000 0x00000000
RedBoot config 0xF1FFF000 0xF1FFF000 0x00001000 0x00000000

== 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 bootloder (automatic boot)==

Use 'fconfig' command (see [http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html RedBoot manual]) to set up bootloader 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==

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

For newer version of socketcan you must use:

echo 660000 >/sys/class/net/can0/can_bittiming/bitrate

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;

Boa5200 HOWTO

2009-02-16T12:22:46Z

Pecam1: /* Updating root filesystem on BOA */

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

==IP address setting in Redboot==
You can set ip address in Redboot using command
[http://ecos.sourceware.org/ecos/docs-latest/redboot/ip-address-command.html ip_address] instead of obtaing it
from DHCP server(see next section).

ip_address [-b] [-l] local_IP_address [/netmask_length] ] [-h server_IP_address] [-d DNS_server_IP_address]

Example:

ip_address -l 192.168.100.1/24 -h 192.168.100.2

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

If you do not have a DHCP server on you network, you can install one on your development box: (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==

Linux kernel sources patched for the board are maintained in a [http://rtime.felk.cvut.cz/gitweb/boa5200/linux.git separate git tree]. Use
git clone git://rtime.felk.cvut.cz/boa5200/linux.git linux-boa5200
to download it.

You can also download the [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/.config;hb=HEAD default kernel .config].

==Building kernel==

The simples way to build the kernel is putting the .config file (see the previous section) to the directory with sources and running:
make ARCH=ppc 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:'''

Instead of building the kernel in the sources directory, we recommend using of a separate build directory:

1. Make the build directory under the linux sources
mkdir _build
cd _build

2. Put the [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/.config;hb=HEAD default .config] and [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/GNUmakefile;hb=HEAD GNUmakefile] into this directory

3. Optionally update the kernel configuration
make menuconfig
kernel config file (.config) will be updated

Next time, always run <tt>make menuconfig</tt> from the _build directory

4. Compile the kenrel and install modules
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

==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 [http://ecos.sourceware.org/ecos/docs-latest/redboot/startup-mode.html 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.

== Loading kernel ==

Place the compiled kernel to the tftpboot directory. Then 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 command
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-create-command.html fis create]:
Example:
RedBoot> fis cr Linux -b 0x00800000 -r 0x00100000 -e 0x00100000 -l 0x116000

To load the kernel from the FLASH are later, execute
RedBoot> fis load Linux
(Then, you can perform exec -c "..." cmd.)

To find out paramter values execute [http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-list-command.html fis list].

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

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

Create jffs2 image:
mkfs.jffs2 -r MPC5200_root -o jffs2.img -b -e 0x10000

On BOA:

Delete old image:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-delete-command.html fis delete] jffs2

Fill memory area at address 0x100000 of size 0xD00000 (size of root image + free space wanted) using
[http://ecos.sourceware.org/ecos/docs-latest/redboot/mfill-command.html mfill] command:

mfi -b 0x100000 -l 0xD00000 -p 0xffffffff

Load root image to that memory area:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/download-command.html load] -r -b 0x100000 jffs2.img

Write image to flash:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-create-command.html fis cr] -b 0x100000 jffs2 -l 0xD00000

Root filesystem is mounted as read-only in Linux. To enable writting:
mount -o remount,rw /

--[[User:Molnam1|Molnam1]] 17:35, 15 December 2008 (CET)

'''Remark:''' I have been unsuccessful doing these steps, maybe the filesystem has not been prepared correctly. However, there is another way to set up the JFFS2 filesystem in FLASH. If you mount a clean (0xff, 0xff,...) FLASH block device as -tjffs2, Linux will create the JFFS2 fs itself.

Procedue (on BOA):
* fis create ...
* fis erase ...
* boot Linux with a root elsewhere (NFS)
* in Linux: mount -tjffs2 /dev/mtdblock2 /mnt
* voila, the fs is created; now, you can untar or cp -a root contents to /mnt

--[[User:Pecam1|Pecam1]] 13:22, 16 February 2009 (CET)

== 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 bootloder (automatic boot)==

Use 'fconfig' command (see [http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html RedBoot manual]) to set up bootloader 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==

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

For newer version of socketcan you must use:

echo 660000 >/sys/class/net/can0/can_bittiming/bitrate

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;

Boa5200 HOWTO

2009-02-16T12:15:12Z

Pecam1: /* Loading kernel */

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

==IP address setting in Redboot==
You can set ip address in Redboot using command
[http://ecos.sourceware.org/ecos/docs-latest/redboot/ip-address-command.html ip_address] instead of obtaing it
from DHCP server(see next section).

ip_address [-b] [-l] local_IP_address [/netmask_length] ] [-h server_IP_address] [-d DNS_server_IP_address]

Example:

ip_address -l 192.168.100.1/24 -h 192.168.100.2

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

If you do not have a DHCP server on you network, you can install one on your development box: (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==

Linux kernel sources patched for the board are maintained in a [http://rtime.felk.cvut.cz/gitweb/boa5200/linux.git separate git tree]. Use
git clone git://rtime.felk.cvut.cz/boa5200/linux.git linux-boa5200
to download it.

You can also download the [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/.config;hb=HEAD default kernel .config].

==Building kernel==

The simples way to build the kernel is putting the .config file (see the previous section) to the directory with sources and running:
make ARCH=ppc 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:'''

Instead of building the kernel in the sources directory, we recommend using of a separate build directory:

1. Make the build directory under the linux sources
mkdir _build
cd _build

2. Put the [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/.config;hb=HEAD default .config] and [http://rtime.felk.cvut.cz/gitweb/boa5200/configs.git?a=blob_plain;f=linux/GNUmakefile;hb=HEAD GNUmakefile] into this directory

3. Optionally update the kernel configuration
make menuconfig
kernel config file (.config) will be updated

Next time, always run <tt>make menuconfig</tt> from the _build directory

4. Compile the kenrel and install modules
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

==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 [http://ecos.sourceware.org/ecos/docs-latest/redboot/startup-mode.html 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.

== Loading kernel ==

Place the compiled kernel to the tftpboot directory. Then 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 command
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-create-command.html fis create]:
Example:
RedBoot> fis cr Linux -b 0x00800000 -r 0x00100000 -e 0x00100000 -l 0x116000

To load the kernel from the FLASH are later, execute
RedBoot> fis load Linux
(Then, you can perform exec -c "..." cmd.)

To find out paramter values execute [http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-list-command.html fis list].

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

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

Create jffs2 image:
mkfs.jffs2 -r MPC5200_root -o jffs2.img -b -e 0x10000

On BOA:

Delete old image:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-delete-command.html fis delete] jffs2

Fill memory area at address 0x100000 of size 0xD00000 (size of root image + free space wanted) using
[http://ecos.sourceware.org/ecos/docs-latest/redboot/mfill-command.html mfill] command:

mfi -b 0x100000 -l 0xD00000 -p 0xffffffff

Load root image to that memory area:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/download-command.html load] -r -b 0x100000 jffs2.img

Write image to flash:
[http://ecos.sourceware.org/ecos/docs-latest/redboot/fis-create-command.html fis cr] -b 0x100000 jffs2 -l 0xD00000

Root filesystem is mounted as read-only in Linux. To enable writting:
mount -o remount,rw /

--[[User:Molnam1|Molnam1]] 17:35, 15 December 2008 (CET)

== 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 bootloder (automatic boot)==

Use 'fconfig' command (see [http://ecos.sourceware.org/ecos/docs-latest/redboot/persistent-state-flash.html RedBoot manual]) to set up bootloader 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==

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

For newer version of socketcan you must use:

echo 660000 >/sys/class/net/can0/can_bittiming/bitrate

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;

ML403

2009-01-06T22:40:36Z

Pecam1:

== FPGA HW&SW development environment ==

=== Software ===

* Xilinx tools
** ISE 9.2i -- package for FPGA HW design; compiles input (HDL, netlist, schematics) and optimizes output bitstream according to given user constraints (mainly timing and pin assignment). In our work, ISE programs are almost exclusively invoked by EDK tools.
** EDK 9.2i -- package for FPGA HW&SW embedded system development; contains libraries of embedded computer IP cores and serves to glue HW FPGA cores together with software.
** Chipscope 9.1i (optional) -- logic analyzer inside of FPGA. Dedicated IP core sends measured waveforms by JTAG to Chipscope analyzer, running on PC with GUI.
* open-source software
** libusb-driver -- much better replacement/emulator of driver for Xilinx USB-JTAG adapter
** gcc 4.3.2, binutils, glibc -- development of system-less as well as Linux SW for PowerPC, contained in Xilinx Virtex-4 hybrid FPGA
** Linux 2.6.27-rc4 PowerPC kernel containing Xilinx Virtex support

=== Hardware ===

* Xilinx Virtex-4 XC4VFX12 hybrid FPGA IC on ML405 evaluation board

== Xilinx FPGA HW&SW development ==

=== Running Linux on FPGA embedded system ===

System HW is created by XPS (Xilinx Platform Studio, the essential part of EDK). The system is composed of library IP cores: the main processor (actually a hard-core in case of PowerPC), peripherals (UART, Ethernet), clock modules, memory drivers and various bridges, and possibly also user developed HDL IP cores. XPS provides a way to instantiate each core once or more times in one system, to interconnect the cores either by defined interfaces (buses), or by generic named signals. Global clock is defined, which will imply timing constraints. Also a pin map is defined for signals, which should be pinned out of the FPGA package. For standard buses, XPS can also allocate memory resources and divide them between selected peripherals to avoid bus collision.

All the mentioned hardware description is stored in a single file, system.mhs. From this file, XPS can create netlists and then invoke several ISE tools, to compile whole hardware into an output bitstream.

XPS initial work flow to get HW running with Linux or a system-less software:

* Get an initial design either by copying a directory tree from a working one, or start it by XPS Base System Builder (GUI wizard).

== Configuration of open-source software for Xilinx Virtex-4 ==

=== Toolchain binaries for Debian ===

Invoke next line to add rtime cross-dev into packages sources list

echo deb ftp://rtime.felk.cvut.cz/debian unstable main >/etc/apt/sources.list.d/rtime-debs.list

Update packages cache (aptitude update)
Check, that libmpfr1ldbl and libgmp3c2 packages are installed and select next packages

binutils-powerpc-elf
binutils-powerpc-linux-gnu
gcc-powerpc-elf
gcc-powerpc-linux-gnu
glibc-powerpc-linux-gnu

=== Toolchain preparation and kernel build information ===

Debian PowerPC GCC build log

[http://buildd.debian.org/build.php?arch=&pkg=gcc-4.3 Debian GCC-4.3 build logs]

==== Kernel headers install ====

[http://xilinx.wikidot.com/u-boot http://xilinx.wikidot.com/u-boot]

mkdir src
cd src
git clone git://git.xilinx.com/u-boot-xlnx.git
git clone git://git.xilinx.com/gen-mhs-devtree.git
git clone --reference /usr/src/linux-devel git://git.xilinx.com/linux-2.6-xlnx.git

mkdir -p build/ml403/linux
cd build/ml403/linux

Copy and adapt GNUmakefile to override ARCH and select kernel source directory

Run

make headers_install

The header-files for building GCC nd GLIB are prepared in usr/include directory.
Copy files found there to the directory /usr/powerpc-linux-gnu/sys-include

==== Glibc ====

The required files are glibc-2.7ds1.tar.bz2 glibc-linuxthreads-20071023.tar.bz2 glibc-libidn-2.7.tar.bz2 glibc-ports-2.7.tar.bz2

mkdir -p src
cd src
tar -xjf ../glibc-2.7ds1.tar.bz2
tar -xjf ../glibc-linuxthreads-20071023.tar.bz2
tar -xjf ../glibc-libidn-2.7.tar.bz2
( cd glibc-2.7 ; mv glibc-libidn-2.7 libidn )
tar -xjf ../glibc-ports-2.7.tar.bz2
( cd glibc-2.7 ; mv glibc-ports-2.7 ports )
ln -s glibc-2.7 glibc

Prepare directory to build PowerPC version of GLIBC

mkdir -p build/powerpc-linux/glibc

If there is no previous install of GLIBC, use next dummy build to install headers.
They are required to build GCC later

libc_cv_ppc_machine=yes \
libc_cv_mabi_ibmlongdouble=yes \
libc_cv_mlong_double_128=yes \
libc_cv_forced_unwind=yes \
libc_cv_c_cleanup=yes \
CC=gcc \
../../../src/glibc/configure --prefix=/usr \
--build=x86_64-linux-gnu \
--host=powerpc-linux-gnu \
--prefix=/usr \
--without-cvs \
--enable-add-ons=libidn,nptl \
--enable-profile \
--without-selinux \
--with-headers=/usr/powerpc-linux-gnu/sys-include \
--enable-kernel=2.6.26 \
--enable-hacker-mode \
--without-cvs --disable-sanity-checks

make DESTDIR=/usr-pkg/glibc-linux-powerpc-2.7-1 \
inst_includedir=/usr-pkg/glibc-linux-powerpc-2.7-1/include \
install-headers

==== Build binutils ====

../../../binutils/configure \
--prefix=/usr \
--disable-nls \
--build=x86_64-linux-gnu \
--host=x86_64-linux-gnu \
--target=powerpc-linux-gnu \
--enable-targets=powerpc64-linux-gnu

make && make DESTDIR=/usr-pkg/binutils-powerpc-linux-gnu_2.18-2_amd64 install

==== Build GCC ====

../../../gcc-4.3/configure -v \
--enable-languages=c,c++ \
--prefix=/usr \
--enable-shared \
--with-system-zlib \
--without-included-gettext \
--enable-threads=posix \
--disable-nls \
--enable-clocale=gnu \
--enable-libstdcxx-debug \
--enable-objc-gc \
--enable-mpfr \
--enable-softfloat \
--enable-tls \
--enable-secureplt \
--enable-targets=powerpc-linux,powerpc64-linux \
--with-cpu=default32 \
--with-long-double-128 \
--enable-checking=release \
--build=x86_64-linux-gnu \
--host=x86_64-linux-gnu \
--target=powerpc-linux-gnu \
--enable-version-specific-runtime-libs \
--disable-libgomp \
--disable-libmudflap

==== Finally build GLIBC ====

../../../src/glibc/configure \
--build=x86_64-linux-gnu \
--host=powerpc-linux-gnu \
--prefix=/usr \
--without-cvs \
--enable-add-ons=libidn,nptl \
--enable-profile \
--without-selinux \
--with-headers=/usr/powerpc-linux-gnu/sys-include \
--enable-kernel=2.6.20

make

make install_root=/usr-pkg/glibc-2.7-powerpc install

=== U-Boot ===

make ml405_config
make

ML403

2009-01-06T19:06:37Z

Pecam1:

== FPGA HW&SW development environment ==

=== Software ===

* Xilinx tools
** ISE 9.2i -- package for FPGA HW design; compiles input (HDL, netlist, schematics) and optimizes output bitstream according to given user constraints (mainly timing and pin assignment). In our work, ISE programs are almost exclusively invoked by EDK tools.
** EDK 9.2i -- package for FPGA HW&SW embedded system development; contains libraries of embedded computer IP cores and serves to glue HW FPGA cores together with software.
** Chipscope 9.1i (optional) -- logic analyzer inside of FPGA. Dedicated IP core sends measured waveforms by JTAG to Chipscope analyzer, running on PC with GUI.
* open-source software
** libusb-driver -- much better replacement/emulator of driver for Xilinx USB-JTAG adapter
** gcc 4.3.2, binutils, glibc -- development of system-less as well as Linux SW for PowerPC, contained in Xilinx Virtex-4 hybrid FPGA
** Linux 2.6.27-rc4 PowerPC kernel containing Xilinx Virtex support

=== Hardrware ===

* Xilinx Virtex-4 XC4VFX12 hybrid FPGA IC on ML405 evaluation board

== ML403 Xilinx Virtex-4 board ==

=== Toolchain binaries for Debian ===

Invoke next line to add rtime cross-dev into packages sources list

echo deb ftp://rtime.felk.cvut.cz/debian unstable main >/etc/apt/sources.list.d/rtime-debs.list

Update packages cache (aptitude update)
Check, that libmpfr1ldbl and libgmp3c2 packages are installed and select next packages

binutils-powerpc-elf
binutils-powerpc-linux-gnu
gcc-powerpc-elf
gcc-powerpc-linux-gnu
glibc-powerpc-linux-gnu

=== Toolchain preparation and kernel build information ===

Debian PowerPC GCC build log

[http://buildd.debian.org/build.php?arch=&pkg=gcc-4.3 Debian GCC-4.3 build logs]

==== Kernel headers install ====

[http://xilinx.wikidot.com/u-boot http://xilinx.wikidot.com/u-boot]

mkdir src
cd src
git clone git://git.xilinx.com/u-boot-xlnx.git
git clone git://git.xilinx.com/gen-mhs-devtree.git
git clone --reference /usr/src/linux-devel git://git.xilinx.com/linux-2.6-xlnx.git

mkdir -p build/ml403/linux
cd build/ml403/linux

Copy and adapt GNUmakefile to override ARCH and select kernel source directory

Run

make headers_install

The header-files for building GCC nd GLIB are prepared in usr/include directory.
Copy files found there to the directory /usr/powerpc-linux-gnu/sys-include

==== Glibc ====

The required files are glibc-2.7ds1.tar.bz2 glibc-linuxthreads-20071023.tar.bz2 glibc-libidn-2.7.tar.bz2 glibc-ports-2.7.tar.bz2

mkdir -p src
cd src
tar -xjf ../glibc-2.7ds1.tar.bz2
tar -xjf ../glibc-linuxthreads-20071023.tar.bz2
tar -xjf ../glibc-libidn-2.7.tar.bz2
( cd glibc-2.7 ; mv glibc-libidn-2.7 libidn )
tar -xjf ../glibc-ports-2.7.tar.bz2
( cd glibc-2.7 ; mv glibc-ports-2.7 ports )
ln -s glibc-2.7 glibc

Prepare directory to build PowerPC version of GLIBC

mkdir -p build/powerpc-linux/glibc

If there is no previous install of GLIBC, use next dummy build to install headers.
They are required to build GCC later

libc_cv_ppc_machine=yes \
libc_cv_mabi_ibmlongdouble=yes \
libc_cv_mlong_double_128=yes \
libc_cv_forced_unwind=yes \
libc_cv_c_cleanup=yes \
CC=gcc \
../../../src/glibc/configure --prefix=/usr \
--build=x86_64-linux-gnu \
--host=powerpc-linux-gnu \
--prefix=/usr \
--without-cvs \
--enable-add-ons=libidn,nptl \
--enable-profile \
--without-selinux \
--with-headers=/usr/powerpc-linux-gnu/sys-include \
--enable-kernel=2.6.26 \
--enable-hacker-mode \
--without-cvs --disable-sanity-checks

make DESTDIR=/usr-pkg/glibc-linux-powerpc-2.7-1 \
inst_includedir=/usr-pkg/glibc-linux-powerpc-2.7-1/include \
install-headers

==== Build binutils ====

../../../binutils/configure \
--prefix=/usr \
--disable-nls \
--build=x86_64-linux-gnu \
--host=x86_64-linux-gnu \
--target=powerpc-linux-gnu \
--enable-targets=powerpc64-linux-gnu

make && make DESTDIR=/usr-pkg/binutils-powerpc-linux-gnu_2.18-2_amd64 install

==== Build GCC ====

../../../gcc-4.3/configure -v \
--enable-languages=c,c++ \
--prefix=/usr \
--enable-shared \
--with-system-zlib \
--without-included-gettext \
--enable-threads=posix \
--disable-nls \
--enable-clocale=gnu \
--enable-libstdcxx-debug \
--enable-objc-gc \
--enable-mpfr \
--enable-softfloat \
--enable-tls \
--enable-secureplt \
--enable-targets=powerpc-linux,powerpc64-linux \
--with-cpu=default32 \
--with-long-double-128 \
--enable-checking=release \
--build=x86_64-linux-gnu \
--host=x86_64-linux-gnu \
--target=powerpc-linux-gnu \
--enable-version-specific-runtime-libs \
--disable-libgomp \
--disable-libmudflap

==== Finally build GLIBC ====

../../../src/glibc/configure \
--build=x86_64-linux-gnu \
--host=powerpc-linux-gnu \
--prefix=/usr \
--without-cvs \
--enable-add-ons=libidn,nptl \
--enable-profile \
--without-selinux \
--with-headers=/usr/powerpc-linux-gnu/sys-include \
--enable-kernel=2.6.20

make

make install_root=/usr-pkg/glibc-2.7-powerpc install

=== U-Boot ===

make ml405_config
make

Main Page

2009-01-06T16:41:32Z

Pecam1: /* Hardware */

'''For Czech students:''' Tato wiki by měla sloužit ke sdílení informací při vývoji různého HW na [http://dce.felk.cvut.cz/ katedře řídící techniky] FEL ČVUT. Důvod vzniku této wiki je ten, že se asto vyskytuje případ, kdy několik studentu pracuje na stejném a nebo podobném hardwaru a jeden lověk dělá práci, která by se mohla hodit i ostatním. Pokud se to ujme, mohla by tato Wiki sloužit jako místo, kde by se publikovaly výsledky práce jednotlivých lidí tak, aby tato práce mohla být užitená i pro ostatní. Mohly by se zde vyskytovat různé návody, odkazy na aktuální verze softwaru apod.

Konkrétní obsah závisí jen na vás. Pokud pracujete s nějakým hardwarem, [http://rtime.felk.cvut.cz/~sojka/ kontaktujte mě] a já vám zde zřídím úet. Anonymní editace je zakázaná kvůli spamerům.

--[[Wikipedista:Sojka|Sojka]] 20:29, 5. 5. 2005 (CEST)

== Hardware ==

* [[Boa5200]]
* [[ColdFire_DEMO52233 | ColdFire DEMO52233 (Board from Freescale)]]
* [[MIDAM MPC5200 DB1]] (Mikroklima)
* [[H8S/2638]]
* [[HC12 | Motorola HC12]]
* [[LPC21xx]]
* [[PiMX1]] i.MX1 processor based board
* [[Wireless_Sensor_Networks | Wireless Sensor Networks (WSNs)]]
* [[ML403 | ML403 Xilinx Virtex-4]]

== Software ==

* [[System-Less Framework]]
* [http://rtime.felk.cvut.cz/omk/ OMK - Advanced Make-System]

== Source Code Version Control ==

* [[Git]], [[Git repository on this server]]
* [[Darcs]]

== HW recomendation ==

=== Hardware shops ===
* [http://www.gme.cz GM electronic]
* [http://www.pselectronic.cz/ PS electronic]
* [http://www.ges.cz/ GES electronic]
* [http://www.tme.cz/ TME electronic eshop]

=== Board developers ===
* [http://www.volny.cz/psk/ PSK] Advanced board developer; Czech only
* [http://www.volny.cz/plspoj/ Mr. Kohout] Not advanced board developer with short delivery date; Czech only
* [http://www.pragoboard.cz/czech/index_cz.htm PragoBoard s.r.o.] Advanced board developer; communication is not easy; English allowed
* [http://www.seapraha.cz/index.php SEA Praha] Unknown board developer

== Wiki documentation ==

Please see [http://meta.wikipedia.org/wiki/MediaWiki_i18n documentation on customizing the interface]
and the [http://meta.wikipedia.org/wiki/MediaWiki_User's_Guide User's Guide] for usage and configuration help.