[Jesse Gilles]

Edit /etc/default/dropbear and add the following line:

DROPBEAR_PORT=x

Where x is your port number.

[Jesse Gilles]

> I can go into U-boot but without network, the device can’t tftp the new rootfs.

You should still able to flash the rootfs over Ethernet via U-boot, as BT posted.

[Jesse Gilles]

Hi Lucas,

I’ve actually just made changes to address this type of issue. It can be fixed by adding udev rules that gives the modem a consistent name, even if the ttyUSB port name changes.

See commit:

http://git.multitech.net/cgi-bin/cgit.cgi/corecdp.git/commit/?id=8efda18df6ac54debdf651c7b9359ff04acd47af

This will be included in the next release of CoreCDP, which is currently in testing, but you are free to try the changes now.

If you use the rules from that commit, you can then set your ppp options file to use /dev/modem_at0 and that name will always point to the correct modem port.

Jesse

[Jesse Gilles]

You can try applying the patch to the meta-java subdir inside your corecdp directory.

Something like:

cd corecdp-2.1.0/meta-java

patch -p1 < the_patch

[Jesse Gilles]

The output pins are open collector outputs to make them more flexible for driving different types of circuitry (relays, etc) — this means the pin is floating for a logical 1, and driven to ground for logical 0. If you want to use the output as a standard digital out, you need an external pullup resistor to create a high voltage level.

Here is more information:

http://www.multitech.net/developer/products/multiconnect-ocg/hardware/multiconnect-ocg-d/gpio-interface-electrical-requirements/

Also, I’ve left the pin names on the website as External Input/Output and updated the doc on the mts-io driver to match instead.

[Jesse Gilles]

I updated the connector page to rename the pins as “Digital Input/Outputs” to better match with the driver names.

[Jesse Gilles]

You are correct, din6 (Digital Input 6) is the same as External Input 6 — just inconsistent naming. Sorry for the confusion.

Jesse

[Jesse Gilles]

There are likely patches and workarounds available for some of the incompatibilities in the upstream OpenEmbedded project. You are free to search their mailing lists and git repos and apply fixes you find.

Currently, building CoreCDP 2.0.2 will NOT work with any Ubuntu 11.10 version, that is correct. It’s possible that an update will be made to improve compatibility, but we ran into multiple issues with several software packages at release time, so it was decided not to support it. If you don’t want to bother with trying to fix the build issues, then we recommend using one the tested distributions documented in the release notes.

[Jesse Gilles]

Unfortunately this isn’t possible with the existing hardware design.

This is something that could possibly be available in future hardware revisions.

[Jesse Gilles]

Ah, sorry, I meant 10.04 LTS, but 11.04 is supported as well. Either 64 or 32-bit is fine.

[Jesse Gilles]

Yes, Ubuntu 11.10 came out not very long before CoreCDP 2.0.2 and there are build problems with it — so it’s unsupported for now. The release notes specify distributions that are known to work. I recommend installing Ubuntu 11.04 LTS.

[Jesse Gilles]

Hm, it looks like you did the right thing with the udev rule. Perhaps try changing the priority of your rule so it runs earlier?

Another option is to use the persistent serial dev names instead of /dev/ttyUSBX. Have a look in /dev/serial/by-id.

[Jesse Gilles]

GRE is built into the kernel already, you don’t need to load a module for it.

[Jesse Gilles]

If you haven’t already, try connecting the debug serial cable and logging the output. This will show any messages from the kernel and any other messages that go to the system console.

Does the unit behave this way if you don’t have the PPP link up? When you do have the link up, is it being used heavily or is it mostly idle?

Thanks,

Jesse

[Jesse Gilles]

There is bluetooth support available in the kernel, but it is not compiled by default. The kernel config needs to be modified to build it.

For CoreCDP 2, this is located at:

multitech/recipes/linux/linux-2.6.35/mtcdp/defconfig

Then user libraries/apps are needed. See the “bluez” recipes available in openembedded/recipes. Note that bluetooth support has not been tested yet at this point by Multi-Tech.

Jesse

[Jesse Gilles]

do_compile () {

${CC} ${CFLAGS}${LDFLAGS} hellobrother.c -o hellobrother

}

You’re missing a space between CFLAGS and LDFLAGS on your compile line. It’s mashing the options together that get passed to gcc.

[Jesse Gilles]

> is the correct way to read this data cat /dev/ttyS3?

You should be able to read data that way, yes. You can also use ‘microcom’ — it usually works better and it is better for doing serial-specific communication because you can set baud rate, etc. The GPS transmits at 9600 baud and microcom also defaults to 9600, so you should be able to run ‘microcom /dev/ttyS3’ and see the NMEA data coming out.

> is it correct that I need to run venus-gps as a daemon in order to read the data from /dev/ttyS3?

No, you don’t need to run venus-gps at all to read GPS data from the receiver. Just open /dev/ttyS3 at 9600 baud. If you’re having issues, I would try power cycling the unit, and then running ‘microcom /dev/ttyS3’ after it boots up. This should work or something is wrong. You only need to use venus-gps if you want to change settings on the GPS receiver or if you want to send the data to a TCP/UDP socket, etc. You should only have one program at a time reading data from /dev/ttyS3 — either venus-gps or microcom, or a piece of custom software, but not more than one.

> how can I programmatically determine whether the GPS is properly initialized and has a fix?

Once you can read data from /dev/ttyS3, you can decode the NMEA data to see if the receiver has a fix or not. There is a link to a NMEA document on the References page

http://www.multitech.net/developer/products/multiconnect-ocg/references/

General info on talking to the receiver:

http://www.multitech.net/developer/products/multiconnect-ocg/applications/venus-gps-receiver/

> how can I see if the GPS has a fix (e.g. via a LED?)

There is an LED on the GPS board that shows when it has a fix, but you have to remove the case to see it. You’ll be able to see which board it is by looking at where the GPS antenna cable is connected. The LED flashes when it has a fix and it’s solid when it does not.

[Jesse Gilles]

How frequently are you seeing the trap warning? I see the timestamps are close together…how many msgs per second? Also, does it do this the entire time the program is running or just once in a while?

[Jesse Gilles]

If the alignment warnings don’t end up causing any issues, which they may not, you can disable the warning as such:

echo 2 > /proc/cpu/alignment

Here is more info on the setting

http://www.kernel.org/doc/Documentation/arm/mem_alignment

Fixing the alignment issue yourself may or may not be simple, but if you’re not too familiar with C debugging, it will be more difficult. It’s probably easier to report the issue to the project authors. Let me know if you narrow it down.

[Jesse Gilles]

What is “traacerlinkd”? I can’t find any reference to it anywhere.

The log messages means that the kernel detected a mis-aligned memory access by that particular process and it tries to fix it if possible. If the process doesn’t crash then it may not cause any noticeable problems, but it is generally indicative of an alignment bug.

[Jesse Gilles]

The php recipe is on git.multitech.net. There may be some compatibility issues with using that recipe with CoreCDP 1.x, yes — this is due to changes in OpenEmbedded and Bitbake. You are free to try it out and see what happens.

To try compiling with sqlite, you would have to add sqlite to the DEPENDS variable and edit the EXTRA_OECONF to build with sqlite instead of without. This might take some research and you’ll need to be familiar with configuring and compiling php to get it working.

I may try to expand the recipe to add sqlite support in the future if I have time, but this would only get tested against CoreCDP 2.x.

[Jesse Gilles]

Also, php isn’t compiled with sqlite support by default — the recipe would need to be modified to change that and see if it builds.

[Jesse Gilles]

CoreCDP 2.0.2 was just released and includes php 5.3.6. You could give that a try if you wish, but it is a major new release and you’ll have to rebuild everything in a new directory.

[Jesse Gilles]

Good deal, glad you got it working.

[Jesse Gilles]

I think the reason your “md5sum test” test didn’t work was because vi didn’t create an empty file on the MTCDP. When I try it, the file is 1 byte instead of 0 (on my Ubuntu box).

The md5sums should most definitely match or they aren’t the same 🙂

[Jesse Gilles]

Using SCP is also reliable for doing file transfers. Or putting the SD card in a card reader attached to your PC.

[Jesse Gilles]

Input file is not page-aligned. Use the padding option.

Data was only partially written due to error

That was the error returned from trying to flash from the SD card. There has to be something different between the two files. Did you compare sizes, checksums etc? Seems like the image file on the SD card is bad.

[Jesse Gilles]

Hm, no that is odd. You’re certain it’s the same rootfs in both scenarios (check file size, checksum, etc)?

When you do the flashing from SD card, do you see any errors on the debug serial port?

[Jesse Gilles]

You can do this, but the only reason really would be to save some space. You can select between the VMs on the fly when you run java on the device. Even if cacao is installed, zero is still the default VM when you run java. Run ‘java -help’ to see the list of options. You can run ‘java -zero’ or ‘java -cacao’.

[Jesse Gilles]

It’s a little confusing, but a bitbake recipe can provide multiple packages. The nfs-utils recipe provides both the nfs-utils and the nfs-utils-client package. When you bitbake nfs-utils, it should give you an nfs-utils-client package in your deploy dir. Or, if you build a custom image, just add “nfs-utils-client” to IMAGE_INSTALL.

[Author]

Posts