PRS-500 lbhook.sh support patch

[igorsk]

igorsk 1 - cramfs 0
Read the provided readme.txt for instructions.
Here's a sample script:

#! /bin/bash

PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sony/bin:/usr/sbin"
LD_LIBRARY_PATH="/opt/sony/ebook/application:/lib:/usr/lib:/usr/local/sony/lib:/opt/sony/ebook/lib"
export PATH LD_LIBRARY_PATH

pstree -a -c -l >/tmp/pstree.log &

and its output (retrieved with "ebook.py get /tmp/pstree.log"):

init) 
  |-getty) console 
  |-(jffs2_gcd_mtd15)
  |-(jffs2_gcd_mtd16)
  |-(keventd)
  |-lbhook.sh) /tmp/lbhook.sh 
  |   `-pstree) -a -c -l 
  |-(msbdrv_thread)
  |-(mtdblockd)
  |-(sdbdrv_thread)
  `-tinyhttp.sh) /opt/sony/ebook/bin/tinyhttp.sh 
      `-tinyhttp)

[gseryakov]

Originally Posted by igorsk

igorsk 1 - cramfs 0
Read the provided readme.txt for instructions.

This is the breakthrough! Just a couple of questions to clarify.

Originally Posted by readme.txt

1. dump the current Rootfs:
>ebook.py get /dev/mtd13 0x863000
...
5. upload new Rootfs:
>ebook.py pwrite "Rootfs" Rootfs.new

So Reader lets you read the flash partitions by addresses and write by names? Is there any way to read them by names?

What is the difference between cramfs from Reader and Librie? I mean - after mounting the cramfs-es.

[arivero]

Originally Posted by gseryakov

So Reader lets you read the flash partitions by addresses and write by names?

Amazed of this. I was afraid that you were going to need to dd it, and of course you can not dd if you can not to run scripts. But straight access to the partition is a bless! Moreover tiu need it, because a file by file extract is not able to recover ln files, /dev things and all these "minor" issues.

Today 01:51 PM

Did you got to sleep, igorsk ?

What is the difference between cramfs from Reader and Librie? I mean - after mounting the cramfs-es.

Judging from the filesystem dumps, the architecture of the aplication has changed, but it seems that the Operating System is the same. Meaning that perhaps the communication trick (console access via usb) could work straight from librie to reader without modification, and perhaps even the display utilities to upload jpg from scripts. Next steps are, in random order:

a) try for console access via USB.
b) try to show a picture in the display using command line utilities.
c) try my command line utilities for DJVU files.
d) review how to compile Andrew's "simple reader", of if it works straighforward.
e) if not console access, create a "SMS-phone" way to enter text to show it in the console. Note that the netpbm utilities, a lot of them, are included in the djvu package, and this includes some text display utility, I believe to remember.

[Slava]

Originally Posted by arivero

... Next steps are, in random order:

a) try for console access via USB.
b) try to show a picture in the display using command line utilities.
c) try my command line utilities for DJVU files.
d) review how to compile Andrew's "simple reader", of if it works straighforward.
e) if not console access, create a "SMS-phone" way to enter text to show it in the console.

Next step will be to copy Russian fonts to /opt/....

Originally Posted by igorsk

igorsk 1 - cramfs 0

Excellent

[gseryakov]

Originally Posted by Slava

Next step will be to copy Russian fonts to /opt/....

Yeah! It was a Russian party from the beginning, because the Reader hack is of terrible need for Russians to drink^Wsmoke^Wread Russian books!

[Slava]

Igor,

I wonder if it's possible to create softlinks for directories under /opt tree to updatable filesystem like /Data? It will make updating fonts and graphics much easier.

[NatCh]

igorsk, You Da Man! You Da Man!

[igorsk]

Originally Posted by gseryakov

So Reader lets you read the flash partitions by addresses and write by names? Is there any way to read them by names?

Download /proc/mtd to see mapping between device numbers and partitions. Then you can use "ebook.py pinfo" command to get the partition info (there ain't much). You can also execute "/usr/local/sony/bin/nblsdm list" with redirection via the script hook.

Originally Posted by gseryakov

What is the difference between cramfs from Reader and Librie? I mean - after mounting the cramfs-es.

You can always extract both and compare From what I've seen, they're almost the same - Reader has an extra SD driver but that's about it. The main difference is the reading application.

Originally Posted by gseryakov

I wonder if it's possible to create softlinks for directories under /opt tree to updatable filesystem like /Data? It will make updating fonts and graphics much easier.

Probably the same trick as with /etc would work, i.e. copy files to ramdisk and remount under a subdir. However, currently the hook script runs after tinyhttp so I'm not sure if the updated fonts will be loaded.

[igorsk]

For the brave, here's modified cramfs tools from Cygwin which I used to extract and reassemble the cramfs image. To make sure you get the same permissions in your new filesystem, use a devtable file (-d in cramfsk and -D in mkcramfs).
A few things to know to minimize a chance to brick your device:
1) Linux0 and Rootfs2 are kernel and root fs used in the recovery (update) mode. It's best not to touch them.
2) USB control is handled by switcher.so (loaded by tinyhttp) in normal mode, and by /opt0/UsbUpdater in recovery mode. So, disabling any of them will leave you without a way to control the unit via USB.
3) Using USB interface, in normal mode you cannot write flash partitions and in recovery mode you cannot read and write files.

[arivero]

Originally Posted by igorsk

However, currently the hook script runs after tinyhttp so I'm not sure if the updated fonts will be loaded.

It can kill tinyhttp and relaunch it, in any case.

[TadW]

Originally Posted by igorsk

igorsk 1 - cramfs 0

You rock, igor!

[porkupan]

Igor,
Just wondering, why are you dumping 0x863000 bytes of Rootfs while the actual size of the filesystem is supposed to be 0x980000? Did you try dumping the whole 0x980000 bytes?

[igorsk]

The partition size is 0x980000. However, the actual size used by the cramfs image is 0x863000. You can check it yourself, it's specified in the second dword of the image.

[porkupan]

Thank you, igorsk!

[NatCh]

Y'all did it! Excellent!