Discussion:
Intel 82551IL chips
(too old to reply)
Желобанов Дмитрий Владимирович
2015-09-15 12:14:57 UTC
Permalink
Hello,

We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms. Our devices run QNX operation system. We faced with an issue: sometimes our devices don't receive Ethernet packets right after boot at all, only reboot helps to revive the devices. We think the root problem is in hardware-software communication with the Ethernet controller, or rather in QNX Ethernet driver.
I looked in Linux driver (e100.c) and found, the driver uploads special firmware in chips like ours.

So, could you give us a document which clarifies changes in d102e_ucode.bin firmware from the original on chip microcode?

öÅÌÏÂÁÎÏ× ä.÷.
ïïï <ðÒÏÓÏÆÔ-óÉÓÔÅÍÙ>, Ç. åËÁÔÅÒÉÎÂÕÒÇ.
Fujinaka, Todd
2015-09-15 16:42:35 UTC
Permalink
The 82551L has been EOLed for about nine years by my estimation. We don't have any further support for it.

Also, it is probably a violation of the GPL to start with the Linux driver to work on the QNX driver. I would suggest trying the FreeBSD driver.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
***@intel.com
(503) 712-4565

-----Original Message-----
From: Желобанов Дмитрий Владимирович [mailto:***@prosoftsystems.ru]
Sent: Tuesday, September 15, 2015 5:15 AM
To: e1000-***@lists.sourceforge.net
Subject: [E1000-devel] Intel 82551IL chips

Hello,

We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms. Our devices run QNX operation system. We faced with an issue: sometimes our devices don't receive Ethernet packets right after boot at all, only reboot helps to revive the devices. We think the root problem is in hardware-software communication with the Ethernet controller, or rather in QNX Ethernet driver.
I looked in Linux driver (e100.c) and found, the driver uploads special firmware in chips like ours.

So, could you give us a document which clarifies changes in d102e_ucode.bin firmware from the original on chip microcode?

Желобанов Д.В.
ООО <Прософт-Системы>, г. Екатеринбург.


------------------------------------------------------------------------------
Ronciak, John
2015-09-15 17:40:01 UTC
Permalink
As long as there is no copy and pasting from the Linux driver to the QNX driver it should not be a problem. I'm not a lawyer but that's generally the case. That said, since the driver works after another a second reboot it's probably not related to the driver. This is probably something that is related to the system during the PCI enumeration of devices. Are all the other devices seen on a cold boot? Is there an equivalent to 'lspci' in QNX? If so what's it show on the first boot from power-off? Are all the devices seen at that point or are some missing?

Cheers,
John
Post by Fujinaka, Todd
-----Original Message-----
Sent: Tuesday, September 15, 2015 9:43 AM
Subject: Re: [E1000-devel] Intel 82551IL chips
The 82551L has been EOLed for about nine years by my estimation. We don't
have any further support for it.
Also, it is probably a violation of the GPL to start with the Linux driver to
work on the QNX driver. I would suggest trying the FreeBSD driver.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
(503) 712-4565
-----Original Message-----
From: Желобанов Дмитрий Владимирович
Sent: Tuesday, September 15, 2015 5:15 AM
Subject: [E1000-devel] Intel 82551IL chips
Hello,
We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms. Our
devices run QNX operation system. We faced with an issue: sometimes our
devices don't receive Ethernet packets right after boot at all, only reboot
helps to revive the devices. We think the root problem is in hardware-
software communication with the Ethernet controller, or rather in QNX
Ethernet driver.
I looked in Linux driver (e100.c) and found, the driver uploads special
firmware in chips like ours.
So, could you give us a document which clarifies changes in d102e_ucode.bin
firmware from the original on chip microcode?
Желобанов Д.В.
ООО <Прософт-Системы>, г. Екатеринбург.
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit
http://communities.intel.com/community/wired
------------------------------------------------------------------------------
Желобанов Дмитрий Владимирович
2015-09-16 05:08:14 UTC
Permalink
Hello,

Of course I wouldn't copy-paste Linux driver into QNX. As a matter of fact, we have the source code for QNX, it names devnp-speedo.
I just want to fix the QNX driver by inspiration of the Linux driver. By the way, the QNX network kernel is a port of the FreeBSD kernel.

The device is visible on PCI bus when the driver doesn't receive packets.
Let me give you more details on the issue:
When the driver stops receiving: the "RX packet counter" is about 200, and we have the message in the slog: <timeout sending 20, stat 80>
I looked in the source code and found lines which issues the message:
#define SCB_STATUS 0x00 /* Command Unit Status */
#define SCB_BYTE2 2

int iobase = speedo->iobase + SCB_STATUS + SCB_BYTE2;
int timeout;

/*
* wait for the previous command to finish
*/
if (SPEEDO_IN8(iobase) != 0x00) {
for(timeout = 1000000; timeout && (SPEEDO_IN8(iobase)); timeout--)
nsec_delay(1000);
if (!timeout) {
log(LOG_ERR,
"timeout sending %x, stat %x", bcmd, SPEEDO_IN8(iobase));
return -1;
}
}

I do want to know what the comment from the Linux driver means:
* Based on comments in the source code for the FreeBSD fxp
* driver, the FIRMWARE_D102E ucode includes both CPUSaver and
*
* "fixes for bugs in the B-step hardware (specifically, bugs
* with Inline Receive)."
*
* So we must fail if it cannot be loaded.

It seems as it is our case, because PCI enumeration gives:
Class = Network (Ethernet)
Vendor ID = 8086h, Intel Corporation
Device ID = 1209h, 8255xER/82551IT Fast Ethernet Controller
PCI index = 1h
Class Codes = 020000h
Revision ID = 10h

Could you give me a document which describes the statement "fixes for bugs in the B-step hardware (specifically, bugs with Inline Receive)."?

Dmitry Zhelobanov
Prosoft-Systems, Russia, Ekaterinburg



-----Original Message-----
From: Ronciak, John [mailto:***@intel.com]
Sent: Tuesday, September 15, 2015 10:40 PM
To: Fujinaka, Todd; Желобанов Дмитрий Владимирович; e1000-***@lists.sourceforge.net
Subject: RE: Intel 82551IL chips

As long as there is no copy and pasting from the Linux driver to the QNX driver it should not be a problem. I'm not a lawyer but that's generally the case. That said, since the driver works after another a second reboot it's probably not related to the driver. This is probably something that is related to the system during the PCI enumeration of devices. Are all the other devices seen on a cold boot? Is there an equivalent to 'lspci' in QNX? If so what's it show on the first boot from power-off? Are all the devices seen at that point or are some missing?

Cheers,
John
Post by Fujinaka, Todd
-----Original Message-----
Sent: Tuesday, September 15, 2015 9:43 AM
Subject: Re: [E1000-devel] Intel 82551IL chips
The 82551L has been EOLed for about nine years by my estimation. We
don't have any further support for it.
Also, it is probably a violation of the GPL to start with the Linux
driver to work on the QNX driver. I would suggest trying the FreeBSD driver.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
(503) 712-4565
-----Original Message-----
From: Желобанов Дмитрий Владимирович
Sent: Tuesday, September 15, 2015 5:15 AM
Subject: [E1000-devel] Intel 82551IL chips
Hello,
We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms.
sometimes our devices don't receive Ethernet packets right after boot
at all, only reboot helps to revive the devices. We think the root
problem is in hardware- software communication with the Ethernet
controller, or rather in QNX Ethernet driver.
I looked in Linux driver (e100.c) and found, the driver uploads
special firmware in chips like ours.
So, could you give us a document which clarifies changes in
d102e_ucode.bin firmware from the original on chip microcode?
Желобанов Д.В.
ООО <Прософт-Системы>, г. Екатеринбург.
----------------------------------------------------------------------
-------- _______________________________________________
E1000-devel mailing list
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit
http://communities.intel.com/community/wired
Желобанов Дмитрий Владимирович
2015-09-16 05:19:33 UTC
Permalink
I want to give a small addition: even the chip is EOL, but we have a big number of embedded devices with the chip on board. All devices installed in the field and, unfortunately, we do must support the devices!

-----Original Message-----
From: Желобанов Дмитрий Владимирович
Sent: Wednesday, September 16, 2015 10:08 AM
To: 'Ronciak, John'; Fujinaka, Todd; e1000-***@lists.sourceforge.net
Subject: RE: Intel 82551IL chips

Hello,

Of course I wouldn't copy-paste Linux driver into QNX. As a matter of fact, we have the source code for QNX, it names devnp-speedo.
I just want to fix the QNX driver by inspiration of the Linux driver. By the way, the QNX network kernel is a port of the FreeBSD kernel.

The device is visible on PCI bus when the driver doesn't receive packets.
Let me give you more details on the issue:
When the driver stops receiving: the "RX packet counter" is about 200, and we have the message in the slog: <timeout sending 20, stat 80> I looked in the source code and found lines which issues the message:
#define SCB_STATUS 0x00 /* Command Unit Status */
#define SCB_BYTE2 2

int iobase = speedo->iobase + SCB_STATUS + SCB_BYTE2;
int timeout;

/*
* wait for the previous command to finish
*/
if (SPEEDO_IN8(iobase) != 0x00) {
for(timeout = 1000000; timeout && (SPEEDO_IN8(iobase)); timeout--)
nsec_delay(1000);
if (!timeout) {
log(LOG_ERR,
"timeout sending %x, stat %x", bcmd, SPEEDO_IN8(iobase));
return -1;
}
}

I do want to know what the comment from the Linux driver means:
* Based on comments in the source code for the FreeBSD fxp
* driver, the FIRMWARE_D102E ucode includes both CPUSaver and
*
* "fixes for bugs in the B-step hardware (specifically, bugs
* with Inline Receive)."
*
* So we must fail if it cannot be loaded.

It seems as it is our case, because PCI enumeration gives:
Class = Network (Ethernet)
Vendor ID = 8086h, Intel Corporation
Device ID = 1209h, 8255xER/82551IT Fast Ethernet Controller
PCI index = 1h
Class Codes = 020000h
Revision ID = 10h

Could you give me a document which describes the statement "fixes for bugs in the B-step hardware (specifically, bugs with Inline Receive)."?

Dmitry Zhelobanov
Prosoft-Systems, Russia, Ekaterinburg



-----Original Message-----
From: Ronciak, John [mailto:***@intel.com]
Sent: Tuesday, September 15, 2015 10:40 PM
To: Fujinaka, Todd; Желобанов Дмитрий Владимирович; e1000-***@lists.sourceforge.net
Subject: RE: Intel 82551IL chips

As long as there is no copy and pasting from the Linux driver to the QNX driver it should not be a problem. I'm not a lawyer but that's generally the case. That said, since the driver works after another a second reboot it's probably not related to the driver. This is probably something that is related to the system during the PCI enumeration of devices. Are all the other devices seen on a cold boot? Is there an equivalent to 'lspci' in QNX? If so what's it show on the first boot from power-off? Are all the devices seen at that point or are some missing?

Cheers,
John
Post by Fujinaka, Todd
-----Original Message-----
Sent: Tuesday, September 15, 2015 9:43 AM
Subject: Re: [E1000-devel] Intel 82551IL chips
The 82551L has been EOLed for about nine years by my estimation. We
don't have any further support for it.
Also, it is probably a violation of the GPL to start with the Linux
driver to work on the QNX driver. I would suggest trying the FreeBSD driver.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
(503) 712-4565
-----Original Message-----
From: Желобанов Дмитрий Владимирович
Sent: Tuesday, September 15, 2015 5:15 AM
Subject: [E1000-devel] Intel 82551IL chips
Hello,
We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms.
sometimes our devices don't receive Ethernet packets right after boot
at all, only reboot helps to revive the devices. We think the root
problem is in hardware- software communication with the Ethernet
controller, or rather in QNX Ethernet driver.
I looked in Linux driver (e100.c) and found, the driver uploads
special firmware in chips like ours.
So, could you give us a document which clarifies changes in
d102e_ucode.bin firmware from the original on chip microcode?
Желобанов Д.В.
ООО <Прософт-Системы>, г. Екатеринбург.
----------------------------------------------------------------------
-------- _______________________________________________
E1000-devel mailing list
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit
http://communities.intel.com/community/wired
Ronciak, John
2015-09-16 22:57:22 UTC
Permalink
HI Dmirty,

I would have no idea of where to get that information from today. That code was written over 12 years ago. I sure there was an errata back then but where to find something that old would be a problem. Also, since the drivers that are in FreeBSD today and in Linux do not have reports of this happening it make sense that this is a QNX only issue. I'd take a look at the FreeBSD driver to see how different it is from the one you are using. Since QNX has never been on our supported OS list we have never tested it ourselves. So we have no idea if other QNX users are seeing this or not, especially since it on such old HW.

Sorry I can't be more help. Try to debug code that 12 or more years old when it's not our driver is very problematic for us.

Cheers,
John
Post by Fujinaka, Todd
-----Original Message-----
From: Желобанов Дмитрий Владимирович
Sent: Tuesday, September 15, 2015 10:20 PM
Subject: RE: Intel 82551IL chips
I want to give a small addition: even the chip is EOL, but we have a big
number of embedded devices with the chip on board. All devices installed in
the field and, unfortunately, we do must support the devices!
-----Original Message-----
From: Желобанов Дмитрий Владимирович
Sent: Wednesday, September 16, 2015 10:08 AM
Subject: RE: Intel 82551IL chips
Hello,
Of course I wouldn't copy-paste Linux driver into QNX. As a matter of fact,
we have the source code for QNX, it names devnp-speedo.
I just want to fix the QNX driver by inspiration of the Linux driver. By the way,
the QNX network kernel is a port of the FreeBSD kernel.
The device is visible on PCI bus when the driver doesn't receive packets.
When the driver stops receiving: the "RX packet counter" is about 200, and
we have the message in the slog: <timeout sending 20, stat 80> I looked in
#define SCB_STATUS 0x00 /* Command Unit Status */
#define SCB_BYTE2 2
int iobase = speedo->iobase + SCB_STATUS + SCB_BYTE2;
int timeout;
/*
* wait for the previous command to finish
*/
if (SPEEDO_IN8(iobase) != 0x00) {
for(timeout = 1000000; timeout && (SPEEDO_IN8(iobase));
timeout--)
nsec_delay(1000);
if (!timeout) {
log(LOG_ERR,
"timeout sending %x, stat %x", bcmd,
SPEEDO_IN8(iobase));
return -1;
}
}
* Based on comments in the source code for the FreeBSD fxp
* driver, the FIRMWARE_D102E ucode includes both CPUSaver and
*
* "fixes for bugs in the B-step hardware (specifically, bugs
* with Inline Receive)."
*
* So we must fail if it cannot be loaded.
Class = Network (Ethernet)
Vendor ID = 8086h, Intel Corporation
Device ID = 1209h, 8255xER/82551IT Fast Ethernet Controller
PCI index = 1h
Class Codes = 020000h
Revision ID = 10h
Could you give me a document which describes the statement "fixes for bugs
in the B-step hardware (specifically, bugs with Inline Receive)."?
Dmitry Zhelobanov
Prosoft-Systems, Russia, Ekaterinburg
-----Original Message-----
Sent: Tuesday, September 15, 2015 10:40 PM
To: Fujinaka, Todd; Желобанов Дмитрий Владимирович; e1000-
Subject: RE: Intel 82551IL chips
As long as there is no copy and pasting from the Linux driver to the QNX
driver it should not be a problem. I'm not a lawyer but that's generally the
case. That said, since the driver works after another a second reboot it's
probably not related to the driver. This is probably something that is related
to the system during the PCI enumeration of devices. Are all the other
devices seen on a cold boot? Is there an equivalent to 'lspci' in QNX? If so
what's it show on the first boot from power-off? Are all the devices seen at
that point or are some missing?
Cheers,
John
Post by Fujinaka, Todd
-----Original Message-----
Sent: Tuesday, September 15, 2015 9:43 AM
Subject: Re: [E1000-devel] Intel 82551IL chips
The 82551L has been EOLed for about nine years by my estimation. We
don't have any further support for it.
Also, it is probably a violation of the GPL to start with the Linux
driver to work on the QNX driver. I would suggest trying the FreeBSD driver.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
(503) 712-4565
-----Original Message-----
From: Желобанов Дмитрий Владимирович
Sent: Tuesday, September 15, 2015 5:15 AM
Subject: [E1000-devel] Intel 82551IL chips
Hello,
We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms.
sometimes our devices don't receive Ethernet packets right after boot
at all, only reboot helps to revive the devices. We think the root
problem is in hardware- software communication with the Ethernet
controller, or rather in QNX Ethernet driver.
I looked in Linux driver (e100.c) and found, the driver uploads
special firmware in chips like ours.
So, could you give us a document which clarifies changes in
d102e_ucode.bin firmware from the original on chip microcode?
Желобанов Д.В.
ООО <Прософт-Системы>, г. Екатеринбург.
----------------------------------------------------------------------
-------- _______________________________________________
E1000-devel mailing list
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit
http://communities.intel.com/community/wired
Loading...