PRS-600 Communication with "subcpu" (button and touchscreen controller)

[Xaphiosis]

Originally Posted by porkupan

If you have a diagnostic MS card, you need to take it out of the device in order to be able to install anything. Or you can install packages from the diagnostic MS card. One or the other. I wonder if that's it.

How did you figure out the diagnostic MS card thing? Also, how did you get the cramfs images for the 600 and 900 in the first place? I'm really interested how this kind of high wizardry is done, and there isn't really much in the ways of "tutorials" as such... so maybe you'll throw a hint or two my way

[customelectronic]

Originally Posted by Xaphiosis

Something I'm not getting from this discussion is whether you've actually managed to flash the alternative (russified) firmware, or any firmware, to the reader. That means firing up windows, unpacking porkupan's package while the reader is plugged in, running flash_reader.bat, waiting for everything to finish, "safely ejecting" the reader, disconnecting the reader, hitting the reset pin on the reader, turning it on again, then once it's up going to the "about" page to see if you've succeeded.

I don't have dos/windows so I read the flash_reader.bat and did each of the lines manually using Linux. (It would have been nice to have a linux shell script to do it...) But after following the instructions in the .bat file by hand (step by step), and installing the files in the Sony reader's internal memory under a directory I make called /test, I unmount it (eject equivalent), unplug it from USB -- and from that point I have tried every combination of resetting it with a paperclip (1st attempt) turning it on again, (I never did try the "About" page), turning it on again without hard reset, resetting it from the diagnostic manual -- and on the off chance that I copied the files to the wrong place I duplicated all files in all directories. tried all combinations of possible resets, startups, again....

(I just tried the "About" page this time -- nothing...., except that it is *unauthorized* now -- which is better than when I started since it was locked up with someone else's authorization -- and resets didn't get rid of it. So, that's a new message I am seeing -- but it doesn't help.)

Have you done that? I'm pretty sure that if you've done that, you can do the arbitrary code execution when inserting an ordinary sd card with "/Sony Reader/software/autorun.xml" on it while pressing VOL+ and OPTION. You can recognise this fact by an appearance of porkupan's menu instead of the normal diagnostic menu.

And that is exactly what I don't get when I go to the diagnostics menu by creating that directory and file; and then inserting the card into the reader while pressing vol+ home at the same time. I get the normal diagnostics no matter what combination of resets, file installs, file permissions, version of flasher, etc. I try.

I didn't use "option" for most of these tests, because I understood the instructions to require booting diagnostics before doing that .... I'll try that before opening diagnostics. If it is something that simple ....

Sorry to be so direct, but I still want to help and yet I'm somehow confused by the above exchange and can't figure out if you've done this, or if you're just placing porkupan's package into /test on the reader or SD card and trying some other tricks...

No offense taken!
I'd rather be embarrassed than frustrated, really!
It would be NICE to have done something wrong for once -- I'm used to doing it right and having wrong hardware. It took me over a week to make a hackintosh because my hardware was slightly incompatible.... lost a bit of money on that, because my mac died and I needed a replacement up pronto; but I eventually modified the hack to work ... that was big time frustrating! just rotten luck.

As for loaded modules, on the 600 at least:

Module                  Size  Used by    Tainted: P
evdev                  10496  0
g_file_storage         50692  0
arcotg_udc             31692  1 g_file_storage
msdrv                1648212  2

Thank you very much! That will be quite helpful as a reference in interpreting the kernel source I have been looking at. I'll answer your next post after I try the option vol+ approach before diagnostics mode.

[customelectronic]

oh well .. it was worth a shot... nothing happened.

Originally Posted by Xaphiosis

How did you figure out the diagnostic MS card thing? Also, how did you get the cramfs images for the 600 and 900 in the first place? I'm really interested how this kind of high wizardry is done, and there isn't really much in the ways of "tutorials" as such... so maybe you'll throw a hint or two my way

There was a link given to the diagnostic programs given back a few posts; I followed that and there was a link (in russian) to the programs. So I downloaded recovery_update.zip, unpacked it, and read porkupan's linux shell scripts. I then used google translator to translate the russian pages I was given, and it wasn't very good -- but I verified that I had the right idea from the scripts in the package.

It has a diag_card_update directory, and inside the directory is PRS-900\ Updater.package and a script called update.sh;
The first time I simply copied those two items to the root directory of my SD card -- and left the autorun.xml where it was. That didn't do anything at all ... my sony was locked up (crashed) from attempting a factory init from diagnostics at the time.
I didn't expect it to work -- but just wanted to try the default first. Then I followed the instructions to run create_900_Update.sh on the diag_card_update directory -- and it didn't work because of a bug. So, I debugged the shell script -- and found that my version of dd is specifically programmed not to read the /dev/stdin or /dev/stdout files -- a quirk. (Sort of like what ps -ax | grep xxx will do, some programmers idea of a joke... do it ps ax | grep xxx .... ) In any event, looking at the expanded trace of the shell it was clear that the dd command always received the stdin, stdout in order to pipe information into sed, awk, etc -- so since that is the default behavior of sed without if= or of= specified, I removed those extra parameters from the scripts -- and it worked correctly. The main issue there is that "update.sh" is intended to be customized, and has to be made executable (it isn't) before running the create_900_Update.sh -- to be retentive I re-unpacked the files in the original state, overwrote the corrected scripts and ran the create_900... on the diag_card_update directory. Then I copied it to the memory card again, inserted the card -- hard reset rebooted, and the Sony rebooted several times and then came up as it would normally. YAY! undead sony...

I have a train to catch, so I'll have to keep the cramfs discussion short -- but essentially, under Linux there is an item called a loopback device (often it is a module, modprobe loop) which allows one to take a file and pretend it is a hard drive/flash drive/etc. In the flasher package we all downloaded, the .img file is an "image" of a partition to be copied onto the Sony. So one can simply do a mount -o loop xxx.img /foo_directory_to_mount and the cramfs image inside of it will become mounted on that directory. Then you can "cd" into the mount, look at all the files of the cramfs as if it were a normal hard drive, and tinker with them.

In the flasher package, the image file is in the directory test-flash.

--Cheers, and I'll be back at it in a few weeks. Now to use the reader for a long boring train ride, and dream of bug fixes and a mobile linux box....

[Mark Nord]

Originally Posted by customelectronic

I don't have dos/windows so I read the flash_reader.bat and did each of the lines manually using Linux. (It would have been nice to have a linux shell script to do it...) But after following the instructions in the .bat file by hand (step by step),

At the chance of being wrong again,
without using WINE or any other virtualiser, you haven't executed this line
.\ebook_msc.exe um recovery

taken from the 900 1.5a.zip flash_reader.bat

And AFAIS this utility initalize the flashing.

[igorsk]

Originally Posted by customelectronic

Igorsk,

Well, I'd like to get a USB/or real serial interface hard/or not. ... so, following up on your idea(s)... (and assuming I'll be tackling this in 3 weeks...again.)

I don't have any access to check an actual sony for loaded modules, etc, so I can't answer even the simple which way is it *really* questions....

You mentioned a keyboard in the previous post; I see in the kernel for the 900 that the Freescale (ARM processor manufacturer) MXC keyboard port was modified for the ebook reader, strongly suggesting there is an active keyboard port. I can't check lsmod on the sony without control, so I don't know if it is module/compiled/active?
This isn't a USB keyboard .... do you know of how such a keyboard is connected?

I don't think mxc keyboard controller is used in the 900 at all. I'm pretty sure all keys are connected to the subcpu only.

Originally Posted by customelectronic

On the memory:
The actual flash/nand rom is a single chip Samsung KLM2G1DEDD. That's a "moviNand/MCP NAND 2Gig nand1 kind, 1.65-1.95V, with a S3C49VDX02 controller" ... which I assume would make/emulate the MMC/SD interface; no datasheet. But the chip itself is a dual in line ball grid array. Unfortunately, I don't have a steel mask to re-ball it with new solder, so although I can remove it -- I can't solder it back on; and buying a new one looks to be impossible...

Yes, moviNAND is Samsung trademark for flash chips with eMMC interface.

Originally Posted by customelectronic

So that leaves isolating an access point and extracting it that way, then decoding with linux software BUT....

I see in drivers/mtd/mtd_blkdevs.c that Sony modified all Linux mtd drivers for enhanced speed, then I noticed...

Sony fully wrote a driver/mtd/sbl , the abbr. "sbl" is unexplained, but it seems consistent with "serial block", eg: a serial access device like SD/MMC cards...? so, very similar to your idea of eMMC.

sbl means "secondary bootloader", and nbl means "NAND bootloader". I think the sources in the Linux tree is what was used on older models (500/505/300). The new bootloaders are in the separate file )(nandboot_091125.tgz for PRS-900). AFAIR they're based on Freescale-provided code (see Linux BSP on Freescale's site). As far as I could determine, they don't offer any interactivity.

Originally Posted by customelectronic

AND driver/mtd/sbl/mtdsbl.c links the sbl acronym to NAND/SBL memory which is the right kind of memory. The source code looks to be coding a proprietary format on the device, though I'm not sure. The Freescale MX31 processor has to have an interface already capable of booting the device, for it is the only rom -- or the ARM has to have an internal flash/mask rom to run a boot. sort of a LILO/GRUB type thing... last far stretch possibility --- otherwise --- there has to be another processor capable of loading RAM with Linux, and then resetting the ARM. hmmm... do you know which it is? or how to find out quickly?

It's quite possible that the initial bootloaders come from the eMMC flash as well - i.MX31 has an "SD card" boot mode.
You could enter the serial bootloader of the chip if you know which pins to ground (as someone did with i.MXL), but that's not really doable without a service manual.

Originally Posted by customelectronic

There are driver mods in drivers/mtd/nand/nand_bbt.c, .../mtd/sdmparse.c, ../mtd/eMMC ../mtd/mtdpart which all muddy up the issue.

Reading the nand memory isn't going to happen today, it's too complicated without a good clue ... but if there are any more suggestions on the software methods, I'll still try them before leaving tomorrow.

You need to boot into the recovery mode with the diagnostic card in - that loads up the serial USB module and if you use porkupan's login_update package it will replace /etc/shadow so that you can login without a password.

Originally Posted by customelectronic

Sony mentioned discontinuing the 900, apparently they are changing the hardware...! so, this info is of limited value ... mostly good for people wishing to maintain and modify a defunct product... DMCA appropriate rvs. engineering. here's a good labeled photo of my board.

Actually from what I saw in the published sources of the new models, the hardware looks more or less the same. The E-Ink controller is upgraded to ISIS, the flash is bigger, and they'll probably beef up the subcpu to handle the IR touchscreen, but the rest looks to be more or less the same (main CPU, the R5C807, USB controller etc).

FWIW, attached is the dmesg output for the 900.

[porkupan]

If you have a diagnostic card, you can install updates from it in normal mode. However, our current publicly described method of updating presumes that you are able to switch your reader into the recovery mode. The ebook_msc utility allows you to do just that. The utility itself doesn't do a whole lot, but it utilizes the functions from Sony's DLLs, which allow it to communicate with the reader. Those functions may be partially ported into Calibre, but the port may not be up-to-date with the current reader models. I would recommend that you use some Windows box to initiate the flashing of the reader. At least until you make a diagnostic card, which will allow you to execute updates from normal mode.

[Xaphiosis]

First: I wrote something incorrect above. It's always been HOME and VOL+. Not OPTION. I apologise for the brain fart. Correct sequence is: start normally, go to home screen, insert SD card (which has "/Sony Reader/software/autorun.xml" on it) while holding HOME and VOL+.

I would suggest, before desoldering from the board, to just go over to someone's house/office with a windows machine and try a flash from there. I normally use linux on all my machines, but my laptop is capable of booting into some outdated version of XP for precisely these circumstances (or get a rescue CD with usb capabilities).

Once you can convince yourself that flashing and arbitrary code execution is possible on your device, then you will not only be happier, but you can figure out how to recreate the situation under linux, which would be a big benefit to the linux-using PRS hackers like me (having to find and boot my laptop to flash my 600 is very tedious).

Taking customelectric's observation that the 900's kernel sources have stuff related to subcpu in subcpu.h that the 600's kernel sources do not, I have found that SONY is already distributing the 650's sources, so it might be worth going hunting around inside those to see if I can find anything new.

[customelectronic]

Hi all,
I managed to miss my train home, so I am staying on vacation a little longer than expected

I built the newest Slackware release on a virtual box here and reinstalled my tool base from home, so I'm online finally!

A surprise hit; the Sony registered four memory devices sdb,c,d,e on this system, where it only registered one on my older Slackware 12.2 release; eg: the ebook memory directory, but not the Linux root directory,

The intermediate sdc,sdd are "MS" and "SD" slots, sdb is the basic ebook user memory/data, and the last directory is labeled "Launcher".
When I look in launcher, I see a "Mac" and "Windows" directory and this is pertinent:

ls -R *

...snip...

Mac/Setup Reader Library.app/Contents/Frameworks:
tinyhttp.framework

Mac/Setup Reader Library.app/Contents/Frameworks/tinyhttp.framework:
Resources  Versions  tinyhttp

Mac/Setup Reader Library.app/Contents/Frameworks/tinyhttp.framework/Versions:
A  Current

Mac/Setup Reader Library.app/Contents/Frameworks/tinyhttp.framework/Versions/A:
Resources  tinyhttp

Mac/Setup Reader Library.app/Contents/Frameworks/tinyhttp.framework/Versions/A/R sources:
Info.plist

Mac/Setup Reader Library.app/Contents/MacOS:
Setup Reader Library

Mac/Setup Reader Library.app/Contents/Resources:
FskCore.xsb  FskinLocalize.so           eblSetup.so         fsZip.so
FskImage.so  Setup Reader Library.icns  eblSetup.xml        kconfig.xml
Fskin.so     Setup Reader Library.rsrc  eblSetupConfig.xml  scripts

Mac/Setup Reader Library.app/Contents/Resources/scripts:
Apptitle_dialog.png    assets.png  background.jpg  regions
ReaderLogo_dialog.png  assets.xml  languages
... snip ...

When I take a look at the lsusb -v, I notice the ID is not PRS-900 but
Bus 001 Device 002: ID 054c:031e Sony Corp. PRS-505 reader

I didn't see this before, and don't have time to tinker around today -- but it looks like something might have updated after all; unless that PRS-505 is an artifact of my Slackware distro or something, all the flash hacks seem to have PRS505 stuff internally suggesting this directory is an update of some kind.

hmmm.....

[igorsk]

Launcher partition is just for the Reader Library installer (actually, a downloader for the real installer).

[customelectronic]

Originally Posted by igorsk

Launcher partition is just for the Reader Library installer (actually, a downloader for the real installer).

I see. So, my old system was just malfunctioning in not detecting that partition.

I found Calilbre, and am looking at it now to see how it works.
Setting up a windows emulator is a pain, so I will work on calibre for a couple of days.

Historically, using porkupan's stuff...
In the one package I downloaded, the ?msc? script was also in python -- and I looked through it. However, what I am hearing from the thread is that msc.exe does something not obvious. I'll have to re-download everything for I can't access what I did from my vacation spot, and look through it again too. One of the packages generated check-summed binaries for the Sony using Linux scripts, and I don't think it required msc to launch it.

When I look at dmesg after plugging in my Sony, the only information I am given is about the usb memory emulation for each of the filesystems on the sony. That puzzles me -- for there does not appear to be an interface other than the filesystems.
Are you suggesting that there is some kind of command sony issues to the control endpoint of the Sony/Linux USB driver through windows DLL's which causes it to enter a special mode? If so, what ought I look for in calibre to see how this works? Or does anyone have a USB packet dump of the transactions I can use to write my own Linux interface driver to probe it?

Thanks for the help.

[igorsk]

It's a standard trick - messages are sent to/from the device using a custom SCSI command. See modules/usb_gadget/file_storage.c in the Sony sources (SC_SONY_EXTENDED).

[customelectronic]

Originally Posted by igorsk

It's a standard trick - messages are sent to/from the device using a custom SCSI command. See modules/usb_gadget/file_storage.c in the Sony sources (SC_SONY_EXTENDED).

Yes, I see that the SC_SONY_EXTENDED triggers functions do_extended_h2d() and do_extended_d2h() in "usbtg_ebook5.c". The extended command reads and writes to a buffer held in the filesystem gadget, "the_fsg". From what I see, the current scsi logical unit (lun/curlun) is only used to report failures, so that the command is really device independent. eg: sending SONY_EXTENDED (0x20) as a SCSI command to any of the Sony reader scsi devices (sdb-sde) on my system, would have the same effect (AFAICT).

The actual extended command appears to be associated with a 4K static buffer (usbtg_ebook5_gfile.h); and there seems to be both proc and device driver interfaces to that buffer; so I presume this is not writing to the root filesystem, but rather this communication buffer is opened by another process as if it were a file.
eg: /proc/usbtg/foo_bar
/dev/usbtg ... or at least ...device w/ major 126, minor 0

Since this is a character device on the Sony, but the SCSI is a block device ... I am not quite sure how to operate the interface; I'll see if I can code a SONY_EXTENDED command to read a 4K block and see what happens....



Side note:

I don't see anything helpful (so far) in calibre with regard to this interface, did I miss something?

..But I did happen to notice earlier in the thread that someone was mentioning peculiarities/problems with subcpu and the USB charging interface for the Sony.

In the source code for the ioctl()'s for usbtg there is the standard "powernego" file operation, but (surprise) also a "usbcharge" file operation. Also in the IOCTL there are USBTG_PD_SET_USBCHARGE and USBTG_GET_USBCHARGE, so perhaps that will help someone find the charging switch they were looking for?

usbtg_ebook5.c: case USBTG_PD_SET_USBCHARGE:
usbtg_ebook5.h:#define USBTG_PD_SET_USBCHARGE _IOW('u', 0x06, unsigned int)

[igorsk]

Yes, Calibre does not use the SCSI commands because it can do everything it needs with normal file operations. The SCSI commands are only used for "system" stuff, such as registering Reader for Adobe ID and firmware update functionality.

[customelectronic]

Originally Posted by igorsk

Yes, Calibre does not use the SCSI commands because it can do everything it needs with normal file operations. The SCSI commands are only used for "system" stuff, such as registering Reader for Adobe ID and firmware update functionality.

I am able to access the SC_SONY_EXTENDED command using Linux scsi generic interface, and verify that the code is functional on my Sony. But ... the usbotg driver gets the size of the SCSI extended transfer from the USB bulk in or out command; the size isn't part of the SCSI command itself.
I imagine the buffer size (input and output) passed to the Linux SCSI generic interface might properly set the direction of the data flow under Linux; ? ; but otherwise, this might require some kernel hacking ...

Looking at the DLL's in the flasher package:

DriveManager.dll USBDLL.dll MSCEncComm.dll prsctr.dll

Only prsctr links to dll's on the Sony, and it isn't linked to ebook_msc.exe; so it is pretty safe to assume that the dll's of the flasher package do all the work; Is the source code available for them in order to make a Linux flasher package?

I can use wine to run the exe, but it doesn't appear to recognize the USB port under Linux.

[igorsk]

Originally Posted by customelectronic

Is the source code available for them in order to make a Linux flasher package?

Sony releases only what they have to. Source code of the UI and PC-side components is not available.