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

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

Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

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

Contents

  Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen) Cyril Brulebois <cyril@debamax.com> - 2022-04-29 18:20 +0200
    Processed: Re: Bug#1010365: linux: failure to boot on Raspberry  Pi Compute Module 4 (black screen) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2022-04-29 19:40 +0200
    Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen) Cyril Brulebois <cyril@debamax.com> - 2022-04-29 19:40 +0200
      Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen) Cyril Brulebois <cyril@debamax.com> - 2022-04-30 07:20 +0200
    Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen) Bjørn Mork <bjorn@mork.no> - 2022-04-30 11:40 +0200
      Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen) Cyril Brulebois <cyril@debamax.com> - 2022-04-30 22:00 +0200
    Processed: Re: Bug#1010365: linux: failure to boot on Raspberry  Pi Compute Module 4 (black screen) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2022-04-30 22:00 +0200
    Bug#1010365: probably related - seeed studio dual gigabit CM4 does not reboot + does not boot once upgraded. Eugen Stan <eugen.stan@netdava.com> - 2022-05-15 12:50 +0200

#75173 — Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

Source: linux
Version: 5.17.3-1
Severity: important
X-Debbugs-Cc: raspi-firmware@packages.debian.org

Hi,

In the process of testing patches for the Raspberry Pi Compute Modules
(CM3 and CM4), for bullseye[1][2] and bookworm[2], I discovered that
bookworm images don't boot on the CM4.

 1. https://bugs.debian.org/1010317
 2. https://bugs.debian.org/996937

The usual start-up rainbow is displayed, the screen turns to black and
nothing happens. My first stop was trying to downgrade the bootloader
(shipped by the raspi-firmware package) to the bullseye's version, but
that didn't help.

Then I moved to starting from a bullseye image (which boots), upgrading
the raspi-firmware package, that still boots.

Then I deployed 5.16.18-1 (from snapshot.debian.org), that still boots.

Then I deployed 5.17.3-1, and it broke booting.

I'll try and pinpoint when it broke using the various intermediary
versions:

 - 5.17~rc3-1~exp1
 - 5.17~rc4-1~exp1
 - 5.17~rc5-1~exp1
 - 5.17~rc6-1~exp1
 - 5.17~rc7-1~exp1
 - 5.17~rc8-1~exp1
 - 5.17.1-1~exp1

and then try to figure out what broke exactly. Contrary to my earlier
efforts to introduce support for that hardware a few months ago, I
haven't been following upstream changes recently, so I'll need to catch
up.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

[toc] | [next] | [standalone]

#75174 — Processed: Re: Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

Processing control commands:

> found -1 5.17~rc3-1~exp1
Bug #1010365 [src:linux] linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)
Marked as found in versions linux/5.17~rc3-1~exp1.

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

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

#75175

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

Control: found -1 5.17~rc3-1~exp1

Cyril Brulebois <cyril@debamax.com> (2022-04-29):
> The usual start-up rainbow is displayed, the screen turns to black and
> nothing happens. My first stop was trying to downgrade the bootloader
> (shipped by the raspi-firmware package) to the bullseye's version, but
> that didn't help.
> 
> Then I moved to starting from a bullseye image (which boots), upgrading
> the raspi-firmware package, that still boots.
> 
> Then I deployed 5.16.18-1 (from snapshot.debian.org), that still boots.
> 
> Then I deployed 5.17.3-1, and it broke booting.
> 
> I'll try and pinpoint when it broke using the various intermediary
> versions:
> 
>  - 5.17~rc3-1~exp1

The first attempt was sufficient: it breaks as early as that version.

> and then try to figure out what broke exactly. Contrary to my earlier
> efforts to introduce support for that hardware a few months ago, I
> haven't been following upstream changes recently, so I'll need to catch
> up.

Checking the upstream diff, nothing obvious on the DTB side. Trying to
use 5.16.18-1's DTB with 5.17~rc3-1~exp1 kernel didn't help anyway.

I've also tried latest mainline: v5.18-rc4-192-g38d741cb70b3

built with:

    cp ~/config-5.17.0-1-arm64 .config
    time PATH=/usr/lib/ccache:$PATH make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- oldconfig       # accept everything
    time PATH=/usr/lib/ccache:$PATH make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg -j32

and the symptoms are the same: black screen at start-up.

I've also checked the serial console (which is confirmed to work if I
boot 5.16.18-1), and I'm not getting anything there either, with either
5.17~rc3-1~exp1 or my local v5.18-rc4-192-g38d741cb70b3 build.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

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

#75181

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

Cyril Brulebois <cyril@debamax.com> (2022-04-29):
> > I'll try and pinpoint when it broke using the various intermediary
> > versions:
> > 
> >  - 5.17~rc3-1~exp1
> 
> The first attempt was sufficient: it breaks as early as that version.

Using the same base image as before, and only updating the kernel: I've
tested upstream builds, starting from the .config found in the Debian
5.16.18-1 package, using oldconfig and accepting everything by default:

 - v5.16 is confirmed a first good;
 - v5.17-rc1 is confirmed a first bad;
 - the culprit seems to be 3ceff4ea07410763d5d4cccd60349bf7691e7e61


Here's the git bisect log:

    git bisect start
    # good: [df0cc57e057f18e44dac8e6c18aba47ab53202f9] Linux 5.16
    git bisect good df0cc57e057f18e44dac8e6c18aba47ab53202f9
    # bad: [e783362eb54cd99b2cac8b3a9aeac942e6f6ac07] Linux 5.17-rc1
    git bisect bad e783362eb54cd99b2cac8b3a9aeac942e6f6ac07
    # good: [fef8dfaea9d6c444b6c2174b3a2b0fca4d226c5e] Merge tag 'regulator-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
    git bisect good fef8dfaea9d6c444b6c2174b3a2b0fca4d226c5e
    # bad: [3ceff4ea07410763d5d4cccd60349bf7691e7e61] Merge tag 'sound-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
    git bisect bad 3ceff4ea07410763d5d4cccd60349bf7691e7e61
    # good: [57ea81971b7296b42fc77424af44c5915d3d4ae2] Merge tag 'usb-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
    git bisect good 57ea81971b7296b42fc77424af44c5915d3d4ae2
    # good: [feb7a43de5ef625ad74097d8fd3481d5dbc06a59] Merge tag 'irq-msi-2022-01-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
    git bisect good feb7a43de5ef625ad74097d8fd3481d5dbc06a59
    # good: [10674ca9ea02491fd3f8ffe303861b7a6837994b] ASoC/SoundWire: improve suspend flows and use set_stream() instead of set_tdm_slots() for HDAudio
    git bisect good 10674ca9ea02491fd3f8ffe303861b7a6837994b
    # good: [c77b1f8a8faeeba43c694d9d09d0b25a4f52cf37] scsi: mpi3mr: Bump driver version to 8.0.0.61.0
    git bisect good c77b1f8a8faeeba43c694d9d09d0b25a4f52cf37
    # good: [f66229aa355f7e0dc0dc20cbc1f4d45c3176eed2] Merge tag 'asoc-v5.17-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
    git bisect good f66229aa355f7e0dc0dc20cbc1f4d45c3176eed2
    # good: [59aa7fcfe2e44afbe9736e5cfa941699021d6957] IB/mthca: Use memset_startat() for clearing mpt_entry
    git bisect good 59aa7fcfe2e44afbe9736e5cfa941699021d6957
    # good: [18451db82ef7f943c60a7fce685f16172bda5106] RDMA/core: Calculate UDP source port based on flow label or lqpn/rqpn
    git bisect good 18451db82ef7f943c60a7fce685f16172bda5106
    # good: [1f43e5230aebb17aea35238dc26e297a61095ac0] mailbox: qcom-ipcc: Support more IPCC instance
    git bisect good 1f43e5230aebb17aea35238dc26e297a61095ac0
    # good: [747c19eb7539b5e6bb15ed57a0a14ebf9f3adb8e] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
    git bisect good 747c19eb7539b5e6bb15ed57a0a14ebf9f3adb8e
    # good: [e1a7aa25ff45636a6c1930bf2430c8b802e93d9c] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
    git bisect good e1a7aa25ff45636a6c1930bf2430c8b802e93d9c
    # good: [19980aa10d2d944ed8fe345ce2eb87c2cb4bedf8] ALSA: hda: intel-dsp-config: add JasperLake support
    git bisect good 19980aa10d2d944ed8fe345ce2eb87c2cb4bedf8
    # good: [081c73701ef0c2a4f6a127da824a641ae6505fbe] ALSA: hda: intel-dsp-config: reorder the config table
    git bisect good 081c73701ef0c2a4f6a127da824a641ae6505fbe
    # first bad commit: [3ceff4ea07410763d5d4cccd60349bf7691e7e61] Merge tag 'sound-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound


I'll try and find out more in a couple of hours, and get in touch with
upstream.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

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

#75183

Cyril Brulebois <cyril@debamax.com> writes:

> Cyril Brulebois <cyril@debamax.com> (2022-04-29):
>> > I'll try and pinpoint when it broke using the various intermediary
>> > versions:
>> > 
>> >  - 5.17~rc3-1~exp1
>> 
>> The first attempt was sufficient: it breaks as early as that version.
>
> Using the same base image as before, and only updating the kernel: I've
> tested upstream builds, starting from the .config found in the Debian
> 5.16.18-1 package, using oldconfig and accepting everything by default:
>
>  - v5.16 is confirmed a first good;
>  - v5.17-rc1 is confirmed a first bad;
>  - the culprit seems to be 3ceff4ea07410763d5d4cccd60349bf7691e7e61

But that's a merge commit. Not likely the real cuplrit, unless there's a
merge bug.

I looked briefly at what was merged there, and I believe this commit
stands out as suspicious:

bjorn@miraculix:/usr/local/src/git/linux$ git show f59f6aaead97
commit f59f6aaead975f0ec4d8ff2d59c4ffb8cf0127b2
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Nov 22 23:21:56 2021 +0100

    mmc: bcm2835: stop setting chan_config->slave_id
    
    The field is not interpreted by the DMA engine driver, as all the data
    is passed from devicetree instead. Remove the assignment so the field
    can eventually be deleted.
    
    Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Acked-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20211122222203.4103644-5-arnd@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>

diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
index 8c2361e66277..463b707d9e99 100644
--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -1293,14 +1293,12 @@ static int bcm2835_add_host(struct bcm2835_host *host)
 
                host->dma_cfg_tx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
                host->dma_cfg_tx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-               host->dma_cfg_tx.slave_id = 13;         /* DREQ channel */
                host->dma_cfg_tx.direction = DMA_MEM_TO_DEV;
                host->dma_cfg_tx.src_addr = 0;
                host->dma_cfg_tx.dst_addr = host->phys_addr + SDDATA;
 
                host->dma_cfg_rx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
                host->dma_cfg_rx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-               host->dma_cfg_rx.slave_id = 13;         /* DREQ channel */
                host->dma_cfg_rx.direction = DMA_DEV_TO_MEM;
                host->dma_cfg_rx.src_addr = host->phys_addr + SDDATA;
                host->dma_cfg_rx.dst_addr = 0;


But I'm basing that only on it being related to the bcm28/27xx SoCs and
a bit unexpected in the sound merge...  I cannot explain why this mmc
host driver change should affect your display.  Could be completely
wrong.  But migt be worth testing?



Bjørn

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

#75186

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

Control: tag -1 upstream
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=215925

Hi Bjørn,

Bjørn Mork <bjorn@mork.no> (2022-04-30):
> But that's a merge commit. Not likely the real cuplrit, unless there's
> a merge bug.
> 
> I looked briefly at what was merged there, and I believe this commit
> stands out as suspicious:
> 
> bjorn@miraculix:/usr/local/src/git/linux$ git show f59f6aaead97
> commit f59f6aaead975f0ec4d8ff2d59c4ffb8cf0127b2
> Author: Arnd Bergmann <arnd@arndb.de>
> Date:   Mon Nov 22 23:21:56 2021 +0100
> 
>     mmc: bcm2835: stop setting chan_config->slave_id

Yeah, I skipped a bunch of details in my last mail since I've tried
various things (including reverting that one I spotted, plus the few
commits around it since it was part of removing that field altogether)
but didn't get any consistent results.

My methodology was probably fragile since I worked incrementally, and I
suppose I got some wires crossed at some point. Sorry for the confusion.


I've redone this entirely, and here are better (and reproducible, this
time) findings:

 - 830aa6f29f07a4e2f1a947dfa72b3ccddb46dd21 breaks the boot, leading to
   a kernel panic very early in the boot process; I'm seeing the trace
   on the screen, not on the serial console. It involves the modified
   brcm_pcie_driver_init() function, so that's quite consistent.

 - 87c71931633bd15e9cfd51d4a4d9cd685e8cdb55 is the last commit
   exhibiting the kernel panic (further in that branch, before it gets
   merged into mainline).

 - 88db8458086b1dcf20b56682504bdb34d2bca0e2 is the last commit that lets
   the CM4 boots properly.

 - d0a231f01e5b25bacd23e6edc7c979a18a517b2b, which is the merge of the
   last two aforementioned commits, is the first one that results in
   a completely black screen (no kernel panic displayed), and still
   nothing on the serial console. It seems to me that the kernel panic
   escalates into a more serious issue after this merge. I note there
   are conflict resolutions about drivers/pci/controller/pcie-brcmstb.c
   in that commit.


No luck with latest master. I've filed this upstream (see link above).


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

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

#75185 — Processed: Re: Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

Processing control commands:

> tag -1 upstream
Bug #1010365 [src:linux] linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)
Added tag(s) upstream.
> forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=215925
Bug #1010365 [src:linux] linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)
Set Bug forwarded-to-address to 'https://bugzilla.kernel.org/show_bug.cgi?id=215925'.

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

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

#75237 — Bug#1010365: probably related - seeed studio dual gigabit CM4 does not reboot + does not boot once upgraded.

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

Hello,

I have a seeed studio CM4 dual gigabit board that I have installed Raspi 
Debian on it 
https://raspi.debian.net/tested/20220121_raspi_4_bookworm.img.xz .


System works fine but does not reboot.
If I reboot it hangs instead and I push the small reset button to 
restart it (or unplug + plug).

I configured wireless AP and ran apt update + apt upgrade on the system.
It upgraded kernel and raspberry-firmware and then it did not boot again.

I had to start in boot mode again and reflash the debian image on the 
system to make it work.

Working system runs linux 5.15.0-2-arm64 - 5.15.5.-2 .
Raspi firmware is 1.20210805+ds-1


For some background, I flashed OpenWrt 22.xx-rc1 before Debian and 
reboot worked. 
https://github.com/sergey-brutsky/openwrt-seeed-carrier-board/issues/1 .

-- 
Eugen Stan

+40770 941 271  / https://www.netdava.com

[toc] | [prev] | [standalone]

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

csiph-web