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>
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)
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>
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.
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>
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>
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>
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>
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>
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 82954d4c10, 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>
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>
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>
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>
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>
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>
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>
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>
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: e44b7f074f
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>
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>
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>
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>
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>
126e458fdc 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 126e458fdc, SLOF prints another checkpoint at the end of
the message, then it clears the last checkpoint with ." " and
we see a nice message. With 126e458fdc, we see:
ted RAM kernel at 400000 (180c3bc bytes) C08FF
This adds "cr" to prevent the message from spoiling.
Fixes: 126e458fdc ("libbootmsg: Do not use '\b' characters when printing checkpoints")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
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>
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>
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>
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>
Printing a checkpoint only makes sense when there is some code between
the checkpoint and the next one. In tree.fs, there are a couple of
checkpoints without real code inbetween, so they are completely useless.
Let's simply remove them.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Refactor the virtio-block code a little bit to provide block write access,
too. Write access to the first 34 sectors is not allowed, though, to avoid
that the user / client program accidentially destroys the partition table.
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>
SLOF automatically switches to USB keyboard input when it detects that
a graphics card and USB keyboard are available. However, for debugging
VGA or USB related issues, or running QEMU with the "-nographic" parameter,
it's more convenient to continue using the hvterm as input.
This patch adds the possibility to continue using hvterm if the user
sets the "direct-serial?" NVRAM variable to true. "direct-serial?" is
currently unused for board-qemu -- it's only used on board-js2x so far
for switching the serial ports there, so using this variable for
selecting the serial input on board-qemu seems to be a good fit, too.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
virtio-gpu and virtio-vga share the same PCI ID (but have a
different PCI class). Since virtio-gpu does not have the VGA
register interface anymore, we should never try to use these
registers in SLOF, i.e. we must not include qemu-vga.fs in this
case.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1375166
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Now that all necessary functions are provided by Paflof, too,
we can finally link the libnet code to this binary. To be able
to call the netboot() function from the Forth code now, we also
add a wrapper that takes the parameter string from the obp-tftp
package and converts it to an argv array that is expected by
the netboot() function.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Add support for virtio serial device to be used as a console device.
Currently, SLOF only supports spapr-vty device. With this addition
virtio console can be used during boot.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Initial display output is replayed to vga/vnc display, similar facility
will be needed for virtio-serial console as the enumeration would only
happen during PCI discovery.
Generalize the write routine that could be used accordingly for
virtio-serial driver as well.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Make uniform indentation(width = 4) everywhere in the file.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
As soon as we are booting with at least one PCI device, the
rtas-do-config-@ Forth word is called quite often, so it
makes sense that we look up the corresponding RTAS token
only once instead of each time the function is called.
Also the "ffffffff and" operation on the lower half of the
PUID is not really required and can be removed, since the
"l!" Forth word is storing the lower four bytes only anyway.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
SLOF currently fails to correctly initialize the secondary and
subordinate bus number registers in the config space of PCI
bridges, so that for example with the following command line,
none of the PCI devices is usable:
qemu-system-ppc64 -nodefaults -nographic -serial mon:stdio \
-device pci-bridge,chassis_nr=1,id=bridge0,addr=0x3 \
-device pci-bridge,chassis_nr=2,id=bridge1,addr=0x4 \
-device virtio-balloon,bus=bridge1,addr=0x1 \
-device virtio-net,bus=bridge0,addr=0x2 \
-device virtio-rng,bus=bridge0,addr=0x5 \
-device pci-bridge,chassis_nr=3,id=br2,addr=0x6,bus=bridge1 \
-device e1000,bus=br2,addr=0x1
This is because SLOF tries to enumerate the PCI bus numbers
that are reachable via a bridge. In the function pci-bridge-probe,
it increases the pci-bus-number counter and writes that value into
the secondary bus number register of the PCI config space, and
after probing all attached bridges, it fills the number of the
last enumerated bus number into the subordinate bus number register.
This works fine if the whole bus enumeration is done by SLOF,
however on board-qemu, we nowadays rely on the pre-initialized PCI
device tree from QEMU - and the numbers that SLOF is trying to use
here do not match with the bus numbers that QEMU already assigned
to the bus segments (QEMU provides the device tree nodes in
descending order, but SLOF tries to enumerate the bus numbers in
ascending order here instead).
To fix this issue, we should simply stop setting up the secondary
and subordinate config space registers of the bridge in SLOF - since
this is done by QEMU already! Thus we replace the "pci-bridge-probe"
function with a board-qemu-specific function "phb-pci-bridge-probe",
that does not call "pci-bus!" and "pci-bus-subo!" anymore. (And since
pci-bridge-probe was the only spot that called phb-pci-probe-bus, we
can get rid of that wrapper now, too, and call phb-pci-walk-bridge
from phb-pci-bridge-probe directly instead).
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1377083
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>
The sequence "my-space pci-htype@ pci-out" in phb-pci-walk-bridge
is bugged: pci-htype@ already consumes the my-space item from the
stack, only leaving one item for pci-out. But pci-out needs two
input items on the stack, the PCI address and a character item.
So this rather should be "my-space dup pci-htype@ pci-out" instead.
However, using the output of pci-htype@ as input character for
pci-out also does not make much sense, since this is likely an
unprintable character. So let's simply use a question mark here
instead to indicate that we did not recognize the type of the
PCI device.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1377083
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Commit 2fed565281 ("Always include evaluator, move
framebuffer token init to fbuffer.fs") made sure that the FCode
evaluator is always included, during each boot cycle. The basic
idea was that we would soon be starting to support PCI cards with
FCode drivers on them. However, this has never happened, and so
this change was in vain. The bad thing is now that the inclusion
of the FCode evaluator also takes a lot of precious boot time,
e.g. when running in QEMU TCG mode, it is more than a second.
So to be able to boot faster again, disable the FCode evaluator
by default again and put it into the ROM-fs instead (so it still
can be loaded manually with "include evaluator.fs" if necessary).
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>
No functional change in this patch, only cosmetics:
Use indentation width = 4 spaces everywhere, fix typo in
one of the comments ("Child pin" instead of "Chile pin"),
and rename "swizzledpin" in the return stack comments
to "parentpin" to match the non-return stack comments.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
PCI bridges can have up to 31 slots. If we limit the value
from pci-addr2dev with "modulo 4", all devices in slots 4
and higher won't work correctly since the interrupt-map
property then contains wrong values in this case. For
example, when QEMU is started with the following command
line, Linux is not able to use the balloon device:
qemu-system-ppc64 ... \
-device pci-bridge,bus=pci.0,id=bridge1,chassis_nr=1,addr=0x6 \
-device virtio-balloon-pci,id=balloon0,bus=bridge1,addr=5
To fix this issue, simply remove the bogus "4 mod" calculation.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1366953
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The legacy PCI interrupts in the device tree are enumerated from 1
to 4. However, the code in pci-gen-irq-map-one generates numbers
between 0 and 3 instead. This renders devices unusable by Linux
in case they should use IRQ 4. For example, when starting QEMU with
qemu-system-ppc64 ... \
-device pci-bridge,bus=pci.0,id=bridge1,chassis_nr=1,addr=0x6 \
-device virtio-balloon-pci,id=balloon0,bus=bridge1,addr=3
Linux can not use the balloon device since it is unable to determine
the right IRQ number in this case.
To fix this issue, we've simply got to make sure that the IRQ
numbers are in the range from 1 to 4 instead of 0 to 3.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1366953
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
With the addition of cpu hotplug in QEMU, cpu@0 can be removed as well.
SLOF should not depend on it. Find the first child in the "/cpus" node
and get the timer base frequency and set it as the chosen cpu as well
Reported-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Allow the new little-endian ring format for the 9p driver, too,
just like it has already been done for the other virtio devices.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The virtio-9p devices currently show up as "unknown-legacy-device"
in the device tree. We've got a driver for this device, so it is
certainly not "unknown", i.e. let's use a better name here instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
There is currently only an unusable stub for the sms menu in SLOF.
It does not make much sense to parse this defunc code each time
we boot, that only wastes time and space in the boot rom image.
So let's simply remove these sms menu remainders for now.
Note: This patch also touches one line in OF.fs to make sure that
the dependencies for this file are properly regenerated (so we
avoid to force everybody to do a 'make distclean' afterwards).
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>
With commit aa9566d2e(virtio-net: move setup-mac to the open routine)
local-mac-address property started getting set during open routine. So
the netboot workflow was addressed. This was required as the device
needs to be probed before reading, after virtio 1.0 changes.
While boot from the disk and grub is set to get kernel over network, it
breaks. As grub looks for local-mac-address property first, which is not
there. Fix this by creating an instance and closing it. setup-mac in the
open will populate the local-mac-addres property
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The "read" function of the dev-null device currently claims that
the same amount of bytes has been read as input bytes have been
requested. This causes grub to hang forever at the boot selection
menu, since grub then thinks that there's a continuous stream of input
data. If nothing has been read (which is always the case for the
dev-null device), the "read" function should simply return 0 instead.
Then grub also boots properly again after the typical short timeout.
Reported-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Also add a device file for non-transitional pci device id: 0x1048
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>
Also add a device file for non-transitional pci device id: 0x1041
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>
Nikunj A Dadhania