talos-skiboot/core/init.c, branch master

Signal skiboot completion to BMC when done

2018-04-30T08:55:22+00:00

sensors: Dont add DTS sensors when OCC inband sensors are available

2018-04-19T23:56:06+00:00

There are two sets of core temperature sensors today. One is DTS scom based core temperature sensors and the second group is the sensors provided by OCC. DTS is the highest temperature among the different temperature zones in the core while OCC core temperature sensors are the average temperature of the core. DTS sensors are read directly by the host by SCOMing the DTS sensors while OCC sensors are read and updated by OCC to main memory. Reading DTS sensors by SCOMing is a heavy and slower operation as compared to reading OCC sensors which is as good as reading memory. So dont add DTS sensors when OCC sensors are available. Signed-off-by: Shilpasri G Bhat Acked-by: Vaidyanathan Srinivasan Signed-off-by: Stewart Smith

core: Correctly load initramfs in stb container

2018-04-11T22:59:57+00:00

Skiboot does not calculate the actual size and start location of the initramfs if it is wrapped by an STB container (for example if loading an initramfs from the ROOTFS partition). Check if the initramfs is in an STB container and determine the size and location correctly in the same manner as the kernel. Since load_initramfs() is called after load_kernel() move the call to trustedboot_exit_boot_services() into load_and_boot_kernel() so it is called after both of these. Signed-off-by: Samuel Mendoza-Jonas Signed-off-by: Stewart Smith

core/cpu: discover stack region size before initialising memory regions

2018-03-27T06:37:01+00:00

Stack allocation first allocates a memory region sized to hold stacks for all possible CPUs up to the maximum PIR of the architecture, zeros the region, then initialises all stacks. Max PIR is 32768 on POWER9, which is 512MB for stacks. The stack region is then shrunk after CPUs are discovered, but this is a bit of a hack, and it leaves a hole in the memory allocation regions as it's done after mem regions are initialised. 0x000000000000..00002fffffff : ibm,os-reserve - OS 0x000030000000..0000303fffff : ibm,firmware-code - OPAL 0x000030400000..000030ffffff : ibm,firmware-heap - OPAL 0x000031000000..000031bfffff : ibm,firmware-data - OPAL 0x000031c00000..000031c0ffff : ibm,firmware-stacks - OPAL *** gap *** 0x000051c00000..000051d01fff : ibm,firmware-allocs-memory@0 - OPAL 0x000051d02000..00007fffffff : ibm,firmware-allocs-memory@0 - OS 0x000080000000..000080b3cdff : initramfs - OPAL 0x000080b3ce00..000080b7cdff : ibm,fake-nvram - OPAL 0x000080b7ce00..0000ffffffff : ibm,firmware-allocs-memory@0 - OS This change moves zeroing into the per-cpu stack setup. The boot CPU stack is set up based on the current PIR. Then the size of the stack region is set, by discovering the maximum PIR of the system from the device tree, before mem regions are intialised. This results in all memory being accounted within memory regions, and less memory fragmentation of OPAL allocations. Signed-off-by: Nicholas Piggin Signed-off-by: Stewart Smith

mem-map: Use a symbolic constant for exception vector size

2018-03-27T05:41:09+00:00

Signed-off-by: Nicholas Piggin Signed-off-by: Stewart Smith

core/fast-reboot: verify mem regions before fast reboot

2018-03-27T05:40:50+00:00

Run the mem_region sanity checkers before proceeding with fast reboot. This is the beginning of proactive sanity checks on opal data for fast reboot (with complements the reactive disable_fast_reboot cases). This is encouraged to re-use and share any kind of debug code and unit test code. Signed-off-by: Nicholas Piggin Signed-off-by: Stewart Smith

Revert "console(lpc/fsp-console): Use only stdout-path property on P9 and above"

2018-03-07T03:24:10+00:00

This reverts commit 20f685a3627a2a522c465716377561a8fbcc608f. We've hit problems on Zaius machines and the needed petitboot changes haven't made it upstream yet. Let's revert for the time being while we sort everything out. We probably have to keep both around for a few years. Signed-off-by: Stewart Smith

console(lpc/fsp-console): Use only stdout-path property on P9 and above

2018-03-02T02:27:01+00:00

dtc tool complaining about below warning as usage of linux,stdout-path property under /chosen node is deprecated. dts: Warning (chosen_node_stdout_path): Use 'stdout-path' instead of 'linux,stdout-path' So this patch fix this by using stdout-path property on all the systems and keep linux,stdout-path only on P8 and before. This property refers to a node which represents the device to be used for boot console output. Verified boot on both P8 and P9 systems with new and older kernels. And also verified dtc warnings got fixed in both P8 and P9. Signed-off-by: Pridhiviraj Paidipeddi [stewart: simplify logic] Signed-off-by: Stewart Smith

npu2-opencapi: Configure NPU for OpenCAPI

2018-03-02T02:17:54+00:00

Scan the device tree for NPUs with OpenCAPI links and configure the NPU per the initialisation sequence in the NPU OpenCAPI workbook. Training of individual links and setup of per-AFU/link configuration will be in a later patch. Signed-off-by: Andrew Donnellan Signed-off-by: Frederic Barrat Reviewed-by: Frederic Barrat Signed-off-by: Stewart Smith

core/init: Assert when kernel not found

2018-03-01T02:28:39+00:00

If the kernel doesn't load out of flash or there is nothing at KERNEL_LOAD_BASE, we end up with an esoteric message as we try to branch to out of skiboot into nothing [ 0.007197688,3] INIT: ELF header not found. Assuming raw binary. [ 0.014035267,5] INIT: Starting kernel at 0x0, fdt at 0x3044ad90 13029 [ 0.014042254,3] *********************************************** [ 0.014069947,3] Fatal Exception 0xe40 at 0000000000000000 [ 0.014085574,3] CFAR : 00000000300051c4 [ 0.014090118,3] SRR0 : 0000000000000000 SRR1 : 0000000000000000 [ 0.014096243,3] HSRR0: 0000000000000000 HSRR1: 9000000000001000 [ 0.014102546,3] DSISR: 00000000 DAR : 0000000000000000 [ 0.014108538,3] LR : 00000000300144c8 CTR : 0000000000000000 [ 0.014114756,3] CR : 40002202 XER : 00000000 [ 0.014120301,3] GPR00: 000000003001447c GPR16: 0000000000000000 This improves the message and asserts in this case: [ 0.014042685,5] INIT: Starting kernel at 0x0, fdt at 0x3044ad90 13049 bytes) [ 0.014049556,0] FATAL: Kernel is zeros, can't execute! [ 0.014054237,0] Assert fail: core/init.c:566:0 [ 0.014060472,0] Aborting! Signed-off-by: Michael Neuling Reviewed-by: Vaidyanathan Srinivasan Tested-by: Joel Stanley Signed-off-by: Stewart Smith