Monday, April 28, 2008
10 Coming Soon...
I'm pretty busy with the lead-up to exams, so I'm going to delay my final conclusions and report until exams and assignments are finished and the dust has settled. Unfortunately, the project never really got fully off the ground (there haven't been enough puns) because of issues with integration and the gumstix doing us the favour of kicking up a fuss at the last minute, but I feel the need to do a final write-up of what went right, what didn't, and what should have been done differently, knowing what I now know.
Wednesday, April 9, 2008
09 Frustrated Flashing
Since we need more packages on the gumstix than we were given, I went about flashing the file-system, playing it safe by first checking out a revision slightly after they started including C++ support by default in the buildroot.
Checking out revisions is very easy, just a standard subversion checkout command:
I began by installing the extra packages onto our current gumstix revision - if it ain't broke, and all. Checking out revisions, while easy, takes a bit of time. Then, the making of the revision takes an even longer time: probably around 2 hours or so for the latest ones. Couple this with another 40-60 minutes for transferring the file-system via serial to the gumstix, and you've got a long wait ahead.
Flashing the file-system is fairly straightforward:
I tried a few post-1444 revisions but running the makefile just wasn't working for some reason. Having run into this hitch, I decided to just opt for the latest release - supposedly not the most stable but it managed to make successfully, so it was worth a shot.
However, it turns out that the bootloader currently being used by the gumstix, u-boot 1.1.4, was older than the compiled u-boot provided with my new revision: u-boot 1.2.0. This meant that not only did I have to flash the file-system and kernel to the gumstix, I also had to replace u-boot which, as I understand from the U-Boot wiki, is tantamount to manually disarming a minefield - one slip-up and I'm toast.
Putting on the file-system was the same as previously quoted, and transferring the kernel was very similar:
So, I decided to flash the file-systemagain, to revision 1445 this time as I'd seen it mentioned as working on the buildroot wiki. Another make, another transfer, and the wifistix was being detected again - I was very glad here, as it ensured me that the system wasn't bricked. Unfortunately, there were still a few problems with the wireless; I was able to scan for networks, but not able to connect to my home network. A bit of searching around online lead me, ironically, to a page about gumstix wireless on the UCD trac. Turns out that the revision I was using dropped the last character on the network essid.
So, at this stage I had my extra packages on the gumstix, and was actually able to test them out. C++ cross compilation worked fine, albeit with a small hello world programme. gpsd was also present, as was gpspipe, which was an excellent sign as they had not previously been included. Unfortunately though, I wasn't able to test either of these features because of the bluetooth not working.
At this point, I'm facing a dilemma: do I flash to yet another revision of the file-system in the hope of fixing the bluetooth, and risk breaking something new, or do I attempt to fix the bluetooth on the current revision? I've been attempting the latter all day, with no result, so I may have to flash a new revision. I'm hoping a solution to my bluetooth problem will pop up tomorrow.
Checking out revisions is very easy, just a standard subversion checkout command:
# svn co http://svn.gumstix.com/gumstix-buildroot/trunk gumstix-buildroot
for the latest build, or# svn co -rXXXX http://svn.gumstix.com/gumstix-buildroot/trunk gumstix-buildroot
for a specific revision, where XXXX is the revision number required.I began by installing the extra packages onto our current gumstix revision - if it ain't broke, and all. Checking out revisions, while easy, takes a bit of time. Then, the making of the revision takes an even longer time: probably around 2 hours or so for the latest ones. Couple this with another 40-60 minutes for transferring the file-system via serial to the gumstix, and you've got a long wait ahead.
Flashing the file-system is fairly straightforward:
{Interrupt the boot}
GUM>loadb a2000000
{Access transfer menu in hypertrm and send rootfs.arm_nofpu.jffs2 file}
GUM>protect on 1:0-1
GUM>erase all
GUM>cp.b a2000000 40000 ${filesize}
GUM>boot
I tried a few post-1444 revisions but running the makefile just wasn't working for some reason. Having run into this hitch, I decided to just opt for the latest release - supposedly not the most stable but it managed to make successfully, so it was worth a shot.
However, it turns out that the bootloader currently being used by the gumstix, u-boot 1.1.4, was older than the compiled u-boot provided with my new revision: u-boot 1.2.0. This meant that not only did I have to flash the file-system and kernel to the gumstix, I also had to replace u-boot which, as I understand from the U-Boot wiki, is tantamount to manually disarming a minefield - one slip-up and I'm toast.
GUM>loadb a2000000
{Access transfer menu in hypertrm and send u-boot.bin file}
GUM>protect off 1:0-1
GUM>era 1:0-1
GUM>cp.b a2000000 0 ${filesize}
GUM>reset
Putting on the file-system was the same as previously quoted, and transferring the kernel was very similar:
{Interrupt the boot}
GUM>loadb a2000000
{Access transfer menu in hypertrm and send uImage file}
GUM>katinstall 100000
GUM>katload 100000
GUM>bootm
So, I decided to flash the file-systemagain, to revision 1445 this time as I'd seen it mentioned as working on the buildroot wiki. Another make, another transfer, and the wifistix was being detected again - I was very glad here, as it ensured me that the system wasn't bricked. Unfortunately, there were still a few problems with the wireless; I was able to scan for networks, but not able to connect to my home network. A bit of searching around online lead me, ironically, to a page about gumstix wireless on the UCD trac. Turns out that the revision I was using dropped the last character on the network essid.
So, at this stage I had my extra packages on the gumstix, and was actually able to test them out. C++ cross compilation worked fine, albeit with a small hello world programme. gpsd was also present, as was gpspipe, which was an excellent sign as they had not previously been included. Unfortunately though, I wasn't able to test either of these features because of the bluetooth not working.
At this point, I'm facing a dilemma: do I flash to yet another revision of the file-system in the hope of fixing the bluetooth, and risk breaking something new, or do I attempt to fix the bluetooth on the current revision? I've been attempting the latter all day, with no result, so I may have to flash a new revision. I'm hoping a solution to my bluetooth problem will pop up tomorrow.
Monday, April 7, 2008
08 GPS and Filesystems
Rejuvenated from the midterm break, and my trip to Nice I dived right back into working on the Gumstix...almost. An exam on the first week back after the break scuppered that slightly, but our subsequent team meeting with Graham went pretty well in terms of discussing milestones, completed as well as upcoming, and this got me focused on the project again. Graham suggested a good plan of attack for getting at the GPS receiver that just hadn't occurred to me previously: bypass the gumstix and try talk to it through a normal unix/linux box. This way I'd be able to spot if connecting and communication was working smoothly with the proposed utilities, before porting them all onto the gumstix.
Unfortunately, I don't have Bluetooth on my laptop, but thankfully John does! Ironically though, John's laptop decided to bork itself the very minute we tried to start testing. Fortunately, it was only a minor breakage (in terms of things I needed working, anyway...) and we were able to test out gpsd and gpspipe in communicating with the GPS receiver.
As previously mentioned, the first step to this is to bind /dev/rfcomm1 to the MAC address of the GPS:
Everything appeared to be working fully, with a stream of information being printed to screen from the GPS unit. We didn't try too hard in deciphering the data the GPS was providing as this wasn't the main goal of the exercise, and making sure that these functions work on the gumstix is a higher priority at the moment.
With this small victory in hand, I decided to try and finally flash the gumstix file-system. Firstly, I added any necessary extra packages to the buildroot and recompiled; no problems there, and the file-system was ready. I transferred this new file-system over serial, which took an absolute age, but seemed to be a safer option than flashing over, say, SSH.
When the file-system arrived it booted with no problem, for which I was rather glad. Then I realised that the wifistix activity light wasn't flashing; for some reason it just wasn't working. Figuring that I may have left out a package in the buildroot, I went back to the configuration section but unfortunately nothing jumped out at me. I did read on the gumstix wiki, however, that wifistix support is not automatically enabled in some of the older gumstix revisions - I suppose this is an excuse to get a newer revision with, hopefully, some problems ironed out.
Unfortunately, I stayed up quite late with the transferring of the new file-system (I think this may have taken close to an hour for a 3mb file), and slept in for a team meeting; oh dear...
Unfortunately, I don't have Bluetooth on my laptop, but thankfully John does! Ironically though, John's laptop decided to bork itself the very minute we tried to start testing. Fortunately, it was only a minor breakage (in terms of things I needed working, anyway...) and we were able to test out gpsd and gpspipe in communicating with the GPS receiver.
As previously mentioned, the first step to this is to bind /dev/rfcomm1 to the MAC address of the GPS:
# rfcomm bind 1 00:0E:6D:5B:41:05
From here we merely need to start the gps daemon (gpsd) with rfcomm1 as an argument, and begin piping (gpspipe) the data being produced by the GPS receiver.# gpsd -n /dev/rfcomm1
# gpspipe -r
Everything appeared to be working fully, with a stream of information being printed to screen from the GPS unit. We didn't try too hard in deciphering the data the GPS was providing as this wasn't the main goal of the exercise, and making sure that these functions work on the gumstix is a higher priority at the moment.
With this small victory in hand, I decided to try and finally flash the gumstix file-system. Firstly, I added any necessary extra packages to the buildroot and recompiled; no problems there, and the file-system was ready. I transferred this new file-system over serial, which took an absolute age, but seemed to be a safer option than flashing over, say, SSH.
When the file-system arrived it booted with no problem, for which I was rather glad. Then I realised that the wifistix activity light wasn't flashing; for some reason it just wasn't working. Figuring that I may have left out a package in the buildroot, I went back to the configuration section but unfortunately nothing jumped out at me. I did read on the gumstix wiki, however, that wifistix support is not automatically enabled in some of the older gumstix revisions - I suppose this is an excuse to get a newer revision with, hopefully, some problems ironed out.
Unfortunately, I stayed up quite late with the transferring of the new file-system (I think this may have taken close to an hour for a 3mb file), and slept in for a team meeting; oh dear...
Subscribe to:
Posts (Atom)