This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Peter Stuge peter at stuge.seMat wrote: > The great news is, I finally flashed it! The second workstation I was > working from was Ubuntu 10.10. This time, I tried on another Ubuntu > 10.04 workstation, which is in a fairly fresh install state. I I > installed dependencies to build the firmware: The arm-elf-toolchain > from bsprak PPA, and most importantly (my guess is, this changed > something), libusb-dev and NOT libusb-1.0.0-dev. This is might seem > strange, but the installed packages are libusb-0.1-4 libusb-1.0.0 and > libusb-dev. Maybe this is a meta package and I'm wrong... libusb-0.1 and libusb-1.0 are different APIs for doing the same thing; accessing USB devices. They are incompatible, meaning that they can not be used interchangeably. Ie. a program built for 0.1 can not use 1.0 directly. This also means that both can be installed at the same time, since they provide different things. There is additionally the libusb-compat-0.1 package which uses the 1.0 API and provides the 0.1 API. Using this is generally more desirable than using the original 0.1 package, but it's not a huge deal. I guess that sam7util uses the old API so you would need libusb-dev in order to build it. But the 0.1 files have literally not changed in years so Ubuntu 10.04 or 10.10 makes no difference. > After I ran strace on sam7 utility and it went much further, finally > ending with something about USBDEVFS ressource busy. A USBDEVFS message confirms that libusb is being used. On the contrary, the strace output you provided for "libusb" mode and "POSIX" mode were identical, and both clearly showed that libusb was *not* being used. Also note that Holger's point of making sure that you are using the correct ttyACM device is quite valid. Just because you see SAM-BA in lsusb does not mean that this piece of hardware will be ttyACM0. It might just as well be ttyACM1 or ttyACM2 or... Your strace output did however show a reply to N# on ttyACM0, indicating that indeed this was the correct port. > Clearly, this all had to do with the USB interface being picky about > something. Maybe someone more knowledgeable can explain. It's impossible to say anything without further analysis. The data you sent does not allow drawing a conclusion. I'm glad that the device works now. //Peter