netdev - Re: GENET and UNIMAC MDIO probe issue?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20211026040336.eiojc64jf7a3a3ov@debamax.com>
Date:   Tue, 26 Oct 2021 06:03:36 +0200
From:   Cyril Brulebois <cyril@...amax.com>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     Stefan Wahren <stefan.wahren@...e.com>,
        Doug Berger <opendmb@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, bcm-kernel-feedback-list@...adcom.com,
        Nicolas Saenz Julienne <nsaenz@...nel.org>
Subject: Re: GENET and UNIMAC MDIO probe issue?

Hi,

Maxime Ripard <maxime@...no.tech> (2021-10-22):
> > looks like you are using the vendor DTB, please use the upstream DTB
> > from linux-next:
> > 
> > bcm2711-rpi-cm4-io.dtb
> 
> I thought upstream_kernel would be enough, but following your message
> I forced it using device_tree, and indeed it works.
> 
> But I'm confused now, I don't have any other DTB for the CM4 on that
> boot partition, where is that other device tree coming from?

It seems to be using the DTB for the Pi 4 B instead, at least judging
by:

    # tr '\0' '\n' < /proc/device-tree/compatible
    raspberrypi,4-model-b
    brcm,bcm2711

For the avoidance of doubt, the relevant /boot/firmware has those files,
copied from the linux-image package without any name changes:

    /boot/firmware/bcm2711-rpi-4-b.dtb
    /boot/firmware/bcm2711-rpi-400.dtb
    /boot/firmware/bcm2711-rpi-cm4-io.dtb
    /boot/firmware/bcm2837-rpi-3-a-plus.dtb
    /boot/firmware/bcm2837-rpi-3-b-plus.dtb
    /boot/firmware/bcm2837-rpi-3-b.dtb
    /boot/firmware/bcm2837-rpi-cm3-io3.dtb

so maybe some fallback to the Pi 4 B happened via the more generic
brcm,bcm2711 compatible fragment?


Initially I was wondering whether there might be some things on the
EEPROM side that might need an update, but wading through some issues
in the raspberrypi/rpi-eeprom repository[1], it seems start.elf is
responsible for passing the dtb file and a quick look into it suggests
there might be a single format string for that: bcm%d-rpi-%s.dtb

 1. https://github.com/raspberrypi/rpi-eeprom

I'm also seeing filename fragments, but nothing that ressembles the io
suffix that's being used for the CM4 upstream DTB.


Since it seems that the bootloader might be expecting “vendor DTB” and
the kernel might use different names when it comes to “upstream DTB”,
are users/distributions expected to set the proper filename via
device_tree= all the time? If that's the case, I hadn't noticed until
now since we used to have things like this in Debian to put files into
place under the “expected filenames”:

    cp <packaged>/bcm2837-rpi-cm3-io3.dtb /boot/firmware/bcm2710-rpi-cm3.dtb

Nowadays, our raspi-firmware package is just copying the DTB files (as
shipped by linux-image packages, meaning “upstream DTB” names without
any renaming), so we might have failed to notice a possible need for
this device_tree parameter…


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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)