Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25 |
|
#
026b8579 |
| 18-Apr-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/zboot: arm64: Grab code size from ELF symbol in payload
Instead of relying on a dodgy dd hack to copy the image code size from the uncompressed image's PE header to the end of the compressed ima
efi/zboot: arm64: Grab code size from ELF symbol in payload
Instead of relying on a dodgy dd hack to copy the image code size from the uncompressed image's PE header to the end of the compressed image, let's grab the code size from the symbol that is injected into the ELF object by the Kbuild rules that generate the compressed payload.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
show more ...
|
Revision tags: v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15 |
|
#
eb684408 |
| 28-Feb-2023 |
Ard Biesheuvel <ardb@kernel.org> |
arm64: efi: Use SMBIOS processor version to key off Ampere quirk
Instead of using the SMBIOS type 1 record 'family' field, which is often modified by OEMs, use the type 4 'processor ID' and 'process
arm64: efi: Use SMBIOS processor version to key off Ampere quirk
Instead of using the SMBIOS type 1 record 'family' field, which is often modified by OEMs, use the type 4 'processor ID' and 'processor version' fields, which are set to a small set of probe-able values on all known Ampere EFI systems in the field.
Fixes: 550b33cfd4452968 ("arm64: efi: Force the use of ...") Tested-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11 |
|
#
19023316 |
| 08-Feb-2023 |
Darren Hart <darren@os.amperecomputing.com> |
arm64: efi: Force the use of SetVirtualAddressMap() on eMAG and Altra Max machines
Commit 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") identifies the Altra
arm64: efi: Force the use of SetVirtualAddressMap() on eMAG and Altra Max machines
Commit 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") identifies the Altra family via the family field in the type#1 SMBIOS record. eMAG and Altra Max machines are similarly affected but not detected with the strict strcmp test.
The type1_family smbios string is not an entirely reliable means of identifying systems with this issue as OEMs can, and do, use their own strings for these fields. However, until we have a better solution, capture the bulk of these systems by adding strcmp matching for "eMAG" and "Altra Max".
Fixes: 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") Cc: <stable@vger.kernel.org> # 6.1.x Cc: Alexandru Elisei <alexandru.elisei@gmail.com> Signed-off-by: Darren Hart <darren@os.amperecomputing.com> Tested-by: Justin He <justin.he@arm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19 |
|
#
61786170 |
| 11-Jan-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi: arm64: enter with MMU and caches enabled
Instead of cleaning the entire loaded kernel image to the PoC and disabling the MMU and caches before branching to the kernel's bare metal entry point,
efi: arm64: enter with MMU and caches enabled
Instead of cleaning the entire loaded kernel image to the PoC and disabling the MMU and caches before branching to the kernel's bare metal entry point, we can leave the MMU and caches enabled, and rely on EFI's cacheable 1:1 mapping of all of system RAM (which is mandated by the spec) to populate the initial page tables.
This removes the need for managing coherency in software, which is tedious and error prone.
Note that we still need to clean the executable region of the image to the PoU if this is required for I/D coherency, but only if we actually decided to move the image in memory, as otherwise, this will have been taken care of by the loader.
This change affects both the builtin EFI stub as well as the zboot decompressor, which now carries the entire EFI stub along with the decompression code and the compressed image.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20230111102236.1430401-7-ardb@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
Revision tags: v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74 |
|
#
d9ffe524 |
| 13-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi/arm64: libstub: Split off kernel image relocation for builtin stub
The arm64 build of the EFI stub is part of the core kernel image, and therefore accesses section markers directly when it needs
efi/arm64: libstub: Split off kernel image relocation for builtin stub
The arm64 build of the EFI stub is part of the core kernel image, and therefore accesses section markers directly when it needs to figure out the size of the various section.
The zboot decompressor does not have access to those symbols, but doesn't really need that either. So let's move handle_kernel_image() into a separate file (or rather, move everything else into a separate file) so that the zboot build does not pull in unused code that links to symbols that it does not define.
While at it, introduce a helper routine that the generic zboot loader will need to invoke after decompressing the image but before invoking it, to ensure that the I-side view of memory is consistent.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|