View Full Version : Pocket Edge Hardware/software - LONG - TECHNICAL


yugami
05-29-2011, 05:07 PM
I spent some time this afternoon poking around the guts of my Pocket Edge, this is what I've found.

The internal storage (all parts of it) is a single flash chip which appears to be 3.5 gig large.
Its broken into 4 pieces ubi:system, ubi:userdata, ubi:cache and ubi:storage

ubi:storage is mapped to /intstorage and is the 2.5 gig of free space.
ubi:system -> /system 322.2 meg
ubi:userdata -> /data 322.2 meg
ubi:cache -> /cache 322.7 meg

I think with a custom update (if we figure out how to do that) and if people move there storage to sdcard we can cut up the storage differently to increase app space. ubi:userdata is where our installed applications end up.

The really interesting stuff is in ubi:system
/system/app - all the APK's that the edge ships with
/system/bin - standard linux stuff
/system/esi - this is that holds the eink/annotation software system startup stuff

esijournal/esicalender/esireader applications attempt to connect to the WACOM DSU (most likely a WACOM 8001) which is a pen enabled touch sensor that goes under a display.

all 3 go through the same startup (and error out since I'm remote)
Connect to DirectFB (this is a low overhead display manager, probably to get the different tool bars etc)
Connect DirectFB to WACOM DSU (touch screen)
Connect FBDev - DirectFB (800x800 resolution)

GDK is also involved - this is a drawing kit for displays and probably provides the windows of the menus/toolbars - possible part of the annotation feature as well.

start_epd.sh
Turns on power save mode for the Marvell processor
init_wacdsu - drives the wacom dsu i'm guessing
sd8688.ko - Wifi/Bluetooth

Loads kernel modules
syscopyarea.ko - makes a bit copy of a FB - this is probably our save for annotation
sysfillrect.ko
sysimgblt.ko - makes an 8 bit source into a 32bit image (copy to lcd feature)
fb_sys_fops.ko - underlying frame buffer read/write to memory

ep3522fb.ko - (nonstandard - possibly eink display driver? referenced as EPD_MODULE) - this looks custom from the brief peak I've had.

bmm.ko - (nonstandard - unknown at this time google bmm_drv.ko shows up some stuff for Marvell Dove)

reference to thirdeye (there is also an application named this) and loads udlfb.ko
udlfb.ko is a driver for Displaylink (displaylink.com) which is a usb based monitor technology
this is our driver for useing a projector I see people talking about?

Another kernel module of note is galcore.ko driver from Vivante Graphics GPU

esi_init.sh calls fix_permissions.sh which is based on this blog post to fix some Android problem
http://blog.elsdoerfer.name/2009/05/25/android-fix-package-uid-mismatches/

QCUdevScript.sh - looks for a 3G modem we don't have probably useful for external 3g modems.

emusan
05-29-2011, 05:20 PM
Great work! I'll look through it a bit more when I have time later, but from a quick scan this looks like pretty useful information.

yugami
05-29-2011, 10:00 PM
just for fun - making an update.zip
http://www.londatiga.net/it/how-to-create-android-update-zip-package/

emusan
05-29-2011, 10:55 PM
just for fun - making an update.zip
http://www.londatiga.net/it/how-to-create-android-update-zip-package/

lol I was just finishing up a similar article(same instructions, different site), this could come in handy if we can get market and talk working, much easier than installing all the gapps separately. I don't suppose you know much about android hacking? If so perhaps we could work together on the problem... Unless of course you know more than I do(VERY likely if you've been doing it for more than a few days), in which case I may just slow you down lol.

yugami
05-29-2011, 11:26 PM
I know nothing about android hacking. Poor weather and a headache have given me an abundance of freetime today so I dusted off my old linux hacking skills (7 years rusty) and played around.

Seems that they are using a custom format for the update.zip they have their own update.sh that does all the work

Fun comment from the update:

# FIRST, whack everything in system/xbin for release, i.e. "user" updates
# ...this is in an effort to harden against misuse and abuse

They really spent way too much time not being open.

trying to disassemble the update.sh is a bit problematic because they reference a series of variables from some external source. perhaps I can use my CNC linux box to mount the raw images and see whats in there.

yugami
05-29-2011, 11:44 PM
Edit to my NAND flash summary. Its a 4Gig chip (makes a lot more sense) The other .5 is probably boot and recovery (recovery is what makes the 2 button update load possible)

Samsung K9LBG08UOD-PCB0

Edit:
Epson E-Ink driver can't make out the model number.

Edit2: EE used the S1D13521 I'm guessing the PE is the S1D13522 based on the ep3522fb.ko driver - Vizplex E Ink screen

simple google shows the documentation for the Epson EInk chip. This does multi region updates which makes the way that the menus update make sense.

emusan
05-29-2011, 11:46 PM
yeah, I spent about an hour or so looking through the update.sh then gave up as I know very little about shell scripts(I've been meaning to go back to it, but its always taken a kind of back seat). There are a few other funny-ish comments sprinkled about but that one is the best, and at the same time the saddest... Though they did at least mention that thats what that portion did, so if we were to "remove" it, wouldn't it not "whack everything in system/xbin"?

I had to sell my Linux box a few months ago to get a laptop for college, so now my *nix'ing is limited to a VM :(.

Oh, and I've got all summer, so I plan to learn a ALL the ins and outs before the end, hopefully something will come of it lol.

yugami
05-30-2011, 12:54 AM
I can point you in the right direction but I shouldn't spend a ton of time on this. Long slow crappy weather weekend is making this very doable right now but long term I need to focus elsewhere.

Please checkout my updates - while the devil is in the details this doesn't seem that tricky.

Android connect to the wacom sensor and you use libgtk-framebuffer to do a higher level drive on the framebuffer (draw the menus). Annotation turns on and uses the x,y output to do the drawing (IMO should do pressure as well if possible) The chip does transparent overlay so it drives the annotation layover.

The nook uses the same EInk display and the downgraded driver chip(3521) (and android)

emusan
05-30-2011, 01:16 AM
Awww... DON'T LEAVE MEEEEE.... lol its okay though, I understand, just be sure to check in from time to time lol.

I noticed the e-ink similarities when I purchased, I think the company only makes a few models, maybe I can find some source code examples out there by others... Unfortunately my experience with e-ink's is zero, and my experience with LCD's is very little(I made a small graphic appear on one once lol).

and what might not seem that tricky to you is probably a few weeks worth of work to me lol(still haven't technically graduated high school yet rofl), but I've got the time right now... thanks for all the help so far, you're great!

yugami
05-30-2011, 02:33 PM
Google "broadsheet e ink" S1D13521 ties into that (either thats its street name or something) there appears to be a broadsheet driver in embedded linux already.

http://developer.txtr.com/Broadsheet_Electrophoretic_Display_Controller_S1D1 3521
http://lxr.free-electrons.com/source/drivers/video/broadsheetfb.c

A friend of mine enhanced the image from the PE teardown someone posted and it looks like (regardless of the name of the driver) they are using the 3521. This has most of the same capabilities from the info sheet From what I can read on the tweaked zoom the chip says

Epson
D13521183
--stuff---
EINK

MondoMor
08-22-2011, 09:17 PM
I think I remember reading that more info about the ICs on the mainboard would help. So I took some pictures.

http://www.mobileread.com/forums/album.php?albumid=711

One complication might be U44, which is a programmable PIC microcontroller:

http://www.mobileread.com/forums/picture.php?albumid=711&pictureid=4611

ivanjt
08-23-2011, 06:49 AM
Very good! If you have pictures like this do you have any of the complete boards - both sides as I'm trying to get some idea of the interconnections.

MondoMor
08-23-2011, 02:38 PM
Next time I open it up (maybe to fix my power switch :( ) I'll try and chuck the board on a flatbed scanner.

There does seem to be a serial port that could probably be used to monitor the boot-up. I need to hack up the right hardware to watch it.

JTY
08-23-2011, 05:15 PM
Next time I open it up (maybe to fix my power switch :( ) I'll try and chuck the board on a flatbed scanner.

There does seem to be a serial port that could probably be used to monitor the boot-up. I need to hack up the right hardware to watch it.

Yes there is serial console on the motherboard, check my post for details.

tekknogenius
10-13-2011, 02:22 PM
Next time I open it up (maybe to fix my power switch :( ) I'll try and chuck the board on a flatbed scanner.

There does seem to be a serial port that could probably be used to monitor the boot-up. I need to hack up the right hardware to watch it.

did youever get your power switch fixed? I broke mine as well.

MondoMor
11-28-2011, 06:40 PM
did youever get your power switch fixed? I broke mine as well.

Sorry it has taken so long to respond. I did fix my power switch. The part number I found in this post (http://www.mobileread.com/forums/album.php?albumid=711&pictureid=4622) was correct.

tekknogenius
11-28-2011, 08:37 PM
Sorry it has taken so long to respond. I did fix my power switch. The part number I found in this post (http://www.mobileread.com/forums/album.php?albumid=711&pictureid=4622) was correct.

Any problems desoldering? Or how were you able to get it off.
Thanks.

MondoMor
11-29-2011, 06:26 PM
I cut off the metal frame with a diagonal cutter, and desoldered the pins one at a time. The mounting leads required a hotter tip than the switch leads, and I used solder braid to ensure the pads were flat before putting the new switch in place. Again, the hotter tip was needed for the mounting leads.

tekknogenius
11-29-2011, 11:32 PM
Thank you. Is it surface mounted?

ivanjt
11-30-2011, 08:19 AM
If the mountings are surface mount then they will have a flat part on a solder pad. If they aren't then the metal will go through the circuit board.

The reason the mounting needs a hotter tip is because you have to heat a lot of metal to soldering temperature.

You know you need to do it - courage!

tekknogenius
12-01-2011, 09:50 AM
You know you need to do it - courage!

You are correct indeed, my friend! LOL Thanks for the encouragement. I've been delaying this for so long. I even ordered this new switch as well. Got it yesterday (or was it the day before). I'm going to do it, what's the worse that can happen? :rofl:

ivanjt
12-01-2011, 12:33 PM
You are correct indeed, my friend! LOL Thanks for the encouragement. I've been delaying this for so long. I even ordered this new switch as well. Got it yesterday (or was it the day before). I'm going to do it, what's the worse that can happen? :rofl:
The worse thing is that you use too much solder and bridge contacts, but that can be cleaned up.

In fact you have really nothing to loose and everything to gain.

I don't know if you can get hold of an old circuit board but if you can then try unsoldering the components on it to give you some idea as to what is involved - we tend to use defunct PC power supplies here for practice.