Hello
> I am able to access and write to software registers. Also, I can verify
> that this simple design is working as expected.
>
> So is it not necessary to get #fpga prompt ?
There isn't a prompt, but recent revisions of tcpborphserver3
generate unsolicited #fpga inform messages when the fpg
Hi, Nimish,
I don't use the corr package much so I don't know about its status, but I share
your understanding that the upload command is not present in publicly available
(i.e. pushed to github or elsewhere) corr packages.
Dave
On Dec 18, 2012, at 9:23 AM, Nimish Sane wrote:
> Ok.
>
> And a
Ok.
And as Jason mentioned earlier, just to reconfirm "upload" command has not
made it to corr package yet, right?
Thanks,
Nimish
On Tue, Dec 18, 2012 at 12:14 PM, David MacMahon
wrote:
> Hi, Nimish,
>
> On Dec 18, 2012, at 8:12 AM, Nimish Sane wrote:
>
> > Also, upload command does not copy t
Hi, Nimish,
On Dec 18, 2012, at 8:12 AM, Nimish Sane wrote:
> Also, upload command does not copy the design to /usr/bof/ directory.
> ?listbof does not list anything. Is this an expected behavior? Also, then is
> progdev command redundant if one is using upload?
Yes, that's how I interpret the
Hi Marc:
On Tue, Dec 18, 2012 at 10:16 AM, Marc Welz wrote:
> Hello
>
> > I do not get #fpga prompt. I get many #log prompts that indicate file
> > transfer status. The final three prompts are as follows:
> >
> > #log info 947013966875 unknown uploaded\_19590582\_bytes
> > #log info 947013966876
Hello
> I do not get #fpga prompt. I get many #log prompts that indicate file
> transfer status. The final three prompts are as follows:
>
> #log info 947013966875 unknown uploaded\_19590582\_bytes
> #log info 947013966876 raw attempting\_to\_empty\_fpga
> #log info 947013966896 raw
> attempting\_
Hello:
On Tue, Dec 18, 2012 at 3:02 AM, Marc Welz wrote:
> Hello
>
> On Mon, Dec 17, 2012 at 4:40 PM, Nimish Sane wrote:
>
> > 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
Hello
On Mon, Dec 17, 2012 at 4:40 PM, Nimish Sane wrote:
> 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.
Th
> 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.
This directory's moved to /usr/bof (or /usr/local/bof, I for
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 a
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 t
> 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?
>
Hi Nimish.
I think you do need to use FTP or scp, or some such, to copy the
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, 20
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
On Thu, Dec 6, 2012 at 10:31 PM, Nimish Sane 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.
Note that on a serial port you will need to
> 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 defa
hi dale, nimish,
my mistake. i saw baud rate of 115200 and immediately
thought of RS232. for USB, there's no equivalent or need
for "null modem".
dan
On Thu, Dec 6, 2012 at 6:49 PM, Dale Gary wrote:
> Hi Dan and all,
>
> This is a USB cable. Is there anything analogous to null modem for su
hi nimish,
are you using a null modem cable?
(this is needed for computer to computer).
what about stop bits, and parity bit settings?
what about the RS232 handshaking lines?
dan
On Thu, Dec 6, 2012 at 2:31 PM, Nimish Sane wrote:
> Hi Dave,
>
> I am using baud rate of 115200. I tried what yo
Nimish
On Dec 6, 2012, at 5:47 PM, David MacMahon wrote:
>
> On Dec 6, 2012, at 2:31 PM, Nimish Sane 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
On Dec 6, 2012, at 2:31 PM, Nimish Sane 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.
That's not good. Maybe try another comm progr
Hi Dave,
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.
I am going back to my another question, which I asked on a separate thread
(this may or may n
On Dec 6, 2012, at 1:29 PM, Nimish Sane wrote:
> Having done this, we can now use picocom to establish a communication over
> these ports. However, we do not see any roach login/prompt on any of the 4
> ports. So we are stuck at that point now. Any clue?
Make sure you're using the right baud r
Dave H.,
Yes, I understand that now. lsusb just reads the info. I had to create a
rule and follow the TN-101 note that you mentioned. We had to reboot the
system apart from the steps mentioned in that application note from FTDI.
We can now see devices getting mounted as /dev/ttyUSB*
There is noth
Hi Nimish,
Yes, I understand that now. lsusb just reads the info. I had to create a
rule and follow the TN-101 note that you mentioned. We had to reboot the
system apart from the steps mentioned in that application note from
FTDI. We can now see devices getting mounted as /dev/ttyUSB*
There is
On Dec 6, 2012, at 1:17 PM, David Hawkins wrote:
> Hi Dave,
>>
>> I think whether a udev rule needs to be created depends on whether
>> the ftdi_sio module knows about the vendor/product ID. If the module
>> already has an alias for the necessary vendor/product ID then the
>> rule is already bu
Hi Dave,
I think whether a udev rule needs to be created depends on whether
the ftdi_sio module knows about the vendor/product ID. If the module
already has an alias for the necessary vendor/product ID then the
rule is already built-in.
I figured since I'd had similar trouble with a FT232H ca
Hi, Dave,
I think whether a udev rule needs to be created depends on whether the ftdi_sio
module knows about the vendor/product ID. If the module already has an alias
for the necessary vendor/product ID then the rule is already built-in.
Nimish, does "modinfo ftdi_sio | grep v0403p6011" output
Hi Nimish,
lsusb returns this:
Bus 002 Device 021: ID 0403:6011 Future Technology Devices
International, Ltd FT4232H Quad HS USB-UART/FIFO IC
I had seen this note earlier, and thought I don't need to do anything
since product id was recognized fine. But, may be I need to something.
Let me check
Hi Dave H.,
lsusb returns this:
Bus 002 Device 021: ID 0403:6011 Future Technology Devices International,
Ltd FT4232H Quad HS USB-UART/FIFO IC
I had seen this note earlier, and thought I don't need to do anything since
product id was recognized fine. But, may be I need to something. Let me
check.
Hi Nimish,
> Yes, I can see that FTID message when I run lsusb.
And the output is what?
If the FTDI product ID is not recognized by ftdi_sio, then
you may have to create a udev rule
http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_101_Customising_FTDI_VID_PID_In_Linux%28FT_81%29
Yes, I can see that FTID message when I run lsusb.
I will check with RedHat support now.
Thanks for your help,
Nimish
On Thu, Dec 6, 2012 at 2:57 PM, David MacMahon wrote:
> I'm running out of ideas. Is the "usbserial" module loaded? Does "lsusb"
> show the "Future Technology Devices Interna
I'm running out of ideas. Is the "usbserial" module loaded? Does "lsusb" show
the "Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO
IC" chip?
You could call RedHat support. That's one of the things you pay for when you
buy RHEL.
Dave
On Dec 6, 2012, at 11:46 AM, N
dmesg | grep -i ftdi still shows the same output.
On Thu, Dec 6, 2012 at 2:45 PM, Nimish Sane wrote:
> I tried this, but it did not create ttyUSB devices.
>
> Nimish
>
>
> On Thu, Dec 6, 2012 at 2:41 PM, David MacMahon
> wrote:
>
>> Now try disconnecting and reconnecting the USB cable. Now tha
I tried this, but it did not create ttyUSB devices.
Nimish
On Thu, Dec 6, 2012 at 2:41 PM, David MacMahon wrote:
> Now try disconnecting and reconnecting the USB cable. Now that the
> ftdi_sio module is loaded, (re-)connecting the cable will hopefully prompt
> udev to create the ttyUSB devices
Now try disconnecting and reconnecting the USB cable. Now that the ftdi_sio
module is loaded, (re-)connecting the cable will hopefully prompt udev to
create the ttyUSB devices for you. After disconnecting, reconnecting, and
waiting for a couple of seconds, try "dmesg | grep -i ftdi" again.
Da
Ok. So now, dmesg | grep -i ftdi shows the following:
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB
Serial Device
usbcore: registered new driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
Nimish
On Thu, Dec 6, 2012 at 2:28 PM,
OK, the fact that the modprobe command showed nothing means that it succeeded,
so try running "dmesg | grep -i ftdi" again.
Dave
On Dec 6, 2012, at 11:20 AM, Nimish Sane wrote:
> Hi Dave,
>
> All of these show nothing.
>
> I just checked and see that there is an LED near the FTDI USB port (na
Hi Dave,
All of these show nothing.
I just checked and see that there is an LED near the FTDI USB port (named
USB OK) that is ON (Red) on the board. Do you know what is that suppose to
indicate?
Thanks,
Nimish
On Thu, Dec 6, 2012 at 2:14 PM, David MacMahon wrote:
> Hi, Nimish,
>
> What does "
Hi, Nimish,
What does "dmesg | grep -i ftdi" show?
Does "lsmod | grep ftdi_sio" show anything? If not, try "modprobe ftdi_sio".
Dave
On Dec 6, 2012, at 10:53 AM, Nimish Sane wrote:
> Hi Dave,
>
> I can see it as a usb device /dev/usbdev* (8 devices actually) but not as
> tty* that I can use
Hi Dave,
I can see it as a usb device /dev/usbdev* (8 devices actually) but not as
tty* that I can use. Does one need to install some drivers for this FTDI
component?
Thanks,
Nimish
On Thu, Dec 6, 2012 at 12:20 PM, David MacMahon
wrote:
> Hi, Nimish,
>
> I think you can find the information in
Hi, Nimish,
I think you can find the information in the output of dmesg as (or after) you
connect the USB cable. It might also be in /var/log/messages.
Dave
On Dec 6, 2012, at 9:04 AM, Nimish Sane wrote:
> Hi Jason,
>
> This is regarding the FTDI part. I am using RHEL 5.8. We could not ident
Hi Jason,
This is regarding the FTDI part. I am using RHEL 5.8. We could not identify
the right device/port in /dev/ directory. Do we need to install any
drivers?
I tried using the Linux driver they have here:
http://www.ftdichip.com/Drivers/VCP.htm However, I am not able to install
this driver.
Hi Jason,
Thank you so much for this information. I will report here if there
are any issues. Though we have not used KATCP previously, we are
familiarizing ourselves to it and plan to use it in future. This is
inline with the scheme you have described. I will try this out now.
Thanks,
Nimish
O
> From our understanding usbboot is still not working and we have to use
> mmcboot using SD cards. Is that correct? In either case, where can I find the
> instructions and required files?
Yeah, I don't actually think USB's ever going to work right as long as we stick
with this PPC part... it's
Hello all:
We just received our REV2 ROACH2 boards. They are just out of the box and
we have not powered them up yet. Is there any document for setting up and
getting started with these boards similar to the document/wikipage for
ROACH boards?
>From our understanding usbboot is still not working
45 matches
Mail list logo
