The TrekStor eBook Reader 3.0 (EBR30-a), review and dissection

The TrekStor eBook Reader 3.0, front
The TrekStor eBook Reader 3.0, front on

There a many, many, e-book reader devices available these days, and they're quickly becoming pretty affordable. The currently cheapest device in Germany (that I know of) is the TrekStor eBook Reader 3.0, model number EBR30-a, at 59.- Euros via Weltbild or Hugendubel.

The device has an 800x480 7" TFT (yep, no e-ink), 2100mAh battery, it can display PDFs, EPUB, and TXT files (and Adobe DRM crap, which I don't really care about), it has an accelerometer which allows for landscape/portrait switching, it can play MP3, OGG, WAV, and WMA audio files (headphone jack), it can display pictures (BMP, GIF, JPG, even PNG, though that's not mentioned in the vendor's specs), and it has 2GB internal storage for books/music/pictures. Uploading of (non-DRM) content is done by a simple file copy, it enumerates as a standard USB mass storage device with FAT filesystem. It's a relatively nice reader for the price, I've read a few PDFs (datasheets, presentations) on it in the subway/train while listening to music from the device and it's quite OK for my purposes. So much for the review part.

However, I didn't really buy it for reading books on it, I was more interested in taking it apart, of course ;-) My hope was that it would turn out to be a really cheap device running Linux/U-Boot which would be perfect for playing around with embedded Linux stuff. Unfortunately, I wasn't so lucky (it seems).

The TrekStor eBook Reader 3.0, opened

I've posted a few photos of the device and its hardware components on my flickr account and over at randomprojects.org, together with all the information I was able to find out so far. Here's a quick summary:

  • Main CPU/SoC: FI E200 B6077BA 26P1
  • RAM: MIRA P3S12D40ETP (512MBit / 64MByte DDR SDRAM, max. 200MHz)
  • NAND flash: Samsung K9GAG08U0E (16GBit / 2GByte, x8, 3.3V)
  • Battery management: KrossPower AXP199 A5004AB 36G
  • RTC/clock/calender chip (I2C): H8563S
  • Some accelerometer (to switch between landscape/portait mode), model unclear so far, maybe the chip labeled 605 132?

The TrekStor eBook Reader 3.0, CPU

There are public datasheets for most of the hardware components (see randomprojects.org for links), but unfortunately the most important one (for the CPU) is not yet found/identified. I was told that the CPU/SoC is probably based on an ARM9 (ARM926EJ-S) core and the firmware running on it seems to be some uCos-based RTOS (not Linux, unfortunately).

So far I was not able to find out the vendor name or website of the "FI E200" CPU/SoC (let alone any datasheets), any hints would be highly appreciated. I checked arm.com: Processor Licensees, but the only two companies whose name starts with "F" having licensed an ARM9 core are Fujitsu and Freescale, which doesn't fit, I think?

I could (and probably will) check the PCB for RX/TX lines on an UART and/or JTAG pads (none are obviously labelled), and given that it's and ARM9 core there is a good chance that OpenOCD can be used and that a standard cross-gcc toolchain for ARM will work. However, that is all pretty pointless until it's clear which SoC exactly is used, and thus whether there is already Linux and/or U-Boot support for it and/or whether datasheets are available so that the respective code could be written. Without datasheets, this is going to be a pretty painful experience, not really worth investing much time, IMHO.

If anyone knows more about the vendor/device and respective datasheets, please let me know. Thanks!

Update 2012-04-19: I found the UART TX pin a while ago, a bootlog is available. The CPU and all other chips are also known now: The SoC is an Allwinner Technology F1 E200, the orientation sensor is a MEMSIC MXC6225XU.

Counting pages in multiple PDFs from the command line, using pdfinfo or pdftk

Say you have a bunch of PDFs and you want to know how many pages each of them has. You could of course use some graphical software to display every single PDF and check the page count (xpdf, evince, whatever), but that gets tedious very fast.

So here's (mostly as a reminder for myself) one way to count pages of many PDFs (in the current directory) using pdfinfo from the xpdf-utils package:

$ cat countpdfpages
for f in *.pdf; do
        echo -n "$f: "
        pdfinfo "$f" 2>/dev/null | grep Pages | cut -d ":" -f 2

A sample run:

$ ./countpdfpages
S71147.pdf:           25
S71226.pdf:           38
S71242-01.pdf:        25
S71258.pdf:           26
S71315.pdf:           35
S72045.pdf:           2

I'm sure there are many other ways to do this, e.g. using pdftk foo.pdf dump_data (in the pdftk package), please leave a comment if you know a simpler way to achieve this. Especially so if you don't need an extra script to do it (i.e. if there's a PDF command line tool which can already count pages in multiple PDFs). Thanks!

Faster and more comfortable LaTeX editing and previewing with latexmk

When writing LaTeX documents I usually just edit the plain text in vim, and in another xterm I type make && xpdf foo.pdf to regenerate the PDF output and view it in xpdf. This is tedious and slow if you do it often. A much better way I found out about now, is to use latexmk.

apt-get install latexmk

This tool autogenerates a PDF or PostScript file out of your *.tex file(s), so it would make my Makefile obsolete. But the much better thing is that it has a preview mode:

latexmk -pvc -pdfps foo.tex

This generates a PDF out of foo.tex (and its dependencies, if any), and refreshes the PDF every time the foo.tex file gets updated (i.e., every time I type :w in vim). So I can now leave the xpdf instance open all the time, and it'll be refreshed automatically to show the latest version of my document.

Caveat: in xpdf you have to press (for example) "next page" and then "previous page" (SPACE, BACKSPACE) to refresh the screen. Leaving out the "-pdfps" makes the regeneration process a bit faster and uses xdvi for previewing as dvi (instead of PDF) which does not require the above SPACE+BACKSPACE hack. But I like xpdf better than xdvi, so I'll stick with it.

Manipulating PDFs from the command line - joining, merging, rotating [Update]

One of the single most useful packages when it comes to PDFs in Linux is pdfjam.

From the website:

  • pdfnup, which allows PDF files to be "n-upped" in roughly the way that psnup does for PostScript files.
  • pdfjoin, which concatenates the pages of multiple PDF files together into a single file.
  • pdf90, which rotates the pages of one or more PDF files through 90 degrees (anti-clockwise).

The installation is easy as always: apt-get install pdfjam

PDF is not exactly the most easily editable format out there, but these tools can save you lots of time and trouble. Just recently I needed to merge two PDFs into one (and I didn't have any source format of the files). A simple pdfjoin foo1.pdf foo2.pdf --outfile bar.pdf does the job in a few seconds.

Equally useful when you need to print huge documents is pdfnup --nup 2x2 foo.pdf, which sticks four PDF pages into one (thus drastically reducing the amount of pages you have to print)...

Update 2006-09-20: As was noted by several people, pdftk is very cool, too. It can do some other things such as split PDFs, encrypt/decrypt them, manipulate metadata and more...

22C3: Final Stuff

More Bandwidth

OK, I will make this short because a gazillion of other people will probably blog about the 22C3 for several days or weeks to come... Today (last day) I only attended one talk — Bluetooth Hacking - The State of The Art. Funny stuff you can do with Bluetooth...

All in all it was a great conference. Get the proceedings or browse the list of talks (most of them have PDFs attached) for more details. Videos of all talks should be available anytime soon (I hope!).

Oh, and the 22C3 is probably the only event where you will see such signs (attached to walls by the congress staff!)...

Syndicate content