PocketBook 2.0.x development

[LoneTech]

I grew impatient with the lack of an SDK for my 903. I'm sure quite a few of you have noticed that the new models - 602, 603, 902 and 903 - do not accept programs built for earlier models. The root cause appears to be a change of ABIs; the 15.1 SDK expects a /lib/ld-linux.so.2 loader but the one in the 903 is .so.3. That's probably because of a switch to EABI. So I installed an EABI system in a qemu emulator, shoved in some headers from the old SDK and libraries from the 903, tweaked a makefile.. and managed to build a program! You'll find poterm runnable for the 903 at my machine, as well as the emulator system image in which it was built - probably usable to build other things as well. Don't forget poterm.ini if you try poterm out!

[paola]

Lonetech, thanks a zillion... though I can only make out a slight outline in the fog of my ignorance meaning that you have cracked a way to get some close relative of the original SDK (software developer kit?) up and ranning.

So trying to understand a bit, do I get it right that you have reproduced on a "virtual" machine (QEMU) a software that adds to the SDK of other models the additional things (libraries) that are specific to the 903? And that this would now allow other programmes to run on the PB903 (both old ones and new developments)?

By the way, when you say "the new models ... do not accept programs built for earlier models" which programmes running on the other pb do you have in mind (sorry, I am a total newby!)?

For other users who are absolute beginenrs like me, here is what I found:
"QEMU is a generic and open source machine emulator and virtualizer.
When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.
But for those tech-unsavy of us, what does this mean in practice?


Poterm is PoTerm is serial terminal shell talks to serial ports and it is capable of sending AT commands to modems. A serial communication library is also available. Works on Windows and Linux also

and for ABI/EABI

In computer software, an application binary interface (ABI) describes the low-level interface between an application (or any type of) program and the operating system or another application.

ABIs cover details such as data type, size, and alignment; the calling convention, which controls how functions' arguments are passed and return values retrieved; the system call numbers and how an application should make system calls to the operating system; and in the case of a complete operating system ABI, the binary format of object files, program libraries and so on. A complete ABI, such as the Intel Binary Compatibility Standard (iBCS),[1] allows a program from one operating system supporting that ABI to run without modifications on any other such system, provided that necessary shared libraries are present, and similar prerequisites are fulfilled.

Other ABIs standardize details such as the C++ name mangling,[2] exception propagation,[3] and calling convention between compilers on the same platform, but do not require cross-platform compatibility.

An ABI should not be confused with an application programming interface (API) which defines a library of routines to call, data structures to manipulate, and/or object classes to use in the construction of an application using that particular (often language specific) API.

An embedded-application binary interface (EABI) specifies standard conventions for file formats, data types, register usage, stack frame organization, and function parameter passing of an embedded software program.

Compilers that support the EABI create object code that is compatible with code generated by other such compilers, thus allowing developers to link libraries generated with one compiler with object code generated with a different compiler. Developers writing their own assembly language code may also use the EABI to interface with assembly generated by a compliant compiler.

The main differences of an EABI with respect to an ABI for general purpose operating systems are that privileged instructions are allowed in application code, dynamic linking is not required (sometimes it is completely disallowed), and a more compact stack frame organization is used to save memory.

[LoneTech]

Pretty much, yes.

The new models (AFAIK, 602, 603, 902, 903) have switched ABIs, which are a fundamental part of how the operating system fits together, to ARM EABI. That alone meant they can't run programs compiled for earlier firmwares. I handled this by making my virtual machine (emulated with qemu) use the same ARM EABI as the 903.

I use qemu to emulate the ARM processor family the PocketBook uses, so that my development platform itself need not use a cross compiler. This makes it easier, but slower, to build libraries and such. On the plus side, qemu is portable, and this allows development on non-x86 machines. The downside is that the e-ink emulation library in the SDK was for x86, and thus does not run in my qemu environment.

The idea was to use qemu to create a virtual computer similar enough to the PocketBook that programs could be copied from one to the other. This since I can easily install development tools in the virtual computer, but not quite so easily in the PocketBook.

The poterm in this case is Pocketbook terminal. I'm not sure if it is related to the serial terminal program poterm; it was found in the pocketbook-free collection of programs for the pocketbook readers. I chose it because it may be useful, was easy to build, and was missing from the presupplied extra programs in my 903.

Later on I will probably achieve customizations (such as pdfviewer with pen panning) or ports (such as Simon Tatham's puzzles or Xournal).

[paola]

thanks for the explanation, the thick fog is turning into mist

Originally Posted by LoneTech

Later on I will probably achieve customizations (such as pdfviewer with pen panning) or ports (such as Simon Tatham's puzzles or Xournal).

Porting Xournal would earn you a marble statue!

[rkomar]

@LoneTech: I'm having trouble with the fsimage.qcow2.bz2 file (393834464 bytes) that I downloaded twice from the site above. Uncompressing it produces the error message: "bunzip2: Compressed file ends unexpectedly;", and produces a file of size 1093720000 bytes. If I run bzip2recover on the compressed file first, and then do the uncompression, I get a file of size 1093724272 bytes. There are no error messages, but I'm not confident that the whole file is there. Unfortunately, I can't see what the exact size of the compressed and uncompressed files should be from the website, as they are only shown in "human-readable" form (i.e 376M and 1.1G). Would you provide the md5sum for the fsimage.qcow2 so that I can check to see if my version is okay?

Edit: Nevermind. I went ahead and tried it under qemu and couldn't boot because of filesystem errors. I'll download the uncompressed version later today.

[LoneTech]

md5sums and sizes for the files in my laptop:
07f4ea73e9f05bae1d8f58e7eeb85f3d fsimage.qcow2 1270480896
1841bc6d8e5a0e4228ce9d2affba7566 fsimage.qcow2.bz2 402667416
My uncompressed copy may be modified since the compression, but the compressed one is intact (bzip2 -t doesn't complain) and should be as the one on the server. At the moment I'm not at home and find it hard to reach the server to verify.

Edit: I can confirm that the .bz2 is incomplete on the server. I'll try to correct it.

It should be fixed now. Sorry about the trouble. A resume of the file ought to work.

md5sum and size for the uncompressed image on the server, should be what was compressed:
98b7b1561cad59a47c9c92e175a1e049 fsimage.qcow2 1129447424

By the way, a reasonable port of Xournal will take a while. The gtk-directfb on the pocketbook appears not to support pen strokes, only taps, so I'd have to implement a separate tslib input layer or something, as well as build gnomecanvas. I do expect to try.

[rkomar]

Originally Posted by LoneTech

Edit: I can confirm that the .bz2 is incomplete on the server. I'll try to correct it.

It should be fixed now. Sorry about the trouble. A resume of the file ought to work.

Thanks! I'll try again in a few hours (bandwidth priority goes to streaming the Canada/Russia WJHC gold medal game right now ).

Edit: Got it, and it boots fine.

[atango]

Thanks LoneTech I installed your poterm in my 902 and it works great. It has warning

/bin/ash: can't access tty; job control turned off

but it works fine. Only if I can use bluetooth keyboard, I may do more interesting things.

BTW, it need DEL key to rotate the screen (G sensor doesn't work), but there is no DEL key in 902pro. Is there way to change the hotkey?

It will be nice if new PB can use already developed applications for PB360 like FBreader180 or hacked Adobe viewer.

[LoneTech]

Modified AdobeViewer is probably a no go, because adobeviewer is setuid (sreader). It appears all protected stuff is under that account, including text to speech and dictionary.

As for Del, I'm not even sure what device had such a button. It's certainly possible to rebuild poterm to use some other button. The tty message is probably from poterm using pipes rather than pseudottys, which would take a bit more work to fix. I haven't adapted poterm, just built it unmodified.

FBreader180 is probably a matter of just building, though I am not sure if it can access the dictionaries then. There's also a risk it needs some work for the accelerometer, if they changed the API for that.

Worst case scenario, the inkview library has had incompatible structure changes (it has happened before, with the settings interface), and this build system will be crippled compared to the (as yet unavailable) SDK.

[atango]

PB will release SDK for new PB machines before March. It looks like GrayNM will build FBReader for PB90x when SDK is published. Let's hope for better.


https://www.mobileread.com/forums/sho...=65865&page=16

[atango]

I downloaded image files from @LoneTech and manage to work with it.

This is my first time to work with qemu and I struggled a bit with segmentation fault. In Ubuntu 10.10, it is necessary to add '-m 256' option.

So to change hotkey of poterm, just change line 90 of poterm.cpp

case KEY_DELETE -> case KEY_MENU

and in file "Term.cpp" change the line 427

"DEL: Rotate" to "MENU: Rotate"

with this I can rotate the poterm with Menu key.

[LoneTech]

Well done! I've uploaded a compiled version of poterm with this change on my server.

[reader42]

Originally Posted by LoneTech

The tty message is probably from poterm using pipes rather than pseudottys, which would take a bit more work to fix.

It uses pipes because you would need root privileges for the pseudottys...

Btw. do you mean with gtk-directfb for pocketbook? Is this only on the new devices or on the PB302 as well?

[LoneTech]

I reckon the older devices will be getting a firmware update to this EABI based system as well. I haven't examined the older firmwares, but the SDK didn't include any Gtk support; it came as a surprise to me when I first fired up the web browser. I've since tried building a bunch of gtk programs (Tatham's puzzle collection) but they're not initializing correctly. Considering the midori executable links directly to inkview, there's probably some little raindance that needs to be done in initialization. Perhaps an ltrace could shed a little light on it.

[paola]

Originally Posted by LoneTech

By the way, a reasonable port of Xournal will take a while. The gtk-directfb on the pocketbook appears not to support pen strokes, only taps, so I'd have to implement a separate tslib input layer or something, as well as build gnomecanvas. I do expect to try.

Hi Lonetech, bearing in mind that I am computer illiterate and probably missing a lot: but I noticed that when reading (both epub and pdfs) in PB903, you can turn pages with a swipe of the stylus, and of course you can write free-hand in scribble: don't these things amount to the software being able to recognise penstrokes?