Ensure we can read out link status from the CTP6 FE at Chamberlin

[ekfriis]

You need to:

1. Compile the softipbus TCP server for Petalinux. See the README here [1] for details.
2. Upload the softipbus-forward server to /tmp on the CTP6 backend. Get the appropriate IP address and ssh password (user is root) from Jes.
3. SSH and run /tmp/soft-ipbus on the BE (leave it running)
4. Compile ctp6_fe_uart_ipbus and upload it (make upload in its directory)
5. Use ctp6commander [2] CLI to check the link status
6. Document these instructions in the README.md

[1] https://svnweb.cern.ch/trac/cactus/browser/trunk/cactuscore/softipbus/README.md
[2] https://github.com/uwcms/ctp6commander

[ekfriis]

Jes is working on getting the JTAG XMD going for step 4, the IP address to ssh to BE is ssh root@192.168.1.31

[nwoods]

I must be missing something obvious here -- the first step says to compile with make but... compile what? Where? It looks like the cactuscore-uhal packages are already installed by Yum, but I can't find anything on Ayinger that looks like TCP or SoftIPBus, so I don't even know where to find the makefile.

[nwoods]

Also, how do I get the Xilinx Petalinux SDK? AFAIK it's not installed on Ayinger.

[ekfriis]

You want to run make in the softipbus package, which is on SVN

svn co svn+ssh://svn.cern.ch/reps/cactus/trunk/cactuscore/softipbus$HOME/trigger_code/softipbus

Check out environment.sh in cms-calo-layer1 for setting up the petalinux
SDK.

Evan

On Wed, Oct 2, 2013 at 11:30 PM, nwoods notifications@github.com wrote:

Also, how do I get the Xilinx Petalinux SDK? AFAIK it's not installed on
Ayinger.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-25578767
.

[nwoods]

Any time I try to scp onto or off of the CTP6 is fails with the message

sh: scp: Input/output error

I'll bug Jes about it after my afternoon class, but if you have any ideas in the mean time I'd love to hear them.

Nate

[ekfriis]

Can you ssh into it? Are you scp into /tmp?

On Thu, Oct 3, 2013 at 7:30 PM, nwoods notifications@github.com wrote:

Any time I try to scp onto or off of the CTP6 is fails with the message

sh: scp: Input/output error

I'll bug Jes about it after my afternoon class, but if you have any ideas
in the mean time I'd love to hear them.

Nate

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-25640844
.

[nwoods]

ssh works fine. I can't scp into /tmp or into ~

[ekfriis]

If you ssh in, can you "touch /tmp/test_creation"

On Thu, Oct 3, 2013 at 7:39 PM, nwoods notifications@github.com wrote:

ssh works fine. I can't scp into /tmp or into ~

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-25641529
.

[nwoods]

Yep, already tried that (it works)... I probably need to ask Jes.
On Oct 3, 2013 12:42 PM, "Evan K. Friis" notifications@github.com wrote:

If you ssh in, can you "touch /tmp/test_creation"

On Thu, Oct 3, 2013 at 7:39 PM, nwoods notifications@github.com wrote:

ssh works fine. I can't scp into /tmp or into ~

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25641529>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-25641848
.

[nwoods]

So fun story: the CTP6 apparently committed circuit board seppuku and corrupted its own root directory. Jes is reflashing Petalinux and with any luck we'll be back in business in a few minutes.

We should probably look into this carefully, though. Jes says that there's almost nothing a person could have done to cause this, so it was probably a board error and we had better make sure it's not going to do that too often.

[nwoods]

I got softipbus and softipbus-forward successfully uploaded onto the CTP6, but neither one will run. I get the following errors (in which I am replacing unreadable characters with 'X'):

~ # /tmp/softipbus
/tmp/softipbus: line 1: syntax error: unexpected word (expecting ")")
~ # /tmp/softipbus-forward 
/tmp/softipbus-forward: line 1: syntax error: unexpected end of file (expecting ")")

Running make with $PETALINUX defined causes the compiler to exit prematurely and tell me that I can only run make unittest (which does not fix the problem), so I tried again without it, uploaded it, and got the same result but with a few extra error messages:

~ # /tmp/softipbus
/tmp/softipbus: line 1: syntax error: unexpected word (expecting ")")
~ # /tmp/softipbus-forward 
/tmp/softipbus-forward: line 1: can't create X��: Read-only file system
/tmp/softipbus-forward: line 1: �XELFXXX����: not found
/tmp/softipbus-forward: line 1: syntax error: unexpected end of file (expecting ")")

[ekfriis]

For it to work on the CTP6, PETALINUX definitely has to be set. The CTP6 has a different architecture than ayinger/your PC so you need to use the special GCC binary from petalinux to "cross-compile" it correctly - otherwise you will expect errors like your second one. The reason for the "error" reported at the end is because since you have cross-compiled to the MB arch you can't run the binaries on your local PC to test them. I've fixed the Makefile so it doesn't cause an error, just an informative message. Run "svn update" in your softipbus directory to get it.

It seems that you are still suffering from the same problem (wrong target architecture [1]), even with $PETALINUX set. I think this is because @jtikalsky has changed the PETALINUX distribution here [2] to the ZYNQ chip. Jes, can you have a look? The $CC that I pick up from include user-commons.mk has changed from "microblazeel-xilinx-linux-gnu-gcc" to "arm-xilinx-linux-gnueabi-gcc".

[1] http://gaoithe.livejournal.com/33519.html
[2] /afs/hep.wisc.edu/home/uwhepfpga/petalinux-v12.12-final-full/software/petalinux-dist/.config

[nwoods]

OK, I'm working on UCT energy sum rates and efficiencies in the hope of having them for the JETMET talk on Tuesday. @jtikalsky, could you let me know when you figure this out? Thanks!

[jtikalsky]

@nwoods, @ekfriis has the right idea, I'm betting. You cannot use this petalinux installation for your work at this time, as it is being used for a build for the ZC702 board. You will need to set up a separate environment to do your builds in, or risk this problem recurring frequently even if I do switch modes back for you right now.

@ekfriis, I believe you did something like this at CERN for yourself when you were developing softipbus initially. Can you give a list of steps you had to do to get that working? I know what's required for a full ground-up build, but a simplified procedure to get to the point of cross-compilation may be more useful here.

@nwoods, for PetaLinux licensing, if you are on the Chamberlin network you can set the environment variable

XILINXD_LICENSE_FILE='2100@dawn.physics.wisc.edu'

which will take care of everything.

[jtikalsky]

So testing Zen mode is interesting

test

testing oranges and pies.
self post.

[ekfriis]

Hi @jtikalsky,

I found an old makefile where I manually pick out the GCC binary from the petalinux folder:

https://github.com/uwcms/soft-ipbus/blob/68ddc9bd2b89c181c460b61df39902bf3b2e7335/Makefile.petalinux#L14

Hopefully @nwoods will find it useful. In any case, can we just have a separate PETALINUX directory with the CTP6? I think this would be easiest.

[nwoods]

I got ipbus and ipbus-forward running on the CTP6 (I think -- they both just sit silently until killed), and I was able, after some effort, to get ctp6_fe_uart_ipbus compiled. At the end of the compilation, it gives an error, saying that the CTP cable is not connected:

echo "connect mb mdm; dow ctp6_fe_uart_ipbus.elf;" | xmd
Xilinx Microprocessor Debugger (XMD) Engine
Xilinx EDK 14.4 Build EDK_P.49d
Copyright (c) 1995-2012 Xilinx, Inc.  All rights reserved.

XMD% 
XMD% ERROR: Failed to Open JTAG Cable
    Cable target is not connected to the host

XMD% 

Since I can ssh into the CTP6, this seems unlikely. Any idea what this could be?

[ekfriis]

Are you on Ayinger?
The SSH connection goes over the ethernet netwrok, and is different than
the JTAG - the JTAG is a USB dongle thing which plugs directly into the
board and lets you do fancy HW stuff.

Look and see if a red JTAG programmer is plugged into Ayinger and into the
CTP6. If not ask Jes/Tom to show you how to connect. Sometime the driver
gets roached/wedged as Tom/Jes would say, supposedly

sudo chmod a+rw /dev/windrvr6

might fix it. If not you need to ask Jes, she knows how to do it. We
don't understand why it stops working sometimes.

On Wed, Oct 9, 2013 at 12:25 AM, nwoods notifications@github.com wrote:

I got ipbus and ipbus-forward running on the CTP6 (I think -- they both
just sit silently until killed), and I was able, after some effort, to get
ctp6_fe_uart_ipbus compiled. At the end of the compilation, it gives an
error, saying that the CTP cable is not connected:

echo "connect mb mdm; dow ctp6_fe_uart_ipbus.elf;" | xmd
Xilinx Microprocessor Debugger (XMD) Engine
Xilinx EDK 14.4 Build EDK_P.49d
Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.

XMD%
XMD% ERROR: Failed to Open JTAG Cable
Cable target is not connected to the host

XMD%

Since I can ssh into the CTP6, this seems unlikely. Any idea what this
could be?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-25933051
.

[nwoods]

I'm about 80% sure that I was just able to compile ctp6_fe_uart_ipbus and upload it. The 20% uncertainty comes from the fact that I actually built and uploaded something called payload.elf, but as far as I could tell from the makefile, this is the correct thing.

I can't finish putting all the pieces together now, though, because the card's TCP connection seems to be down. I told @jtikalsky and she said she'd look at it when she got a chance. Jes, can you email me or comment here when you know what's up? Thanks!

[ekfriis]

Yes, take back your 20% - before each binary (.elf) had a different name, I
made them all build to payload.elf now to make transporting xmd commands a
bit easier.

On Wed, Oct 9, 2013 at 6:41 PM, nwoods notifications@github.com wrote:

I'm about 80% sure that I was just able to compile ctp6_fe_uart_ipbus and
upload it. The 20% uncertainty comes from the fact that I actually built
and uploaded something called payload.elf, but as far as I could tell
from the makefile, this is the correct thing.

I can't finish putting all the pieces together now, though, because the
card's TCP connection seems to be down. I told @jtikalskyhttps://github.com/jtikalskyand she said she'd look at it when she got a chance. Jes, can you email me
or comment here when you know what's up? Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-25986923
.

[nwoods]

Progress: ctp6_fe_uart_ipbus/payload.elf will make upload without
complaining, and both softipbus and softipbus-forward will run on the
CTP6 without giving error messages.

I'm close to get ctp6commander working. I can't source the custom version
of Python because Ayinger can't see cvmfs. Jes tells me that we might be
able to get cvmfs on Ayinger but if there's another way to get it "without
serious trouble", that would be preferable. @ekfriis, do you know if that's
possible?

On Wed, Oct 9, 2013 at 11:56 AM, Evan K. Friis notifications@github.comwrote:

Yes, take back your 20% - before each binary (.elf) had a different name,
I
made them all build to payload.elf now to make transporting xmd commands a
bit easier.

On Wed, Oct 9, 2013 at 6:41 PM, nwoods notifications@github.com wrote:

I'm about 80% sure that I was just able to compile ctp6_fe_uart_ipbus
and
upload it. The 20% uncertainty comes from the fact that I actually built
and uploaded something called payload.elf, but as far as I could tell
from the makefile, this is the correct thing.

I can't finish putting all the pieces together now, though, because the
card's TCP connection seems to be down. I told @jtikalsky<
https://github.com/jtikalsky>and she said she'd look at it when she got a
chance. Jes, can you email me
or comment here when you know what's up? Thanks!

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25986923>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-25988292
.

[jtikalsky]

What is special about this version?

On 10/10/2013 04:47 PM, nwoods wrote:

Progress: ctp6_fe_uart_ipbus/payload.elf will make upload without
complaining, and both softipbus and softipbus-forward will run on the
CTP6 without giving error messages.

I'm close to get ctp6commander working. I can't source the custom version
of Python because Ayinger can't see cvmfs. Jes tells me that we might be
able to get cvmfs on Ayinger but if there's another way to get it "without
serious trouble", that would be preferable. @ekfriis, do you know if that's
possible?

On Wed, Oct 9, 2013 at 11:56 AM, Evan K. Friis
notifications@github.comwrote:

Yes, take back your 20% - before each binary (.elf) had a different
name,
I
made them all build to payload.elf now to make transporting xmd
commands a
bit easier.

On Wed, Oct 9, 2013 at 6:41 PM, nwoods notifications@github.com wrote:

I'm about 80% sure that I was just able to compile ctp6_fe_uart_ipbus
and
upload it. The 20% uncertainty comes from the fact that I actually
built
and uploaded something called payload.elf, but as far as I could tell
from the makefile, this is the correct thing.

I can't finish putting all the pieces together now, though, because
the
card's TCP connection seems to be down. I told @jtikalsky<
https://github.com/jtikalsky>and she said she'd look at it when she
got a
chance. Jes, can you email me
or comment here when you know what's up? Thanks!

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25986923>
.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/4#issuecomment-25988292

.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[nwoods]

I have no idea, but it seems that it's the only one that will run
https://github.com/uwcms/ctp6commander correctly. (See the readme at that
link).

On Thu, Oct 10, 2013 at 4:48 PM, jtikalsky notifications@github.com wrote:

What is special about this version?

On 10/10/2013 04:47 PM, nwoods wrote:

Progress: ctp6_fe_uart_ipbus/payload.elf will make upload without
complaining, and both softipbus and softipbus-forward will run on the
CTP6 without giving error messages.

I'm close to get ctp6commander working. I can't source the custom version
of Python because Ayinger can't see cvmfs. Jes tells me that we might be
able to get cvmfs on Ayinger but if there's another way to get it
"without
serious trouble", that would be preferable. @ekfriis, do you know if
that's
possible?

On Wed, Oct 9, 2013 at 11:56 AM, Evan K. Friis
notifications@github.comwrote:

Yes, take back your 20% - before each binary (.elf) had a different
name,
I
made them all build to payload.elf now to make transporting xmd
commands a
bit easier.

On Wed, Oct 9, 2013 at 6:41 PM, nwoods notifications@github.com
wrote:

I'm about 80% sure that I was just able to compile ctp6_fe_uart_ipbus
and
upload it. The 20% uncertainty comes from the fact that I actually
built
and uploaded something called payload.elf, but as far as I could tell
from the makefile, this is the correct thing.

I can't finish putting all the pieces together now, though, because
the
card's TCP connection seems to be down. I told @jtikalsky<
https://github.com/jtikalsky>and she said she'd look at it when she
got a
chance. Jes, can you email me
or comment here when you know what's up? Thanks!

—
Reply to this email directly or view it on GitHub<

https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25986923>

.

—
Reply to this email directly or view it on
GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25988292>

.

—
Reply to this email directly or view it on GitHub
<#4 (comment)
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26094744
.

[ekfriis]

The default version of python is 2.4, which was not compatible with the
dependencies, which is why I used the CVMFS version.

However, there is a 2.6 version installed on ayinger.

I just pushed ac8ffe559698ba5960f93b165bd0d06911ac3b26, which make
setup_venv.sh work out of the box on ayinger (and have removed the obsolete
CVMFS instruction from the README).

BTW Nate, the code in ctp6commander is a not-completely-tested refactoring
of the original script here [1] used for the integration test. It should
work, but if you have troubles please try the softipbus/scripts version as
well.

[1]
https://svnweb.cern.ch/trac/cactus/browser/trunk/cactuscore/softipbus/scripts/ctp6

On Thu, Oct 10, 2013 at 11:51 PM, nwoods notifications@github.com wrote:

I have no idea, but it seems that it's the only one that will run
https://github.com/uwcms/ctp6commander correctly. (See the readme at that
link).

On Thu, Oct 10, 2013 at 4:48 PM, jtikalsky notifications@github.com
wrote:

What is special about this version?

On 10/10/2013 04:47 PM, nwoods wrote:

Progress: ctp6_fe_uart_ipbus/payload.elf will make upload without
complaining, and both softipbus and softipbus-forward will run on
the
CTP6 without giving error messages.

I'm close to get ctp6commander working. I can't source the custom
version
of Python because Ayinger can't see cvmfs. Jes tells me that we might
be
able to get cvmfs on Ayinger but if there's another way to get it
"without
serious trouble", that would be preferable. @ekfriis, do you know if
that's
possible?

On Wed, Oct 9, 2013 at 11:56 AM, Evan K. Friis
notifications@github.comwrote:

Yes, take back your 20% - before each binary (.elf) had a different
name,
I
made them all build to payload.elf now to make transporting xmd
commands a
bit easier.

On Wed, Oct 9, 2013 at 6:41 PM, nwoods notifications@github.com
wrote:

I'm about 80% sure that I was just able to compile
ctp6_fe_uart_ipbus
and
upload it. The 20% uncertainty comes from the fact that I actually
built
and uploaded something called payload.elf, but as far as I could
tell
from the makefile, this is the correct thing.

I can't finish putting all the pieces together now, though,
because
the
card's TCP connection seems to be down. I told @jtikalsky<
https://github.com/jtikalsky>and she said she'd look at it when she
got a
chance. Jes, can you email me
or comment here when you know what's up? Thanks!

—
Reply to this email directly or view it on GitHub<

https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25986923>

.

—
Reply to this email directly or view it on
GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25988292>

.

—
Reply to this email directly or view it on GitHub
<
#4 (comment)
.

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-26094744>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26094887
.

[nwoods]

Since Evan told me how to make xmd talk to the correct FPGA it's not
crashing any more, but nothing I try to do with xmd is working, saying that
the processor is stalled. Here's the command and error message:

XMD% connect mb mdm -debugdevice deviceNr 2

JTAG chain configuration
--------------------------------------------------
Device   ID Code        IR Length    Part Name
 1       042a2093          10        XC6VHX250T
 2       442a8093          10        XC6VHX380T

MicroBlaze Processor Configuration :
-------------------------------------
Version............................8.40.b
Optimization.......................Performance
Interconnect.......................AXI-LE
MMU Type...........................No_MMU
No of PC Breakpoints...............2
No of Read Addr/Data Watchpoints...0
No of Write Addr/Data Watchpoints..0
Instruction Cache Support..........on
Instruction Cache Base Address.....0xf0000000
Instruction Cache High Address.....0xffffffff
Data Cache Support.................on
Data Cache Base Address............0xf0000000
Data Cache High Address............0xffffffff
Exceptions  Support................on
FPU  Support.......................off
Hard Divider Support...............off
Hard Multiplier Support............on - (Mul32)
Barrel Shifter Support.............off
MSR clr/set Instruction Support....on
Compare Instruction Support........on
Data Cache Write-back Support......off
Fault Tolerance Support............off
Stack Protection Support...........off
Processor Could not be STOPPED - MicroBlaze Pipeline Stalled on a Blocking
Instruction or Invalid Bus Access
Stalled PC: 0x3ffffffc
Try Resetting the Processor to Continue..Processor is stalled at address
0x2d2d0a3e. UNABLE to STOP MicroBlaze
 Debug Operation requires Processor in STOP State.
1. Try to reset the Processor and check if the Processor is Stopped
2. Check your System Design for Correctness

Connected to "mb" target. id = 0
Starting GDB server for "mb" target (id = 0) at TCP port no 1234

This may be something obvious that I don't know because I'm still new to
this. Jes, will you be around after lunch to take a look?

On Fri, Oct 11, 2013 at 2:52 AM, Evan K. Friis notifications@github.comwrote:

The default version of python is 2.4, which was not compatible with the
dependencies, which is why I used the CVMFS version.

However, there is a 2.6 version installed on ayinger.

I just pushed ac8ffe559698ba5960f93b165bd0d06911ac3b26, which make
setup_venv.sh work out of the box on ayinger (and have removed the
obsolete
CVMFS instruction from the README).

BTW Nate, the code in ctp6commander is a not-completely-tested refactoring
of the original script here [1] used for the integration test. It should
work, but if you have troubles please try the softipbus/scripts version as
well.

[1]

https://svnweb.cern.ch/trac/cactus/browser/trunk/cactuscore/softipbus/scripts/ctp6

On Thu, Oct 10, 2013 at 11:51 PM, nwoods notifications@github.com
wrote:

I have no idea, but it seems that it's the only one that will run
https://github.com/uwcms/ctp6commander correctly. (See the readme at
that
link).

On Thu, Oct 10, 2013 at 4:48 PM, jtikalsky notifications@github.com
wrote:

What is special about this version?

On 10/10/2013 04:47 PM, nwoods wrote:

Progress: ctp6_fe_uart_ipbus/payload.elf will make upload
without
complaining, and both softipbus and softipbus-forward will run
on
the
CTP6 without giving error messages.

I'm close to get ctp6commander working. I can't source the custom
version
of Python because Ayinger can't see cvmfs. Jes tells me that we
might
be
able to get cvmfs on Ayinger but if there's another way to get it
"without
serious trouble", that would be preferable. @ekfriis, do you know if
that's
possible?

On Wed, Oct 9, 2013 at 11:56 AM, Evan K. Friis
notifications@github.comwrote:

Yes, take back your 20% - before each binary (.elf) had a
different
name,
I
made them all build to payload.elf now to make transporting xmd
commands a
bit easier.

On Wed, Oct 9, 2013 at 6:41 PM, nwoods notifications@github.com
wrote:

I'm about 80% sure that I was just able to compile
ctp6_fe_uart_ipbus
and
upload it. The 20% uncertainty comes from the fact that I
actually
built
and uploaded something called payload.elf, but as far as I could
tell
from the makefile, this is the correct thing.

I can't finish putting all the pieces together now, though,
because
the
card's TCP connection seems to be down. I told @jtikalsky<
https://github.com/jtikalsky>and she said she'd look at it when
she
got a
chance. Jes, can you email me
or comment here when you know what's up? Thanks!

—
Reply to this email directly or view it on GitHub<

https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25986923>

.

—
Reply to this email directly or view it on
GitHub<

https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25988292>

.

—
Reply to this email directly or view it on GitHub
<
#4 (comment)
.

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-26094744>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-26094887>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26120167
.

[ekfriis]

Try typing "rst" to reset it. Then "dow" the program again, then "run" it

On Fri, Oct 11, 2013 at 7:02 PM, nwoods notifications@github.com wrote:

Since Evan told me how to make xmd talk to the correct FPGA it's not
crashing any more, but nothing I try to do with xmd is working, saying
that
the processor is stalled. Here's the command and error message:

XMD% connect mb mdm -debugdevice deviceNr 2

JTAG chain configuration
--------------------------------------------------
Device ID Code IR Length Part Name
1 042a2093 10 XC6VHX250T
2 442a8093 10 XC6VHX380T

MicroBlaze Processor Configuration :
-------------------------------------
Version............................8.40.b
Optimization.......................Performance
Interconnect.......................AXI-LE
MMU Type...........................No_MMU
No of PC Breakpoints...............2
No of Read Addr/Data Watchpoints...0
No of Write Addr/Data Watchpoints..0
Instruction Cache Support..........on
Instruction Cache Base Address.....0xf0000000
Instruction Cache High Address.....0xffffffff
Data Cache Support.................on
Data Cache Base Address............0xf0000000
Data Cache High Address............0xffffffff
Exceptions Support................on
FPU Support.......................off
Hard Divider Support...............off
Hard Multiplier Support............on - (Mul32)
Barrel Shifter Support.............off
MSR clr/set Instruction Support....on
Compare Instruction Support........on
Data Cache Write-back Support......off
Fault Tolerance Support............off
Stack Protection Support...........off
Processor Could not be STOPPED - MicroBlaze Pipeline Stalled on a Blocking
Instruction or Invalid Bus Access
Stalled PC: 0x3ffffffc
Try Resetting the Processor to Continue..Processor is stalled at address
0x2d2d0a3e. UNABLE to STOP MicroBlaze
Debug Operation requires Processor in STOP State.
1. Try to reset the Processor and check if the Processor is Stopped
2. Check your System Design for Correctness

Connected to "mb" target. id = 0
Starting GDB server for "mb" target (id = 0) at TCP port no 1234

This may be something obvious that I don't know because I'm still new to
this. Jes, will you be around after lunch to take a look?

On Fri, Oct 11, 2013 at 2:52 AM, Evan K. Friis notifications@github.comwrote:

The default version of python is 2.4, which was not compatible with the
dependencies, which is why I used the CVMFS version.

However, there is a 2.6 version installed on ayinger.

I just pushed ac8ffe559698ba5960f93b165bd0d06911ac3b26, which make
setup_venv.sh work out of the box on ayinger (and have removed the
obsolete
CVMFS instruction from the README).

BTW Nate, the code in ctp6commander is a not-completely-tested
refactoring
of the original script here [1] used for the integration test. It should
work, but if you have troubles please try the softipbus/scripts version
as
well.

[1]

https://svnweb.cern.ch/trac/cactus/browser/trunk/cactuscore/softipbus/scripts/ctp6

On Thu, Oct 10, 2013 at 11:51 PM, nwoods notifications@github.com
wrote:

I have no idea, but it seems that it's the only one that will run
https://github.com/uwcms/ctp6commander correctly. (See the readme at
that
link).

On Thu, Oct 10, 2013 at 4:48 PM, jtikalsky notifications@github.com
wrote:

What is special about this version?

On 10/10/2013 04:47 PM, nwoods wrote:

Progress: ctp6_fe_uart_ipbus/payload.elf will make upload
without
complaining, and both softipbus and softipbus-forward will run
on
the
CTP6 without giving error messages.

I'm close to get ctp6commander working. I can't source the custom
version
of Python because Ayinger can't see cvmfs. Jes tells me that we
might
be
able to get cvmfs on Ayinger but if there's another way to get it
"without
serious trouble", that would be preferable. @ekfriis, do you know
if
that's
possible?

On Wed, Oct 9, 2013 at 11:56 AM, Evan K. Friis
notifications@github.comwrote:

Yes, take back your 20% - before each binary (.elf) had a
different
name,
I
made them all build to payload.elf now to make transporting xmd
commands a
bit easier.

On Wed, Oct 9, 2013 at 6:41 PM, nwoods notifications@github.com

wrote:

I'm about 80% sure that I was just able to compile
ctp6_fe_uart_ipbus
and
upload it. The 20% uncertainty comes from the fact that I
actually
built
and uploaded something called payload.elf, but as far as I
could
tell
from the makefile, this is the correct thing.

I can't finish putting all the pieces together now, though,
because
the
card's TCP connection seems to be down. I told @jtikalsky<
https://github.com/jtikalsky>and she said she'd look at it when
she
got a
chance. Jes, can you email me
or comment here when you know what's up? Thanks!

—
Reply to this email directly or view it on GitHub<

https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25986923>

.

—
Reply to this email directly or view it on
GitHub<

https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-25988292>

.

—
Reply to this email directly or view it on GitHub
<

#4 (comment)

.

—
Reply to this email directly or view it on GitHub<

https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-26094744>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-26094887>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-26120167>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26153511
.

[nwoods]

rst worked, and it looks like it's downloading and running successfully. I upgraded ctp6commander but now when I ./setup_venv.sh I get the following (presumably python version-related?) error:

nwoods@ayinger /afs/hep.wisc.edu/cms/nwoods/ctp6commander  master$ ./setup_venv.sh --upgrade
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1294k  100 1294k    0     0  1984k      0 --:--:-- --:--:-- --:--:-- 3052k
Using real prefix '/usr'
New python executable in env/bin/python2.6
Traceback (most recent call last):
  File "virtualenv-1.10.1/virtualenv.py", line 2308, in <module>
    main()
  File "virtualenv-1.10.1/virtualenv.py", line 821, in main
    symlink=options.symlink)
  File "virtualenv-1.10.1/virtualenv.py", line 956, in create_environment
    site_packages=site_packages, clear=clear, symlink=symlink))
  File "virtualenv-1.10.1/virtualenv.py", line 1247, in install_python
    shutil.copyfile(executable, py_executable)
  File "/usr/lib64/python2.6/shutil.py", line 48, in copyfile
    raise Error("`%s` and `%s` are the same file" % (src, dst))
shutil.Error: `/afs/hep.wisc.edu/cms/nwoods/ctp6commander/env/bin/python2.6` and `env/bin/python2.6` are the same file
Requirement already satisfied (use --upgrade to upgrade): argparse in ./env/lib/python2.6/site-packages
Cleaning up...
Requirement already satisfied (use --upgrade to upgrade): flask in ./env/lib/python2.6/site-packages
Requirement already satisfied (use --upgrade to upgrade): Werkzeug>=0.7 in ./env/lib/python2.6/site-packages (from flask)
Requirement already satisfied (use --upgrade to upgrade): Jinja2>=2.4 in ./env/lib/python2.6/site-packages (from flask)
Requirement already satisfied (use --upgrade to upgrade): itsdangerous>=0.21 in ./env/lib/python2.6/site-packages (from flask)
Requirement already satisfied (use --upgrade to upgrade): markupsafe in ./env/lib/python2.6/site-packages (from Jinja2>=2.4->flask)
Cleaning up...
Requirement already satisfied (use --upgrade to upgrade): termcolor in ./env/lib/python2.6/site-packages
Cleaning up...

[nwoods]

A few questions on Mathias's behalf:

Can you explain the difference between softipbus and softipbus-forward? I've used softipbus-forward, and I've been scp'ing softipbus to the card every time I recompile it, but I don't actually know when I'm supposed to use it. From the names, it sounds like both need to be running for things to work, but that's not possible.

Also, if we want to include these in the petalinux flash, how do we do that?

[ekfriis]

explain the difference between softipbus and softipbus-forward

softipbus and softipbus-forward are separate programs.

softipbus runs a TCP server which reads out the local memory - so this is what needs to run to read memory from the backend, if we want to. We have not needed this as a use-case to date. Sidebar: once we get the ZYNQ chip, we will only need this program, since the Mathias will do magic to make the front end appear as back-end memory.

softipbus-forward runs a TCP server (on the backend), and then forwards the packets across the UART, to the front end. The UART devices forwarded over are defined in the softipbus makefile [1] - the current defaults should be correct.

Note that you also need to run the standalone program (ctp6_fe_uart_ipbus) on the front end [2], which reads the data sent on the UART, parses it, and sends a response back along the UART. The backend then sends this back over TCP.

if we want to include these in the petalinux flash, how do we do that?

ask Jes. at some point she added it, but I'm not sure what happened to that.

[1] https://svnweb.cern.ch/trac/cactus/browser/trunk/cactuscore/softipbus/Makefile#L35
[2] https://github.com/uwcms/cms-calo-layer1/tree/master/ctp6_fe_uart_ipbus

[nwoods]

Are you sure that makefile is actually correct? I changed it to not look
like that and I haven't pushed my changes upstream yet.

On Tue, Oct 15, 2013 at 3:45 PM, Evan K. Friis notifications@github.comwrote:

explain the difference between softipbus and softipbus-forward

softipbus and softipbus-forward are separate programs.

softipbus runs a TCP server which reads out the local memory - so this
is what needs to run to read memory from the backend, if we want to. We
have not needed this as a use-case to date. Sidebar: once we get the ZYNQ
chip, we will only need this program, since the Mathias will do magic to
make the front end appear as back-end memory.

softipbus-forward runs a TCP server (on the backend), and then forwards
the packets across the UART, to the front end. The UART devices forwarded
over are defined in the softipbus makefile [1] - the current defaults
should be correct.

Note that you also need to run the standalone program (ctp6_fe_uart_ipbus)
on the front end [2], which reads the data sent on the UART, parses it, and
sends a response back along the UART. The backend then sends this back over
TCP.

if we want to include these in the petalinux flash, how do we do that?

ask Jes. at some point she added it, but I'm not sure what happened to
that.

[1]
https://svnweb.cern.ch/trac/cactus/browser/trunk/cactuscore/softipbus/Makefile#L35
[2]
https://github.com/uwcms/cms-calo-layer1/tree/master/ctp6_fe_uart_ipbus

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26370587
.

[nwoods]

Mathias guessed that the problem we were having was due to a bad FPGA configuration and reflashed with the newest available. Unfortunately, around the same time he did that (but before, so we know the flash isn't responsible), JTAG mysteriously stopped working from Ayinger. The light on the JTAG box is green, so the box thinks it's connected, and it worked fine from Mathias's laptop, so the problem isn't on the card, so it must be an issue with Ayinger. We tried to find Jes to see if she could figure anything out, but she wasn't in. Any idea what sort of thing could cause this?

[nwoods]

We got JTAG working on Tapas's laptop (it still needs to be fixed on Ayinger), and tried to read the links. Now when we run read_uart and payload.elf, xmd now spams the error message

| DEBUG | Partial transaction

a few times a second. On the other hand, the stop command now actually stops it with no problems. cli.py fails in the same way it always did. softipbus-forward no longer produces an error message when we try to run cli.py.

[ekfriis]

@jtikalsky is the only one that knows the black art of fixing the JTAG, I asked her to document it in #23

If you are getting any partial transaction on the FE, that tells me you are getting something transmitted across the UART successfully. Can you try reducing the LOG_LEVEL to 2 (INFO only) and running again? It may be that it times out because writing the DEBUG output to the XMD console is too slow (the bane of debugging on these devices).

I don't get your comment about the Makefile [1], can you clarify?

If the system is not in a "clean" state, things can get wedged - i.e. if softipbus-forward is still waiting for a response it will never get. (Eventually we should add some type of timeout). Can you try:

1. stop softipbus-forward with Ctrl-C
2. stop,rst,run the FE using XMD
3. restart softipbus-forward
4. try cli.py again?

If it fails, please post the console output of each of the three elements.

[1] #4 (comment)

[ekfriis]

I got our cable working, I put the steps that I followed in #23

[ekfriis]

Hi @nwoods, can you make sure any changes you have made are commited and pull-requested, and then document the most-correct steps to date? Pam can try doing it at 904.

[nwoods]

I'm going to attempt to fix the blocking error in the FE code. Is the loop
in question in read_uart or in payload?

On Wed, Oct 16, 2013 at 8:46 AM, Evan K. Friis notifications@github.comwrote:

Hi @nwoods https://github.com/nwoods, can you make sure any changes you
have made are commited and pull-requested, and then document the
most-correct steps to date? Pam can try doing it at 904.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26418619
.

[ekfriis]

Which blocking error? And what is read_uart or payload? read_uart is an
XMD command - payload is the name of the generated file, right?

On Wed, Oct 16, 2013 at 6:21 PM, nwoods notifications@github.com wrote:

I'm going to attempt to fix the blocking error in the FE code. Is the loop
in question in read_uart or in payload?

On Wed, Oct 16, 2013 at 8:46 AM, Evan K. Friis notifications@github.comwrote:

Hi @nwoods https://github.com/nwoods, can you make sure any changes
you
have made are commited and pull-requested, and then document the
most-correct steps to date? Pam can try doing it at 904.

—
Reply to this email directly or view it on GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-26418619>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26433578
.

[nwoods]

Ah, that answers my question. I thought that read_uart was something that you wrote. By blocking error, I mean the (possible) problem that the FE software is getting stuck in a loop waiting for the end of a fake/broken/erroneous packet. Mathias said he talked to you about this?

[ekfriis]

Yes - but don't fix this now! The symptom of this is thing not being started correctly/one end crashing, which means you have to restart all the pieces [see this comment https://github.com//issues/4#issuecomment-26398597] before things will work again.

You should be able to make it work at least once (i.e. by getting everything going so no bad packets are sent) The fix on having a timeout in the loop is for long term stability. Do not try to add this feature until you figure out why the current code is broken - we know the whole chain worked in August.

[ekfriis]

(That being said, adding this feature will be an excellent improvement and a very good opportunity to get your hands dirty, but let's get it working first)

[nwoods]

With the most recent versions of everything, the link test fails with the message

nwoods@ayinger /afs/hep.wisc.edu/cms/nwoods/ctp6commander  master$ python cli.py status
Traceback (most recent call last):
  File "cli.py", line 167, in <module>
    commands[args.command](hw, args)
  File "cli.py", line 48, in do_status
    status_flags = api.status(hw, args.links)
  File "/afs/hep.wisc.edu/cms/nwoods/ctp6commander/api.py", line 156, in status
    hw.dispatch()
uhal._core.exception: 
I'm terribly sorry to have to tell you this, but it appears that there was an exception:
 * Exception type: uhal::exception::TcpConnectionFailure
 * Description: Exception class to handle the case where the TCP connection was refused or aborted.
 * Additional Information:
   > ASIO reported an error: Connection refused
 * Exception occured in the same thread as that in which it was caught (0x137dce50)
 * Exception constructed at time:              2013-10-16 12:39:22.113391
 * Exception's what() function called at time: 2013-10-16 12:39:22.113639

softipbus-forward says nothing, even though it's compiled with log level 3.

Meanwhile, when payload.elf is run, it gives the message

1970-01-01 00:00:00 | DEBUG | Setup interrupts okay
1970-01-01 00:00:00 | INFO  | Serving memory.
1970-01-01 00:01:44 | INFO  | Start size: 0
1970-01-01 00:00:16 | DEBUG | Partial transaction
1970-01-01 00:00:16 | DEBUG | Partial transaction
1970-01-01 00:00:16 | DEBUG | Partial transaction
[... forever]

It spams that partial transaction method forever regardless of whether or not softipbus is running.

[ekfriis]

softipbus-forward should say something with log-level three - please see if
you can figure out why it isn't.

On Wed, Oct 16, 2013 at 7:47 PM, nwoods notifications@github.com wrote:

With the most recent versions of everything, the link test fails with the
message

nwoods@ayinger /afs/hep.wisc.edu/cms/nwoods/ctp6commander master$ python cli.py status
Traceback (most recent call last):
File "cli.py", line 167, in
commands[args.command](hw, args)
File "cli.py", line 48, in do_status
status_flags = api.status(hw, args.links)
File "/afs/hep.wisc.edu/cms/nwoods/ctp6commander/api.py", line 156, in status
hw.dispatch()
uhal._core.exception:
I'm terribly sorry to have to tell you this, but it appears that there was an exception:

• Exception type: uhal::exception::TcpConnectionFailure
• Description: Exception class to handle the case where the TCP connection was refused or aborted.
• Additional Information:

  ASIO reported an error: Connection refused

• Exception occured in the same thread as that in which it was caught (0x137dce50)
• Exception constructed at time: 2013-10-16 12:39:22.113391
• Exception's what() function called at time: 2013-10-16 12:39:22.113639

softipbus-forward says nothing, even though it's compiled with log level
3.

Meanwhile, when payload.elf is run, it gives the message

1970-01-01 00:00:00 | DEBUG | Setup interrupts okay
1970-01-01 00:00:00 | INFO | Serving memory.
1970-01-01 00:01:44 | INFO | Start size: 0
1970-01-01 00:00:16 | DEBUG | Partial transaction
1970-01-01 00:00:16 | DEBUG | Partial transaction
1970-01-01 00:00:16 | DEBUG | Partial transaction
[... forever]

It spams that partial transaction method forever regardless of whether or
not softipbus is running.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26441187
.

[nwoods]

Looking at the Makefile for softipbus (which is the only thing in there I ever changed, IIRC), it looks like we need separate versions for 904 and Chamberlin, so unless you think my version will work properly there, I'm going to hold off on committing those changes for now.

[ekfriis]

That's fine, what you could do (just for completeness) is do copy paste the
output of svn diff in the softipbus.

On Wed, Oct 16, 2013 at 9:08 PM, nwoods notifications@github.com wrote:

Looking at the Makefile for softipbus (which is the only thing in there I
ever changed, IIRC), it looks like we need separate versions for 904 and
Chamberlin, so unless you think my version will work properly there, I'm
going to hold off on committing those changes for now.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26448032
.

[nwoods]

I'm not 100% sure, but there may be a cleaner fix to the python version issue contained in the file cactus/trunk/cactuscore/uhal/pycohal/MANIFEST.in

[ekfriis]

what python version issue?

[nwoods]

The 2.4 vs 2.6 issues, that had us bending over backwards to install new versions of python, set mysterious python path variables, etc.

[ekfriis]

Ah cool, please post another issue/PR with this. In any case, as long as
it works, don't worry too much about installing a good python, it will be
obviated when we upgrade to SLC6.

On Thu, Oct 17, 2013 at 7:43 PM, nwoods notifications@github.com wrote:

The 2.4 vs 2.6 issues, that had us bending over backwards to install new
versions of python, set mysterious python path variables, etc.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26530926
.

[jtikalsky]

Apologies, I've been out of the office most of the week.

0.0.0.0 is not an IP you can connect to. You need to use something
else. Perhaps you meant 127.0.0.1?

On 10/14/2013 05:04 PM, nwoods wrote:

Maybe the -vvv option on ssh gets us somewhere. When I did that, the
error message became

|~ # /tmp/softipbus-forward
debug1: Connection to port 60002 forwarding to 0.0.0.0 port 60002 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed:
debug1: channel 3: free: direct-tcpip: listening port 60002 for 0.0.0.0 port 60002, connect from 127.0.0.1 port 46888, nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 60002 for 0.0.0.0 port 60002, connect from 127.0.0.1 port 46888 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)

debug3: channel 3: close_fds r 9 w 9 e -1 c -1
|

I don't know what that means, but I'm sure someone does...

I connected to the CTP with the command

|ssh -vvv -L 60002:0.0.0.0:60002 root@192.168.1.31
|

—
Reply to this email directly or view it on GitHub
#4 (comment).

[jtikalsky]

"Simple"... I suppose it depends on what you consider simple. You'd
need to take the system.xml and follow the board bringup guide, at least
as far as producing the petalinux_bsp, (you shouldnt need ot produce
fs-boot itself, though it wont hurt).

There are some.. oddities in that process, issues that need to be
corrected along the way. So I think I'd actually say it's not
particularly simple. I would offer to do it for you but I'm not sure I
can get an X-forwarded connection through to 904 properly.

Unfortunately I'd have to go through it again fully, locally, in order
to produce proper instructions.

On 10/14/2013 07:42 AM, Evan K. Friis wrote:

@nwoods https://github.com/nwoods

cc @dabelnap @jtikalsky https://github.com/jtikalsky

Hi, we are now working on this same task at 904. @nwoods
https://github.com/nwoods, can you send us the modifications to the
makefile to make it work? @jtikalsky https://github.com/jtikalsky is
there a simple way to build the petalinux config for microblaze so the
"correct" way of building works as well?

—
Reply to this email directly or view it on GitHub
#4 (comment).

[nwoods]

We've been using 0.0.0.0 for quite a while (always from Ayinger, which
might change it) and it's seemed to work for ssh, etc. The TCP parts of
this seem to be working, so I doubt that's the problem. Happy to be wrong
if it gets fixed, of course...

On Fri, Oct 18, 2013 at 11:08 AM, jtikalsky notifications@github.comwrote:

Apologies, I've been out of the office most of the week.

0.0.0.0 is not an IP you can connect to. You need to use something
else. Perhaps you meant 127.0.0.1?

On 10/14/2013 05:04 PM, nwoods wrote:

Maybe the -vvv option on ssh gets us somewhere. When I did that, the
error message became

|~ # /tmp/softipbus-forward
debug1: Connection to port 60002 forwarding to 0.0.0.0 port 60002
requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed:
debug1: channel 3: free: direct-tcpip: listening port 60002 for 0.0.0.0
port 60002, connect from 127.0.0.1 port 46888, nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 60002 for 0.0.0.0 port 60002, connect
from 127.0.0.1 port 46888 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)

debug3: channel 3: close_fds r 9 w 9 e -1 c -1
|

I don't know what that means, but I'm sure someone does...

I connected to the CTP with the command

|ssh -vvv -L 60002:0.0.0.0:60002 root@192.168.1.31
|

—
Reply to this email directly or view it on GitHub
<#4 (comment)
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26608141
.

[jtikalsky]

I can't say you're WRONG, but connecting to 0.0.0.0 is really Not
something that should work.

0.0.0.0 is the special case address for 'listen on all addresses'. It's
not an address a system should normally be expected to respond to.

If you want to forward port 60002 on your system to 60002 on the card,
127.0.0.1 is the proper IP address for this. "-L60002:127.0.0.1:60002
translates to "Take connections on 60002 locally, forward them to the
remote endpoint, then connect them to 127.0.0.1 (localhost), port
60002". I've no idea why 0.0.0.0 worked for you, honestly.

On 10/18/2013 11:12 AM, nwoods wrote:

We've been using 0.0.0.0 for quite a while (always from Ayinger, which
might change it) and it's seemed to work for ssh, etc. The TCP parts of
this seem to be working, so I doubt that's the problem. Happy to be wrong
if it gets fixed, of course...

On Fri, Oct 18, 2013 at 11:08 AM, jtikalsky
notifications@github.comwrote:

Apologies, I've been out of the office most of the week.

0.0.0.0 is not an IP you can connect to. You need to use something
else. Perhaps you meant 127.0.0.1?

On 10/14/2013 05:04 PM, nwoods wrote:

Maybe the -vvv option on ssh gets us somewhere. When I did that, the
error message became

|~ # /tmp/softipbus-forward
debug1: Connection to port 60002 forwarding to 0.0.0.0 port 60002
requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed:
debug1: channel 3: free: direct-tcpip: listening port 60002 for
0.0.0.0
port 60002, connect from 127.0.0.1 port 46888, nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 60002 for 0.0.0.0 port 60002, connect
from 127.0.0.1 port 46888 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)

debug3: channel 3: close_fds r 9 w 9 e -1 c -1
|

I don't know what that means, but I'm sure someone does...

I connected to the CTP with the command

|ssh -vvv -L 60002:0.0.0.0:60002 root@192.168.1.31
|

—
Reply to this email directly or view it on GitHub

<#4 (comment)
.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/4#issuecomment-26608141

.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[ekfriis]

Hmm, maybe this is the root of all our problems :) @nwoods, maybe 127.0.0.1
will help. Although I think that this probably isn't the type of thing to
fail half-way.

Jes, we can compile correctly with a non-specific install of petalinux now.
We jsut hardcode the path to mb-gcc in. I think this is fine, even for
the long term, so no painful X-forwarded-over-the-atlantic :).

Thanks

Evan

On Fri, Oct 18, 2013 at 6:19 PM, jtikalsky notifications@github.com wrote:

I can't say you're WRONG, but connecting to 0.0.0.0 is really Not
something that should work.

0.0.0.0 is the special case address for 'listen on all addresses'. It's
not an address a system should normally be expected to respond to.

If you want to forward port 60002 on your system to 60002 on the card,
127.0.0.1 is the proper IP address for this. "-L60002:127.0.0.1:60002
translates to "Take connections on 60002 locally, forward them to the
remote endpoint, then connect them to 127.0.0.1 (localhost), port
60002". I've no idea why 0.0.0.0 worked for you, honestly.

On 10/18/2013 11:12 AM, nwoods wrote:

We've been using 0.0.0.0 for quite a while (always from Ayinger, which
might change it) and it's seemed to work for ssh, etc. The TCP parts of
this seem to be working, so I doubt that's the problem. Happy to be wrong
if it gets fixed, of course...

On Fri, Oct 18, 2013 at 11:08 AM, jtikalsky
notifications@github.comwrote:

Apologies, I've been out of the office most of the week.

0.0.0.0 is not an IP you can connect to. You need to use something
else. Perhaps you meant 127.0.0.1?

On 10/14/2013 05:04 PM, nwoods wrote:

Maybe the -vvv option on ssh gets us somewhere. When I did that, the
error message became

|~ # /tmp/softipbus-forward
debug1: Connection to port 60002 forwarding to 0.0.0.0 port 60002
requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed:
debug1: channel 3: free: direct-tcpip: listening port 60002 for
0.0.0.0
port 60002, connect from 127.0.0.1 port 46888, nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 60002 for 0.0.0.0 port 60002, connect
from 127.0.0.1 port 46888 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)

debug3: channel 3: close_fds r 9 w 9 e -1 c -1
|

I don't know what that means, but I'm sure someone does...

I connected to the CTP with the command

|ssh -vvv -L 60002:0.0.0.0:60002 root@192.168.1.31
|

—
Reply to this email directly or view it on GitHub

<#4 (comment)
.

—
Reply to this email directly or view it on
GitHub<
https://github.com/uwcms/cms-calo-layer1/issues/4#issuecomment-26608141>

.

—
Reply to this email directly or view it on GitHub
<#4 (comment)
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-26609086
.

[tsarangi]

@ekfriis
0.0.0.0 isn't the issue. changing it to 127.0.0.1 produces the same error as we have been discussing.

[ekfriis]

I think we are reaching a conclusion in the monster successor of this monster thread, see #26 (comment)