As some people avoid to get bored over christmas holidays, they tend to analyze presents like those cheap hongkong digital picture frames (DPF) that you normally give to your children so that they can lose it the next day.
Of course, other people always have kind of a similar idea, so it is not surprising that there are web pages describing internals of those undocumented devices.
However, the device I got is using another chip (AX206) than the already exploited st2205 based DPFs.
Since the AX206 has a 8051 instruction set, I had a sneak peak with my d52 disassembler. And it turned out, it was possible to have my own code run on the frame, without actually knowing anything about the environment. To access the internal flash, there are various tools listed at the site linked below. The DPF emulates a mass storage device over USB, vendor specific commands are used to do the standard SPI flash operations. The AX206 seems a powerful chip, and we were actually thinking on using it on a project, however there were too many unanswered open questions and the mass price (30k units) was not competitive considering the puzzling support. If a company buries a simple 8052 controller behind NDAs, the suspicion may arise that the chip has too many bugs.
Hacking a more or less unused vendor specific SCSI command in the DPF, I was able to make lcd4linux work with it:
Find more information on this Wiki:
http://picframe.spritesserver.nl/wiki/index.php/DPF_with_AppoTech_AX206
Here a updated release of some tools to hack the above DPFs:
http://localhost/files/dpfhack-0.1alpha.tgz
Here’s the patch and build script to make lcd4linux run with a hacked frame:
http://localhost/files/dpf-lcd4linux.tgz
Hi I have a micca 2.4 device that I think is AX206 based. I got it from Amazon:
http://www.amazon.com/Micca-2-4-Inch-Portable-Wallet-Style-Rechargeable/dp/B0044LYJ8A
hackit.py doesnt find a hack but outputs a hint for profiles.py
(‘20090504’, ‘Jun 08 2010\xff\xff\xff\xff\xff’, ‘ProcTbl5’ )
What is the process of creating a hack for this new device?
-PG
You might try starting from the “pearl” entry in the profiles.py. Could be that it is a very similar firmware, but just another build date. The patching procedure will do a CRC32 check before patching, so there is no immediate danger of bricking the DPF.
[…] […]
Hi hackfin,
could you perhaps publish some details on howto get the needed information to add some “new” entries in the profiles.py for AX206 based picture frames that are not yet supported by the current entries.
I’m asking because I just got two AX206 pic frames from Dealextreme. One was hackable right from the start, but the other was not suported. I added the version information in the profiles.py, but I don’t know about the patch entry and the address.
So, some help would be highly appreciated, if you have the time. If not, no problem at all. Would just be nice.
Thank you very much in advance!
Greets
Ingmar
worked fine for my first AX206 display but the second (same brand) will not work right.
The 2. will not display the thinks right when in developer mode
the 1-5rows are in a random color red ore orange in row 10 for example is showing right if there ist someting. but if there is someting with refresh is showning from lcd4linux the display reboots or shows just a plane color at all.
is it possible to reflash again or restore with the firmeware from the working one?
Hi,
I have analyzed a few DPF’s hardware, it seems that there are various sorts of displays that aren’t really compatible to each other.
So, in order to make a proper hack, I guess one has to detect the display controller used. In your second, non working case, it seems that the display has a different color mapping? Can you make a picture of the false display?
It is very much advised to NOT copy firmware from one to another DPF, unless they are verified to have the same hardware.
the two DPFs are 1:1 the same
the working DPF one: http://img836.imageshack.us/f/dsc00906v.jpg/
the serond DPF: http://img819.imageshack.us/f/dsc00908v.jpg/
shows the clock working some seconds an then it crashes
to that: http://img225.imageshack.us/f/dsc00907p.jpg/
so i think the firmeware itself could be the Problem
as i see that the battery in the second display is dead so maby it crashed after flashing. i don’t know. the firmeware in the second didn’t work right in some ways for example: on power off in the DPF menu it opens pc connection and didn’t power off. and if the display is unused and not connected to pc but pluged to usb and should because it is unused power off it connects to pc… so i think the firmeware itselfe ist not ok
and i think an restore with the working firmware will be a way. But without JTAG?
ok some more images about the Hardware:
http://img822.imageshack.us/i/dsc00915f.jpg/
u4
AX203
http://img339.imageshack.us/f/dsc00919z.jpg/
Can you do a dump of the flash with the fulldump.py script and compare it against the working one?
The false power off functionality is a feature of this hack, when USB is connected. So it will only power off right without USB connection.
You don’t need JTAG to recover, possibly, a BusPirate or another SPI programming tool can do the job. But if you can still access the flash (fulldump.py), you can at least restore the patched sectors. Just don’t touch sector 1, or you’ll have to reprogram the flash externally.
Someone is working on a firmware replacement that should allow full reflashing in future.
As i see i can access the damaged one and dump it with fulldump.py
but the working one will not got to CD-ROM scsi mode so fulldump.py cannot find something. the funny part ist the damaged one knows both modes.
The “working” one will only go back to CDROM mode after you press the reset button, because it never turns completely off when the battery is ok. In the other case, it will be in “non developer” state when you turn it on, as it will fully lose power when unplugged. Does this assumption make sense?
BTW, to access the DPF in developer mode, you have to run “python fulldump.py usb0” instead specifying the /dev/sg device.
I’m getting some errors when compiling the src code.
make:
asx8051 -olsxffg cmdhandler.s
sdcc -o cmdhandler_14f4.ihx -Wl-bBANK0=0x1330 -Wl-gscreen_resx=128 -Wl-gscreen_resy=128 -Wl-bENTRY=0x14f4 cmdhandler.rel
sdcc -o cmdhandler_14e5.ihx -Wl-bBANK0=0x1330 -Wl-gscreen_resx=128 -Wl-gscreen_resy=128 -Wl-bENTRY=0x14e5 cmdhandler.rel
sdcc -o cmdhandler_big_14fb.ihx -Wl-bBANK0=0x1330 -Wl-gscreen_resx=320 -Wl-gscreen_resy=240 -Wl-bENTRY=0x14fb cmdhandler.rel
make: *** Keine Regel vorhanden, um das Target »app_clr.ihx«,
benötigt von »all«, zu erstellen. Schluss.
and then when I do:
sudo python fulldump.py /dev/sg7
I get:
ImportError: No module named dpf
whats wrong?
Using the pearl- dpf with ubuntu maverick 10.10
Hi,
just remove app_clr.ihx from the Makefile rules, it is not needed.
Thank you for your help.
Hack worked now. But when trying to do make of lcd4linux:
build-dpf-lcd4linux.sh src/dpflib/
I get the following error:
checking which drivers to compile… configure: error: Unknown driver ‘DPF’
any idea?
Stefan: perhaps the patching failed. You’ll have to debug this yourself, we can’t provide support for compiling lcd4linux. Best is if you start from a clean directory and check all error messages in lcd4linux/config.log.
Thanks for publishing this hack. Just got my screen from Pearl today. But now your wiki seems to be broken (php parse error showing up).
Does your hacked firmware allow controlling the backlight (brightness, on/off)? The library function seems a bit short…
I plan to have it connected 24/7 as an info display in my kitchen. But I want to show data only after a motion detector fires. Otherwise I think the backlight will wear off too fast.
Hi Gerd,
the spriteserver wiki is someone else’s, sorry, I can’t do anything about the PHP error.
A replacement firmware (being worked on for the Pearl type DPF) will also allow backlight control, and some screen saving options – although it is not necessary to really protect the LED, I have it running 24/7 as well.
Feel free to post a link to your kitchen project, always keen on seeing something about intelligent freezers 🙂
Cheers,
– Strubi
[…] diesen Chip haben und welche nicht. Später entwickelte Martin Strubl von Section5 eine Methode (hier) DPFs mit AppoTech’s AX206 Chip als Display für lcd4linux zu nutzen, allerdings ist der […]
Thx for your reply on my Blog.
I just wanted to ask, if you have any progress made in setting the brightness via lcd4linux? Is this somehow possible?
In your lcd4linux module you let this method empty 😉
Will be possible with the new firmware. Sneak peak here: http://localhost/wp/?p=77
[…] far as we can tell, Section 5′s articles on the AX206 were the first reported hacks of this new generation of DPF. Kudos! Their direction is in use […]