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>
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>
This reverts commit e53c254178
("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>
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>
975b31f80a "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>
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>
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>
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.
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>
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>
As with the "read" function, the disk-label package should
forward the "write" function to its parent.
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Using the SCSI commands WRITE-10 and WRITE-16, we can implement block write
support for SCSI disks. 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>
To support block writes, the deblocker should feature a 'write'
function, too. Since our only client that tries to use write
accesses so far (GRUB2) is always writing whole sectors, we
do not do the complicated read-modify-write dance here yet, but
simply check that the client always tries to write whole sectors.
Reviewed-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Now that we already set the default values in /options during
"(set-defaults)", there is no need anymore to load these values
through the NVRAM after we discovered that we had to re-initialize
it.
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 properties in /options are currently only populated from
the NVRAM common partition or if the user explicitely sets and
environment variable with "setenv". This causes two problems:
1) The properties in /options are not reset when the user runs
the "set-defaults" Forth word, e.g. like this:
setenv auto-boot? false
dev /options
printenv auto-boot?
s" auto-boot?" get-node get-property drop type
set-defaults
printenv auto-boot?
s" auto-boot?" get-node get-property drop type
After the "set-defaults", the property in /options has the
wrong value and is not in sync with the environment variable
anymore.
2) If the common NVRAM partition is not containing all the
required variables, SLOF currently also does not create
default values in /options for the missing entries. This
causes problems for example when we want to initialize the
NVRAM from QEMU instead (to support the "-prom-env" parameter
of QEMU). Boot loaders like grub2 depend on the availability
of certain properties in the /options node and thus refuse
to work if the NVRAM did not contain all the variables.
To fix both issues, let's always populate the /options
properties during "(set-default)" already.
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 ".context" function is just a colorful, but otherwise useless
and unused wrapper around "context @", so this can be removed
safely. Also the .ansi-* functions are way too fancy for just
colorizing the output of the debug function ".wordlist" in a
different color than the default one, so remove these .ansi-*
functions, too.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
SLOF does not use the obsolete "READ (6)" SCSI command, and
according to the comment in front of the "scsi-build-read?"
Forth word, it is even not supported by a couple of devices
anymore, so we do not need to keep the code for this command
in our SLOF sources around.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
When a secondary boot loader like Yaboot tries to load additional files
like the kernel image via TFTP, SLOF internally started the net-snk as a
second client to do the TFTP transfer. So there were suddenly two clients
using the Open Firmware client interface at the same time. Thus the
obp-tftp code had to save the client interface registers from yaboot
before jumping into the net-snk client, and restore them afterwards.
Since we're now not using net-snk for the network loading anymore, we
also don't need to buffer the register contents of the client anymore.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
There is no need anymore to pass most of the arguments as
strings, we can use integers and pointers now instead.
While we're at it, change the maximum TFTP packet block size
in obp-tftp.fs from 1432 to 1428, since this is the correct
value (with 1432, there might be problems with networking
over VLANs). The code in tftp.c forces this value to 1428
anyway (see the MAX_BLOCKSIZE constant there), so this change
is just cosmetical, and should not change the behavior of
the TFTP loading process.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Now that we do not link libnet against net-snk anymore, we can
change the prototype of ping() and thus simplify the "net-ping"
Forth-to-C wrapper. There is no need to convert the parameters
to a temporary argv[] array anymore.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Now that we link libnet to Paflof, we can call the ping
function there directly instead of using the one from
net-snk. We add a similar Forth-to-C wrapper like it has
already been done for netboot() - simplification and clean-up
will be done in a later patch once we do not link against
net-snk anymore.
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>
For disks bigger than 2TB(512B sector size), read-10 would fail as it is
limited by the block address(4bytes). Add and use SCSI command READ(16)
when max blocks is more than 0xFFFFFFFF.
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>
For disks bigger than 2TB(512B sector size), read-capacity-10 would fail
and return FFFFFFFF, as it only has 4byte block address field. Detect
this and use read-capacity-16 which returns 8byte block address.
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>
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>
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>
It would put the pointer and len in the wrong order in the instance>args
buffer. As alloc-mem can handle zero length itself (and return NULL),
this also removes "if" to make the code simpler.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[aik: removed "if" as Segher suggested; removed pipe from comment as Thomas suggested]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
On FAT32, the directory entry contains a new field providing the
top 16-bits of the cluster number. We didn't use it, thus reading
the wrong sectors when trying to access files or directories
beyond block 0x10000.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
[aik: removed unrelated empty lines]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
When hitting F12 during boot multiple times (to make sure that you get
to the boot menu), it is sometimes impossible to select a menu entry
from the boot list - you always get the output "Invalid choice!" and
are dropped to the SLOF prompt.
The "boot-start" function already has some code at the beginning to
flush the keyboard input to get rid of multiple F12 keys. But if you
accidentially press F12 again after that code has been executed,
the code that checks the input for the selected boot menu entry
can not handle it and gets confused.
Fix this issue by flushing the keyboard input queue as late as possible
(i.e. after printing the boot menu items, since that could also take
a short while when the list is long and when using slow VGA text
output), and by ignoring all key sequences that start with an ESC
(like the F12 key ESC sequence) in the main keyboard input loop there.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
When I tried to abort the net-snk TFTP boot by pressing ESC
a couple of times, I sometimes noticed that SLOF ended up
with a negative stack depth counter. After doing some closer
investigation, I disovered that the problem can be reproduced
by simply pressing "ESC ESC RETURN" at the SLOF prompt.
The problem is in the code in accept.fs: If an ESC character is
found in the input stream, the "handle-ESC" function is called.
This reads in the next input character with "key", and if it
does not match 0x5b or 0x4f, it calls "handle-meta" for further
handling. handle-meta consumes the value from "key" on the stack
to use it as an index into a jump table, thus the stack is empty
now. If the index was a 0x1b (due to the second ESC character),
the function handle-CSI is called. But that function expects
another value as index for a jump table on the stack, and since
the stack was already empty, we end up with a negative stack
depth here.
Apparently, handle-meta should call a function instead that
uses "key" to get another character from the input stream,
before calling the handle-CSI function.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Tested-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The current ping command does not take netmask as argument, updated the
ping command to take "client-ip/nn" format ip address.
Add routine to return netmask(class based), when not provided by user.
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 old netflash code is not available in the net-snk anymore,
so it does not make sense to keep the Forth wrapper around.
Anyway, "update-flash -f net:..." can be used nowadays 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>
These words were required in the very early days of SLOF when
"boot net" / "load net" was not working yet. Nowadays, they
are pretty useless and thus can be removed.
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>
These functions are only used by some ancient js2x code,
so move them to that folder accordingly.
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 huge-tftp-load variable is only needed by the obp-tftp
package, so it should reside there, not in base.fs
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>
These functions were only used by the SMS code that has been
removed already a while ago. It does not make sense anymore
to parse them during each boot, and even if we'd still need
them, they should not reside in base.fs. Since we're currently
do not need them anymore, let's simply remove them completely.
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>
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>
Since slof/fs/dma-function.fs has been introduced for board-qemu,
these function definitions shadow the original js2x functions from
slof/fs/pci-config-bridge.fs, because dma-functions.fs is included
after pci-config-bridge.fs in slof/fs/pci-bridge.fs.
To restore the original behavior, move the js2x functions into
a board-specific dma-function.fs file instead and include that
one into the ROM-fs instead of the version for board-qemu.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The "hv-cas" hypercall is only available on board-qemu.
Including archsupport.fs on board-js2x breaks the boot
process there. Thus the archsupport.fs file should
reside in the board-qemu/slof directory instead and
only be included from there.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
QEMU when started with "-boot strict=on", appends "HALT" at the end of
the bootlist. Handle this in the boot order.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The maximum number of root directory entries can be zero on
certain FAT32 file systems. In this case, we've got to read
the cluster number of the root directory from the extended BPB
instead. See also the following URL for details:
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#BPB20_OFS_06h
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
If the devices beyond the bridge requests 64-bit mem
current code does not correctly program the bridge range properties.
64-bit prefetchable memory region is tracked by
pci-[next,max]-mem64. Use these to program the
pci bridge range registers.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
By implementing RFILL as an primitive, we can get a huge
speed-up of the screen erasing function. On board-js2x,
it writes the pattern directly into the IO region, and on
board-qemu it uses the KVMPPC_H_LOGICAL_MEMOP hypercall to
copy the pattern from a temporary buffer into the IO region.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The character drawing function fb8-draw-character uses "mrmove"
(which moves main memory contents to IO memory) to copy the data
of the character from main memory to the frame buffer. However,
the current implementation of "mrmove" performs quite badly on
board-qemu since it triggers a hypercall for each memory access
(e.g. for each 8 bytes that are transfered).
But since the KVMPPC_H_LOGICAL_MEMOP hypercall can transfer bigger
regions at once, we can accelerate the character drawing quite a
bit by simply mapping the "mrmove" to the same macro that is
already used for the "rmove" (which is normally only used for
copying from IO memory to IO memory, but on board-qemu it does
not matter). For keeping board-js2x in sync, this patch also
transforms the "mrmove" for js2x into primitives.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The framebuffer code calculates the length of a line in bytes over
and over again, even in the tight innermost loops of the drawing
functions. We can easily avoid this multiplication and make the
code more readable by storing this value in a variable 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>
The terminal-write function has a built-in trace buffer feature
which is currently always enabled. Since this is only needed
for debugging, let's disable this feature by default. It can
easily be enabled again by typing "true to twtrace-enabled?"
at the Forth prompt.
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>
IEEE1275 - "Standard for Boot", section 6.3.2.5:
Implements "boot" client interface which will store the bootspec
passed by the client and resets the system. The system comes
back with the settings specified in bootspec.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Thomas Huth