cross-distro

cross-distro@lists.linaro.org

148 discussions

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

7 years, 4 months

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/

7 years, 4 months

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

7 years, 5 months

[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

7 years, 10 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

7 years, 10 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

8 years, 5 months

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

8 years, 5 months

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

8 years, 7 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."

8 years, 8 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

8 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro