Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Mon, Nov 03, 2014 at 12:26:33AM +0000, Ben Hutchings wrote:
> On Sun, 2014-11-02 at 21:43 +0100, Karsten Merker wrote:
> [...]
> > Following is the log from a d-i run where /sbin/modprobe and
> > /sbin/insmod have been replaced by a script that logs all
> > invocations of these two binaries with a "modules-debug" prefix
> > before executing the original binary:
> [...]
> > The entry at 00:03:37 does not show a modprobe invocation before
> > the initialization of the stmmac module, so the module does not
> > seem to be loaded by calling modprobe, which would explain why no
> > autoloading of the PHY driver happens there. What I do not
> > understand is that I also see no insmod invocation, and logging
> > insmod invocations works when I run insmod from a shell. So the
> > question remains: how is the stmmac module loaded at that point?
> > I first thought that something might invoke kmod directly (i.e.
> > not by calling the insmod/modprobe aliases), but logging direct
> > kmod invocations also shows nothing, so I am probably overlooking
> > something.
> >
> > Any ideas?
>
> So far as I can see, ethdetect runs hw-detect, which runs update-dev,
> which runs 'udevadm trigger --action=add --subsystem-nomatch=sound' and
> that should result in udev loading stmmac. (udev won't have done that
> when it started because the stmmac module wasn't included in the
> initramfs.)
>
> udev is now linked with libkmod, so it can load modules without running
> modprobe, and most driver modules get loaded that way. But as I said
> before, this isn't the case for the PHY driver modules.
>
> So, I think this shows the kernel is not running modprobe for some
> reason.
Things are getting even stranger:
I have run further installation tests with today's current d-i images
(still based on the same 3.16.5-1 kernel)
- http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
dated 04-Nov-2014 05:16 and
- http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo
dated 2014-11-03 12:14)
on a Cubietruck and on the BananaPi. On the Cubietruck everything
works while on the BananaPi the PHY is not found. Both are
booted from the same USB stick, so there cannot be any
differences in the installer image. The hardware on both is
rather similar (Allwinner A20 SoC with integrated MAC, external
Realtek PHY) and they show the same PHY ID once the probing was
successful, so I assume that they use identical PHY chips:
Cubietruck:
-----------
Jan 1 00:06:47 main-menu[179]: INFO: Menu item 'ethdetect' selected
Jan 1 00:06:48 kernel: [ 78.983839] cfg80211: Calling CRDA to update world regulatory domain
Jan 1 00:06:49 kernel: [ 78.998759] brcmfmac_sdio mmc1:0001:1: firmware: failed to load brcm/brcmfmac43362-sdio.bin (-2)
Jan 1 00:06:49 kernel: [ 79.057067] stmmaceth 1c50000.ethernet: no regulator found
Jan 1 00:06:49 kernel: [ 79.057202] stmmaceth 1c50000.ethernet: no reset control found
Jan 1 00:06:49 kernel: [ 79.057218] Ring mode enabled
Jan 1 00:06:49 kernel: [ 79.057226] No HW DMA feature register supported
Jan 1 00:06:49 kernel: [ 79.057233] Normal descriptors
Jan 1 00:06:49 kernel: [ 79.057241] TX Checksum insertion supported
Jan 1 00:06:49 kernel: [ 79.171058] libphy: stmmac: probed
Jan 1 00:06:49 kernel: [ 79.171089] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
Jan 1 00:06:49 kernel: [ 79.171100] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
BananaPi:
---------
No Ethernet card was detected. If you know the name of the driver
needed by your Ethernet card, you can select it from the list.
--> shell
~ # lsmod |grep realtek
~ # dmesg | tail -8
[ 32.138512] ISO 9660 Extensions: RRIP_1991A
[ 77.235117] stmmaceth 1c50000.ethernet: no reset control found
[ 77.235192] Ring mode enabled
[ 77.235202] No HW DMA feature register supported
[ 77.235211] Normal descriptors
[ 77.235219] TX Checksum insertion supported
[ 77.242678] libphy: stmmac: probed
[ 77.242708] eth0: No PHY found
~ # rmmod stmmac
~ # modprobe stmmac
~ # lsmod |grep realtek
realtek 1563 0
~ # dmesg | tail -8
[ 148.823456] stmmaceth 1c50000.ethernet: no reset control found
[ 148.823487] Ring mode enabled
[ 148.823496] No HW DMA feature register supported
[ 148.823502] Normal descriptors
[ 148.823509] TX Checksum insertion supported
[ 148.854654] libphy: stmmac: probed
[ 148.854683] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[ 148.854694] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
~ #
The main visible difference between the two systems is that the
Cubietruck also has a Broadcom 43362 SDIO Wifi module and d-i
asks for the non-free firmware for it before the stmmac gets
initialized, but I do not see how that should make a difference
regarding the realtek PHY driver.
What makes me wonder is the line
stmmaceth 1c50000.ethernet: no regulator found
on the Cubietruck that does not appear on the BananaPi. Could
there perhaps be some regulator/voltage supply issue with the PHY
so that the PHY is not fully powered up upon the first probing but
later on? The dts shows different setups for the PHY power
supply between the two systems:
BananaPi:
---------
gmac: ethernet@01c50000 {
pinctrl-names = "default";
pinctrl-0 = <&gmac_pins_rgmii_a>;
phy = <&phy1>;
phy-mode = "rgmii";
phy-supply = <®_gmac_3v3>;
status = "okay";
phy1: ethernet-phy@1 {
reg = <1>;
};
}
reg_gmac_3v3: gmac-3v3 {
compatible = "regulator-fixed";
pinctrl-names = "default";
pinctrl-0 = <&gmac_power_pin_bananapi>;
regulator-name = "gmac-3v3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
startup-delay-us = <50000>;
enable-active-high;
gpio = <&pio 7 23 0>;
};
Cubietruck:
-----------
gmac: ethernet@01c50000 {
pinctrl-names = "default";
pinctrl-0 = <&gmac_pins_rgmii_a>;
phy = <&phy1>;
phy-mode = "rgmii";
status = "okay";
phy1: ethernet-phy@1 {
reg = <1>;
};
};
i.e. the PHY appears to have a seperate regulator on the
BananaPi but not on the Cubietruck and I wonder whether the
startup-delay-us = <50000>;
might play a role here.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: