I should have mentioned this before but another thing you can do besides just trying to load a smaller file is to change the constant in ploader.c to a much larger number for the checksum timeout:
#define CHECKSUM_RETRIES (2000 / ACK_TIMEOUT)
This assumes a 2 second timeout which obviously isn't sufficient. Change the 2000 to 10000 and see if that helps.
I should have mentioned this before but another thing you can do besides just trying to load a smaller file is to change the constant in ploader.c to a much larger number for the checksum timeout:
#define CHECKSUM_RETRIES (2000 / ACK_TIMEOUT)
This assumes a 2 second timeout which obviously isn't sufficient. Change the 2000 to 10000 and see if that helps.
That was the first thing I tried although I only had it set to 5000 but 10000 and 20000 doesn't make any difference either. I'm just getting around to having a quick but closer look at what's going on though.
I just pushed another big change that moves all of the status printf statements out of what is supposed to be a generic file, ploader.c. I've also changed that timeout to 10000. What board are you using for this test?
I just pushed another big change that moves all of the status printf statements out of what is supposed to be a generic file, ploader.c. I've also changed that timeout to 10000. What board are you using for this test?
This was on my +P8 on the IoT5500 which runs at 96MHz, however I did try it on a my standard 10MHz crystal boards as well as older 5Mhz crystal boards. Same result.
I can see the synch bytes polling after a load with no response.
This was on my +P8 on the IoT5500 which runs at 96MHz, however I did try it on a my standard 10MHz crystal boards as well as older 5Mhz crystal boards. Same result.
I can see the synch bytes polling after a load with no response.
You're running p1load under Linux? On a RaspberryPi?
You're running p1load under Linux? On a RaspberryPi?
Built as OS=linux make
Tried with various timeouts and even baudrates and smaller images, different boards, same result.
System is:
peter@peter-L702X-LM17 ~/p1load $ uname -a
Linux peter-L702X-LM17 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Built as OS=linux make
Tried with various timeouts and even baudrates and smaller images, different boards, same result.
System is:
peter@peter-L702X-LM17 ~/p1load $ uname -a
Linux peter-L702X-LM17 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
I have no idea what is going wrong. I assume you have the latest code from github from this morning at least? I'll try running the Linux version under a VM on my Mac but it worked on the RaspberryPi yesterday. Unfortunately, I don't have that machine setup anymore.
I have no idea what is going wrong. I assume you have the latest code from github from this morning at least? I'll try running the Linux version under a VM on my Mac but it worked on the RaspberryPi yesterday. Unfortunately, I don't have that machine setup anymore.
Did a new git afresh, slightly different message:
peter@peter-L702X-LM17 ~/p1load1 $ sudo ./bin/linux/p1load IOT5500.ROM
Found propeller version 1 on /dev/ttyUSB1
Loading 'IOT5500.ROM' (65536 bytes)
Loading hub memory ... 64512Timeout
On a 10Mhz rock board:
peter@peter-L702X-LM17 ~/p1load1 $ sudo ./bin/linux/p1load EXPLORER-5-10MHZ.binary
Found propeller version 1 on /dev/ttyUSB0
Loading 'EXPLORER-5-10MHZ.binary' (32400 bytes)
Loading hub memory ... 31744Timeout
I'm not sure what to say. I am using a QuickStart RevA board and I am able to load it with the latest github code on the Mac, Linux, RaspberryPi, and Windows. It uses a 5mhz crystal but I don't see why that should matter. Looks like I need to fix the timeout message though since it gets appended to the byte count.
Does anyone recall how to avoid having to use sudo to access the serial ports under Linux? I had thought that adding myself to the "dialout" group would work but it doesn't seem to on my machine.
Does anyone recall how to avoid having to use sudo to access the serial ports under Linux? I had thought that adding myself to the "dialout" group would work but it doesn't seem to on my machine.
Try the tty group too.
peter@peter-L702X-LM17 ~/p1load1 $ id
uid=1000(peter) gid=1000(peter) groups=1000(peter),4(adm),5(tty),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),110(sambashare),124(vboxusers)
peter@peter-L702X-LM17 ~/p1load1 $ groups
peter adm tty dialout cdrom sudo dip plugdev lpadmin sambashare vboxusers
peter@peter-L702X-LM17 ~/p1load1 $
Peter: Could you pull my latest changes from github and try again? I simplified the serial settings for Linux to match what was done for the Mac and am wondering if that might have fixed the problem you were seeing.
Does anyone here know how to configure a Raspberry Pi so that it isn't necessary to use sudo to access the /dev/ttyAMA0 serial port and GPIO pin 17? I tried adding myself to the dialout, tty, and gpio groups but I still had to use sudo to run p1load. Is there a way to avoid that?
Does anyone here know how to configure a Raspberry Pi so that it isn't necessary to use sudo to access the /dev/ttyAMA0 serial port and GPIO pin 17? I tried adding myself to the dialout, tty, and gpio groups but I still had to use sudo to run p1load. Is there a way to avoid that?
You'll first have to figure out the group of /dev/ttyAMA0, just do a 'ls -l /dev/ttyAMA0' and notice the group. Then add yourself to that group. There is a problem if that group is a system group, e.g. 'root' or 'sys' or the like. You can of course add yourself to that as well, it's just that you're giving yourself a lot of privileges. In those cases you could simply change the group of /dev/ttyAMA0 to a more desirable one. Another problem is that the device may have only owner r/w acces, e.g. crw
T, in that case give the device group read/write access.
Or you can always give it world read/write access and forget about the group membership.
It may be that the device file is managed by e.g. udev, in that case changes you do to /dev/ttyAMA0 may not 'stick', and will get reset after reboot. But that can fixed too, in e.g. udev's configuration setup.
(I don't have a Pi so this is all generic Unix/Linux stuff, otherwise I would be more detailed about that particular device)
What about just making just making p1load suid to root? That way it gets run as root but you don't have to add privileges to your user account which could be dangerous.
Most people would consider setuid root a high security risk. Basically they are giving you permission via your loader to do anything on their machine as the root user. You may be a well intentioned chap with no will to do harm but the odd bug can do serious damage accidentally.
setuid as a user that is not root but can access the serial port is a better idea. I forget who the owner of ttyAMAA0 is out of the box.
I think the safest way is either add the user to the group that has access to that port or mess with udev rules and give the port to the user.
Most people would consider setuid root a high security risk. Basically they are giving you permission via your loader to do anything on their machine as the root user. You may be a well intentioned chap with no will to do harm but the odd bug can do serious damage accidentally.
setuid as a user that is not root but can access the serial port is a better idea. I forget who the owner of ttyAMAA0 is out of the box.
I think the safest way is either add the user to the group that has access to that port or mess with udev rules and give the port to the user.
Normally I would agree with you but when the alternative seems to be to use sudo I don't see any difference in the security risk. If anything, one would assume that adding suid to root to a program would involve a bit more thought than just slapping sudo in front of your command to get it to work. Anyway, I think the problem is with the gpio pins. The AMA0 port can probably be handled by adding yourself to the dialout or tty group depending on the protection of /dev/ttyAMA0. Adding yourself to the gpio group doesn't seem to fix the problem of access to those pins.
I don't recall how this goes or have a Pi to hand to investigate but you should be able to add the user to the GPIO group to get access to those pins. As per instructions here: https://github.com/quick2wire/quick2wire-gpio-admin
I don't recall how this goes or have a Pi to hand to investigate but you should be able to add the user to the GPIO group to get access to those pins. As per instructions here: https://github.com/quick2wire/quick2wire-gpio-admin
Okay, that is interesting. I guess I missed the "export" step that would have made pin 17 available. Unfortunately, I don't have a RaspberryPi setup anymore either so I'll have to hope someone else tries this. Thanks for the link!
See pi-propeller-load for the export/unexport steps.
As far as I know, I took all of my code from pi-propeller-load already. I assume you're talking about the sysfs module and the code you added to use_reset_method()?
Comments
That was the first thing I tried although I only had it set to 5000 but 10000 and 20000 doesn't make any difference either. I'm just getting around to having a quick but closer look at what's going on though.
This was on my +P8 on the IoT5500 which runs at 96MHz, however I did try it on a my standard 10MHz crystal boards as well as older 5Mhz crystal boards. Same result.
I can see the synch bytes polling after a load with no response.
Built as OS=linux make
Tried with various timeouts and even baudrates and smaller images, different boards, same result.
System is:
peter@peter-L702X-LM17 ~/p1load $ uname -a
Linux peter-L702X-LM17 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Did a new git afresh, slightly different message:
On a 10Mhz rock board:
Try the tty group too.
Do you have a link to this document?
T, in that case give the device group read/write access.
Or you can always give it world read/write access and forget about the group membership.
It may be that the device file is managed by e.g. udev, in that case changes you do to /dev/ttyAMA0 may not 'stick', and will get reset after reboot. But that can fixed too, in e.g. udev's configuration setup.
(I don't have a Pi so this is all generic Unix/Linux stuff, otherwise I would be more detailed about that particular device)
-Tor
setuid as a user that is not root but can access the serial port is a better idea. I forget who the owner of ttyAMAA0 is out of the box.
I think the safest way is either add the user to the group that has access to that port or mess with udev rules and give the port to the user.
This same technique tends to be used for avrdude on the Pi, too, so it's not unheard of and an easy couple of steps for me to add into a guide.