Problem with .hdr file versions #3

MarkRivers · 2018-07-19T23:34:44Z

The currrent version of the Readme file says this:

For TN9710P (DeviceID 4027) please obtain the file x3310fw_0_3_3_0_9374.hdr
For TN9710Q (DeviceID 4527) please obtain the file e2010fw_0_3_3_0_9374.hdr
If you are missing these exact files, the driver will compile without support for these PHYs

However the actual versions of these files in the repository are:
x3310fw_0_2_8_0_8850.hdr
e2010fw_0_2_8_0_8850.hdr

So they are not the latest versions referred to in the Readme. When I build the driver on Centos 7 it does not find my TN9710P based card. Is it likely this is because it is using the wrong .hdr files?

The text was updated successfully, but these errors were encountered:

sheepman0 · 2018-07-20T11:31:05Z

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 · 2018-07-20T11:53:49Z

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 · 2018-07-20T12:15:41Z

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 · 2018-07-20T12:39:10Z

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 · 2018-07-20T17:10:37Z

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> .

pheff · 2018-07-20T17:17:40Z

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

russcook · 2018-09-14T13:29:14Z

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

acooks · 2018-11-25T01:17:30Z

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

pheff · 2018-11-26T05:11:24Z

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 · 2018-11-28T18:46:27Z

Thanks very much guys, solved it for me too.

lego12239 · 2019-01-23T11:37:32Z

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

lego12239 · 2019-01-23T11:52:40Z

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

lego12239 · 2019-03-19T09:16:58Z

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

x3310fw_0_3_4_0_9445.hdr.gz

lego12239 · 2019-03-19T09:17:11Z

Please, add this file into git.

jp-bennett · 2019-10-16T05:42:52Z

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 · 2020-09-12T12:37:13Z

@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 · 2020-09-13T14:09:29Z

* 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.

hfvogt · 2020-10-09T14:59:26Z

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 · 2021-04-13T09:35:53Z

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

x3310fw_0_3_10_0_10860.hdr.gz

gitontheball · 2021-04-23T07:11:51Z

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 · 2021-06-27T17:23:29Z

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 · 2022-03-09T23:12:12Z

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?

sheepman0 · 2022-03-10T09:24:09Z

@ziswiler here you go:

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

acooks · 2023-12-27T10:03:26Z

@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/20231214201442.660447-1-tobias@waldekranz.com/

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.

acooks pinned this issue Dec 17, 2023

acooks added PHY_MV88X3310 PHY_MV88E2010 labels Dec 17, 2023

acooks mentioned this issue Jan 9, 2024

Driver not loading for StarTech (ST10GSPEXNB) - Ubuntu Server 18.04.5 LTS; kernel 5.4.0-66-generic #40

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Problem with .hdr file versions #3

Problem with .hdr file versions #3

MarkRivers commented Jul 19, 2018

sheepman0 commented Jul 20, 2018 •

edited

sheepman0 commented Jul 20, 2018

MarkRivers commented Jul 20, 2018

sheepman0 commented Jul 20, 2018

pheff commented Jul 20, 2018 via email

pheff commented Jul 20, 2018

russcook commented Sep 14, 2018

acooks commented Nov 25, 2018

pheff commented Nov 26, 2018 via email

MurrayData commented Nov 28, 2018

lego12239 commented Jan 23, 2019

lego12239 commented Jan 23, 2019

lego12239 commented Mar 19, 2019

lego12239 commented Mar 19, 2019

jp-bennett commented Oct 16, 2019

acooks commented Sep 12, 2020

baruchsiach commented Sep 13, 2020

hfvogt commented Oct 9, 2020

adamisvk commented Apr 13, 2021

gitontheball commented Apr 23, 2021

hfvogt commented Jun 27, 2021

ziswiler commented Mar 9, 2022

sheepman0 commented Mar 10, 2022

acooks commented Dec 27, 2023

Problem with .hdr file versions #3

Problem with .hdr file versions #3

Comments

MarkRivers commented Jul 19, 2018

sheepman0 commented Jul 20, 2018 • edited

sheepman0 commented Jul 20, 2018

MarkRivers commented Jul 20, 2018

sheepman0 commented Jul 20, 2018

pheff commented Jul 20, 2018 via email

pheff commented Jul 20, 2018

russcook commented Sep 14, 2018

acooks commented Nov 25, 2018

pheff commented Nov 26, 2018 via email

MurrayData commented Nov 28, 2018

lego12239 commented Jan 23, 2019

lego12239 commented Jan 23, 2019

lego12239 commented Mar 19, 2019

lego12239 commented Mar 19, 2019

jp-bennett commented Oct 16, 2019

acooks commented Sep 12, 2020

baruchsiach commented Sep 13, 2020

hfvogt commented Oct 9, 2020

adamisvk commented Apr 13, 2021

gitontheball commented Apr 23, 2021

hfvogt commented Jun 27, 2021

ziswiler commented Mar 9, 2022

sheepman0 commented Mar 10, 2022

acooks commented Dec 27, 2023

sheepman0 commented Jul 20, 2018 •

edited