26 (edited by dafunktyfunk 2010-12-29 14:47:53)

Re: OpenEmbedded for Silvermoon devices

Duane wrote:

The device already runs Linux, and for small programs, it's pretty easy to compile and run them on the device itself - just SSH into the device and type "gcc", and it will install the toolchain.

You can also run Linux on your Windows computer using a virtual machine.

THanks!

Now I need to figure out how to SSH into this.

This is what I am trying to load on the InfoCenter 8" device: ftp://ftp.homeseer.com/updates/Beta/Lin … 0_0_56.zip

I am still very much learning.... Forgive me for being trivial...

BTW, this is a free client software.

Re: OpenEmbedded for Silvermoon devices

Its not going to work by just downloading the HStouch executable. For that app to work you will also need mono to be installed on the infocast.


dafunktyfunk wrote:
Duane wrote:

The device already runs Linux, and for small programs, it's pretty easy to compile and run them on the device itself - just SSH into the device and type "gcc", and it will install the toolchain.

You can also run Linux on your Windows computer using a virtual machine.

THanks!

Now I need to figure out how to SSH into this.

This is what I am trying to load on the InfoCenter 8" device: ftp://ftp.homeseer.com/updates/Beta/Lin … 0_0_56.zip

I am still very much learning.... Forgive me for being trivial...

BTW, this is a free client software.

28 (edited by dafunktyfunk 2010-12-29 16:04:00)

Re: OpenEmbedded for Silvermoon devices

DANGIT! I was hoping you would NOT tell me that! LOL

Do you think this will run Mono and do you think this project will work?

Re: OpenEmbedded for Silvermoon devices

I have tried compiling Mono for the Infocast. There is a receipe for the Mono 2.6.3 in the openembedded environment that I have created. however, it fails almost at the last step with the following error:

ERROR: Function do_install failed

Log data follows:
| /home/rs/oe/output/work/armv5te-angstrom-linux-gnueabi/mono-2.6.3-r0.0/image
| /home/rs
| NOTE: make DESTDIR=/home/rs/oe/output/work/armv5te-angstrom-linux-gnueabi/mono-2.6.3-r0.0/image install
| make: *** No rule to make target `install'.  Stop.
| FATAL: oe_runmake failed
| ERROR: Function do_install failed
NOTE: package mono-2.6.3-r0.0: task do_install: Failed


I have been able to create images flash to the sd card and boot with it  but no success with Mono. Any ideas or suggestions?
Thanks
RS

Re: OpenEmbedded for Silvermoon devices

Yes, all indications are Mono should run on it, how is the big question! I have been experimenting and running into some problems. Maybe do a native compile of Mono on the infocast might be the way to go. Am going to try it.

dafunktyfunk wrote:

DANGIT! I was hoping you would NOT tell me that! LOL

Do you think this will run Mono and do you think this project will work?

Re: OpenEmbedded for Silvermoon devices

YOU ROCK!!

Thank you very much!

Re: OpenEmbedded for Silvermoon devices

Hi, I have an image with ts_calibrate now. After I loaded it, it only registered 0 0 for all coordinates, and failed by saying "determinant is too small". This is with matchbox. I seem to remember with OPIE that the touchscreen wasn't stuck, but reversed. Why would it be broken only in matchbox?

33 (edited by violetdream 2010-12-30 16:13:12)

Re: OpenEmbedded for Silvermoon devices

I'm a little confused about something - the recipes in the Chumby folder, are they automatically added? I say this because Wireless is acting strange. I have a wifi0 device, but nothing shows up on scan, and trying to do things through console causes strange results (like it wouldn't take set frequency?) I tried to modprobe the device I saw in the chumby source folders but it said it couldn't see that module. Is it in there but named something else? Do I have to manually add the network, sound, etc etc recipes? I assumed they were already added to have the machine work.

One more thing: Has anyone gotten a different WM working? I tried for a long time to get Openbox and LXDE to play nicely, but that didn't work, and the XFCE image still doesn't build for me.

And another thing: I know you were working with python so maybe you figured this out - installing just "python-core" seems to leave out several libraries, like glob.py and its dependencies, uuid...etc. Are these in a package I don't know about? As far as I know these are standard python libraries.

Re: OpenEmbedded for Silvermoon devices

I'm getting errors with XFCE as well. I'm gonna start a new thread to see if someone can help us figure out what's going on.

Re: OpenEmbedded for Silvermoon devices

Bump...

How is the cooking on this new platform going?

Re: OpenEmbedded for Silvermoon devices

I've kept running into issues w/ XFCE and OpenBox + LXDE and decided to take a break. I found an LXDE task in Angstrom so I'll probably just wait and see if that builds properly on its own in the near future.

Re: OpenEmbedded for Silvermoon devices

Oh ok...

So, so far no go, eh?

38

Re: OpenEmbedded for Silvermoon devices

Trying to get my first oe image built.  Followed the steps from this thread closely but I run into a parsing error when using bitbake:

user@ubuntu1010desktop:~/oe$ bitbake opie-image
NOTE: Handling BitBake files: - (0003/7113) [ 0 %]NOTE: <class 'bb.MalformedUrl'>:${CHUMBY_SVN_HOST}/firmware/gst_pxa168-1.0/trunk;proto=https;module=src while evaluating:
${@patch_deps(d)}
ERROR: ${CHUMBY_SVN_HOST}/firmware/gst_pxa168-1.0/trunk;proto=https;module=src while parsing /home/user/oe/chumby/recipes/gst-plugins/gst-plugins-marvell_svn.bb
NOTE: Handling BitBake files: - (7113/7113) [100 %]
NOTE: Parsing finished. 6333 cached, 430 parsed, 349 skipped, 0 masked.
ERROR: Parsing errors found, exiting...

Seems like i have a dumb environment error.  Any suggestions?

Re: OpenEmbedded for Silvermoon devices

This thread got me curious, so I went to the OpenEmbedded website and did a little reading.  It didn't really explain why this particular Linux flavor was better than another.

For example, in another thread I read about Debian Lenny with X working on the Chumby.  I guess I'm wondering why would this be better?

Re: OpenEmbedded for Silvermoon devices

@box: Whoops.  gst-plugins-marvell_svn.bb shouldn't have been included.  It's from an early attempt at building a complete root filesystem that's identical to the one shipped on units.  I don't know why it's included, but you can just remove recipes/gst-plugins and get it working.

@dafunktyfunk: Initial support for Falconwing is in OE trunk, but it's not that great.  It's an older kernel, and the mechanism used to build the boot image leaves much to be desired.  Part of the problem is that the bootloader seems to have trouble reading from the SD card.  Curious.

@Martin_H: OpenEmbedded seems more suited for embedded devices.  I've not read the Lenny build process, but I'm not quite sure what sort of image it generates.  OE spits out a bootable image, generally tuned for smaller working environments.  It also makes cross-compiling really easy.  Perhaps Debian / scratchbox has something similar.

41

Re: OpenEmbedded for Silvermoon devices

Thanks chumbylurker.  I removed the files and re-ran bitbake.  now I´m running into an error:

user@ubuntu1010desktop:~/oe$ bitbake console-image
NOTE: Handling BitBake files: - (7112/7112) [100 %]
NOTE: Parsing finished. 6333 cached, 430 parsed, 349 skipped, 0 masked.
NOTE: build Angstrom ${DISTRO_VERSION}: started
Traceback (most recent call last):
  File "/usr/bin/bitbake", line 143, in <module>
    main()
  File "/usr/bin/bitbake", line 140, in main
    cooker.cook()
  File "/usr/lib/pymodules/python2.6/bb/cooker.py", line 639, in cook
    return self.buildTargets(pkgs_to_build)
  File "/usr/lib/pymodules/python2.6/bb/cooker.py", line 526, in buildTargets
    bb.event.fire(bb.event.BuildStarted(buildname, targets, self.configuration.event_data))
  File "/usr/lib/pymodules/python2.6/bb/event.py", line 67, in fire
    if tmpHandler(event) == Handled:
  File "tmpHandler(e)", line 10, in tmpHandler
  File "/usr/lib/pymodules/python2.6/bb/__init__.py", line 100, in plain
    bb.msg.warn(''.join(args))
TypeError: warn() takes at least 2 arguments (1 given)

Any ideas?  Thanks in advance!

Re: OpenEmbedded for Silvermoon devices

box wrote:

Thanks chumbylurker.  I removed the files and re-ran bitbake.  now I´m running into an error:

http://forum.chumby.com/viewtopic.php?id=5904

Updating Bitbake will hopefully fix it.

Re: OpenEmbedded for Silvermoon devices

Has anyone got the wireless driver working on this device? The standard driver doesn't scan and tried to use the drivers from original infocast and load them with modprobe -f.

This created a mlan0 which looked promising but still the same problem,  i also tried to use the libertas stuff in the openembedded recipies but that doesn't even create an wifi adapter sad

Re: OpenEmbedded for Silvermoon devices

mlan0 is promising.  Try changing the region code.  I believe it's something like "iwpriv mlan0 setregion 16".  There's a udev rule in the Infocast software that performs this upon insertion, but obviously that doesn't happen if you're manually inserting the device.  I think it defaults to something like Japan.

45 (edited by xRmg 2011-01-17 06:31:43)

Re: OpenEmbedded for Silvermoon devices

ChumbyLurker wrote:

mlan0 is promising.  Try changing the region code.  I believe it's something like "iwpriv mlan0 setregion 16".  There's a udev rule in the Infocast software that performs this upon insertion, but obviously that doesn't happen if you're manually inserting the device.  I think it defaults to something like Japan.


Well it scans now,

What i did was copy the wireless drivers from the original image to the opie image  ( the stuff in /lib/firmware/mrvl and sd8xxx.ko )

modprob -f sd8xxx

This loads the driver ( you have to force it because of the versioning magic )

then you will get a mlan0 interface

iwpriv mlan0 setregioncode 0x10

this forces it to American region ( works in the eu also wink )
And then it will scan and find networks.

Im going back to the old driver and try the setregion trick and see if it works there ^^


-


Edit:

The same trick works with the driver that is default if you generate a clean image, i havent had any luck yet to connect to a wireless network but that are wpa supplicant errors i think

edit2*

its ofcourse

iwpriv wlan0 setregioncode 0x10

Connected to an open network and started the dhcp client

udhcpc -i wlan0

Got connected, so wireless is working now wink

Re: OpenEmbedded for Silvermoon devices

Got a system where almost everything works now big_smile

if you load the touchscreen in scaled mode it works correctly

like:
modprobe silvermoon-tsb scaled_touchscreen=1

Re: OpenEmbedded for Silvermoon devices

Getting closer and closer??!!?!

Very excited!

Re: OpenEmbedded for Silvermoon devices

zdw wrote:


FYI for those with Ubuntu 10.04 (and probably later), bitbake is apt-gettable.

Ubuntu 10.04 folks should probably not use the apt-gettable version. It's version 1.8.18-2 and you want 1.10.2.

Re: OpenEmbedded for Silvermoon devices

@dafunktyfunk: Initial support for Falconwing is in OE trunk, but it's not that great.  It's an older kernel, and the mechanism used to build the boot image leaves much to be desired.  Part of the problem is that the bootloader seems to have trouble reading from the SD card.  Curious.

I'd be really interested in getting OE going for a CHB.  Do the problems require specialized tools and knowledge, or is it possible for mere mortals to contribute?

Re: OpenEmbedded for Silvermoon devices

I've been able to build bootable (OPIE and X11) images with bitbake in an Ubuntu 10.04 virtual machine following the wiki instructions plus some hints from this thread.  Now I'm am stuck.

The machine boots fine to the first screen but the the touch screen driver is turned on by default (as expected).   The Apple LAN dongle works out of the box so I can figure out the IP address from my router logs and then ssh into the box with the root user id.

I plugged in a keyboard for both the OPIE and X11 builds.  The keyboard works for the X11 build so I can create the initial user with password and I can fire up a terminal window to start the touch screen interface.  The keyboard doesn't seem to work under OPIE until you get off the welcome screen so the touch screen becomes more critical at least on the first go-around.

I had mixed results starting the touch screen:

  • silvermoon-tsb scaled_touchscreen=1" and "/sbin/ts_calibrate" work under X11

  • silvermoon-tsb scaled_touchscreen=1" is all out of scale under OPIE, thinkng it's on some kind of bigger screen where the cursor moves twice as fast as your finger. /sbin/ts_calibrate wasn't installed so that would require some kind of manual packaging.

I guess the silvermoon-tsb would have to be added to an rc script to have it work on startup...




I let the smoke out of my serial console cable so I won't have one of those for a couple more days to figure out if the serial console works.