PRS-500 Compiling for the Reader

[alex_d]

Ok, so now we can run anything we want on the Reader, and it's easy. Yay!

Now... how would we go about compiling for it?

Building an a cross-compiler isn't too hard, but maybe someone's already done the deed? (I'm still pissed off why a linux cross-compiler has to be "built." Why can't compilers just compile whatever you want them to? Microsoft's VC++ doesn't care if it outputs x86, x86-64, or even Itanium.)

Also, where do I find all the headers (which specify framebuffer ioctls, for example)?

[sic]

hey Alex,

maybe I missed something...
I saw posts that describe how to modify the Reader's file system, but I wouldn't say we have an easy way to run our own apps.
Please let me know if you know otherwise!

[igorsk]

Originally Posted by alex_d

Also, where do I find all the headers (which specify framebuffer ioctls, for example)?

Check libro_fb sources here:
http://www.sony.net/Products/Linux/
You can also most probably just recompile programs that were released for Librie.
sic,
inspect the shell scripts that come with the flasher.

[alex_d]

thanks a lot! I found a crosscompiler tutorial for the Reader here:
http://www.the-ebook.org/forum/viewt...?p=64904#64904

also a nice tutorial for framebuffer programming here:
http://web.archive.org/web/200512230...rent/x267.html

the framebuffer driver for the reader is very clearly written. frankly, i'm surprised sony even posted the sources. one great find is that eInk has built-in functionality to do auto-refresh. You just call a few ioctls, and now eink doesn't fade! This was really bothering me quite a bit.



OK, now... how do i capture input??

I've found this:
http://www.sven.de/librie/Librie/SoftWare

But the damn link is broken!

[igorsk]

Check http://www.public.asu.edu/~ajennin/librie.html
Basically, you need to read /dev/ttyDB0

[alex_d]

"Basically, you need to read /dev/ttyDB0"

It seems to be a lot more complicated than that. /dev/ttyDB0 is apparently not a terminal for getting keystrokes but an interface to an auxiliary microcontroller or some sort of driver. From this interface one can read various messages, including those coding keystrokes.

What simplereader does is read all the messages, ACk all the messages, and then filter out the keys. This might hinder the other functions of the Reader. The link I posted in my previous post talks about this, but I'm not sure its solution of ignoring messages it doesn't understand will do anything (they'll get sent again, but who's going to read them if i hog ttyDB0?).


The real problem, however, is that I don't know thr codes. Simplereader defines the Keydown message type and the letter keys of the Librie (which was qwerty). Big help. I don't know the keyup message (but ok, i prob don't need it), much less the codes for all the buttons on the Reader. Perhaps I can just figure it out the hard way by reading messages and pressing buttons. But maybe there's a reference?

Another problem is that the mechanism inherently requires polling, which'll either destroy the battery or destroy the responsiveness. Surely that's not how the reader's native software does things?

p.s. how did the person who wrote simplereader figure out how to interact with ttyDB0? Is there Sony source code somewhere? Plain brute force?

[igorsk]

I couldn't find any description of the command in kernel sources. Reader's implementation of keyboard handling is in ebook.so, you could try disassembling that.

[alex_d]

"Reader's implementation of keyboard handling is in ebook.so, you could try disassembling that."
sigh.

ok, so I guess i'll have to find out the key codes just by pressing buttons. i guess it won't be _that hard (easier than reading ARM disassembly!). do you know if i can open a text console and simply do printf? or do i have to interface through the framebuffer?

but the polling... the damn polling...

[HarryT]

Is polling really going to affect the battery life? Experiments appear to have shown that the Reader's power consumption is pretty constant regardless of whether the machine is on or "off". The CPU never seems to go into its low-power "standby" state.

[alex_d]

harry, think about what happens when you play mp3s. using the cpu definately will affect power consumption, and constant polling is pretty taxing.

however, on second thought, i think polling every 10 ms or so won't affect the battery much and will also give perfect responsiveness.

then after 10 minutes of inactivity i'll...

no, wait, what will i do? it probably will not turn itself off like it normally does since i'm stealing all the messages. either that, or it'll turn itself off all the time because i'm stealing all the messages...

Hopefully it won't turn itself off, and I think I can just cut down the polling to be even more infrequent and put the screen into standby (there's an ioctl for that). Hopefully you're right, and my slow-polling method will yield the same two weeks of battery.

But I really wonder what i'll be affecting by messing with /dev/ttyDB0. Am I going to have to take over everything, including the power button? Even battery status supposedly gets conveyed over ttyDB0 so I might have to do that too (which is good, seeing as it doesn't work now!). But I'm not sure how i'd decode the messages for things like that.

The only thing I pray for is that the reset button doesn't use ttyDB0 ;-)

[HarryT]

Is there no way of processing the messages that interest you, and passing the others on to whatever would have processed them had your code not been there?

[alex_d]

I don't know. I think when you read them off of ttyDB0 they're gone. If you don't send an ACK, however, they should get sent again. If someone else is reading the device as well, then maybe that agent will read half the messages and things will eventually be processed. But then if that daemon is reading half the messages, it might swallow up the key presses AND ack them so that I never receive half the input.

I don't know, it's all theoretics at this point and i have to try all of this in hardware.

[alex_d]

Ok, I'm up and running and got framebuffer access working.

Having done some benchmarks, I can continuously refresh at 2bit without black/white transitions in under 0.7s per screen. Not too bad. I think with prefetching the next page into the screen I can get latency down even more (but i'm not sure how to measure this empirically).

However, I can't for the life of me get 1b mode working. I can switch into it, but the memory layout is bizarre and I can't display anything. This sucks, because I was really hoping for some killer refresh rates using 1b mode. If no one here knows anything about it, maybe i'll email the guy who wrote simplereader.

also, the auto-refresh doesn't seem to work. sony probably disabled it. that's too bad, but it's ok. I can just do the refreshes manually.

ok, next step is to render some text and list the files and folders on the sd card.

[alex_d]

Ok, how about some easy questions that I think igorsk can answer:

How much free disk space does the Reader have for my programs? The freetype library alone, for example, is almost two megs.

On a related note, can I run programs from or store libraries on the SD card? If yes, will bad crashes happen if the SD card is removed?

How much free memory does the Reader have for program code and heap?

[igorsk]

Originally Posted by alex_d

How much free disk space does the Reader have for my programs? The freetype library alone, for example, is almost two megs.
On a related note, can I run programs from or store libraries on the SD card? If yes, will bad crashes happen if the SD card is removed?
How much free memory does the Reader have for program code and heap?

Free space depends on which partition you want to use. /Data has approximately 96 megs, minus all the books you have stored. /opt is 7MB compressed, but it's read-only meaning you need to reflash to add files to it. /opt0 has 3 megs, and /tmp is a 4MB ramdisk (gone after reboot).
You can run programs from the card if you mount it first.
Memory infro from dmesg:

Memory: 64MB = 64MB total
Memory: 62676KB available (1391K code, 321K data, 80K init)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)