📜 ⬆️ ⬇️

E-book as a display

Unconventional use of common things - this is something that we are always interested in! After all, sometimes you want to poke the next device. Understand how it works and make some adjustments to its work, adding new features.


Display your pictures

I will tell you how to turn an old Sony PRS-505 reader into a convenient display. And also I will tell you how to write your own programs for this book.
')


Formulation of the problem



For one device, I needed a display to display graphs and experimental data. Data should be displayed infrequently, but it is desirable that the display be low-power, large in size and with good resolution.
My source device runs under Linux and has a USB host. At first I looked towards the Vogue display, but brushed it off due to its small size and resolution. Started looking further.
I have a long time lying around the electronic book PRS-505. I got it and put it in front of me, remembering that there is Linux inside and I heard somewhere that you can reach it through the console. But also understanding that this thing is in itself. Put and forget.

After a while I went hiking with comrade Vshmuk and suddenly saw that he was reading the exact same book. And told him his thoughts. In response, he was ridiculed - as it turned out, the distinguished comrade once wrote an article to Hacker about how to get hardware access to this book, and most importantly, he said that this thing has Framebuffer, like a destkop, and you can even work on it.

Normal people on a hike enjoy nature ...

For those who do not understand in linux, I explain that framebuffer is a file in Linux (like any device in general) that you can (theoretically) stupidly write a memory snapshot file and display it on the screen. You can also make a hardware screenshot, i.e. just dump the video memory by copying this file to another location and view it, copying (more precisely writing to) it back.

Why do you need it:
Why this is needed: For example, on the target machine, there is video output to a virtual screen, with a resolution equal to the resolution of the book (namely, 600x800). Further, periodically, the framebuffer file of the virtual screen is taken and redirected to the com-port, and at that end from the com port, the cat command redirects it to the framebuffer of the book.

I illustrate, all commands are executed on the target machine, the book is connected via UART, via VCP, which hangs on / dev / ttyUSB0. Commands are called every few minutes, for example in the crown.

echo "cat / dev / ttyS0> / dev / fb0"> / dev / ttyUSB0

This command on the UART sends the command to redirect the contents of the COM port file to the framebuffer. Next comes the second command:

cat / dev / fbn> / dev / ttyUSB0

This command transfers the contents of the virtual fbn screen (where is the n-number of the screen) to the COM port. Everything should work fine, the transfer will end when the end-of-file character arrives.


Getting down to business



When we returned from our epic campaign, I sought out his article www.xakep.ru/magazine/xa/129/092/1.asp and went on.

Initially, I disassembled the book and soldered to the debug console using the ft232rl chip to interface the interfaces (see my post “UART and what they eat with” - habrahabr.ru/post/109395 )


Unfolded reader with soldered interface


Back view

Read more about how and to which contacts to get fed, you can read here: www.the-ebook.org/forum/viewtopic.php?p=120092#120092

I do not want to be engaged in citing the article comrade Vshmuk about how to log in, what processes should be killed, etc. It is best to read him in this article. Let me just say: it is empirically established that when a book is connected to the computer via standard USB, no processes need to be killed, everything works and so. As terminalki I use favorite minicom .
After the soldering, I began to study the OS. First of all, I looked at the script, which is mentioned in the article, that it mounts everything and displays the boot image. Let's see what kind of animal it is:

root @ (none): / # cat /etc/rc.d/rcS.d/S20libromount

Of all the forshmak that fell out there, we are most interested in this:

# display booting image /usr/local/sony/bin/nblconfig -dump | head -3 | awk '{print $9}' | grep 02 > /dev/null if [ $? == 0 ]; then # init screen load grep BootImg /proc/mtd > /dev/null if [ $? == 0 ]; then NUM=`grep BootImg /proc/mtd | awk -F: '{print $1}' | awk -Fd '{print$2}'` dd if=/dev/mtd$NUM of=/dev/fb0 bs=256 count=1875 /opt/sony/ebook/bin/writescreen init 0 else /opt/sony/ebook/bin/writescreen init 1 echo no boot image fi else /opt/sony/ebook/bin/writescreen init 1 fi ... 


I decided to try to score a random forcemeat screen, and made just such a command:

root @ (none): / # dd if = / dev / urandom of = / dev / fb0 bs = 256 count = 1875
1875 + 0 records in
1875 + 0 records out
But nothing happened ...

Let's try the following command:

root @ (none): / # / opt / sony / ebook / bin / writescreen init 0
latest nblconfig read from 0x00035000
latest nblconfig written to 0x00035800
And ... the miracle did not happen. Moreover, the team
root @ (none): / # / opt / sony / ebook / bin / writescreen init 1

stupidly extinguishes the screen and everything, after which he no longer showed signs of life.

In general, the problem could not be solved without a hitch. Therefore, I switched to the hardware. He began to think how to make a book for me more carefully, since these snot of thin wires can easily come off. As a result, I brought the debug console through the headphone jack. There, manufacturers right next to the connector provided for null resistors, which I safely removed and hung in there two wires RX and TX, and left the ground from the headphones. She was not galvanically isolated from the number.


Output debug port to audio jack

After I finished the experiments, I decided to try to drive files directly through the console. This is necessary in order not to draw two wires and not to consume a flash drive resource (image recording on a USB flash drive, then playback). I was completely successful in transferring from a book to a computer, but there is already no return.

For the experiment, I tried to transfer the image file. Remember the above I have already talked about the script output boot image? He reads it from the NAND flash drive section of the reader and writes it to the framebuffer:

NUM = `grep BootImg / proc / mtd | awk -F: '{print $ 1}' | awk -Fd '{print $ 2}' `
dd if = / dev / mtd $ NUM of = / dev / fb0 bs = 256 count = 1875
/ opt / sony / ebook / bin / writescreen init 0

The first line defines the section on which the picture lies. Execute this command (which is in single quotes), and find out the section number. In my case, he was equal to nine.

Well, then the second team will be slightly corrected, so that the transfer was conducted to the COM port. Experienced to establish that the console for reception and transmission is the file / dev / tty. We transfer the picture, for this we close the terminal on the computer and execute:

cat / dev / ttyUSB2> bootimg.raw , where ttyUSB2 is my VCP interface based on ft232rl.

Then in another console of the computer we give the command:

echo "dd if = / dev / mtd9 of = / dev / tty bs = 256 count = 1875"> / dev / ttyUSB2 , which sends a command to transfer the image via the console via the console.

Let's transform this picture from a binary image into png:

echo -e "P5 \ n800 600 \ n255 \ n"> result.pgm
cat bootimg.raw >> result.pgm
convert result.pgm result.png

As a result, we get just such a picture. I don’t know why it was so recalibrated, but there were obviously some transmission errors.

image
The resulting picture

By the way, what is a picture that can be recorded in a framebuffer? This is a bitmask, where each byte is equal to the color of the pixel and it weighs exactly 800x600 = 480000 bytes. Therefore, the image that we want to transfer to the frame buffer should be 800x600 and weigh exactly 480000 bytes. In fact, this is the * .pgm-file, only with the header cut off.
I could not transfer the file back. Apparently because the console is a standard input device, and it does not like non-printing characters. You can read more about these experiments here: dlinyj.livejournal.com/608961.html .

Understanding that I haven’t succeeded with the program yet, I decided to remove the book in the case, since now nothing prevented me from doing this.

After examining the system and scripts, it became clear that it was impossible to display an image using console tools. I was told that one comrade had already solved this problem and even described it in his blog systemsand.me/sony-prs-300prs-505-hack . In short, the program will have to write, although it will be very simple.

I downloaded the toolchain (speaking simpler compiler for the build, although this is not quite accurate) from here www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition after a bit of registration with the log, I rolled it on your favorite ubuntu. And tried to collect hello word

For reference, he was going to the command arm-none-linux-gnueabi-gcc -mcpu = arm920t hello.c -o hello

The most important thing was how to transfer the file to the book. I noticed that when the USB is connected, a certain disk with a volume of about 200 meters appears on the computer. But in the system on the book it is not.

I have all the firmware of knikzhi, and I realized that the hard disk is used in the book application (I mean what the device is intended for). This file cramfs.Fsk.img
I mounted this image on my computer and looked at the sony / ebook / bin / tinyhttp.sh script. How to do it is again described in the article in Hacker. Trolo pysch pyshch, no one reads. This is the same script that we choke at the very beginning to get the console, according to the article Vshmuk. And there was this line:

NUM = `grep Data / proc / mtd | awk -F: '{print $ 1}' | awk -Fd '{print $ 2}' `
/ usr / local / sony / bin / mkdosfs / dev / mtdblock $ NUM

Again, the first line gets the device number. Having executed the first script (what is in quotation mark), I got the number seventeen, and then mounted / dev / mtdblock17 on / tmp / t1. I can not explain how I understood that this is exactly what will be a flash drive, but the logic simply suggested that it was in this file that the initialization of user data should go.

And as a result, I saw the contents of the disk, which I see on my computer.

And I decided to try running it:

root @ (none): / tmp / t1 # ls
Digital Editions autorun.inf database hello tmp
root @ (none): / tmp / t1 # cp hello / tmp /
root @ (none): / tmp / t1 # cd ...
root @ (none): / tmp # ls
hello t1
root @ (none): / tmp # ./hello
bash: ./hello: No such file or directory
root @ (none): / tmp # chmod + x hello
root @ (none): / tmp # ./hello
bash: ./hello: No such file or directory

Smart people suggested that the necessary libraries might be missing there, and they were advised to compile with the -static option. After that, everything got worse

root @ (none): / tmp # ./hello
Segmentation fault

It became clear that we should look for a compiler. Thanks to the help of many people, I learned that openinkpot.org/wiki is cutting through this book! And therefore the tulchan should be.

I started to google with the search for "prs-505 toolchain" it was found here code.google.com/p/prs-plus/downloads/detail?name=arm-toolchain-sony-300.tar.gz&can=4&q= . After that, the Hello Word started without problems (even without static!). Well, then the matter of technology, according to systemsand.me/sony-prs-300prs-505-hack sketched a small program

 /* showpic.c */ #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <string.h> #define FBIO_EINK_GET_TEMPERATURE 0x46A1 //Returns temperature in degree Celsius #define FBIO_EINK_DISP_PIC 0x46A2 //Displays picture int main (int argc, char* argv[]) { printf ("Show image\n"); int *fb, *image; int pio_fd = open ( "/dev/fb0", O_RDWR); int f_image = open ( argv[1], O_RDWR); //open file into arg int t= ioctl (pio_fd, FBIO_EINK_GET_TEMPERATURE, NULL); //configure framebuffer fb= mmap(0, 800*600, PROT_WRITE, MAP_SHARED, pio_fd, 0); //map device into memory image= mmap(0, 800*600, PROT_READ, MAP_SHARED, f_image, 0); //load image into memory memcpy(fb,image,800*600); ioctl (pio_fd, FBIO_EINK_DISP_PIC, 0); close(pio_fd); close(f_image); return 0; } 


Defains took from the drauver code from the Sony website www.sony.net/Products/Linux/Audio/PRS-505.html file 8track20070714.tgz

Compiled by a primitive team with a minimum of options: path to toolchain / arm-unknown-linux-gnu-gcc -static showpic.c -o showpic

Without statics did not want to work.

Now in gimp we create a picture with a resolution of 800x600, draw what we want and save as habrahabr.pgm.


My art

You will forgive my art. I was lazy to try hard.

Then open it in any hex editor and delete the entire title before FF


Remove header

Fill the hard disk of the book. We climb into the console and execute:

root @ (none): / # cd tmp /
root @ (none): / tmp # mkdir t1
root @ (none): / tmp # mount / dev / mtdblock17 t1
root @ (none): / tmp # cd t1 /
root @ (none): / tmp / t1 # ls
Digital Editions autorun.inf habrahabr.raw showpic
a.out database send.raw tmp
root @ (none): / tmp / t1 # ./showpic habrahabr.raw
Show image
root @ (none): / tmp / t1 #

And we see:


Farshmak

Oh! We did not turn this picture. Rotate the original image in gimp by 90 degrees and repeat the procedure. As a result, our eyes will appear


Q.E.D!

Results



I managed to write my own program for a book and even display pictures. I must say that the goal is to display gnuplot charts. This package is perfectly able to generate the pgm files itself, and it remains only to use the dd command to cut off the header.


Sample graphics

The main problem that is not solved now is how to transfer graph files to a booklet. I wanted to do this right on the debug console, but for this you need to be able to wean it to be a console and turn it into a regular UART. How to do this, I do not know. Even more, I think to do it on the fly.
I am told that it is possible to assemble a driver so that the device is seen as a COM port via USB, but it seems to me that this could result in one more hemorrhoids. I think you can try to create a folder on a flash drive, and in it mount a virtual temporary file system in RAM. I have not tried this method yet. But transferring a file via a flash drive is an absurd and unreasonable decision.
In general, the question remains open and I am ready to hear all the reasonable suggestions about this.

Thanks


Thanks to all the people who have helped and are helping me in this strange project. I hope they will be even more

References:


1. An initial article in Hacker www.xakep.ru/magazine/xa/129/092/1.asp from where I started my experiment.
2. Instruction for book subscription www.the-ebook.org/forum/viewtopic.php?p=120092 # 120092
3. A similar problem was solved by our compatriot so systemsand.me/sony-prs-300prs-505-hack unfortunately, he could not help me with the source code and toolchain.
4. Source texts of the firmware of the book and drivers www.sony.net/Products/Linux/Audio/PRS-505.html
5.Open draft openinkpot.org/wiki
6. Working tool code.google.com/p/prs-plus/downloads/detail?name=arm-toolchain-sony-300.tar.gz&can=4&q=
7. About my torment with a book, you can read in my dzhj dlinyj.livejournal.com/tag/prs-505

PS I am not a very competent person, I will be very grateful for personal messages with blots to make the article look more worthy.
PPSTak the same remarks in fact I will accept with pleasure. I'm not a cool software developer for Linux, although I would love to become one :).

Remember the best thanks to the author for the post - this is a comment left!

UPD While asleep figured out how to solve the problem with text input and console. Nothing prevents the file from transmitting in text form. It is necessary to rewrite the file a bit so that it receives data from kinsoli, and transfer two commands to it:
start - the beginning of the transfer and stop - the end. Then read the transmitted file on the source computer by byte and split the byte into nibla (half byte). Nibl takes a value from 0 to 15 or in HEX from 0 to F. Well, transfer the character from zero to F. On the side of the book, do the inverse conversion of text nibbles to bytes. The beginning of the transfer means start, the end of the stop. We control the transmission on the console echo.
It will take twice as long, but the solution is the simplest and most obvious.
Ran to write a program!
UPD-UPD After 5 years, wrote a program that turns the book into a clock. Github code github.com/dlinyj/sony_prs-505_clock

Source: https://habr.com/ru/post/274831/


All Articles