Re: [casper] ROACH1 - ethernet problem.

[Ramesh Karuppusamy]

Thanks for all your inputs folks.

Forcing the switch to operate in 100mbps mode on the said port and then 
connecting the ROACH1 has solved the problem now. 

I am super stumped by the problem - this board worked for close to 10 years 
auto-negotiating and decided not to, last Friday!

Cheers,
Ramesh




> On 17. Apr 2020, at 16:04, James Smith  wrote:
> 
> Ramesh,
> 
> I've never actually gotten a ROACH to talk directly to a server. The 
> auto-negotiation in the NIC is not great.
> 
> You pretty much need a switch in-between. Which is why Jason recommended 
> using an old 100Mbps switch.
> 
> Regards,
> James
> 
> 
> On Fri, Apr 17, 2020 at 4:00 PM Ramesh Karuppusamy  > wrote:
> 
> 
> I just tried this by putting a spare network interface on to 100mbps and also 
> forcing the ROACH1 eth0 to 100mpbs - this did not help. Looks like the 
> ethernet device on the ROACH1 is dead.
> 
> I used mii-tool to force 100mbps operation:
> 
> root@roach:~# mii-tool -F 100baseTx-HD eth0
> root@roach:~# mii-tool eth0 
> eth0: 100 Mbit, half duplex, link ok
> 
> And similar command on a server with spare eth3 (connected to the ROACH in 
> question).
> 
> Cheers,
> Ramesh
> 
> 
> 
> 
>> On 17. Apr 2020, at 15:41, James Smith > > wrote:
>> 
>> Just to add to what Jason has said, older 100 Mbps switches are easy enough 
>> to pick up secondhand on eBay and such, depending on where you are. They're 
>> quite cheap.
>> 
>> On Fri, Apr 17, 2020 at 3:19 PM Jason Manley > > wrote:
>> 
>> > Since we are running the ancient Debian Etch on this unit, I have no 
>> > access to ethtool, with which I understand that you can switch to 100mpbs. 
>> > Is there any other way to force 100mbps operation?
>> 
>> This actually wouldn't work anyway (we tried it). Something is broken in 
>> that Nat.Semi PHY's autonegotiation. Sometimes it works, other times not. 
>> And some boards were more susceptible to failing.
>> 
>> You really need a 100mbps switch, or a 1Gbps switch that you can down-speed 
>> to lock the port to 100mbps.
>> 
>> Jason
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "casper@lists.berkeley.edu " group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to casper+unsubscr...@lists.berkeley.edu 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/D5D51B6A-2024-4B77-9FC7-7E84CE46DF6F%40ska.ac.za
>>  
>> .
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "casper@lists.berkeley.edu " group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to casper+unsubscr...@lists.berkeley.edu 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG67D34keSLJjoTLLjOVHXA0WEcsPbxTyb6p9F10rz%3DPcvcF0w%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu " group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu 
> .
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/655FF706-CBDF-4F80-B2EC-BB8B327DB13B%40mpifr-bonn.mpg.de
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu 
> .
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG67D36OV-KJ%2BY%2BND8sBOCwGWS_HFmUP4fF_cNu7O-0SHhB23g%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas

Re: [casper] ROACH1 - ethernet problem.

[James Smith]

Ramesh,

I've never actually gotten a ROACH to talk directly to a server. The
auto-negotiation in the NIC is not great.

You pretty much need a switch in-between. Which is why Jason recommended
using an old 100Mbps switch.

Regards,
James


On Fri, Apr 17, 2020 at 4:00 PM Ramesh Karuppusamy 
wrote:

>
>
> I just tried this by putting a spare network interface on to 100mbps and
> also forcing the ROACH1 eth0 to 100mpbs - this did not help. Looks like the
> ethernet device on the ROACH1 is dead.
>
> I used mii-tool to force 100mbps operation:
>
> root@roach:~# mii-tool -F 100baseTx-HD eth0
> root@roach:~# mii-tool eth0
> eth0: 100 Mbit, half duplex, link ok
>
> And similar command on a server with spare eth3 (connected to the ROACH in
> question).
>
> Cheers,
> Ramesh
>
>
>
>
> On 17. Apr 2020, at 15:41, James Smith  wrote:
>
> Just to add to what Jason has said, older 100 Mbps switches are easy
> enough to pick up secondhand on eBay and such, depending on where you are.
> They're quite cheap.
>
> On Fri, Apr 17, 2020 at 3:19 PM Jason Manley  wrote:
>
>>
>> > Since we are running the ancient Debian Etch on this unit, I have no
>> access to ethtool, with which I understand that you can switch to 100mpbs.
>> Is there any other way to force 100mbps operation?
>>
>> This actually wouldn't work anyway (we tried it). Something is broken in
>> that Nat.Semi PHY's autonegotiation. Sometimes it works, other times not.
>> And some boards were more susceptible to failing.
>>
>> You really need a 100mbps switch, or a 1Gbps switch that you can
>> down-speed to lock the port to 100mbps.
>>
>> Jason
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/D5D51B6A-2024-4B77-9FC7-7E84CE46DF6F%40ska.ac.za
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG67D34keSLJjoTLLjOVHXA0WEcsPbxTyb6p9F10rz%3DPcvcF0w%40mail.gmail.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/655FF706-CBDF-4F80-B2EC-BB8B327DB13B%40mpifr-bonn.mpg.de
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG67D36OV-KJ%2BY%2BND8sBOCwGWS_HFmUP4fF_cNu7O-0SHhB23g%40mail.gmail.com.

Re: [casper] ROACH1 - ethernet problem.

[Jason Manley]

Yeah, but as I say, this never fixed the 1Gbps problem anyway. Was a weird 
problem.

Jason

> On 17 Apr 2020, at 16:00, Ramesh Karuppusamy  wrote:
> 
> 
> 
> I just tried this by putting a spare network interface on to 100mbps and also 
> forcing the ROACH1 eth0 to 100mpbs - this did not help. Looks like the 
> ethernet device on the ROACH1 is dead.
> 
> I used mii-tool to force 100mbps operation:
> 
> root@roach:~# mii-tool -F 100baseTx-HD eth0
> root@roach:~# mii-tool eth0 
> eth0: 100 Mbit, half duplex, link ok
> 
> And similar command on a server with spare eth3 (connected to the ROACH in 
> question).
> 
> Cheers,
> Ramesh
> 
> 
> 
> 
>> On 17. Apr 2020, at 15:41, James Smith  wrote:
>> 
>> Just to add to what Jason has said, older 100 Mbps switches are easy enough 
>> to pick up secondhand on eBay and such, depending on where you are. They're 
>> quite cheap.
>> 
>> On Fri, Apr 17, 2020 at 3:19 PM Jason Manley  wrote:
>> 
>> > Since we are running the ancient Debian Etch on this unit, I have no 
>> > access to ethtool, with which I understand that you can switch to 100mpbs. 
>> > Is there any other way to force 100mbps operation?
>> 
>> This actually wouldn't work anyway (we tried it). Something is broken in 
>> that Nat.Semi PHY's autonegotiation. Sometimes it works, other times not. 
>> And some boards were more susceptible to failing.
>> 
>> You really need a 100mbps switch, or a 1Gbps switch that you can down-speed 
>> to lock the port to 100mbps.
>> 
>> Jason
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/D5D51B6A-2024-4B77-9FC7-7E84CE46DF6F%40ska.ac.za.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG67D34keSLJjoTLLjOVHXA0WEcsPbxTyb6p9F10rz%3DPcvcF0w%40mail.gmail.com.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/655FF706-CBDF-4F80-B2EC-BB8B327DB13B%40mpifr-bonn.mpg.de.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/627DE219-1C77-4FD0-9129-15DBA21C227F%40ska.ac.za.

Re: [casper] ROACH1 - ethernet problem.

[Ramesh Karuppusamy]

I just tried this by putting a spare network interface on to 100mbps and also 
forcing the ROACH1 eth0 to 100mpbs - this did not help. Looks like the ethernet 
device on the ROACH1 is dead.

I used mii-tool to force 100mbps operation:

root@roach:~# mii-tool -F 100baseTx-HD eth0
root@roach:~# mii-tool eth0 
eth0: 100 Mbit, half duplex, link ok

And similar command on a server with spare eth3 (connected to the ROACH in 
question).

Cheers,
Ramesh




> On 17. Apr 2020, at 15:41, James Smith  wrote:
> 
> Just to add to what Jason has said, older 100 Mbps switches are easy enough 
> to pick up secondhand on eBay and such, depending on where you are. They're 
> quite cheap.
> 
> On Fri, Apr 17, 2020 at 3:19 PM Jason Manley  > wrote:
> 
> > Since we are running the ancient Debian Etch on this unit, I have no access 
> > to ethtool, with which I understand that you can switch to 100mpbs. Is 
> > there any other way to force 100mbps operation?
> 
> This actually wouldn't work anyway (we tried it). Something is broken in that 
> Nat.Semi PHY's autonegotiation. Sometimes it works, other times not. And some 
> boards were more susceptible to failing.
> 
> You really need a 100mbps switch, or a 1Gbps switch that you can down-speed 
> to lock the port to 100mbps.
> 
> Jason
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu " group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu 
> .
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/D5D51B6A-2024-4B77-9FC7-7E84CE46DF6F%40ska.ac.za
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu 
> .
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG67D34keSLJjoTLLjOVHXA0WEcsPbxTyb6p9F10rz%3DPcvcF0w%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/655FF706-CBDF-4F80-B2EC-BB8B327DB13B%40mpifr-bonn.mpg.de.


smime.p7s
Description: S/MIME cryptographic signature

Re: [casper] ROACH1 - ethernet problem.

[Indrajit Vittal Barve]

Dear Ramesh,

Here is the link you can download and write the image to the SD card. If 
possible use the 2GB SD card which is shipped along with the board.


https://drive.google.com/open?id=1sK69IUDKkdEw3W6aF0r7wll0QR1KoSiS

sudo dd of=/dev/mmcblk0p1 if=~/roach1_imagebkup_20190416_2GB.img

Note mmcblk0p1 replace your SD card name

---
Thanks and Regards

Indrajit Vittal Barve

On 2020-04-17 19:24, Ramesh Karuppusamy wrote:

Hi Indrajit,

Useful to know - I believe I do have our original ROACH1 image
somewhere, therefore I will try what you suggested.

Thanks!

Cheers,
Ramesh




On 17. Apr 2020, at 15:30, Indrajit Vittal Barve 
 wrote:


Dear Ramesh Karuppusamy,

This kind of issues we faced several times, We use to do re-write the 
SD card image. Then it gets resolved. If you want the image for the 
roach1 I can provide the same. Then you can copy your BOF and run your 
code.


---
Thanks and Regards

Indrajit Vittal Barve

On 2020-04-17 18:26, Ramesh Karuppusamy wrote:

Dear All,
I hope you are all staying healthy.
The gigabit ethernet on our ~10 year old ROACH1 board went silent all
of a sudden this morning. The ethernet port show no activity (the
yellow LED flickers very occasionally). On booting the unit off the 
SD

card, and manually bringing up the interface shows the following
message on the serial console and keeps repeating:
eth0: link is down
root@roach:~# eth0: link is up, 1000 FDX
eth0: link is down
eth0: link is up, 1000 FDX
eth0: link is down
The board does not respond to pings either.
I tried a different cable, a differ port on the switch, and opened up
the board to examine the said port - nothing looks suspicious. Does
anyone have an idea on what could be the issue here?
Thanks in advance for any of your suggestions!
Cheers,
Ramesh


--
You received this message because you are subscribed to the Google 
Groups "casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/84391341484bc337ee7d2358a0f465e4%40iiap.res.in.


--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/ccea4ca396ad3188906b336087d25f8d%40iiap.res.in.

Re: [casper] ROACH1 - ethernet problem.

[Ramesh Karuppusamy]

Hi Indrajit,

Useful to know - I believe I do have our original ROACH1 image somewhere, 
therefore I will try what you suggested.

Thanks!

Cheers,
Ramesh




> On 17. Apr 2020, at 15:30, Indrajit Vittal Barve  wrote:
> 
> Dear Ramesh Karuppusamy,
> 
> This kind of issues we faced several times, We use to do re-write the SD card 
> image. Then it gets resolved. If you want the image for the roach1 I can 
> provide the same. Then you can copy your BOF and run your code.
> 
> ---
> Thanks and Regards
> 
> Indrajit Vittal Barve
> 
> On 2020-04-17 18:26, Ramesh Karuppusamy wrote:
>> Dear All,
>> I hope you are all staying healthy.
>> The gigabit ethernet on our ~10 year old ROACH1 board went silent all
>> of a sudden this morning. The ethernet port show no activity (the
>> yellow LED flickers very occasionally). On booting the unit off the SD
>> card, and manually bringing up the interface shows the following
>> message on the serial console and keeps repeating:
>> eth0: link is down
>> root@roach:~# eth0: link is up, 1000 FDX
>> eth0: link is down
>> eth0: link is up, 1000 FDX
>> eth0: link is down
>> The board does not respond to pings either.
>> I tried a different cable, a differ port on the switch, and opened up
>> the board to examine the said port - nothing looks suspicious. Does
>> anyone have an idea on what could be the issue here?
>> Thanks in advance for any of your suggestions!
>> Cheers,
>> Ramesh
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/84391341484bc337ee7d2358a0f465e4%40iiap.res.in.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/C489B698-9929-4A7A-93B6-8E9C0A1F8DC6%40mpifr-bonn.mpg.de.


smime.p7s
Description: S/MIME cryptographic signature

Re: [casper] ROACH1 - ethernet problem.

[James Smith]

Just to add to what Jason has said, older 100 Mbps switches are easy enough
to pick up secondhand on eBay and such, depending on where you are. They're
quite cheap.

On Fri, Apr 17, 2020 at 3:19 PM Jason Manley  wrote:

>
> > Since we are running the ancient Debian Etch on this unit, I have no
> access to ethtool, with which I understand that you can switch to 100mpbs.
> Is there any other way to force 100mbps operation?
>
> This actually wouldn't work anyway (we tried it). Something is broken in
> that Nat.Semi PHY's autonegotiation. Sometimes it works, other times not.
> And some boards were more susceptible to failing.
>
> You really need a 100mbps switch, or a 1Gbps switch that you can
> down-speed to lock the port to 100mbps.
>
> Jason
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/D5D51B6A-2024-4B77-9FC7-7E84CE46DF6F%40ska.ac.za
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG67D34keSLJjoTLLjOVHXA0WEcsPbxTyb6p9F10rz%3DPcvcF0w%40mail.gmail.com.

Re: [casper] ROACH1 - ethernet problem.

[Indrajit Vittal Barve]

Dear Ramesh Karuppusamy,

This kind of issues we faced several times, We use to do re-write the SD 
card image. Then it gets resolved. If you want the image for the roach1 
I can provide the same. Then you can copy your BOF and run your code.


---
Thanks and Regards

Indrajit Vittal Barve

On 2020-04-17 18:26, Ramesh Karuppusamy wrote:

Dear All,

I hope you are all staying healthy.

The gigabit ethernet on our ~10 year old ROACH1 board went silent all
of a sudden this morning. The ethernet port show no activity (the
yellow LED flickers very occasionally). On booting the unit off the SD
card, and manually bringing up the interface shows the following
message on the serial console and keeps repeating:

eth0: link is down
root@roach:~# eth0: link is up, 1000 FDX
eth0: link is down
eth0: link is up, 1000 FDX
eth0: link is down

The board does not respond to pings either.

I tried a different cable, a differ port on the switch, and opened up
the board to examine the said port - nothing looks suspicious. Does
anyone have an idea on what could be the issue here?

Thanks in advance for any of your suggestions!

Cheers,
Ramesh


--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/84391341484bc337ee7d2358a0f465e4%40iiap.res.in.

Re: [casper] ROACH1 - ethernet problem.

[Jason Manley]

> Since we are running the ancient Debian Etch on this unit, I have no access 
> to ethtool, with which I understand that you can switch to 100mpbs. Is there 
> any other way to force 100mbps operation?

This actually wouldn't work anyway (we tried it). Something is broken in that 
Nat.Semi PHY's autonegotiation. Sometimes it works, other times not. And some 
boards were more susceptible to failing.

You really need a 100mbps switch, or a 1Gbps switch that you can down-speed to 
lock the port to 100mbps.

Jason


-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/D5D51B6A-2024-4B77-9FC7-7E84CE46DF6F%40ska.ac.za.

Re: [casper] ROACH1 - ethernet problem.

[Ramesh Karuppusamy]

Thanks Jason, I thought about it.

Since we are running the ancient Debian Etch on this unit, I have no access to 
ethtool, with which I understand that you can switch to 100mpbs. Is there any 
other way to force 100mbps operation?


Cheers,
Ramesh




> On 17. Apr 2020, at 15:10, Jason Manley  wrote:
> 
> Can you try it with a 100mbps link partner? ROACH1's PHY was notoriously 
> fickle at 1Gbps. We never did get to the bottom of it, even with Nat.Semi's 
> support, and switched PHYs on ROACH2.
> 
> Jason Manley
> DSP Manager
> SKA-SA
> 
> Cell: +27 82 662 7726
> Work: +27 21 506 7300
> 
>> On 17 Apr 2020, at 14:56, Ramesh Karuppusamy  
>> wrote:
>> 
>> Dear All,
>> 
>> I hope you are all staying healthy.
>> 
>> The gigabit ethernet on our ~10 year old ROACH1 board went silent all of a 
>> sudden this morning. The ethernet port show no activity (the yellow LED 
>> flickers very occasionally). On booting the unit off the SD card, and 
>> manually bringing up the interface shows the following message on the serial 
>> console and keeps repeating:
>> 
>> eth0: link is down
>> root@roach:~# eth0: link is up, 1000 FDX
>> eth0: link is down
>> eth0: link is up, 1000 FDX
>> eth0: link is down
>> 
>> The board does not respond to pings either. 
>> 
>> I tried a different cable, a differ port on the switch, and opened up the 
>> board to examine the said port - nothing looks suspicious. Does anyone have 
>> an idea on what could be the issue here?
>> 
>> Thanks in advance for any of your suggestions!
>> 
>> Cheers,
>> Ramesh
>> 
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/0B08CEC2-D030-436C-8E67-E73911E0110B%40mpifr-bonn.mpg.de.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/0A041622-FCCD-4551-9A15-BE87F451B901%40ska.ac.za.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/2487C99F-4DC7-4A14-941F-A5921179D07D%40mpifr-bonn.mpg.de.


smime.p7s
Description: S/MIME cryptographic signature

Re: [casper] ROACH1 - ethernet problem.

[Jason Manley]

Can you try it with a 100mbps link partner? ROACH1's PHY was notoriously fickle 
at 1Gbps. We never did get to the bottom of it, even with Nat.Semi's support, 
and switched PHYs on ROACH2.

Jason Manley
DSP Manager
SKA-SA

Cell: +27 82 662 7726
Work: +27 21 506 7300

> On 17 Apr 2020, at 14:56, Ramesh Karuppusamy  wrote:
> 
> Dear All,
> 
> I hope you are all staying healthy.
> 
> The gigabit ethernet on our ~10 year old ROACH1 board went silent all of a 
> sudden this morning. The ethernet port show no activity (the yellow LED 
> flickers very occasionally). On booting the unit off the SD card, and 
> manually bringing up the interface shows the following message on the serial 
> console and keeps repeating:
> 
> eth0: link is down
> root@roach:~# eth0: link is up, 1000 FDX
> eth0: link is down
> eth0: link is up, 1000 FDX
> eth0: link is down
> 
> The board does not respond to pings either. 
> 
> I tried a different cable, a differ port on the switch, and opened up the 
> board to examine the said port - nothing looks suspicious. Does anyone have 
> an idea on what could be the issue here?
> 
> Thanks in advance for any of your suggestions!
> 
> Cheers,
> Ramesh
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/0B08CEC2-D030-436C-8E67-E73911E0110B%40mpifr-bonn.mpg.de.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/0A041622-FCCD-4551-9A15-BE87F451B901%40ska.ac.za.

Re: [casper] ROACH1 NFS unable to mount root

[Louis P. Dartez]

Hello Brent,
That was it! Thanks for that! Good catch, I'm using a recent Ubuntu version
whereas my previous installs are all really old & stable systems that I
haven't had to touch or mess with in a long time.

Thanks again,
LD

On Thu, Apr 9, 2020 at 12:42 PM Brent Graner  wrote:

> Hi Louis-
>
> I'm only familiar with the ROACH2, but one of the more insidious problems
> we had setting ours up on a new ubuntu 16.04 machine was that the ROACH2
> expects the outdated NFS version 2, which was disabled by default (and
> re-enabled in /proc/fs/nfsd/versions). I’m not sure what the default
> behavior is on the ROACH1 with your OS, but if it's an NFS problem and a
> new-ish Unix OS machine it may be worth checking.
>
> best of luck,
> Brent Graner
> University of Washington
>
> On Thu, Apr 9, 2020 at 10:21 AM Louis P. Dartez 
> wrote:
>
>> Hello,
>> I'm setting up an NFS server for a ROACH-1 board. I've done this a couple
>> of times before but this time there's an issue I've never encountered. The
>> ROACH board is assigned the correct ip address (dhcp is working) and seems
>> to load the uImage just fine. However, when it attempts to mount the root
>> directory it suddenly fails and the kernel panics (see attached minicom
>> output). My issue is very similar to this post from 2015
>>  except
>> I'm not getting a useful NFS error. I don't have another machine on this
>> subnet that I can use to test the NFS mounting from, but I am able to mount
>> that directory using 'sudo mount 192.168.4.12:/srv/roach_boot_etch /mnt'
>> from the same host (I'm not sure if this undermines NFS and just remounts
>> the target).
>> Has anyone else seen something like this before? My ethernet connect is
>> 100Mbps, my exports match what's in the dnsmasq configuration file, I've
>> made sure to restart all services (nfs-kernel-server, dnsmasq, etc.) after
>> all changes, and permissions for the boot/etch directories not restricted
>> (currently all is 777, but there is no change when using 755). In fact, as
>> far as I can tell, my current configuration is identical to others that I
>> have working. I've included the contents of my dnsmasq config, dnsmasq log,
>> the output of rpcinfo -p, exportfs -rva, and showmount -e to this message
>> as well. Any suggests for what to try next at this point would be greatly
>> appreciated!
>>
>> Best,
>> LD
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CALQjEoW7%3Dv%2BDcruFFx9CPuhVmbMORwv7%3DENhTRFmbPbcAJT72w%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CALQjEoXswGvztw-%3DNM8YsTEyg7wKRh23YNNHVmKN-Dou4eS8xw%40mail.gmail.com.

Re: [casper] ROACH1 est_brd_clk()

[Tom Kuiper]

On 04/18/2018 10:53 AM, Gary, Dale E. wrote:
What digitizer are these using?  We have had issues with the KATADC on 
ROACH2, which turns out to need some register initializations in order 
to function properly, and the symptom is a bad est_brd_clk() result.


Hey, wow, Dale! That was fast.  Yes, they are KATADCs.  I'm interested 
in knowing about the registers. The order of the initialization might 
then be due to something in my code.


Thanks

Tom

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] ROACH1 est_brd_clk()

[Gary, Dale E.]

Hi Tom,

What digitizer are these using?  We have had issues with the KATADC on
ROACH2, which turns out to need some register initializations in order to
function properly, and the symptom is a bad est_brd_clk() result.

Regards,
Dale

On Wed, Apr 18, 2018 at 1:48 PM, Tom Kuiper  wrote:

> What situations could cause est_brd_clk() to give the wrong answer?
>
> I have two ROACH1s and a Valon 5007.  Every time we check the Valon it
> puts out the required clock frequency, 1020 MHz, at about +7 dBm.
>
> When I initialize the ROACHs (roach1, roach2) from an ipython command
> line, est_brd_clk() in the __init__() routine finds the expected system
> clock of 255 MHz.  When the two ROACHs are initialized as part of a server
> initialization, the first ROACH initialized passes the system clock test
> and the second fails. I've reversed the order of initialization so it's not
> a specific ROACH that passes or fails.  Then at the end of the server
> initialization, I check both system clocks and they are then both wrong.
> Then, if I shut down the server and re-initialize the ROACHs, they both
> have the right system clock.
>
> If no one has an explanation, perhaps there might be some suggestions for
> what I should try next.
>
> Thanks and warm regards,
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] ROACH1 Programming issues

[Jack Hickish]

Excellent!

Happy ROACHing

Jack

On Thu, 12 Oct 2017 at 22:16 Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> Hi Jack,
>
> The bof was not a executable, and this seemed to be the problem.
> Once I changed it to an executable, then the ROACH got programmed.
>
> Thank to you and James :)
>
> Regards,
>
> Mugundhan
>
> On Fri, Oct 13, 2017 at 10:34 AM, Jack Hickish 
> wrote:
>
>> Hi Mugundhan,
>>
>> Is the boffile that fails to program executable? I.e., if you log into
>> the roach and run "ls -la /boffiles/" do the working and not-working
>> boffiles have the asme permissions.
>> (I don't actually know if roach1 still requires boffiles to be
>> executable, but it used to, so maybe it's worth checking).
>>
>> Cheers
>> Jack
>>
>> On Thu, 12 Oct 2017 at 20:58 Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hi James,
>>>
>>> I tried it using the version of casperfpga you suggested. The same error
>>> is returned.
>>>
>>> I'm attaching the python code that I'm using for programming the board.
>>>
>>> -
>>> Regards,
>>>
>>> Mugundhan V.
>>>
>>> On Thu, Oct 12, 2017 at 5:24 PM, James Smith  wrote:
>>>
 Hello Mugundhan,

 Casperfpga is a work in progress and unfortunately some of the more
 recent developments will have broken compatibility with ROACH1. Its main
 focus at the moment is SKARAB / ROACH2.

 I use the following commit to work on ROACH1:
 avnuser@planck:~/SKASoftware/casperfpga$ git show
 commit 475ed6826b893230d62da8c7dcdcc2541bea83cf
 Merge: 9835009 7402b29
 Author: Paul Prozesky 
 Date:   Fri Mar 4 17:27:09 2016 +0200

 Merge branch 'devel' of github.com:ska-sa/casperfpga into devel

 Try installing casperfpga from that particular git commit and you'll
 likely be more successful.

 Also, before you use the fpga.program() function, you need to set the
 bof file in the system information - I think I have mentioned how to do
 this in the history of the mailing list somewhere before.

 Let me know if it works.

 Regards,
 James


 On Thu, Oct 12, 2017 at 12:35 PM, Mugundhan vijayaraghavan <
 v.vaishnav151...@gmail.com> wrote:

> And I'm using the latest version of casperfpga library and katcp
> version.
>
> On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hello James,
>>
>> I'm attaching the model files of the first and the second designs,
>> along with the bof and the fga files. I used the ipython terminal for
>> programming the fpga in both cases. The error I obtained is attached in a
>> text file.
>>
>> Hope this helps,
>>
>> Thank you,
>>
>> Mugundhan V.
>>
>>
>>
>> On Thu, Oct 12, 2017 at 3:49 PM, James Smith 
>> wrote:
>>
>>> Hello Mugundhan,
>>>
>>> Please describe your context a bit more - what libraries are you
>>> using? Please also paste the error that you get? (and perhaps the code 
>>> you
>>> used to generate the error.)
>>>
>>> Regards,
>>> James
>>>
>>>
>>> On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
>>> v.vaishnav151...@gmail.com> wrote:
>>>
 Hi,

 I'm facing a strange problem. I have an iADC, which I've connected
 to roach1 and have compiled a program to acquire raw samples from it. 
 The
 simulation, compilation and generation works fine and I get the bof 
 and the
 fpg files, which i place in their respective locations, and the ROACH 
 gets
 programmed well.

 I also developed a iADC spectropolarimeter and generated the fpg
 and bof files and placed them in their locations, but now when I try
 programming the ROACH, i get Katcp request time out error. If i 
 reprogram
 the first bof file, it works fine, but repeated compilation and program
 cycles have failed for hte second model, with the same katcp request 
 failed
 error.

 Can someone kindly guide me solving it ?

 Thank you,

 --
 V. Mugundhan
 SRF, IIA

 --
 You received this message because you are subscribed to the Google
 Groups "casper@lists.berkeley.edu" group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to casper+unsubscr...@lists.berkeley.edu.
 To post to this group, send email to casper@lists.berkeley.edu.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to casper+unsubscr...@lists.berkeley.edu.
>>> To post to this group, send email 

Re: [casper] ROACH1 Programming issues

[Mugundhan vijayaraghavan]

Hi Jack,

The bof was not a executable, and this seemed to be the problem.
Once I changed it to an executable, then the ROACH got programmed.

Thank to you and James :)

Regards,

Mugundhan

On Fri, Oct 13, 2017 at 10:34 AM, Jack Hickish 
wrote:

> Hi Mugundhan,
>
> Is the boffile that fails to program executable? I.e., if you log into the
> roach and run "ls -la /boffiles/" do the working and not-working boffiles
> have the asme permissions.
> (I don't actually know if roach1 still requires boffiles to be executable,
> but it used to, so maybe it's worth checking).
>
> Cheers
> Jack
>
> On Thu, 12 Oct 2017 at 20:58 Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hi James,
>>
>> I tried it using the version of casperfpga you suggested. The same error
>> is returned.
>>
>> I'm attaching the python code that I'm using for programming the board.
>>
>> -
>> Regards,
>>
>> Mugundhan V.
>>
>> On Thu, Oct 12, 2017 at 5:24 PM, James Smith  wrote:
>>
>>> Hello Mugundhan,
>>>
>>> Casperfpga is a work in progress and unfortunately some of the more
>>> recent developments will have broken compatibility with ROACH1. Its main
>>> focus at the moment is SKARAB / ROACH2.
>>>
>>> I use the following commit to work on ROACH1:
>>> avnuser@planck:~/SKASoftware/casperfpga$ git show
>>> commit 475ed6826b893230d62da8c7dcdcc2541bea83cf
>>> Merge: 9835009 7402b29
>>> Author: Paul Prozesky 
>>> Date:   Fri Mar 4 17:27:09 2016 +0200
>>>
>>> Merge branch 'devel' of github.com:ska-sa/casperfpga into devel
>>>
>>> Try installing casperfpga from that particular git commit and you'll
>>> likely be more successful.
>>>
>>> Also, before you use the fpga.program() function, you need to set the
>>> bof file in the system information - I think I have mentioned how to do
>>> this in the history of the mailing list somewhere before.
>>>
>>> Let me know if it works.
>>>
>>> Regards,
>>> James
>>>
>>>
>>> On Thu, Oct 12, 2017 at 12:35 PM, Mugundhan vijayaraghavan <
>>> v.vaishnav151...@gmail.com> wrote:
>>>
 And I'm using the latest version of casperfpga library and katcp
 version.

 On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
 v.vaishnav151...@gmail.com> wrote:

> Hello James,
>
> I'm attaching the model files of the first and the second designs,
> along with the bof and the fga files. I used the ipython terminal for
> programming the fpga in both cases. The error I obtained is attached in a
> text file.
>
> Hope this helps,
>
> Thank you,
>
> Mugundhan V.
>
>
>
> On Thu, Oct 12, 2017 at 3:49 PM, James Smith  wrote:
>
>> Hello Mugundhan,
>>
>> Please describe your context a bit more - what libraries are you
>> using? Please also paste the error that you get? (and perhaps the code 
>> you
>> used to generate the error.)
>>
>> Regards,
>> James
>>
>>
>> On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm facing a strange problem. I have an iADC, which I've connected
>>> to roach1 and have compiled a program to acquire raw samples from it. 
>>> The
>>> simulation, compilation and generation works fine and I get the bof and 
>>> the
>>> fpg files, which i place in their respective locations, and the ROACH 
>>> gets
>>> programmed well.
>>>
>>> I also developed a iADC spectropolarimeter and generated the fpg and
>>> bof files and placed them in their locations, but now when I try
>>> programming the ROACH, i get Katcp request time out error. If i 
>>> reprogram
>>> the first bof file, it works fine, but repeated compilation and program
>>> cycles have failed for hte second model, with the same katcp request 
>>> failed
>>> error.
>>>
>>> Can someone kindly guide me solving it ?
>>>
>>> Thank you,
>>>
>>> --
>>> V. Mugundhan
>>> SRF, IIA
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to casper+unsubscr...@lists.berkeley.edu.
>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>
>
>
> --
> V. Mugundhan
> SRF, IIA
>



 --
 V. Mugundhan
 SRF, IIA

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>

Re: [casper] ROACH1 Programming issues

[Jack Hickish]

Hi Mugundhan,

Is the boffile that fails to program executable? I.e., if you log into the
roach and run "ls -la /boffiles/" do the working and not-working boffiles
have the asme permissions.
(I don't actually know if roach1 still requires boffiles to be executable,
but it used to, so maybe it's worth checking).

Cheers
Jack

On Thu, 12 Oct 2017 at 20:58 Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> Hi James,
>
> I tried it using the version of casperfpga you suggested. The same error
> is returned.
>
> I'm attaching the python code that I'm using for programming the board.
>
> -
> Regards,
>
> Mugundhan V.
>
> On Thu, Oct 12, 2017 at 5:24 PM, James Smith  wrote:
>
>> Hello Mugundhan,
>>
>> Casperfpga is a work in progress and unfortunately some of the more
>> recent developments will have broken compatibility with ROACH1. Its main
>> focus at the moment is SKARAB / ROACH2.
>>
>> I use the following commit to work on ROACH1:
>> avnuser@planck:~/SKASoftware/casperfpga$ git show
>> commit 475ed6826b893230d62da8c7dcdcc2541bea83cf
>> Merge: 9835009 7402b29
>> Author: Paul Prozesky 
>> Date:   Fri Mar 4 17:27:09 2016 +0200
>>
>> Merge branch 'devel' of github.com:ska-sa/casperfpga into devel
>>
>> Try installing casperfpga from that particular git commit and you'll
>> likely be more successful.
>>
>> Also, before you use the fpga.program() function, you need to set the bof
>> file in the system information - I think I have mentioned how to do this in
>> the history of the mailing list somewhere before.
>>
>> Let me know if it works.
>>
>> Regards,
>> James
>>
>>
>> On Thu, Oct 12, 2017 at 12:35 PM, Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> And I'm using the latest version of casperfpga library and katcp version.
>>>
>>> On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
>>> v.vaishnav151...@gmail.com> wrote:
>>>
 Hello James,

 I'm attaching the model files of the first and the second designs,
 along with the bof and the fga files. I used the ipython terminal for
 programming the fpga in both cases. The error I obtained is attached in a
 text file.

 Hope this helps,

 Thank you,

 Mugundhan V.



 On Thu, Oct 12, 2017 at 3:49 PM, James Smith  wrote:

> Hello Mugundhan,
>
> Please describe your context a bit more - what libraries are you
> using? Please also paste the error that you get? (and perhaps the code you
> used to generate the error.)
>
> Regards,
> James
>
>
> On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm facing a strange problem. I have an iADC, which I've connected to
>> roach1 and have compiled a program to acquire raw samples from it. The
>> simulation, compilation and generation works fine and I get the bof and 
>> the
>> fpg files, which i place in their respective locations, and the ROACH 
>> gets
>> programmed well.
>>
>> I also developed a iADC spectropolarimeter and generated the fpg and
>> bof files and placed them in their locations, but now when I try
>> programming the ROACH, i get Katcp request time out error. If i reprogram
>> the first bof file, it works fine, but repeated compilation and program
>> cycles have failed for hte second model, with the same katcp request 
>> failed
>> error.
>>
>> Can someone kindly guide me solving it ?
>>
>> Thank you,
>>
>> --
>> V. Mugundhan
>> SRF, IIA
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>



 --
 V. Mugundhan
 SRF, IIA

>>>
>>>
>>>
>>> --
>>> V. Mugundhan
>>> SRF, IIA
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>
>
>
> --
> V. Mugundhan
> SRF, IIA
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to

Re: [casper] ROACH1 Programming issues

[Mugundhan vijayaraghavan]

Hi James,

I tried it using the version of casperfpga you suggested. The same error is
returned.

I'm attaching the python code that I'm using for programming the board.

-
Regards,

Mugundhan V.

On Thu, Oct 12, 2017 at 5:24 PM, James Smith  wrote:

> Hello Mugundhan,
>
> Casperfpga is a work in progress and unfortunately some of the more recent
> developments will have broken compatibility with ROACH1. Its main focus at
> the moment is SKARAB / ROACH2.
>
> I use the following commit to work on ROACH1:
> avnuser@planck:~/SKASoftware/casperfpga$ git show
> commit 475ed6826b893230d62da8c7dcdcc2541bea83cf
> Merge: 9835009 7402b29
> Author: Paul Prozesky 
> Date:   Fri Mar 4 17:27:09 2016 +0200
>
> Merge branch 'devel' of github.com:ska-sa/casperfpga into devel
>
> Try installing casperfpga from that particular git commit and you'll
> likely be more successful.
>
> Also, before you use the fpga.program() function, you need to set the bof
> file in the system information - I think I have mentioned how to do this in
> the history of the mailing list somewhere before.
>
> Let me know if it works.
>
> Regards,
> James
>
>
> On Thu, Oct 12, 2017 at 12:35 PM, Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> And I'm using the latest version of casperfpga library and katcp version.
>>
>> On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hello James,
>>>
>>> I'm attaching the model files of the first and the second designs, along
>>> with the bof and the fga files. I used the ipython terminal for programming
>>> the fpga in both cases. The error I obtained is attached in a text file.
>>>
>>> Hope this helps,
>>>
>>> Thank you,
>>>
>>> Mugundhan V.
>>>
>>>
>>>
>>> On Thu, Oct 12, 2017 at 3:49 PM, James Smith  wrote:
>>>
 Hello Mugundhan,

 Please describe your context a bit more - what libraries are you using?
 Please also paste the error that you get? (and perhaps the code you used to
 generate the error.)

 Regards,
 James


 On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
 v.vaishnav151...@gmail.com> wrote:

> Hi,
>
> I'm facing a strange problem. I have an iADC, which I've connected to
> roach1 and have compiled a program to acquire raw samples from it. The
> simulation, compilation and generation works fine and I get the bof and 
> the
> fpg files, which i place in their respective locations, and the ROACH gets
> programmed well.
>
> I also developed a iADC spectropolarimeter and generated the fpg and
> bof files and placed them in their locations, but now when I try
> programming the ROACH, i get Katcp request time out error. If i reprogram
> the first bof file, it works fine, but repeated compilation and program
> cycles have failed for hte second model, with the same katcp request 
> failed
> error.
>
> Can someone kindly guide me solving it ?
>
> Thank you,
>
> --
> V. Mugundhan
> SRF, IIA
>
> --
> You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

 --
 You received this message because you are subscribed to the Google
 Groups "casper@lists.berkeley.edu" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to casper+unsubscr...@lists.berkeley.edu.
 To post to this group, send email to casper@lists.berkeley.edu.

>>>
>>>
>>>
>>> --
>>> V. Mugundhan
>>> SRF, IIA
>>>
>>
>>
>>
>> --
>> V. Mugundhan
>> SRF, IIA
>>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>



-- 
V. Mugundhan
SRF, IIA

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.
import matplotlib.pyplot as plt
import numpy as np
import scipy as sp
import os
import time
import casperfpga
import sys
import logging

def exit_fail():
print 'FAILURE DETECTED. Log entries:\n'
try:
fpga.stop()
except: pass
raise
exit()

def exit_clean():
try:
fpga.stop()
except: pass
exit()

fpga = casperfpga.katcp_fpga.KatcpFpga('100.100.100.1',7147,10)
if (fpga.is_connected() == True):
print 'Connected to the FPGA '
else:
print '

Re: [casper] ROACH1 Programming issues

[James Smith]

Hello Mugundhan,

Casperfpga is a work in progress and unfortunately some of the more recent
developments will have broken compatibility with ROACH1. Its main focus at
the moment is SKARAB / ROACH2.

I use the following commit to work on ROACH1:
avnuser@planck:~/SKASoftware/casperfpga$ git show
commit 475ed6826b893230d62da8c7dcdcc2541bea83cf
Merge: 9835009 7402b29
Author: Paul Prozesky 
Date:   Fri Mar 4 17:27:09 2016 +0200

Merge branch 'devel' of github.com:ska-sa/casperfpga into devel

Try installing casperfpga from that particular git commit and you'll likely
be more successful.

Also, before you use the fpga.program() function, you need to set the bof
file in the system information - I think I have mentioned how to do this in
the history of the mailing list somewhere before.

Let me know if it works.

Regards,
James


On Thu, Oct 12, 2017 at 12:35 PM, Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> And I'm using the latest version of casperfpga library and katcp version.
>
> On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hello James,
>>
>> I'm attaching the model files of the first and the second designs, along
>> with the bof and the fga files. I used the ipython terminal for programming
>> the fpga in both cases. The error I obtained is attached in a text file.
>>
>> Hope this helps,
>>
>> Thank you,
>>
>> Mugundhan V.
>>
>>
>>
>> On Thu, Oct 12, 2017 at 3:49 PM, James Smith  wrote:
>>
>>> Hello Mugundhan,
>>>
>>> Please describe your context a bit more - what libraries are you using?
>>> Please also paste the error that you get? (and perhaps the code you used to
>>> generate the error.)
>>>
>>> Regards,
>>> James
>>>
>>>
>>> On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
>>> v.vaishnav151...@gmail.com> wrote:
>>>
 Hi,

 I'm facing a strange problem. I have an iADC, which I've connected to
 roach1 and have compiled a program to acquire raw samples from it. The
 simulation, compilation and generation works fine and I get the bof and the
 fpg files, which i place in their respective locations, and the ROACH gets
 programmed well.

 I also developed a iADC spectropolarimeter and generated the fpg and
 bof files and placed them in their locations, but now when I try
 programming the ROACH, i get Katcp request time out error. If i reprogram
 the first bof file, it works fine, but repeated compilation and program
 cycles have failed for hte second model, with the same katcp request failed
 error.

 Can someone kindly guide me solving it ?

 Thank you,

 --
 V. Mugundhan
 SRF, IIA

 --
 You received this message because you are subscribed to the Google
 Groups "casper@lists.berkeley.edu" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to casper+unsubscr...@lists.berkeley.edu.
 To post to this group, send email to casper@lists.berkeley.edu.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>
>>
>>
>>
>> --
>> V. Mugundhan
>> SRF, IIA
>>
>
>
>
> --
> V. Mugundhan
> SRF, IIA
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] ROACH1 Programming issues

[Mugundhan vijayaraghavan]

And I'm using the latest version of casperfpga library and katcp version.

On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> Hello James,
>
> I'm attaching the model files of the first and the second designs, along
> with the bof and the fga files. I used the ipython terminal for programming
> the fpga in both cases. The error I obtained is attached in a text file.
>
> Hope this helps,
>
> Thank you,
>
> Mugundhan V.
>
>
>
> On Thu, Oct 12, 2017 at 3:49 PM, James Smith  wrote:
>
>> Hello Mugundhan,
>>
>> Please describe your context a bit more - what libraries are you using?
>> Please also paste the error that you get? (and perhaps the code you used to
>> generate the error.)
>>
>> Regards,
>> James
>>
>>
>> On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm facing a strange problem. I have an iADC, which I've connected to
>>> roach1 and have compiled a program to acquire raw samples from it. The
>>> simulation, compilation and generation works fine and I get the bof and the
>>> fpg files, which i place in their respective locations, and the ROACH gets
>>> programmed well.
>>>
>>> I also developed a iADC spectropolarimeter and generated the fpg and bof
>>> files and placed them in their locations, but now when I try programming
>>> the ROACH, i get Katcp request time out error. If i reprogram the first bof
>>> file, it works fine, but repeated compilation and program cycles have
>>> failed for hte second model, with the same katcp request failed error.
>>>
>>> Can someone kindly guide me solving it ?
>>>
>>> Thank you,
>>>
>>> --
>>> V. Mugundhan
>>> SRF, IIA
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>
>
>
> --
> V. Mugundhan
> SRF, IIA
>



-- 
V. Mugundhan
SRF, IIA

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] ROACH1 Programming issues

[James Smith]

Hello Mugundhan,

Please describe your context a bit more - what libraries are you using?
Please also paste the error that you get? (and perhaps the code you used to
generate the error.)

Regards,
James


On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> Hi,
>
> I'm facing a strange problem. I have an iADC, which I've connected to
> roach1 and have compiled a program to acquire raw samples from it. The
> simulation, compilation and generation works fine and I get the bof and the
> fpg files, which i place in their respective locations, and the ROACH gets
> programmed well.
>
> I also developed a iADC spectropolarimeter and generated the fpg and bof
> files and placed them in their locations, but now when I try programming
> the ROACH, i get Katcp request time out error. If i reprogram the first bof
> file, it works fine, but repeated compilation and program cycles have
> failed for hte second model, with the same katcp request failed error.
>
> Can someone kindly guide me solving it ?
>
> Thank you,
>
> --
> V. Mugundhan
> SRF, IIA
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] ROACH1 serial to USB connection

[Marc Welz]

This is a bit hazy, but I think that might be because the processor
hasn't stopped properly - some permutation of rebooting, unplugging
and pressing the halt button on the GUI repeatedly sometimes helps.
Also check if the processor isn't running in an overclocked
configuration

regards

marc

On Mon, Apr 3, 2017 at 1:07 PM, Heystek Grobler
 wrote:
> Hi Jason
>
> Its really no problem.
>
> I used the steps that you have send me with a ST-link V2 J-TAG (It is almost
> like the USB wiggler). I can open up a serail connection with Hyperterminal
> and open up an connection with the OCD Commander. Once i run the Macro I get
> the following error:
>
> Write large: processor running (40:0C)
>
> and
>
> An error occured during the execution of your Marco file. Exit Marco
> execution now?
>
> and then nothing happens.
>
> Thanks for your help!!
>
> Heystek
>
> On Fri, Mar 31, 2017 at 9:27 PM, Jason Ray  wrote:
>>
>> Heystek,
>>
>> Sorry for the delay in replying.
>>
>> I'm not sure about the converter script.  Every time I've debricked a
>> roach, I used our USB wiggler, and followed these steps:
>>
>> http://www2.asiaa.sinica.edu.tw/~homin/wiki/pmwiki-2.1.27/uploads/HiSpeedDigital/fileHow_to_update_uboot_file_if_ROACH_cannot_bootup.pdf
>>
>> And, this procedure as well...
>> https://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update
>>
>> Hope this helps,
>> Jason
>>
>>
>>
>> On 3/29/2017 8:45 AM, Heystek Grobler wrote:
>>
>> Hi Jason
>>
>> I got my hands on a JTAG. I went through the CASPER debricking tutorial
>> page but I dont understand how to use the converter script? Do you perhaps
>> know how to use it?
>>
>> Thanks for all of your help
>>
>> Heystek
>>
>> On Mon, Mar 27, 2017 at 11:54 AM, Heystek Grobler
>>  wrote:
>>>
>>> Hi Jason
>>>
>>> Yes, all flow control is off. both the (Xon/Xoff or DC1/DC3) is off.
>>>
>>> On Mon, Mar 27, 2017 at 11:32 AM, Jason Manley  wrote:

 You've checked that hardware flow control is turned off on your serial
 port?

 Jason


 On 27 Mar 2017, at 11:29, Heystek Grobler 
 wrote:

 > Hi Jason
 >
 > The ROACH1 is a brand new board that we just unboxed. I tried
 > connecing to it using two diffirent serial to usb cables and both gave 
 > the
 > same result, a connection to the board, but the terminal only displays a
 > black screen. No Uboot sequence or any kind of output.
 >
 > I will double check by shorting pins 2 & 3 and see if I get anyyhing
 > on the terminal.
 >
 > If I am right if I say I think that the roach might be bricked?
 >
 > Thanks for all the help
 >
 > Heystek
 >
 > On Wed, Mar 22, 2017 at 9:23 PM, Jason Ray  wrote:
 > Heystek,
 >
 > Is this a known good roach1 board?  Could it have been bricked by
 > chance?  If so it will behave like you describe and you may need to do 
 > this:
 >
 > https://casper.berkeley.edu/wiki/ROACH_Debricking
 >
 > Another thing you can try if you haven't already is to swap pins 2 &
 > 3.  Even if you have a null modem cable, something else could be going on
 > (with the adapter perhaps.?) and it never hurts to just swap 2 & 3 and 
 > give
 > it another try.
 >
 > Also, a simple thing you can do to verify your serial adapter is
 > working is to do a loopback, short pins 2 & 3 together, then type 
 > something
 > in the terminal and see if it displays on the screen.
 >
 > Good luck,
 > Jason
 >
 >
 >
 >
 > On 3/22/2017 3:08 PM, Heystek Grobler wrote:
 >> Hi
 >>
 >> When I use dev/tty* I can see the adapter. This is the adapter Im
 >> using
 >>
 >> https://www.unitek-products.com/en/product_detail.php?id=12
 >>
 >>
 >> On Wed, 22 Mar 2017 at 9:05 PM Jack Hickish 
 >> wrote:
 >> H. And the adapter definitely works?
 >>
 >> Sorry, I think you're going to need someone smarter than me.
 >>
 >> On Wed, 22 Mar 2017 at 11:06 Heystek Grobler
 >>  wrote:
 >> Hi Jack
 >>
 >> Jip it is the null-modem type with the 9 pins. If I open up an
 >> terminal connection through putty or minicom I can open up an connection
 >> with the 115200 8N1 settings, but I cant see Uboot. I can only see 'n 
 >> blank
 >> terminal window.
 >>
 >>
 >> On Wed, 22 Mar 2017 at 7:24 PM Jack Hickish 
 >> wrote:
 >> Hi Heystek,
 >>
 >> Just to be clear, you're connecting to the 9 pin serial connector on
 >> the ROACH (not the USB port)?
 >> If you're using a serial cable between the ROACH and your USB
 >> adapter, is it the correct null-modem type?
 >> Do you have the correct comms settings? -- roach1 is 115200 8N1
 >>
 >> Some info which might help is at
 >> https://casper.berkeley.edu/wiki/ROACH_NFS_guide#Preliminary_setup_1:_The_serial_connection
 >>
 >> Cheers
 >> Jack
 >>
 >> On Wed, 22 Mar 2

Re: [casper] ROACH1 serial to USB connection

[Heystek Grobler]

Hi Jason

Its really no problem.

I used the steps that you have send me with a ST-link V2 J-TAG (It is
almost like the USB wiggler). I can open up a serail connection with
Hyperterminal and open up an connection with the OCD Commander. Once i run
the Macro I get the following error:

Write large: processor running (40:0C)

and

An error occured during the execution of your Marco file. Exit Marco
execution now?

and then nothing happens.

Thanks for your help!!

Heystek

On Fri, Mar 31, 2017 at 9:27 PM, Jason Ray  wrote:

> Heystek,
>
> Sorry for the delay in replying.
>
> I'm not sure about the converter script.  Every time I've debricked a
> roach, I used our USB wiggler, and followed these steps:
> http://www2.asiaa.sinica.edu.tw/~homin/wiki/pmwiki-2.1.27/
> uploads/HiSpeedDigital/fileHow_to_update_uboot_file_
> if_ROACH_cannot_bootup.pdf
>
> And, this procedure as well...
> https://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update
>
> Hope this helps,
> Jason
>
>
>
> On 3/29/2017 8:45 AM, Heystek Grobler wrote:
>
> Hi Jason
>
> I got my hands on a JTAG. I went through the CASPER debricking tutorial
> page but I dont understand how to use the converter script? Do you perhaps
> know how to use it?
>
> Thanks for all of your help
>
> Heystek
>
> On Mon, Mar 27, 2017 at 11:54 AM, Heystek Grobler <
> heystekgrob...@gmail.com> wrote:
>
>> Hi Jason
>>
>> Yes, all flow control is off. both the (Xon/Xoff or DC1/DC3) is off.
>>
>> On Mon, Mar 27, 2017 at 11:32 AM, Jason Manley  wrote:
>>
>>> You've checked that hardware flow control is turned off on your serial
>>> port?
>>>
>>> Jason
>>>
>>>
>>> On 27 Mar 2017, at 11:29, Heystek Grobler 
>>> wrote:
>>>
>>> > Hi Jason
>>> >
>>> > The ROACH1 is a brand new board that we just unboxed. I tried
>>> connecing to it using two diffirent serial to usb cables and both gave the
>>> same result, a connection to the board, but the terminal only displays a
>>> black screen. No Uboot sequence or any kind of output.
>>> >
>>> > I will double check by shorting pins 2 & 3 and see if I get anyyhing
>>> on the terminal.
>>> >
>>> > If I am right if I say I think that the roach might be bricked?
>>> >
>>> > Thanks for all the help
>>> >
>>> > Heystek
>>> >
>>> > On Wed, Mar 22, 2017 at 9:23 PM, Jason Ray  wrote:
>>> > Heystek,
>>> >
>>> > Is this a known good roach1 board?  Could it have been bricked by
>>> chance?  If so it will behave like you describe and you may need to do this:
>>> >
>>> > https://casper.berkeley.edu/wiki/ROACH_Debricking
>>> >
>>> > Another thing you can try if you haven't already is to swap pins 2 &
>>> 3.  Even if you have a null modem cable, something else could be going on
>>> (with the adapter perhaps.?) and it never hurts to just swap 2 & 3 and give
>>> it another try.
>>> >
>>> > Also, a simple thing you can do to verify your serial adapter is
>>> working is to do a loopback, short pins 2 & 3 together, then type something
>>> in the terminal and see if it displays on the screen.
>>> >
>>> > Good luck,
>>> > Jason
>>> >
>>> >
>>> >
>>> >
>>> > On 3/22/2017 3:08 PM, Heystek Grobler wrote:
>>> >> Hi
>>> >>
>>> >> When I use dev/tty* I can see the adapter. This is the adapter Im
>>> using
>>> >>
>>> >> https://www.unitek-products.com/en/product_detail.php?id=12
>>> >>
>>> >>
>>> >> On Wed, 22 Mar 2017 at 9:05 PM Jack Hickish 
>>> wrote:
>>> >> H. And the adapter definitely works?
>>> >>
>>> >> Sorry, I think you're going to need someone smarter than me.
>>> >>
>>> >> On Wed, 22 Mar 2017 at 11:06 Heystek Grobler <
>>> heystekgrob...@gmail.com> wrote:
>>> >> Hi Jack
>>> >>
>>> >> Jip it is the null-modem type with the 9 pins. If I open up an
>>> terminal connection through putty or minicom I can open up an connection
>>> with the 115200 8N1 settings, but I cant see Uboot. I can only see 'n blank
>>> terminal window.
>>> >>
>>> >>
>>> >> On Wed, 22 Mar 2017 at 7:24 PM Jack Hickish 
>>> wrote:
>>> >> Hi Heystek,
>>> >>
>>> >> Just to be clear, you're connecting to the 9 pin serial connector on
>>> the ROACH (not the USB port)?
>>> >> If you're using a serial cable between the ROACH and your USB
>>> adapter, is it the correct null-modem type?
>>> >> Do you have the correct comms settings? -- roach1 is 115200 8N1
>>> >>
>>> >> Some info which might help is at https://casper.berkeley.edu/wi
>>> ki/ROACH_NFS_guide#Preliminary_setup_1:_The_serial_connection
>>> >>
>>> >> Cheers
>>> >> Jack
>>> >>
>>> >> On Wed, 22 Mar 2017 at 05:39 Heystek Grobler <
>>> heystekgrob...@gmail.com> wrote:
>>> >> Good day everyone
>>> >>
>>> >> I am trying to connect to a ROACH1 board with a serial to usb cable.
>>> I have tried the connection through putty and minicom. I can open up a
>>> serial connection but I can not see the U-Boot loader kicking in and watch
>>> the start up sequence. I also have ROACH2 and I can see U-Boot and the
>>> start up sequence fine in it with a USB cable.
>>> >>
>>> >> Do you perhaps know what the problem could be that I am not getting
>>> is right 

Re: [casper] ROACH1 serial to USB connection

[Jason Ray]

Heystek,

Sorry for the delay in replying.

I'm not sure about the converter script.  Every time I've debricked a 
roach, I used our USB wiggler, and followed these steps:

http://www2.asiaa.sinica.edu.tw/~homin/wiki/pmwiki-2.1.27/uploads/HiSpeedDigital/fileHow_to_update_uboot_file_if_ROACH_cannot_bootup.pdf

And, this procedure as well...
https://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update

Hope this helps,
Jason


On 3/29/2017 8:45 AM, Heystek Grobler wrote:

Hi Jason

I got my hands on a JTAG. I went through the CASPER debricking 
tutorial page but I dont understand how to use the converter script? 
Do you perhaps know how to use it?


Thanks for all of your help

Heystek

On Mon, Mar 27, 2017 at 11:54 AM, Heystek Grobler 
mailto:heystekgrob...@gmail.com>> wrote:


Hi Jason

Yes, all flow control is off. both the (Xon/Xoff or DC1/DC3) is off.

On Mon, Mar 27, 2017 at 11:32 AM, Jason Manley mailto:jman...@ska.ac.za>> wrote:

You've checked that hardware flow control is turned off on
your serial port?

Jason


On 27 Mar 2017, at 11:29, Heystek Grobler
mailto:heystekgrob...@gmail.com>>
wrote:

> Hi Jason
>
> The ROACH1 is a brand new board that we just unboxed. I
tried connecing to it using two diffirent serial to usb cables
and both gave the same result, a connection to the board, but
the terminal only displays a black screen. No Uboot sequence
or any kind of output.
>
> I will double check by shorting pins 2 & 3 and see if I get
anyyhing on the terminal.
>
> If I am right if I say I think that the roach might be bricked?
>
> Thanks for all the help
>
> Heystek
>
> On Wed, Mar 22, 2017 at 9:23 PM, Jason Ray mailto:j...@nrao.edu>> wrote:
> Heystek,
>
> Is this a known good roach1 board?  Could it have been
bricked by chance?  If so it will behave like you describe and
you may need to do this:
>
> https://casper.berkeley.edu/wiki/ROACH_Debricking

>
> Another thing you can try if you haven't already is to swap
pins 2 & 3.  Even if you have a null modem cable, something
else could be going on (with the adapter perhaps.?) and it
never hurts to just swap 2 & 3 and give it another try.
>
> Also, a simple thing you can do to verify your serial
adapter is working is to do a loopback, short pins 2 & 3
together, then type something in the terminal and see if it
displays on the screen.
>
> Good luck,
> Jason
>
>
>
>
> On 3/22/2017 3:08 PM, Heystek Grobler wrote:
>> Hi
>>
>> When I use dev/tty* I can see the adapter. This is the
adapter Im using
>>
>> https://www.unitek-products.com/en/product_detail.php?id=12

>>
>>
>> On Wed, 22 Mar 2017 at 9:05 PM Jack Hickish
mailto:jackhick...@gmail.com>> wrote:
>> H. And the adapter definitely works?
>>
>> Sorry, I think you're going to need someone smarter than me.
>>
>> On Wed, 22 Mar 2017 at 11:06 Heystek Grobler
mailto:heystekgrob...@gmail.com>>
wrote:
>> Hi Jack
>>
>> Jip it is the null-modem type with the 9 pins. If I open up
an terminal connection through putty or minicom I can open up
an connection with the 115200 8N1 settings, but I cant see
Uboot. I can only see 'n blank terminal window.
>>
>>
>> On Wed, 22 Mar 2017 at 7:24 PM Jack Hickish
mailto:jackhick...@gmail.com>> wrote:
>> Hi Heystek,
>>
>> Just to be clear, you're connecting to the 9 pin serial
connector on the ROACH (not the USB port)?
>> If you're using a serial cable between the ROACH and your
USB adapter, is it the correct null-modem type?
>> Do you have the correct comms settings? -- roach1 is 115200 8N1
>>
>> Some info which might help is at

https://casper.berkeley.edu/wiki/ROACH_NFS_guide#Preliminary_setup_1:_The_serial_connection


>>
>> Cheers
>> Jack
>>
>> On Wed, 22 Mar 2017 at 05:39 Heystek Grobler
mailto:heystekgrob...@gmail.com>>
wrote:
>> Good day everyone
>>
>> I am trying to connect to a ROACH1 board with a serial to
usb cable. I have tried the connection through putty and
minicom. I can open up a serial connection but I can not see
the U-Boot loader kicking in and wa

Re: [casper] ROACH1 serial to USB connection

[Heystek Grobler]

Hi Jason

I got my hands on a JTAG. I went through the CASPER debricking tutorial
page but I dont understand how to use the converter script? Do you perhaps
know how to use it?

Thanks for all of your help

Heystek

On Mon, Mar 27, 2017 at 11:54 AM, Heystek Grobler 
wrote:

> Hi Jason
>
> Yes, all flow control is off. both the (Xon/Xoff or DC1/DC3) is off.
>
> On Mon, Mar 27, 2017 at 11:32 AM, Jason Manley  wrote:
>
>> You've checked that hardware flow control is turned off on your serial
>> port?
>>
>> Jason
>>
>>
>> On 27 Mar 2017, at 11:29, Heystek Grobler 
>> wrote:
>>
>> > Hi Jason
>> >
>> > The ROACH1 is a brand new board that we just unboxed. I tried connecing
>> to it using two diffirent serial to usb cables and both gave the same
>> result, a connection to the board, but the terminal only displays a black
>> screen. No Uboot sequence or any kind of output.
>> >
>> > I will double check by shorting pins 2 & 3 and see if I get anyyhing on
>> the terminal.
>> >
>> > If I am right if I say I think that the roach might be bricked?
>> >
>> > Thanks for all the help
>> >
>> > Heystek
>> >
>> > On Wed, Mar 22, 2017 at 9:23 PM, Jason Ray  wrote:
>> > Heystek,
>> >
>> > Is this a known good roach1 board?  Could it have been bricked by
>> chance?  If so it will behave like you describe and you may need to do this:
>> >
>> > https://casper.berkeley.edu/wiki/ROACH_Debricking
>> >
>> > Another thing you can try if you haven't already is to swap pins 2 &
>> 3.  Even if you have a null modem cable, something else could be going on
>> (with the adapter perhaps.?) and it never hurts to just swap 2 & 3 and give
>> it another try.
>> >
>> > Also, a simple thing you can do to verify your serial adapter is
>> working is to do a loopback, short pins 2 & 3 together, then type something
>> in the terminal and see if it displays on the screen.
>> >
>> > Good luck,
>> > Jason
>> >
>> >
>> >
>> >
>> > On 3/22/2017 3:08 PM, Heystek Grobler wrote:
>> >> Hi
>> >>
>> >> When I use dev/tty* I can see the adapter. This is the adapter Im using
>> >>
>> >> https://www.unitek-products.com/en/product_detail.php?id=12
>> >>
>> >>
>> >> On Wed, 22 Mar 2017 at 9:05 PM Jack Hickish 
>> wrote:
>> >> H. And the adapter definitely works?
>> >>
>> >> Sorry, I think you're going to need someone smarter than me.
>> >>
>> >> On Wed, 22 Mar 2017 at 11:06 Heystek Grobler 
>> wrote:
>> >> Hi Jack
>> >>
>> >> Jip it is the null-modem type with the 9 pins. If I open up an
>> terminal connection through putty or minicom I can open up an connection
>> with the 115200 8N1 settings, but I cant see Uboot. I can only see 'n blank
>> terminal window.
>> >>
>> >>
>> >> On Wed, 22 Mar 2017 at 7:24 PM Jack Hickish 
>> wrote:
>> >> Hi Heystek,
>> >>
>> >> Just to be clear, you're connecting to the 9 pin serial connector on
>> the ROACH (not the USB port)?
>> >> If you're using a serial cable between the ROACH and your USB adapter,
>> is it the correct null-modem type?
>> >> Do you have the correct comms settings? -- roach1 is 115200 8N1
>> >>
>> >> Some info which might help is at https://casper.berkeley.edu/wi
>> ki/ROACH_NFS_guide#Preliminary_setup_1:_The_serial_connection
>> >>
>> >> Cheers
>> >> Jack
>> >>
>> >> On Wed, 22 Mar 2017 at 05:39 Heystek Grobler 
>> wrote:
>> >> Good day everyone
>> >>
>> >> I am trying to connect to a ROACH1 board with a serial to usb cable. I
>> have tried the connection through putty and minicom. I can open up a serial
>> connection but I can not see the U-Boot loader kicking in and watch the
>> start up sequence. I also have ROACH2 and I can see U-Boot and the start up
>> sequence fine in it with a USB cable.
>> >>
>> >> Do you perhaps know what the problem could be that I am not getting is
>> right on the ROACH1?
>> >>
>> >> Have a great day
>> >>
>> >> Heystek Grobler
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups "casper@lists.berkeley.edu" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an email to casper+unsubscr...@lists.berkeley.edu.
>> >> To post to this group, send email to casper@lists.berkeley.edu.
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups "casper@lists.berkeley.edu" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an email to casper+unsubscr...@lists.berkeley.edu.
>> >> To post to this group, send email to casper@lists.berkeley.edu.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "casper@lists.berkeley.edu" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to casper+unsubscr...@lists.berkeley.edu.
>> > To post to this group, send email to casper@lists.berkeley.edu.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "casper@lists.berkeley.edu" group.
>> > To unsubscribe from this group and stop rece

Re: [casper] ROACH1 serial to USB connection

[Heystek Grobler]

Hi Jason

The ROACH1 is a brand new board that we just unboxed. I tried connecing to
it using two diffirent serial to usb cables and both gave the same result,
a connection to the board, but the terminal only displays a black screen.
No Uboot sequence or any kind of output.

I will double check by shorting pins 2 & 3 and see if I get anyyhing on the
terminal.

If I am right if I say I think that the roach might be bricked?

Thanks for all the help

Heystek

On Wed, Mar 22, 2017 at 9:23 PM, Jason Ray  wrote:

> Heystek,
>
> Is this a known good roach1 board?  Could it have been bricked by chance?
> If so it will behave like you describe and you may need to do this:
>
> https://casper.berkeley.edu/wiki/ROACH_Debricking
>
> Another thing you can try if you haven't already is to swap pins 2 & 3.
> Even if you have a null modem cable, something else could be going on (with
> the adapter perhaps.?) and it never hurts to just swap 2 & 3 and give it
> another try.
>
> Also, a simple thing you can do to verify your serial adapter is working
> is to do a loopback, short pins 2 & 3 together, then type something in the
> terminal and see if it displays on the screen.
>
> Good luck,
> Jason
>
>
>
>
> On 3/22/2017 3:08 PM, Heystek Grobler wrote:
>
> Hi
>
> When I use dev/tty* I can see the adapter. This is the adapter Im using
>
> https://www.unitek-products.com/en/product_detail.php?id=12
>
>
> On Wed, 22 Mar 2017 at 9:05 PM Jack Hickish  wrote:
>
>> H. And the adapter definitely works?
>>
>> Sorry, I think you're going to need someone smarter than me.
>>
>> On Wed, 22 Mar 2017 at 11:06 Heystek Grobler 
>> wrote:
>>
>> Hi Jack
>>
>> Jip it is the null-modem type with the 9 pins. If I open up an terminal
>> connection through putty or minicom I can open up an connection with the
>> 115200 8N1 settings, but I cant see Uboot. I can only see 'n blank terminal
>> window.
>>
>>
>> On Wed, 22 Mar 2017 at 7:24 PM Jack Hickish 
>> wrote:
>>
>> Hi Heystek,
>>
>> Just to be clear, you're connecting to the 9 pin serial connector on the
>> ROACH (not the USB port)?
>> If you're using a serial cable between the ROACH and your USB adapter, is
>> it the correct null-modem type?
>> Do you have the correct comms settings? -- roach1 is 115200 8N1
>>
>> Some info which might help is at https://casper.berkeley.
>> edu/wiki/ROACH_NFS_guide#Preliminary_setup_1:_The_serial_connection
>>
>> Cheers
>> Jack
>>
>> On Wed, 22 Mar 2017 at 05:39 Heystek Grobler 
>> wrote:
>>
>> Good day everyone
>>
>> I am trying to connect to a ROACH1 board with a serial to usb cable. I
>> have tried the connection through putty and minicom. I can open up a serial
>> connection but I can not see the U-Boot loader kicking in and watch the
>> start up sequence. I also have ROACH2 and I can see U-Boot and the start up
>> sequence fine in it with a USB cable.
>>
>> Do you perhaps know what the problem could be that I am not getting is
>> right on the ROACH1?
>>
>> Have a great day
>>
>> Heystek Grobler
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "casper@lists.berkeley.edu"  group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Roach1!

[Jack Hickish]

On Sat, 9 Apr 2016 at 20:01 Rolando Paz  wrote:

> Hi Jack
>
> Today I had the opportunity to starting 3 ROACHs1, thanks to Dr. Stan from
> IRYA.
>
> Some doubts:
>
> a) When we starting two of the three Roachs1, we used minicom to
> communicate with them. Two of the roachs goes directly to "roach_login"
> where we put "root" and then we enter into an operating system.
>
> Does this means that the most recent versions of the Roach1, is no longer
> necessary to make this guide
> https://casper.berkeley.edu/wiki/ROACH_NFS_guide?
>

I think the ROACH used to ship with SD card file systems, so you're
probably booting off one of those. It was never necessary to set up NFS
unless you wanted them to boot from a remote file system. The main
advantage of this is it makes it much easier to manage systems with many
ROACH board.



>
> b) The third roach has password, and could not find it is. How we can
> change the user and password?
>
>
The most straightforward way is probably to just copy the SD card image
from one of your working ROACH boards, or from the svn links you found.



> Best Regards
>
> Rolando Paz
>
> 2016-04-09 19:30 GMT-06:00 Jack Hickish :
>
>> Hi Rolando,
>>
>>
>> I don't actually know what the right answer is, but if it were me I'd go
>> for one of --
>>
>> filesystem_etch_2010-03-24_sd_shipping.tar.gz
>> 
>> filesystem_etch_nfs.tar.gz
>> 
>>
>> and whichever kernel looks newest --
>> uImage-20110812-mmcomitfix
>> 
>> ?
>>
>> Good luck,
>>
>> Jack
>>
>> On Wed, 6 Apr 2016 at 22:43 Rolando Paz  wrote:
>>
>>> Regarding the kernel and filesystem, which you advise me to use?
>>>
>>> The kernel
>>> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/
>>>
>>> The filesystem
>>> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/
>>>
>>> Regards
>>>
>>> Rolando
>>>
>>> 2016-04-06 23:37 GMT-06:00 Jack Hickish :
>>>
 Hi Rolando,

 That guide should still be up to date and working.

 Jack

 On Wed, 6 Apr 2016 at 22:35 Rolando Paz  wrote:

> Thanks Jack.
>
> So, Can I follow this guide?
>
> https://casper.berkeley.edu/wiki/ROACH_NFS_guide
>
> Regards
>
> Rolando
>
>
> 2016-04-06 23:07 GMT-06:00 Jack Hickish :
>
>> Hi Rolando, CASPER,
>>
>> The ROACH should still be supported by all the CASPER tutorials which
>> are on the wiki -- https://casper.berkeley.edu/wiki/Tutorials
>>
>> Cheers,
>> Jack
>>
>>
>> On Wed, 6 Apr 2016 at 16:48 Rolando Paz  wrote:
>>
>>> Hi Jack
>>>
>>> The next Friday I will travel to Mexico to pick up one ROACH1!
>>> I was given the opportunity to program it!
>>> How you advise me to start learning to program a ROACH?
>>>
>>> Best Regards
>>>
>>> Rolando Paz
>>>
>>
>
>>>
>

Re: [casper] Roach1!

[Rolando Paz]

Hi Jack

Today I had the opportunity to starting 3 ROACHs1, thanks to Dr. Stan from
IRYA.

Some doubts:

a) When we starting two of the three Roachs1, we used minicom to
communicate with them. Two of the roachs goes directly to "roach_login"
where we put "root" and then we enter into an operating system.

Does this means that the most recent versions of the Roach1, is no longer
necessary to make this guide
https://casper.berkeley.edu/wiki/ROACH_NFS_guide?

b) The third roach has password, and could not find it is. How we can
change the user and password?

Best Regards

Rolando Paz

2016-04-09 19:30 GMT-06:00 Jack Hickish :

> Hi Rolando,
>
>
> I don't actually know what the right answer is, but if it were me I'd go
> for one of --
>
> filesystem_etch_2010-03-24_sd_shipping.tar.gz
> 
> filesystem_etch_nfs.tar.gz
> 
>
> and whichever kernel looks newest --
> uImage-20110812-mmcomitfix
> 
> ?
>
> Good luck,
>
> Jack
>
> On Wed, 6 Apr 2016 at 22:43 Rolando Paz  wrote:
>
>> Regarding the kernel and filesystem, which you advise me to use?
>>
>> The kernel
>> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/
>>
>> The filesystem
>> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/
>>
>> Regards
>>
>> Rolando
>>
>> 2016-04-06 23:37 GMT-06:00 Jack Hickish :
>>
>>> Hi Rolando,
>>>
>>> That guide should still be up to date and working.
>>>
>>> Jack
>>>
>>> On Wed, 6 Apr 2016 at 22:35 Rolando Paz  wrote:
>>>
 Thanks Jack.

 So, Can I follow this guide?

 https://casper.berkeley.edu/wiki/ROACH_NFS_guide

 Regards

 Rolando


 2016-04-06 23:07 GMT-06:00 Jack Hickish :

> Hi Rolando, CASPER,
>
> The ROACH should still be supported by all the CASPER tutorials which
> are on the wiki -- https://casper.berkeley.edu/wiki/Tutorials
>
> Cheers,
> Jack
>
>
> On Wed, 6 Apr 2016 at 16:48 Rolando Paz  wrote:
>
>> Hi Jack
>>
>> The next Friday I will travel to Mexico to pick up one ROACH1!
>> I was given the opportunity to program it!
>> How you advise me to start learning to program a ROACH?
>>
>> Best Regards
>>
>> Rolando Paz
>>
>

>>

Re: [casper] Roach1!

[Jack Hickish]

Hi Rolando,


I don't actually know what the right answer is, but if it were me I'd go
for one of --

filesystem_etch_2010-03-24_sd_shipping.tar.gz

filesystem_etch_nfs.tar.gz


and whichever kernel looks newest --
uImage-20110812-mmcomitfix

?

Good luck,

Jack

On Wed, 6 Apr 2016 at 22:43 Rolando Paz  wrote:

> Regarding the kernel and filesystem, which you advise me to use?
>
> The kernel
> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/
>
> The filesystem
> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/
>
> Regards
>
> Rolando
>
> 2016-04-06 23:37 GMT-06:00 Jack Hickish :
>
>> Hi Rolando,
>>
>> That guide should still be up to date and working.
>>
>> Jack
>>
>> On Wed, 6 Apr 2016 at 22:35 Rolando Paz  wrote:
>>
>>> Thanks Jack.
>>>
>>> So, Can I follow this guide?
>>>
>>> https://casper.berkeley.edu/wiki/ROACH_NFS_guide
>>>
>>> Regards
>>>
>>> Rolando
>>>
>>>
>>> 2016-04-06 23:07 GMT-06:00 Jack Hickish :
>>>
 Hi Rolando, CASPER,

 The ROACH should still be supported by all the CASPER tutorials which
 are on the wiki -- https://casper.berkeley.edu/wiki/Tutorials

 Cheers,
 Jack


 On Wed, 6 Apr 2016 at 16:48 Rolando Paz  wrote:

> Hi Jack
>
> The next Friday I will travel to Mexico to pick up one ROACH1!
> I was given the opportunity to program it!
> How you advise me to start learning to program a ROACH?
>
> Best Regards
>
> Rolando Paz
>

>>>
>

Re: [casper] Roach1!

[Rolando Paz]

Regarding the kernel and filesystem, which you advise me to use?

The kernel
https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/

The filesystem
https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/

Regards

Rolando

2016-04-06 23:37 GMT-06:00 Jack Hickish :

> Hi Rolando,
>
> That guide should still be up to date and working.
>
> Jack
>
> On Wed, 6 Apr 2016 at 22:35 Rolando Paz  wrote:
>
>> Thanks Jack.
>>
>> So, Can I follow this guide?
>>
>> https://casper.berkeley.edu/wiki/ROACH_NFS_guide
>>
>> Regards
>>
>> Rolando
>>
>>
>> 2016-04-06 23:07 GMT-06:00 Jack Hickish :
>>
>>> Hi Rolando, CASPER,
>>>
>>> The ROACH should still be supported by all the CASPER tutorials which
>>> are on the wiki -- https://casper.berkeley.edu/wiki/Tutorials
>>>
>>> Cheers,
>>> Jack
>>>
>>>
>>> On Wed, 6 Apr 2016 at 16:48 Rolando Paz  wrote:
>>>
 Hi Jack

 The next Friday I will travel to Mexico to pick up one ROACH1!
 I was given the opportunity to program it!
 How you advise me to start learning to program a ROACH?

 Best Regards

 Rolando Paz

>>>
>>

Re: [casper] Roach1!

[Jack Hickish]

Hi Rolando,

That guide should still be up to date and working.

Jack

On Wed, 6 Apr 2016 at 22:35 Rolando Paz  wrote:

> Thanks Jack.
>
> So, Can I follow this guide?
>
> https://casper.berkeley.edu/wiki/ROACH_NFS_guide
>
> Regards
>
> Rolando
>
>
> 2016-04-06 23:07 GMT-06:00 Jack Hickish :
>
>> Hi Rolando, CASPER,
>>
>> The ROACH should still be supported by all the CASPER tutorials which are
>> on the wiki -- https://casper.berkeley.edu/wiki/Tutorials
>>
>> Cheers,
>> Jack
>>
>>
>> On Wed, 6 Apr 2016 at 16:48 Rolando Paz  wrote:
>>
>>> Hi Jack
>>>
>>> The next Friday I will travel to Mexico to pick up one ROACH1!
>>> I was given the opportunity to program it!
>>> How you advise me to start learning to program a ROACH?
>>>
>>> Best Regards
>>>
>>> Rolando Paz
>>>
>>
>

Re: [casper] Roach1!

[Rolando Paz]

Thanks Jack.

So, Can I follow this guide?

https://casper.berkeley.edu/wiki/ROACH_NFS_guide

Regards

Rolando


2016-04-06 23:07 GMT-06:00 Jack Hickish :

> Hi Rolando, CASPER,
>
> The ROACH should still be supported by all the CASPER tutorials which are
> on the wiki -- https://casper.berkeley.edu/wiki/Tutorials
>
> Cheers,
> Jack
>
>
> On Wed, 6 Apr 2016 at 16:48 Rolando Paz  wrote:
>
>> Hi Jack
>>
>> The next Friday I will travel to Mexico to pick up one ROACH1!
>> I was given the opportunity to program it!
>> How you advise me to start learning to program a ROACH?
>>
>> Best Regards
>>
>> Rolando Paz
>>
>

Re: [casper] Roach1!

[Jack Hickish]

Hi Rolando, CASPER,

The ROACH should still be supported by all the CASPER tutorials which are
on the wiki -- https://casper.berkeley.edu/wiki/Tutorials

Cheers,
Jack

On Wed, 6 Apr 2016 at 16:48 Rolando Paz  wrote:

> Hi Jack
>
> The next Friday I will travel to Mexico to pick up one ROACH1!
> I was given the opportunity to program it!
> How you advise me to start learning to program a ROACH?
>
> Best Regards
>
> Rolando Paz
>

Re: [casper] ROACH1 10GbE routing

[Ramesh Karuppusamy]

Thanks Marc, I shall try the very first alternative for the time being.

Cheers,
Ramesh


> On 28 Oct 2015, at 10:10, Marc Welz  wrote:
> 
>> 
>> I use an ancient version of the core package, and here is the help on on 
>> tg_tap - no mention of a gateway here...
>> 
>> tap_start(self, tap_dev, device, mac, ip, port) method of 
>> corr.katcp_wrapper.FpgaClient instance
>>Program a 10GbE device and start the TAP driver.
>> 
>>@param self  This object.
>>@param device  String: name of the device (as in simulink name).
>>@param tap_dev  String: name of the tap device (a Linux identifier). If 
>> you want to destroy a device later, you need to use this name.
>>@param mac   integer: MAC address, 48 bits.
>>@param ipinteger: IP address, 32 bits.
>>@param port  integer: port of fabric interface (16 bits).
>> 
>>Please note that the function definition changed from corr-0.4.0 to 
>> corr-0.4.1 to include the tap_dev identifier.
> 
> Hmmm ... there are three options:
> 
> * Try to set the gateway manually - do serveral wordreads of the gbe0
> register, and then write the gateway into the 0xc offset. This is
> probably the quickest way of getting it going, but will only route
> gateware traffic
> 
> * try and extend tcpborphserver to add routing functionality, using
> the code from the new tcpborphserver3 as a guide. That is some effort
> and involves cross-compiling - and might also need a matching update
> to the corr package
> 
> * backport the mmap driver from roach2 to roach1 - that is the biggest
> chunk of work and involves  a bit of kernel hacking, and you
> personally might not be up for it - but if anybody else on the list
> has the energy it it would mean that the roach2 and roach1 userland
> could be pretty much merged, and things like multicast support would
> be available on roach1, in addition to the other fixes and features
> (.fpg files, etc)
> 
> regards
> 
> marc
> 
> 
>> 
>> Cheers,
>> Ramesh
>> 
>> 
>> 
>> 
>> 

Re: [casper] ROACH1 10GbE routing

[Marc Welz]

>
> I use an ancient version of the core package, and here is the help on on 
> tg_tap - no mention of a gateway here...
>
> tap_start(self, tap_dev, device, mac, ip, port) method of 
> corr.katcp_wrapper.FpgaClient instance
> Program a 10GbE device and start the TAP driver.
>
> @param self  This object.
> @param device  String: name of the device (as in simulink name).
> @param tap_dev  String: name of the tap device (a Linux identifier). If 
> you want to destroy a device later, you need to use this name.
> @param mac   integer: MAC address, 48 bits.
> @param ipinteger: IP address, 32 bits.
> @param port  integer: port of fabric interface (16 bits).
>
> Please note that the function definition changed from corr-0.4.0 to 
> corr-0.4.1 to include the tap_dev identifier.

Hmmm ... there are three options:

* Try to set the gateway manually - do serveral wordreads of the gbe0
register, and then write the gateway into the 0xc offset. This is
probably the quickest way of getting it going, but will only route
gateware traffic

* try and extend tcpborphserver to add routing functionality, using
the code from the new tcpborphserver3 as a guide. That is some effort
and involves cross-compiling - and might also need a matching update
to the corr package

* backport the mmap driver from roach2 to roach1 - that is the biggest
chunk of work and involves  a bit of kernel hacking, and you
personally might not be up for it - but if anybody else on the list
has the energy it it would mean that the roach2 and roach1 userland
could be pretty much merged, and things like multicast support would
be available on roach1, in addition to the other fixes and features
(.fpg files, etc)

regards

marc


>
> Cheers,
> Ramesh
>
>
>
>
>

Re: [casper] ROACH1 10GbE routing

[Ramesh Karuppusamy]

Hi Marc,

> Shouldn't you then have a route involving the tap0 interace with a G
> flag in it ?
> 

Sure - here is output after the route was added:

root@dhcpeff64253:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
10.0.0.00.0.0.0 255.255.255.0   U 0  00 tap0
10.0.2.010.0.0.200  255.255.255.0   UG0  00 tap0
134.104.64.00.0.0.0 255.255.240.0   U 0  00 eth0
0.0.0.0 134.104.64.16   0.0.0.0 UG0  00 eth0


>> I have enabled routing on the switch, and I can ping 10.0.2.20 from 
>> 10.0.0.11 on adding relevant static routes on both machines. However this 
>> doesn’t work for the ROACH1. What is going wrong here?
> 
> The tgtap logic handles arp and thus also needs to substitute the
> ethernet mac of the gateway - I don't remember when support was added
> for that - github/ska-sa/katcp_devel has the code in
> transmit_ip_fpga(), there is a chance you might have to backport it.
> However, this is for control traffic (packets that the kernel sends)
> only.
> 
> In the case of the packets being generated by gateware on the fpga,
> this substitution is made differently - I think the gateway register
> needs to be loaded up (at offset 0xc). Doesn't the tap-start call have
> an option for that ?


I use an ancient version of the core package, and here is the help on on tg_tap 
- no mention of a gateway here...

tap_start(self, tap_dev, device, mac, ip, port) method of 
corr.katcp_wrapper.FpgaClient instance
Program a 10GbE device and start the TAP driver.

@param self  This object.
@param device  String: name of the device (as in simulink name).
@param tap_dev  String: name of the tap device (a Linux identifier). If you 
want to destroy a device later, you need to use this name.
@param mac   integer: MAC address, 48 bits.
@param ipinteger: IP address, 32 bits.
@param port  integer: port of fabric interface (16 bits).

Please note that the function definition changed from corr-0.4.0 to 
corr-0.4.1 to include the tap_dev identifier.

Cheers,
Ramesh

Re: [casper] ROACH1 10GbE routing

[Marc Welz]

On Tue, Oct 27, 2015 at 2:46 PM, Ramesh Karuppusamy
 wrote:
>
> Hello List,
>
> For a set up here, we have a ROACH1 with it 10GbE (assigned to 10.0.0.30) 
> ports connected to a HP 5412l switch’s VLAN (subnet 10.0.0.0/24). Is there a 
> way to get the ROACH1’s 10GbE packets on a second VLAN (subnet 10.0.2.0/24) 
> on the same switch?
>
> On starting tgtap, the following routing table looks as follows on the ROACH1:
>
> root@dhcpeff64253:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> 10.0.0.00.0.0.0 255.255.255.0   U 0  00 tap0
> 134.104.64.00.0.0.0 255.255.240.0   U 0  00 eth0
> 0.0.0.0 134.104.64.16   0.0.0.0 UG0  00 eth0
>
>
> I did manually add a static route on the ROACH1 as soon as the gateway was 
> loaded: route add -net 10.0.2.0 netmask 255.255.255.0 gw 10.0.0.200 dev tap0

Shouldn't you then have a route involving the tap0 interace with a G
flag in it ?

> I have enabled routing on the switch, and I can ping 10.0.2.20 from 10.0.0.11 
> on adding relevant static routes on both machines. However this doesn’t work 
> for the ROACH1. What is going wrong here?

The tgtap logic handles arp and thus also needs to substitute the
ethernet mac of the gateway - I don't remember when support was added
for that - github/ska-sa/katcp_devel has the code in
transmit_ip_fpga(), there is a chance you might have to backport it.
However, this is for control traffic (packets that the kernel sends)
only.

In the case of the packets being generated by gateware on the fpga,
this substitution is made differently - I think the gateway register
needs to be loaded up (at offset 0xc). Doesn't the tap-start call have
an option for that ?

regards

marc


>
> Cheers,
> Ramesh

Re: [casper] Roach1 Host name lookup error.

[David MacMahon]

Hi, Brad,

On May 27, 2015, at 1:15 PM, Brad Dober wrote:

> Kernel command line: console=ttyS0,115200 
> mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20(root),54656k@0xa0(usr),256k@0x3f6(env),384k@0x3fa(uboot)fdt_addr=0xfc1c
>  root=192.168.40.1:/srv/roach_boot/etch ip=dhcp

I think you want "root=/dev/nfs rootpath=192.168.40.1:/srv/roach_boot/etch" 
instead of "root=192.168.40.1:/srv/roach_boot/etch".

Interrupt the u-boot startup and run "printenv" to see how this line gets 
constructed, then fix it, then run "saveenv" nd reboot.

The fact that this roach1 gets this far indicates that something is bad with 
the other one.

Dave

Re: [casper] Roach1 Host name lookup error.

[John Ford]

There was a very long thread about this new problem a few weeks ago. 
Bottom line is that it's likely that your host isn't exporting the
filesystem correctly, there's a typo in the DHCP offer, or some other such
host problem.  Look in the mail archives...

John


> So I plugged my other Roach1 that's in the lab into where the troubled
> Roach1 was sitting and started up the netboot. The uImage transferred fine
> this time, but I got another problem: *VFS: Unable to mount root fs via
> NFS, trying floppy.*
> *VFS: Cannot open root device "192.168.40.1:/srv/roach_boot/etch" or
> unknown-block(2,0)*
> *Please append a correct "root=" boot option; here are the available
> partitions:*
>
> Full boot up dump below:
>
> Hit any key to stop autoboot: 10 \0x08\0x08\0x08 0
>
> => run netboot
>
> Waiting for PHY auto negotiation to complete.. done
>
> ENET Speed is 100 Mbps - FULL duplex connection (EMAC0)
>
> BOOTP broadcast 1
>
> DHCP client bound to address 192.168.100.51
>
> Using ppc_4xx_eth0 device
>
> TFTP from server 192.168.40.1; our IP address is 192.168.100.51
>
> Filename 'uImage'.
>
> Load address: 0x40
>
> Loading:
> *\0x08#
>
> \0x09 #
>
> \0x09 #
>
> \0x09 #
>
> \0x09 
>
> done
>
> Bytes transferred = 1390149 (153645 hex)
>
> ## Booting kernel from Legacy Image at 0040 ...
>
> Image Name: Linux-2.6.25-svn3489
>
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
>
> Data Size: 1390085 Bytes = 1.3 MB
>
> Load Address: 
>
> Entry Point: 
>
> Verifying Checksum ... OK
>
> Uncompressing Kernel Image ... OK
>
>
> id mach(): done
>
>
>
> MMU:enter
>
>
>
> MMU:hw init
>
>
>
> MMU:mapin
>
>
>
> MMU:setio
>
>
>
> MMU:exit
>
>
>
> setup_arch: enter
>
>
>
> setup_arch: bootmem
>
>
>
> ocp: exit
>
>
>
> arch: exit
>
>
> Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri Aug
> 12 09:36:28 SAST 2011
>
> AMCC PowerPC 440EPx Roach Platform
>
> Zone PFN ranges:
>
> DMA 0 -> 131071
>
> Normal 131071 -> 131071
>
> Movable zone start PFN for each node
>
> early_node_map[1] active PFN ranges
>
> 0: 0 -> 131071
>
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
>
> Kernel command line: console=ttyS0,115200
> mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20
> (root),54656k@0xa0(usr),256k@0x3f6(env),384k@0x3fa(uboot)fdt_addr=0xfc1c
> root=192.168.40.1:/srv/roach_boot/etch ip=dhcp
>
> PID hash table entries: 2048 (order: 11, 8192 bytes)
>
> console [ttyS0] enabled
>
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
>
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
>
> Memory: 516608k available (2084k kernel code, 720k data, 132k init, 0k
> highmem)
>
> Mount-cache hash table entries: 512
>
> BORPH version CVS-$Revision: 1.10 $ Initialized
>
> net_namespace: 152 bytes
>
> NET: Registered protocol family 16
>
>
>
> PCI: Probing PCI hardware
>
> SCSI subsystem initialized
>
> usbcore: registered new interface driver usbfs
>
> usbcore: registered new interface driver hub
>
> usbcore: registered new device driver usb
>
> NET: Registered protocol family 2
>
> IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
>
> TCP established hash table entries: 16384 (order: 5, 131072 bytes)
>
> TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
>
> TCP: Hash tables configured (established 16384 bind 16384)
>
> TCP reno registered
>
> hwrtype_roach version CVS-$Revision: 1.1 $ registered
>
> JFFS2 version 2.2. (NAND) \0xc2\0xa9 2001-2006 Red Hat, Inc.
>
> io scheduler noop registered (default)
>
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
>
> serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
>
> serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
>
> serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 16550A
>
> serial8250: ttyS3 at MMIO 0x0 (irq = 36) is a 16550A
>
> brd: module loaded
>
> PPC 4xx OCP EMAC driver, version 3.54
>
> mal0: initialized, 2 TX channels, 2 RX channels
>
> rgmii0: input 0 in RGMII mode
>
> eth0: emac0, MAC 02:00:00:02:01:02
>
> eth0: found Generic MII PHY (0x1e)
>
> rgmii0: input 1 in RGMII mode
>
> emac1: can't find PHY!
>
> tun: Universal TUN/TAP device driver, 1.6
>
> tun: (C) 1999-2004 Max Krasnyansky 
>
> Driver 'sd' needs updating - please use bus_type methods
>
> physmap platform flash device: 0400 at fc00
>
> physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
>
> Amd/Fujitsu Extended Query Table at 0x0040
>
> physmap-flash.0: CFI does not contain boot bank location. Assuming top.
>
> number of CFI chips: 1
>
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
>
> mtd: bad character after partition (f)
>
> 6 cmdli

Re: [casper] Roach1 Host name lookup error.

[Brad Dober]

So I plugged my other Roach1 that's in the lab into where the troubled
Roach1 was sitting and started up the netboot. The uImage transferred fine
this time, but I got another problem: *VFS: Unable to mount root fs via
NFS, trying floppy.*
*VFS: Cannot open root device "192.168.40.1:/srv/roach_boot/etch" or
unknown-block(2,0)*
*Please append a correct "root=" boot option; here are the available
partitions:*

Full boot up dump below:

Hit any key to stop autoboot: 10 \0x08\0x08\0x08 0

=> run netboot

Waiting for PHY auto negotiation to complete.. done

ENET Speed is 100 Mbps - FULL duplex connection (EMAC0)

BOOTP broadcast 1

DHCP client bound to address 192.168.100.51

Using ppc_4xx_eth0 device

TFTP from server 192.168.40.1; our IP address is 192.168.100.51

Filename 'uImage'.

Load address: 0x40

Loading:
*\0x08#

\0x09 #

\0x09 #

\0x09 #

\0x09 

done

Bytes transferred = 1390149 (153645 hex)

## Booting kernel from Legacy Image at 0040 ...

Image Name: Linux-2.6.25-svn3489

Image Type: PowerPC Linux Kernel Image (gzip compressed)

Data Size: 1390085 Bytes = 1.3 MB

Load Address: 

Entry Point: 

Verifying Checksum ... OK

Uncompressing Kernel Image ... OK


id mach(): done



MMU:enter



MMU:hw init



MMU:mapin



MMU:setio



MMU:exit



setup_arch: enter



setup_arch: bootmem



ocp: exit



arch: exit


Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri Aug
12 09:36:28 SAST 2011

AMCC PowerPC 440EPx Roach Platform

Zone PFN ranges:

DMA 0 -> 131071

Normal 131071 -> 131071

Movable zone start PFN for each node

early_node_map[1] active PFN ranges

0: 0 -> 131071

Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048

Kernel command line: console=ttyS0,115200
mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20
(root),54656k@0xa0(usr),256k@0x3f6(env),384k@0x3fa(uboot)fdt_addr=0xfc1c
root=192.168.40.1:/srv/roach_boot/etch ip=dhcp

PID hash table entries: 2048 (order: 11, 8192 bytes)

console [ttyS0] enabled

Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)

Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

Memory: 516608k available (2084k kernel code, 720k data, 132k init, 0k
highmem)

Mount-cache hash table entries: 512

BORPH version CVS-$Revision: 1.10 $ Initialized

net_namespace: 152 bytes

NET: Registered protocol family 16



PCI: Probing PCI hardware

SCSI subsystem initialized

usbcore: registered new interface driver usbfs

usbcore: registered new interface driver hub

usbcore: registered new device driver usb

NET: Registered protocol family 2

IP route cache hash table entries: 4096 (order: 2, 16384 bytes)

TCP established hash table entries: 16384 (order: 5, 131072 bytes)

TCP bind hash table entries: 16384 (order: 4, 65536 bytes)

TCP: Hash tables configured (established 16384 bind 16384)

TCP reno registered

hwrtype_roach version CVS-$Revision: 1.1 $ registered

JFFS2 version 2.2. (NAND) \0xc2\0xa9 2001-2006 Red Hat, Inc.

io scheduler noop registered (default)

Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled

serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A

serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A

serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 16550A

serial8250: ttyS3 at MMIO 0x0 (irq = 36) is a 16550A

brd: module loaded

PPC 4xx OCP EMAC driver, version 3.54

mal0: initialized, 2 TX channels, 2 RX channels

rgmii0: input 0 in RGMII mode

eth0: emac0, MAC 02:00:00:02:01:02

eth0: found Generic MII PHY (0x1e)

rgmii0: input 1 in RGMII mode

emac1: can't find PHY!

tun: Universal TUN/TAP device driver, 1.6

tun: (C) 1999-2004 Max Krasnyansky 

Driver 'sd' needs updating - please use bus_type methods

physmap platform flash device: 0400 at fc00

physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank

Amd/Fujitsu Extended Query Table at 0x0040

physmap-flash.0: CFI does not contain boot bank location. Assuming top.

number of CFI chips: 1

cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.

mtd: bad character after partition (f)

6 cmdlinepart partitions found on MTD device physmap-flash.0

Creating 6 MTD partitions on "physmap-flash.0":

0x-0x001c : "linux"

0x001c-0x0020 : "fdt"

0x0020-0x00a0 : "root"

0x00a0-0x03f6 : "usr"

0x03f6-0x03fa : "env"

0x03fa-0x0400 : "uboot"

ppc-soc-ohci ppc-soc-ohci.0: USB Host Controller

ppc-soc-ohci ppc-soc-ohci.0: new USB bus registered, assigned bus number 1

ppc-soc-ohci ppc-soc-ohci.0: irq 21, io mem 0xe400

usb usb1: configuration #1 chosen from 1 choice

hub 1-0:1.0: USB hub found

hub 1-0:1.0: 1 port detected

usb usb1:

Re: [casper] Roach1 Host name lookup error.

[David MacMahon]

Hi, Brad,

On May 27, 2015, at 9:37 AM, Brad Dober wrote:

> I have no issues with the Roach2 that is also connected to this host computer.

No issues meaning that you can tftp the uImage file from the server to the 
roach2?  Does tcpdump/wireshark show any clues vis a vis the ROACH1's attempted 
tftp transfer?

> I switched the Roach1's and Roach'2 ethernet cables and still have the same 
> problem on the Roach1 and Roach2 is still working fine.

Did this also swap the switch ports?

> Which pins / voltages should I be checking on the power supply?

I'd check all of them.  I think it's a standard ATX power supply, but the wiki 
might have more details.

Maybe try reseating (or replacing) the ROACH1 PPC's DIMM module?  I guess it 
was working OK with soloboot/usbboot until the root filesystem got corrupted, 
so maybe this isn't really relevant?

> U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)

I don't know of any specific problems, but you might want to consider updating 
uboot...

https://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update

https://casper.berkeley.edu/wiki/LatestVersions

Dave

Re: [casper] Roach1 Host name lookup error.

[Brad Dober]

I have no issues with the Roach2 that is also connected to this host
computer.
I switched the Roach1's and Roach'2 ethernet cables and still have the same
problem on the Roach1 and Roach2 is still working fine.

Which pins / voltages should I be checking on the power supply?


Brad Dober
Ph.D. Candidate
Department of Physics and Astronomy
University of Pennsylvania
Cell: 262-949-4668

On Wed, May 27, 2015 at 11:59 AM, David MacMahon 
wrote:

> Hi, Brad,
>
> On May 27, 2015, at 8:09 AM, Brad Dober wrote:
>
> > TFTP from server 192.168.40.1; our IP address is 192.168.100.50
> > Filename 'uImage'.
> > Load address: 0x40
> > Loading: *\0x08###T T T #T ##T T T #T ##T T #
>
> The 'T' characters are timeouts waiting for data from the tftp server.
> The '#' characters show that some data is getting through.  This suggests
> an intermittent communication problem and/or marginal operating
> conditions.  Have you tried a different (and known good) network cable?
> Can other hosts (e.g. a laptop) DHCP and tftp from the server OK?  Have you
> checked the ROACH1 power supply voltages?
>
> Dave
>
>

Re: [casper] Roach1 Host name lookup error.

[David MacMahon]

Hi, Brad,

On May 27, 2015, at 8:09 AM, Brad Dober wrote:

> TFTP from server 192.168.40.1; our IP address is 192.168.100.50
> Filename 'uImage'.
> Load address: 0x40
> Loading: *\0x08###T T T #T ##T T T #T ##T T #

The 'T' characters are timeouts waiting for data from the tftp server.  The '#' 
characters show that some data is getting through.  This suggests an 
intermittent communication problem and/or marginal operating conditions.  Have 
you tried a different (and known good) network cable?  Can other hosts (e.g. a 
laptop) DHCP and tftp from the server OK?  Have you checked the ROACH1 power 
supply voltages?

Dave

Re: [casper] Roach1 Host name lookup error.

[Brad Dober]

So this is new. When I rebooted to check the boot process, it took the IP
address immediately, started loading Uboot, but restarted around block 162.
Wireshark shows multiple packets of the same number being send and
acknowledged.

Yes, I'm using dnsmasq.


U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)


CPU: AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz)

No Security/Kasumi support

Bootstrap Option C - Boot ROM Location EBC (16 bits)

32 kB I-Cache 32 kB D-Cache

Board: Roach

I2C: ready

DTT: 1 is 27 C

DRAM: (spd v1.2) dram: notice: ecc ignored

1 GB

FLASH: 64 MB

USB: Host(int phy) Device(ext phy)

Net: ppc_4xx_eth0


Roach Information

Serial Number: 030191

Monitor Revision: 8.3.1698

CPLD Revision: 8.0.1588


type run netboot to boot via dhcp+tftp+nfs

type run soloboot to run from flash without network

type run mmcboot to boot using filesystem on mmc/sdcard

type run usbboot to boot using filesystem on usb

type run bit to run tests


Hit any key to stop autoboot: 2 \0x08\0x08\0x08 0

=> run netboot

Waiting for PHY auto negotiation to complete.. done

ENET Speed is 100 Mbps - FULL duplex connection (EMAC0)

BOOTP broadcast 1

BOOTP broadcast 2

DHCP client bound to address 192.168.100.50

Using ppc_4xx_eth0 device

TFTP from server 192.168.40.1; our IP address is 192.168.100.50

Filename 'uImage'.

Load address: 0x40

Loading: *\0x08###T T T #T ##T T T #T ##T T #

Retry count exceeded; starting again

BOOTP broadcast 1

DHCP client bound to address 192.168.100.50

Using ppc_4xx_eth0 device

TFTP from server 192.168.40.1; our IP address is 192.168.100.50

Filename 'uImage'.

Load address: 0x40

Loading: *\0x08T T T #T #T T T T T T

Retry count exceeded; starting again

BOOTP broadcast 1

BOOTP broadcast 2

BOOTP broadcast 3

BOOTP broadcast 4

DHCP client bound to address 192.168.100.50

Using ppc_4xx_eth0 device

TFTP from server 192.168.40.1; our IP address is 192.168.100.50

Filename 'uImage'.

Load address: 0x40

Loading: *\0x08##T #T T T





Brad Dober
Ph.D. Candidate
Department of Physics and Astronomy
University of Pennsylvania
Cell: 262-949-4668

On Tue, May 26, 2015 at 11:17 PM, David MacMahon 
wrote:

> Nothing obvious comes to mind (yet).  Can you watch the roach1 boot
> process via serial console?  What does that show?  Are you using dnsmasq
> for the DHCP server?  What if you try direct connect with mii-tool to set
> the speed of eth1 to 100 Mbps?
>
> Dave
>
> On May 26, 2015, at 5:00 PM, Brad Dober wrote:
>
> > Hi Dave,
> >
> > Here is the configuration of the network. The host computer, a ROACH1
> and a working ROACH2 running in soloboot are the only ones connected. The
> host is 192.168.40.1 and is offering 192.168.100.50 and the ROACH2 is
> assigned to 192.168.40.50. Is there anything weird about how the ROACH1
> handles larger subnets like below? Or maybe infinite address leases?
> >
> > eth1  Link encap:Ethernet  HWaddr 00:08:54:54:d3:f5
> >   inet addr:192.168.40.1  Bcast:192.168.255.255  Mask:255.255.0.0
> >   inet6 addr: fe80::208:54ff:fe54:d3f5/64 Scope:Link
> >   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >   RX packets:705 errors:0 dropped:0 overruns:0 frame:0
> >   TX packets:1377 errors:0 dropped:0 overruns:0 carrier:0
> >   collisions:0 txqueuelen:1000
> >   RX bytes:210574 (210.5 KB)  TX bytes:302407 (302.4 KB)
> >   Interrupt:20 Base address:0x6000
> >
> > Here is the tcpdump:
> >
> > tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
> 65535 bytes
> > 19:46:49.968388 02:00:00:03:01:91 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800), length 343: (tos 0x0, ttl 255, id 225, offset 0, flags [DF],
> proto UDP (17), length 329)
> > 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
> 02:00:00:03:01:91, length 301, xid 0x144252, secs 1130, Flags [none]
> > Client-Ethernet-Address 02:00:00:03:01:91
> > Vendor-rfc1048 Extensions
> >   Magic Cookie 0x63825363
> >   DHCP-Message Option 53, length 1: Discover
> >   MSZ Option 57, length 2: 576
> >   Parameter-Request Option 55, length 5:
> > Subnet-Mask, Default-Gateway, Hostname, BS
> > RP
> > 19:46:49.968953 00:08:54:54:d3:f5 > 02:00:00:03:01:91, ethertype IPv4
> (0x0800), length 349: (tos 0x0, ttl 64, id 33388, offset 0, flags [none],
> proto UDP (17), length 335)
> > 192.168.40.1.67 > 192.168.100.50.68: BOOTP/DHCP, Reply, length 307,
> xid 0x144252, secs 1130, Flags [none]
> > Your-IP 192.168.100.50
> > Server-IP 192.168.40.1
> > Client-Ethernet-Address 02:00:00:03:01:91
> > file "uImage"
> > Vendor-rfc1048 Extensions
> >   Magic Cookie 0x63825363
> >   DHCP-Message Option 53, length 1: Offer
> >   Server-ID Option 54, length 4: 192.168.40.1
> >   Lease-Time Option 51, length 4: 4294967295
> >   Subnet-Mask Option 1, 

Re: [casper] Roach1 Host name lookup error.

[David MacMahon]

Nothing obvious comes to mind (yet).  Can you watch the roach1 boot process via 
serial console?  What does that show?  Are you using dnsmasq for the DHCP 
server?  What if you try direct connect with mii-tool to set the speed of eth1 
to 100 Mbps?

Dave

On May 26, 2015, at 5:00 PM, Brad Dober wrote:

> Hi Dave,
> 
> Here is the configuration of the network. The host computer, a ROACH1 and a 
> working ROACH2 running in soloboot are the only ones connected. The host is 
> 192.168.40.1 and is offering 192.168.100.50 and the ROACH2 is assigned to 
> 192.168.40.50. Is there anything weird about how the ROACH1 handles larger 
> subnets like below? Or maybe infinite address leases?
> 
> eth1  Link encap:Ethernet  HWaddr 00:08:54:54:d3:f5  
>   inet addr:192.168.40.1  Bcast:192.168.255.255  Mask:255.255.0.0
>   inet6 addr: fe80::208:54ff:fe54:d3f5/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:705 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:1377 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:210574 (210.5 KB)  TX bytes:302407 (302.4 KB)
>   Interrupt:20 Base address:0x6000
> 
> Here is the tcpdump:
> 
> tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 
> bytes
> 19:46:49.968388 02:00:00:03:01:91 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
> (0x0800), length 343: (tos 0x0, ttl 255, id 225, offset 0, flags [DF], proto 
> UDP (17), length 329)
> 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
> 02:00:00:03:01:91, length 301, xid 0x144252, secs 1130, Flags [none]
> Client-Ethernet-Address 02:00:00:03:01:91
> Vendor-rfc1048 Extensions
>   Magic Cookie 0x63825363
>   DHCP-Message Option 53, length 1: Discover
>   MSZ Option 57, length 2: 576
>   Parameter-Request Option 55, length 5: 
> Subnet-Mask, Default-Gateway, Hostname, BS
> RP
> 19:46:49.968953 00:08:54:54:d3:f5 > 02:00:00:03:01:91, ethertype IPv4 
> (0x0800), length 349: (tos 0x0, ttl 64, id 33388, offset 0, flags [none], 
> proto UDP (17), length 335)
> 192.168.40.1.67 > 192.168.100.50.68: BOOTP/DHCP, Reply, length 307, xid 
> 0x144252, secs 1130, Flags [none]
> Your-IP 192.168.100.50
> Server-IP 192.168.40.1
> Client-Ethernet-Address 02:00:00:03:01:91
> file "uImage"
> Vendor-rfc1048 Extensions
>   Magic Cookie 0x63825363
>   DHCP-Message Option 53, length 1: Offer
>   Server-ID Option 54, length 4: 192.168.40.1
>   Lease-Time Option 51, length 4: 4294967295
>   Subnet-Mask Option 1, length 4: 255.255.0.0
>   Hostname Option 12, length 8: "roach1-4"
>   RP Option 17, length 33: "192.168.40.1:/srv/roach_boot/etch"
> 19:46:52.971116 02:00:00:03:01:91 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
> (0x0800), length 343: (tos 0x0, ttl 255, id 226, offset 0, flags [DF], proto 
> UDP (17), length 329)
> 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
> 02:00:00:03:01:91, length 301, xid 0x144e0d, secs 1133, Flags [none]
> Client-Ethernet-Address 02:00:00:03:01:91
> Vendor-rfc1048 Extensions
>   Magic Cookie 0x63825363
>   DHCP-Message Option 53, length 1: Discover
>   MSZ Option 57, length 2: 576
>   Parameter-Request Option 55, length 5: 
> Subnet-Mask, Default-Gateway, Hostname, BS
> RP
> 19:46:52.971744 00:08:54:54:d3:f5 > 02:00:00:03:01:91, ethertype IPv4 
> (0x0800), length 349: (tos 0x0, ttl 64, id 34083, offset 0, flags [none], 
> proto UDP (17), length 335)
> 192.168.40.1.67 > 192.168.100.50.68: BOOTP/DHCP, Reply, length 307, xid 
> 0x144e0d, secs 1133, Flags [none]
> Your-IP 192.168.100.50
> Server-IP 192.168.40.1
> Client-Ethernet-Address 02:00:00:03:01:91
> file "uImage"
> Vendor-rfc1048 Extensions
>   Magic Cookie 0x63825363
>   DHCP-Message Option 53, length 1: Offer
>   Server-ID Option 54, length 4: 192.168.40.1
>   Lease-Time Option 51, length 4: 4294967295
>   Subnet-Mask Option 1, length 4: 255.255.0.0
>   Hostname Option 12, length 8: "roach1-4"
>   RP Option 17, length 33: "192.168.40.1:/srv/roach_boot/etch"
> 
> 
> Brad Dober
> Ph.D. Candidate
> Department of Physics and Astronomy
> University of Pennsylvania
> Cell: 262-949-4668
> 
> On Tue, May 26, 2015 at 7:42 PM, David MacMahon  
> wrote:
> Weird.  Are there any other hosts on the network that might be also sending 
> (non-netboot-aware) DHCP offers?
> 
> What does "sudo tcpdump -i eth0 -n -e -v port bootps or port bootpc" show 
> (replacing eth0 with the actual network interface name where the DHCP 
> activity is).
> 
> Dave
> 
> On May 26, 2015, at 4:34 PM, Brad Dober wrote:
> 
> > Hi Dave,
> >
> > I switched to a 100 Mbps switch, and now I'm still getting t

Re: [casper] Roach1 Host name lookup error.

[Brad Dober]

Hi Dave,

Here is the configuration of the network. The host computer, a ROACH1 and a
working ROACH2 running in soloboot are the only ones connected. The host is
192.168.40.1 and is offering 192.168.100.50 and the ROACH2 is assigned to
192.168.40.50. Is there anything weird about how the ROACH1 handles larger
subnets like below? Or maybe infinite address leases?

eth1  Link encap:Ethernet  HWaddr 00:08:54:54:d3:f5
  inet addr:192.168.40.1  Bcast:192.168.255.255  Mask:255.255.0.0
  inet6 addr: fe80::208:54ff:fe54:d3f5/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:705 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1377 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:210574 (210.5 KB)  TX bytes:302407 (302.4 KB)
  Interrupt:20 Base address:0x6000

Here is the tcpdump:

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535
bytes
19:46:49.968388 02:00:00:03:01:91 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 343: (tos 0x0, ttl 255, id 225, offset 0, flags [DF],
proto UDP (17), length 329)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
02:00:00:03:01:91, length 301, xid 0x144252, secs 1130, Flags [none]
  Client-Ethernet-Address 02:00:00:03:01:91
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 5:
  Subnet-Mask, Default-Gateway, Hostname, BS
  RP
19:46:49.968953 00:08:54:54:d3:f5 > 02:00:00:03:01:91, ethertype IPv4
(0x0800), length 349: (tos 0x0, ttl 64, id 33388, offset 0, flags [none],
proto UDP (17), length 335)
192.168.40.1.67 > 192.168.100.50.68: BOOTP/DHCP, Reply, length 307, xid
0x144252, secs 1130, Flags [none]
  Your-IP 192.168.100.50
  Server-IP 192.168.40.1
  Client-Ethernet-Address 02:00:00:03:01:91
  file "uImage"
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.40.1
Lease-Time Option 51, length 4: 4294967295
Subnet-Mask Option 1, length 4: 255.255.0.0
Hostname Option 12, length 8: "roach1-4"
RP Option 17, length 33: "192.168.40.1:/srv/roach_boot/etch"
19:46:52.971116 02:00:00:03:01:91 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 343: (tos 0x0, ttl 255, id 226, offset 0, flags [DF],
proto UDP (17), length 329)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
02:00:00:03:01:91, length 301, xid 0x144e0d, secs 1133, Flags [none]
  Client-Ethernet-Address 02:00:00:03:01:91
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 5:
  Subnet-Mask, Default-Gateway, Hostname, BS
  RP
19:46:52.971744 00:08:54:54:d3:f5 > 02:00:00:03:01:91, ethertype IPv4
(0x0800), length 349: (tos 0x0, ttl 64, id 34083, offset 0, flags [none],
proto UDP (17), length 335)
192.168.40.1.67 > 192.168.100.50.68: BOOTP/DHCP, Reply, length 307, xid
0x144e0d, secs 1133, Flags [none]
  Your-IP 192.168.100.50
  Server-IP 192.168.40.1
  Client-Ethernet-Address 02:00:00:03:01:91
  file "uImage"
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.40.1
Lease-Time Option 51, length 4: 4294967295
Subnet-Mask Option 1, length 4: 255.255.0.0
Hostname Option 12, length 8: "roach1-4"
RP Option 17, length 33: "192.168.40.1:/srv/roach_boot/etch"


Brad Dober
Ph.D. Candidate
Department of Physics and Astronomy
University of Pennsylvania
Cell: 262-949-4668

On Tue, May 26, 2015 at 7:42 PM, David MacMahon 
wrote:

> Weird.  Are there any other hosts on the network that might be also
> sending (non-netboot-aware) DHCP offers?
>
> What does "sudo tcpdump -i eth0 -n -e -v port bootps or port bootpc" show
> (replacing eth0 with the actual network interface name where the DHCP
> activity is).
>
> Dave
>
> On May 26, 2015, at 4:34 PM, Brad Dober wrote:
>
> > Hi Dave,
> >
> > I switched to a 100 Mbps switch, and now I'm still getting the ROACH1
> continuously sending DCHP  discovers, and my host computer continuously
> sending offers, but now the occasional request/acknowledge and uboot
> download is no longer happening.
> >
> > For what it's worth, I am not using jumbo frames.
> >
> >
> > Brad Dober
> > Ph.D. Candidate
> > Department of Physics and Astronomy
> > University of Pennsylvania
> > Cell: 262-949-4668
> >
> > On Tue, May 26, 2015 at 7:21 PM, David MacMahon <
> dav...@astro.berkeley.edu> wrote:
> > Are you trying to run the ROACH1 on 1 GbE?  ROACH1 is not reliable on 1
> GbE.  You have to force it to be 100 Mbps.  This can be done by using an
> unmanaged non-gigabit switch (or hub), a managed switch that can force its
> port for the ROACH1 to be 100 Mbsp only.  For di

Re: [casper] Roach1 Host name lookup error.

[David MacMahon]

Weird.  Are there any other hosts on the network that might be also sending 
(non-netboot-aware) DHCP offers?

What does "sudo tcpdump -i eth0 -n -e -v port bootps or port bootpc" show 
(replacing eth0 with the actual network interface name where the DHCP activity 
is).

Dave

On May 26, 2015, at 4:34 PM, Brad Dober wrote:

> Hi Dave,
> 
> I switched to a 100 Mbps switch, and now I'm still getting the ROACH1 
> continuously sending DCHP  discovers, and my host computer continuously 
> sending offers, but now the occasional request/acknowledge and uboot download 
> is no longer happening.
> 
> For what it's worth, I am not using jumbo frames.
> 
> 
> Brad Dober
> Ph.D. Candidate
> Department of Physics and Astronomy
> University of Pennsylvania
> Cell: 262-949-4668
> 
> On Tue, May 26, 2015 at 7:21 PM, David MacMahon  
> wrote:
> Are you trying to run the ROACH1 on 1 GbE?  ROACH1 is not reliable on 1 GbE.  
> You have to force it to be 100 Mbps.  This can be done by using an unmanaged 
> non-gigabit switch (or hub), a managed switch that can force its port for the 
> ROACH1 to be 100 Mbsp only.  For direct connect, you'll have to use 
> "mii-tool" on the server.
> 
> Another thing that always gets me is MTU.  I don't think the ROACH1 u-boot 
> supports jumbo frames, so you'll have to run the server with MTU==1500 to 
> netboot ROACH1.
> 
> Dave
> 
> On May 26, 2015, at 3:51 PM, Brad Dober wrote:
> 
> > I've switched to NFS boot to avoid SD card corruptions.
> >
> > However, when attempting to run netboot, the roach will send an IP 
> > discover, the host will offer one, and then the roach will send a discover 
> > again.
> > This goes on for 10-15 times when finally the roach will request the 
> > correct IP, and the host will acknowledge. The roach will then begin the 
> > tftp of the uboot image, but will request block 1 multiple times, gets sent 
> > it, acknowledges once starts getting block 1 and 2 sent and then restarts 
> > the whole process asking for an IP request.
> >
> > The whole process seems very strange and I'm having trouble wrapping my 
> > head around what could be causing it.
> >
> > Has anyone encountered something similar???
> >
> >
> > Brad Dober
> > Ph.D. Candidate
> > Department of Physics and Astronomy
> > University of Pennsylvania
> > Cell: 262-949-4668
> >
> > On Thu, May 21, 2015 at 3:32 AM, Marc Welz  wrote:
> >
> >
> > On Wed, May 20, 2015 at 5:19 PM, Brad Dober  wrote:
> > Hi Casperites,
> >
> > I have a Roach1 which is booting from an SD card.
> > I booted it up yesterday, and it was displaying the "STALE NFS handle" 
> > error that other people have seen in the past (which suggested a corrupt 
> > flash card). I ran fsck and fixed several errors, and when rebooting, the 
> > stale nfs handle error went away. However, now the ROACH could not connect 
> > to the network.
> >
> > When I run "ifconfig 128.91.46.20 netmask 255.255.248.0 gateway 128.91.4", 
> > I get:
> > "gateway: Host name lookup failure"
> >
> > root@(none):~# hostname -v
> > (none)
> >
> > If you require a hostname, put it in /etc/hostname or similar and then run
> >
> > hostname -f /etc/hostname
> >
> > regards
> >
> > marc
> >
> >
> >
> 
> 

Re: [casper] Roach1 Host name lookup error.

[Brad Dober]

Hi Dave,

I switched to a 100 Mbps switch, and now I'm still getting the ROACH1
continuously sending DCHP  discovers, and my host computer continuously
sending offers, but now the occasional request/acknowledge and uboot
download is no longer happening.

For what it's worth, I am not using jumbo frames.


Brad Dober
Ph.D. Candidate
Department of Physics and Astronomy
University of Pennsylvania
Cell: 262-949-4668

On Tue, May 26, 2015 at 7:21 PM, David MacMahon 
wrote:

> Are you trying to run the ROACH1 on 1 GbE?  ROACH1 is not reliable on 1
> GbE.  You have to force it to be 100 Mbps.  This can be done by using an
> unmanaged non-gigabit switch (or hub), a managed switch that can force its
> port for the ROACH1 to be 100 Mbsp only.  For direct connect, you'll have
> to use "mii-tool" on the server.
>
> Another thing that always gets me is MTU.  I don't think the ROACH1 u-boot
> supports jumbo frames, so you'll have to run the server with MTU==1500 to
> netboot ROACH1.
>
> Dave
>
> On May 26, 2015, at 3:51 PM, Brad Dober wrote:
>
> > I've switched to NFS boot to avoid SD card corruptions.
> >
> > However, when attempting to run netboot, the roach will send an IP
> discover, the host will offer one, and then the roach will send a discover
> again.
> > This goes on for 10-15 times when finally the roach will request the
> correct IP, and the host will acknowledge. The roach will then begin the
> tftp of the uboot image, but will request block 1 multiple times, gets sent
> it, acknowledges once starts getting block 1 and 2 sent and then restarts
> the whole process asking for an IP request.
> >
> > The whole process seems very strange and I'm having trouble wrapping my
> head around what could be causing it.
> >
> > Has anyone encountered something similar???
> >
> >
> > Brad Dober
> > Ph.D. Candidate
> > Department of Physics and Astronomy
> > University of Pennsylvania
> > Cell: 262-949-4668
> >
> > On Thu, May 21, 2015 at 3:32 AM, Marc Welz  wrote:
> >
> >
> > On Wed, May 20, 2015 at 5:19 PM, Brad Dober  wrote:
> > Hi Casperites,
> >
> > I have a Roach1 which is booting from an SD card.
> > I booted it up yesterday, and it was displaying the "STALE NFS handle"
> error that other people have seen in the past (which suggested a corrupt
> flash card). I ran fsck and fixed several errors, and when rebooting, the
> stale nfs handle error went away. However, now the ROACH could not connect
> to the network.
> >
> > When I run "ifconfig 128.91.46.20 netmask 255.255.248.0 gateway
> 128.91.4", I get:
> > "gateway: Host name lookup failure"
> >
> > root@(none):~# hostname -v
> > (none)
> >
> > If you require a hostname, put it in /etc/hostname or similar and then
> run
> >
> > hostname -f /etc/hostname
> >
> > regards
> >
> > marc
> >
> >
> >
>
>

Re: [casper] Roach1 Host name lookup error.

[David MacMahon]

Are you trying to run the ROACH1 on 1 GbE?  ROACH1 is not reliable on 1 GbE.  
You have to force it to be 100 Mbps.  This can be done by using an unmanaged 
non-gigabit switch (or hub), a managed switch that can force its port for the 
ROACH1 to be 100 Mbsp only.  For direct connect, you'll have to use "mii-tool" 
on the server.

Another thing that always gets me is MTU.  I don't think the ROACH1 u-boot 
supports jumbo frames, so you'll have to run the server with MTU==1500 to 
netboot ROACH1.

Dave

On May 26, 2015, at 3:51 PM, Brad Dober wrote:

> I've switched to NFS boot to avoid SD card corruptions. 
> 
> However, when attempting to run netboot, the roach will send an IP discover, 
> the host will offer one, and then the roach will send a discover again.
> This goes on for 10-15 times when finally the roach will request the correct 
> IP, and the host will acknowledge. The roach will then begin the tftp of the 
> uboot image, but will request block 1 multiple times, gets sent it, 
> acknowledges once starts getting block 1 and 2 sent and then restarts the 
> whole process asking for an IP request.
> 
> The whole process seems very strange and I'm having trouble wrapping my head 
> around what could be causing it.
> 
> Has anyone encountered something similar???
> 
> 
> Brad Dober
> Ph.D. Candidate
> Department of Physics and Astronomy
> University of Pennsylvania
> Cell: 262-949-4668
> 
> On Thu, May 21, 2015 at 3:32 AM, Marc Welz  wrote:
> 
> 
> On Wed, May 20, 2015 at 5:19 PM, Brad Dober  wrote:
> Hi Casperites,
> 
> I have a Roach1 which is booting from an SD card.
> I booted it up yesterday, and it was displaying the "STALE NFS handle" error 
> that other people have seen in the past (which suggested a corrupt flash 
> card). I ran fsck and fixed several errors, and when rebooting, the stale nfs 
> handle error went away. However, now the ROACH could not connect to the 
> network. 
> 
> When I run "ifconfig 128.91.46.20 netmask 255.255.248.0 gateway 128.91.4", I 
> get:
> "gateway: Host name lookup failure"
> 
> root@(none):~# hostname -v
> (none)
> 
> If you require a hostname, put it in /etc/hostname or similar and then run
> 
> hostname -f /etc/hostname
> 
> regards
> 
> marc
> 
> 
> 

Re: [casper] Roach1 Host name lookup error.

[Brad Dober]

I've switched to NFS boot to avoid SD card corruptions.

However, when attempting to run netboot, the roach will send an IP
discover, the host will offer one, and then the roach will send a discover
again.
This goes on for 10-15 times when finally the roach will request the
correct IP, and the host will acknowledge. The roach will then begin the
tftp of the uboot image, but will request block 1 multiple times, gets sent
it, acknowledges once starts getting block 1 and 2 sent and then restarts
the whole process asking for an IP request.

The whole process seems very strange and I'm having trouble wrapping my
head around what could be causing it.

Has anyone encountered something similar???


Brad Dober
Ph.D. Candidate
Department of Physics and Astronomy
University of Pennsylvania
Cell: 262-949-4668

On Thu, May 21, 2015 at 3:32 AM, Marc Welz  wrote:

>
>
> On Wed, May 20, 2015 at 5:19 PM, Brad Dober  wrote:
>
>> Hi Casperites,
>>
>> I have a Roach1 which is booting from an SD card.
>> I booted it up yesterday, and it was displaying the "STALE NFS handle"
>> error that other people have seen in the past (which suggested a corrupt
>> flash card). I ran fsck and fixed several errors, and when rebooting, the
>> stale nfs handle error went away. However, now the ROACH could not connect
>> to the network.
>>
>> When I run "ifconfig 128.91.46.20 netmask 255.255.248.0 gateway
>> 128.91.4", I get:
>>
>> "gateway: Host name lookup failure"
>>
>>
>> root@(none):~# hostname -v
>>
>> (none)
>>
>> If you require a hostname, put it in /etc/hostname or similar and then run
>
> hostname -f /etc/hostname
>
> regards
>
> marc
>
>
>

Re: [casper] Roach1 Host name lookup error.

[Marc Welz]

On Wed, May 20, 2015 at 5:19 PM, Brad Dober  wrote:

> Hi Casperites,
>
> I have a Roach1 which is booting from an SD card.
> I booted it up yesterday, and it was displaying the "STALE NFS handle"
> error that other people have seen in the past (which suggested a corrupt
> flash card). I ran fsck and fixed several errors, and when rebooting, the
> stale nfs handle error went away. However, now the ROACH could not connect
> to the network.
>
> When I run "ifconfig 128.91.46.20 netmask 255.255.248.0 gateway 128.91.4",
> I get:
>
> "gateway: Host name lookup failure"
>
>
> root@(none):~# hostname -v
>
> (none)
>
> If you require a hostname, put it in /etc/hostname or similar and then run

hostname -f /etc/hostname

regards

marc

Re: [casper] Roach1 Host name lookup error.

[G Jones]

I ran into this a lot when trying to use the sdcard filesystem. I think the
problem is that the filesystem is ext2 or something old like that which is
prone to corruption if the system is hard rebooted. My advice is use NFS
file system.
On May 20, 2015 1:20 PM, "Brad Dober"  wrote:

> Hi Casperites,
>
> I have a Roach1 which is booting from an SD card.
> I booted it up yesterday, and it was displaying the "STALE NFS handle"
> error that other people have seen in the past (which suggested a corrupt
> flash card). I ran fsck and fixed several errors, and when rebooting, the
> stale nfs handle error went away. However, now the ROACH could not connect
> to the network.
>
> When I run "ifconfig 128.91.46.20 netmask 255.255.248.0 gateway 128.91.4",
> I get:
>
> "gateway: Host name lookup failure"
>
>
> root@(none):~# hostname -v
>
> (none)
>
> and
>
> root@(none):~# hostname --fqdn
>
> hostname: Host name lookup failure
>
>
> Any ideas on what could be causing this?
>
> Brad Dober
> Ph.D. Candidate
> Department of Physics and Astronomy
> University of Pennsylvania
> Cell: 262-949-4668
>

Re: [casper] Roach1 not working

[Nishanth Shivashankaran]

Hi David,

   It gives me this result.

/home/nfs/roach1/boot

192.168.70.0/24(rw,wdelay,no_root_squash,sec=sys,rw,no_root_squash,no_all_squash)

thanks
Nishanth


On Sun, May 10, 2015 at 7:59 PM, David MacMahon 
wrote:

> Hi, Nishanth,
>
> On May 10, 2015, at 11:41 AM, Nishanth Shivashankaran wrote:
>
> > IP-Config: Got DHCP answer from 192.168.70.1, my address is 192.168.70.9
> > IP-Config: Complete:
> >  device=eth0, addr=192.168.70.9, mask=255.255.255.0,
> gw=255.255.255.255,
> >  host=192.168.70.9, domain=, nis-domain=(none),
> >  bootserver=192.168.70.1, rootserver=192.168.70.1,
> rootpath=/home/nfs/roach1/current,nolock
> > Looking up port of RPC 13/2 on 192.168.70.1
> > Looking up port of RPC 15/1 on 192.168.70.1
> > Root-NFS: Server returned error -13 while mounting
> /home/nfs/roach1/current
>
> When you are logged into the 192.168.70.1 server, what does "sudo exportfs
> -v" show?
>
> Dave
>
>


-- 
Nishanth Shivashankaran
Arizona State University
Phone:-480-246-6866
Email:nshiv...@asu.edu

Re: [casper] Roach1 not working

[David MacMahon]

Hi, Nishanth,

On May 10, 2015, at 11:41 AM, Nishanth Shivashankaran wrote:

> IP-Config: Got DHCP answer from 192.168.70.1, my address is 192.168.70.9
> IP-Config: Complete:
>  device=eth0, addr=192.168.70.9, mask=255.255.255.0, gw=255.255.255.255,
>  host=192.168.70.9, domain=, nis-domain=(none),
>  bootserver=192.168.70.1, rootserver=192.168.70.1, 
> rootpath=/home/nfs/roach1/current,nolock
> Looking up port of RPC 13/2 on 192.168.70.1
> Looking up port of RPC 15/1 on 192.168.70.1
> Root-NFS: Server returned error -13 while mounting /home/nfs/roach1/current

When you are logged into the 192.168.70.1 server, what does "sudo exportfs -v" 
show?

Dave

Re: [casper] Roach1 not working

[Nishanth Shivashankaran]

Hi All,


   I set the link to 100MBPS as well as 10mbps and tried its giving me the
same result.

thanks.
Nishanth

Here is the screen shot



U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)

CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66, EBC=66
MHz)
   No Security/Kasumi support
   Bootstrap Option C - Boot ROM Location EBC (16 bits)
   32 kB I-Cache 32 kB D-Cache
Board: Roach
I2C:   ready
DTT:   1 FAILED INIT
DRAM:  (spd v1.2) dram: notice: ecc ignored
 1 GB
FLASH: 64 MB
USB:   Host(int phy) Device(ext phy)
Net:   ppc_4xx_eth0

Roach Information
Serial Number:040114
Monitor Revision: 8.3.1698
CPLD Revision:8.0.1588

type run netboot to boot via dhcp+tftp+nfs
type run soloboot to run from flash without network
type run mmcboot to boot using filesystem on mmc/sdcard
type run usbboot to boot using filesystem on usb
type run bit to run tests

Hit any key to stop autoboot:  0
Waiting for PHY auto negotiation to complete.. done
ENET Speed is 10 Mbps - FULL duplex connection (EMAC0)
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 28
DHCP client bound to address 192.168.70.9
Using ppc_4xx_eth0 device
TFTP from server 192.168.70.1; our IP address is 192.168.70.9
Filename 'uImage'.
Load address: 0x40
Loading: #
 ##
done
Bytes transferred = 1390149 (153645 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 0040 ...
   Image Name:   Linux-2.6.25-svn3489
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1390085 Bytes =  1.3 MB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri Aug
12 09:36:28 SAST 2011
AMCC PowerPC 440EPx Roach Platform
Zone PFN ranges:
  DMA 0 ->   262143
  Normal 262143 ->   262143
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 ->   262143
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: console=ttyS0,115200
mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdtp
PID hash table entries: 4096 (order: 12, 16384 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1036416k available (2084k kernel code, 720k data, 132k init, 0k
highmem)
Mount-cache hash table entries: 512
BORPH version CVS-$Revision: 1.10 $ Initialized
net_namespace: 152 bytes
NET: Registered protocol family 16

PCI: Probing PCI hardware
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
hwrtype_roach version CVS-$Revision: 1.1 $ registered
JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.
io scheduler noop registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 16550A
serial8250: ttyS3 at MMIO 0x0 (irq = 36) is a 16550A
brd: module loaded
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 2 TX channels, 2 RX channels
rgmii0: input 0 in RGMII mode
eth0: emac0, MAC 02:00:00:04:01:14
eth0: found Generic MII PHY (0x1e)
rgmii0: input 1 in RGMII mode
emac1: can't find PHY!
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky 
Driver 'sd' needs updating - please use bus_type methods
physmap platform flash device: 0400 at fc00
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
mtd: bad character after partition (f)
6 cmdlinepart partitions found on MTD device physmap-flash.0
Creating 6 MTD partitions on "physmap-flash.0":
0x-0x001c : "linux"
0x001c-0x0020 : "fdt"
0x0020-0x00a0 : "root"
0x00a0-0x03f6 : "usr"
0x03f6-0x03fa : "env"
0x03fa-0x0400 : "uboot"
ppc-soc-ohci ppc-soc-ohci.0: USB Host Controller
ppc-soc-ohci ppc-soc-ohci.0: new USB bus registered, assigned bus number 1
ppc-soc-ohci ppc-soc-oh

Re: [casper] Roach1 not working

[李健]

！？！？
--
这是通过Aico Mail手机客户端发送的邮件。Aico Mail旨在丰富人们的沟通与生活，提供全新的移动办公体验。

John Ford 写到：

Hi. error 13 is permission denied. Probably your exports file isn't quite 
right. Note that you have to allow root permission on the mount. Something like 
this should be in /etc/exports: /home/nfs/roach1/current 
192.168.40.0/24(sync,rw,no_root_squash) John > Hi All, > > I used the usb 
wriggler and ito load the bootloader and now I am seeing > data comming out of 
the serial terminal as before. > But the roach is still not booting properly. I 
am trying to boot the roach > through nfs boot and I am seeing this at the 
terminal. Please can any tell > me how to fix this error. > > Thanks > Nishanth 
> > U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38) > > CPU: AMCC PowerPC 
440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66, EBC=66 > MHz) > No 
Security/Kasumi support > Bootstrap Option C - Boot ROM Location EBC (16 bits) 
> 32 kB I-Cache 32 kB D-Cache > Board: Roach > I2C: ready > DTT: 1 FAILED INIT 
> DRAM: (spd v1.2) dram: notice: ecc ignored > 1 GB > FLASH: 64 MB > USB: 
Host(int phy) Device(ext phy) > Net: ppc_4xx_eth0 > > Roach Information > 
Serial Number: 040114 > Monitor Revision: 8.3.1698 > CPLD Revision: 8.0.1588 > 
> type run netboot to boot via dhcp+tftp+nfs > type run soloboot to run from 
flash without network > type run mmcboot to boot using filesystem on mmc/sdcard 
> type run usbboot to boot using filesystem on usb > type run bit to run tests 
> > Hit any key to stop autoboot: 0 > Waiting for PHY auto negotiation to 
complete done > ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) > 
BOOTP broadcast 1 > *** Unhandled DHCP Option in OFFER/ACK: 28 > *** Unhandled 
DHCP Option in OFFER/ACK: 28 > DHCP client bound to address 192.168.40.8 > 
Using ppc_4xx_eth0 device > TFTP from server 192.168.40.1; our IP address is 
192.168.40.8 > Filename 'uImage'. > Load address: 0x40 > Loading: 
# > 
## > done > Bytes transferred = 1390149 (153645 
hex) > WARNING: adjusting available memory to 3000 > ## Booting kernel from 
Legacy Image at 0040 ... > Image Name: Linux-2.6.25-svn3489 > Image Type: 
PowerPC Linux Kernel Image (gzip compressed) > Data Size: 1390085 Bytes = 1.3 
MB > Load Address:  > Entry Point:  > Verifying Checksum ... OK 
> Uncompressing Kernel Image ... OK > id mach(): done > MMU:enter > MMU:hw init 
> MMU:mapin > MMU:setio > MMU:exit > setup_arch: enter > setup_arch: bootmem > 
ocp: exit > arch: exit > Linux version 2.6.25-svn3489 (dave@lapster) (gcc 
version 4.2.2) #6 Fri Aug > 12 09:36:28 SAST 2011 > AMCC PowerPC 440EPx Roach 
Platform > Zone PFN ranges: > DMA 0 -> 262143 > Normal 262143 -> 262143 > 
Movable zone start PFN for each node > early_node_map[1] active PFN ranges > 0: 
0 -> 262143 > Built 1 zonelists in Zone order, mobility grouping on. Total 
pages: > 260096 > Kernel command line: console=ttyS0,115200 > 
mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20 > 
(root),p > PID hash table entries: 4096 (order: 12, 16384 bytes) > console 
[ttyS0] enabled > Dentry cache hash table entries: 131072 (order: 7, 524288 
bytes) > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > 
Memory: 1036416k available (2084k kernel code, 720k data, 132k init, 0k > 
highmem) > Mount-cache hash table entries: 512 > BORPH version CVS-$Revision: 
1.10 $ Initialized > net_namespace: 152 bytes > NET: Registered protocol family 
16 > > PCI: Probing PCI hardware > SCSI subsystem initialized > usbcore: 
registered new interface driver usbfs > usbcore: registered new interface 
driver hub > usbcore: registered new device driver usb > NET: Registered 
protocol family 2 > IP route cache hash table entries: 32768 (order: 5, 131072 
bytes) > TCP established hash table entries: 131072 (order: 8, 1048576 bytes) > 
TCP bind hash table entries: 65536 (order: 6, 262144 bytes) > TCP: Hash tables 
configured (established 131072 bind 65536) > TCP reno registered > 
hwrtype_roach version CVS-$Revision: 1.1 $ registered > JFFS2 version 2.2. 
(NAND) ??? 2001-2006 Red Hat, Inc. > io scheduler noop registered (default) 
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled > 
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A > serial8250: ttyS1 at MMIO 
0x0 (irq = 1) is a 16550A > serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 
16550A > serial8250: ttyS3 at MMIO 0x0 (irq = 36) is a 16550A > brd: module 
loaded > PPC 4xx OCP EMAC driver, version 3.54 > mal0: initialized, 2 TX 
channels, 2 RX channels > rgmii0: input 0 in RGMII mode > eth0: emac0, MAC 
02:00:00:04:01:14 > eth0: found Generic MII PHY (0x1e) > rgmii0: input 1 in 
RGMII mode > emac1: can't find PHY! > tun: Universal TUN/TAP device driver, 1.6 
> tun: (C) 1999-2004 Max Krasnyansky > Driver 'sd' needs updating - please use 
bus_type methods > physmap platform flash device: 0400 at fc00 > 
p

Re: [casper] Roach1 not working

[G Jones]

Note that for recursive, you need -R not -r

On Fri, May 8, 2015 at 3:55 PM, Nishanth Shivashankaran 
wrote:

> Hi All,
>
>Thanks for the reply. I have the exports set to
>
> /home/nfs/roach1/current   192.168.70.0/24(sync,rw,no_root_squash)
>
> and it did not work. I changed the permissions of all the files in the
> boot and current to chmod -r 777 and it still gives me the same error.
>
> thanks and regards,
> Nishanth
>
>
>
>
>
> On Fri, May 8, 2015 at 6:18 AM, John Ford  wrote:
>
>> Hi.
>>
>> error 13 is permission denied.  Probably your exports file isn't quite
>> right.  Note that you have to allow root permission on the mount.
>> Something like this should be in /etc/exports:
>>
>> /home/nfs/roach1/current 192.168.40.0/24(sync,rw,no_root_squash)
>>
>> John
>>
>>
>> > Hi All,
>> >
>> >I used the usb wriggler and ito load the bootloader and now I am
>> seeing
>> > data comming out of the serial terminal as before.
>> > But the roach is still not booting properly. I am trying to boot the
>> roach
>> > through nfs boot and I am seeing this at the terminal. Please can any
>> tell
>> > me how to fix this error.
>> >
>> > Thanks
>> > Nishanth
>> >
>> > U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)
>> >
>> > CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66,
>> EBC=66
>> > MHz)
>> >No Security/Kasumi support
>> >Bootstrap Option C - Boot ROM Location EBC (16 bits)
>> >32 kB I-Cache 32 kB D-Cache
>> > Board: Roach
>> > I2C:   ready
>> > DTT:   1 FAILED INIT
>> > DRAM:  (spd v1.2) dram: notice: ecc ignored
>> >  1 GB
>> > FLASH: 64 MB
>> > USB:   Host(int phy) Device(ext phy)
>> > Net:   ppc_4xx_eth0
>> >
>> > Roach Information
>> > Serial Number:040114
>> > Monitor Revision: 8.3.1698
>> > CPLD Revision:8.0.1588
>> >
>> > type run netboot to boot via dhcp+tftp+nfs
>> > type run soloboot to run from flash without network
>> > type run mmcboot to boot using filesystem on mmc/sdcard
>> > type run usbboot to boot using filesystem on usb
>> > type run bit to run tests
>> >
>> > Hit any key to stop autoboot:  0
>> > Waiting for PHY auto negotiation to complete done
>> > ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
>> > BOOTP broadcast 1
>> > *** Unhandled DHCP Option in OFFER/ACK: 28
>> > *** Unhandled DHCP Option in OFFER/ACK: 28
>> > DHCP client bound to address 192.168.40.8
>> > Using ppc_4xx_eth0 device
>> > TFTP from server 192.168.40.1; our IP address is 192.168.40.8
>> > Filename 'uImage'.
>> > Load address: 0x40
>> > Loading:
>> #
>> >  ##
>> > done
>> > Bytes transferred = 1390149 (153645 hex)
>> > WARNING: adjusting available memory to 3000
>> > ## Booting kernel from Legacy Image at 0040 ...
>> >Image Name:   Linux-2.6.25-svn3489
>> >Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>> >Data Size:1390085 Bytes =  1.3 MB
>> >Load Address: 
>> >Entry Point:  
>> >Verifying Checksum ... OK
>> >Uncompressing Kernel Image ... OK
>> > id mach(): done
>> > MMU:enter
>> > MMU:hw init
>> > MMU:mapin
>> > MMU:setio
>> > MMU:exit
>> > setup_arch: enter
>> > setup_arch: bootmem
>> > ocp: exit
>> > arch: exit
>> > Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri
>> Aug
>> > 12 09:36:28 SAST 2011
>> > AMCC PowerPC 440EPx Roach Platform
>> > Zone PFN ranges:
>> >   DMA 0 ->   262143
>> >   Normal 262143 ->   262143
>> > Movable zone start PFN for each node
>> > early_node_map[1] active PFN ranges
>> > 0:0 ->   262143
>> > Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
>> > 260096
>> > Kernel command line: console=ttyS0,115200
>> > mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20
>> > (root),p
>> > PID hash table entries: 4096 (order: 12, 16384 bytes)
>> > console [ttyS0] enabled
>> > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>> > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> > Memory: 1036416k available (2084k kernel code, 720k data, 132k init, 0k
>> > highmem)
>> > Mount-cache hash table entries: 512
>> > BORPH version CVS-$Revision: 1.10 $ Initialized
>> > net_namespace: 152 bytes
>> > NET: Registered protocol family 16
>> >
>> > PCI: Probing PCI hardware
>> > SCSI subsystem initialized
>> > usbcore: registered new interface driver usbfs
>> > usbcore: registered new interface driver hub
>> > usbcore: registered new device driver usb
>> > NET: Registered protocol family 2
>> > IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
>> > TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
>> > TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
>> > TCP: Hash tables configured (established 131072 bind 65536)
>> > TCP reno registered
>> > hwrtype_roach version CVS-$Revision: 1.1 $ registered
>> > JFFS2 version 2

Re: [casper] Roach1 not working

[Nishanth Shivashankaran]

Hi All,

   Thanks for the reply. I have the exports set to

/home/nfs/roach1/current   192.168.70.0/24(sync,rw,no_root_squash)

and it did not work. I changed the permissions of all the files in the boot
and current to chmod -r 777 and it still gives me the same error.

thanks and regards,
Nishanth





On Fri, May 8, 2015 at 6:18 AM, John Ford  wrote:

> Hi.
>
> error 13 is permission denied.  Probably your exports file isn't quite
> right.  Note that you have to allow root permission on the mount.
> Something like this should be in /etc/exports:
>
> /home/nfs/roach1/current 192.168.40.0/24(sync,rw,no_root_squash)
>
> John
>
>
> > Hi All,
> >
> >I used the usb wriggler and ito load the bootloader and now I am
> seeing
> > data comming out of the serial terminal as before.
> > But the roach is still not booting properly. I am trying to boot the
> roach
> > through nfs boot and I am seeing this at the terminal. Please can any
> tell
> > me how to fix this error.
> >
> > Thanks
> > Nishanth
> >
> > U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)
> >
> > CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66, EBC=66
> > MHz)
> >No Security/Kasumi support
> >Bootstrap Option C - Boot ROM Location EBC (16 bits)
> >32 kB I-Cache 32 kB D-Cache
> > Board: Roach
> > I2C:   ready
> > DTT:   1 FAILED INIT
> > DRAM:  (spd v1.2) dram: notice: ecc ignored
> >  1 GB
> > FLASH: 64 MB
> > USB:   Host(int phy) Device(ext phy)
> > Net:   ppc_4xx_eth0
> >
> > Roach Information
> > Serial Number:040114
> > Monitor Revision: 8.3.1698
> > CPLD Revision:8.0.1588
> >
> > type run netboot to boot via dhcp+tftp+nfs
> > type run soloboot to run from flash without network
> > type run mmcboot to boot using filesystem on mmc/sdcard
> > type run usbboot to boot using filesystem on usb
> > type run bit to run tests
> >
> > Hit any key to stop autoboot:  0
> > Waiting for PHY auto negotiation to complete done
> > ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
> > BOOTP broadcast 1
> > *** Unhandled DHCP Option in OFFER/ACK: 28
> > *** Unhandled DHCP Option in OFFER/ACK: 28
> > DHCP client bound to address 192.168.40.8
> > Using ppc_4xx_eth0 device
> > TFTP from server 192.168.40.1; our IP address is 192.168.40.8
> > Filename 'uImage'.
> > Load address: 0x40
> > Loading:
> #
> >  ##
> > done
> > Bytes transferred = 1390149 (153645 hex)
> > WARNING: adjusting available memory to 3000
> > ## Booting kernel from Legacy Image at 0040 ...
> >Image Name:   Linux-2.6.25-svn3489
> >Image Type:   PowerPC Linux Kernel Image (gzip compressed)
> >Data Size:1390085 Bytes =  1.3 MB
> >Load Address: 
> >Entry Point:  
> >Verifying Checksum ... OK
> >Uncompressing Kernel Image ... OK
> > id mach(): done
> > MMU:enter
> > MMU:hw init
> > MMU:mapin
> > MMU:setio
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > ocp: exit
> > arch: exit
> > Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri
> Aug
> > 12 09:36:28 SAST 2011
> > AMCC PowerPC 440EPx Roach Platform
> > Zone PFN ranges:
> >   DMA 0 ->   262143
> >   Normal 262143 ->   262143
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN ranges
> > 0:0 ->   262143
> > Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
> > 260096
> > Kernel command line: console=ttyS0,115200
> > mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20
> > (root),p
> > PID hash table entries: 4096 (order: 12, 16384 bytes)
> > console [ttyS0] enabled
> > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> > Memory: 1036416k available (2084k kernel code, 720k data, 132k init, 0k
> > highmem)
> > Mount-cache hash table entries: 512
> > BORPH version CVS-$Revision: 1.10 $ Initialized
> > net_namespace: 152 bytes
> > NET: Registered protocol family 16
> >
> > PCI: Probing PCI hardware
> > SCSI subsystem initialized
> > usbcore: registered new interface driver usbfs
> > usbcore: registered new interface driver hub
> > usbcore: registered new device driver usb
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> > TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> > TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
> > TCP: Hash tables configured (established 131072 bind 65536)
> > TCP reno registered
> > hwrtype_roach version CVS-$Revision: 1.1 $ registered
> > JFFS2 version 2.2. (NAND) ??? 2001-2006 Red Hat, Inc.
> > io scheduler noop registered (default)
> > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> > serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
> > serial8250: ttyS1 at MMIO 0x0 (irq = 1) i

Re: [casper] Roach1 not working

[John Ford]

Hi.

error 13 is permission denied.  Probably your exports file isn't quite
right.  Note that you have to allow root permission on the mount.
Something like this should be in /etc/exports:

/home/nfs/roach1/current 192.168.40.0/24(sync,rw,no_root_squash)

John


> Hi All,
>
>I used the usb wriggler and ito load the bootloader and now I am seeing
> data comming out of the serial terminal as before.
> But the roach is still not booting properly. I am trying to boot the roach
> through nfs boot and I am seeing this at the terminal. Please can any tell
> me how to fix this error.
>
> Thanks
> Nishanth
>
> U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)
>
> CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66, EBC=66
> MHz)
>No Security/Kasumi support
>Bootstrap Option C - Boot ROM Location EBC (16 bits)
>32 kB I-Cache 32 kB D-Cache
> Board: Roach
> I2C:   ready
> DTT:   1 FAILED INIT
> DRAM:  (spd v1.2) dram: notice: ecc ignored
>  1 GB
> FLASH: 64 MB
> USB:   Host(int phy) Device(ext phy)
> Net:   ppc_4xx_eth0
>
> Roach Information
> Serial Number:040114
> Monitor Revision: 8.3.1698
> CPLD Revision:8.0.1588
>
> type run netboot to boot via dhcp+tftp+nfs
> type run soloboot to run from flash without network
> type run mmcboot to boot using filesystem on mmc/sdcard
> type run usbboot to boot using filesystem on usb
> type run bit to run tests
>
> Hit any key to stop autoboot:  0
> Waiting for PHY auto negotiation to complete done
> ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
> BOOTP broadcast 1
> *** Unhandled DHCP Option in OFFER/ACK: 28
> *** Unhandled DHCP Option in OFFER/ACK: 28
> DHCP client bound to address 192.168.40.8
> Using ppc_4xx_eth0 device
> TFTP from server 192.168.40.1; our IP address is 192.168.40.8
> Filename 'uImage'.
> Load address: 0x40
> Loading: #
>  ##
> done
> Bytes transferred = 1390149 (153645 hex)
> WARNING: adjusting available memory to 3000
> ## Booting kernel from Legacy Image at 0040 ...
>Image Name:   Linux-2.6.25-svn3489
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:1390085 Bytes =  1.3 MB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> ocp: exit
> arch: exit
> Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri Aug
> 12 09:36:28 SAST 2011
> AMCC PowerPC 440EPx Roach Platform
> Zone PFN ranges:
>   DMA 0 ->   262143
>   Normal 262143 ->   262143
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0:0 ->   262143
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
> 260096
> Kernel command line: console=ttyS0,115200
> mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20
> (root),p
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> console [ttyS0] enabled
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1036416k available (2084k kernel code, 720k data, 132k init, 0k
> highmem)
> Mount-cache hash table entries: 512
> BORPH version CVS-$Revision: 1.10 $ Initialized
> net_namespace: 152 bytes
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> hwrtype_roach version CVS-$Revision: 1.1 $ registered
> JFFS2 version 2.2. (NAND) ??? 2001-2006 Red Hat, Inc.
> io scheduler noop registered (default)
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
> serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
> serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 16550A
> serial8250: ttyS3 at MMIO 0x0 (irq = 36) is a 16550A
> brd: module loaded
> PPC 4xx OCP EMAC driver, version 3.54
> mal0: initialized, 2 TX channels, 2 RX channels
> rgmii0: input 0 in RGMII mode
> eth0: emac0, MAC 02:00:00:04:01:14
> eth0: found Generic MII PHY (0x1e)
> rgmii0: input 1 in RGMII mode
> emac1: can't find PHY!
> tun: Universal TUN/TAP device driver, 1.6
> tun: (C) 1999-2004 Max Krasnyansky 
> Driver 'sd' needs updating - please use bus_type methods
> physmap platform flash device: 0400 at fc00
> physmap-flash.0: Fou

Re: [casper] Roach1 not working

[David MacMahon]

Hi, Nishanth,

On May 7, 2015, at 8:23 PM, Nishanth Shivashankaran wrote:

> ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)

I don't know whether this is causing your problem, but I believe the ROACH1 
ethernet port is not reliable at 1 Gbps.  I think you somehow need to limit it 
to 100 Mbps (e.g. use a switch/hub that only supports 100 Mbps or use the 
mii-tool program on the server for direct connections).

HTH,
Dave

Re: [casper] Roach1 not working

[Marc Welz]

Well, then you are almost there: Note that the NFS server somehow isn't
happy:

> Root-NFS: Server returned error -13 while mounting
/home/nfs/roach1/current

regards

marc

Re: [casper] Roach1 not working

[Nishanth Shivashankaran]

Hi All,

   I used the usb wriggler and ito load the bootloader and now I am seeing
data comming out of the serial terminal as before.
But the roach is still not booting properly. I am trying to boot the roach
through nfs boot and I am seeing this at the terminal. Please can any tell
me how to fix this error.

Thanks
Nishanth

U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)

CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66, EBC=66
MHz)
   No Security/Kasumi support
   Bootstrap Option C - Boot ROM Location EBC (16 bits)
   32 kB I-Cache 32 kB D-Cache
Board: Roach
I2C:   ready
DTT:   1 FAILED INIT
DRAM:  (spd v1.2) dram: notice: ecc ignored
 1 GB
FLASH: 64 MB
USB:   Host(int phy) Device(ext phy)
Net:   ppc_4xx_eth0

Roach Information
Serial Number:040114
Monitor Revision: 8.3.1698
CPLD Revision:8.0.1588

type run netboot to boot via dhcp+tftp+nfs
type run soloboot to run from flash without network
type run mmcboot to boot using filesystem on mmc/sdcard
type run usbboot to boot using filesystem on usb
type run bit to run tests

Hit any key to stop autoboot:  0
Waiting for PHY auto negotiation to complete done
ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 28
DHCP client bound to address 192.168.40.8
Using ppc_4xx_eth0 device
TFTP from server 192.168.40.1; our IP address is 192.168.40.8
Filename 'uImage'.
Load address: 0x40
Loading: #
 ##
done
Bytes transferred = 1390149 (153645 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 0040 ...
   Image Name:   Linux-2.6.25-svn3489
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1390085 Bytes =  1.3 MB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri Aug
12 09:36:28 SAST 2011
AMCC PowerPC 440EPx Roach Platform
Zone PFN ranges:
  DMA 0 ->   262143
  Normal 262143 ->   262143
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 ->   262143
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: console=ttyS0,115200
mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20
(root),p
PID hash table entries: 4096 (order: 12, 16384 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1036416k available (2084k kernel code, 720k data, 132k init, 0k
highmem)
Mount-cache hash table entries: 512
BORPH version CVS-$Revision: 1.10 $ Initialized
net_namespace: 152 bytes
NET: Registered protocol family 16

PCI: Probing PCI hardware
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
hwrtype_roach version CVS-$Revision: 1.1 $ registered
JFFS2 version 2.2. (NAND) ��� 2001-2006 Red Hat, Inc.
io scheduler noop registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 16550A
serial8250: ttyS3 at MMIO 0x0 (irq = 36) is a 16550A
brd: module loaded
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 2 TX channels, 2 RX channels
rgmii0: input 0 in RGMII mode
eth0: emac0, MAC 02:00:00:04:01:14
eth0: found Generic MII PHY (0x1e)
rgmii0: input 1 in RGMII mode
emac1: can't find PHY!
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky 
Driver 'sd' needs updating - please use bus_type methods
physmap platform flash device: 0400 at fc00
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
mtd: bad character after partition (f)
6 cmdlinepart partitions found on MTD device physmap-flash.0
Creating 6 MTD partitions on "physmap-flash.0":
0x-0x001c : "linux"
0x001c-0x0020 : "fdt"
0x0020-0x00a0 : "root"
0x00a0-0x03f6

Re: [casper] Roach1 not working

[Nishanth Shivashankaran]

HI Marc,
 Thank you for the reply, I am not seeing anything on the serial
terminal. I have ordered a macraigor wiggler, I will try using that and see
if the roach starts working.

Thanks and regards,
Nishanth

On Mon, May 4, 2015 at 12:28 AM, Marc Welz  wrote:

>
>
> On Wed, Apr 29, 2015 at 10:49 PM, Nishanth Shivashankaran <
> nshiv...@asu.edu> wrote:
>
>> Hi All,
>>
>> We bought a new desktop and I tried installing nfs boot on to the new
>> computer to boot the roach1 and  was trying to bring the roach1 up. But I
>> think I messed up installing something somewhere and the roach 1 is not
>> returning anything to the minicom terminal at all.
>>
>> I am sure it is connected to the right port because I can see it on the
>> terminal using dmesg command.
>>
>
> If you can see serial text output, then chances are very good that your
> bootloader
> is still working. Have you tried pressing any key during bootup, to see if
> you can reach the
> bootloader prompt - if you can type "printenv" then uboot is still
> functional, and there is
> no need to resort to jtag
>
> regards
>
> marc
>



-- 
Nishanth Shivashankaran
Arizona State University
Phone:-480-246-6866
Email:nshiv...@asu.edu

Re: [casper] Roach1 not working

[Marc Welz]

On Wed, Apr 29, 2015 at 10:49 PM, Nishanth Shivashankaran 
wrote:

> Hi All,
>
> We bought a new desktop and I tried installing nfs boot on to the new
> computer to boot the roach1 and  was trying to bring the roach1 up. But I
> think I messed up installing something somewhere and the roach 1 is not
> returning anything to the minicom terminal at all.
>
> I am sure it is connected to the right port because I can see it on the
> terminal using dmesg command.
>

If you can see serial text output, then chances are very good that your
bootloader
is still working. Have you tried pressing any key during bootup, to see if
you can reach the
bootloader prompt - if you can type "printenv" then uboot is still
functional, and there is
no need to resort to jtag

regards

marc

Re: [casper] Roach1 not working

[Nishanth Shivashankaran]

Thank you John for replying,

 I saw this wiki page before. The Jtag suggested in this website is no
longer available. I was wondering you can suggest me a cheaper Jtag that is
compatible with the micro processor on the roach board.

Thanks and regards,
Nishanth

On Thu, Apr 30, 2015 at 7:56 AM, John Ford  wrote:

> Hi.  I think maybe you have "bricked" your ROACH, i.e. the bootloader is
> messed up.  You'll possibly need a jtag pod and software to reload it.
> See:
>
> https://casper.berkeley.edu/wiki/ROACH_Debricking
>
> John
>
>
> > Hi All,
> >
> > We bought a new desktop and I tried installing nfs boot on to the new
> > computer to boot the roach1 and  was trying to bring the roach1 up. But I
> > think I messed up installing something somewhere and the roach 1 is not
> > returning anything to the minicom terminal at all.
> >
> > I am sure it is connected to the right port because I can see it on the
> > terminal using dmesg command.
> >
> > I tried using different client like cutecom and putty and it still does
> > not
> > work. I did a basic loop back test to minicom terminal all the characters
> > are showing up properly.
> >
> > I switched back everything to the old computer where it used to work
> > before
> > and it does not work there too. I really dont know if the flash
> bootloader
> > is messed up. Is there a way to check if i have done something wrong or
> > reset the whole machine. I did reset the whole machine using the reset
> > switch in front of the roach. Before it stopped returning characters to
> > the
> > minicom terminal I was getting error messages like kernel panic etc. now
> > even that is not showing up.
> >
> > Can someone help me in this regard.
> >
> > Warm regards,
> > Nishanth Shivashankaran
> > Arizona State University
> > Email:nshiv...@asu.edu
> >
>
>
>


-- 
Nishanth Shivashankaran
Arizona State University
Phone:-480-246-6866
Email:nshiv...@asu.edu

Re: [casper] Roach1 not working

[John Ford]

Hi.  I think maybe you have "bricked" your ROACH, i.e. the bootloader is
messed up.  You'll possibly need a jtag pod and software to reload it. 
See:

https://casper.berkeley.edu/wiki/ROACH_Debricking

John


> Hi All,
>
> We bought a new desktop and I tried installing nfs boot on to the new
> computer to boot the roach1 and  was trying to bring the roach1 up. But I
> think I messed up installing something somewhere and the roach 1 is not
> returning anything to the minicom terminal at all.
>
> I am sure it is connected to the right port because I can see it on the
> terminal using dmesg command.
>
> I tried using different client like cutecom and putty and it still does
> not
> work. I did a basic loop back test to minicom terminal all the characters
> are showing up properly.
>
> I switched back everything to the old computer where it used to work
> before
> and it does not work there too. I really dont know if the flash bootloader
> is messed up. Is there a way to check if i have done something wrong or
> reset the whole machine. I did reset the whole machine using the reset
> switch in front of the roach. Before it stopped returning characters to
> the
> minicom terminal I was getting error messages like kernel panic etc. now
> even that is not showing up.
>
> Can someone help me in this regard.
>
> Warm regards,
> Nishanth Shivashankaran
> Arizona State University
> Email:nshiv...@asu.edu
>

Re: [casper] ROACH1 auto power-on

[Alexander Young]

Hi Louis and Jason,

Thank you very much for the detailed instructions.  I will set the
auto-poweron via Xport and see how it goes.  If it ends up being unreliable
or it turns out our Xport is dead too then we'll look into getting
something like an Arduino board as you suggest.

Thanks,
Alex


On Fri, Feb 21, 2014 at 1:33 AM, Louis Dartez  wrote:

> Hi Alex,
>
> If your Xport 'somewhat' works then I'd advise that you use it at
> least this once to set your ROACH to auto power-on mode using Jason's
> instructions below (you should never need to touch it again, I believe). At
> one point, I needed auto-poweron on a ROACH that had a completely dead
> Xport ( I couldn't even get access to the Actel Fusion). We ended up using
> an Arduino board to digitally control the voltage across the two pins on
> the board that control the power. It wasn't too difficult for us because we
> were already using the Arduino board for something else at the time and had
> some extra pins to spare for this. This may be a bit out of your way if you
> just needed this functionality alone...but it works nonetheless. :)
>
>
> P.S. Before reading Jason's email didn't know that once you set the
> auto-on feature using the Actel the board can still be unreliable.
> L
> > Louis P. Dartez
> > Graduate Research Assistant
> > Center for Advanced Radio Astronomy
> > University of Texas @ Brownsville
>
> On Feb 21, 2014, at 12:27 AM, Jason Manley  wrote:
>
> > There is a bit that you can set in the Actel Fusion that's supposed to
> enable this functionality. We use it on KAT-7, but some have reported that
> it's not entirely reliable (sometimes the ROACH doesn't actually start).
> >
> > use the roach_monitor.py script to connect to your Xport.
> >
> > =
> >ROACH MONITOR CONTROL
> > =
> >
> >  1) Retrieve details
> >  2) Reset crashlog counter
> >  3) Power-up ROACH
> >  4) Reset ROACH, but not Actel
> >  5) Toggle safety-shutdown defeat
> >  6) Power down ROACH
> >  7) Toggle PPC EEPROM boot (config H)
> >  8) Toggle auto power-on after hard-reset.
> >  other) Exit
> >
> > You want option 8.
> >
> > Get it here:
> https://casper.berkeley.edu/svn/trunk/roach/sw/roach_monitor/roach_monitor.py
> >
> > Jason Manley
> > CBF Manager
> > SKA-SA
> >
> > Cell: +27 82 662 7726
> > Work: +27 21 506 7300
> >
> > On 21 Feb 2014, at 4:23, Louis P. Dartez  wrote:
> >
> >> Hey Ford,
> >>
> >>  Wanna tackle this one? Maybe give some details on the Digital
> Finger implementation that we put together for LoFASM II w/ the Arduino a
> while back?
> >>
> >> L
> >>
> >> -- Louis P. Dartez
> >> (956) 372-5812
> >> Arecibo Remote Command Center Scholar
> >> Center for Advanced Radio Astronomy
> >> University of Texas at Brownsville
> >>
> >>
> >> On Thu, Feb 20, 2014 at 5:18 PM, Alexander Young 
> wrote:
> >> Hello all,
> >>
> >> Is there a way (maybe with a jumper in the right place) to make the
> ROACH1 boot automatically when the main power is supplied (i.e., after a
> power failure or shutdown). The Xport isn't really convenient for our
> current hardware setup, but we could make it work if that's our only option.
> >>
> >> Thanks,
> >> Alex
> >>
> >> P.S. I noticed a thread about this already in the casper mail archive,
> but the response with the solution appears to be missing.
> >>
> >> ===
> >> Alexander H. Young
> >> Graduate Student
> >> Department of Physics & Astronomy
> >> University of Pennsylvania
> >> 215-746-3805
> >> ===
> >>
> >
>
>

Re: [casper] ROACH1 auto power-on

[Louis Dartez]

Hi Alex, 

If your Xport ‘somewhat’ works then I’d advise that you use it at least 
this once to set your ROACH to auto power-on mode using Jason’s instructions 
below (you should never need to touch it again, I believe). At one point, I 
needed auto-poweron on a ROACH that had a completely dead Xport ( I couldn’t 
even get access to the Actel Fusion). We ended up using an Arduino board to 
digitally control the voltage across the two pins on the board that control the 
power. It wasn’t too difficult for us because we were already using the Arduino 
board for something else at the time and had some extra pins to spare for this. 
This may be a bit out of your way if you just needed this functionality 
alone…but it works nonetheless. :)


P.S. Before reading Jason’s email didn’t know that once you set the auto-on 
feature using the Actel the board can still be unreliable.
L
> Louis P. Dartez
> Graduate Research Assistant
> Center for Advanced Radio Astronomy
> University of Texas @ Brownsville

On Feb 21, 2014, at 12:27 AM, Jason Manley  wrote:

> There is a bit that you can set in the Actel Fusion that's supposed to enable 
> this functionality. We use it on KAT-7, but some have reported that it's not 
> entirely reliable (sometimes the ROACH doesn't actually start).
> 
> use the roach_monitor.py script to connect to your Xport. 
> 
> =
>ROACH MONITOR CONTROL
> =
> 
>  1) Retrieve details
>  2) Reset crashlog counter 
>  3) Power-up ROACH 
>  4) Reset ROACH, but not Actel 
>  5) Toggle safety-shutdown defeat
>  6) Power down ROACH 
>  7) Toggle PPC EEPROM boot (config H)
>  8) Toggle auto power-on after hard-reset.
>  other) Exit
> 
> You want option 8.
> 
> Get it here: 
> https://casper.berkeley.edu/svn/trunk/roach/sw/roach_monitor/roach_monitor.py
> 
> Jason Manley
> CBF Manager
> SKA-SA
> 
> Cell: +27 82 662 7726
> Work: +27 21 506 7300
> 
> On 21 Feb 2014, at 4:23, Louis P. Dartez  wrote:
> 
>> Hey Ford, 
>> 
>>  Wanna tackle this one? Maybe give some details on the Digital 
>> Finger implementation that we put together for LoFASM II w/ the Arduino a 
>> while back?
>> 
>> L 
>> 
>> -- Louis P. Dartez
>> (956) 372-5812
>> Arecibo Remote Command Center Scholar
>> Center for Advanced Radio Astronomy
>> University of Texas at Brownsville
>> 
>> 
>> On Thu, Feb 20, 2014 at 5:18 PM, Alexander Young  
>> wrote:
>> Hello all,
>> 
>> Is there a way (maybe with a jumper in the right place) to make the ROACH1 
>> boot automatically when the main power is supplied (i.e., after a power 
>> failure or shutdown). The Xport isn't really convenient for our current 
>> hardware setup, but we could make it work if that's our only option.  
>> 
>> Thanks,
>> Alex 
>> 
>> P.S. I noticed a thread about this already in the casper mail archive, but 
>> the response with the solution appears to be missing.
>> 
>> ===
>> Alexander H. Young
>> Graduate Student
>> Department of Physics & Astronomy
>> University of Pennsylvania
>> 215-746-3805
>> ===
>> 
> 

Re: [casper] ROACH1 auto power-on

[Jason Manley]

There is a bit that you can set in the Actel Fusion that's supposed to enable 
this functionality. We use it on KAT-7, but some have reported that it's not 
entirely reliable (sometimes the ROACH doesn't actually start).

use the roach_monitor.py script to connect to your Xport. 

=
ROACH MONITOR CONTROL
=

  1) Retrieve details
  2) Reset crashlog counter 
  3) Power-up ROACH 
  4) Reset ROACH, but not Actel 
  5) Toggle safety-shutdown defeat
  6) Power down ROACH 
  7) Toggle PPC EEPROM boot (config H)
  8) Toggle auto power-on after hard-reset.
  other) Exit

You want option 8.

Get it here: 
https://casper.berkeley.edu/svn/trunk/roach/sw/roach_monitor/roach_monitor.py

Jason Manley
CBF Manager
SKA-SA

Cell: +27 82 662 7726
Work: +27 21 506 7300

On 21 Feb 2014, at 4:23, Louis P. Dartez  wrote:

> Hey Ford, 
> 
>   Wanna tackle this one? Maybe give some details on the Digital 
> Finger implementation that we put together for LoFASM II w/ the Arduino a 
> while back?
> 
> L 
> 
> -- Louis P. Dartez
> (956) 372-5812
> Arecibo Remote Command Center Scholar
> Center for Advanced Radio Astronomy
> University of Texas at Brownsville
> 
> 
> On Thu, Feb 20, 2014 at 5:18 PM, Alexander Young  
> wrote:
> Hello all,
> 
> Is there a way (maybe with a jumper in the right place) to make the ROACH1 
> boot automatically when the main power is supplied (i.e., after a power 
> failure or shutdown). The Xport isn't really convenient for our current 
> hardware setup, but we could make it work if that's our only option.  
> 
> Thanks,
> Alex 
> 
> P.S. I noticed a thread about this already in the casper mail archive, but 
> the response with the solution appears to be missing.
> 
> ===
> Alexander H. Young
> Graduate Student
> Department of Physics & Astronomy
> University of Pennsylvania
> 215-746-3805
> ===
> 

Re: [casper] ROACH1 auto power-on

[Louis P. Dartez]

Hey Ford,

  Wanna tackle this one? Maybe give some details on the Digital
Finger implementation that we put together for LoFASM II w/ the Arduino a
while back?

L

-- Louis P. Dartez
(956) 372-5812
Arecibo Remote Command Center Scholar
Center for Advanced Radio Astronomy
University of Texas at Brownsville


On Thu, Feb 20, 2014 at 5:18 PM, Alexander Young wrote:

> Hello all,
>
> Is there a way (maybe with a jumper in the right place) to make the ROACH1
> boot automatically when the main power is supplied (i.e., after a power
> failure or shutdown). The Xport isn't really convenient for our current
> hardware setup, but we could make it work if that's our only option.
>
> Thanks,
> Alex
>
> P.S. I noticed a thread about this already in the casper mail archive, but
> the response with the solution appears to be missing.
>
> ===
> Alexander H. Young
> Graduate Student
> Department of Physics & Astronomy
> University of Pennsylvania
> 215-746-3805
> ===
>

Re: [casper] ROACH1 QDR size

[Dan Werthimer]

hi gerry,

you might be interested in aaron's paper about in place corner turners:

https://casper.berkeley.edu/wiki/Papers

Parsons, A., The Symmetric Group in Data Permutation, with Applications to
a High-Bandwidth Streaming FFT
Architecture,
June
2008

one of the simplest ways to do an in place corner turn is
to write the data in one row at a time, and then read it out
one column at a time.  as you read out the columns you
write the next block of data one column at a time, and
then read it out by rows, then repeat this whole sequence.
there are some clever ways to do this same thing for bit
reversal or any general data permuting.   there are also some clever
ways to use DRAM without having to refresh.


best wishes,

dan

On Sat, Mar 2, 2013 at 4:12 PM, Gerry Harp  wrote:

> Hi Ryan
>
> Can you say a few words about how the in-place corner turner works? I'd be
> fascinated to hear.
>
> Thanks
>
> Gerry
>
> On 3/1/2013 11:28 AM, David MacMahon wrote:
>
>> Thanks, Ryan,
>>
>> The problem was actually in the integration buffers.  We were using QDR
>> vector accumulators and the vector was too long for the smaller chips.
>>  Anyway, the design has since been retired so it's a moot point for us now,
>> but the in-place QDR corner turn sounds interesting!
>>
>> Dave
>>
>> On Mar 1, 2013, at 10:37 AM, Ryan Monroe wrote:
>>
>>  Hey David,
>>>
>>> I know it's probably too late, but I figured out how to do a QDR-corner
>>> turn without ping-ponging (thus, doubling the effective size of the QDR).
>>>  Give me a shout if you need this in the future!
>>>
>>> On 03/01/2013 10:23 AM, David MacMahon wrote:
>>>
 Hi, Jack,

 We noticed that one of our designs gave bogus results when run on a
 ROACH 1 board with a serial number in the range 02, but valid results
 when run on a ROACH 1 board with a serial number in the ranges 03 or
 04.

 After much head scratching, we opened up one 02, one 03, and
 one 04 roach.  The 02 roach (020247) had Cypress CY7C1263V18 QDR
 chips, which are 2Mx18 bits.  The 03 roach (030144) had Cypress
 CY7C15632KV18 chips, which are 4Mx18.  The 04 roach (040122) had NEC
 D44647186AF5-E25 QDR chips, which are also 4Mx18.

 The 2Mx18 bit QDR chips of the 02 roaches can only store 1M
 (1,048,576) 32-bit words which was too small for our design.

 Hope this helps,
 Dave

 On Mar 1, 2013, at 12:27 AM, Jack Hickish wrote:

  Hi All,
>
> Is someone able to confirm that the size of the QDR chips on ROACH 1
> boards depends solely on the board version? If this is indeed the case,
> does anyone know the QDR specs for the different board iterations?
>
>
> Cheers,
> Jack
>

>>>
>>
> --
> --
> Gerald R. Harp, Ph.D.
> Director, Center for SETI Research
> SETI Institute
>
>
>

Re: [casper] ROACH1 QDR size

[Gerry Harp]

Hi Ryan

Can you say a few words about how the in-place corner turner works? I'd 
be fascinated to hear.


Thanks

Gerry

On 3/1/2013 11:28 AM, David MacMahon wrote:

Thanks, Ryan,

The problem was actually in the integration buffers.  We were using QDR vector 
accumulators and the vector was too long for the smaller chips.  Anyway, the 
design has since been retired so it's a moot point for us now, but the in-place 
QDR corner turn sounds interesting!

Dave

On Mar 1, 2013, at 10:37 AM, Ryan Monroe wrote:


Hey David,

I know it's probably too late, but I figured out how to do a QDR-corner turn 
without ping-ponging (thus, doubling the effective size of the QDR).  Give me a 
shout if you need this in the future!

On 03/01/2013 10:23 AM, David MacMahon wrote:

Hi, Jack,

We noticed that one of our designs gave bogus results when run on a ROACH 1 
board with a serial number in the range 02, but valid results when run on a 
ROACH 1 board with a serial number in the ranges 03 or 04.

After much head scratching, we opened up one 02, one 03, and one 04 
roach.  The 02 roach (020247) had Cypress CY7C1263V18 QDR chips, which are 
2Mx18 bits.  The 03 roach (030144) had Cypress CY7C15632KV18 chips, which 
are 4Mx18.  The 04 roach (040122) had NEC D44647186AF5-E25 QDR chips, which 
are also 4Mx18.

The 2Mx18 bit QDR chips of the 02 roaches can only store 1M (1,048,576) 
32-bit words which was too small for our design.

Hope this helps,
Dave

On Mar 1, 2013, at 12:27 AM, Jack Hickish wrote:


Hi All,

Is someone able to confirm that the size of the QDR chips on ROACH 1 boards 
depends solely on the board version? If this is indeed the case, does anyone 
know the QDR specs for the different board iterations?


Cheers,
Jack






--
--
Gerald R. Harp, Ph.D.
Director, Center for SETI Research
SETI Institute

Re: [casper] ROACH1 QDR size

[Jack Hickish]

Hi David,

That was exactly the information i was looking for -- thanks!

Jack


On 1 March 2013 18:23, David MacMahon  wrote:

> Hi, Jack,
>
> We noticed that one of our designs gave bogus results when run on a ROACH
> 1 board with a serial number in the range 02, but valid results when
> run on a ROACH 1 board with a serial number in the ranges 03 or 04.
>
> After much head scratching, we opened up one 02, one 03, and one
> 04 roach.  The 02 roach (020247) had Cypress CY7C1263V18 QDR chips,
> which are 2Mx18 bits.  The 03 roach (030144) had Cypress CY7C15632KV18
> chips, which are 4Mx18.  The 04 roach (040122) had NEC D44647186AF5-E25
> QDR chips, which are also 4Mx18.
>
> The 2Mx18 bit QDR chips of the 02 roaches can only store 1M
> (1,048,576) 32-bit words which was too small for our design.
>
> Hope this helps,
> Dave
>
> On Mar 1, 2013, at 12:27 AM, Jack Hickish wrote:
>
> > Hi All,
> >
> > Is someone able to confirm that the size of the QDR chips on ROACH 1
> boards depends solely on the board version? If this is indeed the case,
> does anyone know the QDR specs for the different board iterations?
> >
> >
> > Cheers,
> > Jack
>
>

Re: [casper] ROACH1 QDR size

[David MacMahon]

Thanks, Ryan,

The problem was actually in the integration buffers.  We were using QDR vector 
accumulators and the vector was too long for the smaller chips.  Anyway, the 
design has since been retired so it's a moot point for us now, but the in-place 
QDR corner turn sounds interesting!

Dave

On Mar 1, 2013, at 10:37 AM, Ryan Monroe wrote:

> Hey David,
> 
> I know it's probably too late, but I figured out how to do a QDR-corner turn 
> without ping-ponging (thus, doubling the effective size of the QDR).  Give me 
> a shout if you need this in the future!
> 
> On 03/01/2013 10:23 AM, David MacMahon wrote:
>> Hi, Jack,
>> 
>> We noticed that one of our designs gave bogus results when run on a ROACH 1 
>> board with a serial number in the range 02, but valid results when run 
>> on a ROACH 1 board with a serial number in the ranges 03 or 04.
>> 
>> After much head scratching, we opened up one 02, one 03, and one 
>> 04 roach.  The 02 roach (020247) had Cypress CY7C1263V18 QDR chips, 
>> which are 2Mx18 bits.  The 03 roach (030144) had Cypress CY7C15632KV18 
>> chips, which are 4Mx18.  The 04 roach (040122) had NEC D44647186AF5-E25 
>> QDR chips, which are also 4Mx18.
>> 
>> The 2Mx18 bit QDR chips of the 02 roaches can only store 1M (1,048,576) 
>> 32-bit words which was too small for our design.
>> 
>> Hope this helps,
>> Dave
>> 
>> On Mar 1, 2013, at 12:27 AM, Jack Hickish wrote:
>> 
>>> Hi All,
>>> 
>>> Is someone able to confirm that the size of the QDR chips on ROACH 1 boards 
>>> depends solely on the board version? If this is indeed the case, does 
>>> anyone know the QDR specs for the different board iterations?
>>> 
>>> 
>>> Cheers,
>>> Jack
>> 
> 
> 

Re: [casper] ROACH1 QDR size

[Ryan Monroe]

It's not that complete.  I could write a memo about it and throw around 
some matlab code.  I implemented it for a demo several months ago but it 
was never tidy.  Whoever actually needs it would have half of their work 
done though. Basically, you just have to permute the bits of the address 
counter in a specific way.  It's just like what you guys do with the 
"reorder" blocks, where you use luts on the address line to the brams, 
only since your luts would be 2^21 long, I figured out the rule and used 
the permuted counter instead.  EDIT:  It wasn't permuted, I think it was 
a bit-circular-shifted counter.


I'll type that up this weekend.  Probably :-)

On 03/01/2013 10:50 AM, Dan Werthimer wrote:


hi ryan,

can you check this into one of the GIT repositories?

thanks,

dan

On Fri, Mar 1, 2013 at 10:37 AM, Ryan Monroe > wrote:


Hey David,

I know it's probably too late, but I figured out how to do a
QDR-corner turn without ping-ponging (thus, doubling the effective
size of the QDR).  Give me a shout if you need this in the future!

On 03/01/2013 10:23 AM, David MacMahon wrote:

Hi, Jack,

We noticed that one of our designs gave bogus results when run
on a ROACH 1 board with a serial number in the range 02,
but valid results when run on a ROACH 1 board with a serial
number in the ranges 03 or 04.

After much head scratching, we opened up one 02, one
03, and one 04 roach.  The 02 roach (020247) had
Cypress CY7C1263V18 QDR chips, which are 2Mx18 bits.  The
03 roach (030144) had Cypress CY7C15632KV18 chips, which
are 4Mx18.  The 04 roach (040122) had NEC D44647186AF5-E25
QDR chips, which are also 4Mx18.

The 2Mx18 bit QDR chips of the 02 roaches can only store
1M (1,048,576) 32-bit words which was too small for our design.

Hope this helps,
Dave

On Mar 1, 2013, at 12:27 AM, Jack Hickish wrote:

Hi All,

Is someone able to confirm that the size of the QDR chips
on ROACH 1 boards depends solely on the board version? If
this is indeed the case, does anyone know the QDR specs
for the different board iterations?


Cheers,
Jack

Re: [casper] ROACH1 QDR size

[Dan Werthimer]

hi ryan,

can you check this into one of the GIT repositories?

thanks,

dan

On Fri, Mar 1, 2013 at 10:37 AM, Ryan Monroe wrote:

> Hey David,
>
> I know it's probably too late, but I figured out how to do a QDR-corner
> turn without ping-ponging (thus, doubling the effective size of the QDR).
>  Give me a shout if you need this in the future!
>
> On 03/01/2013 10:23 AM, David MacMahon wrote:
>
>> Hi, Jack,
>>
>> We noticed that one of our designs gave bogus results when run on a ROACH
>> 1 board with a serial number in the range 02, but valid results when
>> run on a ROACH 1 board with a serial number in the ranges 03 or 04.
>>
>> After much head scratching, we opened up one 02, one 03, and one
>> 04 roach.  The 02 roach (020247) had Cypress CY7C1263V18 QDR chips,
>> which are 2Mx18 bits.  The 03 roach (030144) had Cypress CY7C15632KV18
>> chips, which are 4Mx18.  The 04 roach (040122) had NEC D44647186AF5-E25
>> QDR chips, which are also 4Mx18.
>>
>> The 2Mx18 bit QDR chips of the 02 roaches can only store 1M
>> (1,048,576) 32-bit words which was too small for our design.
>>
>> Hope this helps,
>> Dave
>>
>> On Mar 1, 2013, at 12:27 AM, Jack Hickish wrote:
>>
>>  Hi All,
>>>
>>> Is someone able to confirm that the size of the QDR chips on ROACH 1
>>> boards depends solely on the board version? If this is indeed the case,
>>> does anyone know the QDR specs for the different board iterations?
>>>
>>>
>>> Cheers,
>>> Jack
>>>
>>
>>
>
>

Re: [casper] ROACH1 QDR size

[Ryan Monroe]

Hey David,

I know it's probably too late, but I figured out how to do a QDR-corner 
turn without ping-ponging (thus, doubling the effective size of the 
QDR).  Give me a shout if you need this in the future!


On 03/01/2013 10:23 AM, David MacMahon wrote:

Hi, Jack,

We noticed that one of our designs gave bogus results when run on a ROACH 1 
board with a serial number in the range 02, but valid results when run on a 
ROACH 1 board with a serial number in the ranges 03 or 04.

After much head scratching, we opened up one 02, one 03, and one 04 
roach.  The 02 roach (020247) had Cypress CY7C1263V18 QDR chips, which are 
2Mx18 bits.  The 03 roach (030144) had Cypress CY7C15632KV18 chips, which 
are 4Mx18.  The 04 roach (040122) had NEC D44647186AF5-E25 QDR chips, which 
are also 4Mx18.

The 2Mx18 bit QDR chips of the 02 roaches can only store 1M (1,048,576) 
32-bit words which was too small for our design.

Hope this helps,
Dave

On Mar 1, 2013, at 12:27 AM, Jack Hickish wrote:


Hi All,

Is someone able to confirm that the size of the QDR chips on ROACH 1 boards 
depends solely on the board version? If this is indeed the case, does anyone 
know the QDR specs for the different board iterations?


Cheers,
Jack

Re: [casper] ROACH1 QDR size

[David MacMahon]

Hi, Jack,

We noticed that one of our designs gave bogus results when run on a ROACH 1 
board with a serial number in the range 02, but valid results when run on a 
ROACH 1 board with a serial number in the ranges 03 or 04.

After much head scratching, we opened up one 02, one 03, and one 04 
roach.  The 02 roach (020247) had Cypress CY7C1263V18 QDR chips, which are 
2Mx18 bits.  The 03 roach (030144) had Cypress CY7C15632KV18 chips, which 
are 4Mx18.  The 04 roach (040122) had NEC D44647186AF5-E25 QDR chips, which 
are also 4Mx18.

The 2Mx18 bit QDR chips of the 02 roaches can only store 1M (1,048,576) 
32-bit words which was too small for our design.

Hope this helps,
Dave

On Mar 1, 2013, at 12:27 AM, Jack Hickish wrote:

> Hi All,
> 
> Is someone able to confirm that the size of the QDR chips on ROACH 1 boards 
> depends solely on the board version? If this is indeed the case, does anyone 
> know the QDR specs for the different board iterations?
> 
> 
> Cheers,
> Jack

Re: [casper] Roach1 uboot network curiosity

[Simon Scott]

From my experience with uBoot, you cannot ping a board running uBoot, 
as uBoot does not listen for pings. You can however ping a PC from the 
board running uBoot.


On 14/05/2012 00:23, Marc Welz wrote:

Hello


With the Roach1 in the uboot state.  Network address (192.168.3.240)
acquired via dhcp, from a directly connected windows+cygwin
PC host system (192.168.3.2).

Roach1 can ping the PC exactly as expected.
PC cygwin ping of Roach1 hangs.

While PC ping is hung if the Roach1 pings an unused address
say 192.168.3.3 then the PC pings of the Roach1 un-hang and
return just as expected.  When the Roach1 pings give up
after the N failures the PC pings return to the hung state.

I speak under correction, but I think uboot only brings up the network
when it needs it (uboot isn't an operating system, it doesn't have
interrupts or background tasks).

regards

marc

Re: [casper] Roach1 uboot network curiosity

[Marc Welz]

Hello

> With the Roach1 in the uboot state.  Network address (192.168.3.240)
> acquired via dhcp, from a directly connected windows+cygwin
> PC host system (192.168.3.2).
>
> Roach1 can ping the PC exactly as expected.
> PC cygwin ping of Roach1 hangs.
>
> While PC ping is hung if the Roach1 pings an unused address
> say 192.168.3.3 then the PC pings of the Roach1 un-hang and
> return just as expected.  When the Roach1 pings give up
> after the N failures the PC pings return to the hung state.

I speak under correction, but I think uboot only brings up the network
when it needs it (uboot isn't an operating system, it doesn't have
interrupts or background tasks).

regards

marc

Re: [casper] Roach1 uboot network curiosity

[John Ford]

> Glen,
> The problem you describe sounds like an issue we had during testing at
> Green Bank last December where the NRAO DHCP server would release the DHCP
> entry if the client did not renew it at regular intervals. It turns out
> that the ROACH linux was not renewing the DHCP entries. I think the final
> solution was to give the ROACHs DHCP entries that did not expire, but I'm
> not 100% sure.

That was indeed the fix.  I don't know if Glen's roach is a static address
or not, but I'll check.

Glen, are you sure it's hung and not just slow?  Sometimes it can take 10
seconds to respond if it has to swap stuff in or out.  Next time it's hung
up, let me have a look at it.

John

>
> Glenn
>
>
> On Fri, May 11, 2012 at 12:04 PM, Glen Langston  wrote:
>
>> Hi Matt,
>>
>> We've got a roach1 configured as a spectrometer and
>> have similar issues.
>>
>> Note that the FPGA part of the roach and also the Katcp communications
>> seem to work well.   The symptom I have is
>>
>> ssh
>>
>> is not reliable without a reboot.
>>
>> We've left the roach running as a spectrometer for a month or more
>> without cycling power and it seems to provide a steady stream
>> of good data at fairly high rates, with little trouble. Only the
>>
>> ssh root@roach
>>
>> just hangs, while ping does respond.
>>
>> As I said, after cycling the power, ssh is OK.
>>
>> Glen
>>
>>
>> > Hi,
>> >
>> > Is anyone willing to explain what seems to me to be an unexpected
>> > behavior in a windows+cygwin PC to Roach1 network connection ?
>> >
>> > With the Roach1 in the uboot state.  Network address (192.168.3.240)
>> > acquired via dhcp, from a directly connected windows+cygwin
>> > PC host system (192.168.3.2).
>> >
>> > Roach1 can ping the PC exactly as expected.
>> > PC cygwin ping of Roach1 hangs.
>> >
>> > While PC ping is hung if the Roach1 pings an unused address
>> > say 192.168.3.3 then the PC pings of the Roach1 un-hang and
>> > return just as expected.  When the Roach1 pings give up
>> > after the N failures the PC pings return to the hung state.
>> >
>> > I've only tried this on 1 particular Roach1 but it is
>> > completely repeatable across power cycling, cable reseating
>> > and resetting the Roach1 and anything else I could think
>> > to try.
>> >
>> > When booted to linux this Roach1 responds to pings exactly
>> > as expected.
>> >
>> > Maybe to be expected because Roach1 uboot doesn't respond
>> > to some particular type of packet requests the PC requires ?
>> >
>> > Thanks,
>> > Matt
>> >
>>
>>
>>
>>
>

Re: [casper] Roach1 uboot network curiosity

[G Jones]

Glen,
The problem you describe sounds like an issue we had during testing at
Green Bank last December where the NRAO DHCP server would release the DHCP
entry if the client did not renew it at regular intervals. It turns out
that the ROACH linux was not renewing the DHCP entries. I think the final
solution was to give the ROACHs DHCP entries that did not expire, but I'm
not 100% sure.

Glenn


On Fri, May 11, 2012 at 12:04 PM, Glen Langston  wrote:

> Hi Matt,
>
> We've got a roach1 configured as a spectrometer and
> have similar issues.
>
> Note that the FPGA part of the roach and also the Katcp communications
> seem to work well.   The symptom I have is
>
> ssh
>
> is not reliable without a reboot.
>
> We've left the roach running as a spectrometer for a month or more
> without cycling power and it seems to provide a steady stream
> of good data at fairly high rates, with little trouble. Only the
>
> ssh root@roach
>
> just hangs, while ping does respond.
>
> As I said, after cycling the power, ssh is OK.
>
> Glen
>
>
> > Hi,
> >
> > Is anyone willing to explain what seems to me to be an unexpected
> > behavior in a windows+cygwin PC to Roach1 network connection ?
> >
> > With the Roach1 in the uboot state.  Network address (192.168.3.240)
> > acquired via dhcp, from a directly connected windows+cygwin
> > PC host system (192.168.3.2).
> >
> > Roach1 can ping the PC exactly as expected.
> > PC cygwin ping of Roach1 hangs.
> >
> > While PC ping is hung if the Roach1 pings an unused address
> > say 192.168.3.3 then the PC pings of the Roach1 un-hang and
> > return just as expected.  When the Roach1 pings give up
> > after the N failures the PC pings return to the hung state.
> >
> > I've only tried this on 1 particular Roach1 but it is
> > completely repeatable across power cycling, cable reseating
> > and resetting the Roach1 and anything else I could think
> > to try.
> >
> > When booted to linux this Roach1 responds to pings exactly
> > as expected.
> >
> > Maybe to be expected because Roach1 uboot doesn't respond
> > to some particular type of packet requests the PC requires ?
> >
> > Thanks,
> > Matt
> >
>
>
>
>

Re: [casper] Roach1 uboot network curiosity

[Glen Langston]

Hi Matt,

We've got a roach1 configured as a spectrometer and
have similar issues.

Note that the FPGA part of the roach and also the Katcp communications
seem to work well.   The symptom I have is

ssh

is not reliable without a reboot.

We've left the roach running as a spectrometer for a month or more
without cycling power and it seems to provide a steady stream
of good data at fairly high rates, with little trouble. Only the

ssh root@roach

just hangs, while ping does respond.

As I said, after cycling the power, ssh is OK.

Glen


> Hi,
>
> Is anyone willing to explain what seems to me to be an unexpected
> behavior in a windows+cygwin PC to Roach1 network connection ?
>
> With the Roach1 in the uboot state.  Network address (192.168.3.240)
> acquired via dhcp, from a directly connected windows+cygwin
> PC host system (192.168.3.2).
>
> Roach1 can ping the PC exactly as expected.
> PC cygwin ping of Roach1 hangs.
>
> While PC ping is hung if the Roach1 pings an unused address
> say 192.168.3.3 then the PC pings of the Roach1 un-hang and
> return just as expected.  When the Roach1 pings give up
> after the N failures the PC pings return to the hung state.
>
> I've only tried this on 1 particular Roach1 but it is
> completely repeatable across power cycling, cable reseating
> and resetting the Roach1 and anything else I could think
> to try.
>
> When booted to linux this Roach1 responds to pings exactly
> as expected.
>
> Maybe to be expected because Roach1 uboot doesn't respond
> to some particular type of packet requests the PC requires ?
>
> Thanks,
> Matt
>

Re: [casper] Roach1 PPC temperature sensor misbehaving

[Matt Dexter]

Thanks Kelvin and Jason.

OK - I think we have a work around for the temp sensor issue.
We'll find a way to jumper it to a valid level or disable it
via software and offer the buyer a TBD discount of some sort.

but now the 1V5 supply issue...
Boy I hope this isn't another strange big Xilinx BGA issue
like what happened on Roach2 010203.
It's probably best if I visit Digicom and help you debug in person.
As Jason says if we use the roach_monitor to watch the temperatures
and voltages
we may see the FPGA or PPC heating up due to a short or someother
voltage going wonky.
or feel a logic translator or maybe QDR VTT&VREF generator or
QDR memory getting hot, ...
that is  check all the loads of the 1V5 supply and look for something
amiss.

could there be something like as happened on at least 1 BWRC Roach1 board 
?

The large current sense resistor R296 had failed somehow and
with use would open up so there'd be too much Vdrop w/ load.
fix was to replace R296.
Do you see valid 1.5V right a power up (unprogrammed big FPGA so as
to minimize current demand) ?

I'll still think about when I can visit in person...

Matt


On Wed, 2 May 2012, Jason Manley wrote:



As suggested by you, we shorted pin 2,4,6 & 8 of J31 together (you 
mentioned 1,3,5 & 7 but I thing you mean 2,4,6,8)


Nope, I definitely meant 1,3,5,7 (1&3 and 5&7 should already have been 
shorted) as shown in the v1.3 schematic. This would have shorted all the 
return lines from the temp sensors together. It's unfortunate that this 
didn't work. If the purchaser of this board doesn't mind (maybe you can 
offer a discount or something), I'd suggest simply disabling the 
hardware safety checks (by setting that software flag using 
roach_monitor.py).





Next thing was we ran burn-in of the board. The board ran for 30 minutes and
suddenly the protection kicked in, it powered up and down again and shut
down afterwards. We monitored the low voltage supply and observed 1V5
dropped to 0.9V. I believed something that killed the U51 before was killing
it again. At this point we don't know how to proceed. I have tried shorting
1,3,5,7 of J31 together but it didn't seem to work. Do you have any idea?


What caused the shutdown? Was it definitely the 1v5 rail? Again, 
roach_monitor.py should tell you the reason for the last shutdown. Is 
there something on the board that was getting hot before it shutdown? 
That PSU can supply a lot of current, so I'd imagine any solder hairline 
traces would have burnt through already.


Jason

Re: [casper] Roach1 PPC temperature sensor misbehaving

[Jason Manley]

> 
> As suggested by you, we shorted pin 2,4,6 & 8 of J31 together (you mentioned 
> 1,3,5 & 7 but I thing you mean 2,4,6,8)
Nope, I definitely meant 1,3,5,7 (1&3 and 5&7 should already have been shorted) 
as shown in the v1.3 schematic. This would have shorted all the return lines 
from the temp sensors together. It's unfortunate that this didn't work. If the 
purchaser of this board doesn't mind (maybe you can offer a discount or 
something), I'd suggest simply disabling the hardware safety checks (by setting 
that software flag using roach_monitor.py).

> Next thing was we ran burn-in of the board. The board ran for 30 minutes and
> suddenly the protection kicked in, it powered up and down again and shut
> down afterwards. We monitored the low voltage supply and observed 1V5
> dropped to 0.9V. I believed something that killed the U51 before was killing
> it again. At this point we don't know how to proceed. I have tried shorting
> 1,3,5,7 of J31 together but it didn't seem to work. Do you have any idea?
What caused the shutdown? Was it definitely the 1v5 rail? Again, 
roach_monitor.py should tell you the reason for the last shutdown. Is there 
something on the board that was getting hot before it shutdown? That PSU can 
supply a lot of current, so I'd imagine any solder hairline traces would have 
burnt through already.

Jason

Re: [casper] Roach1 PPC temperature sensor misbehaving

[Jason Manley]

I agree with Francois and suggest you just disable the PPC temperature 
monitoring on that board rather than trying to rework it.  Using different code 
on that ROACH's Actel Fusion might be painful though. You could either disable 
all the safety shutdowns with that flag as you've done and live with that, or 
otherwise I like your idea of shorting the PPC's temperature diode and I think 
this is a harmless fix. The Fusion drives 10uA and 100uA through these BJT 
temperature sensors and measures the differential voltage to determine the 
temperature so shorting these lines won't increase the currents or anything. 

ATRTN0/1 is the return current for these modules. They're shared lines so you 
can have multiple temperature probes. If I understand you correctly, you're 
suspecting a disconnect between J31 and the Fusion. I think these two lines are 
pulled low/connected together inside the Fusion. So you could try'n connect 
that line to the other ATRTN line to see if you can partially restore some 
temperature monitoring functionality (it'd be noisier if it worked at all). If 
the break's between J31 and the Fusion, try'n short J31's pins 1,3,5 and 7 all 
together and see if you get more sensible temperature readings. 

If the break's between J31 and the PPC (and you can't get to it on the PPC side 
of the break), then I'd suggest just shorting the sensing on J31 and living 
without PPC temp sensing.

Jason

On 26 Apr 2012, at 06:38, Francois Kapp wrote:

> Hi Matt,
> 
> Good sleuthing!
> 
> The x-ray evidence points to pcb damage under the Actel device, without that 
> I would intuitively suggested that the PPC is the more likely candidate for 
> soldering problems. I would say that not monitoring PPC temperature is not a 
> complete show stopper from a hardware point of view, but the device does get 
> warm, so a good check on the heatsink mounting would be required. I'll leave 
> it to the software guys to comment on the workaround suggestion.
> 
> Francois
> 
> On Apr 25, 2012 11:40 PM, "Matt Dexter"  wrote:
> Hi,
> 
> Yesterday I spent some time debugging a Roach1 with
> something strange with the PPC temperature sensor.
> The PPC temperature reported is about 50 deg higher
> than that reported for the Xilinx FPGA or Actel Fusion
> device (which actually has the ADC).
> As in 80 vs 30 when just the Xport is running.
> 
> Could this be caused by the temp sensor having a good
> connection to 1 and only 1 of the 2 PPC's PNP transistor leads ?
> 
> Is there any easy software workaround ?
> Would it be OK to use such a workaround and not monitor PPC's temp ?
> Would you accept delivery of a Roach1 that did not monitor
> the PPC's temp but was otherwise AOK ?
> 
> Or should we remove the Actel Fusion BGA device, inspect&repair
> as necessary, install a new Actel and continue debugging ?
> 
> Thanks
> Matt
> 
> 
> 
> Before I had a chance to look at the board the Actel
> Fusion device U60 was replaced. Both the current and
> previous devices were programmed with the latest and greatest
> design.  I don't know for certain but suspect the previous
> Actel part behaved identically to the device now
> installed.
> 
> We made some ohmmeter measurements and for a while we
> thought that ATRTN1 (J31-7) was 43 ohms to GND vs 7.x ohms
> to ground on a board that reported good temps.  Later
> we redid the measurements and the strange board also reported
> 7.x ohms.  The reported temps were still bonkers.
> 
> The voltages at J31-7 vs J31-8 were about .69 volts and
> that matched the voltages for the Xilinx temps on J31-3 vs J31-4.
> Those voltages decreased and the reported temperatures increased
> as expected after the board was fully powered up.  But still
> the reported values were too high by 50 for the PPC.
> 
> The board would only stay powered up if we disabled the
> automatic failure condition  shutdown function  We checked
> the other reported temps, voltages and currents and they
> were all fine.  The board would also stay up if we temporarily shorted
> J31-7 to J31-8 which leads to a reported temp of -271.  The -271
> is nonsensical but understandable.  As it is higher than the low temp shutoff 
> threshold of -280 all the other
> autoshutoff protections can remain enabled.
> 
> The Actel Fusion device is a 256 pin BGA so it's virtually impossible
> to probe even though the PPC temp sensor input connections
> are on or near the edge of the package.
> Using an X-Ray inspection device and comparing vs a known
> good board we found the very short length of etch that delivers
> the ATRTN1 signal from a via (from the PPC IC and to J31-7) to the
> PCB bad for the Actel's T6 pin looks to be mainly missing.
> 
> So maybe the Actel's ADC is getting a valid version of just one of
> the PPC's PNP transistor leads and thus reporting a value with a
> strange offset ?
> 
> We tried blinding pushing in a fine wire to make a connection from J31-7
> to the tiny U60-

Re: [casper] Roach1 PPC temperature sensor misbehaving

[Francois Kapp]

Hi Matt,

Good sleuthing!

The x-ray evidence points to pcb damage under the Actel device, without
that I would intuitively suggested that the PPC is the more likely
candidate for soldering problems. I would say that not monitoring PPC
temperature is not a complete show stopper from a hardware point of view,
but the device does get warm, so a good check on the heatsink mounting
would be required. I'll leave it to the software guys to comment on the
workaround suggestion.

Francois
On Apr 25, 2012 11:40 PM, "Matt Dexter" 
wrote:

> Hi,
>
> Yesterday I spent some time debugging a Roach1 with
> something strange with the PPC temperature sensor.
> The PPC temperature reported is about 50 deg higher
> than that reported for the Xilinx FPGA or Actel Fusion
> device (which actually has the ADC).
> As in 80 vs 30 when just the Xport is running.
>
> Could this be caused by the temp sensor having a good
> connection to 1 and only 1 of the 2 PPC's PNP transistor leads ?
>
> Is there any easy software workaround ?
> Would it be OK to use such a workaround and not monitor PPC's temp ?
> Would you accept delivery of a Roach1 that did not monitor
> the PPC's temp but was otherwise AOK ?
>
> Or should we remove the Actel Fusion BGA device, inspect&repair
> as necessary, install a new Actel and continue debugging ?
>
> Thanks
> Matt
>
> --**--
>
> Before I had a chance to look at the board the Actel
> Fusion device U60 was replaced. Both the current and
> previous devices were programmed with the latest and greatest
> design.  I don't know for certain but suspect the previous
> Actel part behaved identically to the device now
> installed.
>
> We made some ohmmeter measurements and for a while we
> thought that ATRTN1 (J31-7) was 43 ohms to GND vs 7.x ohms
> to ground on a board that reported good temps.  Later
> we redid the measurements and the strange board also reported
> 7.x ohms.  The reported temps were still bonkers.
>
> The voltages at J31-7 vs J31-8 were about .69 volts and
> that matched the voltages for the Xilinx temps on J31-3 vs J31-4.
> Those voltages decreased and the reported temperatures increased
> as expected after the board was fully powered up.  But still
> the reported values were too high by 50 for the PPC.
>
> The board would only stay powered up if we disabled the
> automatic failure condition  shutdown function  We checked
> the other reported temps, voltages and currents and they
> were all fine.  The board would also stay up if we temporarily shorted
> J31-7 to J31-8 which leads to a reported temp of -271.  The -271
> is nonsensical but understandable.  As it is higher than the low temp
> shutoff threshold of -280 all the other
> autoshutoff protections can remain enabled.
>
> The Actel Fusion device is a 256 pin BGA so it's virtually impossible
> to probe even though the PPC temp sensor input connections
> are on or near the edge of the package.
> Using an X-Ray inspection device and comparing vs a known
> good board we found the very short length of etch that delivers
> the ATRTN1 signal from a via (from the PPC IC and to J31-7) to the
> PCB bad for the Actel's T6 pin looks to be mainly missing.
>
> So maybe the Actel's ADC is getting a valid version of just one of
> the PPC's PNP transistor leads and thus reporting a value with a
> strange offset ?
>
> We tried blinding pushing in a fine wire to make a connection from J31-7
> to the tiny U60-T6 solder ball but never improved the reported value.
> It would have been a big surprise if that actually worked but hey
> no guts no glory.
>
> Do you have any ideas before we remove the Actual Fusion part at U60
> and inspect&repair the PCB trace from the PCB pad to the breakout
> via ?
>
> other ideas:
> 1) tweak the autoshutdown code running on this 1 Roach1 to deal
>   with the ~ 50deg offset in reported PPC temps ?
> 2) jumper the PPC temp signals so Vdiff is 0V (-271 deg) or
>   perhaps some other voltage like 1.0VCC so that
>   PPC temperature monitoring is lost but the rest of the
>   protections are up and running.
> 3) no need to disable entirely the failure mode shutdown function
>   so don't want to persue that path.
> 4) ?
>
> For now, I believe, additional board bringup and debugging will continue
> with J31-7&8 shorted together...
>
>

Re: [casper] Roach1 CX4 port to reference xtal mapping

[Jason Manley]

Hi Matt

I have, for ROACH-1:

X1:
CX-0 maps to MGT bottom 0
CX-1 maps to MGT bottom 1

X4:
CX-2 maps to MGT top 0
CX-3 maps to MGT top 1

Jason



On 07 Apr 2012, at 03:46, Matt Dexter wrote:

> Hi,
> 
> I've confused myself when I try to map CX4 port to reference
> crystal - I hope one of you can help me unconfuse me.
> 
> When viewing the rear of the Roach1 board, with components on top,
> the design tools call out, I think, the CX4 ports as:
>  upper left=2  upper right=1
>  lower left=3  lower right=0
> 
> What is the mapping of these ports to the two 156.25 MHz
> reference crystals X1 and X4 as shown on pages 8 and 9 of
> the schematics ?
> 
> Thanks,
> Matt Dexter
> 
>