bb_dev_kit.html
11.2 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
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
<!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 align="center">BB Developer Kit for iQue<br>
</h2>
<div align="center">$Revision: 1.11 $<br>
$Date: 2003/12/20 00:51:22 $<br>
</div>
<br>
<h3>Purpose</h3>
Release a developer's kit that can be used initially by iQue
to develop applications from scratch for the BB player.<br>
<h3>Assumptions</h3>
<ul>
<li>Developers will use a RedHat Linux system as the platform
on which to develop BB apps.</li>
<li>Developers will not be able to publish games directly at
iQue. That will require using the infrastructure at BroadOn.</li>
<li>Developers will use players running a real Secure Kernel,
but with a special version of the viewer app that will launch the game
executables that they generate using the devkit.</li>
<li>Debugging will be done by downloading over USB and using
<i>osSyncPrintf</i>.</li>
<li>We don't want to expose the file system API to general apps
written using the DevKit, but the iQue Club App already requires this.</li>
<li>The BB devkit will be a complete replacement for the N64 devkit,
meaning that it will not be necessary for developers to install the original
N64 devkit.<br>
</li>
</ul>
<h3>Libultra features</h3>
The devkit will include both the _FINALROM (<b>libultra_rom.a</b>)
and debugging versions (<b>libultra_d.a</b>) of the complete <b>libultra</b>,
including the BB specific primitives. The access to the file system
and card access calls will be restricted by using h/w rights when the final
apps are published. Only the iQue Club App will be allowed to access
the file system. This method makes it unnecessary to have a separate
version of the devkit to support the Club App. None of the BB specific
APIs will be documented in the SDK material.<br>
<h3>Build environment</h3>
The devkit will include the following items:<br>
<ul>
<li>cross compiler</li>
<li>libultra</li>
<li>headers</li>
<li>tools<br>
</li>
<ul>
<li>aesrom to encrypt games</li>
<li>rommd to add metadata to rom files<br>
</li>
<li>devsh to talk to devmon</li>
</ul>
<li>source for bbrdb linux driver<br>
</li>
<li>online documentation, including that from the Nintendo N64
devkit</li>
<li>sample source code from the Nintendo devkit, as modified to
work for our environment (makefile changes)<br>
</li>
</ul>
In order to install the devkit environment, the user does the following:<br>
<ul>
<li>mount the SDK CD:</li>
<ul>
<li>su<br>
</li>
</ul>
<ul>
<li>mkdir /mnt/cdrom (may not be necessary)</li>
<li>mount /dev/cdrom /mnt/cdrom (may also be unnecessary)</li>
</ul>
<li>become root to install the parts shared by all users:</li>
<ul>
<li>su</li>
<li>./install.sh</li>
</ul>
<li>each user on the system must install the non-shared portions of
the devkit relative to their home directory, based on the setting of $ROOT:</li>
<ul>
<li>login as user</li>
<li>mkdir ique_root (pathname is only an example)</li>
<li>setenv ROOT $HOME/ique_root</li>
<li>ROOT=$HOME/ique_root; export ROOT</li>
<li>/opt/ique/sdk-v1.0/devkit/install.sh</li>
</ul>
</ul>
To build an executable, the user adds an invocation of <i>aesrom</i>
to makefile to encrypt the rom file:
<ul>
<li>aesrom rom game.aes</li>
</ul>
If the game uses saved state, then it may necessary to include an invocation
of <i>rommd</i> to specify the type of state saving used. Once the
game file has been encrypted, use <i>devmon</i> and <i>devsh</i> to copy
the new game to the cartridge:<br>
<ul>
<li>Connect iQue player to linux host with USB cable</li>
<li>Bring up <i>devmon</i> on the player</li>
<li>On the linux host, start "<i>mux</i>" on a separate terminal window</li>
<li>Then invoke "<i>devsh</i>" in the directory containing the game
rom file. Using the following <i>devsh</i> commands:</li>
<ul>
<li>d game.aes</li>
<li>a game.aes</li>
</ul>
</ul>
The game should appear on the list of available files shown by <i>devmon.</i>
The game can be invoked by selecting the appropriate entry, using the
D pad on the player, and then pushing the A button to launch the game.<br>
<h3>Execution environment</h3>
The method for allowing a player to execute a locally built game
without requiring the services of the normal software signing infrastructure
is the most problematic part of the developer's kit. It is not
practical to require that a developer feed the built executable through
the BroadOn infrastructure in order to obtain a real ticket and encrypted
.app file every time they run <i>make</i>. It's too risky to release
a signing key to anyone outside BroadOn HQ. The development players
will be normal players, running the real Secure Kernel. The proposal
is to create a special version of the viewer/sysapp that includes enough
of <i>usbmon</i> and <i>launch.aes</i> to allow rom files to be downloaded
onto the cartridge and executed. This viewer is the piece that
must be tightly controlled. This will be done by using a feature
of the Secure Kernel: there is a field in the content metadata
header included in the ticket block of an SKSA bundle that is a BBID. For
a normal SKSA bundle, that field is set to zero, which means that the
Viewer can be launched by the SK on any BB. If the BBID field is
non-zero, then the SK will only launch that Viewer bundle on the BB with
the matching ID. The process for producing an SKSA bundle that is locked
to a particular player requires a special version of the Content Publisher
script for publishing an SKSA bundle.<br>
<br>
The Content Publisher used for creating devkit bundles will use a different
signer certificate than that used for signing normal apps and viewers.
This gives us the capability to revoke the certificate later without
affecting anything other than the development players.<br>
<br>
The player is only capable of executing AES encrypted games, so
we need a method for encrypting the game and loading the AES engine with
the appropriate key to get the game launched. There are two ways
to do this:<br>
<ul>
<li>Use the same key to encrypt the game as was used to encrypt the
viewer. This is the mechanism used by the current launcher. In
this method, the AES engine is loaded once by the SK when the viewer app
is launched and the key never changes.</li>
<li>Create keys at build time in the devkit software. This
could be a fixed key or even a custom key for each app, although
dynamic schemes will be more complicated to implement (the key is generated
on the host, but needs to be accessible to the viewer at runtime on the
player side). In this case the viewer will need h/w rights to load
the AES engine with the key at launch time. </li>
</ul>
The encryption of the game will be done using a script like <i>aesrom</i>
with the appropriate key corresponding to the method selected above. The
first method is probably the best solution, but requires that the AES
key used originally to encrypt the viewer be extracted and then encoded
in the <i>aesrom</i> script at the time that the devkit package is created.<br>
<br>
The special viewer app provided with the devkit will not have the sophisticated
user interface of the real Viewer App: it will likely be a simple
menu based viewer derived from <i>launcher</i>. In order to allow
full testing of game features by developers and provide reliability, it
must implement game state saving and single bit error scrubbing as the real
Viewer does.<br>
<br>
No debugger is supported for first release. The debugging
method is to use <i>osSyncPrintf</i> to track the state of the program
under development.<br>
<ul>
</ul>
<h3>Documentation</h3>
The online documentation included with the devkit provides:<br>
<ul>
<li>The existing N64 DevKit docs from Nintendo.</li>
<li>An html doc explaining the build environment.</li>
<li>A separate one page doc explaining how to install the devkit.</li>
</ul>
<h3>Implementation</h3>
<ul>
<li>Fix bugs in <i>osSyncPrintf </i>that cause it to hang frequently
(<i>done</i>)</li>
<li>Create special viewer app based on launcher, called <i>devmon
(done)</i></li>
<li>Write new documents</li>
<ul>
<li>Build how-to <i>(done)</i></li>
<li>Install how-to <i>(done)</i></li>
</ul>
<li>Create special publishing script for DevKit SKSA bundles
locked to particular players (requires help from Infrastructure Team)</li>
<ul>
<li>Need to keep records of devkit bundles issued and BBIDs. Probably
does not need to be in the database.<br>
</li>
</ul>
<li>Build and installation scripts <i>(done)</i></li>
<li>Figure out the subset of headers to be shipped <i>(done)</i></li>
<ul>
<li>Probably does not include osBb API headers (most osBb headers
were not included)</li>
</ul>
<li>Do we allow users to create more devkit flash cards (allow T,t,S,s
commands)? <i>(No, this is not required.)</i></li>
</ul>
<h3>Status</h3>
<ul>
<li>First prototype of the SDK given to iQue on 12/04/03 (this version
is officially 1.0, since iQue has built production game roms using it).</li>
<li>Demo apps and sound files not included.</li>
</ul>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>