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>
The code in close for calling quiesce looks if there is stdin and
checks whether is being closed. That condition was being used to call
quiesce.
So in case when the ihandle is not that of stdin, close-dev was missing.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
As per 1275 standard, canon converts the possibly ambiguous
device-specifier to a fully qualified pathname (see 6.3.2.2). It is kind
of find-alias for clients. Earlier canon implementation was not complete,
it was not at all returning the full path name. So grub was not getting
the alias path by calling canon and it was breaking.
In this patch I'm checking if the passed string is already a full path
by comparing the first character with '/'. In that case I return the
passed string as is. Otherwise I return the find-alias.
Signed-off-by: Avik Sil <aviksil@linux.vnet.ibm.com>
Reviewed-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
As quiesce is not a standard interface which is not what everybody
supports. Now make quiesce call when the stdin is closed. This makes
sure that the inteface is call always and is not dependent on OS
calling quiesce.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Acked-by: Thomas Huth <thuth@linux.vnet.ibm.com>
grub2 is bogus, it looks for "/memory" to check for available
memory. On a system with multiple memory nodes that might return
anything and not necessarily the RMA node which is the only one
usable in real mode.
This adds a hack to the client interface code which transforms
any request for "/memory" to explicitly look for "/memory@0"
which returns the RMA node.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To analyze the behavior and requirements of boot loaders and OS clients, it's
crucial to know which properties they try to read from our device tree. Thus
we need the possibility to debug the "getprop" client interface call.
Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
"test" was removing the wrong stack items, so the first stack item beyond
its parameters got corrupted.
Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Nikunj A Dadhania