Skip to main content

running jade mobility with phoneME

10 replies [Last post]
fpillone
Offline
Joined: 2008-05-27

Hi guys,

I've compiled phoneME using
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/cdc/trunk cdc
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/jump/trunk jump
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/midp/trunk midp
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/pcsl/trunk pcsl
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/tools/trunk tools
for a PXA270 with no errors.

the problem is when i use jade, everything works perfectly until we talk about mobility. The mobility works well from ubuntu to ubuntu, but when my PXA270 enters the game, i got the following error

Moving now to location : Container-1
jade.core.mobility.AgentMobility: Class [Ljava.lang.Object; not found
jade.core.mobility.AgentMobility: Class [Ljava.lang.Object; not found
jade.core.mobility.AgentMobility: Error creating agent on destination container. Abort transfer. A class was not found during de-serialization [nested java.lang.ClassNotFoundException: [Ljava.lang.Object;]

Can someone help me with it ? Is the serialization working well with phoneME ?

Here is some of the variables used for the compilation, notice that serialization and reflect are true
export USE_AAPCS=true
export CVM_ARM_HAS_WMMX=true
export CVM_OPTIMIZED=true
export CVM_CLASSLOADING=true
export CVM_SERIALIZATION=true
export CVM_REFLECT=true
export CVM_DYNAMIC_LINKING=true
export CVM_JIT=true
export CVM_JIT_REGISTER_LOCALS=true
export USE_MIDP=true
export CVM_DUAL_STACK=true
export USE_SCRIPT_UTILS=true
export USE_JUMP=false
export J2ME_CLASSLIB=basis

Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hi,
>
> Thank you for your explanations about serialization, i'm glad having learnt a few things, such as what the "private static final long serialVersionUID = 3487495895819000L;" field is used to.
>
> I've read much documentation about Jade, but i have NEVER seen anything saying i have to take care about the class hierarchy or JVM version for the mobility, except for MIDP. More over, my movable agent extends the Agent class, which contains "private static final long serialVersionUID = 3487495895819000L;", and extends himself directly the object class. If've well understood what you've told me about serialization, the class hierarchy is not a problem.
>

There is one catch. You should not have a problem when the Agent class
has its own serialVersionUID as long as the parent that you subclass
from also has a serialVersionUID set. Unfortunately, in Java SE 1.4.2,
I don't believe java.lang.Object has serialVersionUID set.

So, if java.lang.Object is different on Java SE 1.4.2 vs. CDC, you will
see a "class not found".

> Moreover, i've once made a mistake, and rather than using the 1.4.2 i was using the 1.6 for a mobility test where i was always staying on the same machine and jvm (i've checked on both consoles with java -version), and the mobility didn't work.
>
> About MIDP and pcsl, a friend has made a script i use to compile the VM. MIDP=true because when i tried with false, the MIDPPkgChecker.class file was not generated and was declared as missing. The file follows, but i've also changed the cdc/build/linux-arm-generic makefile to change "CVM_TARGET_TOOLS_PREFIX=" to "CVM_TARGET_TOOLS_PREFIX?=".

Another possible problem is that you need to be aware that the core lib
support for MIDP is running with API hiding, so the core Java classes
that are seen by the app level is CLDC, not CDC. CLDC is a much smaller
subset of Java SE, so the java.lang.* classes might not match with Java
SE. When you run MIDP on CDC, you get a virtual CLDC stack underneath,
so there is no guarantee for serialization compatibility with Java SE
(1.4.2) when you run in that mode. Serialization compatibility between
CDC and Java SE is only guaranteed with CDC/PBP, CDC/PP, or CDC/FP (not
CDC/MIDP) applications.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

cjplummer
Offline
Joined: 2006-10-16

>
>
> Did someone test the de-serialization ? I suppose it
> would be the next step for me, or try with another
> VM, but i have some more critical tasks to do first.
>
Serialization is tested regularly as part of the TCK.

> cvm -cp testclasses.zip Test return no error, and the
> only things i see with the DEBUG=true are many
> alignement trap things such as the following, which i
> suppose won't help me much
> Alignment trap: cvm (1007) PC=0x408321a0
> Instr=0xe59e1000 Address=0x4683efaf FSR 0x013

Where is this coming from? cvm doesn't print this message, and I don't see why building with CVM_DEBUG=true would cause it. Note that any traps during execution of JIT'd code will result in a NullPointerException being thrown, which could be converted into some other exception by java code. I'd suggest running with -Xjit:compile=none and see if that changes anything.

Chris

Message was edited by: cjplummer

fpillone
Offline
Joined: 2008-05-27

*last msg sent twice, sry*

Message was edited by: fpillone

cjplummer
Offline
Joined: 2006-10-16

First build with CVM_DEBUG=true. This way if you got USE_AAPCS=true wrong, you will see a runtime assert.

Also, you are building with dual stack support. Is jade a CDC application or a midlet. In either case, please provide the cvm command you used to launch jade.

Chris

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> First build with CVM_DEBUG=true. This way if you got USE_AAPCS=true wrong, you will see a runtime assert.
>
> Also, you are building with dual stack support. Is jade a CDC application or a midlet. In either case, please provide the cvm command you used to launch jade.
>
> Chris
>
>

Hi fpillone,

In addition to trying what Chris suggested above and answering his
question about how you launch JADE, I know some very basic info about
JADE via the Web and believe you cannot use JADE-LEAP Agent mobility on
MIDP:

Here is what is said about JADE by itself:

http://www.iro.umontreal.ca/~dift6802/jade/doc/LEAPUserGuide.pdf
---
Section 1.2 Rationale
...
JADE, unfortunately, cannot run, as it is, on small devices for the
following reasons:
1. The complete JADE runtime environment has a memory footprint of some
Mbytes that cannot fit the (often strong) limitations of handheld devices.
2. JADE requires JDK1.4 (or later) while the majority of handheld
devices only
support PersonalJava or MIDP.
3. Wireless links have different characteristics with respect to fixed
network such as
high latency, low bandwidth, intermittent connectivity and dynamic IP
address
assignment that must be taken into account properly.
The LEAP add-on was created to solve these problems and allows deploying
JADE
agents on handheld devices as described in the followings.

Then also see info about JADE-LEAP:

http://sharon.cselt.it/pipermail/jade-develop/2003q4/003544.html
---
Excerpt:

Dear all,
As mention in the Leap User Guide, Agent mobility and
cloning is not supported in MIDP environment,
...

So, the serialization error message you are seeing may be a result of JADE-LEAP not supporting Agent mobility, only some parts of the JADE kernel.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

fpillone
Offline
Joined: 2008-05-27

Thanks for your help.

I can't recompile for the while. Linux has crashed during some wpa wireless configuration, and now when i try to recompile with no changes, i got this :

The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError
make[2]: *** [/home/phoneme/cdc/build/linux-arm-generic/lib/midpclasses.zip] Erreur 1
make[1]: *** [build_classes] Erreur 2
make: *** [/home/phoneme/cdc/build/linux-arm-generic/lib/midpclasses.zip] Erreur 2

I'll try to reinstall the jdk1.4.2_16 and see if it solves the problem, or see what else to do with this.

Jade is a midlet, i'm using JadeLeap version PersonalJava, not MIDP.

"2. JADE requires JDK1.4 (or later) while the majority of handheld
devices only
support PersonalJava or MIDP."
I'm not using directly Jade, but JadeLeap works not only on JDK1.4, but also on "smaller" devices, with three different version of the .jar, one for JDK, one for PersonalJava and one for MIDP. The MIDP one is the only one that does not support mobility. As i use the Pjava one, i shouldn't have any problem. More over, mobility works perfectly with the same jar file, but on the jdk1.4.2_16. I got the error when the PhoneME VM is used.

I've seen a bug report for Jade that said with a jdk1.5 it worked, but the same bug occures with a jdk1.6. (http://jade.tilab.com, bug ID : 000123, since Jan2007).

fpillone
Offline
Joined: 2008-05-27

a simple make clean solved the system resources problem (java.lang.OutOfMemoryError) even if i don't know why..

After having recompiled with the CVM_DEBUG=true, i still have the same error, with no extra information :

Moving now to location : Main-Container
jade.core.mobility.AgentMobility: Error creating agent on destination container. Abort transfer. A class was not found during de-serialization [nested java.lang.ClassNotFoundException: [Ljava.lang.Object;]

Jade allows me to create java agents (~objects) , and make them move from one computer to another one through serialization, maybe wasn't i clear about that. At present, i am able to send an agent serialized on the PhoneME and deserialized on the jdk1.4.2_16, but the bug occures when the agent is deserialized on the PhoneME.

I used to have a bad configuration in /etc/host, but it was raising another error (host unreachable, DispatcherException...) so i assume both machines can communicate correctly, and i have to look at PhoneME side rather than Jade side.

Did someone test the de-serialization ? I suppose it would be the next step for me, or try with another VM, but i have some more critical tasks to do first.

cvm -cp testclasses.zip Test return no error, and the only things i see with the DEBUG=true are many alignement trap things such as the following, which i suppose won't help me much
Alignment trap: cvm (1007) PC=0x408321a0 Instr=0xe59e1000 Address=0x4683efaf FSR 0x013

Hinkmond Wong

Hi fpillone,

Here's a long-winded answer...

phonemeadvanced@mobileandembedded.org wrote:
> a simple make clean solved the system resources problem (java.lang.OutOfMemoryError) even if i don't know why..
>
> After having recompiled with the CVM_DEBUG=true, i still have the same error, with no extra information :
>
> Moving now to location : Main-Container
> jade.core.mobility.AgentMobility: Error creating agent on destination container. Abort transfer. A class was not found during de-serialization [nested java.lang.ClassNotFoundException: [Ljava.lang.Object;]
>
> Jade allows me to create java agents (~objects) , and make them move from one computer to another one through serialization, maybe wasn't i clear about that. At present, i am able to send an agent serialized on the PhoneME and deserialized on the jdk1.4.2_16, but the bug occures when the agent is deserialized on the PhoneME.
>

This is making more sense now. Thanks for the clarification about which
JADE variation you are using and how you are using it for Agent
Mobility. I see from your explanation about how you can de-serialize
from phoneME to JDK 1.4.2_16, but cannot de-serialize the other way.

> Did someone test the de-serialization ? I suppose it would be the next step for me, or try with another VM, but i have some more critical tasks to do first.
>

Yes, de-serialization does work and has been tested on phoneME Advanced,
but there are of course some requirements for using serialization
between phoneME (Java ME) and Java SE.

When you serialize a Java object, the requirement is that the actual
Java object being serialized must find all it's parent class hierarchy
on the platform where it is being de-serialize.

So, for example, if you serialize an object which is an instance of the
subclass of java.awt.Canvas, when you de-serialize that object it must
find java.awt.Canvas (and in turn the entire parent hierarchy of
java.awt.Canvas and all the other dependencies) on the target platform.
And, it cannot be just a subset of java.awt.Canvas, it must be the same
entire java.awt.Canvas class that was used to serialize the object
(Serialization uses a hash of the methods and fields in the class to
make a unique ID of the required parent hierarchy it must find on the
platform).

In a nutshell, the problem I think you are seeing is that when you
serialize from phoneME to Java SE 1.4.2, it is OK, since the entire
parent class hierarchy of the object you are de-serializing is from
phoneME which is a proper subset of Java SE 1.4.2.

However, the other way around, you are probably serializing a JADE
object that drags in the parent class hierarchy of the Java SE 1.4.2
platform, which is a superset of the phoneME class hierarchy. That's a
problem.

So, for example, the java.lang.Object that the Java SE 1.4.2 serialized
Agent Mobility object depends upon is _not_ the same one that is found
on phoneME.

It could look like this:

java.lang.Object (on Java SE 1.4.2)
{
method A;
method B;
method C;
method D;

field A;
}

java.lang.Object (on phoneME, subset of Java SE 1.4.2)
{
method A;
method B;
}

So, if you serialize an object that is a child of java.lang.Object from
phoneME to Java SE 1.4.2, it's OK, since it will find both method A & B
in the java.lang.Object in Java SE 1.4.2 when you de-serialize.

But, going the other way, if you serialize an object that is a child of
java.lang.Object from Java SE 1.4.2, it is _not_ OK, since it will _not_
find methods C, D, or field A. You will get an exception thrown during
de-serialization.

This is a compatibility problem that is solved in some cases by
hardcoding (defining) a unique UID in some classes to override the
hashing of the methods and fields. For example, you might find a line
like this in some class files:

Throwable.java
---
...
/** use serialVersionUID from JDK 1.0.2 for interoperability */
private static final long serialVersionUID = -3042686055658047285L;

If you don't have the above in a class file, Serialization in Java will
use a hash algorithm of the method and fields to create the UID.

And, that's the clash I think you are seeing.

The solution is not easy. It's up to the JADE software to do the right
thing, like to hardcode a serialVersionUID in the object you are
serializing or to make sure to serialize using the java.lang.Object from
the PersonalJava/phoneME class hierarchy and not from Java SE 1.4.2.

Did you consult the docs for JADE to see if 2-way Agent Mobility should
work? Or, possibly do they only mean that 1-way Agent Mobility should work?

If 2-way should work, maybe there is a special way you have to serialize
when on Java SE 1.4.2 to make sure to serialize with a parent class
hierarchy represented by the subset of the PersonalJava/phoneME
platform. I'm not sure if they used a separate JAR file to represent
that which you would point to during serialization, or if they have some
other trick.

Let me know if you have more info on how JADE 2-way Agent Mobility
should work with PersonalJava, since I'm thinking there may be more to
their instructions when going from Java SE 1.4.2 to phoneME.

Also, are you building MIDP with phoneME? The docs you showed say
PersonalJava (or phoneME Personal Profile) is required for Agent
Mobility, not MIDP, so you shouldn't need themidp component or pcsl at
all. To verify this part, can you send your make command line?

Thanks,

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

fpillone
Offline
Joined: 2008-05-27

Hi,

Thank you for your explanations about serialization, i'm glad having learnt a few things, such as what the "private static final long serialVersionUID = 3487495895819000L;" field is used to.

I've read much documentation about Jade, but i have NEVER seen anything saying i have to take care about the class hierarchy or JVM version for the mobility, except for MIDP. More over, my movable agent extends the Agent class, which contains "private static final long serialVersionUID = 3487495895819000L;", and extends himself directly the object class. If've well understood what you've told me about serialization, the class hierarchy is not a problem.

Moreover, i've once made a mistake, and rather than using the 1.4.2 i was using the 1.6 for a mobility test where i was always staying on the same machine and jvm (i've checked on both consoles with java -version), and the mobility didn't work.

About MIDP and pcsl, a friend has made a script i use to compile the VM. MIDP=true because when i tried with false, the MIDPPkgChecker.class file was not generated and was declared as missing. The file follows, but i've also changed the cdc/build/linux-arm-generic makefile to change "CVM_TARGET_TOOLS_PREFIX=" to "CVM_TARGET_TOOLS_PREFIX?=".

#!/bin/bash
#
# This script assumes the following dir layout:
# 1) the script starts in the directory under whicj there are
# following dirs: cdc, jump, midp, pcsl, tools
#
# 2) these dirs hold the corresponding components, *without* additional
# hierachy. E.g. one can use the following commands to checkout
# current trunks for all components
#
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/cdc/trunk cdc
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/jump/trunk jump
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/midp/trunk midp
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/pcsl/trunk pcsl
# svn checkout https://phoneme.dev.java.net/svn/phoneme/components/tools/trunk tools
#
# The settings one might need to tweak are located at the top of the script
#
# Last updated on mai 2008

# Controls if CDC only (without JUMP) configuration is build (JUMP_BUILD=false) or CDC + JUMP configuration (JUMP_BUILD=true)
JUMP_BUILD=false

# Provide your path to JDK 1.4.2 here
export JDK_HOME=/usr/lib/j2sdk1.4.2_16

# define cross toolchain
export CVM_TARGET_TOOLS_PREFIX=/usr/local/arm/oe/bin/arm-linux-gnueabi-

# Unit tetsing related settings
# Provide your path to JUnit3.8.1 junit.jar (defaults to /usr/share/ant/lib/junit.jar---standard path for, e.g., Synaptic Manager)
export JUNIT_JARFILE=/usr/share/java/junit-3.8.1.1.jar

# Select which graphical porting layer we use
export AWT_IMPLEMENTATION=gunit
#export AWT_IMPLEMENTATION=qt

# if use Qtopia as graphical porting layer
export QT_TARGET_LIB_DIR=/usr/local/qtopiarm/lib
export QT_TARGET_INCLUDE_DIR=/usr/local/qtopiarm/include/
export QTEMBEDDED=false
export QTOPIA=false

# Enable special mode
export CVM_DEBUG=true
export USE_AAPCS=true
export CVM_ARM_HAS_WMMX=true
export CVM_OPTIMIZED=true
export CVM_CLASSLOADING=true
export CVM_SERIALIZATION=true
export CVM_REFLECT=true
export CVM_DYNAMIC_LINKING=true
export CVM_JIT=true
export CVM_JIT_REGISTER_LOCALS=true
#export OPT_PKGS=all

## Stanadard settings: modify them at your own risk
TOP_DIR=`pwd`

export USE_MIDP=true
export CVM_DUAL_STACK=true
export USE_SCRIPT_UTILS=true
export USE_JUMP=$JUMP_BUILD
export J2ME_CLASSLIB=cdc

export JUMP_DIR=$TOP_DIR/jump
export MIDP_DIR=$TOP_DIR/midp
export PCSL_DIR=$TOP_DIR/pcsl
export TOOLS_DIR=$TOP_DIR/tools

# Launch the build
cd cdc/build/linux-arm-generic
make $@
INSTALL_PATH=/home/colibri/rootfs/usr/local/phoneme
sudo cp -R bin $INSTALL_PATH/
sudo cp -R lib $INSTALL_PATH/
sudo cp btclasses.zip $INSTALL_PATH/
sudo cp democlasses.jar $INSTALL_PATH/
sudo cp testclasses.zip $INSTALL_PATH/

...............................EOF

Maybe do you have another target than linux-arm-generic you would recommand to me ? The VM is intended to run on a toradex colibri PXA270, maybe the linx-arm-bulverde would be slightly more suitable, but as I'm not used to cross-compilation and hardware stuff I'm not so sure, and there is also a buldverde"mv"? I'm not sure it would solve my problem though..

Thx and have a good week-end

cjplummer
Offline
Joined: 2006-10-16

> Hi,
>
>
>
> About MIDP and pcsl, a friend has made a script i use
> to compile the VM. MIDP=true because when i tried
> with false, the MIDPPkgChecker.class file was not
> generated and was declared as missing.

Try a clean build. There should be no references to MIDPPkgChecker if you are not building with USE_MIDP=true.

>The file
> follows, but i've also changed the
> cdc/build/linux-arm-generic makefile to change
> "CVM_TARGET_TOOLS_PREFIX=" to
> "CVM_TARGET_TOOLS_PREFIX?=".
>
> #!/bin/bash
> #
> # This script assumes the following dir layout:
> # 1) the script starts in the directory under whicj
> there are
> # following dirs: cdc, jump, midp, pcsl, tools
> #
> # 2) these dirs hold the corresponding components,
> *without* additional
> # hierachy. E.g. one can use the following commands
> to checkout
> # current trunks for all components
> #
> # svn checkout
> https://phoneme.dev.java.net/svn/phoneme/components/cd
> c/trunk cdc
> # svn checkout
> https://phoneme.dev.java.net/svn/phoneme/components/ju
> mp/trunk jump
> # svn checkout
> https://phoneme.dev.java.net/svn/phoneme/components/mi
> dp/trunk midp
> # svn checkout
> https://phoneme.dev.java.net/svn/phoneme/components/pc
> sl/trunk pcsl
> # svn checkout
> https://phoneme.dev.java.net/svn/phoneme/components/to
> ols/trunk tools
> #
> # The settings one might need to tweak are located at
> the top of the script
> #
> # Last updated on mai 2008
>
>
> # Controls if CDC only (without JUMP) configuration
> is build (JUMP_BUILD=false) or CDC + JUMP
> configuration (JUMP_BUILD=true)
> JUMP_BUILD=false
>
> # Provide your path to JDK 1.4.2 here
> export JDK_HOME=/usr/lib/j2sdk1.4.2_16
>
> # define cross toolchain
> export
> CVM_TARGET_TOOLS_PREFIX=/usr/local/arm/oe/bin/arm-linu
> x-gnueabi-
>
> # Unit tetsing related settings
> # Provide your path to JUnit3.8.1 junit.jar (defaults
> to /usr/share/ant/lib/junit.jar---standard path for,
> e.g., Synaptic Manager)
> export
> JUNIT_JARFILE=/usr/share/java/junit-3.8.1.1.jar
>
> # Select which graphical porting layer we use
> export AWT_IMPLEMENTATION=gunit
You are building J2ME_CLASSLIB=cdc below, so this option is having no affect.

> #export AWT_IMPLEMENTATION=qt
>
> # if use Qtopia as graphical porting layer
> export QT_TARGET_LIB_DIR=/usr/local/qtopiarm/lib
> export
> QT_TARGET_INCLUDE_DIR=/usr/local/qtopiarm/include/
> export QTEMBEDDED=false
> export QTOPIA=false
>
> # Enable special mode
> export CVM_DEBUG=true
> export USE_AAPCS=true

> export CVM_ARM_HAS_WMMX=true
Disable WMMX until you have all problems worked out.

> export CVM_OPTIMIZED=true

> export CVM_CLASSLOADING=true
> export CVM_SERIALIZATION=true
> export CVM_REFLECT=true
> export CVM_DYNAMIC_LINKING=true
You shouldn't set any of the above 4. Although you are setting them to there defaults, if you set any of them to false there would be problems, so it's best to just leave them out of your build script.

> export CVM_JIT=true
> export CVM_JIT_REGISTER_LOCALS=true
> #export OPT_PKGS=all
>
> ## Stanadard settings: modify them at your own risk
> TOP_DIR=`pwd`
>
> export USE_MIDP=true
> export CVM_DUAL_STACK=true
> export USE_SCRIPT_UTILS=true
> export USE_JUMP=$JUMP_BUILD
I don't think you want any of these.

> export J2ME_CLASSLIB=cdc
I thought you said that Jade requires PersonalJava. How is is working when you just build cdc?

>
> export JUMP_DIR=$TOP_DIR/jump
> export MIDP_DIR=$TOP_DIR/midp
> export PCSL_DIR=$TOP_DIR/pcsl
> export TOOLS_DIR=$TOP_DIR/tools
>
> # Launch the build
> cd cdc/build/linux-arm-generic
> make $@
> INSTALL_PATH=/home/colibri/rootfs/usr/local/phoneme
> sudo cp -R bin $INSTALL_PATH/
> sudo cp -R lib $INSTALL_PATH/
> sudo cp btclasses.zip $INSTALL_PATH/
> sudo cp democlasses.jar $INSTALL_PATH/
> sudo cp testclasses.zip $INSTALL_PATH/
>
> ...............................EOF
>
> Maybe do you have another target than
> linux-arm-generic you would recommand to me ? The VM
> is intended to run on a toradex colibri PXA270, maybe
> the linx-arm-bulverde would be slightly more
> suitable, but as I'm not used to cross-compilation
> and hardware stuff I'm not so sure, and there is also
> a buldverde"mv"? I'm not sure it would solve my
> problem though..
That bulverde target is appropriate for PXA270, but really all it does is enable the use of WMMX. bulverde-mv is similar, but turns off WMMX because there are issues with using it with MontaVista.

>
> Thx and have a good week-end

Chris