= LSE atomics problem =
Large System Extensions, part of ARMv8.1, provides new atomics instructions. These instructions are essential for high performance locking when you have lots of cores.
Recommendation: distributions should provide an alternative optimized glibc with LSE atomics based locks for end users.
= Scalable Vector Extensions =
May have an ABI issue. Situation under investigation.
= Page size =
Don't assume your binaries will always execute in the page size they were built on. Even if your distribution is built on 4K page size, be aware that some of your users might opt to run with 64K page size kernel - for example in containers.
Users be aware, that switching between 4K and 64K kernels may break some data structures that depend on page size. Swap needs be reformatted, and btrfs will explode on page size change-
= OCI spec =
With LSE, SVE, armv8.x releases coming, any containers using newer instructions should be identified in variant field.
= Booting =
One day, booting on arm will be so boring, that nobody will bring it up on our cross-distribution BoF. That day was not today.
RHEL only supports ACPI on arm64. Even if you are not RHEL, you should prefer ACPI over device tree, if the former is available.
U-boot can now start EFI binaries, making u-boot an excellent platform to implement an UEFI bios. This allows single-path installers for distributions, where install of distribution starts always by loading grub from EFI.
On arm64, Kernel doesn't self-decompress. The bootloaders are stringly recommended to support decompressing kernel images. It's optional in grub, make sure your grub does. At least iPXE and u-boot don't support booting Image.gz on arm64, and should be fixed.
Riku
On Fri, Sep 29, 2017 at 02:06:21AM +0300, Riku Voipio wrote:
[snip]
On arm64, Kernel doesn't self-decompress. The bootloaders are stringly recommended to support decompressing kernel images. It's optional in grub, make sure your grub does. At least iPXE and u-boot don't support booting Image.gz on arm64, and should be fixed.
Not strictly true. We do expect that if you're loading in a compressed something that you uncompress it then boot it. I assume part of the reason that Linux didn't go for self-decompression this time is the "my goodness, it's tricky to get here's where we are, here's what else is in the system, lets not stomp anything and get ourself to where we need to be" is in fact tricky.
That said, patches to check for ${VALID_COMPRESSION_HEADER}, uncompress a chunk, confirm valid Image header, and uncompress to where it needs to reside would be welcome.
Thanks!
On 29 September 2017 at 21:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 29, 2017 at 02:06:21AM +0300, Riku Voipio wrote:
[snip]
On arm64, Kernel doesn't self-decompress. The bootloaders are stringly recommended to support decompressing kernel images. It's optional in grub, make sure your grub does. At least iPXE and u-boot don't support booting Image.gz on arm64, and should be fixed.
Not strictly true. We do expect that if you're loading in a compressed something that you uncompress it then boot it. I assume part of the reason that Linux didn't go for self-decompression this time is the "my goodness, it's tricky to get here's where we are, here's what else is in the system, lets not stomp anything and get ourself to where we need to be" is in fact tricky.
Thanks for the clarification. The kernel Documentation/arm64/booting.txt is vague in reasoning, but you are right it's tricky. Kernel developers assume the bootloader is better equipped to know where in memory to decompress than a early kernel decompress loop.
That said, patches to check for ${VALID_COMPRESSION_HEADER}, uncompress a chunk, confirm valid Image header, and uncompress to where it needs to reside would be welcome.
While the unzip command hint is good, from cross-distro PoV I think this kind of transparent decompression is needed to make the syslinux bootmenu command "just work".
Riku
-
Riku Voipio -
Tom Rini