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>
"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>
The reboot function calls machine_fini() and then reboots the system.
Currently it lives in lib/ which means it gets compiled into the
reboot module which lives on the heap.
In a following patch, I want to free the heap on machine_fini()
though, so we would free the memory that the code is running in. That
obviously breaks with smarter UEFI implementations.
So this patch moves it into the core. That way we ensure that all
code running after machine_fini() in the UEFI case is running from
memory that got allocated (and gets deallocated) by the UEFI core.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There is nothing ARM64 (or even ARM) specific about the efi fdt helper
library, which is used for locating or overriding a firmware-provided
devicetree in a UEFI system - so move it to loader/efi for reuse.
Move the fdtload.h include file to grub/efi and update path to
efi/fdtload.h in source code referring to it.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
We only support FDT files with EFI on arm and arm64 systems, not
on x86. So move the helper that finds a prepopulated FDT UUID
into its own file and only build it for architectures where it
also gets called.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
PIT isn't available on some of new hardware including Hyper-V. So
use pmtimer for calibration. Moreover pmtimer calibration is faster, so
use it on coreboor where booting time is important.
Based on patch by Michael Chang.
libgcc for boot environment isn't always present and compatible.
libgcc is often absent if endianness or bit-size at boot is different
from running OS.
libgcc may use optimised opcodes that aren't available on boot time.
So instead of relying on libgcc shipped with the compiler, supply
the functions in GRUB directly.
Tests are present to ensure that those replacement functions behave the
way compiler expects them to.
Previously we supplied only unsigned divisions on platforms that need software
division.
Yet compiler may itself use a signed division. A typical example would be a
difference between 2 pointers which involves division by object size.
