Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #89399 > unrolled thread

Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot

Started byBenjamin Drung <bdrung@debian.org>
First post2025-09-24 20:50 +0200
Last post2025-12-18 13:40 +0100
Articles 14 — 5 participants

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Benjamin Drung <bdrung@debian.org> - 2025-09-24 20:50 +0200
    Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Benjamin Drung <bdrung@debian.org> - 2025-10-30 20:40 +0100
      Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Uwe Kleine-König <u.kleine-koenig@baylibre.com> - 2025-11-05 20:20 +0100
        Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Benjamin Drung <bdrung@debian.org> - 2025-11-17 02:10 +0100
    Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Benjamin Drung <bdrung@debian.org> - 2025-11-22 16:30 +0100
      Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Salvatore Bonaccorso <carnil@debian.org> - 2025-11-26 09:00 +0100
        Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Benjamin Drung <bdrung@debian.org> - 2025-11-28 23:00 +0100
          Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Salvatore Bonaccorso <carnil@debian.org> - 2025-11-29 00:10 +0100
            Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Salvatore Bonaccorso <carnil@debian.org> - 2025-11-30 10:30 +0100
              Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Benjamin Drung <bdrung@debian.org> - 2025-12-17 22:30 +0100
                Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Benjamin Drung <bdrung@debian.org> - 2025-12-17 23:20 +0100
    Processed: Re: Bug#1116251: linux-image-6.12.48+deb13-rpi:  Raspberry Pi Zero W does not boot "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-11-26 09:00 +0100
    Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot Marek Szyprowski <m.szyprowski@samsung.com> - 2025-12-18 12:50 +0100
    Processed: Re: Bug#1116251: linux-image-6.12.48+deb13-rpi:  Raspberry Pi Zero W does not boot "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-12-18 13:40 +0100

#89399 — Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot

FromBenjamin Drung <bdrung@debian.org>
Date2025-09-24 20:50 +0200
SubjectBug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot
Message-ID<LyCIV-hVz-7@gated-at.bofh.it>
Package: src:linux
Version: 6.12.48-1
Severity: normal
X-Debbugs-Cc: bdrung@debian.org

Hi,

I have three Raspberry Pi Zero W running trixie headless. All stopped
working after upgrading to linux-image-6.12.48+deb13-rpi. Since they are
headless, I removed the SD card and checked the logs on there. The last
logs where from upgrading to linux-image-6.12.48+deb13-rpi and the
shutdown (from the reboot). There were no logs from the
linux-image-6.12.48+deb13-rpi boot. So it probably failed to boot in the
kernel or initrd (before switching to the root fs).

I changed the kernel+initrd in /boot/firmware/config.txt from
6.12.48+deb13-rpi to 6.12.43+deb13-rpi and then the system worked again.
I checked that content of the initrd looks okay (only the kernel module
versions differ).

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
Hardware        : BCM2835
Revision        : 0000
Device Tree model: Raspberry Pi Zero W Rev 1.1

** Configuration for modprobe:
blacklist arkfb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist kyrofb
blacklist matroxfb_base
blacklist mb862xxfb
blacklist neofb
blacklist pm2fb
blacklist pm3fb
blacklist s3fb
blacklist savagefb
blacklist sisfb
blacklist tdfxfb
blacklist tridentfb
blacklist vt8623fb
options snd_pcsp index=-2
options cx88_alsa index=-2
options snd_atiixp_modem index=-2
options snd_intel8x0m index=-2
options snd_via82xx_modem index=-2
options bonding max_bonds=0
options dummy numdummies=0
options ifb numifbs=0
options dma dmachans=0x7ff5
options bcm2708 boardrev=0x9000c1
options bcm2708 serial=0x8bb1238
options bcm2708 uart_clock=48000000
options bcm2708 disk_led_gpio=47
options smsc95xx macaddr=B8:27:EB:BB:12:38
options vc_mem mem_base=0x1ec00000
options vc_mem mem_size=0x20000000
options fsck repair=yes
options net ifnames=0

** Network interface configuration:
*** /etc/network/interfaces:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid Skynet
wpa-psk **********************

** PCI devices:
not available

** USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 13.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: armel (armv6l)

Kernel: Linux 6.12.43+deb13-rpi (UP)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.12.48+deb13-rpi depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.148.3
ii  kmod                                    34.2-2
ii  linux-base                              4.12

Versions of packages linux-image-6.12.48+deb13-rpi recommends:
ii  apparmor  4.1.0-1

Versions of packages linux-image-6.12.48+deb13-rpi suggests:
pn  debian-kernel-handbook  <none>
ii  firmware-linux-free     20241210-2
pn  linux-doc-6.12          <none>

Versions of packages linux-image-6.12.48+deb13-rpi is related to:
pn  firmware-amd-graphics      <none>
pn  firmware-atheros           <none>
pn  firmware-bnx2              <none>
pn  firmware-bnx2x             <none>
ii  firmware-brcm80211         20250410-2
pn  firmware-cavium            <none>
pn  firmware-cirrus            <none>
pn  firmware-intel-graphics    <none>
pn  firmware-intel-misc        <none>
pn  firmware-intel-sound       <none>
pn  firmware-ipw2x00           <none>
pn  firmware-ivtv              <none>
pn  firmware-iwlwifi           <none>
pn  firmware-libertas          <none>
pn  firmware-marvell-prestera  <none>
pn  firmware-mediatek          <none>
pn  firmware-misc-nonfree      <none>
pn  firmware-myricom           <none>
pn  firmware-netronome         <none>
pn  firmware-netxen            <none>
pn  firmware-nvidia-graphics   <none>
pn  firmware-qcom-soc          <none>
pn  firmware-qlogic            <none>
pn  firmware-realtek           <none>
pn  firmware-samsung           <none>
pn  firmware-siano             <none>
pn  firmware-ti-connectivity   <none>
pn  xen-hypervisor             <none>

-- no debconf information

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [next] | [standalone]

#89836

FromBenjamin Drung <bdrung@debian.org>
Date2025-10-30 20:40 +0100
Message-ID<LLGF4-9d9O-3@gated-at.bofh.it>
In reply to#89399
On Wed, 24 Sep 2025 20:46:32 +0200 Benjamin Drung <bdrung@debian.org>
wrote:
> Package: src:linux
> Version: 6.12.48-1
> Severity: normal
> X-Debbugs-Cc: bdrung@debian.org
> 
> Hi,
> 
> I have three Raspberry Pi Zero W running trixie headless. All stopped
> working after upgrading to linux-image-6.12.48+deb13-rpi. Since they
are
> headless, I removed the SD card and checked the logs on there. The
last
> logs where from upgrading to linux-image-6.12.48+deb13-rpi and the
> shutdown (from the reboot). There were no logs from the
> linux-image-6.12.48+deb13-rpi boot. So it probably failed to boot in
the
> kernel or initrd (before switching to the root fs).
> 
> I changed the kernel+initrd in /boot/firmware/config.txt from
> 6.12.48+deb13-rpi to 6.12.43+deb13-rpi and then the system worked
again.
> I checked that content of the initrd looks okay (only the kernel
module
> versions differ).

I found some time to rip one out of the installation, solder a cable to
the UART pins and boot with a serial console attached.

I configured /boot/firmware/config.txt:

```
enable_uart=1
uart_2ndstage=1
```

When I boot with 6.12.48+deb13-rpi it hangs here:

```
Raspberry Pi Bootcode
Read File: config.txt, 532
Read File: start.elf, 2981056 (bytes)
Read File: fixup.dat, 7303 (bytes)
MESS:00:00:01.252151:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.256416:0: brfs: File read: 532 bytes
MESS:00:00:01.292170:0: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.298336:0: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.304672:0: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.311009:0: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.317346:0: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.323683:0: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.330019:0: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.336356:0: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.342693:0: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.349030:0: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.355125:0: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.361505:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.365951:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:01.558660:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:01.564486:0: *** Restart logging
MESS:00:00:01.568364:0: brfs: File read: 532 bytes
MESS:00:00:01.573602:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.580979:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.587837:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.594695:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.601552:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.608410:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.615267:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.622126:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.628983:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.635841:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.642457:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.648361:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.656152:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.663011:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.669869:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.676725:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.683584:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.690442:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.697299:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.704157:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.711015:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.717630:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.723244:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:01.731991:0: HDMI0: hdmi_pixel_encoding: 162000000
MESS:00:00:01.737705:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
MESS:00:00:02.620274:0: brfs: File read: /mfs/sd/initrd.img-6.12.48+deb13-rpi
MESS:00:00:02.625721:0: Loaded 'initrd.img-6.12.48+deb13-rpi' to 0x0 size 0xe0bfdc
MESS:00:00:02.649671:0: initramfs loaded to 0x1b1e4000 (size 0xe0bfdc)
MESS:00:00:02.664189:0: dtb_file 'bcm2835-rpi-zero-w.dtb'
MESS:00:00:02.667900:0: brfs: File read: 14729180 bytes
MESS:00:00:02.675736:0: brfs: File read: /mfs/sd/bcm2835-rpi-zero-w.dtb
MESS:00:00:02.680655:0: Loaded 'bcm2835-rpi-zero-w.dtb' to 0x100 size 0x4c27
MESS:00:00:02.696926:0: brfs: File read: 19495 bytes
MESS:00:00:02.747687:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:02.756796:0: brfs: File read: 532 bytes
MESS:00:00:02.760416:0: brfs: File read: /mfs/sd/cmdline.txt
MESS:00:00:02.765284:0: Read command line from file 'cmdline.txt':
MESS:00:00:02.771168:0: 'console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=64M rootwait'
MESS:00:00:02.799201:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
MESS:00:00:02.856093:0: brfs: File read: 105 bytes
MESS:00:00:03.137459:0: brfs: File read: /mfs/sd/vmlinuz-6.12.48+deb13-rpi
MESS:00:00:03.142614:0: Loaded 'vmlinuz-6.12.48+deb13-rpi' to 0x8000 size 0x498c60
MESS:00:00:03.149917:0: Device tree loaded to 0x1b1dee00 (size 0x51ad)
MESS:00:00:03.156884:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:03.163845:0: uart: Baud rate change done...
MESS:00:00:03.167256:0: uart: Baud rate
```

In comparison that is the working 6.12.43+deb13-rpi version:

```
Raspberry Pi Bootcode
Read File: config.txt, 532
Read File: start.elf, 2981056 (bytes)
Read File: fixup.dat, 7303 (bytes)
MESS:00:00:01.252343:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.256608:0: brfs: File read: 532 bytes
MESS:00:00:01.292358:0: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.298524:0: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.304861:0: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.311198:0: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.317534:0: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.323871:0: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.330208:0: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.336545:0: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.342882:0: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.349218:0: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.355313:0: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.361694:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.366139:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:01.558851:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:01.564677:0: *** Restart logging
MESS:00:00:01.568554:0: brfs: File read: 532 bytes
MESS:00:00:01.573792:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.581170:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.588028:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.594886:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.601743:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.608601:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.615458:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.622316:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.629174:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.636030:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.642647:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.648552:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.656343:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.663202:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.670059:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.676918:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.683773:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.690632:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.697490:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.704348:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.711205:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.717821:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.723435:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:01.732181:0: HDMI0: hdmi_pixel_encoding: 162000000
MESS:00:00:01.737896:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
MESS:00:00:02.620176:0: brfs: File read: /mfs/sd/initrd.img-6.12.43+deb13-rpi
MESS:00:00:02.625624:0: Loaded 'initrd.img-6.12.43+deb13-rpi' to 0x0 size 0xe0b1a8
MESS:00:00:02.649568:0: initramfs loaded to 0x1b1e4000 (size 0xe0b1a8)
MESS:00:00:02.664071:0: dtb_file 'bcm2835-rpi-zero-w.dtb'
MESS:00:00:02.667782:0: brfs: File read: 14725544 bytes
MESS:00:00:02.675391:0: brfs: File read: /mfs/sd/bcm2835-rpi-zero-w.dtb
MESS:00:00:02.680310:0: Loaded 'bcm2835-rpi-zero-w.dtb' to 0x100 size 0x4c27
MESS:00:00:02.696581:0: brfs: File read: 19495 bytes
MESS:00:00:02.747742:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:02.756902:0: brfs: File read: 532 bytes
MESS:00:00:02.760705:0: brfs: File read: /mfs/sd/cmdline.txt
MESS:00:00:02.765390:0: Read command line from file 'cmdline.txt':
MESS:00:00:02.771274:0: 'console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=64M rootwait'
MESS:00:00:02.799307:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
MESS:00:00:02.856080:0: brfs: File read: 105 bytes
MESS:00:00:03.137936:0: brfs: File read: /mfs/sd/vmlinuz-6.12.43+deb13-rpi
MESS:00:00:03.143092:0: Loaded 'vmlinuz-6.12.43+deb13-rpi' to 0x8000 size 0x498070
MESS:00:00:03.150393:0: Device tree loaded to 0x1b1dee00 (size 0x51ad)
MESS:00:00:03.157362:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:03.164322:0: uart: Baud rate change done...
MESS:00:00:03.167733:0: uart: Baud rate
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 6.12.43+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.43-1 (2025-08-27)
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
[...]
```

I am out of idea how to further debug that.

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [prev] | [next] | [standalone]

#89927

FromUwe Kleine-König <u.kleine-koenig@baylibre.com>
Date2025-11-05 20:20 +0100
Message-ID<LNRcZ-aJXD-1@gated-at.bofh.it>
In reply to#89836

[Multipart message — attachments visible in raw view] — view raw

On Thu, Oct 30, 2025 at 08:35:37PM +0100, Benjamin Drung wrote:
> On Wed, 24 Sep 2025 20:46:32 +0200 Benjamin Drung <bdrung@debian.org>
> wrote:
> > Package: src:linux
> > Version: 6.12.48-1
> > Severity: normal
> > X-Debbugs-Cc: bdrung@debian.org
> > 
> > Hi,
> > 
> > I have three Raspberry Pi Zero W running trixie headless. All stopped
> > working after upgrading to linux-image-6.12.48+deb13-rpi. Since they
> are
> > headless, I removed the SD card and checked the logs on there. The
> last
> > logs where from upgrading to linux-image-6.12.48+deb13-rpi and the
> > shutdown (from the reboot). There were no logs from the
> > linux-image-6.12.48+deb13-rpi boot. So it probably failed to boot in
> the
> > kernel or initrd (before switching to the root fs).
> > 
> > I changed the kernel+initrd in /boot/firmware/config.txt from
> > 6.12.48+deb13-rpi to 6.12.43+deb13-rpi and then the system worked
> again.
> > I checked that content of the initrd looks okay (only the kernel
> module
> > versions differ).
> 
> I found some time to rip one out of the installation, solder a cable to
> the UART pins and boot with a serial console attached.
> 
> I configured /boot/firmware/config.txt:
> 
> ```
> enable_uart=1
> uart_2ndstage=1
> ```
> 
> When I boot with 6.12.48+deb13-rpi it hangs here:
> 
> ```
> Raspberry Pi Bootcode
> Read File: config.txt, 532
> Read File: start.elf, 2981056 (bytes)
> Read File: fixup.dat, 7303 (bytes)
> MESS:00:00:01.252151:0: brfs: File read: /mfs/sd/config.txt
> MESS:00:00:01.256416:0: brfs: File read: 532 bytes
> MESS:00:00:01.292170:0: HDMI0:EDID error reading EDID block 0 attempt 0
> MESS:00:00:01.298336:0: HDMI0:EDID error reading EDID block 0 attempt 1
> MESS:00:00:01.304672:0: HDMI0:EDID error reading EDID block 0 attempt 2
> MESS:00:00:01.311009:0: HDMI0:EDID error reading EDID block 0 attempt 3
> MESS:00:00:01.317346:0: HDMI0:EDID error reading EDID block 0 attempt 4
> MESS:00:00:01.323683:0: HDMI0:EDID error reading EDID block 0 attempt 5
> MESS:00:00:01.330019:0: HDMI0:EDID error reading EDID block 0 attempt 6
> MESS:00:00:01.336356:0: HDMI0:EDID error reading EDID block 0 attempt 7
> MESS:00:00:01.342693:0: HDMI0:EDID error reading EDID block 0 attempt 8
> MESS:00:00:01.349030:0: HDMI0:EDID error reading EDID block 0 attempt 9
> MESS:00:00:01.355125:0: HDMI0:EDID giving up on reading EDID block 0
> MESS:00:00:01.361505:0: brfs: File read: /mfs/sd/config.txt
> MESS:00:00:01.365951:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
> MESS:00:00:01.558660:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
> MESS:00:00:01.564486:0: *** Restart logging
> MESS:00:00:01.568364:0: brfs: File read: 532 bytes
> MESS:00:00:01.573602:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
> MESS:00:00:01.580979:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
> MESS:00:00:01.587837:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
> MESS:00:00:01.594695:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
> MESS:00:00:01.601552:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
> MESS:00:00:01.608410:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
> MESS:00:00:01.615267:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
> MESS:00:00:01.622126:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
> MESS:00:00:01.628983:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
> MESS:00:00:01.635841:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
> MESS:00:00:01.642457:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
> MESS:00:00:01.648361:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
> MESS:00:00:01.656152:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
> MESS:00:00:01.663011:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
> MESS:00:00:01.669869:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
> MESS:00:00:01.676725:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
> MESS:00:00:01.683584:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
> MESS:00:00:01.690442:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
> MESS:00:00:01.697299:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
> MESS:00:00:01.704157:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
> MESS:00:00:01.711015:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
> MESS:00:00:01.717630:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
> MESS:00:00:01.723244:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
> MESS:00:00:01.731991:0: HDMI0: hdmi_pixel_encoding: 162000000
> MESS:00:00:01.737705:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
> MESS:00:00:02.620274:0: brfs: File read: /mfs/sd/initrd.img-6.12.48+deb13-rpi
> MESS:00:00:02.625721:0: Loaded 'initrd.img-6.12.48+deb13-rpi' to 0x0 size 0xe0bfdc
> MESS:00:00:02.649671:0: initramfs loaded to 0x1b1e4000 (size 0xe0bfdc)
> MESS:00:00:02.664189:0: dtb_file 'bcm2835-rpi-zero-w.dtb'
> MESS:00:00:02.667900:0: brfs: File read: 14729180 bytes
> MESS:00:00:02.675736:0: brfs: File read: /mfs/sd/bcm2835-rpi-zero-w.dtb
> MESS:00:00:02.680655:0: Loaded 'bcm2835-rpi-zero-w.dtb' to 0x100 size 0x4c27
> MESS:00:00:02.696926:0: brfs: File read: 19495 bytes
> MESS:00:00:02.747687:0: brfs: File read: /mfs/sd/config.txt
> MESS:00:00:02.756796:0: brfs: File read: 532 bytes
> MESS:00:00:02.760416:0: brfs: File read: /mfs/sd/cmdline.txt
> MESS:00:00:02.765284:0: Read command line from file 'cmdline.txt':
> MESS:00:00:02.771168:0: 'console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=64M rootwait'
> MESS:00:00:02.799201:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
> MESS:00:00:02.856093:0: brfs: File read: 105 bytes
> MESS:00:00:03.137459:0: brfs: File read: /mfs/sd/vmlinuz-6.12.48+deb13-rpi
> MESS:00:00:03.142614:0: Loaded 'vmlinuz-6.12.48+deb13-rpi' to 0x8000 size 0x498c60
> MESS:00:00:03.149917:0: Device tree loaded to 0x1b1dee00 (size 0x51ad)
> MESS:00:00:03.156884:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:03.163845:0: uart: Baud rate change done...
> MESS:00:00:03.167256:0: uart: Baud rate
> ```
> 
> In comparison that is the working 6.12.43+deb13-rpi version:
> 
> ```
> Raspberry Pi Bootcode
> Read File: config.txt, 532
> Read File: start.elf, 2981056 (bytes)
> Read File: fixup.dat, 7303 (bytes)
> MESS:00:00:01.252343:0: brfs: File read: /mfs/sd/config.txt
> MESS:00:00:01.256608:0: brfs: File read: 532 bytes
> MESS:00:00:01.292358:0: HDMI0:EDID error reading EDID block 0 attempt 0
> MESS:00:00:01.298524:0: HDMI0:EDID error reading EDID block 0 attempt 1
> MESS:00:00:01.304861:0: HDMI0:EDID error reading EDID block 0 attempt 2
> MESS:00:00:01.311198:0: HDMI0:EDID error reading EDID block 0 attempt 3
> MESS:00:00:01.317534:0: HDMI0:EDID error reading EDID block 0 attempt 4
> MESS:00:00:01.323871:0: HDMI0:EDID error reading EDID block 0 attempt 5
> MESS:00:00:01.330208:0: HDMI0:EDID error reading EDID block 0 attempt 6
> MESS:00:00:01.336545:0: HDMI0:EDID error reading EDID block 0 attempt 7
> MESS:00:00:01.342882:0: HDMI0:EDID error reading EDID block 0 attempt 8
> MESS:00:00:01.349218:0: HDMI0:EDID error reading EDID block 0 attempt 9
> MESS:00:00:01.355313:0: HDMI0:EDID giving up on reading EDID block 0
> MESS:00:00:01.361694:0: brfs: File read: /mfs/sd/config.txt
> MESS:00:00:01.366139:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
> MESS:00:00:01.558851:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
> MESS:00:00:01.564677:0: *** Restart logging
> MESS:00:00:01.568554:0: brfs: File read: 532 bytes
> MESS:00:00:01.573792:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
> MESS:00:00:01.581170:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
> MESS:00:00:01.588028:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
> MESS:00:00:01.594886:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
> MESS:00:00:01.601743:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
> MESS:00:00:01.608601:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
> MESS:00:00:01.615458:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
> MESS:00:00:01.622316:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
> MESS:00:00:01.629174:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
> MESS:00:00:01.636030:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
> MESS:00:00:01.642647:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
> MESS:00:00:01.648552:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
> MESS:00:00:01.656343:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
> MESS:00:00:01.663202:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
> MESS:00:00:01.670059:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
> MESS:00:00:01.676918:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
> MESS:00:00:01.683773:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
> MESS:00:00:01.690632:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
> MESS:00:00:01.697490:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
> MESS:00:00:01.704348:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
> MESS:00:00:01.711205:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
> MESS:00:00:01.717821:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
> MESS:00:00:01.723435:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
> MESS:00:00:01.732181:0: HDMI0: hdmi_pixel_encoding: 162000000
> MESS:00:00:01.737896:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
> MESS:00:00:02.620176:0: brfs: File read: /mfs/sd/initrd.img-6.12.43+deb13-rpi
> MESS:00:00:02.625624:0: Loaded 'initrd.img-6.12.43+deb13-rpi' to 0x0 size 0xe0b1a8
> MESS:00:00:02.649568:0: initramfs loaded to 0x1b1e4000 (size 0xe0b1a8)
> MESS:00:00:02.664071:0: dtb_file 'bcm2835-rpi-zero-w.dtb'
> MESS:00:00:02.667782:0: brfs: File read: 14725544 bytes
> MESS:00:00:02.675391:0: brfs: File read: /mfs/sd/bcm2835-rpi-zero-w.dtb
> MESS:00:00:02.680310:0: Loaded 'bcm2835-rpi-zero-w.dtb' to 0x100 size 0x4c27
> MESS:00:00:02.696581:0: brfs: File read: 19495 bytes
> MESS:00:00:02.747742:0: brfs: File read: /mfs/sd/config.txt
> MESS:00:00:02.756902:0: brfs: File read: 532 bytes
> MESS:00:00:02.760705:0: brfs: File read: /mfs/sd/cmdline.txt
> MESS:00:00:02.765390:0: Read command line from file 'cmdline.txt':
> MESS:00:00:02.771274:0: 'console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=64M rootwait'
> MESS:00:00:02.799307:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
> MESS:00:00:02.856080:0: brfs: File read: 105 bytes
> MESS:00:00:03.137936:0: brfs: File read: /mfs/sd/vmlinuz-6.12.43+deb13-rpi
> MESS:00:00:03.143092:0: Loaded 'vmlinuz-6.12.43+deb13-rpi' to 0x8000 size 0x498070
> MESS:00:00:03.150393:0: Device tree loaded to 0x1b1dee00 (size 0x51ad)
> MESS:00:00:03.157362:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:03.164322:0: uart: Baud rate change done...
> MESS:00:00:03.167733:0: uart: Baud rate
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 6.12.43+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.43-1 (2025-08-27)
> [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
> [...]
> ```
> 
> I am out of idea how to further debug that.

Can you try adding

	earlyprintk=serial,0x7e215040

to the kernel commandline. Not sure this activates the right procedures,
maybe try it with the working kernel first.

Best regards
Uwe

[toc] | [prev] | [next] | [standalone]

#90100

FromBenjamin Drung <bdrung@debian.org>
Date2025-11-17 02:10 +0100
Message-ID<LRVUJ-dwj9-1@gated-at.bofh.it>
In reply to#89927
On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
> On Thu, Oct 30, 2025 at 08:35:37PM +0100, Benjamin Drung wrote:
> > On Wed, 24 Sep 2025 20:46:32 +0200 Benjamin Drung <bdrung@debian.org>
> > wrote:
> > > Package: src:linux
> > > Version: 6.12.48-1
> > > Severity: normal
> > > X-Debbugs-Cc: bdrung@debian.org
> > > 
> > > Hi,
> > > 
> > > I have three Raspberry Pi Zero W running trixie headless. All stopped
> > > working after upgrading to linux-image-6.12.48+deb13-rpi. Since they
> > are
> > > headless, I removed the SD card and checked the logs on there. The
> > last
> > > logs where from upgrading to linux-image-6.12.48+deb13-rpi and the
> > > shutdown (from the reboot). There were no logs from the
> > > linux-image-6.12.48+deb13-rpi boot. So it probably failed to boot in
> > the
> > > kernel or initrd (before switching to the root fs).
> > > 
> > > I changed the kernel+initrd in /boot/firmware/config.txt from
> > > 6.12.48+deb13-rpi to 6.12.43+deb13-rpi and then the system worked
> > again.
> > > I checked that content of the initrd looks okay (only the kernel
> > module
> > > versions differ).
> > 
> > I found some time to rip one out of the installation, solder a cable to
> > the UART pins and boot with a serial console attached.
> > 
> > I configured /boot/firmware/config.txt:
> > 
> > ```
> > enable_uart=1
> > uart_2ndstage=1
> > ```
> > 
> > When I boot with 6.12.48+deb13-rpi it hangs here:
> > 
> > ```
> > Raspberry Pi Bootcode
> > Read File: config.txt, 532
> > Read File: start.elf, 2981056 (bytes)
> > Read File: fixup.dat, 7303 (bytes)
> > MESS:00:00:01.252151:0: brfs: File read: /mfs/sd/config.txt
> > MESS:00:00:01.256416:0: brfs: File read: 532 bytes
> > MESS:00:00:01.292170:0: HDMI0:EDID error reading EDID block 0 attempt 0
> > MESS:00:00:01.298336:0: HDMI0:EDID error reading EDID block 0 attempt 1
> > MESS:00:00:01.304672:0: HDMI0:EDID error reading EDID block 0 attempt 2
> > MESS:00:00:01.311009:0: HDMI0:EDID error reading EDID block 0 attempt 3
> > MESS:00:00:01.317346:0: HDMI0:EDID error reading EDID block 0 attempt 4
> > MESS:00:00:01.323683:0: HDMI0:EDID error reading EDID block 0 attempt 5
> > MESS:00:00:01.330019:0: HDMI0:EDID error reading EDID block 0 attempt 6
> > MESS:00:00:01.336356:0: HDMI0:EDID error reading EDID block 0 attempt 7
> > MESS:00:00:01.342693:0: HDMI0:EDID error reading EDID block 0 attempt 8
> > MESS:00:00:01.349030:0: HDMI0:EDID error reading EDID block 0 attempt 9
> > MESS:00:00:01.355125:0: HDMI0:EDID giving up on reading EDID block 0
> > MESS:00:00:01.361505:0: brfs: File read: /mfs/sd/config.txt
> > MESS:00:00:01.365951:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
> > MESS:00:00:01.558660:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
> > MESS:00:00:01.564486:0: *** Restart logging
> > MESS:00:00:01.568364:0: brfs: File read: 532 bytes
> > MESS:00:00:01.573602:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
> > MESS:00:00:01.580979:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
> > MESS:00:00:01.587837:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
> > MESS:00:00:01.594695:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
> > MESS:00:00:01.601552:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
> > MESS:00:00:01.608410:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
> > MESS:00:00:01.615267:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
> > MESS:00:00:01.622126:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
> > MESS:00:00:01.628983:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
> > MESS:00:00:01.635841:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
> > MESS:00:00:01.642457:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
> > MESS:00:00:01.648361:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
> > MESS:00:00:01.656152:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
> > MESS:00:00:01.663011:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
> > MESS:00:00:01.669869:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
> > MESS:00:00:01.676725:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
> > MESS:00:00:01.683584:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
> > MESS:00:00:01.690442:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
> > MESS:00:00:01.697299:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
> > MESS:00:00:01.704157:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
> > MESS:00:00:01.711015:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
> > MESS:00:00:01.717630:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
> > MESS:00:00:01.723244:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
> > MESS:00:00:01.731991:0: HDMI0: hdmi_pixel_encoding: 162000000
> > MESS:00:00:01.737705:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
> > MESS:00:00:02.620274:0: brfs: File read: /mfs/sd/initrd.img-6.12.48+deb13-rpi
> > MESS:00:00:02.625721:0: Loaded 'initrd.img-6.12.48+deb13-rpi' to 0x0 size 0xe0bfdc
> > MESS:00:00:02.649671:0: initramfs loaded to 0x1b1e4000 (size 0xe0bfdc)
> > MESS:00:00:02.664189:0: dtb_file 'bcm2835-rpi-zero-w.dtb'
> > MESS:00:00:02.667900:0: brfs: File read: 14729180 bytes
> > MESS:00:00:02.675736:0: brfs: File read: /mfs/sd/bcm2835-rpi-zero-w.dtb
> > MESS:00:00:02.680655:0: Loaded 'bcm2835-rpi-zero-w.dtb' to 0x100 size 0x4c27
> > MESS:00:00:02.696926:0: brfs: File read: 19495 bytes
> > MESS:00:00:02.747687:0: brfs: File read: /mfs/sd/config.txt
> > MESS:00:00:02.756796:0: brfs: File read: 532 bytes
> > MESS:00:00:02.760416:0: brfs: File read: /mfs/sd/cmdline.txt
> > MESS:00:00:02.765284:0: Read command line from file 'cmdline.txt':
> > MESS:00:00:02.771168:0: 'console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=64M rootwait'
> > MESS:00:00:02.799201:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
> > MESS:00:00:02.856093:0: brfs: File read: 105 bytes
> > MESS:00:00:03.137459:0: brfs: File read: /mfs/sd/vmlinuz-6.12.48+deb13-rpi
> > MESS:00:00:03.142614:0: Loaded 'vmlinuz-6.12.48+deb13-rpi' to 0x8000 size 0x498c60
> > MESS:00:00:03.149917:0: Device tree loaded to 0x1b1dee00 (size 0x51ad)
> > MESS:00:00:03.156884:0: uart: Set PL011 baud rate to 103448.300000 Hz
> > MESS:00:00:03.163845:0: uart: Baud rate change done...
> > MESS:00:00:03.167256:0: uart: Baud rate
> > ```
> > 
> > In comparison that is the working 6.12.43+deb13-rpi version:
> > 
> > ```
> > Raspberry Pi Bootcode
> > Read File: config.txt, 532
> > Read File: start.elf, 2981056 (bytes)
> > Read File: fixup.dat, 7303 (bytes)
> > MESS:00:00:01.252343:0: brfs: File read: /mfs/sd/config.txt
> > MESS:00:00:01.256608:0: brfs: File read: 532 bytes
> > MESS:00:00:01.292358:0: HDMI0:EDID error reading EDID block 0 attempt 0
> > MESS:00:00:01.298524:0: HDMI0:EDID error reading EDID block 0 attempt 1
> > MESS:00:00:01.304861:0: HDMI0:EDID error reading EDID block 0 attempt 2
> > MESS:00:00:01.311198:0: HDMI0:EDID error reading EDID block 0 attempt 3
> > MESS:00:00:01.317534:0: HDMI0:EDID error reading EDID block 0 attempt 4
> > MESS:00:00:01.323871:0: HDMI0:EDID error reading EDID block 0 attempt 5
> > MESS:00:00:01.330208:0: HDMI0:EDID error reading EDID block 0 attempt 6
> > MESS:00:00:01.336545:0: HDMI0:EDID error reading EDID block 0 attempt 7
> > MESS:00:00:01.342882:0: HDMI0:EDID error reading EDID block 0 attempt 8
> > MESS:00:00:01.349218:0: HDMI0:EDID error reading EDID block 0 attempt 9
> > MESS:00:00:01.355313:0: HDMI0:EDID giving up on reading EDID block 0
> > MESS:00:00:01.361694:0: brfs: File read: /mfs/sd/config.txt
> > MESS:00:00:01.366139:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
> > MESS:00:00:01.558851:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
> > MESS:00:00:01.564677:0: *** Restart logging
> > MESS:00:00:01.568554:0: brfs: File read: 532 bytes
> > MESS:00:00:01.573792:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
> > MESS:00:00:01.581170:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
> > MESS:00:00:01.588028:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
> > MESS:00:00:01.594886:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
> > MESS:00:00:01.601743:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
> > MESS:00:00:01.608601:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
> > MESS:00:00:01.615458:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
> > MESS:00:00:01.622316:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
> > MESS:00:00:01.629174:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
> > MESS:00:00:01.636030:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
> > MESS:00:00:01.642647:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
> > MESS:00:00:01.648552:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
> > MESS:00:00:01.656343:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
> > MESS:00:00:01.663202:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
> > MESS:00:00:01.670059:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
> > MESS:00:00:01.676918:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
> > MESS:00:00:01.683773:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
> > MESS:00:00:01.690632:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
> > MESS:00:00:01.697490:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
> > MESS:00:00:01.704348:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
> > MESS:00:00:01.711205:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
> > MESS:00:00:01.717821:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
> > MESS:00:00:01.723435:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
> > MESS:00:00:01.732181:0: HDMI0: hdmi_pixel_encoding: 162000000
> > MESS:00:00:01.737896:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
> > MESS:00:00:02.620176:0: brfs: File read: /mfs/sd/initrd.img-6.12.43+deb13-rpi
> > MESS:00:00:02.625624:0: Loaded 'initrd.img-6.12.43+deb13-rpi' to 0x0 size 0xe0b1a8
> > MESS:00:00:02.649568:0: initramfs loaded to 0x1b1e4000 (size 0xe0b1a8)
> > MESS:00:00:02.664071:0: dtb_file 'bcm2835-rpi-zero-w.dtb'
> > MESS:00:00:02.667782:0: brfs: File read: 14725544 bytes
> > MESS:00:00:02.675391:0: brfs: File read: /mfs/sd/bcm2835-rpi-zero-w.dtb
> > MESS:00:00:02.680310:0: Loaded 'bcm2835-rpi-zero-w.dtb' to 0x100 size 0x4c27
> > MESS:00:00:02.696581:0: brfs: File read: 19495 bytes
> > MESS:00:00:02.747742:0: brfs: File read: /mfs/sd/config.txt
> > MESS:00:00:02.756902:0: brfs: File read: 532 bytes
> > MESS:00:00:02.760705:0: brfs: File read: /mfs/sd/cmdline.txt
> > MESS:00:00:02.765390:0: Read command line from file 'cmdline.txt':
> > MESS:00:00:02.771274:0: 'console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=64M rootwait'
> > MESS:00:00:02.799307:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
> > MESS:00:00:02.856080:0: brfs: File read: 105 bytes
> > MESS:00:00:03.137936:0: brfs: File read: /mfs/sd/vmlinuz-6.12.43+deb13-rpi
> > MESS:00:00:03.143092:0: Loaded 'vmlinuz-6.12.43+deb13-rpi' to 0x8000 size 0x498070
> > MESS:00:00:03.150393:0: Device tree loaded to 0x1b1dee00 (size 0x51ad)
> > MESS:00:00:03.157362:0: uart: Set PL011 baud rate to 103448.300000 Hz
> > MESS:00:00:03.164322:0: uart: Baud rate change done...
> > MESS:00:00:03.167733:0: uart: Baud rate
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 6.12.43+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.43-1 (2025-08-27)
> > [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
> > [...]
> > ```
> > 
> > I am out of idea how to further debug that.
> 
> Can you try adding
> 
> 	earlyprintk=serial,0x7e215040
> 
> to the kernel commandline. Not sure this activates the right procedures,
> maybe try it with the working kernel first.

I tried with the working kernel 6.12.43+deb13-rpi but these were the
earliest lines:

[    4.116565] printk: legacy console [ttyS1] enabled
[    4.129635] printk: legacy bootconsole [earlycon0] disabled
[    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[    4.160972] mousedev: PS/2 mouse device common for all mice
[    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
[    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer

I tried with 6.12.57+deb13-rpi but that failed to boot and the
earlyprintk line did not give any additional logs.

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [prev] | [next] | [standalone]

#90191

FromBenjamin Drung <bdrung@debian.org>
Date2025-11-22 16:30 +0100
Message-ID<LTXIJ-eVw4-1@gated-at.bofh.it>
In reply to#89399
Hi Uwe,

On Fri, 2025-11-21 at 09:52 +0100, Uwe Kleine-König wrote:
> Hello Benjamin,
> 
> On Thu, Nov 20, 2025 at 11:11:07AM +0100, Benjamin Drung wrote:
> > On Thu, 2025-11-20 at 08:58 +0100, Uwe Kleine-König wrote:
> > > On Mon, Nov 17, 2025 at 02:05:41AM +0100, Benjamin Drung wrote:
> > > > On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
> > > > > Can you try adding
> > > > > 
> > > > > 	earlyprintk=serial,0x7e215040
> > > > > 
> > > > > to the kernel commandline. Not sure this activates the right procedures,
> > > > > maybe try it with the working kernel first.
> > > > 
> > > > I tried with the working kernel 6.12.43+deb13-rpi but these were the
> > > > earliest lines:
> > > > 
> > > > [    4.116565] printk: legacy console [ttyS1] enabled
> > > > [    4.129635] printk: legacy bootconsole [earlycon0] disabled
> > > > [    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
> > > > [    4.160972] mousedev: PS/2 mouse device common for all mice
> > > > [    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
> > > > [    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
> > > > 
> > > > I tried with 6.12.57+deb13-rpi but that failed to boot and the
> > > > earlyprintk line did not give any additional logs.
> > > 
> > > Can you please provide a full kernel log of the working kernel?
> > 
> > dmesg log is attached.
> > 
> > > Also please provide the output of:
> > > 
> > > 	for f in /proc/tty/driver/*; do echo $f; sed 's/^/  /' < $f; done
> > 
> > /proc/tty/driver/serial
> >   serinfo:1.0 driver revision:
> >   0: uart:unknown port:00000000 irq:0
> >   1: uart:16550 mmio:0x20215040 irq:53 tx:15629 rx:0 RTS|CTS|DTR
> >   2: uart:unknown port:00000000 irq:0
> >   3: uart:unknown port:00000000 irq:0
> > /proc/tty/driver/ttyAMA
> >   serinfo:1.0 driver revision:
> >   0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:452 rx:980 RTS|CTS|DTR
> 
> OK, is
> 
>  	earlyprintk=serial,0x20215040
> 
> more communicative then?

Nope, but I found
https://www.raspberrypi.com/documentation/computers/configuration.html#enabling-early-console-for-linux
and setting earlycon=uart8250,mmio32,0x20215040 worked. The kernel
6.12.43+deb13-rpi booted with printing the early lines as well (see
dmesg of previous mail).

With all other experiments cleaned, I tried the latest kernel:

```
$ cat /etc/default/raspi-extra-cmdline
earlycon=uart8250,mmio32,0x20215040
$ update-initramfs -u
```

I got following logs before it got stuck:

```
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 6.12.57+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.57-1 (2025-11-05)
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
[    0.000000] random: crng init done
[    0.000000] earlycon: uart8250 at MMIO32 0x20215040 (options '')
[    0.000000] printk: legacy bootconsole [uart8250] enabled
[    0.000000] Memory policy: Data cache writeback
[    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
[    0.000000] OF: reserved mem: node linux,cma compatible matching fail
[    0.000000] cma: Reserved 64 MiB at 0x17000000 on node -1
```

It looks like being cma related and I found a cma boot option in
/etc/default/raspi-firmware. So I modified /boot/firmware/cmdline.txt
and changed cma=64M to cma=0. Then the system booted without problems:

```
[...]
[    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
[    0.000000] OF: reserved mem: node linux,cma compatible matching fail
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
[    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=0 rootwait earlycon=uart8250,mmio32,0x20215040
[...]
```

Then I persisted this change by setting CMA=0 in
/etc/default/raspi-firmware:

```
$ grep -Ev '^(#|$)' /etc/default/raspi-firmware
CMA=0
$ update-initramfs -u
```

This config removes the cma cmdline option completely. The system still
boots:

```
[...]
[    0.000000] Memory policy: Data cache writeback
[    0.000000] Reserved memory: created CMA memory pool at 0x17000000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] OF: reserved mem: 0x17000000..0x1affffff (65536 KiB) map reusable linux,cma
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
[    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0  rootwait earlycon=uart8250,mmio32,0x20215040
[...]
```

That should hopefully narrow down the issue space.

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [prev] | [next] | [standalone]

#90266

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-11-26 09:00 +0100
Message-ID<LViBr-fPG0-1@gated-at.bofh.it>
In reply to#90191
Control: tags -1 + moreinfo

Hi,

On Sat, Nov 22, 2025 at 04:27:53PM +0100, Benjamin Drung wrote:
> Hi Uwe,
> 
> On Fri, 2025-11-21 at 09:52 +0100, Uwe Kleine-König wrote:
> > Hello Benjamin,
> > 
> > On Thu, Nov 20, 2025 at 11:11:07AM +0100, Benjamin Drung wrote:
> > > On Thu, 2025-11-20 at 08:58 +0100, Uwe Kleine-König wrote:
> > > > On Mon, Nov 17, 2025 at 02:05:41AM +0100, Benjamin Drung wrote:
> > > > > On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
> > > > > > Can you try adding
> > > > > > 
> > > > > > 	earlyprintk=serial,0x7e215040
> > > > > > 
> > > > > > to the kernel commandline. Not sure this activates the right procedures,
> > > > > > maybe try it with the working kernel first.
> > > > > 
> > > > > I tried with the working kernel 6.12.43+deb13-rpi but these were the
> > > > > earliest lines:
> > > > > 
> > > > > [    4.116565] printk: legacy console [ttyS1] enabled
> > > > > [    4.129635] printk: legacy bootconsole [earlycon0] disabled
> > > > > [    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
> > > > > [    4.160972] mousedev: PS/2 mouse device common for all mice
> > > > > [    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
> > > > > [    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
> > > > > 
> > > > > I tried with 6.12.57+deb13-rpi but that failed to boot and the
> > > > > earlyprintk line did not give any additional logs.
> > > > 
> > > > Can you please provide a full kernel log of the working kernel?
> > > 
> > > dmesg log is attached.
> > > 
> > > > Also please provide the output of:
> > > > 
> > > > 	for f in /proc/tty/driver/*; do echo $f; sed 's/^/  /' < $f; done
> > > 
> > > /proc/tty/driver/serial
> > >   serinfo:1.0 driver revision:
> > >   0: uart:unknown port:00000000 irq:0
> > >   1: uart:16550 mmio:0x20215040 irq:53 tx:15629 rx:0 RTS|CTS|DTR
> > >   2: uart:unknown port:00000000 irq:0
> > >   3: uart:unknown port:00000000 irq:0
> > > /proc/tty/driver/ttyAMA
> > >   serinfo:1.0 driver revision:
> > >   0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:452 rx:980 RTS|CTS|DTR
> > 
> > OK, is
> > 
> >  	earlyprintk=serial,0x20215040
> > 
> > more communicative then?
> 
> Nope, but I found
> https://www.raspberrypi.com/documentation/computers/configuration.html#enabling-early-console-for-linux
> and setting earlycon=uart8250,mmio32,0x20215040 worked. The kernel
> 6.12.43+deb13-rpi booted with printing the early lines as well (see
> dmesg of previous mail).
> 
> With all other experiments cleaned, I tried the latest kernel:
> 
> ```
> $ cat /etc/default/raspi-extra-cmdline
> earlycon=uart8250,mmio32,0x20215040
> $ update-initramfs -u
> ```
> 
> I got following logs before it got stuck:
> 
> ```
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 6.12.57+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.57-1 (2025-11-05)
> [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
> [    0.000000] random: crng init done
> [    0.000000] earlycon: uart8250 at MMIO32 0x20215040 (options '')
> [    0.000000] printk: legacy bootconsole [uart8250] enabled
> [    0.000000] Memory policy: Data cache writeback
> [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> [    0.000000] cma: Reserved 64 MiB at 0x17000000 on node -1
> ```
> 
> It looks like being cma related and I found a cma boot option in
> /etc/default/raspi-firmware. So I modified /boot/firmware/cmdline.txt
> and changed cma=64M to cma=0. Then the system booted without problems:
> 
> ```
> [...]
> [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> [    0.000000] Zone ranges:
> [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=0 rootwait earlycon=uart8250,mmio32,0x20215040
> [...]
> ```
> 
> Then I persisted this change by setting CMA=0 in
> /etc/default/raspi-firmware:
> 
> ```
> $ grep -Ev '^(#|$)' /etc/default/raspi-firmware
> CMA=0
> $ update-initramfs -u
> ```
> 
> This config removes the cma cmdline option completely. The system still
> boots:
> 
> ```
> [...]
> [    0.000000] Memory policy: Data cache writeback
> [    0.000000] Reserved memory: created CMA memory pool at 0x17000000, size 64 MiB
> [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> [    0.000000] OF: reserved mem: 0x17000000..0x1affffff (65536 KiB) map reusable linux,cma
> [    0.000000] Zone ranges:
> [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0  rootwait earlycon=uart8250,mmio32,0x20215040
> [...]
> ```
> 
> That should hopefully narrow down the issue space.

If I'm not wrong the only cma related change between 6.12.43 and
6.12.48 was the backport of 2c223f7239f3 ("of: reserved_mem:
Restructure call site for dma_contiguous_early_fixup()"):

	commit 46efab01648a04082266115a8e917c3b26b97fa8
	Author: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
	Date:   Wed Aug 6 10:24:21 2025 -0700

	    of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()

	    [ Upstream commit 2c223f7239f376a90d71903ec474ba887cf21d94 ]

	    Restructure the call site for dma_contiguous_early_fixup() to
	    where the reserved_mem nodes are being parsed from the DT so that
	    dma_mmu_remap[] is populated before dma_contiguous_remap() is called.

	    Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
	    Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
	    Tested-by: William Zhang <william.zhang@broadcom.com>
	    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
	    Link: https://lore.kernel.org/r/20250806172421.2748302-1-oreoluwa.babatunde@oss.qualcomm.com
	    Signed-off-by: Sasha Levin <sashal@kernel.org>

Uwe, would that make sense? Benjamin can you try to make a build with
that commit reverted, does it fix the problem?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90324

FromBenjamin Drung <bdrung@debian.org>
Date2025-11-28 23:00 +0100
Message-ID<LWeFr-gtRN-1@gated-at.bofh.it>
In reply to#90266
On Wed, 2025-11-26 at 08:52 +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> On Sat, Nov 22, 2025 at 04:27:53PM +0100, Benjamin Drung wrote:
> > Hi Uwe,
> > 
> > On Fri, 2025-11-21 at 09:52 +0100, Uwe Kleine-König wrote:
> > > Hello Benjamin,
> > > 
> > > On Thu, Nov 20, 2025 at 11:11:07AM +0100, Benjamin Drung wrote:
> > > > On Thu, 2025-11-20 at 08:58 +0100, Uwe Kleine-König wrote:
> > > > > On Mon, Nov 17, 2025 at 02:05:41AM +0100, Benjamin Drung wrote:
> > > > > > On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
> > > > > > > Can you try adding
> > > > > > > 
> > > > > > > 	earlyprintk=serial,0x7e215040
> > > > > > > 
> > > > > > > to the kernel commandline. Not sure this activates the right procedures,
> > > > > > > maybe try it with the working kernel first.
> > > > > > 
> > > > > > I tried with the working kernel 6.12.43+deb13-rpi but these were the
> > > > > > earliest lines:
> > > > > > 
> > > > > > [    4.116565] printk: legacy console [ttyS1] enabled
> > > > > > [    4.129635] printk: legacy bootconsole [earlycon0] disabled
> > > > > > [    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
> > > > > > [    4.160972] mousedev: PS/2 mouse device common for all mice
> > > > > > [    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
> > > > > > [    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
> > > > > > 
> > > > > > I tried with 6.12.57+deb13-rpi but that failed to boot and the
> > > > > > earlyprintk line did not give any additional logs.
> > > > > 
> > > > > Can you please provide a full kernel log of the working kernel?
> > > > 
> > > > dmesg log is attached.
> > > > 
> > > > > Also please provide the output of:
> > > > > 
> > > > > 	for f in /proc/tty/driver/*; do echo $f; sed 's/^/  /' < $f; done
> > > > 
> > > > /proc/tty/driver/serial
> > > >   serinfo:1.0 driver revision:
> > > >   0: uart:unknown port:00000000 irq:0
> > > >   1: uart:16550 mmio:0x20215040 irq:53 tx:15629 rx:0 RTS|CTS|DTR
> > > >   2: uart:unknown port:00000000 irq:0
> > > >   3: uart:unknown port:00000000 irq:0
> > > > /proc/tty/driver/ttyAMA
> > > >   serinfo:1.0 driver revision:
> > > >   0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:452 rx:980 RTS|CTS|DTR
> > > 
> > > OK, is
> > > 
> > >  	earlyprintk=serial,0x20215040
> > > 
> > > more communicative then?
> > 
> > Nope, but I found
> > https://www.raspberrypi.com/documentation/computers/configuration.html#enabling-early-console-for-linux
> > and setting earlycon=uart8250,mmio32,0x20215040 worked. The kernel
> > 6.12.43+deb13-rpi booted with printing the early lines as well (see
> > dmesg of previous mail).
> > 
> > With all other experiments cleaned, I tried the latest kernel:
> > 
> > ```
> > $ cat /etc/default/raspi-extra-cmdline
> > earlycon=uart8250,mmio32,0x20215040
> > $ update-initramfs -u
> > ```
> > 
> > I got following logs before it got stuck:
> > 
> > ```
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 6.12.57+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.57-1 (2025-11-05)
> > [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
> > [    0.000000] random: crng init done
> > [    0.000000] earlycon: uart8250 at MMIO32 0x20215040 (options '')
> > [    0.000000] printk: legacy bootconsole [uart8250] enabled
> > [    0.000000] Memory policy: Data cache writeback
> > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > [    0.000000] cma: Reserved 64 MiB at 0x17000000 on node -1
> > ```
> > 
> > It looks like being cma related and I found a cma boot option in
> > /etc/default/raspi-firmware. So I modified /boot/firmware/cmdline.txt
> > and changed cma=64M to cma=0. Then the system booted without problems:
> > 
> > ```
> > [...]
> > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > [    0.000000] Zone ranges:
> > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > [    0.000000] Movable zone start for each node
> > [    0.000000] Early memory node ranges
> > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=0 rootwait earlycon=uart8250,mmio32,0x20215040
> > [...]
> > ```
> > 
> > Then I persisted this change by setting CMA=0 in
> > /etc/default/raspi-firmware:
> > 
> > ```
> > $ grep -Ev '^(#|$)' /etc/default/raspi-firmware
> > CMA=0
> > $ update-initramfs -u
> > ```
> > 
> > This config removes the cma cmdline option completely. The system still
> > boots:
> > 
> > ```
> > [...]
> > [    0.000000] Memory policy: Data cache writeback
> > [    0.000000] Reserved memory: created CMA memory pool at 0x17000000, size 64 MiB
> > [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> > [    0.000000] OF: reserved mem: 0x17000000..0x1affffff (65536 KiB) map reusable linux,cma
> > [    0.000000] Zone ranges:
> > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > [    0.000000] Movable zone start for each node
> > [    0.000000] Early memory node ranges
> > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0  rootwait earlycon=uart8250,mmio32,0x20215040
> > [...]
> > ```
> > 
> > That should hopefully narrow down the issue space.
> 
> If I'm not wrong the only cma related change between 6.12.43 and
> 6.12.48 was the backport of 2c223f7239f3 ("of: reserved_mem:
> Restructure call site for dma_contiguous_early_fixup()"):
> 
> 	commit 46efab01648a04082266115a8e917c3b26b97fa8
> 	Author: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> 	Date:   Wed Aug 6 10:24:21 2025 -0700
> 
> 	    of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()
> 
> 	    [ Upstream commit 2c223f7239f376a90d71903ec474ba887cf21d94 ]
> 
> 	    Restructure the call site for dma_contiguous_early_fixup() to
> 	    where the reserved_mem nodes are being parsed from the DT so that
> 	    dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
> 
> 	    Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
> 	    Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> 	    Tested-by: William Zhang <william.zhang@broadcom.com>
> 	    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> 	    Link: https://lore.kernel.org/r/20250806172421.2748302-1-oreoluwa.babatunde@oss.qualcomm.com
> 	    Signed-off-by: Sasha Levin <sashal@kernel.org>
> 
> Uwe, would that make sense? Benjamin can you try to make a build with
> that commit reverted, does it fix the problem?

Building the kernel on the Pi Zero would probably take ages. I have a
Raspberry Pi 5 running arm64. That should be able to build the kernel in
a armel schroot, shouldn't it? Is there documentation for building the
kernel?

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [prev] | [next] | [standalone]

#90325

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-11-29 00:10 +0100
Message-ID<LWfLb-guQQ-1@gated-at.bofh.it>
In reply to#90324

[Multipart message — attachments visible in raw view] — view raw

Hi Benjamin,

On Fri, Nov 28, 2025 at 10:53:17PM +0100, Benjamin Drung wrote:
> On Wed, 2025-11-26 at 08:52 +0100, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi,
> > 
> > On Sat, Nov 22, 2025 at 04:27:53PM +0100, Benjamin Drung wrote:
> > > Hi Uwe,
> > > 
> > > On Fri, 2025-11-21 at 09:52 +0100, Uwe Kleine-König wrote:
> > > > Hello Benjamin,
> > > > 
> > > > On Thu, Nov 20, 2025 at 11:11:07AM +0100, Benjamin Drung wrote:
> > > > > On Thu, 2025-11-20 at 08:58 +0100, Uwe Kleine-König wrote:
> > > > > > On Mon, Nov 17, 2025 at 02:05:41AM +0100, Benjamin Drung wrote:
> > > > > > > On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
> > > > > > > > Can you try adding
> > > > > > > > 
> > > > > > > > 	earlyprintk=serial,0x7e215040
> > > > > > > > 
> > > > > > > > to the kernel commandline. Not sure this activates the right procedures,
> > > > > > > > maybe try it with the working kernel first.
> > > > > > > 
> > > > > > > I tried with the working kernel 6.12.43+deb13-rpi but these were the
> > > > > > > earliest lines:
> > > > > > > 
> > > > > > > [    4.116565] printk: legacy console [ttyS1] enabled
> > > > > > > [    4.129635] printk: legacy bootconsole [earlycon0] disabled
> > > > > > > [    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
> > > > > > > [    4.160972] mousedev: PS/2 mouse device common for all mice
> > > > > > > [    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
> > > > > > > [    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
> > > > > > > 
> > > > > > > I tried with 6.12.57+deb13-rpi but that failed to boot and the
> > > > > > > earlyprintk line did not give any additional logs.
> > > > > > 
> > > > > > Can you please provide a full kernel log of the working kernel?
> > > > > 
> > > > > dmesg log is attached.
> > > > > 
> > > > > > Also please provide the output of:
> > > > > > 
> > > > > > 	for f in /proc/tty/driver/*; do echo $f; sed 's/^/  /' < $f; done
> > > > > 
> > > > > /proc/tty/driver/serial
> > > > >   serinfo:1.0 driver revision:
> > > > >   0: uart:unknown port:00000000 irq:0
> > > > >   1: uart:16550 mmio:0x20215040 irq:53 tx:15629 rx:0 RTS|CTS|DTR
> > > > >   2: uart:unknown port:00000000 irq:0
> > > > >   3: uart:unknown port:00000000 irq:0
> > > > > /proc/tty/driver/ttyAMA
> > > > >   serinfo:1.0 driver revision:
> > > > >   0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:452 rx:980 RTS|CTS|DTR
> > > > 
> > > > OK, is
> > > > 
> > > >  	earlyprintk=serial,0x20215040
> > > > 
> > > > more communicative then?
> > > 
> > > Nope, but I found
> > > https://www.raspberrypi.com/documentation/computers/configuration.html#enabling-early-console-for-linux
> > > and setting earlycon=uart8250,mmio32,0x20215040 worked. The kernel
> > > 6.12.43+deb13-rpi booted with printing the early lines as well (see
> > > dmesg of previous mail).
> > > 
> > > With all other experiments cleaned, I tried the latest kernel:
> > > 
> > > ```
> > > $ cat /etc/default/raspi-extra-cmdline
> > > earlycon=uart8250,mmio32,0x20215040
> > > $ update-initramfs -u
> > > ```
> > > 
> > > I got following logs before it got stuck:
> > > 
> > > ```
> > > [    0.000000] Booting Linux on physical CPU 0x0
> > > [    0.000000] Linux version 6.12.57+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.57-1 (2025-11-05)
> > > [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> > > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > > [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
> > > [    0.000000] random: crng init done
> > > [    0.000000] earlycon: uart8250 at MMIO32 0x20215040 (options '')
> > > [    0.000000] printk: legacy bootconsole [uart8250] enabled
> > > [    0.000000] Memory policy: Data cache writeback
> > > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > > [    0.000000] cma: Reserved 64 MiB at 0x17000000 on node -1
> > > ```
> > > 
> > > It looks like being cma related and I found a cma boot option in
> > > /etc/default/raspi-firmware. So I modified /boot/firmware/cmdline.txt
> > > and changed cma=64M to cma=0. Then the system booted without problems:
> > > 
> > > ```
> > > [...]
> > > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > > [    0.000000] Zone ranges:
> > > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > > [    0.000000] Movable zone start for each node
> > > [    0.000000] Early memory node ranges
> > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=0 rootwait earlycon=uart8250,mmio32,0x20215040
> > > [...]
> > > ```
> > > 
> > > Then I persisted this change by setting CMA=0 in
> > > /etc/default/raspi-firmware:
> > > 
> > > ```
> > > $ grep -Ev '^(#|$)' /etc/default/raspi-firmware
> > > CMA=0
> > > $ update-initramfs -u
> > > ```
> > > 
> > > This config removes the cma cmdline option completely. The system still
> > > boots:
> > > 
> > > ```
> > > [...]
> > > [    0.000000] Memory policy: Data cache writeback
> > > [    0.000000] Reserved memory: created CMA memory pool at 0x17000000, size 64 MiB
> > > [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> > > [    0.000000] OF: reserved mem: 0x17000000..0x1affffff (65536 KiB) map reusable linux,cma
> > > [    0.000000] Zone ranges:
> > > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > > [    0.000000] Movable zone start for each node
> > > [    0.000000] Early memory node ranges
> > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0  rootwait earlycon=uart8250,mmio32,0x20215040
> > > [...]
> > > ```
> > > 
> > > That should hopefully narrow down the issue space.
> > 
> > If I'm not wrong the only cma related change between 6.12.43 and
> > 6.12.48 was the backport of 2c223f7239f3 ("of: reserved_mem:
> > Restructure call site for dma_contiguous_early_fixup()"):
> > 
> > 	commit 46efab01648a04082266115a8e917c3b26b97fa8
> > 	Author: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> > 	Date:   Wed Aug 6 10:24:21 2025 -0700
> > 
> > 	    of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()
> > 
> > 	    [ Upstream commit 2c223f7239f376a90d71903ec474ba887cf21d94 ]
> > 
> > 	    Restructure the call site for dma_contiguous_early_fixup() to
> > 	    where the reserved_mem nodes are being parsed from the DT so that
> > 	    dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
> > 
> > 	    Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
> > 	    Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> > 	    Tested-by: William Zhang <william.zhang@broadcom.com>
> > 	    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > 	    Link: https://lore.kernel.org/r/20250806172421.2748302-1-oreoluwa.babatunde@oss.qualcomm.com
> > 	    Signed-off-by: Sasha Levin <sashal@kernel.org>
> > 
> > Uwe, would that make sense? Benjamin can you try to make a build with
> > that commit reverted, does it fix the problem?
> 
> Building the kernel on the Pi Zero would probably take ages. I have a
> Raspberry Pi 5 running arm64. That should be able to build the kernel in
> a armel schroot, shouldn't it? Is there documentation for building the
> kernel?

I hope it is fine for Uwe that i respond here, he might have another
more efficient way to reach our goal.

But we have the simple-patching guideline here:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4

That should work within an armel schroot work well, e.g. on a
porterbox amdahl.d.o i would first setup a schroot via:

schroot -b -c chroot:trixie_armel-dchroot -n linux
dd-schroot-cmd -c linux apt-get update
dd-schroot-cmd -c linux apt-get dist-upgrade
dd-schroot-cmd -c linux apt-get build-dep linux
schroot -r -c linux
(see https://dsa.debian.org/doc/schroot/)

Then download the linux/6.12.57-1 source and make the revert patch
available.

apt-get source linux
cd linux-*
./debian/bin/test-patches -f rpi ../0001-Revert-of-reserved_mem-Restructure-call-site-for-dma.patch

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90329

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-11-30 10:30 +0100
Message-ID<LWLUJ-gSx5-1@gated-at.bofh.it>
In reply to#90325
Hi Benjmanin,

On Sat, Nov 29, 2025 at 12:02:00AM +0100, Salvatore Bonaccorso wrote:
> Hi Benjamin,
> 
> On Fri, Nov 28, 2025 at 10:53:17PM +0100, Benjamin Drung wrote:
> > On Wed, 2025-11-26 at 08:52 +0100, Salvatore Bonaccorso wrote:
> > > Control: tags -1 + moreinfo
> > > 
> > > Hi,
> > > 
> > > On Sat, Nov 22, 2025 at 04:27:53PM +0100, Benjamin Drung wrote:
> > > > Hi Uwe,
> > > > 
> > > > On Fri, 2025-11-21 at 09:52 +0100, Uwe Kleine-König wrote:
> > > > > Hello Benjamin,
> > > > > 
> > > > > On Thu, Nov 20, 2025 at 11:11:07AM +0100, Benjamin Drung wrote:
> > > > > > On Thu, 2025-11-20 at 08:58 +0100, Uwe Kleine-König wrote:
> > > > > > > On Mon, Nov 17, 2025 at 02:05:41AM +0100, Benjamin Drung wrote:
> > > > > > > > On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
> > > > > > > > > Can you try adding
> > > > > > > > > 
> > > > > > > > > 	earlyprintk=serial,0x7e215040
> > > > > > > > > 
> > > > > > > > > to the kernel commandline. Not sure this activates the right procedures,
> > > > > > > > > maybe try it with the working kernel first.
> > > > > > > > 
> > > > > > > > I tried with the working kernel 6.12.43+deb13-rpi but these were the
> > > > > > > > earliest lines:
> > > > > > > > 
> > > > > > > > [    4.116565] printk: legacy console [ttyS1] enabled
> > > > > > > > [    4.129635] printk: legacy bootconsole [earlycon0] disabled
> > > > > > > > [    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
> > > > > > > > [    4.160972] mousedev: PS/2 mouse device common for all mice
> > > > > > > > [    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
> > > > > > > > [    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
> > > > > > > > 
> > > > > > > > I tried with 6.12.57+deb13-rpi but that failed to boot and the
> > > > > > > > earlyprintk line did not give any additional logs.
> > > > > > > 
> > > > > > > Can you please provide a full kernel log of the working kernel?
> > > > > > 
> > > > > > dmesg log is attached.
> > > > > > 
> > > > > > > Also please provide the output of:
> > > > > > > 
> > > > > > > 	for f in /proc/tty/driver/*; do echo $f; sed 's/^/  /' < $f; done
> > > > > > 
> > > > > > /proc/tty/driver/serial
> > > > > >   serinfo:1.0 driver revision:
> > > > > >   0: uart:unknown port:00000000 irq:0
> > > > > >   1: uart:16550 mmio:0x20215040 irq:53 tx:15629 rx:0 RTS|CTS|DTR
> > > > > >   2: uart:unknown port:00000000 irq:0
> > > > > >   3: uart:unknown port:00000000 irq:0
> > > > > > /proc/tty/driver/ttyAMA
> > > > > >   serinfo:1.0 driver revision:
> > > > > >   0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:452 rx:980 RTS|CTS|DTR
> > > > > 
> > > > > OK, is
> > > > > 
> > > > >  	earlyprintk=serial,0x20215040
> > > > > 
> > > > > more communicative then?
> > > > 
> > > > Nope, but I found
> > > > https://www.raspberrypi.com/documentation/computers/configuration.html#enabling-early-console-for-linux
> > > > and setting earlycon=uart8250,mmio32,0x20215040 worked. The kernel
> > > > 6.12.43+deb13-rpi booted with printing the early lines as well (see
> > > > dmesg of previous mail).
> > > > 
> > > > With all other experiments cleaned, I tried the latest kernel:
> > > > 
> > > > ```
> > > > $ cat /etc/default/raspi-extra-cmdline
> > > > earlycon=uart8250,mmio32,0x20215040
> > > > $ update-initramfs -u
> > > > ```
> > > > 
> > > > I got following logs before it got stuck:
> > > > 
> > > > ```
> > > > [    0.000000] Booting Linux on physical CPU 0x0
> > > > [    0.000000] Linux version 6.12.57+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.57-1 (2025-11-05)
> > > > [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> > > > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > > > [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
> > > > [    0.000000] random: crng init done
> > > > [    0.000000] earlycon: uart8250 at MMIO32 0x20215040 (options '')
> > > > [    0.000000] printk: legacy bootconsole [uart8250] enabled
> > > > [    0.000000] Memory policy: Data cache writeback
> > > > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > > > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > > > [    0.000000] cma: Reserved 64 MiB at 0x17000000 on node -1
> > > > ```
> > > > 
> > > > It looks like being cma related and I found a cma boot option in
> > > > /etc/default/raspi-firmware. So I modified /boot/firmware/cmdline.txt
> > > > and changed cma=64M to cma=0. Then the system booted without problems:
> > > > 
> > > > ```
> > > > [...]
> > > > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > > > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > > > [    0.000000] Zone ranges:
> > > > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > > > [    0.000000] Movable zone start for each node
> > > > [    0.000000] Early memory node ranges
> > > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > > > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > > > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=0 rootwait earlycon=uart8250,mmio32,0x20215040
> > > > [...]
> > > > ```
> > > > 
> > > > Then I persisted this change by setting CMA=0 in
> > > > /etc/default/raspi-firmware:
> > > > 
> > > > ```
> > > > $ grep -Ev '^(#|$)' /etc/default/raspi-firmware
> > > > CMA=0
> > > > $ update-initramfs -u
> > > > ```
> > > > 
> > > > This config removes the cma cmdline option completely. The system still
> > > > boots:
> > > > 
> > > > ```
> > > > [...]
> > > > [    0.000000] Memory policy: Data cache writeback
> > > > [    0.000000] Reserved memory: created CMA memory pool at 0x17000000, size 64 MiB
> > > > [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> > > > [    0.000000] OF: reserved mem: 0x17000000..0x1affffff (65536 KiB) map reusable linux,cma
> > > > [    0.000000] Zone ranges:
> > > > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > > > [    0.000000] Movable zone start for each node
> > > > [    0.000000] Early memory node ranges
> > > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > > > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > > > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0  rootwait earlycon=uart8250,mmio32,0x20215040
> > > > [...]
> > > > ```
> > > > 
> > > > That should hopefully narrow down the issue space.
> > > 
> > > If I'm not wrong the only cma related change between 6.12.43 and
> > > 6.12.48 was the backport of 2c223f7239f3 ("of: reserved_mem:
> > > Restructure call site for dma_contiguous_early_fixup()"):
> > > 
> > > 	commit 46efab01648a04082266115a8e917c3b26b97fa8
> > > 	Author: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> > > 	Date:   Wed Aug 6 10:24:21 2025 -0700
> > > 
> > > 	    of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()
> > > 
> > > 	    [ Upstream commit 2c223f7239f376a90d71903ec474ba887cf21d94 ]
> > > 
> > > 	    Restructure the call site for dma_contiguous_early_fixup() to
> > > 	    where the reserved_mem nodes are being parsed from the DT so that
> > > 	    dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
> > > 
> > > 	    Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
> > > 	    Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> > > 	    Tested-by: William Zhang <william.zhang@broadcom.com>
> > > 	    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > 	    Link: https://lore.kernel.org/r/20250806172421.2748302-1-oreoluwa.babatunde@oss.qualcomm.com
> > > 	    Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > 
> > > Uwe, would that make sense? Benjamin can you try to make a build with
> > > that commit reverted, does it fix the problem?
> > 
> > Building the kernel on the Pi Zero would probably take ages. I have a
> > Raspberry Pi 5 running arm64. That should be able to build the kernel in
> > a armel schroot, shouldn't it? Is there documentation for building the
> > kernel?
> 
> I hope it is fine for Uwe that i respond here, he might have another
> more efficient way to reach our goal.
> 
> But we have the simple-patching guideline here:
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> 
> That should work within an armel schroot work well, e.g. on a
> porterbox amdahl.d.o i would first setup a schroot via:
> 
> schroot -b -c chroot:trixie_armel-dchroot -n linux
> dd-schroot-cmd -c linux apt-get update
> dd-schroot-cmd -c linux apt-get dist-upgrade
> dd-schroot-cmd -c linux apt-get build-dep linux
> schroot -r -c linux
> (see https://dsa.debian.org/doc/schroot/)
> 
> Then download the linux/6.12.57-1 source and make the revert patch
> available.
> 
> apt-get source linux
> cd linux-*
> ./debian/bin/test-patches -f rpi ../0001-Revert-of-reserved_mem-Restructure-call-site-for-dma.patch

In case you can/want trust unsigned packages (but I have put a
sha256sum along signed with my key in the DD keyring), you can test
the patch revert via the packages on:
https://people.debian.org/~carnil/tmp/linux/1116251/

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90512

FromBenjamin Drung <bdrung@debian.org>
Date2025-12-17 22:30 +0100
Message-ID<M37fP-3Fpb-3@gated-at.bofh.it>
In reply to#90329

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2025-11-30 at 10:27 +0100, Salvatore Bonaccorso wrote:
> Hi Benjmanin,
> 
> On Sat, Nov 29, 2025 at 12:02:00AM +0100, Salvatore Bonaccorso wrote:
> > Hi Benjamin,
> > 
> > On Fri, Nov 28, 2025 at 10:53:17PM +0100, Benjamin Drung wrote:
> > > On Wed, 2025-11-26 at 08:52 +0100, Salvatore Bonaccorso wrote:
> > > > Control: tags -1 + moreinfo
> > > > 
> > > > Hi,
> > > > 
> > > > On Sat, Nov 22, 2025 at 04:27:53PM +0100, Benjamin Drung wrote:
> > > > > Hi Uwe,
> > > > > 
> > > > > On Fri, 2025-11-21 at 09:52 +0100, Uwe Kleine-König wrote:
> > > > > > Hello Benjamin,
> > > > > > 
> > > > > > On Thu, Nov 20, 2025 at 11:11:07AM +0100, Benjamin Drung wrote:
> > > > > > > On Thu, 2025-11-20 at 08:58 +0100, Uwe Kleine-König wrote:
> > > > > > > > On Mon, Nov 17, 2025 at 02:05:41AM +0100, Benjamin Drung wrote:
> > > > > > > > > On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
> > > > > > > > > > Can you try adding
> > > > > > > > > > 
> > > > > > > > > > 	earlyprintk=serial,0x7e215040
> > > > > > > > > > 
> > > > > > > > > > to the kernel commandline. Not sure this activates the right procedures,
> > > > > > > > > > maybe try it with the working kernel first.
> > > > > > > > > 
> > > > > > > > > I tried with the working kernel 6.12.43+deb13-rpi but these were the
> > > > > > > > > earliest lines:
> > > > > > > > > 
> > > > > > > > > [    4.116565] printk: legacy console [ttyS1] enabled
> > > > > > > > > [    4.129635] printk: legacy bootconsole [earlycon0] disabled
> > > > > > > > > [    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
> > > > > > > > > [    4.160972] mousedev: PS/2 mouse device common for all mice
> > > > > > > > > [    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
> > > > > > > > > [    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
> > > > > > > > > 
> > > > > > > > > I tried with 6.12.57+deb13-rpi but that failed to boot and the
> > > > > > > > > earlyprintk line did not give any additional logs.
> > > > > > > > 
> > > > > > > > Can you please provide a full kernel log of the working kernel?
> > > > > > > 
> > > > > > > dmesg log is attached.
> > > > > > > 
> > > > > > > > Also please provide the output of:
> > > > > > > > 
> > > > > > > > 	for f in /proc/tty/driver/*; do echo $f; sed 's/^/  /' < $f; done
> > > > > > > 
> > > > > > > /proc/tty/driver/serial
> > > > > > >   serinfo:1.0 driver revision:
> > > > > > >   0: uart:unknown port:00000000 irq:0
> > > > > > >   1: uart:16550 mmio:0x20215040 irq:53 tx:15629 rx:0 RTS|CTS|DTR
> > > > > > >   2: uart:unknown port:00000000 irq:0
> > > > > > >   3: uart:unknown port:00000000 irq:0
> > > > > > > /proc/tty/driver/ttyAMA
> > > > > > >   serinfo:1.0 driver revision:
> > > > > > >   0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:452 rx:980 RTS|CTS|DTR
> > > > > > 
> > > > > > OK, is
> > > > > > 
> > > > > >  	earlyprintk=serial,0x20215040
> > > > > > 
> > > > > > more communicative then?
> > > > > 
> > > > > Nope, but I found
> > > > > https://www.raspberrypi.com/documentation/computers/configuration.html#enabling-early-console-for-linux
> > > > > and setting earlycon=uart8250,mmio32,0x20215040 worked. The kernel
> > > > > 6.12.43+deb13-rpi booted with printing the early lines as well (see
> > > > > dmesg of previous mail).
> > > > > 
> > > > > With all other experiments cleaned, I tried the latest kernel:
> > > > > 
> > > > > ```
> > > > > $ cat /etc/default/raspi-extra-cmdline
> > > > > earlycon=uart8250,mmio32,0x20215040
> > > > > $ update-initramfs -u
> > > > > ```
> > > > > 
> > > > > I got following logs before it got stuck:
> > > > > 
> > > > > ```
> > > > > [    0.000000] Booting Linux on physical CPU 0x0
> > > > > [    0.000000] Linux version 6.12.57+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.57-1 (2025-11-05)
> > > > > [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> > > > > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > > > > [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
> > > > > [    0.000000] random: crng init done
> > > > > [    0.000000] earlycon: uart8250 at MMIO32 0x20215040 (options '')
> > > > > [    0.000000] printk: legacy bootconsole [uart8250] enabled
> > > > > [    0.000000] Memory policy: Data cache writeback
> > > > > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > > > > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > > > > [    0.000000] cma: Reserved 64 MiB at 0x17000000 on node -1
> > > > > ```
> > > > > 
> > > > > It looks like being cma related and I found a cma boot option in
> > > > > /etc/default/raspi-firmware. So I modified /boot/firmware/cmdline.txt
> > > > > and changed cma=64M to cma=0. Then the system booted without problems:
> > > > > 
> > > > > ```
> > > > > [...]
> > > > > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > > > > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > > > > [    0.000000] Zone ranges:
> > > > > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > > > > [    0.000000] Movable zone start for each node
> > > > > [    0.000000] Early memory node ranges
> > > > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > > > > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > > > > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=0 rootwait earlycon=uart8250,mmio32,0x20215040
> > > > > [...]
> > > > > ```
> > > > > 
> > > > > Then I persisted this change by setting CMA=0 in
> > > > > /etc/default/raspi-firmware:
> > > > > 
> > > > > ```
> > > > > $ grep -Ev '^(#|$)' /etc/default/raspi-firmware
> > > > > CMA=0
> > > > > $ update-initramfs -u
> > > > > ```
> > > > > 
> > > > > This config removes the cma cmdline option completely. The system still
> > > > > boots:
> > > > > 
> > > > > ```
> > > > > [...]
> > > > > [    0.000000] Memory policy: Data cache writeback
> > > > > [    0.000000] Reserved memory: created CMA memory pool at 0x17000000, size 64 MiB
> > > > > [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> > > > > [    0.000000] OF: reserved mem: 0x17000000..0x1affffff (65536 KiB) map reusable linux,cma
> > > > > [    0.000000] Zone ranges:
> > > > > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > > > > [    0.000000] Movable zone start for each node
> > > > > [    0.000000] Early memory node ranges
> > > > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > > > > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > > > > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0  rootwait earlycon=uart8250,mmio32,0x20215040
> > > > > [...]
> > > > > ```
> > > > > 
> > > > > That should hopefully narrow down the issue space.
> > > > 
> > > > If I'm not wrong the only cma related change between 6.12.43 and
> > > > 6.12.48 was the backport of 2c223f7239f3 ("of: reserved_mem:
> > > > Restructure call site for dma_contiguous_early_fixup()"):
> > > > 
> > > > 	commit 46efab01648a04082266115a8e917c3b26b97fa8
> > > > 	Author: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> > > > 	Date:   Wed Aug 6 10:24:21 2025 -0700
> > > > 
> > > > 	    of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()
> > > > 
> > > > 	    [ Upstream commit 2c223f7239f376a90d71903ec474ba887cf21d94 ]
> > > > 
> > > > 	    Restructure the call site for dma_contiguous_early_fixup() to
> > > > 	    where the reserved_mem nodes are being parsed from the DT so that
> > > > 	    dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
> > > > 
> > > > 	    Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
> > > > 	    Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> > > > 	    Tested-by: William Zhang <william.zhang@broadcom.com>
> > > > 	    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > 	    Link: https://lore.kernel.org/r/20250806172421.2748302-1-oreoluwa.babatunde@oss.qualcomm.com
> > > > 	    Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > > 
> > > > Uwe, would that make sense? Benjamin can you try to make a build with
> > > > that commit reverted, does it fix the problem?
> > > 
> > > Building the kernel on the Pi Zero would probably take ages. I have a
> > > Raspberry Pi 5 running arm64. That should be able to build the kernel in
> > > a armel schroot, shouldn't it? Is there documentation for building the
> > > kernel?
> > 
> > I hope it is fine for Uwe that i respond here, he might have another
> > more efficient way to reach our goal.
> > 
> > But we have the simple-patching guideline here:
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> > 
> > That should work within an armel schroot work well, e.g. on a
> > porterbox amdahl.d.o i would first setup a schroot via:
> > 
> > schroot -b -c chroot:trixie_armel-dchroot -n linux
> > dd-schroot-cmd -c linux apt-get update
> > dd-schroot-cmd -c linux apt-get dist-upgrade
> > dd-schroot-cmd -c linux apt-get build-dep linux
> > schroot -r -c linux
> > (see https://dsa.debian.org/doc/schroot/)
> > 
> > Then download the linux/6.12.57-1 source and make the revert patch
> > available.
> > 
> > apt-get source linux
> > cd linux-*
> > ./debian/bin/test-patches -f rpi ../0001-Revert-of-reserved_mem-Restructure-call-site-for-dma.patch
> 
> In case you can/want trust unsigned packages (but I have put a
> sha256sum along signed with my key in the DD keyring), you can test
> the patch revert via the packages on:
> https://people.debian.org/~carnil/tmp/linux/1116251/

Thanks for providing the kernel. I downloaded linux-image-
6.12+unreleased-rpi_6.12.57-1a~test_armel.deb and installed it. This
kernel hangs on boot (see attached boot.log). It hangs there
reproducible.

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [prev] | [next] | [standalone]

#90514

FromBenjamin Drung <bdrung@debian.org>
Date2025-12-17 23:20 +0100
Message-ID<M382d-3FZK-5@gated-at.bofh.it>
In reply to#90512
On Wed, 2025-12-17 at 22:20 +0100, Benjamin Drung wrote:
> On Sun, 2025-11-30 at 10:27 +0100, Salvatore Bonaccorso wrote:
> > Hi Benjmanin,
> > 
> > On Sat, Nov 29, 2025 at 12:02:00AM +0100, Salvatore Bonaccorso wrote:
> > > Hi Benjamin,
> > > 
> > > On Fri, Nov 28, 2025 at 10:53:17PM +0100, Benjamin Drung wrote:
> > > > On Wed, 2025-11-26 at 08:52 +0100, Salvatore Bonaccorso wrote:
> > > > > Control: tags -1 + moreinfo
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > On Sat, Nov 22, 2025 at 04:27:53PM +0100, Benjamin Drung wrote:
> > > > > > Hi Uwe,
> > > > > > 
> > > > > > On Fri, 2025-11-21 at 09:52 +0100, Uwe Kleine-König wrote:
> > > > > > > Hello Benjamin,
> > > > > > > 
> > > > > > > On Thu, Nov 20, 2025 at 11:11:07AM +0100, Benjamin Drung wrote:
> > > > > > > > On Thu, 2025-11-20 at 08:58 +0100, Uwe Kleine-König wrote:
> > > > > > > > > On Mon, Nov 17, 2025 at 02:05:41AM +0100, Benjamin Drung wrote:
> > > > > > > > > > On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
> > > > > > > > > > > Can you try adding
> > > > > > > > > > > 
> > > > > > > > > > > 	earlyprintk=serial,0x7e215040
> > > > > > > > > > > 
> > > > > > > > > > > to the kernel commandline. Not sure this activates the right procedures,
> > > > > > > > > > > maybe try it with the working kernel first.
> > > > > > > > > > 
> > > > > > > > > > I tried with the working kernel 6.12.43+deb13-rpi but these were the
> > > > > > > > > > earliest lines:
> > > > > > > > > > 
> > > > > > > > > > [    4.116565] printk: legacy console [ttyS1] enabled
> > > > > > > > > > [    4.129635] printk: legacy bootconsole [earlycon0] disabled
> > > > > > > > > > [    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
> > > > > > > > > > [    4.160972] mousedev: PS/2 mouse device common for all mice
> > > > > > > > > > [    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
> > > > > > > > > > [    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
> > > > > > > > > > 
> > > > > > > > > > I tried with 6.12.57+deb13-rpi but that failed to boot and the
> > > > > > > > > > earlyprintk line did not give any additional logs.
> > > > > > > > > 
> > > > > > > > > Can you please provide a full kernel log of the working kernel?
> > > > > > > > 
> > > > > > > > dmesg log is attached.
> > > > > > > > 
> > > > > > > > > Also please provide the output of:
> > > > > > > > > 
> > > > > > > > > 	for f in /proc/tty/driver/*; do echo $f; sed 's/^/  /' < $f; done
> > > > > > > > 
> > > > > > > > /proc/tty/driver/serial
> > > > > > > >   serinfo:1.0 driver revision:
> > > > > > > >   0: uart:unknown port:00000000 irq:0
> > > > > > > >   1: uart:16550 mmio:0x20215040 irq:53 tx:15629 rx:0 RTS|CTS|DTR
> > > > > > > >   2: uart:unknown port:00000000 irq:0
> > > > > > > >   3: uart:unknown port:00000000 irq:0
> > > > > > > > /proc/tty/driver/ttyAMA
> > > > > > > >   serinfo:1.0 driver revision:
> > > > > > > >   0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:452 rx:980 RTS|CTS|DTR
> > > > > > > 
> > > > > > > OK, is
> > > > > > > 
> > > > > > >  	earlyprintk=serial,0x20215040
> > > > > > > 
> > > > > > > more communicative then?
> > > > > > 
> > > > > > Nope, but I found
> > > > > > https://www.raspberrypi.com/documentation/computers/configuration.html#enabling-early-console-for-linux
> > > > > > and setting earlycon=uart8250,mmio32,0x20215040 worked. The kernel
> > > > > > 6.12.43+deb13-rpi booted with printing the early lines as well (see
> > > > > > dmesg of previous mail).
> > > > > > 
> > > > > > With all other experiments cleaned, I tried the latest kernel:
> > > > > > 
> > > > > > ```
> > > > > > $ cat /etc/default/raspi-extra-cmdline
> > > > > > earlycon=uart8250,mmio32,0x20215040
> > > > > > $ update-initramfs -u
> > > > > > ```
> > > > > > 
> > > > > > I got following logs before it got stuck:
> > > > > > 
> > > > > > ```
> > > > > > [    0.000000] Booting Linux on physical CPU 0x0
> > > > > > [    0.000000] Linux version 6.12.57+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.57-1 (2025-11-05)
> > > > > > [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> > > > > > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > > > > > [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
> > > > > > [    0.000000] random: crng init done
> > > > > > [    0.000000] earlycon: uart8250 at MMIO32 0x20215040 (options '')
> > > > > > [    0.000000] printk: legacy bootconsole [uart8250] enabled
> > > > > > [    0.000000] Memory policy: Data cache writeback
> > > > > > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > > > > > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > > > > > [    0.000000] cma: Reserved 64 MiB at 0x17000000 on node -1
> > > > > > ```
> > > > > > 
> > > > > > It looks like being cma related and I found a cma boot option in
> > > > > > /etc/default/raspi-firmware. So I modified /boot/firmware/cmdline.txt
> > > > > > and changed cma=64M to cma=0. Then the system booted without problems:
> > > > > > 
> > > > > > ```
> > > > > > [...]
> > > > > > [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
> > > > > > [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
> > > > > > [    0.000000] Zone ranges:
> > > > > > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > > > > > [    0.000000] Movable zone start for each node
> > > > > > [    0.000000] Early memory node ranges
> > > > > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > > > > > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > > > > > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=0 rootwait earlycon=uart8250,mmio32,0x20215040
> > > > > > [...]
> > > > > > ```
> > > > > > 
> > > > > > Then I persisted this change by setting CMA=0 in
> > > > > > /etc/default/raspi-firmware:
> > > > > > 
> > > > > > ```
> > > > > > $ grep -Ev '^(#|$)' /etc/default/raspi-firmware
> > > > > > CMA=0
> > > > > > $ update-initramfs -u
> > > > > > ```
> > > > > > 
> > > > > > This config removes the cma cmdline option completely. The system still
> > > > > > boots:
> > > > > > 
> > > > > > ```
> > > > > > [...]
> > > > > > [    0.000000] Memory policy: Data cache writeback
> > > > > > [    0.000000] Reserved memory: created CMA memory pool at 0x17000000, size 64 MiB
> > > > > > [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> > > > > > [    0.000000] OF: reserved mem: 0x17000000..0x1affffff (65536 KiB) map reusable linux,cma
> > > > > > [    0.000000] Zone ranges:
> > > > > > [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
> > > > > > [    0.000000] Movable zone start for each node
> > > > > > [    0.000000] Early memory node ranges
> > > > > > [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
> > > > > > [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
> > > > > > [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0  rootwait earlycon=uart8250,mmio32,0x20215040
> > > > > > [...]
> > > > > > ```
> > > > > > 
> > > > > > That should hopefully narrow down the issue space.
> > > > > 
> > > > > If I'm not wrong the only cma related change between 6.12.43 and
> > > > > 6.12.48 was the backport of 2c223f7239f3 ("of: reserved_mem:
> > > > > Restructure call site for dma_contiguous_early_fixup()"):
> > > > > 
> > > > > 	commit 46efab01648a04082266115a8e917c3b26b97fa8
> > > > > 	Author: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> > > > > 	Date:   Wed Aug 6 10:24:21 2025 -0700
> > > > > 
> > > > > 	    of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()
> > > > > 
> > > > > 	    [ Upstream commit 2c223f7239f376a90d71903ec474ba887cf21d94 ]
> > > > > 
> > > > > 	    Restructure the call site for dma_contiguous_early_fixup() to
> > > > > 	    where the reserved_mem nodes are being parsed from the DT so that
> > > > > 	    dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
> > > > > 
> > > > > 	    Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
> > > > > 	    Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> > > > > 	    Tested-by: William Zhang <william.zhang@broadcom.com>
> > > > > 	    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > 	    Link: https://lore.kernel.org/r/20250806172421.2748302-1-oreoluwa.babatunde@oss.qualcomm.com
> > > > > 	    Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > > > 
> > > > > Uwe, would that make sense? Benjamin can you try to make a build with
> > > > > that commit reverted, does it fix the problem?
> > > > 
> > > > Building the kernel on the Pi Zero would probably take ages. I have a
> > > > Raspberry Pi 5 running arm64. That should be able to build the kernel in
> > > > a armel schroot, shouldn't it? Is there documentation for building the
> > > > kernel?
> > > 
> > > I hope it is fine for Uwe that i respond here, he might have another
> > > more efficient way to reach our goal.
> > > 
> > > But we have the simple-patching guideline here:
> > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> > > 
> > > That should work within an armel schroot work well, e.g. on a
> > > porterbox amdahl.d.o i would first setup a schroot via:
> > > 
> > > schroot -b -c chroot:trixie_armel-dchroot -n linux
> > > dd-schroot-cmd -c linux apt-get update
> > > dd-schroot-cmd -c linux apt-get dist-upgrade
> > > dd-schroot-cmd -c linux apt-get build-dep linux
> > > schroot -r -c linux
> > > (see https://dsa.debian.org/doc/schroot/)
> > > 
> > > Then download the linux/6.12.57-1 source and make the revert patch
> > > available.
> > > 
> > > apt-get source linux
> > > cd linux-*
> > > ./debian/bin/test-patches -f rpi ../0001-Revert-of-reserved_mem-Restructure-call-site-for-dma.patch
> > 
> > In case you can/want trust unsigned packages (but I have put a
> > sha256sum along signed with my key in the DD keyring), you can test
> > the patch revert via the packages on:
> > https://people.debian.org/~carnil/tmp/linux/1116251/
> 
> Thanks for providing the kernel. I downloaded linux-image-
> 6.12+unreleased-rpi_6.12.57-1a~test_armel.deb and installed it. This
> kernel hangs on boot (see attached boot.log). It hangs there
> reproducible.

The "Linux version 4.14.98+" in the log puzzled me and
/etc/kernel/postinst.d/z50-raspi-firmware did not copy kernel
6.12.57-1a~test to /boot/firmware.

I found the old kernel.img and kernel7.img that I deleted. I copied the
6.12.57-1a~test kernel manually:

```
update-initramfs -u -k 6.12+unreleased-rpi
cd /boot/firmware/
cp ../vmlinuz-6.12+unreleased-rpi .
cp ../initrd.img-6.12+unreleased-rpi .
vim config.txt
reboot
```

Then the Pi booted the correct kernel (6.12+unreleased-rpi) successfully
with following cmdline configurations:

* no cma set
* cma=0
* cma=64M

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [prev] | [next] | [standalone]

#90267 — Processed: Re: Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2025-11-26 09:00 +0100
SubjectProcessed: Re: Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot
Message-ID<LViBs-fPG0-11@gated-at.bofh.it>
In reply to#89399
Processing control commands:

> tags -1 + moreinfo
Bug #1116251 [src:linux] linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot
Added tag(s) moreinfo.

-- 
1116251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116251
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#90517

FromMarek Szyprowski <m.szyprowski@samsung.com>
Date2025-12-18 12:50 +0100
Message-ID<M3kG5-3OIj-1@gated-at.bofh.it>
In reply to#89399
On 18.12.2025 09:29, Uwe Kleine-König wrote:
> Control: forwarded -1 https://lore.kernel.org/linux-iommu/hnwgn7glub4klmkzabzcm76eldaa3xm5ua72eldwzesblveo2a@4xq2bxhmbsyq
> Hello,
>
> I extended the audience to people involved in the creation of
> 2c223f7239f376a90d71903ec474ba887cf21d94.
>
> On Wed, Dec 17, 2025 at 11:07:00PM +0100, Benjamin Drung wrote:
>> On Wed, 2025-12-17 at 22:20 +0100, Benjamin Drung wrote:
>>> On Sun, 2025-11-30 at 10:27 +0100, Salvatore Bonaccorso wrote:
>>>> On Sat, Nov 29, 2025 at 12:02:00AM +0100, Salvatore Bonaccorso wrote:
>>>>> On Fri, Nov 28, 2025 at 10:53:17PM +0100, Benjamin Drung wrote:
>>>>>> On Wed, 2025-11-26 at 08:52 +0100, Salvatore Bonaccorso wrote:
>>>>>>> On Sat, Nov 22, 2025 at 04:27:53PM +0100, Benjamin Drung wrote:
>>>>>>>> On Fri, 2025-11-21 at 09:52 +0100, Uwe Kleine-König wrote:
>>>>>>>>> On Thu, Nov 20, 2025 at 11:11:07AM +0100, Benjamin Drung wrote:
>>>>>>>>>> On Thu, 2025-11-20 at 08:58 +0100, Uwe Kleine-König wrote:
>>>>>>>>>>> On Mon, Nov 17, 2025 at 02:05:41AM +0100, Benjamin Drung wrote:
>>>>>>>>>>>> On Wed, 2025-11-05 at 20:14 +0100, Uwe Kleine-König wrote:
>>>>>>>>>>>>> Can you try adding
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	earlyprintk=serial,0x7e215040
>>>>>>>>>>>>>
>>>>>>>>>>>>> to the kernel commandline. Not sure this activates the right procedures,
>>>>>>>>>>>>> maybe try it with the working kernel first.
>>>>>>>>>>>> I tried with the working kernel 6.12.43+deb13-rpi but these were the
>>>>>>>>>>>> earliest lines:
>>>>>>>>>>>>
>>>>>>>>>>>> [    4.116565] printk: legacy console [ttyS1] enabled
>>>>>>>>>>>> [    4.129635] printk: legacy bootconsole [earlycon0] disabled
>>>>>>>>>>>> [    4.147050] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
>>>>>>>>>>>> [    4.160972] mousedev: PS/2 mouse device common for all mice
>>>>>>>>>>>> [    4.172622] i2c-bcm2835 20805000.i2c: Could not read clock-frequency property
>>>>>>>>>>>> [    4.186585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
>>>>>>>>>>>>
>>>>>>>>>>>> I tried with 6.12.57+deb13-rpi but that failed to boot and the
>>>>>>>>>>>> earlyprintk line did not give any additional logs.
>>>>>>>>>>> Can you please provide a full kernel log of the working kernel?
>>>>>>>>>> dmesg log is attached.
>>>>>>>>>>
>>>>>>>>>>> Also please provide the output of:
>>>>>>>>>>>
>>>>>>>>>>> 	for f in /proc/tty/driver/*; do echo $f; sed 's/^/  /' < $f; done
>>>>>>>>>> /proc/tty/driver/serial
>>>>>>>>>>    serinfo:1.0 driver revision:
>>>>>>>>>>    0: uart:unknown port:00000000 irq:0
>>>>>>>>>>    1: uart:16550 mmio:0x20215040 irq:53 tx:15629 rx:0 RTS|CTS|DTR
>>>>>>>>>>    2: uart:unknown port:00000000 irq:0
>>>>>>>>>>    3: uart:unknown port:00000000 irq:0
>>>>>>>>>> /proc/tty/driver/ttyAMA
>>>>>>>>>>    serinfo:1.0 driver revision:
>>>>>>>>>>    0: uart:PL011 rev2 mmio:0x20201000 irq:81 tx:452 rx:980 RTS|CTS|DTR
>>>>>>>>> OK, is
>>>>>>>>>
>>>>>>>>>   	earlyprintk=serial,0x20215040
>>>>>>>>>
>>>>>>>>> more communicative then?
>>>>>>>> Nope, but I found
>>>>>>>> https://www.raspberrypi.com/documentation/computers/configuration.html#enabling-early-console-for-linux
>>>>>>>> and setting earlycon=uart8250,mmio32,0x20215040 worked. The kernel
>>>>>>>> 6.12.43+deb13-rpi booted with printing the early lines as well (see
>>>>>>>> dmesg of previous mail).
>>>>>>>>
>>>>>>>> With all other experiments cleaned, I tried the latest kernel:
>>>>>>>>
>>>>>>>> ```
>>>>>>>> $ cat /etc/default/raspi-extra-cmdline
>>>>>>>> earlycon=uart8250,mmio32,0x20215040
>>>>>>>> $ update-initramfs -u
>>>>>>>> ```
>>>>>>>>
>>>>>>>> I got following logs before it got stuck:
>>>>>>>>
>>>>>>>> ```
>>>>>>>> [    0.000000] Booting Linux on physical CPU 0x0
>>>>>>>> [    0.000000] Linux version 6.12.57+deb13-rpi (debian-kernel@lists.debian.org) (arm-linux-gnueabi-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 Debian 6.12.57-1 (2025-11-05)
>>>>>>>> [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
>>>>>>>> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
>>>>>>>> [    0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1
>>>>>>>> [    0.000000] random: crng init done
>>>>>>>> [    0.000000] earlycon: uart8250 at MMIO32 0x20215040 (options '')
>>>>>>>> [    0.000000] printk: legacy bootconsole [uart8250] enabled
>>>>>>>> [    0.000000] Memory policy: Data cache writeback
>>>>>>>> [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
>>>>>>>> [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
>>>>>>>> [    0.000000] cma: Reserved 64 MiB at 0x17000000 on node -1
>>>>>>>> ```
>>>>>>>>
>>>>>>>> It looks like being cma related and I found a cma boot option in
>>>>>>>> /etc/default/raspi-firmware. So I modified /boot/firmware/cmdline.txt
>>>>>>>> and changed cma=64M to cma=0. Then the system booted without problems:
>>>>>>>>
>>>>>>>> ```
>>>>>>>> [...]
>>>>>>>> [    0.000000] Reserved memory: bypass linux,cma node, using cmdline CMA params instead
>>>>>>>> [    0.000000] OF: reserved mem: node linux,cma compatible matching fail
>>>>>>>> [    0.000000] Zone ranges:
>>>>>>>> [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
>>>>>>>> [    0.000000] Movable zone start for each node
>>>>>>>> [    0.000000] Early memory node ranges
>>>>>>>> [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
>>>>>>>> [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
>>>>>>>> [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 cma=0 rootwait earlycon=uart8250,mmio32,0x20215040
>>>>>>>> [...]
>>>>>>>> ```
>>>>>>>>
>>>>>>>> Then I persisted this change by setting CMA=0 in
>>>>>>>> /etc/default/raspi-firmware:
>>>>>>>>
>>>>>>>> ```
>>>>>>>> $ grep -Ev '^(#|$)' /etc/default/raspi-firmware
>>>>>>>> CMA=0
>>>>>>>> $ update-initramfs -u
>>>>>>>> ```
>>>>>>>>
>>>>>>>> This config removes the cma cmdline option completely. The system still
>>>>>>>> boots:
>>>>>>>>
>>>>>>>> ```
>>>>>>>> [...]
>>>>>>>> [    0.000000] Memory policy: Data cache writeback
>>>>>>>> [    0.000000] Reserved memory: created CMA memory pool at 0x17000000, size 64 MiB
>>>>>>>> [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
>>>>>>>> [    0.000000] OF: reserved mem: 0x17000000..0x1affffff (65536 KiB) map reusable linux,cma
>>>>>>>> [    0.000000] Zone ranges:
>>>>>>>> [    0.000000]   Normal   [mem 0x0000000000000000-0x000000001bffffff]
>>>>>>>> [    0.000000] Movable zone start for each node
>>>>>>>> [    0.000000] Early memory node ranges
>>>>>>>> [    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
>>>>>>>> [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001bffffff]
>>>>>>>> [    0.000000] Kernel command line:  dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x8bb1238 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:BB:12:38 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0  rootwait earlycon=uart8250,mmio32,0x20215040
>>>>>>>> [...]
>>>>>>>> ```
>>>>>>>>
>>>>>>>> That should hopefully narrow down the issue space.
>>>>>>> If I'm not wrong the only cma related change between 6.12.43 and
>>>>>>> 6.12.48 was the backport of 2c223f7239f3 ("of: reserved_mem:
>>>>>>> Restructure call site for dma_contiguous_early_fixup()"):
>>>>>>>
>>>>>>> 	commit 46efab01648a04082266115a8e917c3b26b97fa8
>>>>>>> 	Author: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>>>>>>> 	Date:   Wed Aug 6 10:24:21 2025 -0700
>>>>>>>
>>>>>>> 	    of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()
>>>>>>>
>>>>>>> 	    [ Upstream commit 2c223f7239f376a90d71903ec474ba887cf21d94 ]
>>>>>>>
>>>>>>> 	    Restructure the call site for dma_contiguous_early_fixup() to
>>>>>>> 	    where the reserved_mem nodes are being parsed from the DT so that
>>>>>>> 	    dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>>>>>>>
>>>>>>> 	    Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
>>>>>>> 	    Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>>>>>>> 	    Tested-by: William Zhang <william.zhang@broadcom.com>
>>>>>>> 	    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>> 	    Link: https://lore.kernel.org/r/20250806172421.2748302-1-oreoluwa.babatunde@oss.qualcomm.com
>>>>>>> 	    Signed-off-by: Sasha Levin <sashal@kernel.org>
>>>>>>>
>>>>>>> Uwe, would that make sense? Benjamin can you try to make a build with
>>>>>>> that commit reverted, does it fix the problem?
>>>>>> Building the kernel on the Pi Zero would probably take ages. I have a
>>>>>> Raspberry Pi 5 running arm64. That should be able to build the kernel in
>>>>>> a armel schroot, shouldn't it? Is there documentation for building the
>>>>>> kernel?
>>>>> I hope it is fine for Uwe that i respond here, he might have another
>>>>> more efficient way to reach our goal.
>>>>>
>>>>> But we have the simple-patching guideline here:
>>>>> https://protect2.fireeye.com/v1/url?k=6d29844b-0ca29171-6d280f04-74fe4860008a-0bd2c61b0efaf6bb&q=1&e=9d70d889-a8df-4ca7-962f-11b3a6da1b85&u=https%3A%2F%2Fkernel-team.pages.debian.net%2Fkernel-handbook%2Fch-common-tasks.html%23id-1.6.6.4
>>>>>
>>>>> That should work within an armel schroot work well, e.g. on a
>>>>> porterbox amdahl.d.o i would first setup a schroot via:
>>>>>
>>>>> schroot -b -c chroot:trixie_armel-dchroot -n linux
>>>>> dd-schroot-cmd -c linux apt-get update
>>>>> dd-schroot-cmd -c linux apt-get dist-upgrade
>>>>> dd-schroot-cmd -c linux apt-get build-dep linux
>>>>> schroot -r -c linux
>>>>> (see https://dsa.debian.org/doc/schroot/)
>>>>>
>>>>> Then download the linux/6.12.57-1 source and make the revert patch
>>>>> available.
>>>>>
>>>>> apt-get source linux
>>>>> cd linux-*
>>>>> ./debian/bin/test-patches -f rpi ../0001-Revert-of-reserved_mem-Restructure-call-site-for-dma.patch
>>>> In case you can/want trust unsigned packages (but I have put a
>>>> sha256sum along signed with my key in the DD keyring), you can test
>>>> the patch revert via the packages on:
>>>> https://people.debian.org/~carnil/tmp/linux/1116251/
>>> Thanks for providing the kernel. I downloaded linux-image-
>>> 6.12+unreleased-rpi_6.12.57-1a~test_armel.deb and installed it. This
>>> kernel hangs on boot (see attached boot.log). It hangs there
>>> reproducible.
>> The "Linux version 4.14.98+" in the log puzzled me and
>> /etc/kernel/postinst.d/z50-raspi-firmware did not copy kernel
>> 6.12.57-1a~test to /boot/firmware.
>>
>> I found the old kernel.img and kernel7.img that I deleted. I copied the
>> 6.12.57-1a~test kernel manually:
>>
>> ```
>> update-initramfs -u -k 6.12+unreleased-rpi
>> cd /boot/firmware/
>> cp ../vmlinuz-6.12+unreleased-rpi .
>> cp ../initrd.img-6.12+unreleased-rpi .
>> vim config.txt
>> reboot
>> ```
>>
>> Then the Pi booted the correct kernel (6.12+unreleased-rpi) successfully
>> with following cmdline configurations:
>>
>> * no cma set
>> * cma=0
>> * cma=64M
> If I understood right that means that
> 46efab01648a04082266115a8e917c3b26b97fa8 aka
> 2c223f7239f376a90d71903ec474ba887cf21d94 broke booting on the Raspberry
> Pi Zero W when CMA is used.
>
> #regzbot introduced: 2c223f7239f376a90d71903ec474ba887cf21d94
>
> Does this ring a bell for someone, or do you have some debugging
> instructions? Complete context is available at
> https://bugs.debian.org/1116251.

There is a fix posted for this case, but it needs a bit more discussion:

https://lore.kernel.org/all/20251210002027.1171519-1-oreoluwa.babatunde@oss.qualcomm.com/

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[toc] | [prev] | [next] | [standalone]

#90519 — Processed: Re: Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2025-12-18 13:40 +0100
SubjectProcessed: Re: Bug#1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot
Message-ID<M3lst-3Pol-11@gated-at.bofh.it>
In reply to#89399
Processing control commands:

> forwarded -1 https://lore.kernel.org/linux-iommu/hnwgn7glub4klmkzabzcm76eldaa3xm5ua72eldwzesblveo2a@4xq2bxhmbsyq
Bug #1116251 [src:linux] linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot
Set Bug forwarded-to-address to 'https://lore.kernel.org/linux-iommu/hnwgn7glub4klmkzabzcm76eldaa3xm5ua72eldwzesblveo2a@4xq2bxhmbsyq'.

-- 
1116251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116251
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web