On network boots grub_ieee1275_net_config() is used to determine the
boot device but the path continues to be taken from the Open Firmware
/chosen/bootpath property. This assumes the device node follows the
generic IEEE 1275 syntax which is not always the case. Different drivers
may extend or redefine the format and GRUB may then misinterpret the
argument as a filename and set $prefix incorrectly.
The generic Open Firmware device path format is:
device-name[:device-argument]
device-argument := [partition][,[filename]]
For example, a bootpath such as:
/vdevice/l-lan@30000002:speed=auto,duplex=auto,1.2.243.345,,9.8.76.543,1.2.34.5,5,5,255.255.255.0,512
does not follow this form. The section after the colon (the device-argument)
contains driver-specific options and network parameters, not a valid filename.
The GRUB interprets this string as a filename which results in $prefix being
set to "/", effectively losing the intended boot directory.
The firmware is not at fault here since interpretation of device nodes
is driver-specific. Instead, GRUB should use the filename provided in
the cached DHCP packet which is consistent and reliable. This is also
the same mechanism already used on UEFI and legacy BIOS platforms.
This patch updates grub_machine_get_bootlocation() to prefer the result
from grub_ieee1275_net_config() when complete and only fall back to the
firmware bootpath otherwise.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Enhancing the infrastructure to enable the Platform Keystore (PKS) feature,
which provides access to the SB_VERSION, db, and dbx secure boot variables
from PKS.
If PKS is enabled, it will read secure boot variables such as db and dbx
from PKS and extract EFI Signature List (ESL) from it. The ESLs would be
saved in the Platform Keystore buffer, and the appendedsig module would
read it later to extract the certificate's details from ESL.
In the following scenarios, static key management mode will be activated:
1. When Secure Boot is enabled with static key management mode
2. When SB_VERSION is unavailable but Secure Boot is enabled
3. When PKS support is unavailable but Secure Boot is enabled
Note:
SB_VERSION: Key Management Mode
1 - Enable dynamic key management mode. Read the db and dbx variables from PKS,
and use them for signature verification.
0 - Enable static key management mode. Read keys from the GRUB ELF Note and
use it for signature verification.
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Read secure boot mode from 'ibm,secure-boot' property and if the secure boot
mode is set to 2 (enforce), enter lockdown. Else it is considered as disabled.
There are three secure boot modes. They are
0 - disabled
No signature verification is performed. This is the default.
1 - audit
Signature verification is performed and if signature verification fails,
display the errors and allow the boot to continue.
2 - enforce
Lockdown the GRUB. Signature verification is performed and if signature
verification fails, display the errors and stop the boot.
Now, only support disabled and enforce.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Change RMA size from 512 MB to 768 MB which will result in more memory
at boot time for PowerPC. When vTPM, Secure Boot or FADump are enabled
on PowerPC the 512 MB RMA memory is not sufficient for boot. With this
512 MB RMA, GRUB runs out of memory and fails to boot the machine.
Sometimes even usage of CDROM requires more memory for installation and
along with the options mentioned above exhausts the boot memory which
results in boot failures. Increasing the RMA size will resolves multiple
out of memory issues observed on PowerPC machines.
Failure details (GRUB debug console dump):
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 1
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum runtime space
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 0
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum runtime space
kern/file.c:215: Closing `/ppc/ppc64/initrd.img' ...
kern/disk.c:297: Closing `ieee1275//vdevice/v-scsi@30000067/disk@8300000000000000'...
kern/disk.c:311: Closing `ieee1275//vdevice/v-scsi@30000067/disk@8300000000000000' succeeded.
kern/file.c:225: Closing `/ppc/ppc64/initrd.img' failed with 3.
kern/file.c:148: Opening `/ppc/ppc64/initrd.img' succeeded.
error: ../../grub-core/kern/mm.c:552:out of memory.
Signed-off-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds support for Radix, Xive and Radix_gtse in Options
vector5 which is required for KVM LPARs. KVM LPARs ONLY support
Radix and not the Hash. Not enabling Radix on any PowerVM KVM LPARs
will result in boot failure.
Signed-off-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Display upper_mem_limit and its rounded-down value in MiB.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename regions_claim() to grub_regions_claim() to make it available for
memory allocation. The ieee1275 loader will use this function on PowerVM
and KVM on Power and thus avoid usage of memory that it is not allowed
to use.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Add support for memory alignment requirements and adjust a candidate
address to it before checking whether the block is large enough. This
must be done in this order since the alignment adjustment can make
a block smaller than what was requested.
None of the current callers has memory alignment requirements but the
ieee1275 loader for kernel and initrd will use it to convey them.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Return the allocated address of the memory block in the request structure
if a memory allocation was actually done. Leave the address untouched
otherwise. This enables a caller who wants to use the allocated memory
directly, rather than adding the memory to the heap, to see where memory
was allocated. None of the current callers need this but the converted
ieee1275 loader will make use of it.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Let the regions_claim() request structure's init_region determine whether
to call grub_mm_init_region() on it. This allows for adding memory to
GRUB's memory heap if init_region is set to true, or direct usage of the
memory otherwise. Set all current callers' init_region to true since they
want to add memory regions to GRUB's heap.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
The regions_claim() function limits the allocation of memory regions
by excluding certain memory areas from being used by GRUB. This for
example includes a gap between 640MB and 768MB as well as an upper
limit beyond which no memory may be used when an fadump is present.
However, the ieee1275 loader for kernel and initrd currently does not
use regions_claim() for memory allocation on PowerVM and KVM on Power
and therefore may allocate memory in those areas that it should not use.
To make the regions_claim() function more flexible and ultimately usable
for the ieee1275 loader, introduce a request structure to pass various
parameters to the regions_claim() function that describe the properties
of requested memory chunks. In a first step, move the total and flags
variables into this structure.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
When a kernel dump is present then restrict the high memory regions to
avoid allocating memory where the kernel dump resides. Use the
ibm,kernel-dump node under /rtas to determine whether a kernel dump
exists and up to which limit GRUB can use available memory. Set the
upper_mem_limit to the size of the kernel dump section of type
REAL_MODE_REGION and therefore only allow GRUB's memory usage for high
addresses from RMO_ADDR_MAX to upper_mem_limit. This means that GRUB can
use high memory in the range of RMO_ADDR_MAX (768MB) to upper_mem_limit
and the kernel-dump memory regions above upper_mem_limit remain
untouched. This change has no effect on memory allocations below
linux_rmo_save (typically at 640MB).
Also, fall back to allocating below rmo_linux_save in case the chunk of
memory there would be larger than the chunk of memory above RMO_ADDR_MAX.
This can for example occur if a free memory area is found starting at 300MB
extending up to 1GB but a kernel dump is located at 768MB and therefore
does not allow the allocation of the high memory area but requiring to use
the chunk starting at 300MB to avoid an unnecessary out-of-memory condition.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch enables multiple options in Vec5 which are required and
solves the boot issues seen on some machines which are looking for
these specific options.
1. LPAR: Client program supports logical partitioning and
associated hcall()s.
2. SPLPAR: Client program supports the Shared
Processor LPAR Option.
3. DYN_RCON_MEM: Client program supports the
“ibm,dynamic-reconfiguration-memory” property and it may be
presented in the device tree.
4. LARGE_PAGES: Client supports pages larger than 4 KB.
5. DONATE_DCPU_CLS: Client supports donating dedicated processor cycles.
6. PCI_EXP: Client supports PCI Express implementations
utilizing Message Signaled Interrupts (MSIs).
7. CMOC: Enables the Cooperative Memory Over-commitment Option.
8. EXT_CMO: Enables the Extended Cooperative Memory Over-commit Option.
9. ASSOC_REF: Enables “ibm,associativity” and
“ibm,associativity-reference-points” properties.
10. AFFINITY: Enables Platform Resource Reassignment Notification.
11. NUMA: Supports NUMA Distance Lookup Table Option.
12. HOTPLUG_INTRPT: Supports Hotplug Interrupts.
13. HPT_RESIZE: Enable Hash Page Table Resize Option.
14. MAX_CPU: Defines maximum number of CPUs supported.
15. PFO_HWRNG: Supports Random Number Generator.
16. PFO_HW_COMP: Supports Compression Engine.
17. PFO_ENCRYPT: Supports Encryption Engine.
18. SUB_PROCESSORS: Supports Sub-Processors.
19. DY_MEM_V2: Client program supports the “ibm,dynamic-memory-v2” property in the
“ibm,dynamic-reconfiguration-memory” node and it may be presented in the device tree.
20. DRC_INFO: Client program supports the “ibm,drc-info” property definition and it may be
presented in the device tree.
Signed-off-by: Avnish Chouhan <avnish@linux.vnet.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch converts the plain numbers used in Vec5 properties to constants.
1. LPAR: Client program supports logical partitioning and
associated hcall()s.
2. SPLPAR: Client program supports the Shared
Processor LPAR Option.
3. CMO: Enables the Cooperative Memory Over-commitment Option.
4. MAX_CPU: Defines maximum number of CPUs supported.
Signed-off-by: Avnish Chouhan <avnish@linux.vnet.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
As a legacy support, if the vector 5 is not implemented, Power Hypervisor will
consider the max CPUs as 64 instead 256 currently supported during
client-architecture-support negotiation.
This patch implements the vector 5 and set the MAX CPUs to 256 while setting the
others values to 0 (default).
Signed-off-by: Diego Domingos <diegodo@linux.vnet.ibm.com>
Acked-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Avnish Chouhan <avnish@linux.vnet.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On powerpc-ieee1275, we are running out of memory trying to verify
anything. This is because:
- we have to load an entire file into memory to verify it. This is
difficult to change with appended signatures.
- We only have 32MB of heap.
- Distro kernels are now often around 30MB.
So we want to be able to claim more memory from OpenFirmware for our heap
at runtime.
There are some complications:
- The grub mm code isn't the only thing that will make claims on
memory from OpenFirmware:
* PFW/SLOF will have claimed some for their own use.
* The ieee1275 loader will try to find other bits of memory that we
haven't claimed to place the kernel and initrd when we go to boot.
* Once we load Linux, it will also try to claim memory. It claims
memory without any reference to /memory/available, it just starts
at min(top of RMO, 768MB) and works down. So we need to avoid this
area. See arch/powerpc/kernel/prom_init.c as of v5.11.
- The smallest amount of memory a ppc64 KVM guest can have is 256MB.
It doesn't work with distro kernels but can work with custom kernels.
We should maintain support for that. (ppc32 can boot with even less,
and we shouldn't break that either.)
- Even if a VM has more memory, the memory OpenFirmware makes available
as Real Memory Area can be restricted. Even with our CAS work, an LPAR
on a PowerVM box is likely to have only 512MB available to OpenFirmware
even if it has many gigabytes of memory allocated.
What should we do?
We don't know in advance how big the kernel and initrd are going to be,
which makes figuring out how much memory we can take a bit tricky.
To figure out how much memory we should leave unused, I looked at:
- an Ubuntu 20.04.1 ppc64le pseries KVM guest:
vmlinux: ~30MB
initrd: ~50MB
- a RHEL8.2 ppc64le pseries KVM guest:
vmlinux: ~30MB
initrd: ~30MB
So to give us a little wriggle room, I think we want to leave at least
128MB for the loader to put vmlinux and initrd in memory and leave Linux
with space to satisfy its early allocations.
Allow other space to be allocated at runtime.
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This was apparently "required by some firmware": commit dc9468500919
(2007-02-12 Hollis Blanchard <hollis@penguinppc.org>).
It's not clear what firmware that was, and what platform from 14 years ago
which exhibited the bug then is still both in use and buggy now.
It doesn't cause issues on qemu (mac99 or pseries) or under PFW for Power8.
I don't have access to old Mac hardware, but if anyone feels especially
strongly we can put it under some feature flag. I really want to disable
it under pseries because it will mess with region merging.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
On PowerVM, the first time we boot a Linux partition, we may only get
256MB of real memory area, even if the partition has more memory.
This isn't enough to reliably verify a kernel. Fortunately, the Power
Architecture Platform Reference (PAPR) defines a method we can call to ask
for more memory: the broad and powerful ibm,client-architecture-support
(CAS) method.
CAS can do an enormous amount of things on a PAPR platform: as well as
asking for memory, you can set the supported processor level, the interrupt
controller, hash vs radix mmu, and so on.
If:
- we are running under what we think is PowerVM (compatible property of /
begins with "IBM"), and
- the full amount of RMA is less than 512MB (as determined by the reg
property of /memory)
then call CAS as follows: (refer to the Linux on Power Architecture
Reference, LoPAR, which is public, at B.5.2.3):
- Use the "any" PVR value and supply 2 option vectors.
- Set option vector 1 (PowerPC Server Processor Architecture Level)
to "ignore".
- Set option vector 2 with default or Linux-like options, including a
min-rma-size of 512MB.
- Set option vector 3 to request Floating Point, VMX and Decimal Floating
point, but don't abort the boot if we can't get them.
- Set option vector 4 to request a minimum VP percentage to 1%, which is
what Linux requests, and is below the default of 10%. Without this,
some systems with very large or very small configurations fail to boot.
This will cause a CAS reboot and the partition will restart with 512MB
of RMA. Importantly, grub will notice the 512MB and not call CAS again.
Notes about the choices of parameters:
- A partition can be configured with only 256MB of memory, which would
mean this request couldn't be satisfied, but PFW refuses to load with
only 256MB of memory, so it's a bit moot. SLOF will run fine with 256MB,
but we will never call CAS under qemu/SLOF because /compatible won't
begin with "IBM".)
- unspecified CAS vectors take on default values. Some of these values
might restrict the ability of certain hardware configurations to boot.
This is why we need to specify the VP percentage in vector 4, which is
in turn why we need to specify vector 3.
Finally, we should have enough memory to verify a kernel, and we will
reach Linux. One of the first things Linux does while still running under
OpenFirmware is to call CAS with a much fuller set of options (including
asking for 512MB of memory). Linux includes a much more restrictive set of
PVR values and processor support levels, and this CAS invocation will likely
induce another reboot. On this reboot grub will again notice the higher RMA,
and not call CAS. We will get to Linux again, Linux will call CAS again, but
because the values are now set for Linux this will not induce another CAS
reboot and we will finally boot all the way to userspace.
On all subsequent boots, everything will be configured with 512MB of RMA,
so there will be no further CAS reboots from grub. (phyp is super sticky
with the RMA size - it persists even on cold boots. So if you've ever booted
Linux in a partition, you'll probably never have grub call CAS. It'll only
ever fire the first time a partition loads grub, or if you deliberately lower
the amount of memory your partition has below 512MB.)
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Open Hack'Ware was the only user. It added a lot of complexity.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The HEAP_MAX_ADDR is confusing. Currently it is set to 32MB, except on
ieee1275 on x86, where it is 64MB.
There is a comment which purports to explain it:
/* If possible, we will avoid claiming heap above this address, because it
seems to cause relocation problems with OSes that link at 4 MiB */
This doesn't make a lot of sense when the constants are well above 4MB
already. It was not always this way. Prior to commit 7b5d0fe4440c
(Increase heap limit) in 2010, HEAP_MAX_SIZE and HEAP_MAX_ADDR were
indeed 4MB. However, when the constants were increased the comment was
left unchanged.
It's been over a decade. It doesn't seem like we have problems with
claims over 4MB on powerpc or x86 ieee1275. The SPARC does things
completely differently and never used the constant.
Drop the constant and the check.
The only use of HEAP_MIN_SIZE was to potentially override the
HEAP_MAX_ADDR check. It is now unused. Remove it too.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add a new disk driver called obdisk for IEEE1275 platforms. Currently
the only platform using this disk driver is SPARC, however other IEEE1275
platforms could start using it if they so choose. While the functionality
within the current IEEE1275 ofdisk driver may be suitable for PPC and x86, it
presented too many problems on SPARC hardware.
Within the old ofdisk, there is not a way to determine the true canonical
name for the disk. Within Open Boot, the same disk can have multiple names
but all reference the same disk. For example the same disk can be referenced
by its SAS WWN, using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@w5000cca02f037d6d,0
It can also be referenced by its PHY identifier using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@p0
It can also be referenced by its Target identifier using this form:
/pci@302/pci@2/pci@0/pci@17/LSI,sas@0/disk@0
Also, when the LUN=0, it is legal to omit the ,0 from the device name. So with
the disk above, before taking into account the device aliases, there are 6 ways
to reference the same disk.
Then it is possible to have 0 .. n device aliases all representing the same disk.
Within this new driver the true canonical name is determined using the the
IEEE1275 encode-unit and decode-unit commands when address_cells == 4. This
will determine the true single canonical name for the device so multiple ihandles
are not opened for the same device. This is what frequently happens with the old
ofdisk driver. With some devices when they are opened multiple times it causes
the entire system to hang.
Another problem solved with this driver is devices that do not have a device
alias can be booted and used within GRUB. Within the old ofdisk, this was not
possible, unless it was the original boot device. All devices behind a SAS
or SCSI parent can be found. Within the old ofdisk, finding these disks
relied on there being an alias defined. The alias requirement is not
necessary with this new driver. It can also find devices behind a parent
after they have been hot-plugged. This is something that is not possible
with the old ofdisk driver.
The old ofdisk driver also incorrectly assumes that the device pointing to by a
device alias is in its true canonical form. This assumption is never made with
this new driver.
Another issue solved with this driver is that it properly caches the ihandle
for all open devices. The old ofdisk tries to do this by caching the last
opened ihandle. However this does not work properly because the layer above
does not use a consistent device name for the same disk when calling into the
driver. This is because the upper layer uses the bootpath value returned within
/chosen, other times it uses the device alias, and other times it uses the
value within grub.cfg. It does not have a way to figure out that these devices
are the same disk. This is not a problem with this new driver.
Due to the way GRUB repeatedly opens and closes the same disk. Caching the
ihandle is important on SPARC. Without caching, some SAS devices can take
15 - 20 minutes to get to the GRUB menu. This ihandle caching is not possible
without correctly having the canonical disk name.
When available, this driver also tries to use the deblocker #blocks and
a way of determining the disk size.
Finally and probably most importantly, this new driver is also capable of
seeing all partitions on a GPT disk. With the old driver, the GPT
partition table can not be read and only the first partition on the disk
can be seen.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Read from NULL pointer canon in function grub_machine_get_bootlocation().
Function grub_ieee1275_canonicalise_devname() may return NULL.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Split up some of the functionality in grub_machine_get_bootlocation into
grub_ieee1275_get_boot_dev. This will allow for code reuse in a follow on
patch.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It enables net boot even when there is no bootp/dhcp server.
* grub-core/net/drivers/ieee1275/ofnet.c: Add grub_ieee1275_parse_bootpath and
call it at grub_ieee1275_net_config_real.
* grub-core/kern/ieee1275/init.c: Add bootpath to grub_ieee1275_net_config.
* include/grub/ieee1275/ieee1275.h: Likewise.
