Age | Commit message (Collapse) | Author | Files | Lines |
|
Setup skiboot.tcl with Power11 config to be boot on Power11 mambo.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Update the external archictecture checker script and Makefile
for aarch64.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
In ffspart we assign this make variable:
FFSPART_VERSION ?= $(shell ./make_version.sh $(EXE))
However, ./make_version.sh is actually a make target, and whether it
exists or not at the time of this assignment is by chance, depending on
how the make concurrency works out.
In practice, this intermittently causes CI build failure:
make -j${MAKE_J} check
+ make -j4 check
...
[ RUN-TEST ] check-ffspart
...
make[1]: ./make_version.sh: No such file or directory
...
make[1]: *** [Makefile:13: check] Error 1
make[1]: Entering directory '/build/external/ffspart'
...
running test/tests/00-usage
running test/tests/01-param-sanity
Fatal error, cannot execute binary './ffspart'. Did you make?
make[1]: Leaving directory '/build/external/ffspart'
make: *** [/build/external/Makefile.check:21: check-ffspart] Error 2
make: *** Waiting for unfinished jobs....
The rule for make_version.sh is just a symlink:
make_version.sh:
$(Q_LN)ln -sf ../../make_version.sh
To avoid the race, call make_version.sh from its actual location instead
of relying on the link to be created. The same thing was done for gard
in commit 8ab0caf26de9 ("external/gard: Fix make dist target").
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Currently the path where to install the opal-prd binary is defined in
the Makefile by the $sbindir variable, but its service files hard-codes
the path to /usr/sbin/opal-prd. The build should generate the service
file based on the actual $sbindir value.
Also strip the trailing slash from the $prefix variable.
Signed-off-by: Dan Horák <dan@danny.cz>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
commit 0a6a2ff30c9e ("mambo: Add persistent memory disk support") allows
user to map disk images persistent memory using PMEM_DISK ENV variable.
However, If the size of the disk image file passed is not 2MB align,
then the Linux kernel fails to detect pmem device with misaligned error.
nd_pmem namespace0.0: [mem 0x20000000000-0x203fffe01ff flags 0x200]
misaligned, unable to map
nd_pmem namespace0.0: probe with driver nd_pmem failed with error -95
And then linux kernel fails to mount root fs from /dev/pmem0
md: ... autorun DONE.
/dev/root: Can't open blockdev
VFS: Cannot open root device "/dev/pmem0" or unknown-block(0,0):
error -6
[...]
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Fix this by adding remaining bytes as padding to make pmem device memory
map 2MB aligned.
Reported-by: Brad Thomasson <bthomas@us.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Add an ftrace command that steps instructions and prints the symbol
whenever it changes. This can be helpful for low level debugging.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
My user id didn't have access to disk.img and the code printed
the error message:
ERROR: pmem: 'mysim mmap' command needs newer mambo
mysim mmap has been in Mambo for a while so this patch prints out the
error message from catch. Now we get the useful:
ERROR: pmem: 'mysim mmap' Error opening file disk.img for mapping
Signed-off-by: Ryan Grimm <grimm@linux.ibm.com>
Reviewed-by: Dan Horák <dan@danny.cz>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
In the case of LE kernel and BE skiboot, the bt functions triggers an
illegal address when the kernel has a stack pointer in skiboot. For
example, in copy_and_flush:
pc: 0x000000000000C25C +0x000000000000C25C
lr: 0x000000000000C240 +0x000000000000C240
stack:0x0000000031C13D20 0x8428023000000000 +0x8428023000000000
Illegal Address 0x001EC13100000007
The bad address is from mem_display_64 and is fixed up by inverting
the LE bit:
systemsim % mem_display_64 [ expr 0x0000000031C13D20 ] 1
0x103EC13100000000
systemsim % mem_display_64 [ expr 0x0000000031C13D20 ] 0
0x0000000031C13E10
This patch tests the pointer by catching the illegal access and
inverting the LE bit. Now the stack trace looks good:
pc: 0x000000000000C254 +0x000000000000C254
lr: 0x000000000000C240 +0x000000000000C240
stack:0x0000000031C13D20 0x0000000030022884 .load_and_boot_kernel+0xc6c
stack:0x0000000031C13E10 0x0000000030023344 .main_cpu_entry+0x8bc
Opal calls also look good too now:
pc: 0x0000000030028588 .cpu_idle_delay+0xb8
lr: 0x000000003002856C .cpu_idle_delay+0x9c
stack:0x0000000031C13A10 0x0000000030028514 .cpu_idle_delay+0x44
stack:0x0000000031C13AB0 0x000000003002D6C0 .time_wait_nopoll+0x34
stack:0x0000000031C13B20 0x000000003002D77C .time_wait+0xa8
stack:0x0000000031C13BA0 0x000000003002821C .cpu_wait_job+0x3c
stack:0x0000000031C13C40 0x0000000030029554 .opal_reinit_cpus+0x3c0
stack:0x0000000031C13D10 0x00000000300038AC opal_entry+0x14c
stack:0x000000000071FDA0 0xC0000000000537B0 opal_call+0x40
stack:0x000000000071FE60 0xC00000000005450C opal_reinit_cpus+0x20
stack:0x000000000071FED0 0xC00000000065FDAC opal_configure_cores+0x48
stack:0x000000000071FF00 0xC000000000656554 early_setup+0x134
Signed-off-by: Ryan Grimm <grimm@linux.ibm.com>
Reviewed-by: Dan Horák <dan@danny.cz>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
In OF mambo pads zeros in the CPU node names. So if you have more than
16 CPUs, the first core will be at /cpus/PowerPC@00. Currently we
always look for /cpus/PowerPC@0.
Fix by zero padding based on the max CPU count. This also converts to
hex since that's what's actually needed.
This fix should handle any topology. I've tested upto 128 threads (16
cores * 8 threads) but past that the mambo I have starts throwing
internal errors.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
|
|
This adds ibm,mmu-pid-bits and a new ibm,mmu-lpid-bits to POWER10 CPUs.
POWER9 Linux has some workarounds for processors bugs that means it's
probably safer to not add the entries there.
Linux already hard codes these values correctly on these processors, but
this allows more flexibility to change things.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
|
|
This patch enables Skiboot to initialize and Linux to boot to user space
on the AWAN core and chip models.
We need the distinction between core and chip models because the core
models do not have an XSCOM unit, CHIPTOD, nor RNG. The chip
model does have them and they work.
So, add a device_type property to the awan node to distinguish core from
chip. Sample DTS are provided for the core and chip models in
external/awan.
Just like Mambo, we need to return in slw_init before trying to
initialize SLW. Without an XSCOM unit in the device tree for the core
model, the SLW code path eventually fails an assert due to lack of
chips.
This commit defines a QUIRK_AWAN where previously Mambo used
QUIRK_MAMBO_CALLOUTS so now Mambo and AWAN core both work.
Also, fix up chip quirks so the core model and chip model boot and
initialize the appropriate units.
Disable sreset and power management in a couple spots because the chip
model does not support stop with EC=1 and enter_p9_pm_state spins in the
branch-to-self after stop.
Provide an external/awan/README.md with a high-level view of booting in
the environment.
Signed-off-by: Ryan Grimm <grimm@linux.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
If the SMT configuration is not 8, set small-core mode in SIM_CTRL1
and PVR registers.
Also allow only 1, 2, 4, or 8 threads, and only allow 1 and 2 threads
if there is only one processor configured. This helps avoid strange
crashes due to thread/core enumeration problems with unexpected threads
per core.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Update SIM_CTRL1 bits to set ARC0/1, which disables atomic RC updates in
hardware which matches implementation.
Comment some remaining quirks with the P9 configuration.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Update PVR and mambo f000f bits:
- Set POWER10 to DD2.0
Update SIM_CTRL and SIM_CTRL1 bits:
- Set the LPAR-per-core mode bit. This is required for SMT KVM to work.
- Set ARC0/ARC1 bits which enable atomic RC update interrupts (not
hardware updates), which matches implementation.
- Enable DEXCR, HAIL, ROP, BHRB disable, block BHRB writes in PR=0,
and RFC02628 on POWER10.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Make it a bit easier to boot large kernels by printing more info when
the kernel is too big, so the user has some idea how much they need to
adjust PAYLOAD_ADDR by.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Starting P10, hostboot/HDAT will provide consistent reserved node name. It will
just provide node name without starting string "ibm,". That will cause
`pm-complex <*>` operation to fails.
This patch fixes above issue. For backward compatability purpose I have
kept support for old variant of node name as well.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Add Power10 support for opal-gard utility.
Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
[Folded test case fix and updated commit message - Vasant]
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Co-authored-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Co-authored-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Co-authored-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
[Folded Maddy's IMC changes and Ravi's DAWR changes - Vasant]
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
I'm hitting a stack size warning when building pflash:
common/arch_flash_powerpc.c: In function ‘get_dev_mtd.constprop’:
common/arch_flash_powerpc.c:177:1: error: the frame size of 8240
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
That function has 2 PATH_MAX strings, each of which will use up 4kB of
stack.
We've tried to work around the issue of stack size warnings on host
binaries in a few places, with limited success. This patch removes the
check completely instead. We need to modify the HOSTCFLAGS variable
assignment to be immediate for this to work.
Signed-off-by: Anton Blanchard <anton@ozlabs.org>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Add support for tracing I2C transactions performed by skiboot. This covers
both internally initiated I2C ops and those that requested by the kernel
via the OPAL API.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Make the trace tool's output format match that of skiboot's prlog().
Printing a timebase tick count in hex isn't terribly useful and having
a common format makes correlating trace entries to log entries much
easier.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Not all kernels support mmap() on an OPAL exported memory range. Fall
back to allocating a buffer and using the normal file IO system calls
to read the contents of the trace buffer in those cases.
This does mean we can't use "follow" mode since we can't monitor the
raw trace data effectively, but otherwise it works fine.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Convert scripts to Python3 as Python2 has been EOLed in 2020.
Fixes: https://github.com/open-power/skiboot/issues/225
Signed-off-by: Dan Horák <dan@danny.cz>
[Fixed directory walking logic in generate-fwts-olog - Vasant]
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
Linux requires chained CPIOs to be 4 byte aligned otherwise they are
ignored. This aligns them.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Dan Horák <dan@danny.cz>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
A very hacky, but very useful script that parses the PowerNV EEH register dump
from the kernel log, and the verbose EEH dump from the opal message log
and renders it into something mostly readable.
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
On systems using recent versions of systemd /dev (devtmpfs) is mounted with
noexec option. Such mount prevents mapping HBRT image code region as RWX
from /dev. This commit, as suggested in github PR linked below, attempts to
work around the situation by copying HBRT image to anon mmaped memory
region and sets mprotect rwx on it, allowing opal-prd to sucessfully
execute the code region.
Having memory region set as RWX is not ideal for security, but fixing that
is a separate and hard to solve problem. Original code also mmaped region
as RWX, so this PR does not make things worse at least.
Closes: https://github.com/open-power/skiboot/issues/258
Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[oliver: whitespace fix, add a comment, reflow commit message]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Mambo has a strange feature called MEMORY_OVERFLOW, enabled by
default, which causes some accesses to non-existent memory addresses
to transparently "create" memory.
This can be confusing when debugging, eg:
systemsim % mysim cpu 0 display spr pc
0xC0000000000246B8
systemsim % mysim memory display 0xC0000000000246B8 8
0x0000000000000000
Appears to show that the memory at pc (NIP) is currently zeroes.
The astute observer will note that "mysim memory display" takes
physical addresses, not effective addresses. So unless this machine
has > 12XB of RAM, this access should have failed as there is no
memory at that address.
Turning MEMORY_OVERFLOW off gives us a much more sensible result:
systemsim % mysim memory display 0xC0000000000246B8 8
Illegal Address 0xC0000000000246B8
It doesn't appear to have any effect on accesses done from Linux, with
the setting enabled or disabled we still get a machine check for bad
accesses in real mode:
0:mon> p $__mmu_off
return value is 0x9000000030001003
0:mon> d c008000000000000
c008000000000000 [15447.242793] Disabling lock debugging due to kernel taint
[15447.242824] MCE: CPU0: machine check (Severe) Host Real address Load/Store (foreign) [Not recovered]
[15447.242868] MCE: CPU0: NIP: [c000000000103090] mread+0x90/0x190
[15447.242897] MCE: CPU0: Initiator CPU
[15447.242918] MCE: CPU0: Hardware error
[15447.242939] opal: Hardware platform error: Unrecoverable Machine Check exception
[15447.242978] CPU: 0 PID: 18 Comm: kopald Tainted: G M 5.7.0-gcc-8.2.0-13354-gd475a86526b5-dirty #127
[15447.243022] NIP: c000000000103090 LR: c000000000103034 CTR: c0000000000c2050
[15447.243059] REGS: c0000000fffbfd70 TRAP: 0200 Tainted: G M (5.7.0-gcc-8.2.0-13354-gd475a86526b5-dirty)
[15447.243101] MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 28002224 XER: 20040000
[15447.243150] CFAR: c000000000029660 DAR: c008000000000000 DSISR: 00000008 IRQMASK: 3
[15447.243150] GPR00: 0000000028002224 c0000000f05074c0 c000000001775e00 0000000000000000
[15447.243150] GPR04: c0000000f0507768 0000000000000010 0000000000000010 c0000000f0507768
[15447.243150] GPR08: 0007ffff0faf8899 0000000000000000 c0000000f0507767 9000000030001003
[15447.243150] GPR12: 0000000031c10000 c000000001970000 c0000000f0507738 0000000000000000
[15447.243150] GPR16: 000000000000002e 0000000000000010 000000000000002e 0000000000000010
[15447.243150] GPR20: c000000000e563d0 c000000000ffcf88 c000000000fddf30 c008000000000000
[15447.243150] GPR24: c0000000f0507767 c000000000ffc678 0000000000000040 c0000000f0507878
[15447.243150] GPR28: c0000000f0507768 c0000000f0507768 0000000000000010 0000000000000000
[15447.243485] NIP [c000000000103090] mread+0x90/0x190
[15447.243514] LR [c000000000103034] mread+0x34/0x190
[15447.243538] Call Trace:
[15447.243559] [c0000000f05074c0] [c0000000f0507510] 0xc0000000f0507510 (unreliable)
[15447.243602] [c0000000f0507510] [c000000000107b48] xmon_core+0xd18/0x3a10
[15447.243640] [c0000000f0507850] [c00000000010a870] xmon+0x30/0x80
[15447.243677] [c0000000f05079f0] [c0000000001050d4] sysrq_handle_xmon+0xc4/0xd0
[15447.243720] [c0000000f0507a20] [c000000000882954] __handle_sysrq+0xd4/0x220
[15447.243758] [c0000000f0507ac0] [c00000000089db68] __hvc_poll+0x268/0x4b0
[15447.243796] [c0000000f0507b60] [c00000000089e824] hvc_handle_interrupt+0x24/0x70
[15447.243838] [c0000000f0507b80] [c0000000001c2474] __handle_irq_event_percpu+0xb4/0x350
[15447.243880] [c0000000f0507c50] [c0000000001c2754] handle_irq_event_percpu+0x44/0xc0
[15447.243923] [c0000000f0507c90] [c0000000001c2844] handle_irq_event+0x74/0xc0
[15447.243965] [c0000000f0507cc0] [c0000000001c9770] handle_level_irq+0xe0/0x1c0
[15447.244006] [c0000000f0507cf0] [c0000000001c0a44] generic_handle_irq+0x54/0x80
[15447.244046] [c0000000f0507d10] [c0000000000ca050] opal_handle_events+0x130/0x150
[15447.244088] [c0000000f0507d60] [c0000000000c1e7c] kopald+0x9c/0x140
[15447.244124] [c0000000f0507db0] [c00000000016ea9c] kthread+0x19c/0x1b0
[15447.244161] [c0000000f0507e20] [c00000000000d1a8] ret_from_kernel_thread+0x5c/0x74
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
The memory_error() hservice interface expects the memory_error() call to
just accept the offline request and return without actually offlining the
memory. Currently we will attempt to offline the marked pages before
returning to HBRT which can result in an excessively long time spent in the
memory_error() hservice call which blocks HBRT from processing other
errors. Fix this by adding a worker process which performs the page
offlining via the sysfs memory error interfaces.
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
The configuration of SIM_CTRL1 doesn't match POWER9 in a number of
ways, including missing vslv, vsrv, addex and xsmax*/xsmin*/xscmp*
instructions.
Signed-off-by: Anton Blanchard <anton@ozlabs.org>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Bytes 22-23 Bit 0 in ibm,pa-features indicate TM support. None of the
pa_features_p9*[] in hdata/cpu-common.c set this bit so do not set it
in the ibm,pa-features made for mambo either.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Right now the $(sbindir) variable isn't defined, so the binary gets installed
directly into $(DESTDIR).
Signed-off-by: Dan Horák <dan@danny.cz>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
To go along with core-check and friends.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
The various ffspart test cases use /dev/zero as an input which doesn't
behave like a normal file. The stat.st_size field for char devs is
generally zero so the subsequent attempt to mmap() the file fails
because we requested a zero size mapping.
Previously we didn't notice this, but it sort of worked since the
partitions in the test script that used /dev/zero as an input were
also had those partitions marked as ECC. This resulted in the partition
contents being re-generated (using a buffer libflash allocates) and
the source data pointer being ignored since we said it was zero length.
Fix all this by dropping mmap() entirely and inhale the input file into
a buffer we malloc() instead. This works for any file, including
/dev/urandom, which can't be mmap()ed.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
opal-gard on POWER9P system fails to identify few chip targets while
displaying gard records. This patch fixes that.
Before:
# opal-gard list
ID | Error | Type | Path
-------------------------------------------------------------------------------
00000001 | 90004af4 | Predictive | /Sys0/Node0/Proc0/MC0/MI0/UNKNOWN0/UNKNOWN0
===============================================================================
After this patch:
# ./opal-gard list
ID | Error | Type | Path
---------------------------------------------------------------------------
00000001 | 90004af4 | Predictive | /Sys0/Node0/Proc0/MC0/MI0/MCC0/OMI0
===========================================================================
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Reviewed-by: Dan Horák <dan@danny.cz>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Cc: Dan Horák <dan@danny.cz>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
SPDX makes it a simpler diff.
I have audited the commit history of each file to ensure that they are
exclusively authored by IBM and thus we have the right to relicense.
The motivation behind this is twofold:
1) We want to enable experiments with coreboot, which is GPLv2 licensed
2) An upcoming firmware component wants to incorporate code from skiboot
and code from the Linux kernel, which is GPLv2 licensed.
I have gone through the IBM internal way of gaining approval for this.
The following files are not exclusively authored by IBM, so are *not*
included in this update (I will be seeking approval from contributors):
core/direct-controls.c
core/flash.c
core/pcie-slot.c
external/common/arch_flash_unknown.c
external/common/rules.mk
external/gard/Makefile
external/gard/rules.mk
external/opal-prd/Makefile
external/pflash/Makefile
external/xscom-utils/Makefile
hdata/vpd.c
hw/dts.c
hw/ipmi/ipmi-watchdog.c
hw/phb4.c
include/cpu.h
include/phb4.h
include/platform.h
libflash/libffs.c
libstb/mbedtls/sha512.c
libstb/mbedtls/sha512.h
platforms/astbmc/barreleye.c
platforms/astbmc/garrison.c
platforms/astbmc/mihawk.c
platforms/astbmc/nicole.c
platforms/astbmc/p8dnu.c
platforms/astbmc/p8dtu.c
platforms/astbmc/p9dsu.c
platforms/astbmc/vesnin.c
platforms/rhesus/ec/config.h
platforms/rhesus/ec/gpio.h
platforms/rhesus/gpio.c
platforms/rhesus/rhesus.c
platforms/astbmc/talos.c
platforms/astbmc/romulus.c
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
[oliver: fixed up the drift]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
This patch just renames the env var to be non-plural to match PMEM_DISK.
A related patch going in to mambo will make the actual mode used in
mambo be called "private" instead of "cow" to reflect the fact that
you're getting a private copy of the image file and that any data
written to it will be lost when mambo exits. Unlike the old bogusdisk
driver, there is no separate .cow file where the writes go.
Signed-off-by: Aaron Sawdey <acsawdey@linux.ibm.com>
Acked-by: Michael Neuling <mikey@neuling.org>
[oliver: fixed whitespace damage on the patch]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
I've added support in mambo's "memory mmap" command to have a "cow" mode
which just uses MAP_PRIVATE instead of MAP_SHARED on the file so that writes
to the memory region are not sent back to the file. This allows multiple
mambo instances to share the same filesystem image.
This is implemented by having a PMEM_MODES environment variable. If this
is set, it is expected to contain a comma separated list of modes (rw or cow)
for the list of files in PMEM_DISK. If there are fewer modes than files, the
remaining files default to "rw".
Signed-off-by: Aaron Sawdey <acsawdey@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Enable a new PVR for gard tool to work on another p9 variant. Makes op-test
as well happy.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[oliver: s/Axone/axone/]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Skiboot expects a chip-id to be associated with the pmem device tree
node. Without one the following assertion is hit during boot:
1305405: (1305405): [ 0.001300406,3] ***********************************************
1316412: (1316412): [ 0.001306446,3] < assert failed at core/device.c:968 >
1319544: (1319544): [ 0.001316645,3] .
1322726: (1322726): [ 0.001319777,3] .
1325958: (1325958): [ 0.001322959,3] .
1329490: (1329490): [ 0.001326191,3] OO__)
1332972: (1332972): [ 0.001329723,3] <"__/
1336404: (1336404): [ 0.001333205,3] ^ ^
1612307: (1612307): [ 0.001581877,3] Fatal TRAP at 00000000300297f4 .dt_get_chip_id+0x28 MSR 9000000000021002
1618779: (1618779): [ 0.001612557,3] CFAR : 00000000300ce7b4 MSR : 9000000030001000
1625236: (1625236): [ 0.001619014,3] SRR0 : 00000000300297f4 SRR1 : 9000000000021002
1631693: (1631693): [ 0.001625471,3] HSRR0: 0000000030012624 HSRR1: 9000000030001000
1637745: (1637745): [ 0.001631928,3] DSISR: 00000000 DAR : 0000000000000000
1644023: (1644023): [ 0.001637980,3] LR : 00000000300297dc CTR : 0000000000000000
1649684: (1649684): [ 0.001644258,3] CR : 20000202 XER : 00040000
1656705: (1656705): [ 0.001649921,3] GPR00: 00000000300297dc GPR16: 0000000000000000
1663740: (1663740): [ 0.001656946,3] GPR01: 0000000031c13940 GPR17: 0000000000000000
1670775: (1670775): [ 0.001663981,3] GPR02: 0000000030127400 GPR18: 0000000000000000
1677810: (1677810): [ 0.001671016,3] GPR03: 00000000ffffffff GPR19: 0000000000000000
1684845: (1684845): [ 0.001678051,3] GPR04: 00000000300d0376 GPR20: 0000000000000000
1691796: (1691796): [ 0.001685086,3] GPR05: 000000000000000c GPR21: 0000000000000000
1698831: (1698831): [ 0.001692037,3] GPR06: 0000000031c10060 GPR22: 0000000000000000
1705960: (1705960): [ 0.001699072,3] GPR07: 0000000030500010 GPR23: 00000000300eca0c
1713089: (1713089): [ 0.001706201,3] GPR08: 0000000030502b48 GPR24: 00000000300cf2c8
1720124: (1720124): [ 0.001713330,3] GPR09: 0000000000000000 GPR25: 00000000300ce8d7
1727182: (1727182): [ 0.001720365,3] GPR10: 0000000000000063 GPR26: 00000000300ce8fb
1734228: (1734228): [ 0.001727423,3] GPR11: 0000000000000003 GPR27: 00000000300d0398
1741358: (1741358): [ 0.001734469,3] GPR12: 0000000040000402 GPR28: 00000000300ce91d
1748488: (1748488): [ 0.001741599,3] GPR13: 0000000031c10000 GPR29: 00000000300d048f
1755618: (1755618): [ 0.001748729,3] GPR14: 00000000300026fc GPR30: 0000000030502cb8
1762748: (1762748): [ 0.001755859,3] GPR15: 0000000030000000 GPR31: 0000000030502cb8
2414283: (2414283): CPU 0000 Backtrace:
2414283: (2414283): S: 0000000031c13c40 R: 00000000300297dc .dt_get_chip_id+0x10
2414283: (2414283): S: 0000000031c13cb0 R: 000000003002ab68 .add_chip_dev_associativity+0x14
2414283: (2414283): S: 0000000031c13d50 R: 0000000030017c00 .mem_region_init+0x144
2414283: (2414283): S: 0000000031c13e30 R: 00000000300153d0 .main_cpu_entry+0x4d4
2414283: (2414283): S: 0000000031c13f00 R: 000000003000275c boot_entry+0x1bc
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Tested-by: Praveen K Pandey <praveen@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Make skiboot.tcl able to load and use a CVC blob from a real system.
This code comes from the src/securerom/ code in Hostboot.
we now use this in the sreset_world and hello_world test cases when we
do a secure boot run of them
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
[oliver: folded cvc.bin into this patch, misc fixes]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Soon hostboot/HDAT will provide consistent reserved node name. It will
just provide node name without starting string "ibm,". Commit 50d508c3
made sure that all device tree nodes starts with "ibm,".
But we use hostboot/HDAT provided name for `ibm,prd-label` property. So we
have to fix couple of our `ibm,prd-label` property based search/comparision
to accommodate this change.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
This allows us to test various combinations of the Linux
spectre/meltdown mitigations.
The default values of the existing settings remain the same.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
gard tool is not supported on FSP based system. But we can still
run gard tests on FSP based system.
Acked-by: Stewart Smith <stewart@flamingspork.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Currently trying to clear a gard record results in errors:
$ ./opal-gard -pef part create /sys0/node0/proc1
$ ./opal-gard -pef part list
ID | Error | Type | Path
---------------------------------------------------------
00000001 | 00000000 | Manual | /Sys0/Node0/Proc1
=========================================================
$ ./opal-gard -pef part clear 00000001
Clearing gard record 0x00000001...done
ECC: uncorrectable error: ffffff00ffffffff ff
libflash ecc invalid
$
A little wrapper around hexdump(1) helps show where the error lies by grouping
output in blocks of nine such that the last byte is the ECC byte:
$ declare -f ecchd
ecchd ()
{
hexdump -e '"%08_ax""\t"' -e '9/1 "%02x ""\t""|"' -e '9/1 "%_p""|\n"' "$@"
}
A clean GARD partition displays as:
$ ecchd part
0002c000 ff ff ff ff ff ff ff ff 00 |.........|
*
00030ffb ff ff ff ff ff |.....|
$
Dumping the corrupt partition shows:
$ ecchd part
0002c000 ff ff ff ff ff ff ff ff 00 |.........|
*
0002c024 ff ff ff ff ff ff ff ff ff |.........|
0002c02d ff ff ff 00 ff ff ff ff ff |.........|
*
0002c051 ff ff ff 00 ff ff ff ff 00 |.........|
0002c05a ff ff ff ff ff ff ff ff 00 |.........|
*
00030ffb ff ff ff ff ff |.....|
$
blocklevel_smart_write() turned out to not be quite as smart as it thought it
was in that any unaligned write to ECC protected partitions aligned the
calculated ECC values to the start of the write buffer and not relative to the
start of the partition.
Fixes: 29d1e6f78109 ("libflash/blocklevel: add a smart write function which wraps up eraseing and writing")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Attempting to clear a specific gard record leads to corruption of the target
record rather than the expected removal:
$ ./opal-gard -f romulus.pnor list
No GARD entries to display
$ ./opal-gard -f romulus.pnor create /sys0/node0/proc1
$ ./opal-gard -f romulus.pnor list
ID | Error | Type | Path
---------------------------------------------------------
00000001 | 00000000 | Manual | /Sys0/Node0/Proc1
=========================================================
$ ./opal-gard -f romulus.pnor clear 00000001
Clearing gard record 0x00000001...done
$ ./opal-gard -f romulus.pnor list
ID | Error | Type | Path
---------------------------------------------------------
00000001 | 00000000 | Unknown | /Sys0/Node0/Proc1
=========================================================
The GUARD partition needs to be compacted when clearing records as the
end of the list is a sentinel represented by the erased-flash state. The
compaction strategy is to read the trailing records and write them to
the offset of the record to be removed, followed by writing the sentinel
record at the offset of what was previously the last valid record.
The corruption occurs due to incorrect calculation of the offset at which the
trailing records will be written.
Cc: Skiboot Stable <skiboot-stable@lists.ozlabs.org>
Fixes: 5616c42d900a ("libflash/blocklevel: Make read/write be ECC agnostic for callers")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
On arches where only file operation make sense such as x86 and others, use the same
code.
Signed-off-by: Frédéric Bonnard <frediz@debian.org>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
After commit 7b12d5489fcf ("hw/lpc: Configure SerIRQ interrupts on
P9P"), we abort on p9p Simics:
[ 1486.000029845,3] Duplicate property "interrupt-map" in node /lpcm-opb@6030000000000/lpc@f0000000
[ 1487.000158147,0] Aborting!
CPU 0000 Backtrace:
S: 0000000031c13940 R: 0000000030013d18 .backtrace+0x5c
S: 0000000031c139f0 R: 000000003001dbf8 ._abort+0x60
S: 0000000031c13a80 R: 000000003002d448 .new_property+0x94
S: 0000000031c13b20 R: 000000003002d5e8 .dt_add_property+0xd0
S: 0000000031c13bc0 R: 000000003004202c .lpc_create_int_map+0xa4
S: 0000000031c13da0 R: 0000000030043748 .lpc_finalize_interrupts+0x94
S: 0000000031c13e30 R: 0000000030015d18 .main_cpu_entry+0x620
S: 0000000031c13f00 R: 0000000030002740 boot_entry+0x1b8
Since skiboot creates these interrupt properties now, and always has on
older p9 systems, remove them from the input device tree.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|