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

[customelectronic]

The restore caused my system to not mount at first, (worse) but there were a few bugs in the scripts...
But, then again, after removing all files from the root of the sony, it rebooted and deregistered -- so, at least I no longer have a brick; and I can use it with the sony store; HEY! this is better than when I began. The recovery stuff works, and well! Understanding russian is difficult -- but being as I am linux only; this is a boon to have a linux based recovery script where I know the technical stuff to fix things myself.
I can read code from anyone -- if not their native tounge.

Thank you kartu!

I still don't have the USB terminal; but at least I know how to change the auto-update, but it may still be faster for me to just reflow desolder the ARM, attach a test jig and reprogram it manually.

I'll experiment a little more, but as I am leaving for vacation -- I only have a day to do this in;

Mark -- Yes, I see the Data directory is key, and I can home in on that. Thanks.



Oh, quick question: Is the USB serial terminal of the Sony supposed to show up as a /dev/ttyUSBxxx like normal, or is is something special?

--Thanks!

[customelectronic]

Hi,
I am able to create all the restore packages, and load them, but the sony900 doesn't show any signs of recognizing them; nor even the full Russified installation package.
In the restoration package, I noticed the setup.sh scripts were not executable -- and when the packages were test un-tarred & verified, they were not executable; So after trying them as delivered with no result -- I rebuilt them with executable shell scripts in various configurations; nothing works. I have a reset Sony and that's it... none of the hacks shows any sign of working at all to achieve arbitrary execution code. It doesn't matter if the file is placed on the memory stick, the internal memory, the internal memory sub /test. etc. all combinations failed. From time to time I would cause a calibration error, but I think that may have just been how I handled it. I tried hard resets, power down from diagnostics, card shove in with button combos, simple turn on, insertion of the card, erasing the caches, all failed as well.

In diagnostic mode, which works again, I can factory initialize to my hearts content without locking the system up anymore. The only log function which works is "convert log", but that doesn't appear to do anything. All other tests work fine.

I watched DMESG and USB endpoints and it never produced anything except "mass storage" in spite of the recovery images supposedly having a terminal log in version.

For future reference of others, my machine was manufactured in '09 after the 48th week. So it appears that Sony has done something new by that date. Bummer, I;'d really like to fix some bugs in it at least...

I am looking at the memories and preparing for a desolder job/ or massive jumpering if possible to access the flash directly with a Superpro. I can hand replace the cramfs; and worst case I can start compiling kernels from scratch. long or short, I'm going to win;if anyone knows tips/shortcuts, let me know. Thx.

I have a kindle 2 which I bought with a broken screen because I had read the screens were made on a kaptan plastic, so I figured being flexible, the screen itself wouldn't be totally damaged. I was wrong -- but to pass general info along, the screens in Sony's and kindles have a glass backed substrate. Under a microscope, it is fairly obvious that some kind of transistor is grown on it. The electrophoretic paper can be peeled off of it; and the top user side of it is one pure zinc oxide/transparent semiconductor (I assume Zn). NOt individual wires as I had hoped. Attaching that electrode to ground, I am able to change the color of the paper based on the polarity of the charge in a wire brought near the opposite side -- the picture color (Black/white) change stays until a voltage of opposite polarity is applied. So a dead screen isn't a total loss -- but it is practically non-recyclable.

The Epson chip I mentioned on the Sony is also in the Kindle, as well as the same basic ARM processor. It doesn't have the card reader chip, and it does have labeled test points; It was also manufactured last year. Not only is the screen driver chip the same, 32 grayscale, although that kindle I think is only 8 level...not sure. But the connector for my larger screen looks like it will fit into the same socket ... I may pass along a test at some point, but in theory the driver is compiled for a specific resolution and anyone could re-compile it for a larger resolution if they wanted to.

I am going to finish analyzing the circuit tonight, and see if a de-solder is practical in the morning. I hope my troubles help others ... !

[kartu]

customelectronic

I am very newb with embedded/linux/jtag stuff, so I don't quite understand whether you've managed to reanimate your device.
Unless you are actually looking for a reason to do some (de)soldering (I probably would, if I could ) I'd contact porkupan (aka boroda) on this matter.

PS
Very offtopic

Originally Posted by customelectronic

Understanding russian is difficult...

I bet Georgian is even more difficult, just an example:
სხვა სხვისა ომში ბრძენია

your nick would look like:
კასტომელეკტრონიკ

[customelectronic]

Originally Posted by kartu

customelectronic

I am very newb with embedded/linux/jtag stuff, so I don't quite understand whether you've managed to reanimate your device.
Unless you are actually looking for a reason to do some (de)soldering (I probably would, if I could ) I'd contact porkupan (aka boroda) on this matter.

PS
Very offtopic

I bet Georgian is even more difficult, just an example:
სხვა სხვისა ომში ბრძენია

your nick would look like:
კასტომელეკტრონიკ

Yes it is re-animated; but I can't get it to run anything from porkupan, or others. It is locked in normal Sony mode -- it is better than when I started; for I can use the sony store now.... But, I'm irritated with it. I would contact porkupan, but I only have one day -- and I doubt I can get a 1 day turn with him speaking Russian.... If I can't work it out by tomorrow, I'll give up until I'm back from vacation -- roughly three weeks... and then I might try porkupan. Your links did help. Thank you.

I deciphered all the chips in my Sony. Wow. Three MCU's, one ARM11 w/ multimedia (400MHz or so) One what looks like a Renesas: R5F21246SNxxxFP R8C microcontroller 32K rom. 8/16 bit processor, and then a third one possibly integrated into the Samsung 2G flash rom. Why sony needed the extra Renesas one has me stumped. My curiosity is getting to me. This thing is seriously overkill in the way it is built -- the ARM processor has all the peripherals built in, but Sony still used external peripheral chips... that makes me wonder why.

Desoldering full chips is impractical in one day, but it looks like I might be able to isolate the flash memory and decode it; there are several test points .. it just depends on how quickly I figure them out tomorrow. A task beyond the typical hacker....

[kartu]

Yes it is re-animated; but I can't get it to run anything from porkupan, or others. It is locked in normal Sony mode

So, for example, this installer doesn't work for you? (it flashes with new_opt.900.img located in test-flash subfolder)

[customelectronic]

Originally Posted by kartu

So, for example, this installer doesn't work for you? (it flashes with new_opt.900.img located in test-flash subfolder)

Interesting choice of link; yes that is the very last one I tried, and it doesn't work.
That's 1.02e. I tried 1.0; also and the first one I tried was 1.05. Although, come to think of it, I am only sure of trying the kernel loader script of 1.05; when I tried the image of 1.05 in /test on the Sony internal memory -- that's what was on the system when it locked up and stopped booting all the way up. "almost brick".

The links you gave me a couple of posts back appeared to trigger the sony to complete the *normal* boot -- but nothing else. It is almost like it was a random fluke.. After that -- Once I cleaned off the 1.05 flasher files (/temp) from the sony internal memory -- everything returned to normal. But I have not once gotten the "DANGER" sign during the diagnostics which would indicate the flasher was working. etc. Nor have I ever gotten a log to write to /Data or /tmp/Data or /media from modifying any of those scripts. Pretty much a dead failure.

[igorsk]

Originally Posted by customelectronic

Why sony needed the extra Renesas one has me stumped. My curiosity is getting to me. This thing is seriously overkill in the way it is built -- the ARM processor has all the peripherals built in, but Sony still used external peripheral chips... that makes me wonder why.

The Renesas chip is the "subcpu" mentioned in the subject of this thread. It is present in all models beginning from PRS-500 (and probably Librie). Sony uses it to handle the simple tasks of controlling keyboard, power, leds and touch screen. I guess this way the big and hungry ARM can spend most of the time sleeping on low power but when it needs some time for number crunching - such as rendering HTML - it doesn't need to bother about all the "small fish". I think it's also for this reason that Sony went back to using a dedicated SD/MS controller (Ricoh R5C807) after a short stint of relying on the built-in CPU ports in PRS600. Such extra hardware might increase the cost a bit but it seems it does help to save power.

[porkupan]

Originally Posted by Mark Nord

This is obvious, as the holding vol+ & Home & inserting SD-Card, in a not russified PRS600/900 just trigger the execution of autorun.xml in a path hardcoded in kbook.so

The russified new_opt.900 (cramfs)image must hold a patched kbook.so which points AutoRunRoot.Path to "Data/test/" thus enabling custom-fsk-scipt execution.

Just to clarify that.

Actually, the path is indicated in kconfig.xml. So, it's configurable by a text XML file, at least in theory. I overmount a test version of kconfig.xml when /Data/test folder is present. I also used the same method to try and test the custom made dictionaries - the project that we gave up on eventually.

[customelectronic]

Originally Posted by igorsk

The Renesas chip is the "subcpu" mentioned in the subject of this thread. It is present in all models beginning from PRS-500 (and probably Librie). Sony uses it to handle the simple tasks of controlling keyboard, power, leds and touch screen. I guess this way the big and hungry ARM can spend most of the time sleeping on low power but when it needs some time for number crunching - such as rendering HTML - it doesn't need to bother about all the "small fish". I think it's also for this reason that Sony went back to using a dedicated SD/MS controller (Ricoh R5C807) after a short stint of relying on the built-in CPU ports in PRS600. Such extra hardware might increase the cost a bit but it seems it does help to save power.

Hmm.. I thought about that when I first was looking at it; I don't have any power measurements to check with, but what is really odd is that Sony still chose to use that particular ARM processor with all its internal peripherals. I was looking at another arm 9, which does 800MHz, but doesn't have the multimedia extensions -- and the power consumption can be down in the microamps, with the processor running at 1Mips or so -- the same as the Renes... cpu. The thing is, the particular processor they have chosen -- the same as the kindle, BTW, but a mysterious extra letter "D" in the sony version.... and no explanation in the data sheets -- I would think still has to clock all those peripherals even when not in use. It can partially shut them down, but their very existence is going to cost some power. Multiplier units with multiword fp registers are notorious power hogs. Yet they still put this ARM in a machine with a display that is incapable of 30 frames a second video.... My old pentium SSE2 machine with SSE2 turned off renders HTML much faster than the Sony.

Looking at the video driver, too, is a puzzle -- for there are huge timeouts on the order of a second (100's of milleseconds at least); when a complete shut down and restart of the video chip is mentioned in the comments to be on the order of 2ms -- and I know for a fact the screen keeps its image with power off. OUCH! There are reasons for this kind of code -- but it really looks to me like someone had to get it done FAST, and that information was not given to the engineer/software people in a timely fashion or something was misrepresented. Many of the datasheets are not available directly -- eg: samsung has 1G memories on their site, but the 2G memories in the sony have no datasheets. I found the pinouts, but it wasn't direct.
It all speaks of closed shop deals between companies, and a little misrepresentation going on.

Ps. I just re-tried the 1.05a flasher. Copied the autorun and the test-flash image files into the internal /test directory of the Sony. Negative -- nothing bad or good at all, as if it wasn't there. I don't have windows, so I didn't run the msc executable -- but that shouldn't matter for I did everthing the batch files indicated, and I even tried adding an asterisk to the MD5 just for retentiveness on the fourth try.

Getting the data off the ROM is problematic, for its interface to the ARM isn't clear to me. It has an MCU of some kind according to Samsung, and I am not sure if it is emulating a hard drive or what. I need to adsorb the kernel code for the nand memory .... but I don't think I have enough time.

cheers .... comments, suggestions, and questions welcome.

[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.

[igorsk]

AFAIK PRS-900 uses eMMC flash. So if you really want to do it the hard way, use the SD/MMC protocol. Or just use the mtd driver provided by Sony.

[customelectronic]

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.

The ms duo card is only a 16Meg, it is no good for installing; all attempts at an actual flash style install used the internal memory of sony with /temp. The MS did work as a diagnostic MS card which triggered the Sony to factory reset earlier, but no evidence that the script actually ran correctly. I tried both with the card in an out during boot, after boot, hard reset, test shutdown -- restart -- and I erased it for this last test, and only did a touch /Sony Reader/software/autorun.xml which does work to get the sony into test mode. I have also tried with all autorun.xml & scripts on memory stick in all combinations of root, Sony Reader subdirectory (I think that's the name... too tired to remember ) and the software subdirectory. 8 combinations tried -- none were good.

Ps. The bash scripts that make the diagnostic card use dd if=/dev/stdin or of=/dev/stdout occasionally. on Slackware 12/13 my version of dd gives an error message and won't run; it is only dd that refuses to use these dev files -- the header code works correctly. Since dd defaults to stdin, and stdout, simply removing the extra parameter made the scripts run correctly.

I tried the diagnostic card recovery, and the serial version, both as untarred/zipped and after running the script on these two versions and checking them. ...again In all combinations... no evidence that it ever changed the OTG usb driver to the serial one. all kernel dmesg/lsusb -(long format) showed only bulk storage device. Timing of plugging in the cable made no difference either.

The sony boots very regularly with the LED flashing about 10 times during startup. It's a champion plain sony reader.... The only quirk is that if the USB is plugged in during the early part of the boot (but after the boot is started), it will sometimes delay the boot for a significant period of time and may never switch to a mounted filesystem over usb. I get a "No media" error when mounting it when that happens, but that is pretty obviously an unplanned for combination of events. Simply unplug and replug restores normal USB bulk storage operation. It doesn't crash anymore...

sigh.

[customelectronic]

Originally Posted by igorsk

AFAIK PRS-900 uses eMMC flash. So if you really want to do it the hard way, use the SD/MMC protocol. Or just use the mtd driver provided by Sony.

want to do it the hard way ... and what I am doing isn't???

That would make sense because the Samsung flash is located relatively far away from the ARM processor, and it looks like there are some lv/ttl chips 245/541/? chips in the area between them suggesting an at most 16 bit low speed bus change/buffer, or interface glue logic of some kind in that general area. Perhaps after a shower, I'll upload a picture.... Thx. for the idea.

[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?

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...

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.

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?

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.

Ps: enlarge(able) photo below and note...
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.



Uploaded with ImageShack.us

[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.

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.

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...

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