I don't really know how to answer. I don't think I discovered anything monumental, more of an increasingly coherent idea of how things fit together...
As far as the linux kernel and drivers were concerned, I didn't really know much at all. When trying to figure out the screen, I noticed there was a /dev/fb, which indicated a framebuffer device. Trying to write to it though did nothing. After digging a bit, I remembered that many devices are controlled through ioctl calls on their representative filenames. To figure out which driver it was, I pulled out the kernel messages (dmesg), and the kernel config which sony thanfully left in there (/proc/config.gz) and found that it was a "broadsheet" driver that they use. So to make the screen display the framebuffer contents I read the source code for the driver and found where the ioctl handling entry point was, and traced from there what info to give it to make the screen transfer, then had to look through it again when it froze the machine, until I figured out how to change the power mode. So reading over the souce code gave me a better idea of how drivers are written.
Also, the whole "USB gadget" and "USB on-the-go" stuff was something I didn't know about. The fact that a driver can make a device look like a disk, a serial port, a network card, etc, I find awesome. That OTG (on-the-go) can also flip things around and allow you to plug another device into your reader was cool too. In order to compile the g_serial module, I learned to cross-compile the kernel. Since sony modified the OTG drivers (but provided the modified source), I learned that the kernel attaches checksums to all kernel module symbols to prevent modules for a different kernel from being loaded. I also learned to build a kernel module by itself in a separate directory. I checked out what they modified, to see if it was anything interesting. I learned that for one USB gadget module to work, you need to unload the others. Then I had to dig through the init scripts in /etc/init.d looking for how to restore the g_file_storage module so that tinyhttp can come back to at least a marginally usable state. Also, you can just "create" a serial port with "mknod /dev/ttygserial c 127 0" and it magically works through g_serial when you connect the reader to a PC!
With ELF executables and dynamically linked modules, I basically had to learn how the whole dynamic symbol resolution mechanism works. It's actually quite complicated.The best info I've found was
http://em386.blogspot.com/2006/10/re...e-symbols.html
I think I talked about this when I posted the first version of my disassembly-annotating tool. That tool is more advanced now, figures out returns, call sites, performs simple symbolic execution to find memory addresses and strings, as well as collecting a call graph. It can then export that call graph in DOT (graphviz) form which one can then plot into other formats (svg/pdf/png/whatever).
I'm attaching the latest version of the tool, as well as two partial graphs produced from it, for ebookSystem.so and ebook.so (these are the modules where all the hardware control happens). I'd advise against trying to view them in anything other than inkscape or an intelligent vector graphics viewer (e.g. ImgMagick runs the system out of memory).
I actually hacked together another simple program to generate those SVGs from DOT files with positioning such that inkscape sees the arrows as connectors (read: you can reposition nodes), but it's kind of dodgy.
So as you can see, it's been quite a learning adventure with my PRS600. Not to mention, I've read a lot on it too
I honestly don't know if any of this helps or interests you, but, you're the author of PRS+, so I figured it's worth a shot. Also, I find it a lot of fun. I would drag everyone into it if they let me!
