swnotes.html
5.67 KB
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
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>/tmp/n46software.html</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
</head>
<body>
<h2>BB Player Software Notes</h2>
September 2002<br>
<br>
<br>
This document assumes that you have read the <a
href="../n64software.html"> N64 Software Notes</a> document <br>
<br>
The software "tree" for the bbplayer is largely a clone of the n64os20l N64
development software directory. The goal is to put the BB Player specific
changes and additions in the new tree and leave the existing n64os20l tree
in a buildable state for testing agains the existing N64 development systems.
The n64os20l directory should be readonly for the most part (maybe
the odd bug fix or portability fix for code that hasn't been tried yet).<br>
<br>
The player software is in the <tt>bbplayer</tt> directory (peer to n64os20l)
and builds in much the same way (install the devroot, do make headers; make
exports; etc). Both n64os20j and bbplayer use $ROOT as the place to
install compiled tools, libraries, etc. If you use a different setting
for $ROOT when building bbplayer and n64os20l, then they will not interfere
with one one another.<br>
<br>
The bbplayer directory contains a few additions such as the <tt>simos</tt>
directory for the R4300/BCP simulation and the <tt>bbapps</tt> directory
for the browser/first-app,etc. Most of the N64 software doesn't need
to be modified if we continue to use the same file names, etc. The
boot rom and secure kernel code are located in the lib subdirectory. New
functionality available to the browser/first app and games are integrated
into the libultra subdirectories as appropriate (e.g., serial controller
support, game state read/write, file system operations, etc.). <br>
<h3>SimOS (aka SimBB)</h3>
SimOS is a MIPS instruction set simulator. We are integrating extra
support to emulate some of the BCP functionality (e.g., MI and PI interfaces)
to assist in the development of software. The rcp/bcp support is in
the <tt>simos/cpus/simbb</tt> subdirectory. SimOS requires the <tt>
SIMOS_DIR</tt> to be set to the full path to the simos directory and when
running requires an initialization file with the name <tt>init.simos</tt>
to set various parameters and path names. An application can be started
in one of several different ways:<br>
<br>
<ul>
<li>run an elf binary from RAM (at address 0x80000000) using the 'b' command
(e.g., b hello)</li>
<li>run an elf binary from ROM (at address 0xbfc00000) using the 'r' command,
(e.g. r romfile)<br>
</li>
<li> run an elf binary from ROM (at address 0xbfc00000) by setting
the name of the ROM file in the init.simos file and then using the 'r' command
to simulate a reset</li>
<li> run a cartridge rom binary at the RAM address specified in the
rom file using the 'c' command (e.g., c romfile)</li>
</ul>
The path to the init.simos file can also be set with the environment variable
SIMOS_INIT.<br>
<br>
There is an example test program in the subdirectory <tt>simos/TEST</tt>which
can be run from RAM using the 'b' command.<br>
<br>
Currently the simulator prints some debugging information regarding accesses
to RCP/BCP address space. This is likely to change in the future (see
below). There is a version of gdb that can be used with simos in the
devroot directory. To use the debugger you must attach it to the simos
target debug port (a socket being listened on by simos) using the debugger
command:<br>
<br>
<tt>target simos localhost:2345</tt><br>
<br>
Simos should be sitting in the command prompt when you type this command
from gdb. The debugger will then block until you start running a program
(using any of the three methods). Once you have started the program
it will interrupt the debugger and give you an opportunity to set breakpoints,
etc or continue the program. You can interrupt a running program by
typing ^C at the debugger, but it may take a few seconds before the simulator
sees the interrupt. At this point you can dump cpu registers, single
step, etc.<br>
<br>
To help with debugging, the environment variable SIMOS_TRACEPC, when set,
causes a hex dump of fetched instructions to be written to stdout.<br>
<h3>BCP Functionality</h3>
The emulation of BCP functionality uses a few environment variables:<br>
<br>
SIMOS_FLASH - pathname to a file containing the external flash data. This
file is used to initialize an in-memory copy of the flash memory (flash writes
do not get committed to the file). The format for the file is the same
as that for the verilog rtl simulator (ascii hex file as space separated
bytes of data).<br>
<br>
SIMOS_VIRAGE{0,1,2} - 3 environment variables containing pathnames to a files
containing the virage{0,1,2} data. These are similar to SIMOS_FLASH
except that they load the in memory virage image, and the format uses ascii
hex data grouped as 32-bit words rather than 8-bit bytes, just like the verilog
rtl. <br>
<br>
SIMOS_BCPDEBUG - a string that provides control over debug messages for each
unit {AI,MI,PI,RI,SI,SP,VI}. Including any of these abbreviations in
the string turns of debugging for that unit, e.g.,<br>
<tt>setenv SIMOS_BCPDEBUG "PI MI"</tt><br>
enables MI and PI debugging messages<br>
<br>
The simulator exits when the GPIO power signal is turned off or the IDE backdoor
exit address is written to. These mechanisms are compatible with the
RTL simulator.<br>
<br>
The same backdoor print mechanism used in the RTL simulator is also available.<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>