How to retrieve CPU frequency when cpufreq is missing under 3.16.0-4-arm64?

I'm testing on an early Mustang board. Its ARMv8/Aarch64, but it lacks the mostly standard CRC and Crypto extensions. The tests run in userland, without any elevation. One of the tests performs some benchmarks. For accurate results the test script attempts to query the CPU frequency. It appears

Broadcom BCM2709, ARMv8, and missing CPU features

Hi Everyone, I recently purchased a Raspberry Pi 3. Its got a Broadcom SoC, and its ARMv8. Its running a Debian-lite kernel, which I believe is a modified 4.4 kernel. Below is the output from cpuinfo. I see ARMv8's crc32 is available, but I don't see pmull, aes or sha. At the moment, I'm not

Re: ARM64 (was: Summary of the ARM ports BoF at DC16)

>> The Mustang board is a nice test platform because its an early ARMv8 >> board. While its ARMv8, it lacks CRC and Crypto extensions. > > That's interesting. Having almost given up on any AMD ARM > hardware ever appearing, I've been considering getting a > Gigabyte MP30-AR0 (which I thought for

Re: Broadcom BCM2709, ARMv8, and missing CPU features

On Thu, Jul 28, 2016 at 3:06 AM, Tixy <t...@yxit.co.uk> wrote: > On Thu, 2016-07-28 at 02:38 -0400, Jeffrey Walton wrote: > [...] >> >> // AES (aese) >> >> ".byte 0x4e, 0x28, 0x48, 0x20;\n" >> > >> > So as instructions a

Re: Broadcom BCM2709, ARMv8, and missing CPU features

> Using '.byte' below rather than '.inst' or '.inst.w' is another can of > worms... > > $ gcc -g3 -O0 -march=armv7-a -mfpu=neon test.cc -o test.exe > $ ./test.exe > $ > > $ cat test.cc > #include > int main(int argc, char* argv[]) > { > __asm__ __volatile__ > ( > ".code 32" > > //

Re: Broadcom BCM2709, ARMv8, and missing CPU features

>> Using '.byte' below rather than '.inst' or '.inst.w' is another can of >> worms... > > And if I'm not mistaken, the part of the reason why you got the > instructions wrong... > >> $ gcc -g3 -O0 -march=armv7-a -mfpu=neon test.cc -o test.exe >> $ ./test.exe >> $ > > Does the tool-chain default

ARM64 (was: Summary of the ARM ports BoF at DC16)

> arm64 > = > > Most recent ARM port. All looking good now - we've been mostly able to > move on from Juno development platforms to real server hardware > now. We're using some APM Mustang machines and an AMD Seattle box > hosted by ARM and Linaro at the moment, and even real arm64 server >

Re: Broadcom BCM2709, ARMv8, and missing CPU features

On Wed, Jul 27, 2016 at 2:18 AM, Paul Wise <p...@debian.org> wrote: > On Wed, Jul 27, 2016 at 11:28 AM, Jeffrey Walton wrote: > >> I recently purchased a Raspberry Pi 3. Its got a Broadcom SoC, and its >> ARMv8. > ... >> model name: ARMv7 Processor rev 4 (v7

Re: Which port for armv4l?

> Hmm... I guess you'd still suffer from performance problems when your > locally-compiled packages get updated by "apt-get upgrade" and hence > replacing your tuned packages with the stock precompiled ones. > So I guess for the sun to shine we'd want some way to flag some packages > as "always

Re: Thinking about a "jessie and a half" release

> There's something I've been pondering for a while, along with some > other folks - it might be useful to do a "jessie and a half" release, > similarly to what we did in the etch days. That's *basically* just > like a normal jessie release, but with a few key updates: > > * backports kernel > *

Re: Broadcom BCM2709, ARMv8, and missing CPU features

On Tue, Jul 26, 2016 at 11:28 PM, Jeffrey Walton <noloa...@gmail.com> wrote: > Hi Everyone, > > I recently purchased a Raspberry Pi 3. Its got a Broadcom SoC, and its > ARMv8. Its running a Debian-lite kernel, which I believe is a modified > 4.4 kernel. > > Below is the

Re: [pkg-go] Bug#852959: Bug#852959: prometheus FTBFS on armhf: github.com/prometheus/prometheus/storage/local fails

> Sadly, it turns out armhf fails to build due to one test taking a bit > too much memory[1], and there is an RC bug open for that: #852959[2]. > > So now I don't know what to do, except asking for removal of prometheus > from armhf. As a stopgap, you might consider adding a small swapfile and

Re: Thinking about a "jessie and a half" release

> There's something I've been pondering for a while, along with some > other folks - it might be useful to do a "jessie and a half" release, > similarly to what we did in the etch days. That's *basically* just > like a normal jessie release, but with a few key updates: > > * backports kernel > *

Re: Thinking about a "jessie and a half" release

>>> Is anybody else interested in helping? Thoughts/comments? >> >>Sorry to bump an old thread >> >>Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for >>the platform. >> >>Clang 3.5 and 3.6 are no longer maintained. The bugs we are >>discovering and reporting are being closed

Re: How do I turn the radio in a pi 3b off

On Tue, Jan 10, 2017 at 10:25 AM, Jim MacKenzie wrote: > If you don't have an access point configured on your WiFi radio, your radio > will listen only, and never reply, hence there is no vulnerability. I hope I don't drift too far... I was able to crash a couple of iPads a few

Re: how to distinguish armel and armhf at runtime?

On Fri, Sep 22, 2017 at 3:57 PM, Uwe Kleine-König wrote: >... > For armhf I need to define __ARM_PCS_VFP but that must be absent on armel. Forgive my ignorance... If the compiler was built for the native platform, then wouldn't the compiler and preprocessor definitions

Re: Why so little info on the Pocket Beagle?

On Wed, Oct 4, 2017 at 7:53 PM, Robert Nelson wrote: > ... > With our images, the "kernel" isn't auto updated. This allows users to > stay on whatever kernel version they started development on: (With > options from: 3.8.x/3.14.x/4.1.x/4.4.x/4.9.x/4.14.x) > > To get

Re: Why so little info on the Pocket Beagle?

On Wed, Oct 4, 2017 at 8:31 PM, Nigel Sollars wrote: > Um no I dont think so, > > Here is why, as these kernels by Robert have worked real well with my BBB > Rev B. I have had on odd occasions a kernel panic, allowing unsuspected > folk to this end would I think create

Re: Why so little info on the Pocket Beagle?

On Tue, Oct 3, 2017 at 4:14 PM, Lennart Sorensen <lsore...@csclub.uwaterloo.ca> wrote: > On Tue, Oct 03, 2017 at 02:59:04PM -0400, Jeffrey Walton wrote: >> For your first boot you usually attach a HD monitor and keyboard to >> get through the administrivia, like setting a roo

Re: Why so little info on the Pocket Beagle?

On Tue, Oct 3, 2017 at 2:49 PM, Lennart Sorensen wrote: > On Tue, Oct 03, 2017 at 10:30:16AM -0400, Nigel Sollars wrote: >> The CPU is already well documented with beaglebone (all versions ) .. I >> would be very surprised if this puppy did not work out of the box. >

Introducing 2017’s extensions to the Arm Architecture

In case it did not make your radar: https://community.arm.com/processors/b/blog/posts/introducing-2017s-extensions-to-the-arm-architecture It looks like ARMv8.4 will also provide hardware support for China's SM3 (hash) and SM4 (block cipher), like they support SHA and AES. Jeff

Re: arm64 support?

> I asked about arm64 support about a month back and basically got a not > much answer. I have a pair of the 4GB rockchip rock64's that I'd love to > replace a pi3b with. > > ... > So I am wondering where I should go looking for an arm64 image to install > if there actually is one now? Usually

Re: Is there a way to make the pi use swap?

On Fri, Sep 14, 2018 at 8:16 PM, Alan Corey wrote: > My /etc/fstab just has > /var/swap2 none swap sw 0 0 > That's for a swap file which was made by dding 0s into it, then running > mkswap. > > You'd replace /var/swap2 with /dev/sda2 > > Sounds like you're just not loading it from your fstab.

Re: Does ARMEL toolchain include NEON support?

On Thu, Feb 28, 2019 at 1:18 PM Wookey wrote: > > On 2019-02-28 09:05 +, Ian Campbell wrote: > > > > To spell it out: the gist of this is that it isn't possible to provide > > a single arm binary which works well for both armel and armhf (which I > > think is what Jeff is trying/wants to

Does ARMEL toolchain include NEON support?

Hi Everyone, I'm investigating a failed build for ARMEL. I don't have access to the build machine so I have to study the logs or ask our package maintainer to run commands for us. The build log is at https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B=experimental (package) and

Re: Does ARMEL toolchain include NEON support?

On Wed, Feb 27, 2019 at 4:01 PM Steve McIntyre wrote: > > On Wed, Feb 27, 2019 at 02:16:46PM -0500, Jeffrey Walton wrote: > > > >I'm investigating a failed build for ARMEL. I don't have access to the > >build machine so I have to study the logs or ask our package >

Re: Does ARMEL toolchain include NEON support?

On Wed, Feb 27, 2019 at 2:59 PM Vagrant Cascadian wrote: > > On 2019-02-27, Jeffrey Walton wrote: > > I'm investigating a failed build for ARMEL. I don't have access to the > > build machine so I have to study the logs or ask our package > > maintainer to run commands f

Re: Does ARMEL toolchain include NEON support?

On Wed, Feb 27, 2019 at 5:46 PM Steve McIntyre wrote: > > ... > >The problem is, I don't know what the output of or 'g++ -dumpmachine' > >or 'uname -m' are, so I am not sure if we are misdetecting IS_ARM32 or > >IS_NEON . > > So, I've got to ask - what hardware are you likely targeting here >

Re: openssl sha1 not working with large files on stretch arm.

On Thu, Apr 11, 2019 at 11:24 AM peter green wrote: > > I got a report from a user about "openssl sha1 " not working for > large files on raspbian stretch. > > I investigated the problem and found that when I tried to use "openssl sha1 > " for a large (>2GB) file on Debian armhf stretch or

Re: Selecting compatible Raspberry Pi components

On Sun, May 3, 2020 at 12:59 PM Richard Owlett wrote: > > I've been thinking about what a handheld computer COULD be. > My image is heavily influenced by my recollection of Palm Pilot. > > My project goals are two-fold >1. create a personal data logger reminiscent of a Palm Pilot >2.

OT: Huge Right to Repair Win for Consumers

Hi Everyone, This is not as off-topic as it may seem. In the US, the FTC just issued a report that favors consumers. The report and its recommendations may provide a means to pierce the veil of closed platforms, like closed-sourced firmware. It also looks like the Magnuson-Moss Warranty Act will

Re: Feedback from the community -> ARM

On Fri, Jun 11, 2021 at 2:20 PM Diederik de Haas wrote: > ... > [1] https://lwn.net/Articles/749530/ That's an interesting project. Thanks for that link. Insecure infrastructure (and other gadgets, like home routers) is such a problem I hope the CIP project can get funding from places like the

Re: Feedback from the community -> ARM

>> This is no longer relevant, since the arm64 and armhf capable RPi >> boards are way more popular than the old boards now. >> >> https://wiki.debian.org/PaulWise >> > > Pi Zero is still ARM v6 :( And the RPI-1's. I still have one to test Botan, Crypto++, GnuPG and OpenSSL on ARMv6. Jeff

Re: hardware encryption

On Wed, Jan 20, 2021 at 5:40 AM wrote: > ... > this thing about hardware accelerated encryption is a bit of a mystery > to me > some processors advertise it but how do we know if it's being used > is there a way to test if hardware accelerated encryption is being used > or if it's just

Re: hardware encryption

On Thu, Jun 3, 2021 at 10:50 AM Diederik de Haas wrote: > > On woensdag 20 januari 2021 11:40:26 CEST brainf...@posteo.net wrote: > > hardware accelerated encryption is a bit of a mystery to me > > some processors advertise it but how do we know if it's being used > > is there a way to test if

Re: hardware encryption,Re: hardware encryption

> https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators#finding_out_what_s_available_in_the_kernel > is the only page I found wrt /proc/crypto and I do indeed have > several 'skcipher' and 'shash' nodes with prio >= 300. > That article also speaks about /dev/crypto, but I

OT: Right to Repair Executive Order in US

Hi Everyone, This just came down the pipe for folks in the US: https://www.theverge.com/2021/7/9/22569869/biden-executive-order-right-to-repair-isps-net-neutrality. The Executive Order squarely targets tech. Also see Steve Lehto's analysis https://www.youtube.com/watch?v=6qyYEvcS5-8. Lehto is a

Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

On Tue, Mar 2, 2021 at 3:48 PM Arnd Bergmann wrote: > > On Tue, Mar 2, 2021 at 7:51 PM LinAdmin wrote: > > > > There is really no good reason to run a 32-bit /kernel/ on the Pi 4, > > > especially the version > > > with 8GB RAM. While the bug should get fixed in principle to make the > > >

Re: Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

On Sat, Feb 27, 2021 at 1:21 PM Bernhard Übelacker wrote: > > I have retried with the patch in #974828, but it still > crashed with the test files from this bug, therefore > I guess #974828 is similar but unrelated. > > Then I took another look at the valgrind runs and found > that these invalid

Re: Reducing apt's memory footprint (on small boxes)

On Sun, Feb 14, 2021 at 9:22 PM Paul Wise wrote: > > On Sun, Feb 14, 2021 at 2:53 PM Paul Wise wrote: > > > I think that this could be useful to a subset of Debian users, > > possibly including embedded hardware and low-RAM cloud/VPS users. > > This could also be useful to bandwidth-constrained

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

On Sun, Feb 21, 2021 at 8:58 AM Reco wrote: > > Hi. > > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote: > > I guess a question is why you want an RTC. If you have a decent > > internet connection just run NTP on something and it will set the > > computer's clock. > > IPSec,

Re: Debian on Raspberry Pi and Pine* and probably ARM support in general (was Re: Debian on Pine64 H64B?)

On Sat, Sep 11, 2021 at 4:27 AM Keith Bainbridge wrote: > ... > There's an interesting review of the Pro here: > https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/ > > Sounds interesting. Pity they are out of stock They seem to be always out of stock. I've been trying to buy a

Re: Debian on Pine64 H64B?

On Sat, Sep 11, 2021 at 11:19 PM Gunnar Wolf wrote: > ... > > OK, but nslookup raspi.debian.net and whois 208.97.148.173 shows > > raspi.debian.net is hosted at NightmareHost, which probably explains > > the very long delays in seeing the site sometimes. I respect > > Gunnar's support for

Debian armhf test system?

Hi Everyone, We are trying to track down the cause of a build failure on Debian; see [1]. I want to setup a Debian armhf system for testing. (I have about 6 testing boards, but they are other OSes). I found the relevant area of the manual that says Debian supports armel, armhf and arm64,[2] but

Re: armhf SIGILL, Illegal Instruction

On Wed, Sep 29, 2021 at 5:05 PM peter green wrote: > > As I understand it, there are two variants of "VFPv3", a version with 32 > double registers (d0 to d31) and a version with only 16 double registers (d0 > to d16). > The former is reffered to by gcc as "vfpv3" while the latter is reffered to

Re: armhf SIGILL, Illegal Instruction

On Wed, Sep 29, 2021 at 4:06 PM Ash Hughes wrote: > > Hi, > > I've been getting some programs terminated with SIGILL today, and I'm > trying to find out if this is a package issue or if Debian (Bullseye) is > no longer compatible with my ARM machine. I first got an error with > onedrive, with gdb

Re: armv8 does not respect personality ADDR_LIMIT_3GB

On Tue, Oct 5, 2021 at 4:00 PM Lennart Sorensen wrote: > > ... > This fixnum idea in gcl is broken. It must go away. Pointers are for > addresses and nothing else. +1. Tagged pointers caused a lot of problems porting some packages to Aarch64. Tagged pointers were blocking a number of web

Re: Debian armhf test system?

On Sat, Sep 25, 2021 at 9:59 AM Jeffrey Walton wrote: > > Can someone provide a recommendation for a readily available armhf > device? Like something I can order from Amazon? Thanks everyone. I ordered a device. Jeff

Re: armhf: abel.d.o hardware status ?

On Wed, Jun 29, 2022 at 11:34 AM Wookey wrote: > > On 2022-06-29 15:13 +0200, Mathieu Malaterre wrote: > > On Wed, Jun 29, 2022 at 2:48 PM Wookey wrote: > > > > What exactly is going wrong when you try to use valgrind? > > > > Well you should see something like this on abel.d.o: > > > > *

Re: vldm on armhf?

On Wed, Jul 20, 2022 at 3:40 PM Thorsten Glaser wrote: > > Dixi quod… > > >did something change wrt. compiler defaults on armhf recently? > > armel also FTBFS with SIGILL in the testsuite. > > So something changed incompatibly between 2019-11-10 and now > in the ARM toolchain. But what, and how

Re: Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

On Tue, Aug 23, 2022 at 4:40 PM Simon McVittie wrote: > > Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786623 > Control: affects -1 + src:mozjs102 > > On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote: > > The final link fails with multiple definitions of the

Re: [Y2038] debian/armhf time64 build?

On Wed, Sep 28, 2022 at 3:24 AM Dominique MARTINET wrote: > ... > Ugh, this is going to be a massive headache... > Other distributions I've worked with (e.g. nixos) have a wrapper for gcc > and clang that just enforce the flags they want the distro to be built > with -- I don't think debian has

Re: abel.d.o + gcc-12.x

On Mon, Sep 5, 2022 at 2:54 AM Mathieu Malaterre wrote: > > Dear Debian arm porters, > > I have two requests: > > - Could someone please check the status of abel.d.o ? (*) > - One of gcc dev asked me to verify the status of a bug in gcc-12.x > branch. Are there any pre-build version of GCC 12.x

Re: armbian for arm64's is 99% debian testing for arm64's.

On Wed, Dec 28, 2022 at 4:17 PM gene heskett wrote: > > But its dfu-util is truly ancient at version 0.9 > version 0.10 has been available for several years if I read ticket dates > on sourceforge correctly. > > dfu-util-v0.9 on a banana pi m5, cannot do any dfu-utils duties. sudo > dfu-util -l

Re: MariaDB 10.11 issue on armel/armhf

On Mon, Jan 16, 2023 at 10:21 PM Otto Kekäläinen wrote: > > Are there any ARM experts here interested in helping MariaDB 10.11 run > better on armel/armhf? > > The issue is explained well in upstream bug > https://jira.mariadb.org/browse/MDEV-30411 but upstream is not > investing

Re: Looking for an armhf install image

On Mon, Apr 3, 2023 at 8:03 AM Lennart Sorensen wrote: > > On Sun, Apr 02, 2023 at 09:51:23PM -0400, Alan Corey wrote: > > I know I can but it will be twice as slow, which is why I want armhf. > > Under 64 bit both the data and pointers will be twice as big. With > > unlimited memory that would

Re: Debian on Lenovo Chromebook (ARMv8)

On Thu, Mar 30, 2023 at 4:38 PM Thomas Uwe Grüttmüller wrote: > > I recently bought a Chromebook with the intent to delete Chrome and > install Debian. I’m not talking about running Debian in a virtual > machine or chroot environment under ChromeOS, but booting directly into > it. The laptop is a

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox wrote: > > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote: > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in > > > MAINTAINERS and if distros are going to do such a damnfool thing, > > > then we

Re: unbreaking LibreOffices tests on at least release architectures

On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard wrote: > > Am 22.07.23 um 14:02 schrieb Andreas Schwab: > > On Jun 18 2023, Rene Engelhard wrote: > > > >> For riscv64 I already pointed that out in the thread starting at > >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the

Re: unbreaking LibreOffices tests on at least release architectures

On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard wrote: > > Am 20.06.23 um 00:03 schrieb Jeffrey Walton: > > > > You can usually uncover them by building the package with CFLAGS=" ... > > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined

Re: unbreaking LibreOffices tests on at least release architectures

On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard wrote: > > Hi, > > Am 19.06.23 um 23:19 schrieb Adrian Bunk: > > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: > >> ... > >> I won't be of much help here unfortunately, except > >> maybe testing patches, but then again there's

Re: RM: icinga2 [armel mips64el ppc64el riscv64] -- ROM; FTBFS

On Tue, Jan 2, 2024 at 11:44 PM Sebastiaan Couwenberg wrote: > > On 1/3/24 00:02, Aurelien Jarno wrote: > > On 2023-12-22 15:43, Bas Couwenberg wrote: > >> Please remove icinga2 from armel, mips64el, ppc64el, riscv64 where it > >> FTBFS to unblock testing migration. > > > > What is the reasoning

Re: Ability to further support 32bit architectures

On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank wrote: > > On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote: > > Disabling debug symbols, enabling debug symbol zstd compression, using > > split debug symbols (disabled BTF usage) should help here. > > Okay, maybe more workarounds

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

On Tue, Mar 26, 2024 at 6:30 PM Thorsten Glaser wrote: > > [...] > > The options for the armel/armhf porters are to either get the > .debs from me, install them in a chroot, and then the other B-D, > and rebuild the packages, or to use dpkg --force-depends to > install the dependencies (which

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

On Tue, Mar 26, 2024 at 7:44 PM Thorsten Glaser wrote: > > I’m answering back from the $dayjob address because Googlemail > cannot communicate with normal mailservers. > > >I can send you two dev boards, if you want them. The first is > >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second