HD3 dev

[random42]

Hi, searched around fairly comprehensively and could not find the info I was looking for. Apologies if my searching was subpar. Have gone through the thread "PB6xx/7xx/8xx: root + sshd..." associated source code and walked the dependency tree on GitHub.

Looking for some info about PB HD3 wrt development:

• what's CPU and architecture , ARM-7 ?
• is there a particular version of Linux that it runs ? I've seen mention of busybox being installed on top of it which is cool, but would love to get more *nix services like crontab (esp if it could wake up the device).
• what/why are the compiler flags what they are? Reverse engineering what I see in various repos is not leading to much understanding on my part.
• most SDKs that I see reference to contain compiled binaries for the compilers themselves, do we know what was used to bootstrap those?
• are there resources I am missing that could help me understand such things?
• Am I correct in that QT is the UI framework that these devices use?
• have I chosen the wrong device?

I'm interested in developing some applications for the device, ideally by cross compiling in a language that is a little nicer (personal opinion) to use like Rust or Go.

If I'm successful, would be happy to put together a how-to guide on GitHub.

> About me

I'm a professional software developer of over 15 years and I consider myself pretty good. At this point my experience is much higher in the stack: C#, Java, Groovy, Python, Ruby, Javascript, GoLang, Rust, Bash. CS degree was heavy on C/C++ but it was a lifetime ago. I have only dabbled in embedded development with things like Particle IoT and rPI.

[rkomar]

I guess it depends on what you want to do with these programs. If you want to display stuff on the screen and interact with it via the buttons and touch screen, then you are probably going to have to build in a layer of code that interfaces with libinkview. The latter is the API that the devices use, and that is provided to programmers in PocketBook's SDK. You might look at koreader as an example of a program that is written in another language (LUA), and that interfaces with libinkview.

It is the "requirement" of using libinkview that makes it hard to test applications off the device. There was an emulation library built for Windows over 10 years ago, but it is rudimentary and hasn't kept up with the changes to libinkview. The only way to seriously test new applications is to run them on the devices themselves.

That said, the OS on the devices is a pretty standard linux distribution. For stuff that doesn't use the screen and buttons, you can generally copy programs from the debian lenny armel distro onto the device and run them there. You may have to copy over missing libraries, too. That may provide a lot of what you need to do your development.

[Marco77]

SDK-A13 # A13-based devices (626, 627, 641, 840)
SDK-B288 # B288-based (632, 740)
SDK-iMX6 # 631
(thanks)

PocketBook Touch HD3 has codename 632.
PocketBook InkPad 3 Pro has codename 740-2 IIRC, same SoC as 740.
B288 is sun8iw10 by manufacturer Allwinner.

cat /proc/version to get the cross compiler, e.g. Linux version 3.10.65 (jenkins@bsp-builder) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #2 SMP Fri Mar 29 11:59:01 EET 2019. See /proc/config.gz for kernel compilation env

In each of the SDK_6.3.0/SDK-* directories, there's a config.cmake file with flags, dunno if it's what you need?
SET (GENERAL_FLAGS "-mcpu=cortex-a8 -march=armv7-a -mfpu=neon -mfloat-abi=softfp")

It targets an ARMv7 ISA with soft floating point and uses the GNU EABI (Linux, not the bare metal ARM one), therefore a lot of compiled binaries work out of the box.

The reader app for epub and PDF relies on closed-source ReaderLib (libpbrdlib.so). It is cross-compiled using clang and uses libraries such as Qt, SQLite 3, DjVu and probably others. This dynamic module relies on libadobe_rmsdk.so for DRM and libinkview.so for interacting with the device (for IPC, etc.).
AFAICT, it is a custom-made renderer and sadly cannot be patched for QML stylesheet rules like Kobo eReader (or provide a better alternative).

OTOH, eink-reader.app which is the main GUI relies heavily on Qt and should be customizable with enough research.
e.g. binwalk --dd='gzip:gz:gunzip %e' -C _outdir ebrmain-cramfs/bin/eink-reader.app

see https://github.com/dennwc/inkview for a Go implementation of SDK, it may help with porting stuff in pure Rust

[random42]

Great information, thank you! If I get something working that is useful I will be sure to share.

[ezdiy]

A bit of caution: Pocketbook SDK is a messy voodoo magic.

The official SDK is https://github.com/pocketbook-free and probably https://github.com/pocketbook

However those are somewhat incomplete, meaning it won't allow you to link to a lot of stuff that's actually on the device, plus it attempts to do some horrible things like depend on local system version of headers, which breaks spectacularly unless you have a peculiar distro the sdk snapshot was taken from.


So you'll eventually end up hacking up the SDK to get running anyway - https://github.com/blchinezu/pocketbook-sdk or https://github.com/ezdiy/pocketbook-sdk5

It's not pretty.

The cross compiler binaries are not all that interesting on their own, and indeed you can bootstrap your own gcc from scratch (just configure all paths relative into the forest of hacked up SDK .h/.so/.a files). It's just something incredibly tedious, for little benefit. The reason for that is things like libgcc version - you can't just run a modern gcc in there, as the PB libraries you're forced to use link to old runtimes new gcc won't run with.

Whenever you can, just avoid the SDK, and run a clean toolchain of your choice and static link. Usually you'll want https://github.com/bootlin/toolchains-builder or buildroot. Those are modern, have clean build scripts and all that good stuff. But you won't be able to co call inkview with it. It's for pure side linux stuff (ie what my rooting tools mostly are about anyway).

All Pocketbook CPUs are standard Cortex-A7 targets, there's nothing out of ordinary.

Regarding "nicer" stuff. If you want gui, I've often found myself just scripting koreader in lua to conjure various kludges. That's because you just edit the script on device via samba mount, and live-refresh in app. Shortens testing cycles considerably.