buglabs / bug-osgi Goto Github PK
View Code? Open in Web Editor NEWRoot project for BUG OSGi Bundles
Root project for BUG OSGi Bundles
While finishing up the on-BUG JUnit testing bundle for the LCD module, I noticed that while the setBackLight(int val) method was correctly setting the back light to the desired value, it was returning 1 ('Operation not Permitted') rather than 0. On a similar note, the javadoc at http://darner:8085/job/bug-osgi/javadoc/ suggests that the back light values range from 0-7 when, as far as I can see, they range from 0-100.
My code:
http://pastebin.com/u4VcDC9z
I have a test that prints out a set number of bytes from the getInputStream method in the INMEARawFeed interface. In my 2.1 testing, this would printout the raw NMEA data. For 3.0, It does not appear to print out anything. Again, this may be a problem with me porting my test suite over to 3.0.
Pastes:
Code: http://pastebin.com/RjvLsVWt
Wasn't sure whether to throws this in the Dragonfly repo or here.
Currently, when attempting to connect to a BUG running rootfs 3.0 from Dragonfly 3.0, the sdk claims it cannot connect. Creating a manual connection to the BUG and appending port 8080 onto the end of the address solves this problem. jconolly mentioned something about how the port should be 80 rather than 8080 in addition to Dragonfly defaulting to the correct port so one does not need to create the manual connection.
Again, not sure whether this should be in Dragonfly repo or here.
Right now, if you are to create an app in Dragonfly 3.0 and send it to a BUG containing the 3.0 rootfs, the following error pops up.
"The BUG Application 'Test' has been built for a different Execution Environment than is running on BUG 'barberdt30bug'. Please set the Execution Environment in your application's manifest to match one of: JavaSE-1.6,J2SE-1.5,J2SE-1.4,J2SE-1.3,OSGi/Minimum-1.2,OSGi/Minimum-1.1,OSGi/Minimum-1.0"
Looking at the manifest for the app being sent, I don't see any current implementation of 'Execution Environment' variable, but I may just be missing something simple.
Note: This relates to a separate issue, in which I was sending the app in the first place to see where it was placed within the rootfs. With the new rootfs, I am unsure where 'apps' are supposed to be located. I see the 'build-in' apps, such as the appui and networkingui in the bundle directory, but is this where all apps are to be located (versus the separate 'apps' and 'bundles' directories of the previous rootfs)?
I am noticing that the bundles that I have loaded into /usr/share/osgi/bundle are not being started when Felix starts. Some of the bundles that are loaded stock on the rootfs are also experiencing the same behavior. This isn't much of a problem for my tests since I would actually prefer to start my bundles manually (from the appui) so I can choose what modules are tested at any given time, but I would suspect this is not the desired behavior.
p.s. The bundles are being loaded correctly, just not started.
On OSGi start:
01.13 14:33:22 ERROR Bundle/Modlet error occurred: java.lang.IllegalArgumentException, Invalid sysfs directory: /sys/devices/platform/i2c_omap.3/i2c-3/3-0070/i2c-5/5-0017 [34]com.buglabs.bug.bmi (3.0.0)
01.13 14:33:22 ERROR java.lang.IllegalArgumentException: Invalid sysfs directory: /sys/devices/platform/i2c_omap.3/i2c-3/3-0070/i2c-5/5-0017
at com.buglabs.bug.sysfs.SysfsNode.(SysfsNode.java:25)
at com.buglabs.bug.module.lcd.ML8953Device.(ML8953Device.java:29)
at com.buglabs.bug.module.lcd.ML8953Device.getInstance(ML8953Device.java:56)
at com.buglabs.bug.module.lcd.ML8953AccelerometerImplementation.(ML8953AccelerometerImplementation.java:22)
at com.buglabs.bug.module.lcd.pub.LCDModlet.start(LCDModlet.java:80)
at com.buglabs.bug.bmi.BMIModuleEventHandler.handleEvent(BMIModuleEventHandler.java:112)
at com.buglabs.bug.bmi.Activator.coldPlug(Activator.java:163)
at com.buglabs.bug.bmi.Activator.frameworkEvent(Activator.java:369)
at org.apache.felix.framework.util.EventDispatcher.invokeFrameworkListenerCallback(Unknown Source)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Unknown Source)
at org.apache.felix.framework.util.EventDispatcher.run(Unknown Source)
at org.apache.felix.framework.util.EventDispatcher.access$000(Unknown Source)
at org.apache.felix.framework.util.EventDispatcher$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:636)
[34]com.buglabs.bug.bmi (3.0.0)
On the BUG, the closest path that exists is: /sys/devices/platform/i2c_omap.3/i2c-3/3-0070/i2c-5/
cat /etc/buildinfo
BUG Linux Build Information
Version: 3.0.1003110016
Build Host: Linux darner 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC 2011 x86_64 GNU/Linux
Build User: root
Build Time: Mon Oct 3 04:16:22 UTC 2011
Revision: 84b43f8
This sounds like it should be expected, but as connector has shown us, if there isn't a nice way to handle this exception, everything that relies on the fix breaks.
Will work on a repro with pastes soon. Just wanted to get the issue up before I forgot.
Rootfs: 3.0 Build #14
After being connected to the office network for a while, the connection will drop and ifconfig will show a connected wlan0 interface with a bogus IP (not 192.168....). Restarting connman will not fix the issue. So far the only fix I have come up with is to reboot the machine. When it comes back up will will connect with a proper IP and the drop will occur again randomly. @mgrundy believes this is DHCP related and may have to do with expired leases not being handled properly. Either way, he mentioned that it may be a bug in the rootfs, so I thought I would create an issue for it. Let me know what other information I can provide.
Edit: The BUG that is currently experiencing these problems is at hostname officeswarm2 and IP 192.168.0.215 (when it has a correct IP of course).
After running the automated camera module tests and digging through the printout, it looks like there is a bug with the ICamera2ModuleControl interface. All of the get methods are returning -1 values. Additionally, all of the set methods are also returning -1 for their IOCTL returns. The other camera module interfaces seem to be working correctly. This may be a bug on my end since I am just porting my test suite over to 3.0 for the first time. Let me know if you think that's the case.
-Davis
Pastes:
Example Code: http://pastebin.com/BGZtvWB6
Example Printout: http://pastebin.com/97hRvR8q
-Still trying to work out the formatting on my tests' printouts. This printout shows the returns for the last 'get' method and then the printouts for each of the 'set' methods followed by their errors/failures
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.