Just a very short notice (bed calls). It seems that its possible to run python on the pocketbook 903: http://www.mobileread.com/forums/showpost.php?p=1879701&postcount=1.

The nice thing: it seems that exactly the same binaries work on onyx boox as well. I just copied the files mentioned in the other thread onto the boox m92, and did a symlink from /mnt/ext1/applications into that python directory.


root@onyx /mnt/ext1/applications$ ln -s /media/flash/python .
root@onyx /mnt/ext1/applications$ cd python
root@onyx /media/flash/python$ echo "print 1+2" > test.py

root@onyx /media/flash/python$ ./bin/python test.py

3


(the testserver is missing a libz.so.1 on the boox, but I am quite optimistic that this can be easily fixed, given the open source nature of the m92.

For me this is really exiting - it would allow lots of existing python code (for e.g. epub or pdf handling) to be run, maybe with an web-interface run off a local webserver. ...easy cross platform development....web servers .... n900.... sweet dreams for me tonight :-)

jbaach:

This is quite interesting, and indeed opens many possibilities. I think the M92 could become the perfect mobile reading device if the community gets behind it. Do you know what sort of video server the M92 uses? I haven't really taken too much of a look at the git-hub sources.

A bit off topic, but I would also love to try to get nfs working on the M92 (which I just ordered, mostly because of you!).


Thanks,
Ryan

Python!? That is fantastic. I am not programmer but in IT and somehow familiar with programming so here is my question, would it run Qt? I would love to have Anki (http://ankisrs.net/)running on it!!!!

What about a calibre client to communicate with the pc version? :)

I have to ask though, how fast will such programs work on an 800mhz ARM processor?

I think you will have to approach the Calibre's programmers for that.
Anki is running fine on Nook. Anki (Ankidroid) in written in Python.
Not sure if the Nook processor is much more powerfull then M92's.

What about PyQt support?

This looks rather promising: https://bitbucket.org/dboddie/pyqt4-for-embedded-linux/overview But it contains not only PyQt, but the whole package of Qt, Python, SIP and PyQt...

Today, I had a closer look at cross-compiling PyQt. And everything I can tell at the moment is: It's a horror. Compiling Python 2.7.3 is really easy considering this Howto: http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html

But PyQt is so incompatible to cross-compiling. No native parameters for HOST or TARGET and BUILD. And just scan through all those patches here: https://bitbucket.org/dboddie/pyqt4-for-embedded-linux/overview Unfortunately some of them are not fitting the latest version of PyQt, so you will have to check out each one yourself... that's not exactly fun.

I can't believe, cross-compiling PyQt is so damn hard. Isn't Qt about cross-platform compatibility etc? So if somebody runs into a solution to this problem, I would really love to see it...

EDIT:
On M92 we have version 4.7.3 of Qt. Unfortunately that's not compatible with the most recent version of PyQt (4.9.1). So it'd be cool to know where to get older versions of PyQt, 4.8.X preferably...

I don't know what the OS on the Onyx devices looks like, but maybe you can avoid cross-compiling by building within an emulated ARM linux environment. For my PocketBook, I can use a Debian lenny armel system under qemu to build software that isn't set up for cross-compilation. Maybe you can do the same, or even use the newer Debian sid/squeeze armel system instead.

That's a nice idea. But don't we have to use the exact same Qt (4.7.3) and gcc (4.4.4) versions to build new software for our M92? If I simply set up a VM with armel debian and the Qt and gcc from the repos, won't I run into problems?

It depends on the versions of the dynamic libraries. In general, the libraries are backwards compatible for the same major version number. So, if the libraries are slightly newer on the device, the programs will still run. They won't load if they have a different major version number, or if the minor version number is smaller than what the program was built against. So, if the emulated system has QT4, but a version older than 4.7.3, then you're probably okay. If the emulated system has QT3, or a version above 4.7.3, then it won't work.

If worse comes to worst, you can start with a slightly older emulated system, and update the libraries there
that are giving trouble. It's still probably less mental effort than trying to cross-compile a package that isn't prepared for such work.

Well I set up a debian squeeze armel system on qemu-system-arm. But it's performance is terrible. It has a maximum of 256 MB of RAM (versatile board). That's rediculous. It's unbelievably slow and you can't honestly build something like PyQt on such a machine?! Is it even possible to get more RAM on any arm vm today?

Well I set up a debian squeeze armel system on qemu-system-arm. But it's performance is terrible. It has a maximum of 256 MB of RAM (versatile board). That's rediculous. It's unbelievably slow and you can't honestly build something like PyQt on such a machine?! Is it even possible to get more RAM on any arm vm today?

It's true that it's slow, but you only have to do it once, and you don't have to be around while it's building. As far as the RAM goes, that seems to be a limitation of qemu and the verstatilepb board. Maybe you can build another system based on a realview-pb-a8 or realview-pbx-a9 board and get 512 MB (maybe even 1024 MB), but that seems like more work and time than just waiting for your current system to finish.

You don't seem to have an idea of _how_ slow it really is. At the moment I'm trying to build qt embedded (with Q_WS_QWS) to prevent problems that occur when building pyside with Q_WS_X11, which is the version that comes with debian's qt4-x11.

At the moment "configure" is running. I started it half an hour ago! The actual build process might take a whole day or even longer...

Everything different from the versatile board seems to be rather hard to set up at the moment. No tutorials on the net that fit a noob like me...

You don't seem to have an idea of _how_ slow it really is. At the moment I'm trying to build qt embedded (with Q_WS_QWS) to prevent problems that occur when building pyside with Q_WS_X11, which is the version that comes with debian's qt4-x11.

At the moment "configure" is running. I started it half an hour ago! The actual build process might take a whole day or even longer...

Everything different from the versatile board seems to be rather hard to set up at the moment. No tutorials on the net that fit a noob like me...

I built ghostscript this way, so I _do_ have some idea of the speed. However, I almost cried in frustration when I saw what people were doing to get that software cross-compiled. Building in qemu may have been slow, but it took no effort after the development tools were added, and it finally just worked. I just went off and did something else in the meantime. The real question is, can you produce a faster system and build your software before the slow system does, and is it worth the effort if you only use it rarely? In my case, the answer was no.

I built ghostscript this way, so I _do_ have some idea of the speed. However, I almost cried in frustration when I saw what people were doing to get that software cross-compiled. Building in qemu may have been slow, but it took no effort after the development tools were added, and it finally just worked. I just went off and did something else in the meantime. The real question is, can you produce a faster system and build your software before the slow system does, and is it worth the effort if you only use it rarely? In my case, the answer was no.

One could always try and debootstrap on a SDCard to directly use the M92 (this way you'd only need chroot ported to the M92)
CPU emulation indeed is painfully slow...

P.S.: The busybox binary already supports chroot ;)

simply because I saw it mentioned above (though I'm a bit puzzled as to why someone would want to run a web server on an Ebook-Reader):
jbaach: you're aware that busybox includes a basic http server applet? (though it's not enabled in the M92 binary, it'd probably be trivial to do so...)
also telnet/telnetd, if you need that for developing... (hmm... that makes me wonder whether I should build a new busybox binary...)

Just to let you know: I had my armel debian running in qemu for more than 24 hours building qt4. It took like 15 hours for the qtwebkit alone, so I broke up, because there was no chance that this would come to an end within a reasonable period of time...
I think I'll give up on the whole qemu approach. It was interesting to play around with qemu and debian for the first time in my life. But this setup will not serve my purposes.

My next approach will be scratchbox2. I'm gonna setup x86 debian inside of VirtualBox and use a chroot-like scratchbox environment to cross compile with the official freescale arm-linux-gcc etc. This looks really promising. Maybe I can even use the qt sdk provided by onyx inside the scratchbox and thus avoid rebuilding qt4.

In the meantime, I found out that we won't be able to build pyside with onyx' qt sdk, because it depends on QtXmlPatterns. I don't know yet whether PyQt will run without it. At least, PySide can be built with an embedded qt version at all. (PyQt has huge problems when built without X11.) So maybe I will end up recompiling Qt 4.7.3 embedded, but with QtXmlPatterns.

EDIT: There is one thing that I learned from using the debian armel stuff: Everything (especially all the binaries) that's released for debian armel runs on our M92 - at least concerning the architecture. The only reason why we can't just start using the debian armel deb files is that they heavily rely on lots of shared libraries we lack (and thus would have to pack on our M92's memory). But maybe the time will come when this compatibility turns out useful ;)

EDIT: There is one thing that I learned from using the debian armel stuff: Everything (especially all the binaries) that's released for debian armel runs on our M92 - at least concerning the architecture. The only reason why we can't just start using the debian armel deb files is that they heavily rely on lots of shared libraries we lack (and thus would have to pack on our M92's memory). But maybe the time will come when this compatibility turns out useful ;)

I almost suspected it... but doesn't that make the chroot approach the next best step in your quest?

Today I tried setting up scratchbox2 according to this HowTo: http://biffengineering.com/wiki/index.php?title=HowToSetupCrossCompileEnvironment
It was not really hard to configure. But python wouldn't compile after that due to strange reasons (segmentaion fault...). Furthermore I didn't have apt-get in my debootstrap rootfs and couldn't figure out what had gone wrong...

After that, I tried scratchbox (ver 1) and was not able to find a tutorial about adding our freescale toolchain to the compilers. all tutorials about scratchbox 1 are extremely old (2005) and not complete at all. Really frustrating. I think I will stop here. No energy left to put any more effort into this whole thing.

EDIT: Just to add some information what exactly went wrong with scratchbox2: The debootstrap must be run first with fakeroot and --foreign and after that a second time inside of sb2 -eR and with option --second-stage. But the second run will always fail, because scratchbox doesn't remap the /dev directory and debootstrap will try to mknod inside of /dev - of course without success due to missing permissions.
I actually gave up on this completely. But I asked for help in the scratchbox-users mailinglist. Maybe they know what to do.

simply because I saw it mentioned above (though I'm a bit puzzled as to why someone would want to run a web server on an Ebook-Reader):
jbaach: you're aware that busybox includes a basic http server applet? (though it's not enabled in the M92 binary, it'd probably be trivial to do so...)
also telnet/telnetd, if you need that for developing... (hmm... that makes me wonder whether I should build a new busybox binary...)

In the end I did (if for no other reason than adding 'watch' support ;) ).
If someone has use for it: attached.

Added features: see readme. (Most important to me: watch and some shell alternatives) Did not check whether all added features work (e.g., some lack kernel support)

Cheers!