Problems with using the Pluto as a Standalone Device

GradStudent said:

The wiki asks for the Linaro i686 package, but I needed to use the x86_64 package, or the terminal won't recognize the files

The generated application needs to be targeted for Pluto and not your Desktop. If you compile for x86_64 it won't run on Pluto.

GradStudent said:

I upgraded to the 7.5.0 version instead of the 7.2.1 version, I don't remember my reasoning for this, but as I'm using firmware version 0.35, it seemed like the right thing to do

This shouldn't really matter.

-Travis

When I install the i686 package, this is what I get:

The file is there in the file explorer too, and is listed as an executable, so I don't know what to do here.  The best answer I could find on Stack Overflow was that the compiler version was likely 32-bit and my machine didn't support 32-bit software.  I tried installing 32-bit compatibility packages, build-essentials, and some libstdc-dev packages, but no dice. I figured the i686 and x86_64 were the cpu architecture of the system I ran the compiler on, not for, which is why I switched packages, but I get why that wasn't the right thing to do.

Any ideas?

What is your PATH set to?

-Travis

I set the path variable in my .bashrc since that's what I'm used to doing.

So I managed to get past this by "sudo apt-get install gcc-multilib", and now running "arm-linux-gnueabihf --version" works, but running the compile command fails:

I got around this by "sudo apt-get install  zlib1g:i386", which I realize might be dangerous, given the Pluto needs i686 not i386, but zlib1g:i686 didn't exist so I figured it was worth a shot.  The compile command now fails in a different way:

I feel like I'm missing something simple and stupid here, any ideas?

So I managed to get past this by "sudo apt-get install gcc-multilib", and now running "arm-linux-gnueabihf --version" works, but running the compile command fails:

I got around this by "sudo apt-get install  zlib1g:i386", which I realize might be dangerous, given the Pluto needs i686 not i386, but zlib1g:i686 didn't exist so I figured it was worth a shot.  The compile command now fails in a different way:

I feel like I'm missing something simple and stupid here, any ideas?

Do you have the sysroot at the $HOME/pluto-0.30.sysroot location? 

-Travis

Yes, but for me it's $HOME/pluto-0.35.sysroot:

You will need to update your command to reflect that path.

-Travis

That worked, thank you.  My bad for not reading it close enough.

Do you have any advice on debugging the USB OTG method?  I went and re-read and re-tried everything on that wiki page to double check I did everything by the book, but it still won't create files on the thumb drive.

Do the LEDs change when inserting a USB stick? Is the USB stick FAT32? How are you telling it to write data to the USB stick?

-Travis

The LEDs change in the same pattern that the wiki page lists, the USB drive is FAT32, 4096 block size, 2gb (technically 1.8-ish), and I'm using the example script on the wiki page:

#!/bin/sh

# the default directory the script runs in is /dev, so change to the drive
cd /media/sda1/

# create a file
touch foobar

# change the RX_LO to 2.4GHz
iio_attr -a -c  ad9361-phy RX_LO frequency 2400000000

I made the file on Ubuntu from the terminal so the line endings should be fine.

I found what I believe to be the problem, I made sure to run chmod on the file to add execute permissions but apparently it didn't take.  Not sure why, and for some reason no Linux machine at my disposal will change the file permissions, even when root (and verbose mode says it was successful).  I'll take this to Stack Overflow or a Linux forum somewhere, it's no longer an Pluto/Analog Devices question.

Thanks for the help, and so you know, you're a bit of a legend.  Almost everyone I've asked for help on my grad work has pointed me in your direction.