cross-distro

cross-distro@lists.linaro.org

147 discussions

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

by Wookey

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 X-Spam-Status: No, score=-0.2 required=4.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VERIFIED,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=no autolearn_force=no version=3.4.1 List-Id: <debian-devel.lists.debian.org> 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. 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). 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.) Having a position paper co-signed by several different distros could be beneficial in making our views heard. The downside is that the deadline for submitting papers is fairly short, I think something like 1.5 weeks so this would need to move fairly quickly. Thanks, (not subscribed to the list so please cc) ----- End forwarded message ----- Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/

6 years

OpenJDK 11 AArch64 trig + log intrinsic accuracy

by Steve Capper

Hello, As a heads-up there's a bug in OpenJDK 11 whereby the sin, cos and log intrinsics lose accuracy on AArch64. A temporary workaround to this issue can be found discussed here: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-September/00015… Cheers, -- Steve

6 years, 1 month

[PATCH v2] ArmPkg/TimerDxe: remove workaround for KVM timer handling

by Ard Biesheuvel

When we first ported EDK2 to KVM/arm, we implemented a workaround for the quirky timer handling on the KVM side. This has been fixed in Linux commit f120cd6533d2 ("KVM: arm/arm64: timer: Allow the timer to control the active state") dated 23 June 2014, which was incorporated into Linux release 4.3. So almost 4 years later, it should be safe to drop this workaround on the EDK2 side. This reverts commit b1a633434ddc. Cc: cross-distro(a)lists.linaro.org Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Acked-by: Marc Zyngier <marc.zyngier(a)arm.com> Reviewed-by: Leif Lindholm <leif.lindholm(a)linaro.org> Acked-by: Laszlo Ersek <lersek(a)redhat.com> --- v2: add acks Note to cross-distro readers: this means guest firmware built with this patch will not work on KVM/ARM hosts using kernel v4.2 or earlier. ArmPkg/Drivers/TimerDxe/TimerDxe.c | 1 - ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c | 10 ---------- 2 files changed, 11 deletions(-) diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c b/ArmPkg/Drivers/TimerDxe/TimerDxe.c index a3202fa056f3..bd616d2efc73 100644 --- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c +++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c @@ -337,7 +337,6 @@ TimerInterruptHandler ( // Set next compare value ArmGenericTimerSetCompareVal (CompareValue); - ArmGenericTimerEnableTimer (); ArmInstructionSynchronizationBarrier (); } diff --git a/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c b/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c index 69a4ceb62db6..c941895a3574 100644 --- a/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c +++ b/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c @@ -26,16 +26,6 @@ ArmGenericTimerEnableTimer ( TimerCtrlReg = ArmReadCntvCtl (); TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE; - - // - // When running under KVM, we need to unmask the interrupt on the timer side - // as KVM will mask it when servicing the interrupt at the hypervisor level - // and delivering the virtual timer interrupt to the guest. Otherwise, the - // interrupt will fire again, trapping into the hypervisor again, etc. etc. - // This is scheduled to be fixed on the KVM side, but there is no harm in - // leaving this in once KVM gets fixed. - // - TimerCtrlReg &= ~ARM_ARCH_TIMER_IMASK; ArmWriteCntvCtl (TimerCtrlReg); } -- 2.17.0

6 years, 6 months

ARMv8.1-Atomics awareness in Glibc

by Steve Capper

Hello, For information, a patch has been posted to the glibc development list: https://sourceware.org/ml/libc-alpha/2018-04/msg00393.html which enables searching of "atomics" subdirectories when ld loads libraries, for systems where 8.1 atomics are enabled. This should allow one to employ the 8.1 atomics "baked in" to an optimised self-contained library rather than have to decouple them with alternative code paths, ifuncs, custom loaders etc. As an example, with this patch applied and running in a test model with 8.1 atomics enabled, and a filesystem with an extra libc supplied; I got the following from /proc/self/maps: /lib/aarch64-linux-gnu/atomics/libc.so.6 (re-running the model without atomics enabled gave the libc in /lib/aarch64-linux-gnu/ instead). Cheers, -- Steve

6 years, 6 months

SFO17 Cross-Distro meeting notes

by Riku Voipio

= 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

7 years, 1 month

ARM Cross-distro BoF at Linaro Connect next week

by Riku Voipio

Hi, We'll have the traditional cross-distribution BoF at Linaro connect Wednesday 27.9, at 3PM US pacific time - 22.00 UTC. We don't have a set agenda, but if anything is bugging you, replying to this mail is great way to make it into our topics :) Riku

7 years, 1 month

pathname for AArch32/Virt edk2 builds

by dann frazier

hey, I'm investigating enabling AArch32/Virt edk2 builds in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857858 I wanted to see if we can reach a consensus on what the pathname for these images should be, as these paths for other architectures have become hardcoded in upstream projects like OpenStack Nova and libvirt. These project currently expect to find the AArch64 images at: /usr/share/AAVMF/AAVMF_{CODE,VARS}.fd And, similarly, the x86-64 images at: /usr/share/ovmf/OVMF_{CODE,VARS}.fd I'm unaware of anyone shipping 32-bit x86 images. I propose: /usr/share/AAVMF/AAVMF32_{CODE,VARS}.fd -dann

7 years, 3 months

Re: arm64 ILP32 triplet change proposal

by Andreas Schwab

On Mär 16 2017, Wookey <wookey(a)wookware.org> wrote: > After feedback from people interested in ILP32, and discussion at > Linaro Connect, it seems that everyone involved is in agreement that > the triplets with the 'ilp32' bit in the ABI/OS part rather than the > machine/cpu part makes more sense. And that we can and should change > it, so long as it doesn't add significant delay. Thus it was agreed to > make this change. So the triplet for ilp32 on arm64/aarch64 is now: > > aarch64-linux-gnu_ilp32 (normal, little endian) > aarch64_be-linux-gnu_ilp32 (big endian) That makes it quite difficult to support building ilp32 packages with rpm. Andreas. -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

7 years, 4 months

Fwd: [RFC PATCH] acpi/pci: mcfg: add quirk for Marvell Armada8k

by Ard Biesheuvel

Hello all, Please refer to the patch and the ACPI/arm64 maintainer's reply below if you are interested in understanding why the SolidRun MacchiatoBin board (an arm64 board based on the Marvell Armada 8040 SoC) cannot be fully supported in ACPI mode in the upstream kernel. The change itself is trivial, but it violates a policy regarding standards compliance when it comes to implementing the PCIe root complex. However, this is a very useful board when it comes to development involving secure and non-secure firmware, given that all the code it runs is open (ARM Trusted Firmware, U-Boot, UEFI). So perhaps it may be worth considering taking this as a downstream patch in the distros? -- Ard. Forwarded conversation Subject: [RFC PATCH] acpi/pci: mcfg: add quirk for Marvell Armada8k ------------------------ From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: 27 April 2017 at 14:17 To: leif.lindholm(a)linaro.org, graeme.gregory(a)linaro.org Cc: agraf(a)suse.de, mw(a)semihalf.com, yehuday(a)marvell.com, linaro-acpi(a)lists.linaro.org, lorenzo.pieralisi(a)arm.com, Ard Biesheuvel <ard.biesheuvel(a)linaro.org> This implements a quirk for the Marvell Armada80x0 running in ACPI mode, in which case the config space configuration is not 100% ECAM compatible. The issue with this SoC is that it only consists of a host bridge, and all type 0 configuration cycles are forwarded to the peer (i.e., the device in the slot), which will therefore appear at all device slots on bus 0. This can be fixed by reducing the IATU window size for bus 0, but due to CX_ATU_MIN_REGION_SIZE == 64KB (which is a synthesis-time configuration parameter of the IP block) the window producing type 0 config cycles will always produce two copies of the peer device. So add a quirk that specifies a config space accessor override, and override config space accesses to devices on bus 0 other than device 0. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- drivers/acpi/pci_mcfg.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c index 2944353253ed..7d68b3208043 100644 --- a/drivers/acpi/pci_mcfg.c +++ b/drivers/acpi/pci_mcfg.c @@ -49,6 +49,40 @@ struct mcfg_fixup { NULL, IORESOURCE_BUS) #define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff) +/* + * The Armada 8k uses Synopsys PCIe IP, which /can/ be configured at + * synthesis time to be ECAM compatible, by reducing the IATU minimum + * window size to 32 KB. This way, we can reduce the window that produces + * type 0 config cycles to only cover b/d 0/0, which will make the peer + * only appear once on bus 0. The rest of the ECAM region can be enabled + * to generate type 1 config cycles in an ECAM compliant manner, which + * makes the rest of the hierarchy accessible if the peer is a true + * bridge. + * + * Note that in this configuration, there is only a host bridge that + * translates memory accesses to PCI bus cycles, and given that there + * is only a single peer, there is no reason to model a pseudobridge + * on bus 0 and make the peer appear on bus 1. (This is how the various + * DT drivers for snps,dw-pcie compatible controllers are implemented.) + */ +static void __iomem *armada8k_pcie_ecam_map_bus(struct pci_bus *bus, + unsigned int devfn, + int where) +{ + if (bus->number == 0 && PCI_SLOT(devfn) > 0) + return NULL; + return pci_ecam_map_bus(bus, devfn, where); +} + +static struct pci_ecam_ops armada8k_pcie_ecam_ops = { + .bus_shift = 20, + .pci_ops = { + .map_bus = armada8k_pcie_ecam_map_bus, + .read = pci_generic_config_read, + .write = pci_generic_config_write, + } +}; + static struct mcfg_fixup mcfg_quirks[] = { /* { OEM_ID, OEM_TABLE_ID, REV, SEGMENT, BUS_RANGE, ops, cfgres }, */ @@ -133,6 +167,8 @@ static struct mcfg_fixup mcfg_quirks[] = { XGENE_V2_ECAM_MCFG(4, 0), XGENE_V2_ECAM_MCFG(4, 1), XGENE_V2_ECAM_MCFG(4, 2), + + { "MVEBU ", "ARMADA8K", 0, 0, MCFG_BUS_ANY, &armada8k_pcie_ecam_ops }, }; static char mcfg_oem_id[ACPI_OEM_ID_SIZE]; -- 2.9.3 ---------- From: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Date: 28 April 2017 at 17:14 To: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Cc: leif.lindholm(a)linaro.org, graeme.gregory(a)linaro.org, agraf(a)suse.de, mw(a)semihalf.com, yehuday(a)marvell.com, linaro-acpi(a)lists.linaro.org On Thu, Apr 27, 2017 at 02:17:32PM +0100, Ard Biesheuvel wrote: > This implements a quirk for the Marvell Armada80x0 running in ACPI mode, > in which case the config space configuration is not 100% ECAM compatible. Too bad, I am not keen on merging any more ECAM quirks, we have been very clear about this and it is in our best interest to keep this code out of tree - we will bootstrap ACPI PCI systems on ECAM HW/FW compliant systems, that's it (I understand it is painful but it is necessary). Thanks, Lorenzo

7 years, 6 months

arm64 ILP32 triplet change proposal

by Wookey

I have been working on arm64 ILP32 bootstrapping (in debian) for some time now (sporadically), and in doing so noticed that we (ARM) did not choose the best triplet. After internal discussion we have decided that it would be better if it was changed, if possible. The technical case for this is set out below. Changing it is only sensible if there is consensus across distros and upstreams that this is the right way to go, so comment is being solicited here. If people have good reasons why it is worth the extra work and difference from x86 practice involved in keeping the existing triplet, then we can do that. The existing triplets (big+little endian) are: aarch64_ilp32-linux-gnu aarch64_be_ilp32-linux-gnu The proposed new triplets are: aarch64-linux-gnu_ilp32 aarch64_be-linux-gnu_ilp32 The reasoning for changing is as follows. The main technical argument is: * ILP32 is an ABI, not a machine/kernel feature. So it makes more sense to put the ILP32 indicator in the 'ABI' part of the triplet than the 'kernel/machine' part of the triplet. No kernel will ever return 'aarch64_ilp32' via uname (only 'aarch64' or 'aarch64_be'). Any aarch64 machine, with a new-enough kernel, can run LP64 or ILP32 code. The kernel/hardware really doesn't care. Which you choose/want is a feature of the userspace, more specifically of the glibc and/or gcc defaults in place, (gcc defaults optionally overridden with a -mabi option). Thus it makes sense to say "this userspace is 'gnu_ilp32' ABI", when building/configuring software. The main practical arguments are: * We don't have to change config.sub/guess in every autoconfed piece of software in the world to get our new ABI recognised. To use aarch64_ilp32-linux-gnu requires config.sub and config.guess to be updated in every autoconf-using package, and no autoconf update has even gone upstream yet so this will take years. If we use aarch64-linux-gnu_ilp32 instead, autoconf 'just works' already without any changes, as abi suffixes are passed-through. This is the thing that will significantly reduce the effort of building an ILP32 userspace. * The x86 'x32' ABI is exactly analagous to the aarch64 ilp32 ABI, and they chose to use an ABI suffix: 'x86_64-linux-gnux32' Avoiding gratuitous difference from x86, in the exact same situation, without any technical justification for divergence, is sensible. More stuff should just work, like the autoconf case, or at least be fixed in the same way, so porting is easier. Being gratuitously different is both confusing to people and likely to make more porting work (but I don't have a good handle on how much more, beyond autoconf-using packages). We do insist on an '_' separator, because separators are good for both clarity and parsing. (i.e gnu_ilp32, not gnuilp32) We realise that it is rather late in the day for this change, as some people have been using the existing triplet in toolchains already, but the kernel and glibc ABI was only relatively recently settled and patches submitted, there is no autoconf support yet upstream, and the toolchain support is incomplete in that you can't actually build a self-hosted ilp32-defaulting toolchain yet, so we believe that it is not actually too late, and worth trying to fix this now in the interests of a simpler porting process in the long term. The set of people who actually use ILP32 at this early stage, and thus care, is currently quite small, but we would like to hear from anyone who has baked the existing triplet into something and maybe released it, such that this change could cause serious dificulties? (loader path is the main place this gets exposed). Are there good reasons why it is in fact not practical to change to using the new triplet (assuming that we get on with it reasonably promptly)? Thank you for reading this far, I look forward to your comments. Wookey -- Principal hats: Linaro, Debian, ARM http://wookware.org/

7 years, 7 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro