Re: Bug#1074111: [arm64] boot stops at 'Starting kernel ...' without any further output when kernel built with recent binutils

Version: 2.42.90.20240720-1 On Monday, 22 July 2024 17:53:01 CEST Emanuele Rocca wrote: > Hi Diederik, Hi Emanuele, > On 2024-07-22 10:15, Diederik de Haas wrote: > > The referenced commit is part of 2.42.90.20240720-1, so this bug can be > > closed (and the workaround for

Re: Bug#1074111: [arm64] boot stops at 'Starting kernel ...' without any further output when kernel built with recent binutils

On Monday, 15 July 2024 20:37:54 CEST Emanuele Rocca wrote: > On 2024-06-26 03:19, Emanuele Rocca wrote: > > Binutils upstream is now looking at the issue, see: > > https://sourceware.org/bugzilla/show_bug.cgi?id=31924 > > > > For the time being we could explicitly set CONFIG_RELR=n in > >

Re: Raspberry Pi: gpiomem device support

On Wednesday, 3 April 2024 21:49:45 CEST Thomas Lehmann wrote: > Ah, and I found Kernel code in drivers/char/raspberrypi-gpiomem.c and > the accompanying Kconfig defining the config "RASPBERRYPI_GPIOMEM". That file and that module/symbol do NOT exist in the upstream Linux kernel (probably only

Re: Can't connect Raspberry Pi 3B+ Rev. 1.3 to Wifi 5G

On Friday, 17 November 2023 19:58:22 CET basti wrote: > @Diederik I'am not sure if OpenWRT is the Problem. Other clients can > connect to 5G Wifi. Or did you mean that Raspi does not Support DFS? I had to put my OpenWrt router on a non-DFS channel for 5G, otherwise I couldn't connect to it. But

Re: Can't connect Raspberry Pi 3B+ Rev. 1.3 to Wifi 5G

On Friday, 17 November 2023 16:53:41 CET basti wrote: > The Access Point is OpenWRT and operate in > AC mode, Channel 64 (5320 MHz). > ... > root@debian:~# iw reg get > global > country DE: DFS-ETSI > (2400 - 2483 @ 40), (N/A, 20), (N/A) > (5150 - 5250 @ 80), (N/A, 23), (N/A),

Re: RFC: android-style boot image support for flash-kernel

On Sunday, 30 April 2023 23:28:23 CEST Roger Shimizu wrote: > Currently, the dev-board is supported by Linaro [2][3], and most > kernel device-tree, patches and firmware are already upstreamed. > I confirmed that with simple snippet below, generated boot.img can be > used to boot the RB3 / DB845c

Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

On Sunday, 16 April 2023 11:17:43 CEST Georg Gast wrote: > ExecStart=/bin/sh -c "modprobe i2c_bcm2835 && modprobe i2c_bcm2708 && > modprobe rtc_ds1307 && sleep 1 && echo ds1307 0x68 > > /sys/class/i2c-adapter/i2c-1/new_device && /sbin/hwclock -s" Nice :-) I wonder whether this (essentially) is

Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

On Sunday, 16 April 2023 04:47:37 CEST Rick Thomas wrote: > I've got a Raspberry Pi 4B (4GB) with a DS3231 RTC module. I can make the > combo work with Ubuntu and RaspberryPI-OS. I'd like to try it with the > plain-vanilla Debian from but I > can't find

Re: Looking for an armhf install image

On Monday, 3 April 2023 03:51:23 CEST 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 be OK but a Pi CPU can only access 1 GB. > I've tried 64 bit. For the

Re: Installation of bookworm on cubox-i

On Saturday, 18 March 2023 22:37:55 CET Rainer Dorsch wrote: > Any feedback is welcome :-) Please report installation issues to debian-boot@l.d.o signature.asc Description: This is a digitally signed message part.

Re: Bug#1032362: Kernel doesn't find SATA ports on Softiron 1000 (arm64 Seattle)

On Sunday, 5 March 2023 03:08:23 CET Steve McIntyre wrote: > On Sun, Mar 05, 2023 at 12:09:24AM +, Steve McIntyre wrote: > >Source: linux > >Version: 6.1.12-1 > > > >I've just upgraded my Seattle-based system to bookworm and it no > >longer finds the onboard AHCI SATA storage so it stops at an

Re: abi-compliance-checker and library transitions [Re: another attempt at Y2038]

On Monday, 20 February 2023 16:24:37 CET Arnd Bergmann wrote: > On Wed, Feb 15, 2023, at 18:08, Wookey wrote: > > On 2023-02-04 21:42 -0800, Steve Langasek wrote: > >> On Thu, Oct 20, 2022 at 09:42:58PM -0700, Steve Langasek wrote: > >> > >> Does doing an ABI transition of ~113 libraries seem

Re: Support for Orange Pi 4 LTS

I'll give a general answer to the best of my knowledge, which may be flawed and/or incomplete. Hopefully others will add to and/or correct me. On Friday, 10 February 2023 16:57:07 CET Andrew M.A. Cater wrote: > On Fri, Feb 10, 2023 at 09:06:10AM +0100, Christian Marillat wrote: > > Is Orange Pi

Re: neon: armhf baseline for next release ?

On Friday, 10 February 2023 22:30:18 CET Arnd Bergmann wrote: > This does not sound quite correct either: while no new SoCs have come > out without NEON for ten years now (the last ones were Tegra 2, I recently brought my Asus Transformer TF-101 'back to life' and was absolutely thrilled that I

Re: Bug#1029543: hw-detect: clarify use cases about searching for firmware packages on external media

On Wednesday, 25 January 2023 23:01:01 CET Diederik de Haas wrote: > This sounds like a nice solution for the SD card images. > I myself always use a wired connection, but I saw yesterday that someone > tried to use d-i for RockPro64 but didn't get any output on screen and then > tried

Re: Bug#1029543: hw-detect: clarify use cases about searching for firmware packages on external media

On Wednesday, 25 January 2023 20:22:33 CET Cyril Brulebois wrote: > # SD card images (might also be applicable to the upcoming ChromeOS images) > ... > All of this assuming that the end results can be appended as the third > part of the + + combination! This sounds like a nice solution for the

Re: Enable V3D on Raspberry Pi 4!

On Thursday, 19 January 2023 19:02:58 CET Sally A.haj wrote: > Since the release of kernel 6.0.X, which has been announced the enabling > of v3d to support hard acceleration in RPi4, I've tried tested/daily > image from raspi.debian.net, the latest test, I installed Gnome, and I > can see from

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

On Thursday, 29 December 2022 04:29:02 CET Paul Wise wrote: > > Armbian != Debian. > > While that is true, it seems that Armbian is an overlay derivative, > which means that they just use Debian binaries for most packages, While that is also true, Armbian does make their own kernel, with custom

Re: Bug#1016963: Help with testing u-boot!

On Thursday, 29 December 2022 04:33:51 CET Rick Thomas wrote: > Rebooting while watching the serial console output says "U-Boot SPL > 2016.05-rc2+dfsg0~20160423~1-1 (Apr 24 2016 - 04:24:21)" So the firmware > does not correspond to what aptitude says. The main difference with your other

Re: Help with testing u-boot!

On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote: > debian stable (2021.01*), testing (2022.04*), unstable (2022.10*) > and experimental (2023.01-rc*) > > # arm64 > ... > rock64-rk3328 I don't recall ever having issues with u-boot on my Rock64's, so for me 2022.04 - 2022.10

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

On Wednesday, 28 December 2022 22:35:28 CET Andrew M.A. Cater wrote: > hang out on IRC on debian-arm or debian-boot Or #armbian on libera signature.asc Description: This is a digitally signed message part.

Re: Raspberry Pi 1B cpu scaling

On Friday, 11 November 2022 10:25:58 CET basti wrote: > I have installed the 20220121_raspi_1_bullseye.img.xz image from > https://raspi.debian.net/tested-images/ > on one of my old Raspberry Pi 1B. > > As I can see cpu scaling seems to not work. Support for CPU frequency scaling on the RPi 0/1

Re: how to enable spi on Raspberry Pi 4 (bookworm)?

On Sunday, 30 October 2022 18:04:28 CET Sebastian Kuzminsky wrote: > The Raspbian Buster armhf binaries can be made to run on Debian Bookworm > arm64 with a little bit of coaxing, but they rely on kernel features > that are not in Bookworm's arm64 kernel Do you know which kernel features? I can

Re: Building (Debian) kernel optimized for RPi Zero (W) and 1

On Tuesday, 25 October 2022 14:34:12 CEST Diederik de Haas wrote: > > and entirely based on the kernel patches that are added on top of mainline > > as well as the configuration. The patch set may be more substantial then I initially thought. In 2015 I asked plugwash the general proce

Re: Building (Debian) kernel optimized for RPi Zero (W) and 1

On Tuesday, 25 October 2022 12:01:01 CEST Arnd Bergmann wrote: > > I have a Zero W running Debian's armel kernel and I find that device to be > > annoyingly slow. > > I also have a RPi 1 running raspbian.org's 4.9 kernel, which is a special > > kernel build by plugwash and compiled like the rest

Re: Building (Debian) kernel optimized for RPi Zero (W) and 1

On Tuesday, 25 October 2022 11:33:40 CEST Arnd Bergmann wrote: > > IIUC, for the kernel, either compiler should be fine. The > > documentation[0] for compiling the RPi Zero kernel seems to bear this > > out - it even uses the "CROSS_COMPILE=arm-linux-gnueabihf-". If you've > > got access to the

Re: Building (Debian) kernel optimized for RPi Zero (W) and 1

On Tuesday, 25 October 2022 10:02:09 CEST Andrew M.A. Cater wrote: > Debian armel runs fine without recompilation at a slight penalty. It is exactly this 'slight penalty' that I want to verify. I have a Zero W running Debian's armel kernel and I find that device to be annoyingly slow. I also

Re: Building (Debian) kernel optimized for RPi Zero (W) and 1

On maandag 24 oktober 2022 11:16:42 CEST Punit Agrawal wrote: > I am probably missing some context but I wanted to point to the armel > cross compiler in Debian - gcc-arm-linux-gnueabi. Is there some reason > to build the cross-compiler yourself? I don't want to build for armel, but for

Building (Debian) kernel optimized for RPi Zero (W) and 1

Hi, Debian provides a kernel for Raspberry Pi Zero (W) and 1, but that targets the armel architecture. I want to compile a/the Debian kernel that does use the HW capabilities of the RPi 0/1, similarly to how raspbian.org recompiles the Debian packages. Except AFAIK the Debian kernel. I know that

Re: Looking for testers for Quartz64 patch for Debian kernel

On Sunday, 16 October 2022 14:15:17 CEST Diederik de Haas wrote: > I would like to add initial support for (various) Quartz64 devices from > Pine64 to the Debian kernel. I've made a patch for it (attached). I just noticed that CONFIG_MOTORCOMM_PHY isn't "=y", but "=m&

Re: Looking for testers for Quartz64 patch for Debian kernel

On Sunday, 16 October 2022 14:15:17 CEST Diederik de Haas wrote: > you'd do that by building a kernel with the patch Of course it's better to build from source yourself, but as a convenience I've also build them and uploaded it here: https://mateloos.be/~diederik/kernel/quartz64/ signature.

Looking for testers for Quartz64 patch for Debian kernel

rom af034db5cee66c141446ee52d8cce00092b0779d Mon Sep 17 00:00:00 2001 From: Diederik de Haas Date: Sun, 21 Nov 2021 15:47:46 +0100 Subject: [PATCH] Add initial support for Pine64's Quartz64 devices https://wiki.pine64.org/wiki/Quartz64_Development gives a very good overview of components needed by Quart

Re: insecure W+X mapping

On Thursday, 28 July 2022 19:30:55 CEST Rainer Dorsch wrote: > I do not observe any functional issue so far though. > > There is a similar report here, but is seen on a 5.13 kernel: > https://lore.kernel.org/all/yun2qpc5ibaiv...@shell.armlinux.org.uk/T/ > > Not sure if it was already present in

Re: latency test results for armhf vs arm64?

On Saturday, 16 July 2022 18:19:31 CEST gene heskett wrote: > > You said raspios which sure looks like raspian. Raspian/Raspberry Pi > > OS is armv6. If you are running Debian armhf, then it is armv7 but it > > would be a lot less confusing to call it Debian and not raspios in > > that case. >

Re: Performance degraded, Bookworm on Raspberry Pi 4B

On Tuesday, 15 March 2022 13:32:37 CET Hank Barta wrote: > Some additional information that might be useful is that the system seems > unable to determine CPU frequencies. For example > > root@up:~# cpupower frequency-info > analyzing CPU 0: > no or unknown cpufreq driver is active on this CPU

Re: Performance degraded, Bookworm on Raspberry Pi 4B

On Tuesday, 15 March 2022 05:20:02 CET Gunnar Wolf wrote: > Given you have already pursued the situation to this detail, could you > share... between which versions do you see the regression? raspi-firmware/testing 1.20220120+ds-1 arm64 [upgradable from: 1.20210805+ds-1] signature.asc

Re: uboot@qnap - debian

On Saturday, 12 February 2022 16:14:19 CET Philippe Clérié wrote: > My apologies for the confusion. *Pi OS* here was meant as a shortcut for > the *official* distribution of Debian for the Raspberry Pi. Which I am > using by the way. Which is still confusing, because I'm not aware of an 'official

Re: Debian on Pine64 H64B?

On zondag 12 september 2021 01:26:37 CEST Oregano 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 raspi's, but the

Re: Replacement for raspPi

On donderdag 9 september 2021 00:21:27 CEST Andrew M.A. Cater wrote: > DRAT - I mistyped - the Rock64 and the RockPro64? - the Rock64 has 4G of > memory and a good selection of I/O, 1G Ethernet and the potential for eMMC > storage. The RockPro has even more. I'd suggest going for the RockPro64

Re: Rpi compute module 4

On donderdag 19 augustus 2021 18:50:54 CEST Andrew M.A. Cater wrote: > Raspberry Pi OS is off-topic here True, but I'm not sure this case is off-topic as (iiuc) Lucas found a solution for Raspbian. The problem could use more details/specifics though. Lucas' use of 'raspi' could mean a bunch of

Re: Feedback from the community -> ARM

On maandag 14 juni 2021 14:06:36 CEST John Paul Adrian Glaubitz wrote: > This is actually the only solution you have. My response was based on disagreeing with "the only solution", which Adrian Bunk made too. Consequently, I also disagree with your statement. As almost all companies only seem

Re: Feedback from the community -> ARM

On maandag 14 juni 2021 13:15:07 CEST Adrian Bunk wrote: > Any solution to the abandonware problem for consumer products has to be > political, you need a law mandating for how many years repairs and > security updates have to be available. There is another type of solution that you can do right

Re: Feedback from the community -> ARM

Hi! On vrijdag 11 juni 2021 18:38:46 CEST Uwe Kleine-König wrote: > IMHO the version to pick is always the current tip of the development > tree. I understand that from a (kernel) developer's POV. > Assuming the vendors get their changes into mainline users are > free to use any later kernel.

Re: Feedback from the community -> ARM

Hi Uwe, On vrijdag 11 juni 2021 15:20:34 CEST Uwe Kleine-König wrote: > In my bubble most vendor kernel already do this. They align however not > to an ELTS kernel, but to the Android universe. That's at least the case > for NXP which is quite dominant in my bubble. Lucky you :) I'm not very

Re: Feedback from the community -> ARM

On donderdag 10 juni 2021 16:43:44 CEST Uwe Kleine-König wrote: > - Fragmentation > - Vendor kernels vs. mainline > This got better in the past is my subjective impression, but it > still hurts. Device tree made this a tad simpler, but it's not > unusual to have vendor

Re: Feedback from the community -> ARM

On vrijdag 11 juni 2021 09:25:07 CEST Ralph Aichinger wrote: > I really think Debian should have a better answer to installing > on the Raspberry Pi I think the problem isn't on Debian's side, but on the side of the Raspberry Pi Foundation (RPF). If they would upstream more/sooner or better yet,

Re: Feedback from the community -> ARM

On donderdag 10 juni 2021 21:43:38 CEST Andrew M.A. Cater wrote: > Just get _someone_ to make a good quality 64 bit server which doesn't cost > the earth and works well with UEFI and relatively standard interfaces > and components. +1 > get something that looks like a performant mini-ATX / itx

Re: Feedback from the community -> ARM

On donderdag 10 juni 2021 18:44:23 CEST Marcin Juszkiewicz wrote: > 3. How many years we need to wait for Arm systems to work out-of- > the-box? I mean unpack, connect input/video/power, boot generic > distro installer, install, reboot and use. So far there are > nearly no such ones

Re: hardware encryption,Re: hardware encryption

On vrijdag 4 juni 2021 14:05:28 CEST Jeffrey Walton wrote: > Yeah, kernel crypto is not well documented (in my opinion). It's a complicated subject with various nuances and if you're not "in the know", like I am, it's very hard to f.e. qualify/quantify whether having "ARM CE" is just nice

Re: hardware encryption,Re: hardware encryption

[Note that I've combined the output of several posts for comparison] [As a result I've also made several edits for consistency/readability] On donderdag 3 juni 2021 21:40:04 CEST Ryutaroh Matsumoto wrote: > From: Ryutaroh Matsumoto > > Note that openssl version is much older ... with Debian

Re: hardware encryption,Re: hardware encryption

On donderdag 3 juni 2021 21:40:04 CEST Ryutaroh Matsumoto wrote: > > Note that openssl version is much older but it is bundled with Debian > > Bullseye. > I installed openssl ver. 3 from Debian experimental, > and observed much slower speed than ver. 1.1.1 in Debian Bullseye, > on the same

Re: hardware encryption,Re: hardware encryption

m does NOT have a license to them > From: Diederik de Haas > Date: Thu, 03 Jun 2021 19:34:19 +0200,Thu, 03 Jun 2021 19:34:19 +0200 > > > $ openssl speed aes-128-cbc > > The 'numbers' are in 1000s of bytes per second processed. > > type16 bytes

Re: hardware encryption

On donderdag 3 juni 2021 17:52:50 CEST Jeffrey Walton wrote: > I _think_ OpenSSH uses OpenSSL, not kernel crypto. If that means that hardware/accelerated crypto is dependent on the program being used, that would suck > To benchmark OpenSSL, you use something like: > # C implementation >

Re: hardware encryption

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 hardware accelerated encryption is being used > or if it's just

Re: Enabling (HDMI) audio on rk3328/rk3399 (Rock64/RockPro64)

On maandag 10 mei 2021 15:17:24 CEST Diederik de Haas wrote: > I may be wrong here, but it appears that for the Rock64, 'audio-graph-card' > is used for 'sound' while 'simple-audio-card' is used for 'hdmi-sound'. s/Rock64/RockPro64/ signature.asc Description: This is a digitally signed m

Re: Enabling (HDMI) audio on rk3328/rk3399 (Rock64/RockPro64)

they showed status "okay" for both the nodes. Excellent. I made the request without doing ('proper') research into rk3399/RockPro64, but I just took a look based on your msg and it appears that the dts[i] files for rk3399/RockPro64 are far more 'evolved' (more detailed/enabled nodes

Enabling (HDMI) audio on rk3328/rk3399 (Rock64/RockPro64)

In order to get better multimedia support in Debian kernels, primarily for arm64 SBCs, I filed https://bugs.debian.org/987576 requesting CONFIG_SND_AUDIO_GRAPH_CARD to be enabled. The idea came from seeing an upstream commit titled "arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD" and the

Re: Raspi 4 debian image update-initramfs

On vrijdag 23 april 2021 16:27:05 CEST Vorak David Hoeung wrote: > Have you any idea ? You need a newer image which contains initramfs-tools version 0.140, where the reset_raspberrypi module gets included. You need that for USB boot to work. You should try a daily built image as that does have

Re: WiFi on RPi

On dinsdag 2 maart 2021 00:04:01 CET oreg...@disroot.org wrote: > Edit /etc/network/interfaces.d/wlan0 > Uncomment lines and change to my wifi SSID and password. > ... > It's probably better, more secure, to use WPA-PSK so the password is > encrypted, but the above was simpler and worked. You can

Re: Debian Bullseye on Raspberry Pi 4 4GB?

On zaterdag 20 februari 2021 13:46:00 CET Rick Thomas wrote: > Hmmm... The "tested images" page [1] lists images for both Buster and > Bullseye that reportedly boot on the RPi 0W. I don't know what they had to > do to make it work. They're cheap enough that I may just buy one and try > it, for

Re: Debian Bullseye on Raspberry Pi 4 4GB?

On vrijdag 19 februari 2021 18:03:34 CET Pete Batard wrote: > I agree that, without OP clarifying, this is open to interpretation. That was my point, which resulted in: let's give OP as many options as possible so he can choose for himself. > As the provider of a custom image, I can understand

Re: Debian Bullseye on Raspberry Pi 4 4GB?

On vrijdag 19 februari 2021 15:48:41 CET Pete Batard wrote: > On 2021.02.19 13:37, Diederik de Haas wrote: > > On vrijdag 19 februari 2021 00:02:27 CET Rick Thomas wrote: > >> Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from > >> a CD/DVD or

Re: Debian Bullseye on Raspberry Pi 4 4GB?

On vrijdag 19 februari 2021 00:02:27 CET Rick Thomas wrote: > Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a > CD/DVD or USB Flash stick or uSDcard? > > If so, where would I look for instructions for doing so? https://raspi.debian.net/tested-images/ contains a

Re: Rockchip RK3399 based board for server use?

On zaterdag 11 januari 2020 20:42:24 CET David Pottage wrote: > Are there any other boards or chipsets I should be considering? I have > not considered the RaspberryPi, because of heat issues, and because in > older versions most of the I/O passed through the USB PHY, so file > server performance