Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit 0ba90a7f01 ("efi: Move grub_reboot() into kernel") broke
the build on i386-efi - genmoddep.awk bails out with message
grub_reboot in reboot is duplicated in kernel
This is because both lib/i386/reset.c and kern/efi/efi.c now provide
this function.
Rather than explicitly list each i386 platform variant in
Makefile.core.def, include the contents of lib/i386/reset.c only when
GRUB_MACHINE_EFI is not set.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The 32-bit arm Linux kernel is built as a zImage, which self-decompresses
down to near start of RAM. In order for an initrd/initramfs to be
accessible, it needs to be placed within the first ~768MB of RAM.
The initrd loader built into the kernel EFI stub restricts this down to
512MB for simplicity - so enable the same restriction in grub.
For arm64, the requirement is within a 1GB aligned 32GB window also
covering the (runtime) kernel image. Since the EFI stub loader itself
will attempt to relocate to near start of RAM, force initrd to be loaded
completely within the first 32GB of RAM.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The 32-bit arm efi port now shares the 64-bit linux loader, so delete
the now unused bits from the 32-bit linux loader.
This in turn leaves the grub-core/kern/arm/efi/misc.c unused, so
delete that too.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The arm64 and arm linux kernel EFI-stub support presents pretty much
identical interfaces, so the same linux loader source can be used for
both architectures.
Switch 32-bit ARM UEFI platforms over to the existing EFI-stub aware
loader initially developed for arm64.
This *WILL* stop non-efistub Linux kernels from booting on arm-efi.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In preparation for using the linux loader for 32-bit and 64-bit platforms,
rename grub_arm64*/GRUB_ARM64* to grub_armxx*/GRUB_ARMXX*.
Move prototypes for now-common functions to efi/efi.h.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since ARM platforms do not have a common memory map, add a helper
function that finds the lowest address region with the EFI_MEMORY_WB
attribute set in the UEFI memory map.
Required for the arm64 efi linux loader to restrict the initrd
location to where it will be accessible by the kernel at runtime.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There are several implementations of this function in the tree.
Add a central version in grub-core/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI Graphics Output Protocol can return a 64-bit
linear frame buffer address in some firmware/BIOS
implementations. We currently only store the lower
32-bits in the lfb_base. This will eventually be
passed to Linux kernel and the efifb driver will
incorrectly interpret the framebuffer address as
32-bit address.
The Linux kernel has already added support to handle
64-bit linear framebuffer address in the efifb driver
since quite some time now.
This patch adds the support for 64-bit linear frame
buffer address in GRUB to address the above mentioned
scenario.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Clean up code for matching IS_ARM64 slightly by making use of struct
linux_arm64_kernel_header and GRUB_LINUX_ARM64_MAGIC_SIGNATURE.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Clean up code for matching IS_ARM slightly by making use of struct
linux_arm_kernel_header and GRUB_LINUX_ARM_MAGIC_SIGNATURE.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Most 8" or 7" x86 Windows 10 tablets come with volume up/down buttons and
a power-button. In their UEFI these are almost always mapped to arrow
up/down and enter.
Pressing the volume buttons (sometimes by accident) will stop the
menu countdown, but the power-button / "enter" key was not being recognized
as enter, so the user would be stuck at the grub menu.
The problem is that these tablets send scan_code 13 or 0x0d for the
power-button, which officialy maps to the F3 key. They also set
unicode_char to 0x0d.
This commit recognizes the special case of both scan_code and unicode_char
being set to 0x0d and treats this as an enter key press.
This fixes things getting stuck at the grub-menu and allows the user
to choice a grub-menu entry using the buttons on the tablet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without that fix we have:
In file included from ../../include/grub/command.h:25:0,
from ../../grub-core/loader/multiboot.c:30:
../../grub-core/loader/multiboot_elfxx.c: In function 'grub_multiboot_load_elf64':
../../grub-core/loader/multiboot_elfxx.c:130:28: error: 'relocatable' undeclared (first use in this function)
"load_base_addr=0x%x\n", relocatable,
This happens due to mistake in the commit 14ec665
(mbi: Use per segment a separate relocator chunk).
So, let's fix it.
Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
When booting an arm* system on UEFI with an empty device tree (currently
only when hardware description comes from ACPI), we don't currently set
default to 1 cell (32 bits).
Set both of these properties, to 2 cells (64 bits), to resolve issues
with kexec on some platforms.
This change corresponds with linux kernel commit ae8a442dfdc4
("efi/libstub/arm*: Set default address and size cells values for an empty dtb")
and ensures booting through grub does not behave differently from booting
the stub loader directly.
See also https://patchwork.kernel.org/patch/9561201/
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To be able to resuse the prop_entry_size macro, move it to
<grub/fdt.h> and rename it grub_fdt_prop_entry_size.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Instead of setting up a all comprising relocator chunk for all segments,
use per segment a separate relocator chunk.
Currently, if the ELF is non-relocatable, a single relocator chunk will
comprise memory (between the segments) which gets overridden by the relst()
invocation of the movers code in grub_relocator16/32/64_boot().
The overridden memory may contain reserved ranges like VGA memory or ACPI
tables, which may lead to crashes or at least to strange boot behaviour.
Signed-off-by: Alexander Boettcher <alexander.boettcher@genode-labs.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The sparse inode metadata format became a mkfs.xfs default in
xfsprogs-4.16.0, and such filesystems are now rejected by grub as
containing an incompatible feature.
In essence, this feature allows xfs to allocate inodes into fragmented
freespace. (Without this feature, if xfs could not allocate contiguous
space for 64 new inodes, inode creation would fail.)
In practice, the disk format change is restricted to the inode btree,
which as far as I can tell is not used by grub. If all you're doing
today is parsing a directory, reading an inode number, and converting
that inode number to a disk location, then ignoring this feature
should be fine, so I've added it to XFS_SB_FEAT_INCOMPAT_SUPPORTED
I did some brief testing of this patch by hacking up the regression
tests to completely fragment freespace on the test xfs filesystem, and
then write a large-ish number of inodes to consume any existing
contiguous 64-inode chunk. This way any files the grub tests add and
traverse would be in such a fragmented inode allocation. Tests passed,
but I'm not sure how to cleanly integrate that into the test harness.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Chris Murphy <lists@colorremedies.com>
This patch ensures that grub-probe will find the root device placed in
/dev/mapper/dm-[0-9]+-.* e.g. device named /dev/mapper/dm-0-luks will be
found and grub.cfg will be updated properly, enabling the system to boot.
Signed-off-by: Oleg Solovyov <mcpain@altlinux.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rounding up the bufio->block_size to meet power of 2 to facilitate next_buf
calculation in grub_bufio_read().
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename grub_gpt_part_type to grub_gpt_part_guid and update grub_gpt_partentry
to use this type for both the partition type GUID string and the partition GUID
string entries. This change ensures that the two GUID fields are handled more
consistently and helps to simplify the changes needed to add Linux partition
GUID support.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
diskboot.img now is loaded at 0x8000 and is jumped to with 0:0x8000.
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
"F2FS (Flash-Friendly File System) is flash-friendly file system which was merged
into Linux kernel v3.8 in 2013.
The motive for F2FS was to build a file system that from the start, takes into
account the characteristics of NAND flash memory-based storage devices (such as
solid-state disks, eMMC, and SD cards).
F2FS was designed on a basis of a log-structured file system approach, which
remedies some known issues of the older log structured file systems, such as
the snowball effect of wandering trees and high cleaning overhead. In addition,
since a NAND-based storage device shows different characteristics according to
its internal geometry or flash memory management scheme (such as the Flash
Translation Layer or FTL), it supports various parameters not only for
configuring on-disk layout, but also for selecting allocation and cleaning
algorithm.", quote by https://en.wikipedia.org/wiki/F2FS.
The source codes for F2FS are available from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.githttp://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git
This patch has been integrated in OpenMandriva Lx 3.
https://www.openmandriva.org/
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A GPU inserted into a PCIe I/O slot disappears during system startup.
The problem centers around GRUB and a specific VGA init function in
efi_uga.c. This causes an LER (Link Error Recorvery) because the MMIO
memory has not been enabled before attempting access.
The fix is to add the same coding used in other VGA drivers, specifically
to add a check to insure that it is indeed a VGA controller. And then
enable the MMIO address space with the specific bits.
Signed-off-by: Mike Travis <mike.travis@hpe.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>
These fields must reflect the ROM-BIOS's geometry for CHS-based
loaders to correctly load their next stage. Most loaders do not
query the ROM-BIOS (Int13.08), relying on the BPB fields to hold
the correct values already.
Tested with lDebug booted in qemu via grub2's
FreeDOS direct loading support, refer to
https://bitbucket.org/ecm/ldosboot + https://bitbucket.org/ecm/ldebug
(For this test, lDebug's iniload.asm must be assembled with
-D_QUERY_GEOMETRY=0 to leave the BPB values provided by grub.)
Signed-off-by: C. Masloch <pushbx@38.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Return the 64bit number of blocks of storage associated with the device or
instance. Where a "block" is a unit of storage consisting of the number of
bytes returned by the package's "block-size" method. If the size cannot be
determined, or if the number of blocks exceeds the range return -1.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Return the number of blocks of storage associated with the device or
instance. Where a "block" is a unit of storage consisting of the number
of bytes returned by the package's "block-size" method. If the size cannot
be determined, the #blocks method returns the maximum unsigned integer
(which, because of Open Firmware's assumption of two's complement arithmetic,
is equivalent to the signed number -1). If the number of blocks exceeds
the range of an unsigned number, return 0 to alert the caller to try
the #blocks64 command.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
IEEE Std 1275-1994 Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
3.8.3 deblocker support package
Any package that uses the "deblocker" support package must define
the following method, which the deblocker uses as a low-level
interface to the device
block-size ( -- block-len ) Return "granularity" for accesses to this
device.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
IEEE 1275-1994 Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
E.3.2.2 Bus-specific methods for bus nodes
A package implementing the scsi-2 device type shall implement the
following bus-specific method:
no-data-command ( cmd-addr -- error? )
Executes a simple SCSI command, automatically retrying under
certain conditions. cmd-addr is the address of a 6-byte command buffer
containing an SCSI command that does not have a data transfer phase.
Executes the command, retrying indefinitely with the same retry criteria
as retry-command.
error? is nonzero if an error occurred, zero otherwise.
NOTE no-data-command is a convenience function. It provides
no capabilities that are not present in retry-command, but for
those commands that meet its restrictions, it is easier to use.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
IEEE 1275-1994 Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
E.3.2.2 Bus-specific methods for bus nodes
A package implementing the scsi-2 device type shall implement the
following bus-specific method:
set-address ( unit# target# -- )
Sets the SCSI target number (0x0..0xf) and unit number (0..7) to which
subsequent commands apply.
This function is for devices with #address-cells == 2
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Convert physical address to text unit-string.
Convert phys.lo ... phys-high, the numerical representation, to unit-string,
the text string representation of a physical address within the address
space defined by this device node. The number of cells in the list
phys.lo ... phys.hi is determined by the value of the #address-cells property
of this node.
This function is for devices with #address-cells == 4
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
decode-unit ( addr len -- phys.lo ... phys.hi )
Convert text unit-string to physical address.
Convert unit-string, the text string representation, to phys.lo ... phys.hi,
the numerical representation of a physical address within the address space
defined by this device node. The number of cells in the list
phys.lo ... phys.hi is determined by the value of the #address-cells
property of this node.
This function is for devices with #address-cells == 4
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Limit NVMe of_path_of_nvme to just SPARC hardware for now. It has been
found that non-Open Firmware hardware platforms can some how access
this function.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme
support within ofpath) introduced a functional regression:
On systems which are not based on Open Firmware but have at
least one NVME device, find_obppath will return NULL and thus
trying to append the disk name to of_path will result in a
crash.
The proper behavior of of_path_of_nvme is, however, to just
return NULL in such cases, like other users of find_obppath,
such as of_path_of_scsi.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This way debuginfo built from the .module will still include this
information, but the final result won't have the data we don't actually
need in the modules, either on-disk, loaded at runtime, or in prebuilt
images.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme
support within ofpath) introduced a build regression:
grub-core/osdep/linux/ofpath.c:365:21: error: comparison between pointer
and zero character constant [-Werror=pointer-compare]
if ((digit_string != '\0') && (*part_end == 'p'))
Update digit_string to compare against the char instead of the pointer.
Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use kernel header struct and magic definition to align (and coexist) with
i386/arm64 ports.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename GRUB_LINUX_MAGIC_SIGNATURE GRUB_LINUX_I386_MAGIC_SIGNATURE,
to be usable in code that supports more than one image type.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI page definitions and macros are generic and should not be confined
to arm64 headers - so move to efi/memory.h.
Also add EFI_PAGE_SIZE macro.
Update loader sources to reflect new header location.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The CRC implementation imported from libgcrypt 1.5.3 is arguably
non-free, due to being encumbered by the restrictive Internet Society
licence on RFCs (see e.g. https://wiki.debian.org/NonFreeIETFDocuments).
Fortunately, libgcrypt has since replaced it with a version that is both
reportedly better-optimised and doesn't suffer from this encumbrance.
The ideal solution would be to update to a new version of libgcrypt, and
I spent some time trying to do that. However, util/import_gcry.py
requires complex modifications to cope with the new version, and I
stalled part-way through; furthermore, GRUB's libgcrypt tree already
contains some backports of upstream changes. Rather than allowing the
perfect to be the enemy of the good, I think it's best to backport this
single change to at least sort out the licensing situation. Doing so
won't make things any harder for a future wholesale upgrade.
This commit is mostly a straightforward backport of
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=06e122baa3321483a47bbf82fd2a4540becfa0c9,
but I also imported bufhelp.h from libgcrypt 1.7.0 (newer versions
required further changes elsewhere).
I've tested that "hashsum -h crc32" still produces correct output for a
variety of files on both i386-pc and x86_64-emu targets.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add NVMe support within ofpath.
The Open Firmware text representation for a NVMe device contains the
Namespace ID. An invalid namespace ID is one whose value is zero or whose
value is greater than the value reported by the Number of Namespaces (NN)
field in the Identify Controller data structure. At the moment only a
single Namespace is supported, therefore the value is currently hard coded
to one.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The definition of bpb's num_total_sectors_16 and num_total_sectors_32
is that either the 16-bit field is non-zero and is used (in which case
eg mkfs.fat sets the 32-bit field to zero), or it is zero and the
32-bit field is used. Therefore, a BPB is invalid only if *both*
fields are zero; having one field as zero and the other as non-zero is
the case to be expected. (Indeed, according to Microsoft's specification
one of the fields *must* be zero, and the other non-zero.)
This affects all users of grub_chainloader_patch_bpb which are in
chainloader.c, freedos.c, and ntldr.c
Some descriptions of the semantics of these two fields:
https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
The old 2-byte fields "total number of sectors" and "number of
sectors per FAT" are now zero; this information is now found in
the new 4-byte fields.
(Here given in the FAT32 EBPB section but the total sectors 16/32 bit
fields semantic is true of FAT12 and FAT16 too.)
https://wiki.osdev.org/FAT#BPB_.28BIOS_Parameter_Block.29
19 | 2 | The total sectors in the logical volume. If this value is 0,
it means there are more than 65535 sectors in the volume, and the actual
count is stored in "Large Sectors (bytes 32-35).
32 | 4 | Large amount of sector on media. This field is set if there
are more than 65535 sectors in the volume.
(Doesn't specify what the "large" field is set to when unused, but as
mentioned mkfs.fat sets it to zero then.)
https://technet.microsoft.com/en-us/library/cc976796.aspx
0x13 | WORD | 0x0000 |
Small Sectors . The number of sectors on the volume represented in 16
bits (< 65,536). For volumes larger than 65,536 sectors, this field
has a value of zero and the Large Sectors field is used instead.
0x20 | DWORD | 0x01F03E00 |
Large Sectors . If the value of the Small Sectors field is zero, this
field contains the total number of sectors in the FAT16 volume. If the
value of the Small Sectors field is not zero, the value of this field
is zero.
https://staff.washington.edu/dittrich/misc/fatgen103.pdf page 10
BPB_TotSec16 | 19 | 2 |
This field is the old 16-bit total count of sectors on the volume.
This count includes the count of all sectors in all four regions of the
volume. This field can be 0; if it is 0, then BPB_TotSec32 must be
non-zero. For FAT32 volumes, this field must be 0. For FAT12 and
FAT16 volumes, this field contains the sector count, and
BPB_TotSec32 is 0 if the total sector count “fits” (is less than
0x10000).
BPB_TotSec32 | 32 | 4 |
This field is the new 32-bit total count of sectors on the volume.
This count includes the count of all sectors in all four regions of the
volume. This field can be 0; if it is 0, then BPB_TotSec16 must be
non-zero. For FAT32 volumes, this field must be non-zero. For
FAT12/FAT16 volumes, this field contains the sector count if
BPB_TotSec16 is 0 (count is greater than or equal to 0x10000).
(This specifies that an unused BPB_TotSec32 field is set to zero.)
By the way fix offsets in include/grub/fat.h.
Tested with lDebug booted in qemu via grub2's
FreeDOS direct loading support, refer to
https://bitbucket.org/ecm/ldosboot + https://bitbucket.org/ecm/ldebug
Signed-off-by: C. Masloch <pushbx@38.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Code is currently ignoring errors from efibootmgr, giving users
clearly bogus output like:
Setting up grub-efi-amd64 (2.02~beta3-4) ...
Installing for x86_64-efi platform.
Could not delete variable: No space left on device
Could not prepare Boot variable: No space left on device
Installation finished. No error reported.
and then potentially unbootable systems. If efibootmgr fails, grub-install
should know that and report it!
We've been using similar patch in Debian now for some time, with no ill effects.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Fix the Open Firmware (OF) path property for sun4v SPARC systems.
These platforms do not have a /sas/ within their path. Over time
different OF addressing schemes have been supported. There
is no generic addressing scheme that works across every HBA.
It looks that this functionality will not work if you try to cross-install
SPARC GRUB2 binary using e.g. x86 grub-install. By default it should work.
However, we will also have other issues here, like lack of access to OF
firmware/paths, which make such configs unusable anyway. So, let's leave
this patch as is for time being. If somebody cares then he/she should fix
the issue(s) at some point.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
