Problem with .hdr file versions about tn40xx-driver

[lego12239]

Hi. I've got x3310fw_0_3_4_0_9445.hdr :-)

x3310fw_0_3_4_0_9445.hdr.gz

[pheff]

Seems replying by email and attaching file does not post the file here so posting it again.

x3310fw_0_3_3_0_9374.tar.gz

[lego12239]

Please, add this file into git.

[hfvogt]

by the way, the driver package driver(linux)_teg-10gectx_v1(0.3.6.17).tar.gz offered by Trendnet for the discontinued TEG-10GECTX (Version v1.0R), see under
https://www.trendnet.com/support/support-detail.asp?prod=310_TEG-10GECTX
includes the 0.3.4.0 firmware for the 88x3310 phy. There is no mentioning in the driver package though, about copyrights.

That is certainly not a long-term solution. However, the firmwares for the 88x3310 and 88e2010 PHYs are always distributed within the windows driver binaries TN40xxmp_64.sys and TN40xxmp_32.sys. I have written a small extraction program, still a bit quick and dirty, but I am happy to share it if there is interest...

[adamisvk]

Hello, I have managed to get firmware version 0.3.10.0 from another HW.

x3310fw_0_3_10_0_10860.hdr.gz

[acooks]

@pheff, could you help obtain a distributable copy of x3310fw_0_3_4_0_9445?

[sheepman0]

@ziswiler here you go:

https://mega.nz/file/Zh0GnQIS#eBB0L16lvBAS6nvvY7sZxkVtjwGsraNJJ0pMwCHEiK4

[sheepman0]

What does lspci -nn | grep -i network return? Is it definitely the right PCI ID for the driver?

I also noticed this though but have been unable to obtain the x3310fw_0_3_3_0_9374.hdr file from anywhere... Marvell won't talk to me, and seemingly TrendNet (my card vendor) aren't able to help either bizarrely. If anyone can get their hands on x3310fw_0_3_3_0_9374.hdr it'd be much appreciated if they might share it.

[sheepman0]

Quick update.. I noticed with my card (that has a DeviceID of 4027) the driver wasn't building with support for it. It also errors if you try make MV88X3310=YES.

If your card has the same device ID try copying the attached file into your build directory and running it again. It is still that old x3310fw_0_2_8_0_8850.hdr version but it might get your card working at least.
MV88X3310_phy.h.zip

[MarkRivers]

Here is the output of lspci with grep for ethernet

[epics@camaroc7 ~]$ lspci -nn | grep -i ethernet
06:00.0 Ethernet controller [0200]: Broadcom Limited NetXtreme BCM5761 Gigabit Ethernet PCIe [14e4:1681] (rev 10)
23:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10G X550T [8086:15d1] (rev 01)
24:00.0 Ethernet controller [0200]: Tehuti Networks Ltd. TN9710P 10GBase-T/NBASE-T Ethernet Adapter [1fc9:4027]

It shows 3 network cards, which is correct. The Broadcom is a 1GB interface on the motherboard, the Intel card is a 10GB PCIe card. Both of these are working fine. It sees the Tehuti card.
Is that the correct PCI ID for the driver?

The problem is that ifconfig does not show the card.

[epics@camaroc7 ~]$ ifconfig
enp35s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 192.168.1.1  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::5b36:b15a:96ed:4afd  prefixlen 64  scopeid 0x20<link>
        ether 00:0a:cd:31:31:c8  txqueuelen 1000  (Ethernet)
        RX packets 5  bytes 300 (300.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15  bytes 2224 (2.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 164.54.160.15  netmask 255.255.255.0  broadcast 164.54.160.255
        inet6 fe80::9f4b:e9d0:8e9b:1384  prefixlen 64  scopeid 0x20<link>
        ether bc:30:5b:c9:ab:30  txqueuelen 1000  (Ethernet)
        RX packets 9364  bytes 934115 (912.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1179  bytes 275505 (269.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 132  bytes 16884 (16.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 132  bytes 16884 (16.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:24:18:b4  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enps60 is the Broadcom NIC and enp35s0 is the Intel NIC. The Tehuti NIC is not there.

This is what I did to build and install the driver:

[root@camaroc7 tn40xx-0.3.6.16.1]# make clean
make -C /lib/modules/3.10.0-862.6.3.el7.x86_64/build M=/usr/local/tn40xx-0.3.6.16.1 clean
make[1]: Entering directory `/usr/src/kernels/3.10.0-862.6.3.el7.x86_64'
  CLEAN   /usr/local/tn40xx-0.3.6.16.1/.tmp_versions
  CLEAN   /usr/local/tn40xx-0.3.6.16.1/Module.symvers
make[1]: Leaving directory `/usr/src/kernels/3.10.0-862.6.3.el7.x86_64'
[root@camaroc7 tn40xx-0.3.6.16.1]# make        
make -C /lib/modules/3.10.0-862.6.3.el7.x86_64/build M=/usr/local/tn40xx-0.3.6.16.1 clean
make[1]: Entering directory `/usr/src/kernels/3.10.0-862.6.3.el7.x86_64'
make[1]: Leaving directory `/usr/src/kernels/3.10.0-862.6.3.el7.x86_64'
Building kernel 3.10.0-862.6.3.el7.x86_64 resume supported
make -C /lib/modules/3.10.0-862.6.3.el7.x86_64/build M=/usr/local/tn40xx-0.3.6.16.1 modules 
make[1]: Entering directory `/usr/src/kernels/3.10.0-862.6.3.el7.x86_64'
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/tn40.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/CX4.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/CX4_Linux.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/QT2025_phy.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/QT2025_phy_Linux.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/TLK10232_phy.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/TLK10232_phy_Linux.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/AQR105_phy.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/AQR105_phy_Linux.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/MV88X3120_phy.o
  CC [M]  /usr/local/tn40xx-0.3.6.16.1/MV88X3120_phy_Linux.o
  LD [M]  /usr/local/tn40xx-0.3.6.16.1/tn40xx.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/local/tn40xx-0.3.6.16.1/tn40xx.mod.o
  LD [M]  /usr/local/tn40xx-0.3.6.16.1/tn40xx.ko
make[1]: Leaving directory `/usr/src/kernels/3.10.0-862.6.3.el7.x86_64'
[root@camaroc7 tn40xx-0.3.6.16.1]# make install
install -d /lib/modules/3.10.0-862.6.3.el7.x86_64/kernel/drivers/net
install -m 644 tn40xx.ko /lib/modules/3.10.0-862.6.3.el7.x86_64/kernel/drivers/net
depmod 3.10.0-862.6.3.el7.x86_64

Am I missing a step?

I just saw that you sent a .zip file. I wrote the above before I saw that. I have now rebuilt the driver with that file, and am rebooting to see if it fixes it.

Success! Thanks so much. ifconfig now sees the card as enp36s0.

[epics@camaroc7 ~]$ ifconfig
enp35s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 192.168.1.1  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::5b36:b15a:96ed:4afd  prefixlen 64  scopeid 0x20<link>
        ether 00:0a:cd:31:31:c8  txqueuelen 1000  (Ethernet)
        RX packets 5  bytes 300 (300.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 2250 (2.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp36s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:02:7a:39:01:24  txqueuelen 3000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 42  memory 0xdfb00000-dfb10000  

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 164.54.160.15  netmask 255.255.255.0  broadcast 164.54.160.255
        inet6 fe80::9f4b:e9d0:8e9b:1384  prefixlen 64  scopeid 0x20<link>
        ether bc:30:5b:c9:ab:30  txqueuelen 1000  (Ethernet)
        RX packets 2745  bytes 342174 (334.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1157  bytes 266050 (259.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 132  bytes 16884 (16.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 132  bytes 16884 (16.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:24:18:b4  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[sheepman0]

Glad it fixed it. I would still like to get my hands on the x3310fw_0_3_3_0_9374.hdr file though if anyone has it!

[pheff]

Please find attached FW hdr file and release notes. Please submit it to this github project.

…

On Fri, Jul 20, 2018 at 5:39 AM, sheepman0 ***@***.***> wrote: Glad it fixed it. I would still like to get my hands on the x3310fw_0_3_3_0_9374.hdr file though if anyone has it! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcyRGYj1lo3OCuEC3cNFVpWh8bXYJeF_ks5uIc9vgaJpZM4VXPjO> .

[russcook]

pheff, you are my hero today! You totally saved my bacon.

[pheff]

Hi Andrew, Yes, please give me a few days to find out what is required. pat

…

On Sat, Nov 24, 2018 at 5:17 PM Andrew Cooks ***@***.***> wrote: @pheff <https://github.com/pheff>, could you help obtain a distributable copy of x3310fw_0_3_4_0_9445? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcyRGRYL3xZl_KobE4m8OtJO2ngJpxlgks5uye-qgaJpZM4VXPjO> .

[MurrayData]

Thanks very much guys, solved it for me too.

[lego12239]

The same problem - can't find x3310fw_0_3_4_0_9445.hdr .

[lego12239]

@acooks, why don't you want to include x3310fw_0_3_3_0_9374.hdr in release branch?

[jp-bennett]

I would assume the 0.2.8.0 version of the firmware is what was last released under a GPL license. Marvell appears to be requiring an NDA for the changelog at the very least. It's very likely that this project does not have the legal right to distribute newer firmware versions. This is a frustrating but common problem.

[acooks]

@baruchsiach submitted a patch to mainline kernel to add firmware loading for the 88x3310 phy.

The discussion explains the problem:

• the 88x3310 PHY doesn't work without firmware.
• the PHY loads FW from either SPI flash automatically, or must be loaded over MDIO bus by the driver.
• the TN9170P NIC implementation doesn't have a SPI flash to store the PHY firmware, saving a couple of dollars.
• Marvell, who makes the 88x3310 PHY, won't allow redistribution of the firmware files**
• even if the tn40xx driver is converted to use phylib support in mainline kernel, the 88x3310 firmware distribution problem remains.
• this makes the TN9170P and similar NICs with 88x3310 PHY and lacking SPI flash legally unsupportable in an Open Source driver.

** There is a loophole. Any NIC implementation that uses the SPI flash is also distributing the firmware, albeit in a slightly inconvenient package. I suspect that the firmware can easily be read out of the SPI flash of any NIC that contains it, so anyone who ships the flash ROM, also ships the firmware. However, none of this is going to help to convince the mainline kernel to include this firmware.

Patch submission with discussion

Later version of the patch, presumably with review comments addressed

[baruchsiach]

* this makes the TN9170P and similar NICs with 88x3310 PHY and lacking SPI flash legally unsupportable in an Open Source driver.

IANAL. But I would just like to note that this statement is not accurate in my opinion. It is perfectly legal to apply the firmware load support patch to Open Source driver, and then distribute the result. The patch code is not derived from any non-GPL code.

I presume it is also legal for OEM vendors to distribute the PHY firmware files stored on devices for software to load at run-time. Otherwise, the hardware is not usable.

[gitontheball]

Hi. I see this is the only page on the entire internet that refers to this issue, so I need to ask anyone: I am in urgent and significant need of the other file referred to here, which is the e2010fw_0_3_4_0_9445.hdr file (the firmware for the 88e2010 PHY). Please, if someone could please post that file here, it would be immeasurably appreciated. Please let me know and thanks so much for any and all help locating this.

by the way, the driver package driver(linux)_teg-10gectx_v1(0.3.6.17).tar.gz offered by Trendnet for the discontinued TEG-10GECTX (Version v1.0R), see under
https://www.trendnet.com/support/support-detail.asp?prod=310_TEG-10GECTX
includes the 0.3.4.0 firmware for the 88x3310 phy. There is no mentioning in the driver package though, about copyrights.

That is certainly not a long-term solution. However, the firmwares for the 88x3310 and 88e2010 PHYs are always distributed within the windows driver binaries TN40xxmp_64.sys and TN40xxmp_32.sys. I have written a small extraction program, still a bit quick and dirty, but I am happy to share it if there is interest...

[hfvogt]

Hi gitontheball,

if you download the trendnet windows driver where the link was given above and extract the cab file data2.cab under "Installation Files" e.g. with cabextract, then you will find under "DefaultComponent" the windows driver files *.sys. Compile my little extraction program attached
read-marvell-fw.c.gz
and call it with the *.sys file as a parameter. Then you get all firmware files in your current directory as file.hdr.new.
Happy extracting :-)

[ziswiler]

Hello, I have managed to get firmware version 0.3.10.0 from another HW.

x3310fw_0_3_10_0_10860.hdr.gz

Looks like that one is no longer available for download. @adamisvk could you please share it again?

[acooks]

@baruchsiach submitted a patch to mainline kernel to add firmware loading for the 88x3310 phy.

The discussion explains the problem:

* the 88x3310 PHY doesn't work without firmware.

* the PHY loads FW from either SPI flash automatically, or must be loaded over MDIO bus by the driver.

* the TN9170P NIC implementation doesn't have a SPI flash to store the PHY firmware, saving a couple of dollars.

* Marvell, who makes the 88x3310 PHY, won't allow redistribution of the firmware files**

* even if the tn40xx driver is converted to use phylib support in mainline kernel, the 88x3310 firmware distribution problem remains.

* this makes the TN9170P and similar NICs with 88x3310 PHY and lacking SPI flash legally unsupportable in an Open Source driver.

** There is a loophole. Any NIC implementation that uses the SPI flash is also distributing the firmware, albeit in a slightly inconvenient package. I suspect that the firmware can easily be read out of the SPI flash of any NIC that contains it, so anyone who ships the flash ROM, also ships the firmware. However, none of this is going to help to convince the mainline kernel to include this firmware.

Patch submission with discussion

Later version of the patch, presumably with review comments addressed

@wkz has posted another patch set to add support for loading 88x3310 PHY firmware to the mainline kernel:

https://lore.kernel.org/netdev/[email protected]/

In the discussion, the same concerns were raised about where to get the firmware and how to distribute it. Unfortunately little or no progress has been made on that front.