summaryrefslogtreecommitdiffstats
path: root/c/src/lib/libbsp/powerpc/motorola_powerpc/README.qemu
blob: 9ccf3779a968e5c691f9f4bd35812c4bb91636e8 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
The 'qemuprep'/'qemuprep-altivec' BSPs are variants of
'motorola_powerpc' that can run under QEMU. They are *not*
binary compatible with other variants of 'motorola_powerpc'
(nor with each other).

Most significant differences to real hardware:
 - no OpenPIC, just a 8259 PIC (even though qemu implements an openpic
   at least to some extent it is not configured into the prep platform
   as of qemu-0.14.1).
 - no VME (absense of the VME controller is detected by the BSP)
 - the only network chip supported by both, qemu and vanilla RTEMS
   is the ISA NE2000 controller. Note that the default interrupt line
   settings used by RTEMS and QEMU differ: RTEMS uses 5 and QEMU 9.
   This can be addressed by passing a RTEMS commandline option
   --ne2k-irq=9.
   Other controllers (i8559, e1000, pcnet) implemented by qemu can
   also be used but require unbundled RTEMS drivers (libbsdport).
   Note that the bundled 'if_fxp' has not been ported to PPC and works
   on x86 only.
 - unlike a real motorola board you can run qemu emulating a 7400 CPU
   which features altivec. I.e., you can use this BSP (altivec-enabled
   variant) to test altivec-enabled code.

Compatibility: qemu had quite a few bugs related to the PREP platform.
Version 0.12.4, for example, required patches. 0.14.1 seems to have
fixed the show-stoppers. Hence, you *need* at least qemu-0.14.1 for
this BSP; it should work without the need for patching QEMU.

BIOS: qemu requires you to use a BIOS. The one that came with qemu
0.12.4 didn't work for me so I created a minimal dummy that provides
enough functionality for the RTEMS bootloader to work.

BSP Variants:
You can compile the BSP for either a 604 CPU or a 7400 (altivec-enabled).
Note that you cannot run the altivec-enabled BSP variant on a CPU w/o
altivec/SIMD hardware. The non-altivec variant is called 'qemuprep'
and the altivec-enabled one 'qemuprep-altivec'. Hence, you can
configure RTEMS:

604/non-altivec variant only:
  configure --target=powerpc-rtems --enable-rtemsbsp=qemuprep
7400/altivec variant only:
  configure --target=powerpc-rtems --enable-rtemsbsp=qemuprep-altivec
both variants:
  configure --target=powerpc-rtems --enable-rtemsbsp='qemuprep qemuprep-altivec'

Building QEMU:
In case you have no pre-built qemu-0.14.1 you can
compile it yourself:

cd qemu-0.14.1
configure --target-list=ppc-softmmu
make

Running QEMU:
A number of command-line options are important (BTW: make sure
you run the PPC/PREP emulator and not a natively installed i386/PC
emulating 'qemu')

-M prep         --- select machine type: prep
-cpu 604        --- select 604 CPU for non-altivec variant
-cpu 7400       --- select 7400 CPU for altivec variant

              NOTE: the 7455 and 7457 emulations are buggy as of
              qemu-0.14.1 and they won't work.

-bios <rtems-install-prefix>/powerpc-rtems/qemuprep/qemu_fakerom.bin
-bios <rtems-install-prefix>/powerpc-rtems/qemuprep-altivec/qemu_fakerom.bin
                --- select proprietary dummy 'BIOS'

-nographic      --- redirect serial/IO to console where qemu is run

-kernel <path>  --- path to your RTEMS executable (.ralf file, e.g., 'hello.ralf')
-no-reboot      --- terminate after one run
-append <arg>   --- RTEMS kernel comand line (use e.g., to modify
                    ne2000 driver interrupt line)

Networking:
(We assume your RTEMS application is correctly configured and
built for networking using the ne2k adapter [other adapters 
can be used with unbundled/libbsdport drivers])

I use networking with a 'tap' interface on the host machine
and can then communicate with the emulated target in any
desired way.  The Ethernet address specified in the RTEMS network interface
configuration and the Qemu command line must match, otherwise uni-cast frames
are not received.  It is best to use a NULL pointer in the RTEMS network
interface configuration for the Ethernet address, so that the default from Qemu
is used.  Make sure that your firewall settings allow communication between
different Qemu instances and your host.

On (linux) host:

# create a 'permanent' tap device that can be used by myself
# (as non-root user).
sudo tunctl -u `id -u`
# configure tap0 interface
sudo ifconfig tap0 10.1.1.1 netmask 255.255.255.0 up
# provide a suitable dhcpd config file (for the emulated
# platform to boot: IP address etc.
#
# execute dhcp on host
sudo dhcpd -d tap0

Start emulated prep platform:

ppc-softmmu/qemu-system-ppc                               \
    -M prep                                               \
    -cpu 7400                                             \
    -bios  <rtems-prefix>/powerpc-rtems/qemuprep-altivec/lib/qemu_fakerom.bin \
    -kernel <my_path>/my_app.ralf                         \
	-append --ne2k-irq=9                                  \
    -nographic                                            \
    -no-reboot                                            \
    -net nic,model=ne2k_isa                               \
    -net tap,vlan=0,ifname=tap0,script=no,downscript=no 

Again: if you use the non-altivec BSP variant, use -cpu 604
and if you use the altivec-enabled variant then you MUST use
-cpu 7400.

Have fun.

Till Straumann, 2011/07/18