aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-07-07libnet: Move the external declaration of send_ip to ethernet.hThomas Huth3-4/+3
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>
2017-07-07libc: Declare size_t as unsigned longThomas Huth1-2/+1
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>
2017-06-30libnet/netload: Three more minor clean-upsThomas Huth1-12/+13
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>
2017-06-30libnet/tftp: Allow loading to address 0Thomas Huth1-5/+6
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>
2017-06-28libnet: Refactor some code of netload() into a separate functionThomas Huth1-83/+94
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>
2017-06-28libnet: Rework error message printingThomas Huth1-82/+44
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>
2017-06-28libnet: Remove remainders of netsave codeThomas Huth3-13/+0
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>
2017-06-28lib/Makefile: Pass FLAG to make in SUBDIRS targetMurilo Opsfelder Araujo2-2/+2
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>
2017-06-28virtio-net: Fix ugly error messageThomas Huth1-3/+4
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>
2017-06-15pci-phb: Set correct pci-bus-number while walking PCI bridgesThomas Huth1-0/+1
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>
2017-06-15libnet: Cosmetical clean-upThomas Huth3-14/+11
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>
2017-06-15paflof: Print stack warning to stderr, not stdoutThomas Huth1-1/+1
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>
2017-06-15libnet: Allocate ICMPv6 packet space on the heap, not on the stackThomas Huth1-4/+26
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>
2017-06-08A new SLOF boot menuThomas Huth9-67/+303
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>
2017-06-08libc: The arguments of puts() can be marked as "const"Thomas Huth2-2/+2
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>
2017-06-07Increase MAX-ALIAS to 10Thomas Huth2-2/+1
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>
2017-06-06Use TYPE for the standard output instead of io_putchar()Thomas Huth2-7/+25
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>
2017-06-06pci: Remove unused next-pci-[mem|mmio|io] functionsThomas Huth2-8/+1
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>
2017-05-16pci: Reserve free space at the end of bridge windows instead of at the beginningThomas Huth1-6/+9
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>
2017-04-28pci: Generate a 64-bit range property if necessaryThomas Huth1-2/+3
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>
2017-04-28pci: Fix assigned-addresses for 64bit nonprefetchable BARAlexey Kardashevskiy1-2/+4
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>
2017-04-28pci-phb: Set pci-max-mem64 to the correct valueThomas Huth1-3/+3
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>
2017-04-26Rework the printing of the banner during bootThomas Huth3-3/+12
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>
2017-04-26bootmsg: Fix message for detected kernelAlexey Kardashevskiy1-1/+1
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>
2017-04-26logo: Update the logoAlexey Kardashevskiy5-34/+3
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>
2017-04-26pci: Put non-prefetchable 64bit BARs into 32bit MMIO windowAlexey Kardashevskiy1-5/+1
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.
2017-04-06Fix "Unsupported PQ" problems in the scsi-disk open functionThomas Huth1-2/+6
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>
2017-03-09pci: force minimum mem bar alignment of 64K for board-qemuMichael Roth4-8/+40
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>
2017-03-03version: update to 20170303qemu-slof-20170303Alexey Kardashevskiy1-1/+1
This is aimed to go to QEMU v2.9. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-03-03qemu-bootlist: Take the "-boot strict=off" setting properly into accountThomas Huth1-4/+14
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>
2017-02-06virtio-scsi: initialize vring avail queue buffersLaurent Vivier2-34/+15
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>
2017-02-03virtio: Remove global variables in block and 9p driverThomas Huth2-12/+6
No need for a global variable to store the virtqueue information here, thus let's remove the global vq variable and make it local to the init function instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2016-12-20Remove superfluous checkpoints in tree.fsThomas Huth1-16/+0
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>
2016-11-24Provide "write" function in the disk-label packageThomas Huth1-0/+5
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>
2016-11-24virtio: Implement block write supportThomas Huth5-14/+41
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>
2016-11-24scsi: Add SCSI block write supportThomas Huth2-0/+96
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>
2016-11-24deblocker: Add a 'write' functionThomas Huth1-0/+21
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>
2016-11-24virtio-scsi: Fix descriptor order for SCSI WRITE commandsThomas Huth1-5/+14
Virtio needs the descriptors ordered: All descriptors for buffers that contain data that should go *to* the device have to be put into the queue first. The descriptors for buffers that read *from* the device have to be sorted in last. For SCSI WRITE commands (which we never used in the past), the order was wrong, so QEMU complains with a "Incorrect order for descriptors" message as soon as we use it for SCSI WRITE commands. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2016-11-14board-qemu: Add a possibility to use hvterm input instead of USB keyboardThomas Huth1-3/+10
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>
2016-11-14Do not try to use virtio-gpu in VGA modeThomas Huth1-2/+10
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>
2016-11-10virtio: Fix stack comment of virtio-blk-readThomas Huth1-1/+1
The real parameters differ from the current stack comment. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2016-10-27envvar: Do not read default values for /options from the NVRAM anymoreThomas Huth1-1/+1
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>
2016-10-27envvar: Set properties in /options during "(set-defaults)"Thomas Huth1-6/+10
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>
2016-10-19version: update to 20161019qemu-slof-20161019Alexey Kardashevskiy1-1/+1
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2016-10-19virtio-serial: Fix compile errorAlexey Kardashevskiy1-1/+2
This stops using C99 declaration which breaks compile on gcc 4.8. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Tested-by: Thomas Huth <thuth@redhat.com>
2016-10-17scsi: Remove debug functions from scsi-loader.fsThomas Huth1-27/+0
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>
2016-10-17scsi: Remove unused read-6 commandThomas Huth1-50/+0
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>
2016-10-17obp-tftp: Remove the ciregs-bufferThomas Huth1-11/+0
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>
2016-10-17libnet: Simplify the net-load arguments passingThomas Huth4-35/+27
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>
2016-10-17libnet: Simplify the Forth-to-C wrapper of ping()Thomas Huth4-26/+16
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>
generated by cgit v1.1 at 2025-09-20 13:47:28 +0000