customerelectronic: thank you for your post and kind words. It's clear you're someone who is far more competent at this kind of thing than I am, so while I will try do your questions justice, I'm afraid my skillset may come up short (and what I do know is restricted to the PRS600 I own). So, here goes.
The system is a freescale iMX something or other, iMX.31 in the case of the PRS600. Reading the datasheets will certainly help you figure out the connections on the board, but it didn't help me figure out functionality (I never got around to disassembling the reader). There are several mtl sections on the NAND chip which are mounted read-only during startup. I think two of these are relevant to the concept of "flashing the firmware". One carries the root filesystem (of interest to you), while the other I have no idea. The contents of the important mtl is a cramfs image, which, if you can flash it to the device, can cause the device to do whatever you want.
The iMX has two serial ports. One is connected to the "subcpu" (/dev/ttymxc1), and the other is unconnected (/dev/ttymxc0). If you want to connect to that port, you might get a login prompt (saw a screenshot on a russian site like that), or you might get nothing (saw a post of someone doing that too). The broadsheet interface is at /dev/fb0 pointed to by /dev/fb.
Getting started on hacking/code execution. First, you need arbitrary code execution. There are two ways I know of bootstrapping the process. Both involve the same "exploit" (loading a .so module that in its onLoad function calls system(...) - credit goes to porkupan). I've documented a bit on that in one of the READMEs attached to my post at
https://www.mobileread.com/forums/showthread.php?t=82714
The first method is to flash the device with a custom cramfs image. Just as for the 600, porkupan created "russified" firmware for the 900:
http://projects.mobileread.com/reade...sh%20packages/
If you can use his version, it follows you can also modify the cramfs image to do whatever you want it to. Be aware that it is a very good idea to ensure that whatever modifications you make allow you a return to the SONY software (tinyhttp it's called), as that's what actually allows you to flash the reader's root mtl. Lose that ability and you might have a brick on your hands.
Anyway, instructions for that are likely the same as for the 600 as the files and setup seems identical. Here's what goes for an installation manual:
http://translate.google.com/translat...hp%3Ft%3D12146
If you install porkupan's "russified" firmware, he also added a feature where it can execute stuff from the /test folder when you insert an SD card and press a magical combination (replacing SONY's default test suite). I've documented using this to get a shell over USB in my USB shell post (linked to above).
To answer your question which I missed above, the boroda firmware only modifies the functionality contained in the xml resources interpreted by the tinyhttp program. It does not modify the kernel. Insofar as I know, I am the only person who posted about compiling modules for the kernel as released by SONY (which you seem to have the sources of). I don't think anyone has been brave (or stupid) enough to compile the entire kernel, flash it to the reader and then pray it works :/
The other method is not to flash the device. These guys have figured out how to simply run binaries on startup using a different autorun.xml setup, combined with the porkupan/igorsk module loading trick I mentioned above. Their thread is here:
https://www.mobileread.com/forums/showthread.php?t=87474
While their software is not open source, the part that actually starts it up is pretty obvious, so you can easily modify it to suit your needs. It also maintains the ability to go back into the normal ebook software if necessary. As a first step, make it run, say, a modified version of my "fb.c" I distributed with the USB shell post, and you'll know if you have arbitrary code execution.
In any case, sony just bludgeoned their tinyhttp program straight into /etc/init.d/rc (at the end). So in my cramfs image, I changed the last line of /etc/init.d/rc to run my own program (which I've attached to this post):
Source code and other stuff is available here:
http://www.sony.net/Products/Linux/Audio/PRS-900.html (note that the SDMS module is SONY proprietary and taints the kernel, so no sources for that I think).
Regarding your observations on subcpu.h: it's not available in my kernel sources for the PRS600:
Code:
[~/PRS600/extra/linux-2.6.23_090626]# find . -name "subcpu.h"
[~/PRS600/extra/linux-2.6.23_090626]#
So I had to reverse-engineer it from scratch. Thank you for finding that! I will now be able to check my assumptions. There's some weird stuff going on, e.g. you can put the subcpu to sleep, but then none of the buttons or touch screen work anymore, so you can't wake it up. Without docs, it's all a bit strange. The WM8350 is well documented, but not how it's connected to everything. So in theory I should make it start charging the battery from the USB port, but thus far the best I've managed is
I think getting it to trickle-charge. Luckily the OTG filesystem driver exposes the charging/usb interface. This interface will not be available if you unload it and replace it with the OTG serial driver, causing confusion
The broadsheet driver stuff I've mostly got figured out. I even wrapped it in a nice interface and wrote a silly little editline-based wrapper (needs editline.so in the library path). Ah, I'll attach that too (fb_inter.tar.gz).
I'm also attaching some reverse-engineered code which queries the status of the SD/MS devices, but apart from the obvious (inserted/removed) I don't know what the numbers mean.
Finally, I'm attaching some code which reads a WM8350 register specified on the command line. Might prove useful. No idea.
Anyway, that's as coherent an answer as I'm able to give you (I could make it more coherent given time, but you said you're flying soon and wanted to get started fast). I've walked 25km yesterday and just got back from martial arts, so I'm really tired. If something doesn't make sense, feel free to ask me again. I do hope the above helps with the generic idea of things, and maybe you'll only be left with specific/technical questions which are quicker for me to answer.
Good luck to you sir, I hope to hear of happy hours of hacking from you. I also envy you slightly for your 900's larger screen. I don't use SONY's library/store anyway, but a larger screen... now that would be something!
As for my own hacking, I need to finish my PhD, so it's all on hold at the moment. Grr. Otherwise I'd implement the touchscreen/buttons as a uinput device and port Qt...