Thanks John and Dave.
Few issues:
1. The file system on the Roach2 is read-only. I am not able to create a
directory /boffiles. There is none right now. I believe there was some
discussion about keeping it read-only system. I want to know what options
we have.
2. nc does not have -q option. In anyways, the upload command with nc is
not working as expected. I get lot of log messages followed by messages
like: "raw attempting to empty fpga" and "raw attempting to program
bitstream of bytes to device /dev/roach/config.
I am still stuck with this.
Thanks,
Nimish
On Fri, Dec 14, 2012 at 5:48 PM, David MacMahon
wrote:
> Hi, Nimish,
>
> tcpborhpservr3 provides an "upload" command that can used to upload a bof
> file to the FPGA. From the KATCP README that Marc Welz sent on December 4:
>
> > ?upload port
> >
> > Upload and program a local gateware image file to the roach. Send
> > the local image to the tcp port on the roach, as specified. No
> > escaping of the image file required as it has its own stream,
> > which should be closed when upload has completed. Still a bit
> > experimental and subject to revision (there was an uploadbof command
> > which was different).
> >
> > Example
> >
> > ?upload 3000
> > !upload ok 3000
> >
> > Then from a local terminal type
> >
> > nc -w 2 -q 2 192.168.40.57 3000 < some-image.bof
> >
> > Which will give you
> >
> > #fpga loaded
> > #fpga ready
> >
>
>
> Dave
>
> On Dec 14, 2012, at 2:10 PM, Nimish Sane wrote:
>
> > Hi all:
> >
> > A basic question: my understanding is that to use KATCP, one first needs
> to copy the bof file to Roach2. Is that correct? If yes, how does one
> transfer the file to Roach2 board without ftp or scp?
> >
> > If not, how does one use KATCP to program the FPGA?
> >
> > Thanks much,
> >
> > Nimish
> >
> > On Fri, Dec 7, 2012 at 4:52 PM, Nimish Sane
> wrote:
> > Hi Jason and others,
> >
> > On Fri, Dec 7, 2012 at 1:22 AM, Jason Manley wrote:
> > > I am using baud rate of 115200. I tried what you suggested and I still
> not see anything on any of the 4 ports. I have tried with both the Roach2
> boards that we have, and it is the same behavior.
> > We use minicom to good effect. Remember to disable all flow control,
> both HW and SW (on my default in minicom).
> >
> > Using minicom did not work as well. However, we used a Windows XP
> machine to connect the FTDI device to by installing drivers from:
> http://www.ftdichip.com/Drivers/VCP.htm
> >
> > We were able to successfully communicate using putty or HyperTerminal
> over a COM port. The Roach2 is booting properly and we could login and
> access it. We modified the /etc/rc.local file as Jason had suggested to
> assign a static IP and enable telnet. We are now able to telnet into the
> Roach2 board, and hence, do not need to worry about the FTDI device for now.
> >
> > It would be nice to know if someone has a similar experience on RedHat
> and if they have been able to resolve it. Windows driver installation and
> communication over USB serial port was, however, way easier!
> >
> >
> > > I am going back to my another question, which I asked on a separate
> thread (this may or may not be related). We see Fault LED on Roach2 ON
> (Red) many times. Most of the times we are able to get rid of it is by
> recycling the main power to the enclosure (by pulling the plug). However,
> every time I recycle power using POWER switch on the board, I see this
> Fault LED switched on again.
> >
> > I'm guessing you've got some early firmware on that board. The threshold
> levels and things were only finalised last week. Alec Rust (cc'd here) can
> probably give you more details.
> >
> > Alec: Could you please provide more details on this and how to update
> the firmware? Thanks!
> >
> > You can check the schematics to see exactly what triggers this light,
> and trace the circuit back if you want (it's all hardware), or query it
> over the KATCP sensors to see what triggered it. But basically it's if
> there's a HW fault like over temperature on the PPC or FPGA, voltage or
> current rail out of spec, or, possibly a fan failure. You might want to
> flash your rev2 board with new uboot to get this working properly.
> >
> > > There is also a Red LED near FTDI USB (named USB OK), which is glowing
> whenever the USB cable is connected.
> > This is just to indicate that USB communications are working with the
> FTDI part. If you plug a cable in and this light DOESN'T come on, then
> there's something wrong. In retrospect, perhaps it should have been green
> rather than red!
> >
> > Ok. Good to know this.
> >
> > Jason
> >
> > Thanks all for your help.
> >
> > Nimish
> >
> >
> >
> > --
> > Nimish Sane
> >
> > Center for Solar-Terrestrial Research
> > New Jersey Institute of Technology
> > University Heights
> > Newark, NJ 07102-1982 USA
> > Tel: (973) 642 4958
> > Fax: (973) 596 3617
> > nimish.s...@njit.edu
> >
> >
> >
> >
> > --
> > Nimish S
