C6678 AMC related questions

Hi Prateek,

The good new is YES, our TMDXEVM6678L EVM can be used in a uTCA chassis in addition to standalone without modifications. This has been validated.

However, there are few caveats the customer should be aware of.

A) Our EVMs are designed for low cost development use and are not at all intended for production applications;

                We do not support AMC hot-swap features, industrial temp ranges or a standard front panel.

                 These can easily be developed by a customer interested in doing production development but are not needed for DSP development.

B) We support the basic MCH functionality and AMC card state changes from M1-M4 with an on-board MMC (implemented by the MSP430 on the EVM)

                The EVM can be properly detected, report its basic service and booted without the user doing anything.

                 The front edge BLUE LED reflects to the AMC state changes, similar to most AMC cards.

                The EVM supports GigE, SRIO and PCIe on the AMC backplane. We are compatible with the AMC SCOPES Alliance port mapping for uTCA systems.

                                   http://scope-alliance.org/technical-documents

C) All of this is in process of being validated in the following configuration, which we are still working to complete and document.

                  ELMA Blu!ECO uTCA chassis - model 040-033TI

                  N.A.T. MCH (base version with GigE switch)

                  JumpGen Host Card (with linux)

So to quickly answer your questions above:

1) Do the cards come programmed with FRU data in them?

YES

2) If yes, what is FRU data? i.e. PCI configuration, current draw, etc

Basic support for GigE, SRIO-Gen1 ... PCIe and SRIO-Gen2 will be validated soon.

3) Is there enough FRU data so that card in uTCA chassis will allow the card to boot?

YES

4) Card is missing a switch that is required to get powered on AMC bus. ?

NO, everything you need is there: MMC is supported on the EVM which communicates to the MCH to apply power and boot the EVM.

5) Card is not AMC slot install friendly, as there is no front panel/latch for easy card insertion/removal. Do we have more information on this?

YES, This is a a low cost development board.

5) Is there document that describes how to use EVMs in AMC system?

Coming soon....

Regards,

Peter.                

The EVM does not contain a faceplate and handle as these mechanicals added cost that we did not want to bear in a low-cost EVM solution.

The MMC handle switch input is always reported as closed so the IPMB handshake will complete successfully and the system manager supplies main power.  We do not support hot-swap.  The EVM must be installed in the chassis before it is powered on.

We market the EVM as being AMC compatible, not AMC compliant.

Tom

Thanks for the reply Peter, just a little bit more info on what you wrote:

B) We support the basic MCH functionality and AMC card state changes from M1-M4 with an on-board MMC (implemented by the MSP430 on the EVM)

                The EVM can be properly detected, report its basic service and booted without the user doing anything.

                 The front edge BLUE LED reflects to the AMC state changes, similar to most AMC cards.

                The EVM supports GigE, SRIO and PCIe on the AMC backplane. We are compatible with the AMC SCOPES Alliance port mapping for uTCA systems.

Does the FRU connectivity record show PCIe on AMC lanes 4-7 ? what about the SRIO ?

How much current does the EVM card request (current-draw record in the fru data) ?

The chassis we will put the EVM card in is small, so we will need to remove the fan, heat sink, and standoffs from the card.  I assume this is ok (thermally) because once in the chassis the fans will adequately cool the card, is that a reasonable assumption ?

Regarding the MMC code - did TI write their own or license it from someone else ?  I'm not asking because we want to release it or modify it, just fyi...

 thanks,

   Dan

Hi Dan,

Our EVMs have GigE on port-0 (Second GigE is routed to the front panel PHY);  SRIO on ports 8-11; and PCIe on ports 4-7

                        This is the SCOPES Alliance configuration.

                        The MMC reports the FRU data to the MCH for the GigE and SRIO. We are waiting to complete our validation of PCIe before we include this in the FRU stats.

The EVM design supports removing the fan, so long as you have alternate air flow across the heat sink.

                      You should not remove the heat sink as this is vital to stay within the thermal specs for this device.

                       The stand-offs can also be removed to fit the EVM within a full height slot.

The EVM power draw from the uTCA should be less than 20W; I'm not sure what the exact number is.

The MMC code (for the MSP430) is BSD licensed open source from TI. This will be provided when we release our documentation.

Regards,

Peter.

Thanks Peter, all sounds great except the part about the MMC not reporting PCIe data to the MCH.  Sorry for the confusion - does this mean there are no connectivity records for PCIe that the MCH can read ?  Doesn't that mean the MCH won't configure it's PCIe switch ?  Or are the records there for the MCH to read but the MMC just doesn't report them ?

I would like to put the EVM in a chassis, have it boot and the MCH configure it's own PCIe stuff, then configure a separate host card as the root and the EVM as an end point.  I'm thinking that if there are no PCIe connectivity records in the EVM FRU data, I won't be able to do this.

 thanks,

   Dan

Hi Dan,

You are about at the limits of my AMC standards knownledge; but my understanding is that the MCH is really not doing anything with the card stats, except providing the power to card. The MCH typically does not provide the PCIe switching; that is usually provided by a separate Host card.

The PCIe interface is there on the EVM at ports 8-11 and available to a host card to configure and access; regardless of the FRU stats reporting. There is nothing from the MCH to use it.

But there is likely to be some PCIe static configuration necessary from the Host card (and some initialization on the DSP) to access memory on the EVM through PCIe.

This is what we will validate soon.

Booting the DSP and loading code from Host over PCIe is also possible, but I'm not certain we need to do this in an uTCA system.

        This is a more common scenario for a PC-ATX chassis, which we will do using our AMC-to-PCIe ATX adapter card...

So I don't see any problems for you to accomplish what you want... with the understanding that this is just for development and a full production card would need to fill in some details to be fully compliant with the AMC standard.

Regards,

Peter.

I've been working on getting a couple of our EVM6678's to work in an AMC chassis from Vadatech. I've been having issues with getting it to power up. While I've managed to get it to forcefully power up, it doesn't seem to be communicating properly with the backplane. The chassis is actually showing the card as being in an unknown state and I can't get it to activate. Any thoughts?

- Chris

Hi Chris,

Unfortunately, there is some variability in the AMC protocol implementations across different MCH modules from different vendors.

We have so far validated that our EVM works with the NAT-MCH, here is the link to that device:

                   http://www.nateurope.com/data_sheets/NAT-MCH_ds.pdf

We will confirm other MCH compatibility as we can.

Also, the MMC source code implementation for the MSP430 on our EVM will be posted as Open Source soon so that the community can contribute to supporting other uTCA/MCH devices.

Hi Chris,

I'm curious what Vadatech chassis you're using, because that's exactly what I'm looking to do, and why I'm asking about the FRU data in the EVM.  When we receive our Vadatech chassis we want to bring up the EVM as well.  I assume you had to remove the fan and standoffs ?

What state does the MCH say the EVM card is in ?  When you say you forcefully power it up, do you turn off autonomous control on the power module and just enable the payload power to the card ?

From the MCH, can you read the FRU data on the EVM card ?  Does it have anything useful ?  Can you see connectivity records for PCIe in there ?  Since the Vadatech MCH supports e-keying, if it can't find any connectivity records I believe it won't power up the card.  This way it protects everything, i.e. if you were trying to plug the EVM (with PCIe) into an MCH with 10G/XAUI instead of PCIe, you wouldn't want the fabric turned on.

Have you talked to Vadatech about this ?  We use their 10G MCHs on other projects and have found them to be very helpful.  In the past where cards haven't booted, we've sent them the FRU data and they've looked at it and been able to tell us what's wrong with it, or missing, or...

Dan

Hi Dan,

We're using the VT862 which we have sparsely populated enough that I didn't need to remove anything from the EVM card. If you were to remove the fan and standoffs I think two of them would be able to fit adjacent to one another.

The MCH actually reports the card as being in an unknown state. I've gotten it to power up using the autonomous power up option on the power module, but this doesn't help with the card actually being detected or entering an active state. 

I've been talking to Vadatech about the issue, but haven't made any progress yet.

- Chris

I've been working with Vadatech the past couple days continuing to try to get these cards working, but there hasn't been much progress. We're still unable to get them to communicate properly with the MCH and power up. I tried pulling the FRU data directly through IPMI per Vadatechs instructions but even that didn't work.

Anyone with TI have any idea as to what may be happening or have suggestions of things to try?

Thanks,

Chris Thunes

Here is the Gforge link to download the MSP430 MMC code:

https://gforge.ti.com/gf/project/msp430_mmc_code/

click on files, then you will see a zip file to download.

Regards,

Travis

Hi Chris,

After talking with TI last week, they told me they do NOT have anything in FRU data connectivity records for PCIe on the current EVM.  I believe the Vadatech MCH is very strict (after working with Vadatech on 10G fabric MCHs and backplanes) and thus will not give payload power to a card without any connectivity records.  Otherwise, you could plug a PCIe card in a 10G backplane and if powered up, may damage either the card or MCH or both (i.e. "e-keying").  When you pulled the FRU data directly, were there any connectivity records ?  Did any of the FRU data come out ok, i.e. the basic product record info section ?

As you already mentioned, you did override the power module and force it to give payload power to the EVM card.  But since there are no connectivity records, I don't believe the MCH will initialize the on-board PLX PCIe switch and thus you won't be able to communicate with the EVM card over PCIe.  There is also poin to point SRIO on the EVM card so if you plug the EVM and your host card into your backplane such that the SRIO link is between them, I think you may be able to communicate that way.

Dan

I just talked to Vadatech too.  They say the problem is in the TI MMC code, and that it keeps hanging the I2C bus.  That's probably why you can't read even the regular FRU data via IPMI.

Does TI have a plan to fix this and release new MMC code ?

There is an effort ongoing to make the MMC on the C6678 EVM compatible with the Advantech MCH.  We beleive that once we have found and fixed the compatibility issues with the Advantech MCH that it should work with most other MCHs as they claim to require rigid protocol compliance.  The C6678 EVM has previously been successfully integrated with an NAT MCH.

Tom

Hi Travis,

I am not able to access this link says Permission Denied through my gforge login - how can I get access permissions?

Thanks,

Prateek

Hi Travis,

I too created a Gforge account and get Permission Denied when trying to access the link above.

Dan

The https://gforge.ti.com/gf/project is there, but the msp430_mmc_code directory is not listed.

This issue should be fixed now. Let me know if you still can't access it.

Also, found an issue with browser and file download that are working to fix. 

Under Files, if you click on downloading a file, Windows Explorer download file as .tgz while Mozilla does as .zip. Mozilla/WinZipworks fine om .zip download however Winzip under Explorer returns as Invalid archive directory when trying to open .tgz file. Workaround is to save file as .zip extension rather than .tgz and then WinZip or another unzip tool should be able to unzip the contents.

Prateek

Yeah, for some reason the default observer permissions kept the project directory hidden, I fixed that.  I have one of TI's Gforge support folks looking into the internet explorer issue and hopefully that will be fixed very shortly.

Regards,

Travis

Hi Chris,

Any luck or changes ?

Dan

2 Questions:

1. How is the effort is progressing to make the MMC code compatible with the Advantech MCH

2. How is the PCIe testing effort going ?  Even the production EVM cards do not have PCIe point to point connectivity records, because the PCIe testing had not been concluded.  Has the testing been concluded now and is it working ?

Dan

Dan,

The MMC code debug with the Advantech MCH is progressing.  A few more weeks will be needed to complete this.

Please start a separate e2e thread with the PCIe question.

Tom

Thanks Tom.  Once the MMC debug with Advantech has completed, will the code be released through the MSP430 projects ?

I'll start a new thread with the PCIe.

Dan

Yes

Hi Chris,

I have the EVM card in a VT852 chassis, and have modified the MMC code to play 'nice' with the Vadatech MCH.  Now the EVM boots up nicely in the chassis, FRU data is present etc... Have you tried the PCIe interface on the TI card in the VT chassis ?  I created the connectivity records and am starting with it now, just wondering if you'd had any luck...

Dan

Hi Dan,

I haven't done anything with PCIe. SRIO is the only thing I've worked with on the EVM in the chassis. Did you modify the MMC code yourself or did Advantech provide you with an update?

- Chris

Hi Chris,

I modified the MMC code myself.  I downloaded CCSv5 and got the USB FET debugger.  A bit non-trivial since you can't use the MMC Uart for debugging, since it requires 12V to be present (i.e. payload power active).  Seems a bit "catch-22" when you need 12V for the MMC serial port to debug why you can't get the card to go active and get 12V :-)  But all better... Now I have it in the VT852 chassis and am trying to bring up PCI.

Dan,

Have you posted, or would you be willing to post your code modifications?

Regards,

Travis

Hi Travis,

I haven't posted them yet but would be willing to once I've made sure everything works.  For example, there are no PCIe records in FRU data, and the FRU data is generated by the MMC code.  I want to make sure the records I generate work, then I can be sure I'm posting correct code.

I'm also trying to test the Gbe port through the AMC backplane, which is Mac0 from the DSP.  The front panel RJ-45 works fine (DSP mac1) and the hua application does DHCP ok and I can point my browser to the card.  The HUA application though is hardcoded to use the front panel port.  Are there any applications burned into the card that will use the Gbe port on the backplane so I can try that out ?  Then I can verify the connectivity record for that in the FRU data too.

Dan

Hi Dan,

We are using a VT862 chassis.  Would you be willing to post your MMC code so that we can update our EVMs to run in it.

Thanks,
Bryan

Hi Brian,

In theory I should, but (unfortunately) I need to check with the lawyers first...  Do you have the ability to burn new MMC code ?  Or would you need to build the code ?

Dan

We do.  If the code is built for the 6678 EVM, we would not even need the source, just the executable.

Checking with the lawyers now...

Dan,

Thanks for checking.  I don't expect you will have any issues, since this original code is open source code.  The whole purpose of Gforge release is to allow folks like yourself to download and then upload helpful modifications.  We could either use that route or you could post to the e2e forum and I could upload there as well.  FYI, there is a disclaimer to protect all contributors in their submissions to the e2e forums.

Let us know what you find.

Regards,

Travis

ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS AND PROVIDERS OF CONTENT MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. TI AND ITS RESPECTIVE SUPPLIERS AND PROVIDERS OF CONTENT MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH RESPECT TO THESE MATERIALS. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Thanks Travis - I don't think there would be any problems either, but want to be sure...

Hello!

I’ve have framed a system of following parts: chassis ELMA blue!eco, MicroTCA Carrier Hub Advantech UTCA-5503 и C6678 EVM Rev. A102-1.

Red and blue LED start blinking, after the power is set in C6678 EVM mode. Further only blue light-emitting diode glows. Power (12 V) from AMC slot isn’t applied to board C6678 EVM.
According to the following log file MCH, MMC don’t transmit data to FRU.

cli> fru
20: FRU #0
Entity: (0xc2, 0x60)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: Normal State Change (0x00)
Device ID String: "Advantech ShMM"
82: FRU #0
Entity: (0xc2, 0x60)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: Normal State Change (0x00)
Device ID String: "Advantech MCMC"
82: FRU #8
Entity: (0x00, 0x00)
Hot Swap State: M1 (Inactive), Previous: M0 (Not Installed),
Last State Change Cause: Normal State Change (0x00)
Device ID String: "Error:Cann't find dev.loc. SDR"
82: FRU #40
Entity: (0x1e, 0x61)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: State Change due to FRU programmatic action (0x03)
Device ID String: "Cooling Unit"
82: FRU #50
Entity: (0x0a, 0x61)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: State Change due to FRU programmatic action (0x03)
Device ID String: "PDM"
82: FRU #3
Entity: (0xc2, 0x61)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: Normal State Change (0x00)
Device ID String: "Advantech MCH"
cli>

Can you please advise something for solving this problem?

Truly yours. Dmitry.

Dmitry,

This has been covered at the top of this thread (it is currently 3 pages long).  Please be sure to read from the beginning.

It appears from the log that you are trying to use an Advantech MCH.  Our MMC code has not been validated to operate with the Advantech MCH yet.  The current implementation is validated with the N.A.T. MCH.  We are currently modifying the code to work with the Advantech MCH.  We will release it when it is available.  We are hoping that the next release will operate generally with most MCH variants.  This activity has taken longer than we had planned.

Tom

Dmitry,

Do you have ability to rebuild the MMC code (i.e. MSP430 development environment) ?  If so, I can tell you what to change so the card will be recognized by the MCH and boot.  Basically the MCH is asking the EVM card for some SDR data.  The EVM card returns garbage and the MCH isn't happy, and then ignores the card.  However, even if it does boot, it only has connectivity records for SRIO Gen1.  That means if you want to use SRIO Gen2 or any PCIe flavor, you'll have to add connectivity records to the fru data as well, and thus will require you to modify the MMC code. 

I have the EVM card up in a Vadatech chassis (and MCH) with PCIe Gen2 x4 lanes as an endpoint and working fine.

Tom - any idea when the code will be posted ?

Dan

Dan,

Our revised MMC code is still going through modification and validation testing.  Did you provide your code to Travis for posting on the Gforge site?

Tom

Hi Tom,

After talking with the lawyers, I couldn't provide actual code.  However, I did email him a very detailed description of the changes I made :-)  And I can answer any questions too.  I just can't actually release the code itself.  I also sent it to Peter Flynn, you can get it from him or I can send it to you.

Dan

Dan,

Thanks, I will get it.

Tom

Hi Tom,

Will work with NAT-MCH-PCIex24?

Dmitry/

Dmitry,

As stated at the top of this thread, we have integrated successfully with the NAT MCH that supports basic Ethernet connectivity.  We will soon be working with their MCH that supports SRIO GEN2.  Please note that we are using a customized ELMA backplane that supports the SCOPES recommendation that supports both PCIe and SRIO simultaneously from the AMC.  This customized backplane is available for order from ELMA.  Our PCIe integration thus far has been directly connected between two AMC slots.  We have not integrated with a PCIe-enabled MCH in a chassis.  Also note that another post to this thread indicates that this integration has been successfully done by one of our customers but with modifications to the MMC code.  We plan to support this in the future.

Tom

Dmitry,

I forgot to mention that we have also successfully integrated with a NAT MCH containing SRIO GEN1 support.

Tom

Dan,

I can buy  OLIMEX  USB JTAG MSP430-JTAG-TINY.

What you want to change the code to MMC worked PCIe?

Dmitry.

Hi Dmitry,

You can buy the JTAG device, but remember you don't want the 2x7 pin header for your EVM.  The A102-1 EVMs use the SBW so make sure you get that interface.  Or just get the TI one and you can run 4 wires to the card. 

You'll also have to rebuild the code - I used CCSv5.

If you want PCIe connectivity, you'll have to modify the lines that look like:

        LinkDescriptorPack(&fru_data.p2p_rec.link_descr[2][0],  0x3F, 0, 0, 0, AMC_LINK_SERIAL_RAPID_IO, 0, 0, 0, 1, 1);

You will have to add lines (and appropriate values) for PCIE type links, and increase the AMC_LINKS_MAX and AMC_CHANNELS_MAX in amc.h

Dan

Happy to announce major updates to the MMC code which now supports NAT, Advantech, and Vadatech MCH cards.  Please see:

https://gforge.ti.com/gf/project/msp430_mmc_code/              Click on files on the left.

Big thanks go out to Dan Gold and Rakesh Modi for making this happen!!!

Regards,

Travis

Thank you.
Now the module is powered.
But there are still problems.

Pigeon Point MicroTCA Shelf Manager ver. 1.0.2
Pigeon Point is a trademark of Pigeon Point Systems.
Copyright (c) 2002-2007 Pigeon Point Systems
Advantech aMCH (c) 2007 by Advantech
Build date / time: Aug December 2008 12:47:24
All rights reserved
cli> fru

20: FRU # 0
Entity: (0xc2, 0x60)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: Normal State Change (0x00)
Device ID String: "Advantech ShMM"
82: FRU # 0
Entity: (0xc2, 0x60)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: Normal State Change (0x00)
Device ID String: "Advantech MCMC"
82: FRU # 8
Entity: (0xc1, 0x64)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: Normal State Change (0x00)
Device ID String: "TI-LC_EVM"
82: FRU # 40
Entity: (0x1e, 0x61)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: State Change due to FRU programmatic action (0x03)
Device ID String: "Cooling Unit"
82: FRU # 50
Entity: (0x0a, 0x61)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: State Change due to FRU programmatic action (0x03)
Device ID String: "PDM"
82: FRU # 3
Entity: (0xc2, 0x61)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process),
Last State Change Cause: Normal State Change (0x00)
Device ID String: "Advantech MCH"
cli> frudata
20: FRU # 0 FRU Info size: 4096 bytes.
20: FRU # 254 FRU Info size: 3728 bytes.
82: FRU # 0 FRU Info size: 4096 bytes.
82: FRU # 253 FRU Info size: 4464 bytes.
82: FRU # 1 FRU Info size: 3728 bytes.
82: FRU # 8 FRU Info size: 469 bytes.
82: FRU # 40 FRU Info size: 116 bytes.
82: FRU # 50 FRU Info size: 101 bytes.
82: FRU # 3 FRU Info size: 4096 bytes.
cli> frudata 82 8
82: FRU # 8 FRU Info size: 469 bytes.
Raw FRU Info Data:

length mismatch: len = 22, but 25 was expected
cli: An error occurred during command execution
cli>

Dmitry.

Dmitry,

That is beyond the scope of our EVM support.  We only intend AMC compatibility.  We recommend that you debug this with your MCH manufacturer.

Tom