[Jesse Gilles]

Yeah, you need to load the kernel image from 2.0 along with the rootfs. The kernel in 2.0 is different than in 1.1.1, so you don’t have any kernel modules in your rootfs that match your kernel you are running.

I would rebuild your kernel in case something went wrong.

bitbake linux -c clean; bitbake corecdp-base-image

Then try flashing just the kernel from U-Boot. There isn’t really a way to test the uImage before you load it, you can only really checksum it to ensure the file transfer worked. If the flashing goes badly, you can just boot back into U-Boot and flash a different kernel again.

[Jesse Gilles]

Flashing from U-boot is by far the easiest and fastest method.

Did you examine your U-boot environment and make sure everything got set correctly?

“We’re not able to load an image from U-Boot.”

Please be more specific. Are you still having problems setting environment variables? Failing to TFTP files? Failing to boot from an already flashed image?

[Jesse Gilles]

If you modify a file provided by a package which has already been built, it doesn’t get automatically rebuilt because it doesn’t know you changed anything.

You either need to modify the bitbake recipe and increment the PR variable (package revision) or ‘clean’ the package and rebuild it. (bitbake package -c clean; bitbake package)

[Jesse Gilles]

That sounds like the issue I had with minicom and Ubuntu 10.04. The uboot-setenv script never exits, but I think it works properly. Try resetting the unit and then run ‘print’. If all of the variables are set correctly then it worked.

Then try flashing again.

[Jesse Gilles]

The factory image is corecdp-full-image from CoreCDP 1.1.1. CoreCDP 2.0.x isn’t released yet, so no units are shipping with it.

There is a minor change to the flashing from Linux procedure for CoreCDP 2.0.0. So if you flash in a 2.0.0 corecdp-base-image, you’ll need to add one more step to your flash procedure using Linux. If you have 1.1.1 on there when you flash from Linux, then you don’t need the extra step.

If you’re flashing from 2.0.0, you need to create the file /var/volatile/do_flash_upgrade before rebooting. If this file doesn’t exist, it will skip upgrading even if the appropriate files are in /media/card/flash-upgrade. This is useful because it prevents unintended flashing if the unit is rebooted again without removing the files in /media/card/flash-upgrade.

So put the files in the usual spot with right names in /media/card/flash-upgrade and then run:

touch /var/volatile/do_flash_upgrade

reboot

This will get added to documentation once 2.0.x is released.

[Jesse Gilles]

How did you attempt to flash the openjdk image in? If you tried it from u-boot using tftp, it won’t work unfortunately, because the image is too large to fit in RAM (64 MB). OpenJDK is very large so any image created that includes it will be too large to flash via u-boot/tftp and has to be flashed from Linux by putting it on the SD card first.

If your unit doesn’t boot anymore, flash the base-image from u-boot first. Then boot up and transfer the openjdk-image to the SD card and flash it that way. There are instructions on flashing from Linux farther down on the NAND flash programming page.

Not exactly sure what your issue is with the uboot-setenv script…it looks like there is a new line in your setenv bootcmd, which causing it to try to execute the bootm command rather than saving it in the bootcmd variable.

What linux distro and version are you using? There is a known issue with using the uboot-setenv script from Minicom on Ubuntu 10.04 where it looks like the script never finishes, but it actually does work. Upgrading minicom fixes it (you can grab the package from a newer Ubuntu version).

[Jesse Gilles]

Not sure why it’s doing that. You may also want to try using the ‘cgi’ module instead of ‘fastcgi’ just to see if you can get that working — I think it’s a little simpler. Otherwise, I would look at the lighttpd docs on their website and go from there.

[Jesse Gilles]

Your lighttpd config is looking for php in /usr/local/bin. It isn’t installed there which is why it is failing…

2011-10-28 15:47:55: (mod_fastcgi.c.990) chdir failed: No such file or directory /usr/local/bin/php

Fix the path to php in your lighttpd config. Run ‘which php’ to see where it is located in $PATH.

[Jesse Gilles]

Yes, you need the lighttpd-module-fastcgi package. You may also need other modules. As I have suggested before, please look at the sample images provided by Multi-Tech. They are in openembedded/recipes/images. Have a look at corecdp-webserver-image.

[Jesse Gilles]

JM K:

There is a web server already on the MTCDP and php is already available for it. Both are installed in the corecdp-full-image, which is preflashed into the unit when it ships. Look at the image recipes located at: corecdp/openembedded/recipes/images/corecdp*

You don’t need to develop an HTTP server, you just need to configure lighttpd the way you want and write some php code and put it in the web directory. Look at the config for lighttpd to see where. Also, there isn’t really anything different for making a PHP-based web interface on the MTCDP versus doing it on a regular Linux machine. Do some searching for building web apps with lighttpd and php and you should be fine. You don’t need anything ARM-specific.

[Jesse Gilles]

Output looks fine to me. It should take quite a while to build as noted on the Getting Started page.

[Jesse Gilles]

Yes, this is normal. If the build stops prematurely and emits errors, that is different.

[Jesse Gilles]

Not sure what the issue is, but it usually means the TMPDIR can’t be found or written to when you run bitbake.

Things to review:

* make sure corecdp is extracted in your home dir

* you aren’t running anything as root

* make sure you loaded the environment script when you were in the right directory

* try removing your TMPDIR (rm -rf build/tmp)

cd corecdp-1.1.1

source env-oe.sh

(run bitbake)

[Jesse Gilles]

The external RS232 port is setup to be a DCE port, so the RX and TX lines are swapped compared to your PC serial port (DTE). You’ll need to use a null modem adapter when you’re connecting the serial device to the CDP since the CDP is DCE and your external device is also DCE.

[Jesse Gilles]

Check that you have write permissions and own the entire directory structure where you extracted corecdp. It is easiest if you extract corecdp under your home directory since you will automatically have the proper permissions.

[Jesse Gilles]

All of the content is on the multitech.net site. Here are some examples:

http://www.multitech.net/developer/products/multiconnect-ocg/development/working-with-a-single-recipe/

http://www.multitech.net/developer/products/multiconnect-ocg/development/creating-a-custom-image/

http://www.multitech.net/developer/products/multiconnect-ocg/development/setting-up-a-package-feed/

[Jesse Gilles]

tcpdump is the right tool for the job, you just need to build it and install it.

[Jesse Gilles]

No, not sure why you’re seeing that. I would double check the checksum on the file and maybe download it manually and make sure you can untar it yourself.

[Jesse Gilles]

Looks like the expat download was bad.

gzip: stdin: invalid compressed data–crc error

Try deleting it and rebuilding. The easiest way to clean up the recipe and any downloaded source code is to run the “distclean” task on it.

bitbake expat -c distclean

[Jesse Gilles]

Where exactly are you having the character issues? With content filled in on the fax cover page? Or are you sending the text body of your email as the first page of the fax (not a cover page)?

[Jesse Gilles]

You mistyped the image name.

[Jesse Gilles]

I noticed you are doing the build outside of your home directory…do you have full permissions to /corecdp-2.0.0?

Check to make sure there is a build sub directory. Bitbake puts all of it’s files in build/tmp under the top directory (/corecdp-2.0.0/build/tmp in your case). Make sure that your entire directory structure is writable by you and that the build dir exists.

[Jesse Gilles]

Mariano,

CoreCDP 2 has not beeen released yet, so there is no more detailed guide than what is provided. When CoreCDP 2.0 is released, the multitech.net website will be updated accordingly.

Please remember you are using unreleased, unsupported code.

To summarize the steps, here is what you should do after you’ve cloned the repo. You can skip checking out a specific tag or branch since there isn’t any release tags yet, only the master branch.

cd corecdp-2 (or wherever you cloned to)

./setup.sh

source env-oe.sh

bitbake corecdp-openjdk-image

Thanks,

Jesse

[Jesse Gilles]

No, sorry, you can’t send commands from your PC directly to the cellular modem. But you can ssh to the MTCDP and then run microcom to send AT commands to the modem.

[Jesse Gilles]

You could also use a serial cable and connect it to your PC, run terminal software on both ends and send characters back and forth.

[Jesse Gilles]

I think it would be helpful for you to do some research on using gcc in general if you are not familiar with it. If the program compiles successfully, it doesnt print anything out. It only prints messages if there are errors. You specified the -o option to gcc, which told it to put the output as a file named “mymodbuscomm”. If you ran it successfully as you mentioned, then you should have a compiled program called “mymodbuscomm” and you should be able to run it on the MTCDP if the libmodbus library is installed.

You shouldn’t set the path in your Makefile. Bitbake will setup all the paths needed and you should only need to invoke the compiler using the right variables like you had in your recipe in the first place.

$(CC) $(CFLAGS) $(LDFLAGS) mymodbuscomm.c -o mymodbuscomm

If you building the recipe then the paths and variables will be set. They will also be set if you open a devshell. If you don’t do either of those, then you don’t have any special paths set and you have to set them yourself or specify the full path to the compiler when you run it.

[Jesse Gilles]

JM,

I think some of your difficulty is arising from the fact the application needs to be cross compiled, not built for your Linux workstation. This means you have to use a different compiler and that headers and libraries are installed in a non-standard location.

When you are cross-compiling, you can’t just call “gcc” since that will be the compiler for your workstation, not the embedded device. Also, for the same reason, you can’t use includes from /usr/include and libs from /usr/lib because those are also for your workstation.

When you open up the devshell, print out your env (just run “env”) and look at the environment variables defined and you’ll see where the cross-compiler located, etc.

When you run the cross-compiler, it will have the includes and libs for the target system already in its default search paths, so if the libmodbus recipe installed the headers and libs in the right spot, you shouldn’t need to add the -I and -L options to your compile command. But you will need to add ‘-lmodbus’ so it knows to link against.

The compiler is located at:

$OETREE/build/tmp/cross/armv5te/bin

The headers dir that is search by default is:

$OETREE/build/tmp/staging/armv5te-corecdp-linux-gnueabi/usr/include

And libs are in:

$OETREE/build/tmp/staging/armv5te-corecdp-linux-gnueabi/usr/lib

$OETREE is the top of your corecdp directory structure.

[Jesse Gilles]

Hi JM,

A couple of things:

1. Adding “libmodbus” to DEPENDS doesn’t make your application link against it. It makes bitbake know that in order to build your recipe, it needs to build libmodbus first and put the needed files in the sysroot (so your recipe can find the headers and libs). You’ll need to tell GCC that you want to link against the libmodbus library, it doesn’t know about it automatically.

2. You can certainly compile your application right in the bitbake recipe, but it might be easier to manage if you were to write a Makefile to compile it. Then you can actively develop your application by just running make until you get it building. Once you have it building, then you can resume running the bitbake recipe to package it up.

You can open up a development shell with all of the environment variables set for cross-compiling (CC, CFLAGS, LDFLAGS, etc) by running:

bitbake modbuscomm -c devshell

Then you can run make or run $CC and you can fix your build and then go back to running the bitbake recipe again. Also, if you switch to using a Makefile, then your do_compile task goes away and the compiling happens in the make file. You can also do the same thing for do_install if you want.

Hope that helps,

Jesse

[Jesse Gilles]

What server firmware are you using?

[Jesse Gilles]

No, you shouldn’t need to modify anything in the sshd config, it should be listening on all network interfaces by default.

If you have some iptables rules defined, I would try clearing them out all temporarily and then try it again. Without any iptables rules, all traffic should be allowed and you should be able to ssh to the unit if you have a public IP address.

[Author]

Posts