power_module.html
6.6 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
<!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 Power On/Off Sequence</h2>
November 2002<br>
<br>
<br>
This document describes the processing flow for handling power on and off.
Power is controlled by a combination of the power push button and software
controlled logic. When the power push button is first pressed in, power
is controlled by the push button. To put the player in a state where
power is on independent of the power button, the power control bit in the
PI_GPIO register must be set to 1. Until this bit is set, power is controlled
by the push button. If the power button is released before the bit
is set, then power to the player will be turned off. The circuit is
described in <a
href="../hw/design_notes/power_reset/bb%20system%20pwr%20up-dwn%20ckt%20no%20ff.doc">
bb system pwr up-dwn ckt no ff.doc</a><br>
<br>
The power bit in the GPIO register is set to 0 to turn off power. The
end user requests power to be turned off by pressing the power push button
in. Pressing the button will trigger two events, first the INT2 interrupt
will be asserted at the CPU and second 1/2 second later NMI/secure kernel
transfer will be asserted at the CPU. However, the secure kernel event
is not enabled unless the MI_SEC_MODE_BUT_TRAP_EN bit is enabled in the MI_SEC_MODE
register and the INT2 interrupt is not enabled unless the MI_INTR_BUT interrupt
is enabled in the MI_INTR_EMASK register . The current instantaneous
state of the push button is available in the MI_INTR_BUT bit in the MI_EINTR
register. The MI_SEC_MODE register includes a bit indicating whether
the secure kernel trap is due to a power off request.<br>
<br>
This leads to a power on/off sequence as follows:<br>
<br>
Assumptions:<br>
<ul>
<li>boot rom code does not handle any power on or off processing</li>
<li>we can be up and running in the secure kernel in <= 200ms so that
the user isn't holding in the push button for an unusually long time period.<br>
</li>
<li>whatever code handles power on, must be able to do power off as well
so we don't get stuck in a power on state</li>
<li>button debouncing handled is software</li>
<li>no need for user confirmation of power off </li>
</ul>
Sequence:<br>
<ol>
<li>Power button is pushed, CPU boot rom code starts, control transfers
to secure kernel</li>
<li>Secure kernel sets the power bit in the GPIO register, and waits for
the button to be released. Release is detected by polling the MI_INTR_BUT
bit. Release is complete when the button is detected in the released
state for a continuous polling loop of 100ms.</li>
<li>After the release sequence the secure kernel enables the power off
signaling mechanism using INT2 and the secure trap signaling mechanism. An
interrupt vector must be registered for INT2.</li>
<li>The secure kernel handler must determine whether the trap occured while
another application was running. If an application is running, then
control is transferred to more general secure kernel code which then loads
the browser application to complete the rest of the power off processing.
If another application is not running, or the browser application should
have been running, then the secure kernel will see the INT2 interrupt rather
than the secure kernel trap and the GPIO power bit is turned off immediately.
This handles the case of no module being present or the browser application
failing. </li>
<li>If another application is running, then the secure kernel's INT2 interrupt
vector should not be invoked. Instead the application-specific INT2 vector
will be invoked and be used by the application to shutdown audio and video
processing. The secure kernel will be entered using the 1/2second delayed
NMI and the secure kernel will detect the button request in the MI_SEC_MODE
register. The secure kernel will delegate the power off processing
to the browser application so that the secure kernel needn't deal with the
complexities of application state saving. If the browser can not be
successfully started, power is turned off by the secure kernel.</li>
</ol>
Observations:<br>
<br>
<ul>
<li>If no module is present at power on, the ERROR LED will remain on
while there is power and power will immediately be turned off when the power
button is released. The power LED will reflect the current state of
the push button.</li>
<li>Once power has been turned on in software it can always be turned
off in software since there should be enough secure kernel code to present
to handle it, and an application can not block the power off NMI. The
power LED will reflect the state of the power GPIO bit.<br>
</li>
</ul>
<br>
<h2>Module Detect/Removal Sequence</h2>
This document describes the sequence for detecting memory module insertion
and removal. There are two status bits in the PI_ERROR register that
reflect the state of the module. The MD_CUR bit reflects the instantaneous
presence of the module and the MD_CHG bit indicates whether there has been
a transistion in the module presence (either removal or insertion) since the
last time the CHG bit was cleared. The CHG bit will also raise a PI
error interrupt. The interrupt can be masked with the MI_EINTR_MASK
register. <br>
<br>
Since there is no hardware-debouncing of the module presence signals, software
determining the status of the module must use some caution in using the status
bits to determine whether a module is present or to determine when a module
state change has completed (i.e., module is completely inserted). To
detect whether a module is present, software can test the MD_CHG bit to determine
if there has been any status change. If none, then sample the MD_CUR
bit to determine if the module is present. Ideally, the MD_CHG bit should
be monitored over some small time window to ensure that the module is not
in the process of being inserted or removed. One way to do this would
be to simply set a timer and wait for some time period, e.g., 100msec. Another
would be to record time stamps when the MD_CHG bit changes. To wait
for the module to be inserted or removed, the software should also establish
a time window of ~100 msec and ensure that both that the MD_CHG bit has not
been set and that at the end of this window the MD_CUR bit has the
desired value. <br>
</body>
</html>