cross-distro

cross-distro@lists.linaro.org

147 discussions

by Ard Biesheuvel

Hello all, Just a note to whomever is subscribed to this list regarding some changes in v5.10 that may affect distros' kernel deployments: efivars ------- efivars is the ancient predecessor to efivarFs, that allows access to EFI variables via sysfs (but with some restrictions). This has been deprecated since before ARM even had UEFI support, and it is no longer going to be enabled going forward. EFI pstore has been rewritten to no longer rely on it, and on x86, the module is still available, but no longer gets loaded automatically. On !x86, it is no longer built at all. As far as I could figure out (and I did ask around as well), this is highly unlikely to regress anything, and on x86, the module can still be loaded manually if needed (or enabled as a builtin) deprecated crypto ----------------- Some crypto drivers have been made to depend on CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE, which is only available if the crypto AF_ALG socket API is enabled, as the algorithms are never used by the kernel itself. However, none of these ciphers are known to be relied upon by user space either (via AF_ALG), and so I strongly recommend the distros incorporate # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set into their v5.10+ kernel configs so that these deprecated algorithms are simply dropped from the build (the algos are arc4, tea, khazad, SEED and anubis, others may follow in the future, e.g., md4/5). Note that iwd/libell used to rely on the kernel's ecb(arc4) implementation, but this is no longer the case. kexec/kdump tools ----------- To make the kernel's PE/COFF header spec compliant, the stext symbol will be aligned to 64 KB regardless of the page size the kernel was built with. As far as I can tell looking at the debian source of the associated tooling, the symbol value of stext is used to infer the page size, so this will no longer work.

4 years

AArch64 atomics, -moutline-atomics support in GCC

by Steve Capper

Hello cross-distro, I thought it a good idea to send an update on gcc support for LSE == Large System Extensions. These are a series of instructions introduced in Armv8.1 that allow one to atomically update values using a single instruction rather than as a sequence of: Load Exclusive + modify + store exclusive. This extension is optional, meaning that not all implementations support it. It has to be selected at runtime. As atomic operations are rather fundamental operations, existing mechanisms (such as ifunc resolvers) are not really suitable for runtime selection. glibc 2.28+ supports HWCAP_ATOMICS for runtime selection meaning .so's can be deployed in an "atomic" folder. The trouble with this approach is that it requires more building and testing work to deploy multiple .so's. Recently, in gcc 10, there is support for "-moutline-atomics". This flag prompts gcc to generate both exclusive monitor and LSE code for atomic operations and the pertinent routine is selected at runtime. The runtime selection process involves a conditional direct branch and has been found to only have a modest overhead. From gcc 10.1 upwards, -moutline-atomics is enabled by default (but can be disabled by -mno-outline-atomics) For those interested in backports of this functionality into older versions of gcc please see: GCC-8 aarch64: Add early clobber for aarch64_store_exclusive https://gcc.gnu.org/git?p=gcc.git;a=commit;h=512b0ffab3bc4f334cbb36c598192c… aarch64: Simplify LSE cas generation https://gcc.gnu.org/git?p=gcc.git;a=commit;h=1bf932b1ab9002089ddd79d6453218… aarch64: Improve cas generation https://gcc.gnu.org/git?p=gcc.git;a=commit;h=369a4d6dd2df645f1870506d8dd6a5… aarch64: Improve swp generation https://gcc.gnu.org/git?p=gcc.git;a=commit;h=5d8ff6f1ff2cef121dc33d954535fc… aarch64: Improve atomic-op lse generation https://gcc.gnu.org/git?p=gcc.git;a=commit;h=f557aa1a836377d49fdbd4e7cecb2e… aarch64: Remove early clobber from ATOMIC_LDOP scratch https://gcc.gnu.org/git?p=gcc.git;a=commit;h=5497bc389dca6a992aaa063df30895… aarch64: Extend %R for integer registers https://gcc.gnu.org/git?p=gcc.git;a=commit;h=c7ae64412b6c9c7b966f3c0ab8eaa5… aarch64: Implement TImode compare-and-swap https://gcc.gnu.org/git?p=gcc.git;a=commit;h=1101198f3d099af0555d7202a2a00c… Aarch64: Fix shrinkwrapping interactions with atomics (PR92692) https://gcc.gnu.org/git?p=gcc.git;a=commit;h=0b65e477890b7fe7f47a3dd85975ab… aarch64: Tidy aarch64_split_compare_and_swap https://gcc.gnu.org/git?p=gcc.git;a=commit;h=eccc28184d58dc27232d6710dc44eb… aarch64: Add out-of-line functions for LSE atomics https://gcc.gnu.org/git?p=gcc.git;a=commit;h=06f8058a8368f79e2cbf4659db53b9… Add visibility to libfunc constructors https://gcc.gnu.org/git?p=gcc.git;a=commit;h=36579491fa01039694ad12e673ffe5… aarch64: Implement -moutline-atomics https://gcc.gnu.org/git?p=gcc.git;a=commit;h=ff54767725cd86e1d937cde50ec499… aarch64: Fix store-exclusive in load-operate LSE helpers https://gcc.gnu.org/git?p=gcc.git;a=commit;h=4eaef24ba1f83ccfb54c9e473eb203… aarch64: Configure for sys/auxv.h in libgcc for lse-init.c https://gcc.gnu.org/git?p=gcc.git;a=commit;h=5d44ad1e0a66651495ed964058cdd6… aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368] https://gcc.gnu.org/git?p=gcc.git;a=commit;h=163e0d03f2cdc80de4968c4be4694c… aarch64: Fix bootstrap with old binutils [PR93053] https://gcc.gnu.org/git?p=gcc.git;a=commit;h=a69a60c4969cea06c1d44b5e3e4970… aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435] https://gcc.gnu.org/git?p=gcc.git;a=commit;h=1dbd821ee74e6c234e61e25b0801a0… re PR target/90724 (ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve) https://gcc.gnu.org/git?p=gcc.git;a=commit;h=69472d76d2456a447f61bc539bd6fe… aarch64: Fix for PR target/94814 Backport of PR target/94518: Fix memmodel index in aarch64_store_exclusive_pair https://gcc.gnu.org/git?p=gcc.git;a=commit;h=034dfe065033a846761b0a5c35fc86… aarch64: Force TImode values into even registers https://gcc.gnu.org/git?p=gcc.git;a=commit;h=80c605c875fb394212164908151bf0… [AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0d2a937abf6ea0e03bfd7cb56c0f… GCC-9 aarch64: Extend %R for integer registers https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=Ea7ffe1da05df28c8dd5c1f5292b3… aarch64: Implement TImode compare-and-swap https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=53c1356515ac1357c341b59432696… [AArch64] Fix shrinkwrapping interactions with atomics (PR92692) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=Ea376dd471a3b006bc48945c1d9a2… aarch64: Tidy aarch64_split_compare_and_swap https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=43e46197c10daad6e0aee839c8526… aarch64: Add out-of-line functions for LSE atomics https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b36f6a808e5ce7484c1039458f2e3… aarch64: Implement -moutline-atomics https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9cf2784a69e126283c33fdbcfbf57… aarch64: Fix store-exclusive in load-operate LSE helpers https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bb9156ede009cfb572ab98c64288d… aarch64: Configure for sys/auxv.h in libgcc for lse-init.c https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c15ff4d0803ffd02fdb9147e82e88… aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=13f6d5ac48a7d55b41927849aeebc… aarch64: Fix bootstrap with old binutils [PR93053] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bfe912a35c0c39a623ba6e0066b60… aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=be64fc4cab7facee309447302b6ee… re PR target/90724 (ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=65709f4b93c74101440ab16bf4bdd… [AArch64] PR target/94518: Fix memmodel index in aarch64_store_exclusive_pair https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=470626394ab7779cb663258048da8… [AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b6dc99434abb6f5fa70ced8790bca… Cheers, -- Steve Capper IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 5 months

Bug on binutils 2.33 for aarch64 with A53 errata

by Guillaume Gardet

Hi, FYI, there is a bug on binutils 2.33 for aarch64 when --fix-cortex-a53-835769 and --fix-cortex-a53-843419 are used, which can lead to an invalid operation. The upstream bug report with a workaround is available at https://sourceware.org/bugzilla/show_bug.cgi?id=25210 Cheers, Guillaume IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 10 months

GRUB 2.04 release, armhf, stuff

by Leif Lindholm

Hi all, TL;DR, GRUB 2.04 is released, and the below is fixed in there, including one important bit for arm64. Around the dawn of time, I started working on a GRUB port to 32-bit ARM on UEFI. By the time we got to the linux loader, the EFI stub support was still being developed for the kernel - and the boot/runtime UEFI support wasn't merged yet. So I bodged up the existing loader I had put together for the GRUB U-Boot port to at least check it wasn't overwriting anything important, and put some info into the chosen node to tell Linux what it needed to do to boot in UEFI mode and that was that. UEFI on 32-bit ARM never took off, and hence the relevant GRUB port, but you could kind of use it with the bodged U-Boot loader. Then that mischievous scoundrel Alex Graf went and implemented some basic UEFI interfaces for U-Boot, and the long-buried sins of the past were brought to the surface for all to see. So, anyway, I had to provide a *real* linux loader for 32-bit ARM on UEFI, so I went and genericised the arm64 UEFI linux loader. Of course, this had some spectacular fallout in various parts of the GRUB source tree. Finally, this all got merged upstream in September 2018. However, the timing of the next GRUB release was not clear, so I set up a branch with the minimum amount of patches required to go on top of the Debian Buster 2.02 GRUB (so Debian wouldn't have to wait until 2021-22): https://git.linaro.org/people/leif.lindholm/grub.git/log/?h=debian-buster-a…. This roughly corresponds to cherry-picking upstream: a0e4ee533dc0c6a78ecc55e97ac0fb98755f7fe7 linux, efi, arm*, fdt: Break FDT extra allocation space out into a #define 9bfba354bbd9f1541b1e5593549809aa3e720992 loader/multiboot_mbi2: Use central copy of grub_efi_find_mmap_size() 9415914e0fb4d0e09f49431cfb591551bd20f63a loader/ia64/linux: Use central copy of grub_efi_find_mmap_size() ad2bebc6fc3d77e38294aaa824362a0851239703 loader/i386/linux: Use central copy of grub_efi_find_mmap_size() c79ebcd18cf3e208e9dda5e2ae008f76c92fe451 i386: Don't include lib/i386/reset.c in EFI builds a2f26adfef2fc8a7d7392c3704031df4624c67b0 efi: Restrict arm/arm64 linux loader initrd placement 77808dd66bda72ff14873bcd701ec25a0db1dfee arm: Delete unused efi support from loader/arm d0c070179d4d78c297364e41ece54fd7755c4b58 arm/efi: Switch to arm64 linux loader d24dd120864ed72a80d7bb9c0288c4f29934f79d arm64/linux/loader: Rename functions and macros and move to common headers bad144c60f664a83f5a7d3a014927bffaa2abbf1 efi: Add grub_efi_get_ram_base() function for arm64 8ec18d1a4c26129c0a018ee7a61739a929ee1a25 efi: Add central copy of grub_efi_find_mmap_size 9b37229f013db1b150082ac130be7c20b3db8cea commands/file: Use definitions from arm64/linux.h 40dc61ed75e08e7dc2951bdae5c59fecb15bbb72 commands/file: Use definitions from arm/linux.h 347210a5d5ce655b95315f320faa515afb723c11 efi/fdt: Set address/size cells to 2 for empty tree e93fd6b776a7e6cef36c445d00436e5a23cfeba5 fdt: Move prop_entry_size to fdt.h a244d9ebc7547f7ed373d9796a3bf186e7c035a1 arm: make linux.h safe to include for non-native builds cda033298680b6984044563b2ef6374a725b8aac arm: switch linux loader to linux_arm_kernel_header struct 7fd9722d0c5e9c5a85b782ef435c80085da308b2 arm64: align linux kernel magic macro naming with i386 ff1cf2548a3f33da19278829687d074ad746dd0a arm64: align linux kernel header struct naming with i386 7d36709d5e769eb49b41cca709bd64336b47ab4f i386: make struct linux_kernel_header architecture specific 3245f02d9d7274e942426541cf73dc73e7298f02 make GRUB_LINUX_MAGIC_SIGNATURE architecture-specific 8776e5a942582adaadc67865ed74cdd199e56a16 Make arch-specific linux.h include guards architecture unique 083c6e2455dcd4aafb6062d89fd6029dd3adddb6 arm64/efi: move EFI_PAGE definitions to efi/memory.h f826330683675f0deb55b58fd229afd7d65fb053 efi: change heap allocation type to GRUB_EFI_LOADER_CODE 91212e0aa07e704a61e4540c18a27f149f5e51c3 arm64 linux loader: improve type portability c5841ba7f0d14c193f20854e7e55b4f7ce9207d5 efi: Add GRUB_PE32_MAGIC definition 8c9465fac901caac6802d6872a1374518b001517 efi: move fdt helper library 4bc909bf89f5b4ff86c9e4e609d4fe0c11a66b0c Remove grub_efi_allocate_pages. dd5fde2df83c5c03b7ba04d2cc5b7be96de8da7b efi: refactor grub_efi_allocate_pages Additionally, I would strongly recommend cherry-picking the following two 2d55ffecbb966d3e42023729d8bbf3c21c59e049 configure: Disable arm movw/movt relocations for GCC 566b16a0dc23d72357d2d75b781d3c7895b8a234 arm64/efi: Fix grub_efi_get_ram_base() The latter sorts out a brainfart wreaking havoc on the arm64 port. But with that, both arm and arm64 actually respect the kernel's initrd placement rules (meaning you can actually boot on arm64 systems with tons of RAM, or large holes in the memory map). But as I said, GRUB 2.04 has been released, and if moving to that is an option, please do. My intent is to also bring RISC-V into the fold and use the same loader for all three. Anyway, if you got this far, have (another) cup of coffee. / Leif

5 years, 3 months

LuaJIT

by Andrew Wafaa

Hi All, Just as a heads up, there's a fork of LuJIT called unimaginatively LuaJIT2[0]. The progress of LuaJIT has been exceptionally slow, and getting patches merged has been difficult at best. This fork has numerous enhancements for both Arm and POWER. Regards, Andy 0 - https://github.com/openresty/luajit2

5 years, 3 months

Re: [edk2] [edk2-announce] ATTN: List Transition Begins Today

by Leif Lindholm

FYI: EDK2 development mailing list changing to devel(a)edk2.groups.io This will give us some better flexibility with regards to whitelisting non-subscribers and suchlike currently not possible through 01.org. On Wed, Apr 03, 2019 at 10:59:31AM -0500, stephano wrote: > tl;dr > If you're sending emails to this list, now would be a good time to switch > over to the new list: https://edk2.groups.io/g/devel > > > We will be transitioning to Groups.io today for our devel mailing list. At > some point today, this email will begin to bounce any incoming messages. > I'll be working on getting the archive of old emails uploaded to Groups.io. > When I have a timetable for the archives I'll update the new list. > > Cheers, > Stephano > _______________________________________________ > edk2-devel mailing list > edk2-devel(a)lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel

5 years, 7 months

shim crashes

by dann frazier

hey, Heads-up, while testing out arm64 SecureBoot in the QEMU virt model, I hit a couple bugs in shim that were causing it to crash: https://github.com/rhboot/shim/pull/173 https://github.com/rhboot/shim/pull/174 They are not arm64-specific, but happen to not escalate to crashes on x86 because of it's memory layout. -dann

5 years, 7 months

nouveau h/w acceleration is blacklisted by default in chromium 71+

by Ard Biesheuvel

Hello all, (cc'ing everybody who I think might care - please ignore if you don't) Chromium [as of 71] now defaults to software rendering when it detects the nouveau driver. This is bad for the ARM ecosystem, since it is the only driver we have for NVIDIA hardware, and it has fewer issues than AMD GPU drivers + hardware running on ARM systenms. https://lists.freedesktop.org/archives/nouveau/2019-January/031798.html It can be addressed by setting the 'ignore-gpu-blacklist' option, but this requires an explicit action from the user, which is unfortunate and undesirable. Is there any way we can influence this?

5 years, 9 months

Full rebuilds of the Debian archive for armel-on-arm64 and armhf-on-arm64

by Steve McIntyre

Hi folks, In the hope this might be interesting for people... I've just finished with my analysis of rebuilding the Debian archive for armel and armhf using arm64 build machines. I've been rebuilding the archive *specifically* to check if we would have any problems building our 32-bit Arm ports (armel and armhf) using 64-bit arm64 hardware. I might have found other issues too, but that was my goal. Executive summary: As far as I can see we're basically fine to use arm64 hosts for building armel and armhf, *so long as* those hosts include hardware support for the 32-bit A32 instruction set. As I've mentioned before in Debian, that's not a given on *all* arm64 machines, but there are sufficient machine types available that I think we should be fine. There are a couple of things we'll need to do in terms of setup. See https://blog.einval.com/2019/01/07#rebuilding_on_arm64 for the full article. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

5 years, 10 months

Re: Fwd: Re: Fw: Debian packaging, dependency management and the C++ standards meeting

by Detlef Vollmann

I got this mail forwarded, I'm not on any of the lists, don't know too much about Debian packaging, but generally attend the C++ standards meeting. On 10/11/18 16:32, Baurzhan Ismagulov wrote: > ----- Forwarded message from Bill Gatliff <bgat(a)billgatliff.com> ----- > > Date: Wed, 10 Oct 2018 14:00:42 -0500 > From: Bill Gatliff <bgat(a)billgatliff.com> > To: Wookey <wookey(a)wookware.org> > Cc: cross-distro(a)lists.linaro.org > Subject: Re: Fw: Debian packaging, dependency management and the C++ standards > meeting > > I'd be interested in helping out. I'm not an official Debian developer, but > I've done a fair amount of packaging, am pretty skilled in C++, have a > strong background in embedded work and presentations, and don't mind being > That Guy when necessary. > > No interest in showing up unannounced or solo, though. Ideas? Well, while the meeting lasts the whole week, tooling will probably only discussed in one single evening session. If you're actually interested in showing up, contact Titus and ask him to fix the date. But the admin telco for the meeting in San Diego will be only on Oct 26; Titus might not be able to fix the date before that. > On Wed, Oct 10, 2018, 10:05 AM Wookey <wookey(a)wookware.org> wrote: > >> This came up on debian-devel, and seems like a very cross-distro >> thing, albeit not ARM-specific, so reposting here. Anyone here able to >> explain/interested in explaining distro-thinking to the C++ standards >> people (in San Diego)? >> >> ----- Forwarded message from Jussi Pakkanen <jpakkane(a)gmail.com> ----- >> >> Date: Wed, 3 Oct 2018 19:56:29 +0300 >> From: Jussi Pakkanen <jpakkane(a)gmail.com> >> To: debian-devel(a)lists.debian.org >> Subject: Debian packaging, dependency management and the C++ standards >> meeting >> >> Hi >> >> Last week I was at CppCon, which is the biggest C++ developers' >> conference in the world. There were a lot of talks about dependencies, >> packaging and deployment and other such things related to Debian. A >> representative snippet can be seen in this video starting at 1:13:56: >> >> https://www.youtube.com/watch?v=TjdCxXdjaSA >> >> The tl/dr version is that people running the C++ standardisation work >> do not really have knowledge about the way Debian does things and >> because of this might not take relevant things into consideration. As >> an example there is a rising trend of "discard ABI stability, static >> link everything and recompile the world on every change" vibe going on >> similar to most new system programming languages. This would make >> things difficult for Debian due to obvious reasons. >> >> They specifically mention that there is a standardisation meeting next >> month (in San Diego?) and that if people from Debian and other groups >> underrepresented in the C++ standardisation process were to attend, >> they would like to talk to them to understand their requirements. This >> specific thing is mentioned in the video at 1:17, the person in the >> white shirt answering the question is Titus Winters, Google's C++ lead >> (of some sort, don't know the specifics) and he is a big advocate of >> static linking everything. But there are people in the C++ committee who need stable ABIs, but often this can be restricted to specific parts of the interface, while other parts can be linked in statically. >> I can't attend due to geographical reasons but would there be someone >> who could and would be interested? It would probably be beneficial to >> have Debian people there to tell about those specific requirements, >> because it seems like most people on the standardisation committee do >> not really have a good grasp on what they are. In fact it might make >> sense to send distro people in general, since the requirements are >> very similar for Red Hat, Ubuntu, SuSE et al. If you have contacts in >> those organisations who would be interested in this issue feel free to >> send them links to this email thread. I know Red Hat at least has sent >> people to the meeting in the past but on the language/stdlib side, not >> for packaging (that I know of at least). Yes, typically the some GCC people from Red Hat are at the meeting. They know ABI requirements pretty well (GCC introduced a new linking scheme for this in GCC 5.0) but probably don't know the specifics of packaging. >> An alternative, or parallel, approach could be to write a paper >> outlining the issues and submitting it to the standard body. This does >> require someone to be physically at the meeting and to present the >> paper and its conclusions to the participants and be ready to answer >> questions. (I have never actually done this myself, so the above >> description might have flaws.) This description is pretty accurate. >> Having a position paper co-signed by >> several different distros could be beneficial in making our views >> heard. Definitely. But the deadline for this meeting was last Moday. But for an author it would probably be useful to be at the Meeting (at least for the SG15 evening session) to get a feeling of what the different people in the committee think. And try to find co-authors inside the committee. And then write a paper for the next meeting Feb 18-23, 2019 in Kona, HI. Detlef

6 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro