Re: [casper] Vitesse data sheets and NDAs

2013-01-30 Thread Francois Kapp
Afraid David M is right - the last PHY we used that did not require an NDA
for access to the datasheet was the 1Gb National part on ROACH.  It is
unfortunate, but unavoidable at the moment.  Hopefully the PHY will not
need much discussion in terms of applications, so only people who need to
get involved with the actual hardware design will need to sign NDA's.

-Francois


On Tue, Jan 29, 2013 at 11:41 PM, David MacMahon
dav...@astro.berkeley.eduwrote:

 Hi, David,

 I think this is becoming more and more common in the industry, at least
 for networking chips.  I think Marvell also requires an NDA to get the
 datasheet for the 1 GbE PHYs on the ROACH2 itself.  Are you aware of any
 similar SFP+ PHYs that do NOT require an NDA for the datasheet?

 Dave

 On Jan 29, 2013, at 12:34 PM, David Forbes wrote:

  Hi all,
 
  I'm looking at the SFP+ card for the ROACH 2 board. It appears to use a
 Vitesse 8488 PHY chip. The Vitesse folks say I need to sign a
 non-disclosure agreement (NDA) to read the data sheet.
 
  It seems like a big problem to use a chip with secrets in its data sheet
 in a board for an open hardware platform. Which is to say, I will have a
 hard discussing the merits of using this part with my coworkers (or anyone
 else on the CASPER list) unless they sign the NDA as well.
 
  Thoughts?
  --
  David Forbes Steward Observatory / ARO
  University of Arizonadfor...@email.arizona.edu
  933 N Cherry Room 172   phone 520-626-1361
  Tucson AZ 85721   fax 520-621-5554
 
 





-- 
Francois Kapp

Sub-system Manager
Digital Back End
meerKAT

Team founder: Team SKA Africa
http://www.facebook.com/Team.SKA.Africa
http://teamskaafrica.wordpress.com/
http://www.givengain.com/activist/87536/projects/3987/

SKA South Africa
Third Floor
The Park
Park Road (off Alexandra Road)
Pinelands
7405
Western Cape
South Africa

Latitude: -33.94329 (South); Longitude: 18.48945 (East).

(p) +27 (0)21 506 7300
(p) +27 (0)21 506 7360 (direct)
(f) +27 (0)21 506 7375
(m) +27 (0)82 787 8407


Re: [casper] tcpborphserver3 failure in tg.c

2013-01-30 Thread Marc Welz
Hello

On Tue, Jan 29, 2013 at 8:42 PM, G Jones glenn.calt...@gmail.com wrote:
 Hi,
 As mentioned previously, we've been noticing failures of
 tcpborphserver3 at a rate that has become annoying enough to finally
 track down. We compiled from the github source on the ROACH2 itself
 with debugging enabled and ran through gdb. The failure results are
 described below. The problem seems to occur during the starttap
 command. We'll forward along the raw katcp command we're using, but
 the curious thing is why base which comes from:

 base = gs-s_raw_mode-r_map + gs-s_register-e_pos_base;

 is pointing to invalid memory sometimes.

So I am the author of this.

gs-s_raw_mode-r_map is the pointer into the FPGA which is mapped
into the address space of the process.

gs-s_register-e_pos_base is offset of the register in this memory area.

These pointers can become invalid when the fpga is reprogrammed - but
there is a test to exit when the fpga is reprogrammed - which (going by your
report) may not be sufficient.

Does the crash occur while the fpga is being (re)programmed ? If so, while
I try to understand the failure, you could do an explicit tap stop
before reprogramming the fpga (as a temp workaround).

If it occurs on other occasions, then this problem becomes more interesting.

regards

marc

 -- Forwarded message --
 From: Ramon E. Creager rcrea...@nrao.edu
 Date: Tue, Jan 29, 2013 at 3:09 PM
 Subject: [Gbsapp] tcpborphserver3 failure in tg.c


 I've gotten the tcpborphserver to fail under the debugger, but because I
 don't yet understand the memory management used in this program I'm not
 yet sure what the problem is, so I'm putting this out in case someone
 who understands the tcpborphserver can help isolate the problem more
 quickly than I can.  The segv occurs in tg.c, line 421.  The gdb output is:

 Program received signal SIGSEGV, Segmentation fault.
 0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0, mac=0x107b7970
 \002\002\n\021) at tg.c:421
 421   *((uint32_t *)(base + offset)) = value;
 (gdb) where
 #0  0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0,
 mac=0x107b7970 \002\002\n\021) at tg.c:421
 #1  0x1000a140 in configure_fpga (gs=0x107b7928) at tg.c:877
 #2  0x1000ae68 in create_getap (d=0x107878b8, instance=0,
 name=0x10795da0 gbe0, tap=0x10795d9b tap0,
 ip=0x10795da5 10.17.0.65, port=6, mac=0x10795db6
 02:02:0A:11:00:41, period=10) at tg.c:1167
 #3  0x1000b258 in insert_getap (d=0x107878b8, name=0x10795da0 gbe0,
 tap=0x10795d9b tap0,
 ip=0x10795da5 10.17.0.65, port=6, mac=0x10795db6
 02:02:0A:11:00:41, period=10) at tg.c:1230
 #4  0x1000b514 in tap_start_cmd (d=0x107878b8, argc=6) at tg.c:1290
 #5  0x100143bc in call_katcp (d=0x107878b8) at dispatch.c:879
 #6  0x100145cc in dispatch_katcp (d=0x107878b8) at dispatch.c:951
 #7  0x10018994 in run_shared_katcp (d=0x10782008) at shared.c:659
 #8  0x1001cbe8 in run_core_loop_katcp (dl=0x10782008) at server.c:699
 #9  0x1001d0c0 in run_config_server_katcp (dl=0x10782008, file=0x0,
 count=32, host=0x10047c90 7147, port=0)
 at server.c:832
 #10 0x10002034 in main (argc=3, argv=0xbff188f4) at main.c:196
 (gdb) frame 1
 #1  0x1000a140 in configure_fpga (gs=0x107b7928) at tg.c:877
 877   if(write_mac_fpga(gs, GO_MAC, gs-s_mac_binary)  0){
 (gdb) frame 0
 #0  0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0,
 mac=0x107b7970 \002\002\n\021) at tg.c:421
 421   *((uint32_t *)(base + offset)) = value;
 (gdb) list
 416
 417   value = (   0x0  0xff00) |
 418   (   0x0  0xff) |
 419   ((mac[0]   8)  0xff00) |
 420(mac[1] 0xff);
 421   *((uint32_t *)(base + offset)) = value;
 422
 423
 424   value = ((mac[2]  24)  0xff00) |
 425   ((mac[3]  16)  0xff) |
 (gdb) print base
 $1 = (void *) 0x1033fff
 (gdb) print offset
 $2 = 0
 (gdb) print value
 $3 = 514
 (gdb)

 'base' is a void * which is set like this:
  base = gs-s_raw_mode-r_map + gs-s_register-e_pos_base;
 (back to gdb):

 (gdb) print *(gs-s_raw_mode)
 $12 = {r_registers = 0x10783d80, r_hwmon = 0x10783d90, r_fpga = 1, r_map
 = 0x, r_map_size = 33554432,
   r_image = 0x0, r_bof_dir = 0x10783da0 /boffiles, r_top_register =
 17314052, r_argc = 3,
   r_argv = 0xbff188f4, r_chassis = 0x107876e0, r_taps = 0x10785820,
 r_instances = 0}
 (gdb) print *(gs-s_register)
 $13 = {e_pos_base = 16990208, e_len_base = 16384, e_pos_offset = 0
 '\000', e_len_offset = 0 '\000',
   e_mode = 3 '\003'}
 (gdb)


 I should add that 'base' is pointing to memory gdb says it cannot access
 (hence the segv):

 (gdb) print *(uint32_t *)base
 Cannot access memory at address 0x1033fff


 Ray




Re: [casper] casper Digest, Vol 62, Issue 42

2013-01-30 Thread Joe Greenberg
When I contacted Vitesse, they signed me up so I could download the 8488 
without signing any NDA.
So it appears they are not strict about actually making you sign the 
NDA, but you do have to get permission to view the data sheet.

Joe


casper-requ...@lists.berkeley.edu wrote:

Send casper mailing list submissions to
casper@lists.berkeley.edu

To subscribe or unsubscribe via the World Wide Web, visit

https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu

or, via email, send a message with subject or body 'help' to
casper-requ...@lists.berkeley.edu

You can reach the person managing the list at
casper-ow...@lists.berkeley.edu

When replying, please edit your Subject line so it is more specific
than Re: Contents of casper digest...


Today's Topics:

1. Vitesse data sheets and NDAs (David Forbes)
2. tcpborphserver3 failure in tg.c (G Jones)
3. Re: tcpborphserver3 failure in tg.c (G Jones)
4. Re: ROACH2 J10 (David MacMahon)
5. Re: Vitesse data sheets and NDAs (David MacMahon)
6. Re: Three Tenure-track Faculty positions
   (Madanayake,Habarakada Liyanachchi)
7. Re: Vitesse data sheets and NDAs (Francois Kapp)


--

Message: 1
Date: Tue, 29 Jan 2013 13:34:40 -0700
From: David Forbesdfor...@email.arizona.edu
Subject: [casper] Vitesse data sheets and NDAs
To: Caspercasper@lists.berkeley.edu
Message-ID:51083260.5030...@email.arizona.edu
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi all,

I'm looking at the SFP+ card for the ROACH 2 board. It appears to use a Vitesse
8488 PHY chip. The Vitesse folks say I need to sign a non-disclosure agreement
(NDA) to read the data sheet.

It seems like a big problem to use a chip with secrets in its data sheet in a
board for an open hardware platform. Which is to say, I will have a hard
discussing the merits of using this part with my coworkers (or anyone else on
the CASPER list) unless they sign the NDA as well.

Thoughts?