From: Kristian K. <kr...@kr...> - 2006-10-09 20:33:47
|
Hello everyone, It seems to me that some people are having problems loading their own FS image on the new Netstix (no tweener/stuart). Has kexec been considered for this? It should be possible to boot from the kernel on flash, load an initrd/initramfs (and support for ext2, pcmcia, etc) and look for a "valid" (TBD) ext2 filesystem on the CF card. If it finds one, it should be able to parse a configuration file (from the CF, or perhaps a default in the jffs2 flash) (not unlike GRUB) and boot the kernel that it found on CF using kexec. That kernel would then boot and use the root filesystem on CF. One might be able to then overwrite (yikes!) the jffs2 fs and reflash. I designed a kexec based "bootloader" for x86 using a process similar to these. It's called runnix and it supports all of this and more, including parsing a default config file to enable network support, downloading the new filesystem image from a server (http/ftp), verify it (sha1), install it, and boot it. It's still very preliminary, but it does work: http://misc.krisk.org/runnix-0.1.tar.gz I came up with the idea and put this together in the course of an evening several months ago, and I just haven't had the time to get back to it. I know it has bugs all over the place, but it could be used for something like this. I know that u-boot is quite capable, but the nice thing about kexec is that you have ALL of the functionality of the Linux kernel and whatever else you put in your initrd/initramfs. The default for Runnix is a full featured Linux kernel for x86 (almost all hardware - no modules, though - kexec does not support them) and pretty complete busybox config. All of this and it is still only a couple of MB. The default Gumstix kernel does not include the kexec syscall, and the image does not include kexec-tools. I have both of these in the AstLinux version although I have not yet tested them with Gumstix/ARM. Hopefully I'll get around to it and get back to everyone shortly. Does this sound plausible? Any thoughts? -- Kristian Kielhofner |
From: <den...@gm...> - 2006-10-09 21:37:06
|
That would be GREAT!!! -- Denis Galv=E3o AsteriskBrasil.org Esta=E7=E3o VoIP 2006 www.estacaovoip.com.br On 09 de out de 2006, at 17:32, Kristian Kielhofner wrote: > Hello everyone, > > It seems to me that some people are having problems loading = their own > FS image on the new Netstix (no tweener/stuart). Has kexec been > considered for this? > > It should be possible to boot from the kernel on flash, load an > initrd/initramfs (and support for ext2, pcmcia, etc) and look for a > "valid" (TBD) ext2 filesystem on the CF card. If it finds one, it > should be able to parse a configuration file (from the CF, or =20 > perhaps a > default in the jffs2 flash) (not unlike GRUB) and boot the kernel that > it found on CF using kexec. That kernel would then boot and use the > root filesystem on CF. One might be able to then overwrite =20 > (yikes!) the > jffs2 fs and reflash. > > I designed a kexec based "bootloader" for x86 using a process = similar > to these. It's called runnix and it supports all of this and more, > including parsing a default config file to enable network support, > downloading the new filesystem image from a server (http/ftp), =20 > verify it > (sha1), install it, and boot it. It's still very preliminary, but it > does work: > > http://misc.krisk.org/runnix-0.1.tar.gz > > I came up with the idea and put this together in the course of = an > evening several months ago, and I just haven't had the time to get =20 > back > to it. I know it has bugs all over the place, but it could be used =20= > for > something like this. > > I know that u-boot is quite capable, but the nice thing about =20= > kexec is > that you have ALL of the functionality of the Linux kernel and =20 > whatever > else you put in your initrd/initramfs. The default for Runnix is a =20= > full > featured Linux kernel for x86 (almost all hardware - no modules, =20 > though > - kexec does not support them) and pretty complete busybox config. =20= > All > of this and it is still only a couple of MB. > > The default Gumstix kernel does not include the kexec syscall, = and =20 > the > image does not include kexec-tools. I have both of these in the > AstLinux version although I have not yet tested them with Gumstix/ARM. > Hopefully I'll get around to it and get back to everyone shortly. > > Does this sound plausible? Any thoughts? > > -- > Kristian Kielhofner > > ----------------------------------------------------------------------=20= > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to =20 > share your > opinions on IT & business topics through brief surveys -- and earn =20 > cash > http://www.techsay.com/default.php?=20 > page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Craig H. <cr...@gu...> - 2006-10-09 21:50:58
|
On Oct 9, 2006, at 1:32 PM, Kristian Kielhofner wrote: > Does this sound plausible? Any thoughts? My experience of kexec has not been great. As in it just basically hangs whenever I try to switch to a new kernel. That's on my x86_64 box. I haven't looked at the ARM kexec code, but it seems to me that it'd be hard for kexec to fake-reboot any faster than it'd be to just do a regular reboot. It should be pretty straightforward to extend the u-boot default bootcmd which currently looks for an MMC card with a "gumstix-factory.script" script on it to also look for a similar such script on a CF card, and if found, execute that. The script could then hold instructions on where to find the kernel/initrd and boot them appropriately, with the appropriate bootargs. Seems like this would be less error-prone, more flexible, and less complex than using kexec, without much if any downside. C |
From: Kristian K. <kr...@kr...> - 2006-10-09 22:09:55
|
Craig Hughes wrote: > On Oct 9, 2006, at 1:32 PM, Kristian Kielhofner wrote: > > >> Does this sound plausible? Any thoughts? > > > My experience of kexec has not been great. As in it just basically > hangs whenever I try to switch to a new kernel. That's on my x86_64 > box. I haven't looked at the ARM kexec code, but it seems to me that > it'd be hard for kexec to fake-reboot any faster than it'd be to just > do a regular reboot. It should be pretty straightforward to extend > the u-boot default bootcmd which currently looks for an MMC card with > a "gumstix-factory.script" script on it to also look for a similar > such script on a CF card, and if found, execute that. The script > could then hold instructions on where to find the kernel/initrd and > boot them appropriately, with the appropriate bootargs. Seems like > this would be less error-prone, more flexible, and less complex than > using kexec, without much if any downside. > > C C, That is interesting because I have had great success with kexec on x86. I suppose it remains to be seen how stable it is with ARM. I'm not interested in kexec for the fast reboot capabilities. More for the capability to start a COMPLETELY different kernel using the available resources (i.e. anything/everything) of an already loaded kernel. I have not tried it, but I have read that U-boot does not support booting from the CF yet. The kernel can certainly access the CF. While using U-boot would certainly be less error-prone, and less complex, I can't see how it could be more flexible. Can you elaborate on this? Thanks C! -- Kristian Kielhofner |
From: Alexandre P. N. <al...@om...> - 2006-10-09 22:18:10
|
[cut] >C, > > That is interesting because I have had great success with kexec on x86. > I suppose it remains to be seen how stable it is with ARM. > > I'm not interested in kexec for the fast reboot capabilities. More for >the capability to start a COMPLETELY different kernel using the >available resources (i.e. anything/everything) of an already loaded >kernel. I have not tried it, but I have read that U-boot does not >support booting from the CF yet. The kernel can certainly access the CF. > > While using U-boot would certainly be less error-prone, and less >complex, I can't see how it could be more flexible. Can you elaborate >on this? > >Thanks C! > >-- >Kristian Kielhofner > > u-boot does support accessing and booting from the cf. You have to recompile uboot to enable those options, tough. I somehow managed to destroy uboot by using that, so if you're willing to try that, I recommend paying special attention to the commands you use with the modified uboot. You can even enable ext2 support and have a ext2fs on the cf. On the modified uboot, pinit initializes pcmcia subsystem, after that you can load the kernel by the means of fatload or ext2load. - Alexandre |
From: Craig H. <cr...@gu...> - 2006-10-09 22:34:40
|
On Oct 9, 2006, at 3:08 PM, Kristian Kielhofner wrote: > That is interesting because I have had great success with kexec on > x86. > I suppose it remains to be seen how stable it is with ARM. I have admitedly only tried it on x86_64; it is supposed to work there though, but I couldn't get it to (gentoo with custom kernel build) > I'm not interested in kexec for the fast reboot capabilities. > More for > the capability to start a COMPLETELY different kernel using the > available resources (i.e. anything/everything) of an already loaded > kernel. I have not tried it, but I have read that U-boot does not > support booting from the CF yet. The kernel can certainly access > the CF. u-boot supports CF just fine -- looks like the enabling patch was checked in with r997 (slight improvement with r999) in June. I think gumstix with those u-boot tweaks on them have been shipping since about August. Older gumstix can be updated to the latest u-boot from http://sf.net/projects/gumstix to get CF working on them. > While using U-boot would certainly be less error-prone, and less > complex, I can't see how it could be more flexible. Can you elaborate > on this? Because you can stick anything you want to in the gumstix- factory.script -- you could have it load the kernel over tftp then NFS mount a root filesystem and pass an initrd from the compact flash or something wacky like that. The gumstix-factory script is basically just a shell script which u-boot executes in its hush shell. I guess you could do all that from within linux too, but it'd be trickier than just modifying a couple lines of shell script to do it. C |
From: Kristian K. <kr...@kr...> - 2006-10-09 22:47:12
|
Craig Hughes wrote: ..snipped.. > > > Because you can stick anything you want to in the gumstix- > factory.script -- you could have it load the kernel over tftp then > NFS mount a root filesystem and pass an initrd from the compact flash > or something wacky like that. The gumstix-factory script is > basically just a shell script which u-boot executes in its hush > shell. I guess you could do all that from within linux too, but it'd > be trickier than just modifying a couple lines of shell script to do it. > > C > C, Wow, so it sounds like U-boot does and can do just about anything you'd ever want... Which of course begs the question - why isn't something like what I proposed setup by default (only using U-boot, of course)? If someone buys a NetStix, how can they re-flash it or edit the boot parameters without a serial port? Thanks for all of the updates on U-boot (and putting up with my crazy ideas)! :) -- Kristian Kielhofner |
From: john r. <jo...@cf...> - 2006-10-10 15:52:22
|
Could someone post an example of this? I'd like to boot an image or kernel from mcc if thats possible. Thanks, John Kristian Kielhofner wrote: > Craig Hughes wrote: > > ..snipped.. > >> >>Because you can stick anything you want to in the gumstix- >>factory.script -- you could have it load the kernel over tftp then >>NFS mount a root filesystem and pass an initrd from the compact flash >>or something wacky like that. The gumstix-factory script is >>basically just a shell script which u-boot executes in its hush >>shell. I guess you could do all that from within linux too, but it'd >>be trickier than just modifying a couple lines of shell script to do it. >> >>C >> > > > C, > > Wow, so it sounds like U-boot does and can do just about anything you'd > ever want... Which of course begs the question - why isn't something > like what I proposed setup by default (only using U-boot, of course)? > If someone buys a NetStix, how can they re-flash it or edit the boot > parameters without a serial port? > > Thanks for all of the updates on U-boot (and putting up with my crazy > ideas)! :) > |
From: Kristian K. <kr...@kr...> - 2006-10-10 16:21:13
|
john roll wrote: > Could someone post an example of this? I'd like to > boot an image or kernel from mcc if thats possible. > > Thanks, > > John > John, This script: http://www.hughes-family.org/~craig/TFTP/gumstix-factory.script combined with the BOOTCOMMAND from u-boot's base.patch from gumstix SVN makes me think that all you have to do is drop gumstix-factory.script and a valid root filesystem called root_fs_arm onto a fat formated MMC card. That should do it. I'll probably make an attempt at flashing from CF later. Note that this will REFLASH your stix. It won't let you just boot an arbitrary kernel from MMC, although with all of u-boot's coolness I am sure that is possible with a little script-foo. -- Kristian Kielhofner |
From: ken s. <ken...@gm...> - 2006-10-10 06:51:32
|
On 10/9/06, Craig Hughes <cr...@gu...> wrote: > On Oct 9, 2006, at 3:08 PM, Kristian Kielhofner wrote: > > > That is interesting because I have had great success with kexec on > > x86. > > I suppose it remains to be seen how stable it is with ARM. > > I have admitedly only tried it on x86_64; it is supposed to work > there though, but I couldn't get it to (gentoo with custom kernel build) from the kexec docs: i386 and ppc can turn off their mmu while x86_64 cannot, yet they all implement identity mapped memory for code running in the processors native mode. kexec is diabled in the kernel for arm. this patch: http://www.rpsys.net/openzaurus/patches/kexec-arm-r1.patch builds a 2.6.15 kernel that runs, but the userspace kexec-tools don't support arm. configure: error: unsupported architecture arm --- ken |
From: ken s. <ken...@gm...> - 2006-10-10 07:24:05
|
On 10/9/06, ken staton <ken...@gm...> wrote: > On 10/9/06, Craig Hughes <cr...@gu...> wrote: > > On Oct 9, 2006, at 3:08 PM, Kristian Kielhofner wrote: > > > > > That is interesting because I have had great success with kexec on > > > x86. > > > I suppose it remains to be seen how stable it is with ARM. > > > > I have admitedly only tried it on x86_64; it is supposed to work > > there though, but I couldn't get it to (gentoo with custom kernel build) > > from the kexec docs: > i386 and ppc can turn off their mmu while x86_64 cannot, yet they all implement > identity mapped memory for code running in the processors native mode. > > kexec is diabled in the kernel for arm. > > this patch: http://www.rpsys.net/openzaurus/patches/kexec-arm-r1.patch > builds a 2.6.15 kernel that runs, but the userspace kexec-tools don't > support arm. > > configure: error: unsupported architecture arm > > --- > ken > this patch: http://lists.osdl.org/pipermail/fastboot/2005-March/001290.html builds userspace. crash results later... |
From: Kristian K. <kr...@kr...> - 2006-10-10 16:09:02
|
ken staton wrote: > On 10/9/06, ken staton <ken...@gm...> wrote: > >>On 10/9/06, Craig Hughes <cr...@gu...> wrote: >> >>>On Oct 9, 2006, at 3:08 PM, Kristian Kielhofner wrote: >>> >>> >>>> That is interesting because I have had great success with kexec on >>>>x86. >>>> I suppose it remains to be seen how stable it is with ARM. >>> >>>I have admitedly only tried it on x86_64; it is supposed to work >>>there though, but I couldn't get it to (gentoo with custom kernel build) >> >>from the kexec docs: >>i386 and ppc can turn off their mmu while x86_64 cannot, yet they all implement >> identity mapped memory for code running in the processors native mode. >> >>kexec is diabled in the kernel for arm. >> >>this patch: http://www.rpsys.net/openzaurus/patches/kexec-arm-r1.patch >>builds a 2.6.15 kernel that runs, but the userspace kexec-tools don't >>support arm. >> >>configure: error: unsupported architecture arm >> >>--- >>ken >> > > > this patch: http://lists.osdl.org/pipermail/fastboot/2005-March/001290.html > builds userspace. > > crash results later... I think it is pretty obvious from all of this that although kexec does offer some interesting functionality, for the purpose of booting from CF and flashing flash from Linux, the existing tools (especially u-boot) should be just fine. The extensive functionality of u-boot is really quite impressive. Especially for an app that runs in 150K on bare hardware (as Craig mentioned). When I get some time, I would love to explore the possibilities and write/update some documentation. For instance, this all started because all of the docs that I could find do not say that u-boot can boot from CF on the 'stix. -- Kristian Kielhofner |
From: Craig H. <cr...@gu...> - 2006-10-10 00:15:28
|
On Oct 9, 2006, at 3:47 PM, Kristian Kielhofner wrote: > Wow, so it sounds like U-boot does and can do just about anything > you'd > ever want... Which of course begs the question - why isn't something > like what I proposed setup by default (only using U-boot, of course)? Cos I hadn't gotten around to realizing that it's missing yet ;) This functionality *is* there for MMC, just not for CF. Adding it for CF should be pretty straightforward, once I find an hour or so to do it and test it (with various configurations of hardware). If someone wants to short-circuit the process and send me a bootcmd that they think works, I'd be happy to start there ;) > If someone buys a NetStix, how can they re-flash it or edit the boot > parameters without a serial port? You can edit u-boot parameters with fw_printenv/fw_setenv (be sure your fw_printenv/fw_setenv was compiled against the same version of u- boot as the one you have installed, or you can nuke u-boot!) You can reflash the gumstix u-boot or rootfs from within linux by using flashcp. Note that if flashing the rootfs, you'll need to remount / as read-only, and also probably copy anything you want to run (like flashcp and stuff) to /tmp in RAM first. Also, you need to pad your new rootfs image out with 0xff to the full length of the flash on your gumstix, or else because of the way that JFFS2 works, you'll get bits of the old filesystem "leftover". The NetConsole is also enabled (but not turned on) in u-boot, so you can use that to get a u-boot console over UDP by reading the doc at in the u-boot source directory at u-boot-1.1.4/doc/ README.NetConsole ; assuming you have an OK version of fw_setenv, you can even set that up from within linux. > Thanks for all of the updates on U-boot (and putting up with my crazy > ideas)! :) u-boot is pretty powerful for a ~150k program running on bare hardware. And very extensible too if there's something it doesn't do which you need/want it to do. There's lots of already-written options disabled by default in the gumstix build to keep size down somewhat, but it's really loaded with features if you want them. C |
From: ken s. <ken...@gm...> - 2006-10-10 16:16:30
|
Hi John On 10/10/06, john roll <jo...@cf...> wrote: > > Could someone post an example of this? I'd like to > boot an image or kernel from mcc if thats possible. > http://sourceforge.net/mailarchive/message.php?msg_id=36442003 Regards, Ken |
From: Craig H. <cr...@gu...> - 2006-10-10 18:58:20
|
On Oct 10, 2006, at 9:16 AM, ken staton wrote: > Hi John > > On 10/10/06, john roll <jo...@cf...> wrote: >> >> Could someone post an example of this? I'd like to >> boot an image or kernel from mcc if thats possible. >> > > http://sourceforge.net/mailarchive/message.php?msg_id=36442003 Readable version of the same thread at gmane: http://thread.gmane.org/gmane.linux.distributions.gumstix.general/ 14981/focus=14981 C |
From: ken s. <ken...@gm...> - 2006-10-15 16:41:03
|
On 10/9/06, Craig Hughes <cr...@gu...> wrote: > This functionality *is* there for MMC, just not for CF. Adding it > for CF should be pretty straightforward, once I find an hour or so to > do it and test it (with various configurations of hardware). If > someone wants to short-circuit the process and send me a bootcmd that > they think works, I'd be happy to start there ;) this works with a basix and with a netcf. boots the jffs2 if it doesn't find gumstix-factory.script setenv bootcmd 'icache on\; setenv stderr nulldev\; setenv stdout nulldev\; if pinit on && fatload ide 0 a2000000 gumstix-factory.script\; then setenv stdout serial\; setenv stderr serial\; echo Found gumstix-factory.script...\; autoscr\; else if mmcinit && fatload mmc 0 a2000000 gumstix-factory.script\; then setenv stdout serial\; setenv stderr serial\; echo Found gumstix-factory.script...\; autoscr\; else setenv stdout serial\; setenv stderr serial\; fsload && bootm\; fi\; fi' |
From: Bill K. <bkn...@nc...> - 2006-10-15 16:50:18
|
I've been trying to get python installed and finally got the builroot made and installed, but this version doesn't have the pyserial module I need. I couldn't find anything about that in the menuconfig packages area but I did see in the mail list archives the someone had it working with what they call buildroot r1090. Is there a place I can download this? I've been looking at faq and mail list archives and googling for an hour and not yet found if and where there is a repository of ready made buildroots. |
From: ken s. <ken...@gm...> - 2006-10-15 18:58:41
|
On 10/15/06, Bill Knighton <bkn...@nc...> wrote: > I've been trying to get python installed and finally got the builroot > made and installed, but this version doesn't have the pyserial module I > need. I couldn't find anything about that in the menuconfig packages The pyserial module is not distributed _with_ Python. installing Python modules is most easily done using a native environment (rather than a cross compiler). > area but I did see in the mail list archives the someone had it working > with what they call buildroot r1090. Is there a place I can download > this? I've been looking at faq and mail list archives and googling for > an hour and not yet found if and where there is a repository of ready > made buildroots. look here: http://docwiki.gumstix.org/Root_filesystems#Using_the_MMC_Card_as_the_Root_Filesystem devsys_mmc_r1090.zip includes a root filesystem with python, pyserial, pexpect, and pysqlite. it also has gcc which is required for pysqlite. googling likely didn't lead you to this page on the wiki because it was created recently. Regards, Ken |
From: Justin F. <ju...@er...> - 2006-10-15 21:48:47
|
I've had success adding pyserial after the fact. Simply download the platform independent source from the project page (http://pyserial.sourceforge.net/), uncompress, copy to the Gumstix, and run "python setup.py install". Viola. Justin -----Original Message----- From: ken staton [mailto:ken...@gm...] Sent: Sunday, October 15, 2006 12:59 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] is there a repository of ready made buidroots? On 10/15/06, Bill Knighton <bkn...@nc...> wrote: > I've been trying to get python installed and finally got the builroot > made and installed, but this version doesn't have the pyserial module I > need. I couldn't find anything about that in the menuconfig packages The pyserial module is not distributed _with_ Python. installing Python modules is most easily done using a native environment (rather than a cross compiler). > area but I did see in the mail list archives the someone had it working > with what they call buildroot r1090. Is there a place I can download > this? I've been looking at faq and mail list archives and googling for > an hour and not yet found if and where there is a repository of ready > made buildroots. look here: http://docwiki.gumstix.org/Root_filesystems#Using_the_MMC_Card_as_the_Root_F ilesystem devsys_mmc_r1090.zip includes a root filesystem with python, pyserial, pexpect, and pysqlite. it also has gcc which is required for pysqlite. googling likely didn't lead you to this page on the wiki because it was created recently. Regards, Ken |
From: G E. <gel...@gm...> - 2006-10-15 22:24:46
|
for modules that do need to be compiled, i was able to successfully cross-compile pysqlite, pymad, pyao, and pybluez using the compiler provided with the buildroot, so that is another option. greg On Oct 15, 2006, at 2:48 PM, Justin Ford wrote: > I've had success adding pyserial after the fact. Simply download the > platform independent source from the project page > (http://pyserial.sourceforge.net/), uncompress, copy to the > Gumstix, and run > "python setup.py install". Viola. > > Justin > > -----Original Message----- > From: ken staton [mailto:ken...@gm...] > Sent: Sunday, October 15, 2006 12:59 PM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] is there a repository of ready made > buidroots? > > On 10/15/06, Bill Knighton <bkn...@nc...> wrote: >> I've been trying to get python installed and finally got the builroot >> made and installed, but this version doesn't have the pyserial >> module I >> need. I couldn't find anything about that in the menuconfig packages > > The pyserial module is not distributed _with_ Python. > installing Python modules is most easily done using a native > environment > (rather than a cross compiler). > >> area but I did see in the mail list archives the someone had it >> working >> with what they call buildroot r1090. Is there a place I can download >> this? I've been looking at faq and mail list archives and >> googling for >> an hour and not yet found if and where there is a repository of ready >> made buildroots. > > look here: > http://docwiki.gumstix.org/ > Root_filesystems#Using_the_MMC_Card_as_the_Root_F > ilesystem > > devsys_mmc_r1090.zip includes a root filesystem with python, > pyserial, pexpect, and pysqlite. it also has gcc which is required for > pysqlite. > > googling likely didn't lead you to this page on the wiki because it > was created recently. > > Regards, > Ken > > > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Bill K. <bkn...@nc...> - 2006-10-19 04:02:19
|
Justin Ford wrote: > I've had success adding pyserial after the fact. Simply download the > platform independent source from the project page > (http://pyserial.sourceforge.net/), uncompress, copy to the Gumstix, and run > "python setup.py install". Viola. > > It installed ok, but when I go to use it: >>> import serial Traceback (most recent call last): File "<stdin>", line 1, in ? File "serial/__init__.py", line 15, in ? from serialposix import * File "serial/serialposix.py", line 13, in ? import sys, os, fcntl, termios, struct, select, errno ImportError: File not found I installed py-serial on an ipaq with Familiar linux on it. It needed : python-stringold python-fcntl python-terminal from ipkg's before py-serial worked. I think the above is the same error message I got on th ipaq. Did you already have this stuff on your gumstix? |
From: Justin F. <jus...@ho...> - 2006-10-19 23:58:32
|
Weird...no, didn't have to fool with anything like that. Just did the buildroot with Python, booted up for the first time, and installed PySerial. No trouble. I'm not sure what the difference is in your case... -----Original Message----- From: Bill Knighton [mailto:bkn...@nc...] Sent: Wednesday, October 18, 2006 10:02 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] py-serial installation Justin Ford wrote: > I've had success adding pyserial after the fact. Simply download the > platform independent source from the project page > (http://pyserial.sourceforge.net/), uncompress, copy to the Gumstix, and run > "python setup.py install". Viola. > > It installed ok, but when I go to use it: >>> import serial Traceback (most recent call last): File "<stdin>", line 1, in ? File "serial/__init__.py", line 15, in ? from serialposix import * File "serial/serialposix.py", line 13, in ? import sys, os, fcntl, termios, struct, select, errno ImportError: File not found I installed py-serial on an ipaq with Familiar linux on it. It needed : python-stringold python-fcntl python-terminal from ipkg's before py-serial worked. I think the above is the same error message I got on th ipaq. Did you already have this stuff on your gumstix? |
From: Bill K. <bkn...@nc...> - 2006-10-20 13:41:22
|
Justin Ford wrote: > Weird...no, didn't have to fool with anything like that. Just did the > buildroot with Python, booted up for the first time, and installed PySerial. > No trouble. I'm not sure what the difference is in your case... > > I think I just need to reinstall everything. If I start python for the first time after reboot and import serial there's that error. If I exit python and do it again everything is fine. But sometimes that error will say "segentation fault". It does successfully send and recieve. |
From: ken s. <ken...@gm...> - 2006-10-19 04:51:58
|
On 10/18/06, Bill Knighton <bkn...@nc...> wrote: > Justin Ford wrote: > > I've had success adding pyserial after the fact. Simply download the > > platform independent source from the project page > > (http://pyserial.sourceforge.net/), uncompress, copy to the Gumstix, and run > > "python setup.py install". Viola. > > > > > It installed ok, but when I go to use it: > >>> import serial > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "serial/__init__.py", line 15, in ? > from serialposix import * > File "serial/serialposix.py", line 13, in ? > import sys, os, fcntl, termios, struct, select, errno > ImportError: File not found > > I installed py-serial on an ipaq with Familiar linux on it. It needed : > python-stringold > python-fcntl > python-terminal > from ipkg's before py-serial worked. I think the above is the same > error message I got on th ipaq. > Did you already have this stuff on your gumstix? The process of converging on answers goes a little faster with more information: which buildroot version did you build? which py-serial version did you build? I assume you did: cd pyserial-2.2 python setup.py install Did you change anything else with make menuconfig (when you were turning python on)? I've just built: buildroot rev 1090 with pyserial-2.2 import serial works fine. You can check which of the modules by importing them separately: > File "serial/serialposix.py", line 13, in ? > import sys, os, fcntl, termios, struct, select, errno > ImportError: File not found import sys import os etc I'll bet on termios... Regards, Ken |
From: Bill K. <bkn...@nc...> - 2006-10-22 02:03:34
|
ken staton wrote: > The process of converging on answers goes a little faster with more information: > which buildroot version did you build? > which py-serial version did you build? > I assume you did: > cd pyserial-2.2 > python setup.py install > > Did you change anything else with make menuconfig (when you were > turning python on)? > > I've just built: buildroot rev 1090 with pyserial-2.2 > import serial works fine. > > You can check which of the modules by importing them separately: > >> File "serial/serialposix.py", line 13, in ? >> import sys, os, fcntl, termios, struct, select, errno >> ImportError: File not found >> > import sys > import os > etc > > I'll bet on termios... > > Regards, > Ken > > -- I was using the latest version. I think it was 1137. I did have a bunch of other stuff selected. I did it over with r1090. I still got a few other things with menuconfig. But this time there were no errors. |