Does RT support the Broadcom 5754 Gigabit Ethernet controller

[AnthonV]

Hi, I'm purchasing one of the latest Dell Precisions to run RT on.  It comes standard with an integrated Broadcom 5754 Gigabit Ethernet controller.  The NI documents only list the "Broadcom® BCM5751 "0x1677" (8.0+)" as being supported. 

Any idea whether I be able to use RT with the 5754?

Thanks

[Riconquistiamola]

Hi AnthonV,

 The functionality you are looking for is Ethernet Whitelist support, and it is available in LabVIEW Real-Time 8.6. I am in the process of writing a KB about this feature, but I can provide the steps below to do so in the meantime.

---

A user will create the enetwhitelist.ini file either on c:/ni-rt/system/Ethernet or on the root dir of the safe-mode USB stick. It is required for this feature to work in safe-mode from an USB stick that the stick is the only USB device on the system at boot time. The enetwhitelist.ini file will be divided into three classes of sections:
The [GENERAL] section of the ini file will have the Drivers field. This field will contain an enumeration of drivers the user will enable the white-list feature for. The driver names will be separated by commas and will be referenced by their dll names:
i8254x.dll
i8255x.dll
bcm57xx.dll
nvidia.dll
Another field in the [GENERAL] section will be called VerboseLoading. This field is optional and has a Boolean value (TRUE/FALSE). If it is set to TRUE debug information will be printed on the screen notifying the user of the status of the whitelisted drivers.

---

The second part of the ini file will contain one section for each driver supporting the whitelist feature. The names of these sections will be the same as the valid driver names presented for the Drivers field above. Each of these sections will contain a single field named Adapters, whose value will be the chip name of the Ethernet Adapter (e.g.: 8254PI, BCM5721 … ).
The last part of the ini file will contain sections describing the chips added in the section above. Each of the chips in the Adapters field must have a section of their own here (e.g. for the example above we have [8254PI] and [BCM5721] sections). These sections will have the following fields:

• ChipID – single value, hexadecimal value of the chip’s PCI ID (also known as the Device ID).
• EEPROM – mandatory only for chips from the Intel 8254x family. Possible values are Legacy or Marvel. If an EEPROM value is not provided, Legacy is considered to be default. In case the driver cannot control the device, the user must edit the ini file and add EEPROM=Marvel in the chip’s section.
• FAMILY – mandatory only for chips from the Intel 8254x family. Possible values are 8254x, 82571, 82572, 82573 or 82563. If an FAMILY value is not provided, 8254x is considered to be default.
• VendorID - optional field, used in case support is added for a device from a different vendor which is register compatible with the Intel devices. Default value is the Intel vendor ID.
• Description - optional field used to provide a description for the chipset; used for debug purposes only.

This structure provides means of turning the whitelist feature on/off for a certain driver. This is done by simply adding/removing the driver dll name from the Drivers field in the [GENERAL] section: the white-list feature for a driver will only work if its name is in that field value. The same way, a chip whitelisting can be turned on or off by adding or removing the chip’s name in the Adapters field in its driver section.

---

 Example of a enetwhitelist.ini file

 [GENERAL]
Drivers=i8254x.dll, bcm57xx.dll
VerboseLoading=TRUE

[i8254x.dll]
Adapters=82541PI, 82541GX
LoadPredefinedChipsets=TRUE

[bcm57xx.dll]
Adapters=BCM5721

[nvidia.dll]
Adapters=

[i8255x.dll]
Adapters=

[82541GX]
ChipID= 107A
EEPROM=Legacy
FAMILY=8254x
Description="Intel 82541GX Ethernet Chipset

[82541PI]
ChipID=1077
VendorID=0x8086
EEPROM=Marvel
FAMILY=8254x

[BCM5721]
ChipID=0x167D

[BCM5705]
ChipID=0x1659

In the above example, white-list feature is enabled only for the Intel 8254x and Broadcom 57xx drivers, and the chips enabled by the white-list feature are 82541GX and 82541PI for Intel and BCM5721 for Broadcom. I have also attached the enetwhitelist.ini from my personal testing.

Please let me know if you have any questions/comments/concern and if you are successful! Cheers.

Message Edited by Riconquistiamola on 10-22-2008 10:59 AM

[AnthonV]

Thanks for the very detailed information Michael!  Honestly I'm not 100% sure whether you are saying 'yes' or 'no' but I'm going to assume this is a 'yes'! 

So I am thus going to order the Dell this week but delivery is only expected in 4 weeks time, so it will be a while before I can try what you are suggesting (by then there might be a RT 8.7 with this included in the build 🙂 ).  I'll post on this thread if I have any difficulties.

Thanks

AnthonV

[Riconquistiamola]

AnthonV,

Ethernet whitelist support in 8.6 means "maybe." We have only tested ethernet chipsets in the requirements document, so whitelist support is not guaranteed to work. Instead, we allow users to test their NICs to determine supportability. That's why I'm interested to hear whether or not you are successful!

The worst-case scenario is your NIC is not supported. In that case, simply purchase a PCI NIC that is supported. Cheers.

[hanzr]

Dear Michael K,

I am in the process of evaluating this system that AnthonV was inquiring about. I used RT 8.5.1 to create an RT Desktop PC Utility Disk Drive, which does not support the White List function. When presented with the menu after reboot, I select "7. Evaluate System" and run it which returns the issue with the NIC as expected. It also returns an error with regards to the SATA hard drive which is configured as AHCI - this is unexpected.

Subsequently, I installed an evaluation version of RT 8.6 and Labview 8.6 to generate an RT Desktop PC Utility Disk Drive, but now, upon reboot and being presented by the same menu and selecting option 7, nothing happens. The computer simply hangs. 

I thought it may have something to do with other dependencies, so I installed everything on the Developer System, but this made no difference. Am I missing anything?

The PC is a Dell Precision T7400. I have two SATA drives (could this be the issue) which operates through some SAS controller (could this be the issue). 

Any feedback would be appreciated.

[Riconquistiamola]

Hi Hanzr,

First, I recommend simplifying your system as much as possible. Work with a single SATA HDD in AHCI mode during the setup process. Disable multicore, integrated audio, etc. until the PC is running RT.

Though your experience indicates the contrary, the Utility USB Drive didn't change from 8.5 to 8.6 (other than adding listed hardware support). I'd like to know if it will boot successfully on any other RT PCs you have already created.

Finally, what is the HDD error message displayed in 8.5.1?

[hanzr]

Dear Michael K,

I tried simplifying the system (Dell T7400) by disabling the SAS controller and using the SATA slots for a single HDD configured to use AHCI. I disabled the audio in BIOS, but the BIOS has no control over multicore/non-multicore. I tried two configuration, with and without a SATA CD/DVD-ROM (I forgot to remove it the first time). Of course I tried using the RT 8.5.1 and 8.6 utility disks. 

Using 8.5.1 and no CD - utility evaluates but cannot start up File System nor find devices for ethernet drivers and suggest installing multicore support.

Using 8.5.1 and CD - utility only returns the following: uTlsInitTerm: pDllBlk is NULL

Using 8.6 and no CD - nothing happens, PC hangs

Using 8.6 and CD - utility returns the following:

uTlsInitTerm: pDllHand is NULL

uTlsInitTerm: pDllHand is NULL

uTlsInitTerm: pDllHand is NULL

uTlsInitTerm: pDllHand is NULL

uTlsInitTerm: pDllHand is NULL

uTlsInitTerm: pDllHand is NULL

uTlsInitTerm: pDllHand is NULL

uTlsInitTerm: pDllHand is NULL

uTlsInitTerm: pDllHand is NULL

XMT: 6 0 3 0 0 0

r3

 I also ran the utility on an Intel Pentium Dual E2180, where the BIOS allowed me to configure the SATA drive as IDE/Legacy. Both the RT 8.5.1 and 8.6 utilities run, but both fail to start up the File System telling me that I should configure the drive as PATA or IDE Legacy. 

Then I ran both utilities on an NI PXI-1042 Chassis with an NI PXI-8187 Embedded Controller - both worked, but both return the same error with the HDD/Starting up File System.

The full message:

"Starting up File System...     failed.

Error! Could not initialize IDE hard drive. Check hardware configuration.

Note: Labview Real-Time supports only Parallel ATA models. If you have

Serial ATA hard drive it must be configured to work in "legacy" or

compatibility mode to appear as Parallel ATA."

 Thanks for the reply and suggestion. I hope this reply helps you to help me.

[Texas_Diaz]

The BCM5754 is part of the NetXtreme II Broadcom device family, and the ONLY support we have is for the original NetXtreme family of chipsets (which only the BCM5751 has ever really worked, so that's all our drivers are designed to support at this time).  I don't want to say bad things on an open forum about Broadcom, but let's just say they aren't the most helpful people when it comes to requesting development documentation about their products (even when we're buying products from them).  This means that unless something significantly changes in our relationship with Broadcom we will not be able to support additional chipsets in the Broadcom line of ethernet chips. 

If anyone knows anyone at Broadcom who can help us obtain documentation on developing ethernet drivers for the NetXtreme II class devices, we are certainly ready and willing to dedicate resources to write RT ethernet drivers for those chipsets.  No, the FreeBSD driver is NOT enough, we need the full register spec and programming documentation - we will not attempt to reverse-engineer a FreeBSD driver to possibly determine how to translate a deterministic RT driver.

-Danny

[Texas_Diaz]

Oh, and about the uTlsInitTerm error...

The uTlsInitTerm messages are from the DLL loading engine, where the DLL_PROCESS_ATTACH, DLL_PROCESS_DETACH, DLL_THREAD_ATTACH, and DLL_THREAD_DETACH routines are loaded.  pDLLHand is referencing the fact that when the DLL's ATTACH/DETACH function is called, the global handle list for the DLL is NULL; as if the DLL was loaded and there was an internal error that wasn't propagated correctly, or by the time the ATTACH/DETACH was called the DLL and associated structures was already cleared from memory and its data structures cleared out.  Not really sure why this would be happening in your case, but this is the reason for the error...

-Danny

[Texas_Diaz]

Oh, sorry, one more thing....

Ethernet whitelisting support is only currently supported on the Intel8254x ethernet drivers.  We know we didn't cover the full gambit of 82541, 8257x, and other chipsets in the same family as the chips we currently support (which we could probably very well support if we had added those chips to our list, but if we cannot verify then it's best to not hose you by accident).  So, that's why we came up with the White Listing capability, but it only made sense to support it on the chipsets we knew customers wanted to extend and we were fairly certain success had a high probability.

-Danny