I don't see the problem even on marc019, but I don't see 1.4.1 running on marc019. Did you build your own version of 1.4.1? Where is the sccDump that you are using?

I work on marc041. Could you downgrade it to 1.3.0, or what else could we do? Thanks.

Yes, we can do this.

There's been some discussion of setting up a 1.3.0 system for people who want 1.3.0 and giving accounts on that system.

I'm not sure what is the best approach for this. What would you prefer? ... 1) your system downgraded to 1.3.0 or 2) access to an additional 1.3.0 system with your system staying at 1.4.1.3. Downgrading is not a one-way street. It's easy to go back to 1.4.1 ... we backup all the config files.

There is also a movement afoot to upgrade the ETI FW to work with 1.4.1.3 ... because baremetal has recently gotten a lot more interest. I would not recommend waiting for the upgrade, but would recommend using it when it becomes available.

And then about the ETI FW itself. It's not Intel code; it belongs to ETI. Although technically we could install the ETI FW on your marc machine ourselves, I think it's best that you get it from ETI. If you haven't done it already, it's easy.

http://communities.intel.com/message/108074#108074

In that way you become part of ETI's user database.

A downgrade sounds fine. I don't think we have used anything version-specific so far, so you can proceed with it as far as I am concerned.

Ted Kubaska wrote:

 

I don't see the problem even on marc019, but I don't see 1.4.1 running on marc019. Did you build your own version of 1.4.1? Where is the sccDump that you are using?

I'm getting the error when I run the 1.4.1 binary I downloaded from the repository.  It's located at /home/mziwisky/tmp/sccKit2/1.4.1/bin/sccDump.  With the installed 1.4.0 binary there is no problem.

darence wrote:

 

As for miketerm, I did try to run "make run" first, but it doesn't help... Anyway, I'll have sccKit downgraded -- looks like a good idea for both your framework and ETI.

From your output, it's not obvious why you were getting the errors you had.  Wish I could reproduce it on marc019, but it seems I'm having unrelated issues with 1.4.1.  In any event, miketerm ought to work with 1.4.0, but hasn't been tested with 1.3.0.

If you care to try miketerm with an sccKit that you've downloaded but not installed to /opt, it only takes a few modifications in miketerm.cpp.  In lines 36 and 87, you must change

   sprintf(str, "sccDump -d ...

to

   sprintf(str, "<path_to_sccKit_binaries>/sccDump -d ...

and similarly, line 145 should go from

   sprintf(str, "sccWrite -d ...

to

   sprintf(str, "<path_to_sccKit_binaries>/sccWrite -d ...

But hopefully things will work fine after the downgrade, and you won't have to bother with that.  If you do continue to try using miketerm, let me know how it goes, especially if you run into other issues.

--Mike

I dont see the error with 1.4.1.3 on marc101 (1.4.1 with patch3). It looks as if you've taken 1.4.1 with patch2, and the only diffference between patch2 and patch3 is that a test program (sccProductiontest) is fixed. But I can see the error running the sccDump under your tmp directory.

When you install a new sccKit, it's more than just copying the binaries over. There's a new FGPA bitstream and beginning with 1.4.1 the SCC Linux is 2.6.38 rather than 2.6.16.  I dont think the new SCC Linux makes a difference .. I can "sccReset -g" on marc101 and still see sccDump work correctly.

But the new bitstream might. Running an sccDump under your tmp directory possibly can be made to work, but it is a non-standard configuration that we have not tested. Do you want us to upgrade your system to 1.4.1.3 officially? I'm nearly certain sccDump will work correctly then.

Are you doing some baremetal work? I have not yet seen the ETI FW work for an sccKit > 1.3.0 (although I think it will soon). How are you doing baremetal?

Your offical sccKit (currently installed) is 1.4.0 with eMAC enabled, which is a known unstable configuration. Have you noticed any instability?

http://marcbug.scc-dc.com/bugzilla3/show_bug.cgi?id=264

If you have and you want to retain 1.4.0, we can disable eMAC for you.

Switching between sccKit versions is not difficult but it does require root privilege.

Do you want us to upgrade your system to 1.4.1.3 officially? I'm nearly certain sccDump will work correctly then.

Yes, please upgrade marc019 to the latest sccKit.

Are you doing some baremetal work? I have not yet seen the ETI FW work for an sccKit > 1.3.0 (although I think it will soon). How are you doing baremetal?

I am doing baremetal, but I've built up my own framework for it.  I've made a printf() function that writes to a circular buffer in shared memory.  This buffer is polled periodically by miketerm, a program running on the MCPC which prints out whatever it finds there.  So I have one-way communication from the SCC to the MCPC, but do not yet have a way to send characters the other way.

Your offical sccKit (currently installed) is 1.4.0 with eMAC enabled, which is a known unstable configuration. Have you noticed any instability?

http://marcbug.scc-dc.com/bugzilla3/show_bug.cgi?id=264

I have noticed the instability described in that bugzilla when playing with SCC Linux, but it does not seem to affect the work I'm doing on baremetal.

So if you want to stick with miketerm, try the command `sccDump -d 0 0x1ec000000 32` and let me know what your output is.  I get:

 

[mziwisky@marc019 1.4.1/]$ bin/sccDump -d 0 0x1ec000000 32

INFO: Packet tracing is disabled...
INFO: Initializing System Interface (SCEMI setup)....
INFO: Successfully connected to PCIe driver...
INFO: Welcome to sccDump 1.4.1 (build date Jun 28 2011 - 16:02:28)...
INFO: --------------------------------------------------

 

Memory access out of range. Limit = 100000000 hex. Please reduce start address.
--------------------------------------------------

 

Hmm, it works with my copy of the 1.4.1 release. The command is supposed to use the "memorySize=<N>" setting in "/opt/sccKit/systemSettings.ini"... Could you please double check that configuration value? <N> should be 8 for a Rocky Lake platform...

All,

  ETI has updated the SCC framework to work with sccKit 1.4.0. See this post for details:

http://communities.intel.com/message/136837#136837

Michael Riepen wrote:

 

Could you please double check that configuration value? <N> should be 8 for a Rocky Lake platform...

Yep, memorySize=8 on my marc machine (marc019).  The installed sccDump 1.4.0 works fine, just not the 1.4.1 binary I put in my home directory.

We installed 1.4.1.3 on marc019 and sccDump I think is working correctly now. MichaelR, I think Mike was using his 1.4.1.2 sccDump with a 1.4.0 bitstream. Could that have caused trouble?

tekubasx@marc019:/opt/sccKit$ sccDump -d 0 0x1ec000000 32
INFO: Packet tracing is disabled...
INFO: Initializing System Interface (SCEMI setup)....
INFO: Successfully connected to PCIe driver...
INFO: Welcome to sccDump 1.4.1 (build date Jun 28 2011 - 16:02:28)...
INFO:  Contacting SystemIF to read memory. Please be patient ...
INFO:  done System Read.
--------------------------------------------------
  Reading on PERIW of Tile x=0, y=0
  startAddress = 1ec000000 hex (8254390272 dec)
  stopAddress  = 1ec00001f hex
  Requested/Displayed length: 32/32 bytes
--------------------------------------------------
** 8 bits alignment
--------------------------------------------------
00000001ec000000 | 00 00 00 00 00 00 00 00  | ........
00000001ec000008 | 00 00 00 00 00 00 00 00  | ........
00000001ec000010 | 00 00 00 00 00 00 00 00  | ........
00000001ec000018 | 00 00 00 00 00 00 00 00  | ........
tekubasx@marc019:/opt/sccKit$ which sccDump
/opt/sccKit/1.4.1.3/bin/sccDump
tekubasx@marc019:/opt/sccKit$

Ted Kubaska wrote:

 

We installed 1.4.1.3 on marc019 and sccDump I think is working correctly now.

Confirmed -- sccDump is working well.  Thanks for the upgrade, Ted.

Unfortunately, now sccWrite has an issue -- it's only allowing writes to 128-bit boundaries, not 64-bit boundaries.

[mziwisky@marc019 ~/]$ sccWrite -d 0 0x1ec000000 0xdeadbeef
INFO: Welcome to sccWrite 1.4.1 (build date Jun 28 2011 - 16:03:11)...
INFO: Wrote 0x00000000deadbeef to address 0x1ec000000 in DDR3 memory (MC of Tile 0x00)...
[mziwisky@marc019 ~/]$ sccWrite -d 0 0x1ec000008 0xdeadbeef
ERROR: The given address 0x1ec000008 is not 64 bit aligned!
Try again with 64 bit aligned address (e.g. 0x1ec000000)!

 

Usage: sccWrite [option]

 

Options:
  -h or --help: Print this message and exit...
  -d or --ddr3 <route> <64 bit aligned address> <value>: Write 64 bit to memory controller...
  -m or --mpb <route> <64 bit aligned address> <value>: Write 64 bit to message passing buffer...
  -c or --crb <route> <32 bit aligned address> <value>: Write 32 bit configuration register or LUT entry of tile <route>...
  -s or --sif <32 bit aligned address> <value>: Write 32 bit system interface FPGA register at address <address> (e.g. 0x8010)...

 

This application will write memory content (or memory mapped registers) to the SCC
Platform... It's possible to address the MCs, the MPBs or the CRBs...
Access is always 32 bit. Addresses also need to be 32-bit aligned and will be truncated otherwise... If you need
to write smaller chunks, you need to perform read-modify-write. This limitation may disappear in future versions...

Yes, I know ... this is Bug 304

http://marcbug.scc-dc.com/bugzilla3/show_bug.cgi?id=304