version: update to 20190114

This is for QEMU 4.0.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

vio-vscsi: Support multiple channels / buses

The spapr-vscsi device of QEMU supports multiple channels (a.k.a. buses).
But when QEMU is started with a device on a bus > 0, SLOF fails to detect
the device, so that the boot fails. For example:

 qemu-system-ppc64 -nodefaults  -nographic -serial stdio -device spapr-vscsi \
  -blockdev driver=file,filename=/path/to/cdrom.iso,node-name=d1,read-only=on \
  -device scsi-cd,id=cd1,drive=d1,channel=6,scsi-id=5,lun=1

Thus SLOF should scan the various channels for bootable SCSI devices, too.
Since the common SLOF code for scanning SCSI devices has no meaning of
"channels" or "bus", we simply fake the bus ID to be part of the target
ID, so instead of supporting 64 targets = 64 devices, we now support
8 channel * 64 targets = 512 devices instead.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1663160
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

board-qemu/slof/vio-vscsi: Scan up to 64 SCSI IDs

QEMU supports up the 64 SCSI IDs on the vscsi "bus", see the string
"max_target = 63" in the source file hw/scsi/spapr_vscsi.c of QEMU.
However, SLOF currently only checks the first 9 IDs on the vscsi adaptor,
so when you try to boot from a CD-ROM like this, the boot fails:

 qemu-system-ppc64 ... -device spapr-vscsi,id=scsi0,reg=0x2000 \
    -drive file=/path/to/cdrom.iso,format=raw,if=none,id=dr1,readonly=on \
    -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=63,lun=1,drive=dr1,id=scd1

Thus let's change the amount of IDs that we scan in SLOF to 64, too, to
match the ID range that QEMU provides.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

usb/storage: Implement block write support

The only missing parts were to manage the transfer direction in
do-bulk-command and to copy the data to the buffer before the
write operation.

This is needed as GRUB2 wants to write the grubenv file at start
and hangs because the data are not provided to the disk controller.

I've checked the file is correctly modified by modifying an environment
variable in GRUB2 with "set saved_entry=2" then "save_env saved_entry"
and checking the result in linux with "grub2-editenv list".

Fixes: Fixes: a0b96fe66fcd991b407c1d67ca842921e477a6fd
       (Provide "write" function in the disk-label package)
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

usb/storage: Invert the logic of the IF-statements

to prepare write implementation

Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

fdt: Fix phandles for NVLink/NVLink2

The NVIDIA driver for NVLink2-capable GPU NVIDIA V100 discovers topology
between GPU/NPUs/GPURAM via the device tree which needs to have cross
references between device tree nodes.

This adds patching of the nodes needed for the driver to initialize.
As all these properties only contain phandles and nothing else, there is
no risc of accidendal damage.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
* added the commit log

fdt: Factor out code to replace a phandle in place

We generate a fake XICS phandle in QEMU and SLOF replaces that phandle
with the real one (i.e. SLOF's node address) in interrupt-parent and
interrupt-map properties. These properties are handled differently -
the interrupt-map is fixed in place while interrupt-parent is
decoded+encoded+set as a property.

This changes interrupt-parent fixing code to do what the interrupt-map
code does because soon we are going to have more phandles to fix and some
contain an array of phandles (such as "ibm,npu").

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* removed fdt-replace-l,

pci: use appropriate base class ids

This will allow SLOF to print the appropriate name instead of "unknown"
for PCI classes 0xd to 0x11.

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Makefile: Set a proper DRIVER_NAME when building from a git tree

The DRIVER_NAME environment variable is not set up correctly for the
build_romfs tool in case we build from a git tree, so the field in the
rom header did not contain much useful data. Let's use the revision
string from git as DRIVER_NAME in this case.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

romfs/tools: Silence more compiler warnings with GCC 8.1

GCC 8 complains about the following usages of strncpy, too:

create_crc.c:86:3: warning: â€˜strncpy’ specified bound 16 equals destination
 size [-Wstringop-truncation]
   strncpy(uHeader.stHeader.version, pcVersion, 16);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
create_crc.c:84:3: warning: â€˜strncpy’ specified bound 16 equals destination
 size [-Wstringop-truncation]
   strncpy(uHeader.stHeader.version, pcVersion, 16);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Let's work around the issue by using memcpy instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

romfs/tools: Silence GCC 8.1 compiler warning with FLASHFS_MAGIC

GCC 8.1 introduce some new warnings which affect create_crc.c. One of
them is:

create_crc.c: In function â€˜createHeaderImage’:
create_crc.c:110:2: warning: â€˜strncpy’ output truncated before terminating nul
 copying 8 bytes from a string of the same length [-Wstringop-truncation]
  strncpy(uHeader.stHeader.magic, FLASHFS_MAGIC, 8);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Initialize the header struct statically here instead to silence the warning.

Suggested-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

romfs/tools: Remove superfluous union around the rom header struct

Accessing the struct with memset and memcpy can also be done without the
union wrapper. While we're at it, also remove the FLASHFS_HEADER_DATA_SIZE
macre and use sizeof(stHeader) instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

make.rules: Compile SLOF with -fno-asynchronous-unwind-tables

With the new GCC 8, the asynchronous-unwind-tables are always enabled.
We don't need this for SLOF, so disable them to save 32 kiB in the
boot_rom.bin.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

version: update to 20180702

This is aimed to go to QEMU v3.0.

Compared to 20180621, this fixes a couple issues related to gcc8.1.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Fix bad assembler statements for compiling with gcc 8.1 / as 2.30

When compiling with a very recent toolchain, I get these warnings:

../../llfw/boot_abort.S: Assembler messages:
../../llfw/boot_abort.S:76: Warning: invalid register expression

and:

stage2_head.S: Assembler messages:
stage2_head.S:57: Warning: invalid register expression

The first one is using the wrong opcode, we should use "and" instead of
"andi" here. The second one is using a register instead of a constant
for load-immediate, which is non-sense, too. Fix it to use the right
constant instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libelf: Add REL32 to the list of ignored relocations

When compiling SLOF with GCC 8.1, I currently get a lot of these errors:

ERROR: Unhandled relocation (A) type 26

Type 26 is the "relative 32-bit" relocation. We can simply ignore it
(like the other relative relocations - REL14, REL24 and REL64) to
shut up these error messages.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

version: update to 20180621

This is aimed to go to QEMU v3.0.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

lib/libnet/pxelinux: Fix two off-by-one bugs in the pxelinux.cfg parser

There are two small bugs in the pxelinux.cfg parser:

1. If the file does not end with a '\n', the code set 'eol = cfg + cfgsize'
and later wrote a NUL character to *eol, i.e. it wrote the NUL character
beyond the end of the buffer. We've got to use 'eol = cfg + cfgsize - 1'
instead.

2. The code always replaced the last byte of the buffer with a NUL character
to get a proper termination. If the config file ends with a required character
(e.g. the last line is a KERNEL or INITRD line and the file does not have
a '\n' at the end), the last character got lost. Move the obligation for the
terminating NUL character to the caller instead so that we can be sure to
have a proper terminated buffer in pxelinux_parse_cfg() without the need to
blindly overwrite the last character here.

Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

lib/libnet/pxelinux: Make the size handling for pxelinux_load_cfg more logical

The pxelinux_load_cfg() function always tried to load one byte less than
its parameter said (so that we've got space for a terminating NUL-character
later). This is not very intuitive, let's better ask for one byte less
when we call the function. While we're at it, add a sanity check that
the function really did not load more bytes than requested.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libc: Add a simple implementation of an assert() function

... useful for "this should never happen" situations, where
you want to make sure that it really never happens.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
[aik: removed extra ';' and empty line]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Support UUID-based pxelinux.cfg file names

Retrieve the UUID from the device tree and pass it to the pxelinux.cfg
function, so that we can look there for UUID-based file names, too.

Signed-off-by: Thomas Huth <thuth@redhat.com>
[aik: removed trailing space]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

slof: Add a helper function to get the contents of a property in C code

We will need to retrieve the UUID of the VM in the libnet code, so we
need a function to get the contents from a device tree property.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Add support for DHCPv4 options 209 and 210

There are two dedicated DHCP options for loading PXELINUX config files,
option 209 (config file name) and 210 (path prefix). We should support
them, too, in case some users want to configure their boot flow this way.
See RFC 5071 and the following URL for more details:
https://www.syslinux.org/wiki/index.php?title=PXELINUX#DHCP_options

Unlike most other strings in libnet, I've chosen to not use fixed-size
arrays for these two strings, but to allocate the memory via malloc here.
We always have to make sure not to overflow the stack in Paflof, so
adding 2 * 256 byte arrays to struct filename_ip sounded just too
dangerous to me.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Wire up pxelinux.cfg network booting

In case the normal network loading failed, try to load a pxelinux.cfg
config file. If that succeeds, load the kernel and initrd with the
information that could be found in this file.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Add functions for downloading and parsing pxelinux.cfg files

Booting a kernel via pxelinux.cfg files is common on x86 and also with
ppc64 bootloaders like petitboot, so it would be nice to support this
in SLOF, too. This patch adds functions for downloading and parsing
such pxelinux.cfg files. See this URL for more details on pxelinux.cfg:
https://www.syslinux.org/wiki/index.php?title=PXELINUX

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Put code for determing TFTP error strings into a separate function

This way we can easily re-use the rc --> string translation in later
patches.

Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libc: Add the snprintf() function

Code has been taken from the sprintf() function (which is almost the same,
except that snprintf calls vsnprintf instead of vsprintf internally).

Signed-off-by: Thomas Huth <thuth@redhat.com>
[aik: fixed traling spaces]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Pass ip_version via struct filename_ip

When we will support loading of pxelinux.cfg files later, we have to call
the tftp load function multiple times from different places. To avoid that
we've also got to pass around the ip_version information via function para-
meters to all spots, let's rather put it into struct filename_ip instead
since we've got this struct filename_ip info available everywhere already.

While we're at it, also drop the  __attribute__((packed)) from the struct.
The struct is only used internally, without exchanging it with the outside
world, so the attribute is certainly not necessary here.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

resolve ihandle and xt handle in the input command (like for the output)

Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Fix output word

We can select the console output, but it does not really work

Implement term-io-emit, as we have term-io-key to really
send characters to the output selected by stdout.

Resolve xt and ihandle in the output command.

Use them in the new term-io-emit function.

Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
[aik: fixed commit log]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

obp-tftp: Make sure to not overwrite paflof in memory

The obp-tftp package is currently using an arbitrary large value
as maximal load size. If the downloaded file is big enough, we
can easily erase Paflof in memory this way. Let's make sure that
this can not happen by limiting the size to the amount of memory
below the Paflof binary (which is close to the end of the RAM)
in case of board-qemu, or the amount of memory between the minimum
RAM size and the load-base on board-js2x.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Get rid of unused huge_load and block_size parameters

The blocksize is hard-coded to 1428 bytes in obp-tftp.fs, so instead of
hardcoding this in the Forth code, we could also move this into tftp.c
directly instead. A similar condition exists with the huge-tftp-load
parameter. While this non-standard variable could still be changed in the
obp-tftp package, it does not make much sense to set it to zero since you
only lose the possibility to do huge TFTP loads with index wrap-around in
that case.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libc: Check for NULL pointers in free()

POSIX says that the free() function should simply do nothing if a NULL
pointer argument has been specified. So let's be a little bit more
compliant in our libc and add a NULL pointer check here, too.

Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libc: Implement strrchr()

This function will be used in one of the next patches to find the last
slash in a file name string.

Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Get rid of unnecessary (char *) casts

For some strange reasons, the libnet code is using int8_t arrays for
strings in a couple of places where it really does not make any sense.
Therefor a lot of "(char *)" casts are needed when the code is using
the string functions from the libc. Let's change the strings to use
"char" instead of "int8_t" so we can get rid of a lot of these casts.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

broken_sc1: check for H_PRIVILEGE

Recently, found that when DAWR was disabled by linux kernel, the hcall started
returning H_UNSUPPORTED, and VM did not boot up as broken_sc1 patched up SC
calls falsely.

Instead of checking for various returns, check if its not in privilege mode and
patch sc1 in that case.

CC: Michael Ellerman <michael@ellerman.id.au>
CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

OF: Use new property "stdout-path" for boot console

Linux kernel commit 2a9d832cc9aae21ea827520fef635b6c49a06c6d
(of: Add bindings for chosen node, stdout-path) deprecated chosen property
"linux,stdout-path" and "stdout".

Check for new property "stdout-path" first and as a fallback check
"linux,stdout-path". This older property can be deprecated after 5 years.

Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

version: update to 20171214

This is aimed to go to QEMU v2.12.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

boot: use a temporary bootdev-buf

The catpad size is 1K size, which can overflow easily with around 20 devices
having bootindex. Replace usage of $cat with a dynamically allocated buffer(16K)
here. Introduce new words to work on the buffer (allocate, free and
concatenate)

Reported here: https://github.com/qemu/SLOF/issues/3

Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

boot: do not concatenate bootdev

We were concatenating the word " parse-load" and $bootdev list that was input to
evaluate. Open code EVALUATE work such that concatenation is not required.
"load" and "load-next" does not use $cat anymore.

Reported here: https://github.com/qemu/SLOF/issues/3

Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libvirtio: Mark struct virtio_scsi_req_cmd as packed

The struct contains an uneven amount of bytes, so we should use
the "packed" attribute to avoid padding problems here. So far the
problems did not show up yet since the struct is filled by Forth
code only and QEMU seems to be quite forgiving about the length of
the descriptor, but anyway, let's better be safe than sorry here.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

fdt: Implement "fdt-fetch" method for client interface

The guest kernel fetches the device tree via the client interface,
calling it for every node and property, and traversing the entire tree
twice - first to build strings blob, second - to build struct blob.

On top of that there is also not so efficient implementation of
the "getprop" method - it calls slow  "get-property" which does full
search for a property.

As the result, on a 256 CPU + 256 Intel E1000 virtual devices,
the guest's flatten_device_tree() takes roughly 8.5sec.

However now we have a FDT rendering helper in SLOF which takes about 350ms
to render the FDT. This implements a client interface call to allow
the guest to read it during early boot and save time.

The produced DTB is almost the same as the guest kernel would have
produced itself - the differences are:
1. SLOF creates an empty reserved map; the guest can easily fix
it up later;
2. SLOF only reuses 40 most popular strings; the guest reuses everything
it can - on a 256CPU + 256 PCI devices guest, the difference is about
20KB for 350KB FDT blob.

Note, that the guest also ditches the "name" property just like SLOF
does:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/prom_init.c?h=v4.13#n2302

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---

If the guest tries "fdt-fetch" and SLOF does not have it, than SLOF
prints an error:
===
copying OF device tree...

fdt-fetch NOT FOUNDBuilding dt strings...
Building dt structure...
===

and the guest continues with the old method. We could suppress SLOF error
for such unlikely situation though.

rtas: Store RTAS address and entry in the device tree

At the moment we count on the guest kernel to update or create device
tree properties pointing to the instantiated RTAS copy which is not
very reliable.

This stores rtas-base and rtas-size in the DT at the instantiation
point so later on the H_UPDATE_DT hcall can supply QEMU with an updated
location of RTAS.

This superseeds f9a60de30 "Add private HCALL to inform updated
RTAS base and entry".

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v5:
* ditched rtas-entry, added rtas-size (which is always 20 bytes though)

board-qemu: Fix slof-build-id length

The existing code hardcodes the length of /openprom/model to 10 characters
even though it is less than that - len("aik")==3. All 10 chars go to
the device tree blob and DTC complains on such a property as there are
characters after terminating null:

aik@fstn1-p1:~$ dtc -f -I dtb -O dts -o dbg.dts dbg.dtb
Warning (model_is_string): "model" property in /openprom is not a string

This uses the real length and limits it by 10 to avoid breaking something.

Since the same code parses the build id field, this moves from-cstring
to a common place for both js2x and qemu boards.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

fdt: Pass the resulting device tree to QEMU

This creates flatten device tree and passes it to QEMU via a custom
hypercall right before jumping to RTAS.

This preloads strings with 40 property names from CPU and PCI device nodes
and the strings lookup only searches within these.

Test results on a guest with 256 CPUs and 256 virtual Intel E1000 devices
running on a POWER8 box:
FDTsize=366024 Strings=15888 Struct=350080 Reused str=12457 242 ms

A simple guest (one CPU, no PCI) with this patch as is:
FDTsize=15940 Strings=3148 Struct=12736 Reused str=84 7 ms

While we are here, fix the version handling in fdt-init. It only matters
a little for the fdt-debug==1 case though.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v6:
* fix memory sizes for free-mem
* store correct chosen-cpu to the header (used to be just 0)
* fdt-skip-string uses zcount now and works 30% faster
* moved to a new file - fdt-fl.fs

v5:
* applied latest comments from Segher
* s/fdt-property/fdt-copy-property/, s/fdt-properties/fdt-copy-properties/
* reduced the temporary buffers to 1MB each as the guest uses 1MB in total
anyway
* do not pass root phandle to fdt-flatten-tree, it fetches it from
device-tree itself
* reworked fdt-copy-properties to use for-all-words proposed by Segher

v4:
* reworked fdt-properties, works lot faster
* do not store "name" properties as nodes have names already

v3:
* fixed stack handling after hcall returned
* fixed format versions in both rendering and parsing paths
* rebased on top of removed unused hvcalls
* renamed used variables to have fdtfl- prefixes as there are already
some for parsing the initial dt

v2:
* fixed comments from review
* added strings cache
* changed last_compat_vers from 0x17 to 0x16 as suggested by dwg

---

I tested the blob by storing it from QEMU to a file and decompiling it.

fdt: Fix version and add a word for FDT header size

This fixes the version handling in fdt-init. It only matters
a little for the fdt-debug==1 case though.

This defines /fdth word for the FDT header size; this will be used
in the next patch.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Greg Kurz <groug@kaod.org>

tree: Rework set-chosen-cpu and store /chosen ihandle and phandle

This replaces current set-chosen-cpu with a cleaner and faster
implementation which does not clobber the current node and stores
the chosen CPU phandle/ihandle.

This adds a helper to get the chosen CPU unit address.

This moves chosen cpu words to root.fs as otherwise it is quite hard
to maintain dependencies.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>

node: Add some documentation

This adds some internal structure commented definitions so they won't
break things now and grep can find them.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Revert various SLOF-to-QEMU private hypercalls

This reverts commits:

604d28cc3 "board-qemu: add private hcall to inform host on "phandle" update"
089fc18a9 "libhvcall: drop unused KVMPPC_H_REPORT_MC_ERR and KVMPPC_H_NMI_MCE defines"
1c17c13a5 "rtas: Improve error handling in instantiate-rtas"
f9a60de30 "Add private HCALL to inform updated RTAS base and entry"

A bigger hammer is coming soon which will pass the entire device
tree to QEMU, not just some random bits.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Greg Kurz <groug@kaod.org>

Use input-device and output-device

QEMU can now set environment variables from the command line (with -prom-env).
By this means, we can set the output-device and input-device variables,
and SLOF can read it and set stdout and stdin accordingly.

Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Tested-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

netboot: Create bootp-response when bootp is used

According to TFTP Booting extension, after the success of BOOTP, BOOTREPLY
packet should be copied to bootp-response property under "/chosen"

While in current case, even when DHCP was used, bootp-response was being set. So
set bootp-response when BOOTP is used and dhcp-response for DHCP

Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet/ipv6: assign times_asked value directly

times_asked value remains same as the structure is zeroed, but it makes more
sense to do that directly instead of adding with previous value.

Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

usb-xhci: Reset ERSTSZ together with ERSTBA

When shutting down the adapter, SLOF writes 0 to the Event Ring Segment
Table Base Address Register (ERSTBA) but does not reset the Event Ring
Segment Table Size Register (ERSTSZ) which makes QEMU do DMA access
at zero address which fails in unassigned_mem_accepts.

This resets ERSTSZ right before resetting ERSTBA so these 2 registers
can stay in sync.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>

virtio-net: rework the driver to support multiple open

Found that virtio-net is using a around 200K receive buffer per device, if we
connect more than 40 virtio-net devices the heap(8MB) gets over. Because of
which allocation starts failing and the VM does not boot.

Moreover, the driver did not support opening multiple device, which is possible
using the OF client interface. As it was using globals to store the state
information of the driver.

Now the driver allocates a virtio_net structure during device open stage and
fills in the state information. This details are used during various device
functions and finally for cleaning up on close operation.

Now as the buffer memory is allocated during open and freed during the close
operations the heap usage is contained.

Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

board-qemu: add private hcall to inform host on "phandle" update

The "interrupt-map" property in each PHB node references the "phandle"
property of the "interrupt-controller" node. This is used by the guest
OS to setup IRQs for any PCI device plugged into the PHB. QEMU sets this
property to an arbitrary value in the flattened DT passed to SLOF.

Since commit 82954d4c1088, SLOF has some generic code to convert all
references to any "phandle" property to a SLOF specific value.

This is is perfectly okay for coldplug devices, since the guest OS only
sees the converted value in "interrupt-map". It is a problem though for
hotplug devices. Since they don't go through SLOF, the guest OS receives
the arbitrary value set by QEMU and fails to setup IRQs.

In order to support PHB hotplug, this patch introduces a new private
hcall, which allows SLOF to tell QEMU that a "phandle" was converted
from an old value to a new value.

Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

version: update to 20170724

This is aimed to go to QEMU v2.10.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

pci-scan: Fix pci-bridge-set-mem-base and pci-bridge-set-mem-limit

The functions used a bogus mixture between programming the registers
with pci-next-mem64 and pci-next-mem - the upper register bits were
filled with the value from the 64-bit memory space while the lower
bits were filled with the bits from the 32-bit memory space variable.

This separates handling of pci-{next|max}-mem64 from pci-{next|max}-mem.

This zeroes bottom 4 bits of the prefetchable memory limit and
prefetchable memory base registers for 32bit windows to enforce
that the resources are marked as 32bit.

This simplifies updating of the prefetchable memory limit in
ci-bridge-set-mem-limit.

Signed-off-by: Thomas Huth <thuth@redhat.com>
[aik: extended commit log with 32bit window changes]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>

pci: Avoid 32-bit prefetchable memory area if possible

PCI bridges can only have one prefetchable memory area. If we are
already using 64-bit prefetchable memory regions, we can not use
a dedicated 32-bit prefetchable memory region anymore. In that
case the 32-bit BARs should all be located in the 32-bit non-
prefetchable memory space instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Remove unused functions ishexdigit and $cat-comma

They are completely unused, and ishexdigit seems even to be implemented
in a wrong way, thus let's simply remove them.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

pci: Translate PCI addresses to host addresses at the end of map-in

Currently, it is not possible to use VGA devices attached to a
PCI bridge on board-qemu, e.g. by starting QEMU like this:

 qemu-system-ppc64 -nodefaults -device pci-bridge,id=br1,chassis_nr=1 \
        -serial mon:stdio -device VGA,id=video,bus=br1,addr=1

One of the problems is the missing translate-address at the end
of the map-in function of the bridge - which was already marked
as a TODO, but apparently has never been enabled. So let's do
that now!

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Define 'open' and 'close' words of the /aliases nodes right from the start

It's much easier to do this when we create the node instead of
looking up the device node again later in each of the boards.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

virtio-scsi: Allow LUNs bigger than 255

The virtio-scsi device expects LUNs according to a "Single level LUN
structure" as defined in the "SCSI Architecture Model" specification.
SLOF currently only uses the "Single level LUN structure using
peripheral device addressing method" which provides the possibility
to specify up to 256 different LUNs.
To be able to use LUNs greater than 255, the "Single level LUN structure
using flat space addressing method" has to be used instead. This can
be done by setting the top-most bits to "01" instead of "00" in the first
byte of the two LUN bytes.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1431584
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

paflof: Silence gcc's -Warray-bounds warning for stack pointers

The SLOF stack pointers - dp/rp - point to the top used element which
means for an empty stack they point to an element below the stack.
This means that for pushing to the stack we can use a store-with-update
instruction (stdu). This generates good code for most primitives,
better than the other stack pointer offsets.

However, with -Warray-bounds enabled, this produces warnings like below:

At the moment SLOF is  gcc produces a warning:
/home/aik/p/slof/slof/paflof.c: In function ‘engine’:
/home/aik/p/slof/slof/paflof.c:84:23: warning: array subscript is below array bounds [-Warray-bounds]
   dp = the_data_stack - 1;
        ~~~~~~~~~~~~~~~^~~

This silences gcc by doing c-cast.

Suggested-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
---

uintptr_t is not used anywhere in SLOF, hence type_u.

board_qemu: move code out of fdt-fix-node-phandle

This patch moves the code that actually alter the device tree to a
separate word, for improved readability. While here, it also makes
the comment of fdt-replace-all-phandles more accurate.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

board_qemu: drop unused values early in fdt-fix-node-phandle

These two values are pushed on the stack by decode-int and stay unused
until the 2drop line. Let's drop them right away to make it obvious.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

pci: Improve the pci-var-out debug function

Print all related variables, using the code from phb-parse-ranges in
board-qemu/slof/pci-phb.fs, so that we can easily check all the values
from the SLOF prompt, too.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libhvcall: drop unused KVMPPC_H_REPORT_MC_ERR and KVMPPC_H_NMI_MCE defines

These defines were introduced to add support for FWNMI in KVM guests. This
has been WIP since 2015 and the KVM part finally made it to kvm-ppc-next.

Latest work on the QEMU side [1] no longer needs KVMPPC_H_REPORT_MC_ERR.
The KVMPPC_HCALL_MAX define is never used anywhere, and moreover it
is bogus since there's no KVMPPC_H_NMI_MCE private hcall.

[1] http://lists.nongnu.org/archive/html/qemu-ppc/2015-12/msg00199.html

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Move parse_tftp_args to tftp.c

To be able to re-use the libnet code in other projects (where
the rather Open Firmware specific netload.c can not be used),
the function parse_tftp_args() must be moved to another file.
The function is related to TFTP, and its prototype is already
declared in tftp.h, so the code should reside in tftp.c.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Make the code compilable with -Wformat-security

When compiling the libnet code with the -Wformat-security compiler
flag, there is a warning in tftp.c that printf is used without
format argument. It's not a real problem here, but let's make
the code ready for this compiler flag anyway and add a proper
format string here, too.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Move the external declaration of send_ip to ethernet.h

When compiling SLOF with the -Wredundant-decls compiler flag,
there is currently a warning in the libnet code since the send_ip
pointer is currently declared twice, one time in ipv4.h and
one time in ipv6.h. To avoid this warning, let's move the
declaration to IP-version independent ethernet.h instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libc: Declare size_t as unsigned long

If size_t is only "int", memset() and friends are limited
to 4 GB. And ssize_t is already declared as "long", so it
is somewhat inconsequent to define size_t as "int" only.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet/netload: Three more minor clean-ups

The error code in netload_error() could be longer than 4 characters,
so we should rather use the calculated string length here instead.

The tftp_err variable is only used in tftp_load() so it can be moved
there.

And the icmp_err_str variable only points to constant strings, so it
should be marked with "const".

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet/tftp: Allow loading to address 0

It's theoretically possible to load a file to address 0, too, so
we should use a different marker than NULL to check for a valid
buffer.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Refactor some code of netload() into a separate function

netload() is a huge function, it's easy to lose track here. So
let's refactor the TFTP-related loading and error printing code
into a separate function instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Rework error message printing

There is a repetive pattern of code in netload.c to print out
error message: snprintf(buf, ...) + bootmsg_error() + write_mm_log().
The code can be simplified / shortened quite a bit by consolidating
this pattern in a helper function.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Remove remainders of netsave code

The code does not exist in the repository, so it does not make
sense to keep the prototypes and the Forth wrapper around.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

lib/Makefile: Pass FLAG to make in SUBDIRS target

Some applications, e.g. https://maas.io/, trust on the dhcp code 93
option to reply the correct pxelinux.0 file according to client
architecture.

Today, dhcp.c is compiled without DHCPARCH, which causes it not to
send client architecture in the dhcp request, i.e. dhcpd server can
reply a pxelinux.0 binary that is not intended for client
architecture.

This patch makes sure client architecture is sent in the dhcp request.

Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

virtio-net: Fix ugly error message

If virtio-net-open fails, SLOF currently prints out an ugly error
message: "virtio-net-open failedexiting". This happens because
there is no "cr" after the error message in the open function, and
virtio-net-init prints that other unhelpful error message "exiting"
right afterwards.
Fix it by issuing a CR in the open function already, and by removing
the unhelpful message from virtio-net-init.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

pci-phb: Set correct pci-bus-number while walking PCI bridges

Commit e44b7f07 ("Fix secondary and subordinate PCI bus enumeration")
created a board-qemu specific version of the pci-bridge-probe function
to fix problems with the secondary and  subordinate bus number
registers. Unfortunately, this function missed to update the
pci-bus-number variable like the original pci-bridge-probe function
did it, so that new bridges currently end up with a bad "my-bus"
setting (which is initialized from the pci-bus-number variable)
and thus things that depend on this setting, like the "decode-unit"
function currently don't work as expected on these PCI bridges.
Fix it by initializing the pci-bus-number from the PCI config
space settings that is provided by QEMU.

Fixes: e44b7f074f549f78303ad4d67d39b18db93d11bf
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1459755
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Cosmetical clean-up

Replace indentation spaces with tabs, remove superfluous prototype
(ip6addr_add() is declared in ipv6.h already) and fix the old-style
declaration of ip6_create_prefix_info(). No functional changes done.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

paflof: Print stack warning to stderr, not stdout

Now that stdout is routed through the TYPE Forth word, we should
avoid using stdout in critical sections in the engine() function.
So print the stack warning via stderr now instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libnet: Allocate ICMPv6 packet space on the heap, not on the stack

While doing IPv6 network booting in SLOF, I recently ran into
"ERROR: stack overflow in engine()!" messages. Looks like the
huge ether_packet arrays that are created on the stack in icmpv6.c
can cause these stack overflows. Fix this issue by allocating
the ether_packets from the heap instead (the functions should
not be timing critical, so the additional overhead should not
be an issue here).

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

A new SLOF boot menu

The current SLOF boot menu heavily depends on the contents of the
"qemu,boot-list" and "qemu,boot-device"" properties in the device tree,
so that the menu entries either look very strange (when there is no
alias, see https://bugzilla.redhat.com/show_bug.cgi?id=1429832 ) or
are duplicated (https://bugzilla.redhat.com/show_bug.cgi?id=1446018).

A proper boot menu should rather show all available boot devices
instead, so this patch series introduces a new boot menu (written in
C this time) which is independent from the "qemu,boot-list/device"
properties by looking at the available aliases instead. It is now also
possible by selecting the entries with one key stroke only (you don't
have to press RETURN anymore), so this is now hopefully much more user
friendly than the old menu.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

libc: The arguments of puts() can be marked as "const"

puts() does not change the string, so the parameter can be "const".

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Increase MAX-ALIAS to 10

It's not obvious for the normal user why the alias enumeration should
stop at the digit '7' already, so let's allow '8' and '9', too, by
bumping the MAX-ALIAS constant to 10. Also remove the unnecessary
duplicate of this value from qemu-bootlist.fs.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Use TYPE for the standard output instead of io_putchar()

All stdout text from the C code of the paflof binary (e.g. all output
from printf() and friends) is currently only written via io_putchar()
to the hvterm console. If the user decided to use a VGA display instead,
the text is currently not shown there. This is especially affecting the
output of the TFTP boot functions which are using printf() to provide
valuable information like IP addresses and progress indication to the
user. Let's fix this nuisance by routing the stdout text through the
TYPE Forth word instead, so that it now shows up on both, the hvterm
console and the VGA console.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

pci: Remove unused next-pci-[mem|mmio|io] functions

The next-pci-mem and next-pci-mmio Forth words are completely unused,
and pci-next-io is only used in one location (which can easily be
replaced), so let's get simply rid of these legacy functions.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

pci: Reserve free space at the end of bridge windows instead of at the beginning

This reverts commit e53c2541784fba7951c8aa6ccdbe4412fb03fca6
("pci-scan: reserve memory for pci-bridge without devices").
That commit reserved some free space on PCI bridges at the beginning
of the bridges' memory windows (by adjusting the pci-next-[mem|mmio|io]
variables during the pci-bridge-set-[mem|mmio|io]-base functions).

While this was basically a good idea, this way also had two drawbacks:

1) There also might be free space at the end of the window (since the
base of the next bridge window has to be aligned, too), so the free
space on the bridge is non-contiguous.

2) As soon as there was at least one device on the bridge that uses
at least some few byte in the I/O space, SLOF reserved at least 8k
of I/O space on the bridge - which is a *lot* in the scarce I/O space,
so that for example it was not possible anymore to next 8 PCI bridges
with devices attached to them (see the buglink below for details).

It's better to reserve the free space at the end of the memory windows
instead (in the pci-bridge-set-[mem|mmio|io]-limit functions), and
with regards to the scarce I/O space, we should also reserve less
I/O memory on each bridge, so we use a limit of 2k (plus alignment)
here now.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1443433
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>

pci: Generate a 64-bit range property if necessary

If the memory range exceeds the 32-bit boundary, we should generate
a 64-bit range property entry instead of a 32-bit entry.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

pci: Fix assigned-addresses for 64bit nonprefetchable BAR

975b31f80aff "pci: Put non-prefetchable 64bit BARs into 32bit MMIO window"
moved 64bit non-prefetchable BARs into 32bit non-prefetchable window
of a bridge. However the resource would still be advertised as 64bit
in the "assigned-addresses" property so fix the resource type.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>

pci-phb: Set pci-max-mem64 to the correct value

When running QEMU with a virtio device attached to a PCI bridge,
SLOF currently fails to initialize the device correctly. For example,
with the following command line:

 qemu-system-ppc64 -nographic -nodefaults -serial mon:stdio \
               -device pci-bridge,bus=pci.0,id=b1,chassis_nr=1 \
               -device virtio-net-pci,netdev=n1,bus=b1 -netdev user,id=n1

SLOF prints this error message during its PCI scan:

 Device does not support virtio 1.0 0
 virtio-net-open failedexiting

This happens because the virtio driver code can not access the
memory region of the device, because the bridge is configured
in the wrong way. The problem is that SLOF currently sets the
pci-max-mem64 variable to the size of the 64-bit PCI address space,
but it should be set to the end address of the 64-bit space instead.
The pci-max-mem64 is used for the memory limit register of the PCI
bridge (see pci-bridge-set-mem-base) during PCI scan, and using
a wrong value here blocks all memory accesses to the devices behind
the bridge.
So fix this issue by calculating the pci-max-mem64 value correctly.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Rework the printing of the banner during boot

If the initial boot attempt fails, for example because the file that we
downloaded via TFTP is not executable, or because the user exited grub
instead of booting a kernel, SLOF prints out the banner text twice.
This is quite ugly. Fix it by avoiding to print the banner during the
first boot attempt, i.e. by adding the ".banner" command to the "boot"
command only after we've done the first attempt via "start-it".

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1443904
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

bootmsg: Fix message for detected kernel

126e458fdc00 assumes that checkpoints are always printed from
the beginning of a line which is not the case when SLOF detects
a kernel image in check-boot-from-ram. When this happens, SLOF prints
a diagnostic message:
Detected RAM kernel at 400000 (180c3bc bytes)

Without 126e458fdc00, SLOF prints another checkpoint at the end of
the message, then it clears the last checkpoint with ."      " and
we see a nice message. With 126e458fdc00, we see:
     ted RAM kernel at 400000 (180c3bc bytes) C08FF

This adds "cr" to prevent the message from spoiling.

Fixes: 126e458fdc00 ("libbootmsg: Do not use '\b' characters when printing checkpoints")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>

logo: Update the logo

This removes old ugly logo to save precious boot cycles and make it
easier to do automation scripts. This removes logo for both QEMU and JS2x
boards. As .banner does not call .slof-logo anymore, this also removes
redefinitions of .banner.

While we are here, this updates a year in the copyright notice for
the QEMU board. This also removes some spaces from the standard banner.

Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>

pci: Put non-prefetchable 64bit BARs into 32bit MMIO window

At the moment 64bit non-prefetchable BARs of devices behind PCI p2p
bridge go to a 64bit prefetchable windows which is not correct and
causes linux guests to fail to ioremap() such resources.

This moves 64bit non-prefetchable BARs 32bit non-prefetchable window.

Note that this does not make distinction between P2P and PHB so
from now on XHCI BARs will be allocated from 32bit MMIO space.
However since most 64bit-MMIO-capable devices have prefetchable BARs,
and XHCI BAR is just 4K (so it is unlikely to cause any space problems),
this should not affect usual behavior.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Laurent Vivier <lvivier@redhat.com>
---

This fixes QEMU's XHCI when it is put on a P2P PCI bridge.

There is a little naming confusion as it may look like the patch
is changing assignment for all 64bit BAR but it does not as:
- "mmio" is used for non-prefetchable memory,
- "mem" is used for prefetchable memory.

Fix "Unsupported PQ" problems in the scsi-disk open function

The open function of the scsi-disk code has a bug: If it encounters
a Peripheral Qualifier != 0, it does not clean up the pointer to the
INQUIRY buffer before exiting, so the stack is messed up afterwards
and you get an ugly "Unknown Exception" before getting to the SLOF
prompt.
Also it's not a real error if the byte is set to 0x7f - this simply
means that the "SCSI target device is not capable of supporting a
peripheral device connected to this logical unit" (according to the
SPC-3 standard). So in this case, we should not issue an error
message, thus let's use the pointer to the INQUIRY buffer to check
whether the PQ/PDT byte is 0x7f to fix both problems.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

pci: force minimum mem bar alignment of 64K for board-qemu

This is needed to ensure VFIO passthrough devices are able to
offload MMIO accesses to KVM.

Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

version: update to 20170303

This is aimed to go to QEMU v2.9.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

qemu-bootlist: Take the "-boot strict=off" setting properly into account

SLOF currently completely ignores the "-boot strict=off" setting from
QEMU as soon as the user specified one of the devices with a "bootindex"
parameter. We should continue booting from other devices if strict
booting is disabled.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

virtio-scsi: initialize vring avail queue buffers

virtioscsi_init() uses the result of virtio_get_vring_avail() whereas
the queue is not enabled: on the first boot, its value is NULL and
the driver uses this to communicate with the device. After a reboot,
its value is the one given by the OS driver, and it works if the
address is in a range SLOF can access.

In some cases, for instance with NUMA nodes and hotplugged memory,
SLOF cannot access the address set by the kernel, and virtioscsi_init()
fails with a data storage exception.

To set the vring avail buffer address, we need to enable the queue, what
is done by virtio_set_qaddr().

This patch fixes the problem by calling virtio_queue_init_vq() (like other
virtio drivers) in virtioscsi_init() as it allocates memory and enables the
queue. virtio_queue_init_vq() also replaces the calls to virtio_vring_size()
and virtio_get_vring_avail().

Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>