PRS-500 Reader internals

[porkupan]

Well, I also tried a little experiment.

1) Tried adding a TTF font to the C:\Program Files\Sony\CONNECT Reader\Data\fonts directory and changing the kconfig.xml. This didn't seem to make any difference, as if the CONNECT app's use of the fonts was not really based on the XML config, but predefined in the code.

2) Added Cyrillic support to tt0011m_.ttf using FontForge (copied the Cyrillic characters from Times New Roman, AutoHint'ed and AutoInstr'ed). Once I copied the changed font to the CONNECT Reader directory, the CONNECT PC program was able to support the Cyrillic.

3) Tried to upload the new font to the ebook, using ebook.py (after backing it up, of course ). Well, this didn't work. I suspect, the directory /opt/sony/ebook/FONT may not be writable by the "user", represented in the Readed's runtime by the USB Upload helper. So, perhaps we can write into the /tmp directory, but not into the /opt/sony/ebook.... At least not yet.

If you are interested, here is the message I got back when trying to overwrite the font:
C:\Program Files\Sony\CONNECT Reader\Data\bin>ebook.py put tt0011m_.ttf /opt/sony/ebook/FONT/tt0011m_.ttf
Sony Reader utility 0.2 (c) 2006 Igor Skochinsky
Uploading tt0011m_.ttf as /opt/sony/ebook/FONT/tt0011m_.ttf
Traceback (most recent call last):
File "C:\Program Files\Sony\CONNECT Reader\Data\bin\ebook.py", line 430, in <module>
upload(b, localfile, remotefile)
File "C:\Program Files\Sony\CONNECT Reader\Data\bin\ebook.py", line 386, in upload
f.write(file(local,"rb").read())
File "C:\Program Files\Sony\CONNECT Reader\Data\bin\ebook.py", line 140, in write
raise os.error, "Error writing %d bytes to file '%s'"%(slen, filename)
NameError: global name 'filename' is not defined

[Slava]

Originally Posted by porkupan

Well, I also tried a little experiment.
2) Added Cyrillic support to tt0011m_.ttf using FontForge (copied the Cyrillic characters from Times New Roman, AutoHint'ed and AutoInstr'ed). Once I copied the changed font to the CONNECT Reader directory, the CONNECT PC program was able to support the Cyrillic.

that's interesting

[porkupan]

Originally Posted by Slava

that's interesting

You can try it yourself. Here is the new font:
http://files.ebook.googlepages.com/Dutch801BT-Roman.ttf
Just overwrite the tt0011m_.ttf with this font, and see what happens (you can of course use BookDesigner to generate Cyrillic LRFs).

I never really had any doubts that it would be easy to "cyrillize" the CONNECT PC thing. The question is, how do you copy the same font into the Reader.

[igorsk]

Thanks for the info porkupan! I'll see what I can do about the problem

[Slava]

Originally Posted by porkupan

You can try it yourself.

It's working, thank you

Originally Posted by igorsk

Thanks for the info porkupan! I'll see what I can do about the problem

Yes, please-please-please

[igorsk]

Okay, so I did some investigation (mostly consisting of reading S20libromount script ) and here's the summary:
/opt, /opt1/keys and /opt1/info are mounted from cramfs images, meaning they're read-only.
/opt0 and /Data use jffs2 which is writable
/etc and /var are copied to ramdisk (created in /dev/shm/) and remounted at /, so we can't access the original dirs.
Sooo, the only way to change the files in /opt/ would be to change the actual cramfs images in the flash, which seems to be doable during the firmware update process. I will investigate how it's done but I don't think I'll be brave enough to attempt the actual reflashing

[igorsk]

Here's the flash memory map:
dev: size erasesize name
mtd0: 00200000 00010000 "sdm device NOR 0"
mtd1: 079a0000 00020000 "sdm device NAND/SBL 0"
mtd2: 08000000 00020000 "eBook-1 NAND flash partition 0"
mtd3: 00040000 00010000 "Loader"
mtd4: 00010000 00010000 "Reserved"
mtd5: 00010000 00010000 "FIS directory"
mtd6: 00080000 00020000 "nblconfig"
mtd7: 00180000 00010000 "Linux"
mtd8: 00010000 00010000 "msbios"
mtd9: 00010000 00010000 "Id"
mtd10: 00010000 00010000 "Info"
mtd11: 00160000 00020000 "Linux0"
mtd12: 007e0000 00020000 "Rootfs2"
mtd13: 00980000 00020000 "Rootfs"
mtd14: 00700000 00020000 "Fsk"
mtd15: 00300000 00020000 "Opt0"
mtd16: 05be0000 00020000 "Data"

Mapping to the filesystem:
Id -> /opt1/keys
Info -> /opt1/info
Fsk -> /opt
Opt0 -> /opt0
Data -> /Data
Can't confirm it, but it seems likely that "Rootfs" is the rest of /

[gseryakov]

Originally Posted by igorsk

Okay, so I did some investigation (mostly consisting of reading S20libromount script ) and here's the summary:
/opt, /opt1/keys and /opt1/info are mounted from cramfs images, meaning they're read-only.
...
Sooo, the only way to change the files in /opt/ would be to change the actual cramfs images in the flash, which seems to be doable during the firmware update process. I will investigate how it's done but I don't think I'll be brave enough to attempt the actual reflashing

Another possibility is to create a copy of /opt on writable space, make the needed changes and remount it. Since no reflashing is involved the quota for bravery could be reduced, right?

[geekraver]

Originally Posted by igorsk

Is this better?

struct Request {
 DWORD reqNo;
 DWORD reserved[2];
 DWORD extralen;
};
struct Answer {
 DWORD reserved[3];
 DWORD dataLen;
 char  data[1]; //variable length
};
struct SendBuffer {
 DWORD type; //0x10005 for WriteFile
 DWORD reserved[2];
 DWORD dataLen;
 char  data[1]; //variable length
};

int UsbReceiveProc(Request* request, size_t answersize, Answer* answer);
void UsbBuffFree(Answer* answer);
int UsbSendProc(Request* request, SendBuffer* buf, size_t sendsize, DWORD* bytesSent);

Every request and answer further defines the variable data part, e.g.:

struct FileOpenRequest: Request {
 DWORD nPathLen;
 char path[1]; //variable length
};
struct FileOpenAnswer: Asnswer {
 DWORD hFile;
};

Couple of questions about this:

1) is the size that gets passed through for the read data just for the extra stuff; i.e. for FileOpen it would be "sizeof(FileOpenAnswer) - 16"?

2) Should the "Answer* answer" arg in UsbReceiveProc actually be "Answer** answer", i.e. something like:

FileOpenAnswer *pAns = 0;
HREF hErr = UsbReceiveProc(pReq, sizeof(FileOpenAnswer)-16, &pAns);
if (hErr == 0)
{
    // do something with the answer
    ...
    // free the answer
    UsbFreeProc(pAns);
}

[igorsk]

Originally Posted by geekraver

Couple of questions about this:

1) is the size that gets passed through for the read data just for the extra stuff; i.e. for FileOpen it would be "sizeof(FileOpenAnswer) - 16"?

Request.extralen is the size of data following the header. "answersize" is how much data you expect to get in the answer. For FileOpen: extralen=4+nPathLen, answersize = 4. (and you should get 4 in Answer.dataLen).

Originally Posted by geekraver

2) Should the "Answer* answer" arg in UsbReceiveProc actually be "Answer** answer", i.e. something like:

Yes, it fills in the pointer which you'll need to free.

[geekraver]

Good - I think I'm almost done - I just have one area that's still a bit unclear which is the returned data from DirEnumNext. It seems you're passing in an answer size of zero in this case but are getting back a type and filename (with no length; is it nul-terminated?)

[igorsk]

No, there is a size, I just don't use it.

struct DirEnumNextAnswer: Asnswer {
 DWORD nType; //1=file,2=dir
 DWORD nPathLen;
 char path[1];//of nPathLen bytes
};

[Slava]

Originally Posted by igorsk

I will investigate how it's done but I don't think I'll be brave enough to attempt the actual reflashing

Probably these steps will help if reflashing goes bad

1. If the device is on, slide the "Power" so that it turns off. Look for a small pinhole on the back panel and press the reset button on the back using a pin.
   
2. Slide the “Power” button to turn it on. While the screen displays "Starting up ...", you will see the light above the "Power" button flash in yellow. Wait for 35 to 40 seconds, then proceed to hold down the “MARK” and “VOL +” buttons.
   
3. CONTINUE TO keep these 2 buttons pressed for about 5 to 10 seconds, until the round “PAGE” button makes a quick blue flash.
   
4. CONTINUE to keep these 2 buttons pressed for another 25 seconds, the screen will show a “Reset All” message, and ask to delete all content.
   
5. Press button '5' to clean up content, this could take several minutes if you have many files on the Reader. When the deletion completes, the Reader will turn off.
   
6. Press the "Power" button to turn it on; this could take several minutes if you have many files on the Reader.
   
7. Connect your device to your PC and log-in to the store.
   
8. Go to Account>Manage Devices – you will be asked if you’d like to authorize this device to your account. Please say yes.
9. Your device should be ready to read eBooks purchased from your account.

[NatCh]

Where'd you turn that up, Slava?

[Slava]

From the Stuart Young's Post. And he (and other non-us owners) got it from Sony Connect eBooks Team's email.