With the UDP side of the protocol out of the way I moved on to the TCP side, which is used to actually communicate with the device (for example to use one of the serial ports).Read more…
We ended the last post having split up the UDP scan/refresh response into individual fields, with each consisting of a value identifier, a length, and the actual content of the field. Now we come to deciphering the meaning of those fields.Read more…
The DeviceMaster range, at least with current firmware and drivers, uses a UDP-based protocol for discovery. The obvious first step, then, was to start Wireshark and log a few scans performed via PortVision DX. The Scan function within PortVision DX sent messages of the following form to the UDP broadcast address 255.255.255.255 on port 4606:
a9 8d fd 53 7a 1c b0 de 00 00 2c 00 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A lot of zeros there, not much to go on. Performing more scans showed the the 0x2c in byte 11 was incrementing, so this was presumably a sequence number of some kind. Leaving PortVision DX open overnight showed that it was a 16 bit count in little-endian byte order. The 0x0c byte could be specifying a function—in this case a scan.Read more…
This is the first post of a short series describing my effort to reverse engineer the protocol used by Comtrol for their DeviceMaster range of Ethernet device servers. These allow RS-232/422/485 connected devices to be communicated with over an ethernet network.
This is another error related to using a newer version of texinfo than expected. It’s also another “wait for it to fail and then edit in the working directory” solution unless someone can provide a better option.
Once the build has failed with the following message:
grep.texi:291: @itemx must follow @item
open up $GUMSTIXTOP/tmp/work/x86_64-linux/grep-native-2.5.1-r2/grep-2.5.1/doc/grep.texi and delete lines 286 to 290 (inclusive). Side-effect: your generated documentation will no longer be perfect.
For my third post on compiling OpenEmbedded for Gumstix on a modern system, we come across errors downloading base-passwd, busybox, curl, dosfstools, fakeroot, file, gconf-dbus, git, iana-etc, ipkg, ipkg-utils, libxml-parser-perl, libxml2, mime-support, module-init-tools, netbase, openssl, pax-utils, pcmciautils, popt, pxaregs.c, setserial, sysvinit, tinylogin, tslib, udev, update-alternatives, update-rc.d, usbutils, util-linux, and zlib.
This is a simple problem and a simple fix: old versions of these packages are either moved to a different location or removed entirely, so we change the URLs that the build process uses. Beware: using alternate sources for these packages carries an inherent risk – you may be downloading a modified version without knowing. Where possible you should also add hash entries for each file based on a known good value.Read more…
This error message provides very little clue as to what the actual problem is when compiling Python during the OpenEmbedded build process:
gcc: error: directory”: No such file or directory
As it turns out (thanks to the tip here), this is caused by a change in subversion.
Luckily it’s easy to inject your own copy earlier in the path than the one it usually finds. Simply create a script called svnversion in $GUMSTIXTOP/bitbake/bin and insert the following:
#!/bin/sh echo exported
Your problem should be solved.
I received the following error when compiling OpenEmbedded due to a file that is no longer included in Perl distributions:
| Can’t locate find.pl in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at perlpath.pl line 7.
There are ways to integrate a copy of the file into the build process, but my inexperience with bitbake et al. meant that when they didn’t work I couldn’t troubleshoot very well myself. Instead, I simply placed the file in /etc/perl. The contents of the file, which should be called find.pl, can be found below.Read more…
The second problem I encountered in building OpenEmbedded for our Gumstix devices was a failure when downloading binutils. Specifically, the checksum found for the downloaded file didn’t match the one that the build process expected. The message given is:
NOTE: The MD5Sums did not match. Wanted: ‘9d22ee4dafa3a194457caf4706f9cf01’ and Got: ‘ccd264a5fa9ed992a21427c69cba91d3’
NOTE: Task failed: Checksum of ‘ftp://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.bz2’ failed
NOTE: package binutils-cross-2.18-r1: task do_fetch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of /home/kemp/gumstix/gumstix-oe/org.openembedded.snapshot/packages/binutils/binutils-cross_2.18.bb do_fetch failed
ERROR: Task 317 (/home/kemp/gumstix/gumstix-oe/org.openembedded.snapshot/packages/binutils/binutils-cross_2.18.bb, do_fetch) failed
The error is due to an incompatibility between older versions of binutils and newer versions of texinfo. This post show you how to resolve this.Read more…
I have had to check out our Gumstix stock and find out if it’s still usable. They are a mix of old Connex and (non-Pro) Verdex boards and so the only OS I can build for them is OpenEmbedded. I have yet to find out if the currently available version from the Gumstix website actually works with these versions of the boards, but one step at a time…
This post walks through how to solve the following error message when building OpenEmbedded on modern systems:
| configure: error:
| quilt requires at least version 2.4 of GNU patch. You can download a
| current version of patch from ftp.gnu.org, or if you already have GNU patch
| then you can supply its path with the ‘–with-patch=’ option.