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
|
.. _skiboot-6.3-rc3:
skiboot-6.3-rc3
===============
skiboot v6.3-rc3 was released on Thursday May 2nd 2019. It is the third
release candidate of skiboot 6.3, which will become the new stable release
of skiboot following the 6.2 release, first released December 14th 2018.
Skiboot 6.3 will mark the basis for op-build v2.3. I expect to tag the final
skiboot 6.3 in the next week (I also predicted this last time, so take my
predictions with a large amount of sodium).
skiboot v6.3-rc3 contains all bug fixes as of :ref:`skiboot-6.0.19`,
and :ref:`skiboot-6.2.3` (the currently maintained
stable releases).
For how the skiboot stable releases work, see :ref:`stable-rules` for details.
Over :ref:`skiboot-6.3-rc2`, we have the following changes:
- Expose PNOR Flash partitions to host MTD driver via devicetree
This makes it possible for the host to directly address each
partition without requiring each application to directly parse
the FFS headers. This has been in use for some time already to
allow BOOTKERNFW partition updates from the host.
All partitions except BOOTKERNFW are marked readonly.
The BOOTKERNFW partition is currently exclusively used by the TalosII platform
- Write boot progress to LPC port 80h
This is an adaptation of what we currently do for op_display() on FSP
machines, inventing an encoding for what we can write into the single
byte at LPC port 80h.
Port 80h is often used on x86 systems to indicate boot progress/status
and dates back a decent amount of time. Since a byte isn't exactly very
expressive for everything that can go on (and wrong) during boot, it's
all about compromise.
Some systems (such as Zaius/Barreleye G2) have a physical dual 7 segment
display that display these codes. So far, this has only been driven by
hostboot (see hostboot commit 90ec2e65314c).
- Write boot progress to LPC ports 81 and 82
There's a thought to write more extensive boot progress codes to LPC
ports 81 and 82 to supplement/replace any reliance on port 80.
We want to still emit port 80 for platforms like Zaius and Barreleye
that have the physical display. Ports 81 and 82 can be monitored by a
BMC though.
- Copy and convert Romulus descriptors to Talos
Talos II has some hardware differences from Romulus, therefore
we cannot guarantee Talos II == Romulus in skiboot. Copy and
slightly modify the Romulus files for Talos II.
- npu2: Disable Probe-to-Invalid-Return-Modified-or-Owned snarfing by default
V100 GPUs are known to violate NVLink2 protocol in some cases (one is when
memory was accessed by the CPU and they by GPU using so called block
linear mapping) and issue double probes to NPU which can cope with this
problem only if CONFIG_ENABLE_SNARF_CPM ("disable/enable Probe.I.MO
snarfing a cp_m") is not set in the CQ_SM Misc Config register #0.
If the bit is set (which is the case today), NPU issues the machine
check stop.
The snarfing feature is designed to detect 2 probes in flight and combine
them into one.
This adds a new "opal-npu2-snarf-cpm" nvram variable which controls
CONFIG_ENABLE_SNARF_CPM for all NVLinks to prevent the machine check
stop from happening.
This disables snarfing by default as otherwise a broken GPU driver can
crash the entire box even when a GPU is passed through to a guest.
This provides a dial to allow regression tests (might be useful for
a bare metal). To enable snarfing, the user needs to run: ::
sudo nvram -p ibm,skiboot --update-config opal-npu2-snarf-cpm=enable
and reboot the host system.
- hw/npu2: Show name of opencapi error interrupts
- core/pci: Use PHB io-base-location by default for PHB slots
On witherspoon only the GPU slots and the three pluggable PCI slots
(SLOT0, 1, 2) have platform defined slot names. For builtin devices such
as the SATA controller or the PLX switch that fans out to the GPU slots
we have no location codes which some people consider an issue.
This patch address the problem by making the ibm,slot-location-code for
the root port device default to the ibm,io-base-location-code which is
typically the location code for the system itself.
e.g. ::
pciex@600c3c0100000/ibm,loc-code
"UOPWR.0000000-Node0-Proc0"
pciex@600c3c0100000/pci@0/ibm,loc-code
"UOPWR.0000000-Node0-Proc0"
pciex@600c3c0100000/pci@0/usb-xhci@0/ibm,loc-code
"UOPWR.0000000-Node0"
The PHB node, and the root complex nodes have a loc code of the
processor they are attached to, while the usb-xhci device under the
root port has a location code of the system itself.
- hw/phb4: Read ibm,loc-code from PBCQ node
On P9 the PBCQs are subdivided by stacks which implement the PCI Express
logic. When phb4 was forked from phb3 most of the properties that were
in the pbcq node moved into the stack node, but ibm,loc-code was not one
of them. This patch fixes the phb4 init sequence to read the base
location code from the PBCQ node (parent of the stack node) rather than
the stack node itself.
- hw/xscom: add missing P9P chip name
- asm/head: balance branches to avoid link stack predictor mispredicts
The Linux wrapper for OPAL call and return is arranged like this: ::
__opal_call:
mflr r0
std r0,PPC_STK_LROFF(r1)
LOAD_REG_ADDR(r11, opal_return)
mtlr r11
hrfid -> OPAL
opal_return:
ld r0,PPC_STK_LROFF(r1)
mtlr r0
blr
When skiboot returns to Linux, it branches to LR (i.e., opal_return)
with a blr. This unbalances the link stack predictor and will cause
mispredicts back up the return stack.
- external/mambo: also invoke readline for the non-autorun case
- asm/head.S: set POWER9 radix HID bit at entry
When running in virtual memory mode, the radix MMU hid bit should not
be changed, so set this in the initial boot SPR setup.
As a side effect, fast reboot also has HID0:RADIX bit set by the
shared spr init, so no need for an explicit call.
- opal-prd: Fix memory leak in is-fsp-system check
- opal-prd: Check malloc return value
- hw/phb4: Squash the IO bridge window
The PCI-PCI bridge spec says that bridges that implement an IO window
should hardcode the IO base and limit registers to zero.
Unfortunately, these registers only define the upper bits of the IO
window and the low bits are assumed to be 0 for the base and 1 for the
limit address. As a result, setting both to zero can be mis-interpreted
as a 4K IO window.
This patch fixes the problem the same way PHB3 does. It sets the IO base
and limit values to 0xf000 and 0x1000 respectively which most software
interprets as a disabled window.
lspci before patch: ::
0000:00:00.0 PCI bridge: IBM Device 04c1 (prog-if 00 [Normal decode])
I/O behind bridge: 00000000-00000fff
lspci after patch: ::
0000:00:00.0 PCI bridge: IBM Device 04c1 (prog-if 00 [Normal decode])
I/O behind bridge: None
- build: link with --orphan-handling=warn
The linker can warn when the linker script does not explicitly place
all sections. These orphan sections are placed according to
heuristics, which may not always be desirable. Enable this warning.
- build: -fno-asynchronous-unwind-tables
skiboot does not use unwind tables, this option saves about 100kB,
mostly from .text.
- hw/xscom: Enable sw xstop by default on p9
This was disabled at some point during bringup to make life easier for
the lab folks trying to debug NVLink issues. This hack really should
have never made it out into the wild though, so we now have the
following situation occuring in the field:
1) A bad happens
2) The host kernel recieves an unrecoverable HMI and calls into OPAL to
request a platform reboot.
3) OPAL rejects the reboot attempt and returns to the kernel with
OPAL_PARAMETER.
4) Kernel panics and attempts to kexec into a kdump kernel.
A side effect of the HMI seems to be CPUs becoming stuck which results
in the initialisation of the kdump kernel taking a extremely long time
(6+ hours). It's also been observed that after performing a dump the
kdump kernel then crashes itself because OPAL has ended up in a bad
state as a side effect of the HMI.
All up, it's not very good so re-enable the software checkstop by
default. If people still want to turn it off they can using the nvram
override.
- opal/hmi: Initialize the hmi event with old value of TFMR.
Do this before we fix TFAC errors. Otherwise the event at host console
shows no thread error reported in TFMR register.
Without this patch the console event show TFMR with no thread error:
(DEC parity error TFMR[59] injection) ::
[ 53.737572] Severe Hypervisor Maintenance interrupt [Recovered]
[ 53.737596] Error detail: Timer facility experienced an error
[ 53.737611] HMER: 0840000000000000
[ 53.737621] TFMR: 3212000870e04000
After this patch it shows old TFMR value on host console: ::
[ 2302.267271] Severe Hypervisor Maintenance interrupt [Recovered]
[ 2302.267305] Error detail: Timer facility experienced an error
[ 2302.267320] HMER: 0840000000000000
[ 2302.267330] TFMR: 3212000870e14010
|
