LCD screen for your dockstar (cheap! <$5)

Hi rotidude,

commited your patch to svn (renamed it to delightdigi_black). Thanks!

superelchi

neon Wrote:
-------------------------------------------------------
> 1.Is there any volunteer to port st2205term to
> AX206?

I have an AX206 frame but no time right now. Porting st2205term should be quite straight forward if there is an example of how to blit some pixels from a back buffer.

-PG

I made an attempt but got stuck.
@petergunn could you explain this section of st2205term.c to me?

if (use_dpf)
    {
        char *d=f->data;
	short rect[4]; // my code
        if (ch>32 && ch<127) d+=(f->w+1)*f->h*(ch-32);
        unsigned char *rgb,*rgb_fg=rgb_colors[fg],*rgb_bg=rgb_colors[bg];
        int m,n;
        for (m=0;m<f->h;m++) { //what is m?
            unsigned char *p=pixels+(y+m)*(sw+sw+sw)+x+x+x;
	    // rect[0]=  ???
	    // rect[1]=  ???
	    // rect[2]=  ???
	    // rect[3]=  ???
	
            for (n=0;n<f->w;n++) { //what is n?
                rgb=(*d++=='#')?rgb_fg:rgb_bg;
		// dpf_screen_blit(picframe,p,RGB565(*rgb,*rgb++,*rgb++),rect); my code
                /** Blit data to screen
 *
 * \param buf     buffer to 16 bpp RGB 565 image data
 * \param rect    rectangle tuple: [x0, y0, x1, y1]
 */
                *p++=*rgb++; //PG: What does this do? Red Byte?
                *p++=*rgb++; //PG: What does this do? Green Byte?
                *p++=*rgb++; //PG: What does this do? Blue byte?
            }
            d++; // skip linefeed
        }
    }	

FYI: new version (0.205) in svn. Firmware now works with dpflib 0.1alpha. No more segfaults.

superelchi

ax206term Wrote:
-------------------------------------------------------
> I made an attempt but got stuck.
> @petergunn could you explain this section of
> st2205term.c to me?
>
>

> if (use_dpf)
>     {
>         char *d=f->data;
> 	short rect[4]; // my code
>         if (ch>32 && ch<127)
> d+=(f->w+1)*f->h*(ch-32);
>         unsigned char
> *rgb,*rgb_fg=rgb_colors[fg],*rgb_bg=rgb_colors[bg]
> ;
>         int m,n;
>         for (m=0;m<f->h;m++) { //what is m?

Each font character if a rectangular array of pixels. 
m is the y-coordinate within the pixel array which ranges from 0..font height (f->h-1)

>             unsigned char
> *p=pixels+(y+m)*(sw+sw+sw)+x+x+x;
> 	    // rect[0]=  ???
> 	    // rect[1]=  ???
> 	    // rect[2]=  ???
> 	    // rect[3]=  ???

Not sure what the coordinates in rect[] are...
rect[0]=x; rect[1]=y; // x,y is top left
rect[2]=x+f->w-1; rect[3]=y+f->h-1; // bottom right

> 	
>             for (n=0;n<f->w;n++) { //what is n?
>                 rgb=(*d++=='#')?rgb_fg:rgb_bg;

m is the x-coordinate within the pixel array which ranges from 0..font width (f->w-1)


> 		//
> dpf_screen_blit(picframe,p,RGB565(*rgb,*rgb++,*rgb
> ++),rect); my code

The RGB565 would have to convert the RGB data to the right binary format for the picframe back buffer.

>                 /** Blit data to screen
>  *
>  * \param buf     buffer to 16 bpp RGB 565 image
> data
>  * \param rect    rectangle tuple: [x0, y0, x1,
> y1]
>  */
>                 *p++=*rgb++; //PG: What does this
> do? Red Byte?

Yes, copies the Red byte (0..255) - see rgb_colors[]

>                 *p++=*rgb++; //PG: What does this
> do? Green Byte?

Yes, copies the Green byte (0..255) - see rgb_colors[]

>                 *p++=*rgb++; //PG: What does this
> do? Blue byte?

Yes, copies the Blue byte (0..255) - see rgb_colors[]

>             }
>             d++; // skip linefeed
>         }
>     }	
>

You are looking in the right place - the draw_char() routine plots each character that has changed into an offscreen buffer in the dockstars memory. The buffer is later copied to the picframe (either st2205_send_data() or dlo_copy_host_bmp()).

The same approach should work for the AX206 - find an efficient way to copy a back buffer to the device, then change draw_char() to plot the chars onto the backbuffer pixel-by-pixel - plot(x+n,y+m,color(r,g,b)) - then copy the back buffer to the device.

st2205term only supports 8 colors (see rgb_colors). To be efficient you may want to convert these to a format suitable for the whatever backing store data structure suits the AX206 interface rather than converting on-the-fly.

-PG



Edited 1 time(s). Last edit at 04/23/2012 07:56PM by petergunn.

Hi ax206term,

if you need some hints how to code the backbuffer/transmission to ax206, have a look at my VDR graphlcd driver. This driver is a little complex, because it supports up to four displays, hotplugging, auto-rotation, etc. But the basic approach should be easy to grab.
Note that I did not use libdpf for this. Did some "creative copy&paste" from libdpf sources. Sorry hackifin - integrating libdpf.a into an existing project ist just a mess. Maybe someday I will get my hands dirty and clean this up...

superelchi

~/st2205term-0.10# ./st2205term --dpf
INFO: using keymap from file /root/st2205term-0.10/us.kmap
INFO: using fontdata from file /root/st2205term-0.10/fonts.txt
INFO: picframe selection automatic (polling /dev/disk/by-id)
load_kmap(/root/st2205term-0.10/us.kmap) - loading key defintions
load_kmap(/root/st2205term-0.10/us.kmap) - 71 key defintions loaded
load_font(/root/st2205term-0.10/fonts.txt,0) - loading font defintion
INFO: connecting to picframe device /dev/usb0 (/dev/bus/usb/004/021)
Opening generic SCSI device '/dev/bus/usb/004/021'
calling SCSI ioctl(): Operation not permitted
SCSI inquiry failed
WARN: failed to connect to picframe

I'm having difficulty with this chunk of code

if (picframe)
        { // we think we're connected but are we really?
            struct stat s; // stat device to see if it is still there
            int rc=stat(device,&s);
            if (rc<0)
            {
                destroy_terminal();
                dpf_close(*picframe);
                free(pixels); pixels=NULL;
                picframe=NULL;
                fprintf(stderr,"WARN: picframe disconnected\n");
            }
        }

        if (picframe==NULL)
        {
            char *dev=NULL;
            if (dev==NULL)
            {
                static char path[PATH_MAX];
                dev="/dev/usb0";
            }

            if (realpath(dev,device)==NULL)

udev rule is working. I'm not sure if it's my code or libdpf is not playing nice.

ax206term Wrote:
-------------------------------------------------------
>

> ~/st2205term-0.10# ./st2205term --dpf
> INFO: using keymap from file
> /root/st2205term-0.10/us.kmap
> INFO: using fontdata from file
> /root/st2205term-0.10/fonts.txt
> INFO: picframe selection automatic (polling
> /dev/disk/by-id)
> load_kmap(/root/st2205term-0.10/us.kmap) - loading
> key defintions
> load_kmap(/root/st2205term-0.10/us.kmap) - 71 key
> defintions loaded
> load_font(/root/st2205term-0.10/fonts.txt,0) -
> loading font defintion
> INFO: connecting to picframe device /dev/usb0
> (/dev/bus/usb/004/021)
> Opening generic SCSI device
> '/dev/bus/usb/004/021'
> calling SCSI ioctl(): Operation not permitted
> SCSI inquiry failed
> WARN: failed to connect to picframe
>

Is /dev/bus/usb/004/021 the right device for the AX206 picframe? I dont think the SCSI itoctl() messages are not coming from the st2205term code. Are they being generated by libdpf?

>
> I'm having difficulty with this chunk of code
>

> if (picframe)
>         { // we think we're connected but are we
> really?
>             struct stat s; // stat device to see
> if it is still there
>             int rc=stat(device,&s);
>             if (rc<0)
>             {
>                 destroy_terminal();
>                 dpf_close(*picframe);
>                 free(pixels); pixels=NULL;
>                 picframe=NULL;
>                 fprintf(stderr,"WARN: picframe
> disconnected\n");
>             }
>         }
> 
>         if (picframe==NULL)
>         {
>             char *dev=NULL;
>             if (dev==NULL)
>             {
>                 static char path[PATH_MAX];
>                 dev="/dev/usb0";
>             }
> 
>             if (realpath(dev,device)==NULL)
>

> udev rule is working. I'm not sure if it's my code
> or libdpf is not playing nice.

That code is for hotplugging. When the st2205 picframe was unplugged the libst2205 library didnt notice so that piece of code tried to stat the device to see if its still there (the device under /dev disappears when its unplugged). If its gone the code tried to forceably the terminal and the libst2205 API instance and resets everything. It then waits until another device is plugged in and creates a new terminal and API instance.

If libdpf wants "/dev/usb0" rather than "/dev/bus/usb/004/021" then replace take out the realpath() call and set 'device' directly i.e. strcpy(device,dev)

-PG



Edited 1 time(s). Last edit at 04/24/2012 07:38PM by petergunn.

>Is /dev/bus/usb/004/021 the right device for the AX206 picframe?

No. Its not. Libdpf uses "usb0" only as a keyword. Usb0 = first connected dpf, usb1 = second one, etc. It will search for the correct device name/number by itself. There is no device named /dev/usb0 (unless you write your own udev rule.)

superelchi

Hi,

This isn't correct:

Opening generic SCSI device '/dev/bus/usb/004/021'
calling SCSI ioctl(): Operation not permitted
SCSI inquiry failed

To access the DPF in HID or hacked mode (non-scsi device), you simply call dpf_open like:

         error = dpf_open("usb0", &dpf);

The mode the device is in will be autodetected.
If you specify a file path, it will assume it's a generic SCSI device and of course fail with the ioctls.

As another, somewhat more efficient protocol is in the pipeline (experimental), it will break compatibility if you roll your own blitting code. I'd recommend to look at the lcd4linux patches to see how the libdpf is integrated. It's rather easy, if your code is somewhat object oriented.

Cheers,

- hackfin

hackfin Wrote:
-------------------------------------------------------
>
> As another, somewhat more efficient protocol is in
> the pipeline (experimental), it will break
> compatibility if you roll your own blitting code.
> I'd recommend to look at the lcd4linux patches to
> see how the libdpf is integrated. It's rather
> easy, if your code is somewhat object oriented.
>
> Cheers,
>
> - hackfin

.. but I hope you will keep the current protocol for compatibility with - uhm - not-the-recommended-way driver implementations? Like mine :-)

superelchi

Thank you hackfin, superelchi and petergunn for your replies.

./st2205term --dpf --font=large --blink
INFO: using keymap from file /root/st2205term-0.10/us.kmap
INFO: using fontdata from file /root/st2205term-0.10/fonts.txt
INFO: picframe selection automatic (polling /dev/disk/by-id)
load_kmap(/root/st2205term-0.10/us.kmap) - loading key defintions
load_kmap(/root/st2205term-0.10/us.kmap) - 71 key defintions loaded
load_font(/root/st2205term-0.10/fonts.txt,2) - loading font defintion
Found AX206 DPF
Got LCD dimensions: 320x240
create_terminal 320x240 pixels => 40x15 chars
rote_vt_forkpty: command='/bin/bash --login' PID=-1
INFO: successfully connected to picframe
Opened device /dev/input/by-id/usb-Logitech_Logitech_USB_Keyboard-event-kbd (/dev/input/event0) => Logitech Logitech USB Keyboard

I got some rendering of the console on the dpf but I think I got the RGB565 wrong and the console isn't quite behaving.

Can somebody have a look at the code please? Did I get the dimensions for draw_char and dpf_screen_blit rect correct?



PS: This post is appearing on the dpf as I type :P

I compiled st2205term with this line for anybody who wants to try this

gcc -Wall -g -O2 -DHAVE_DPF -o st2205term st2205term.c -lrote -ldpf

librote.so and libdpf.so are in /usr/local/lib. I also copied dpf.h, spiflash.h and usbuser.h from dpf-ax to st2205term directory.

Superelchi:

>
> .. but I hope you will keep the current protocol
> for compatibility with - uhm -
> not-the-recommended-way driver implementations?
> Like mine :-)

sure, the old procotol will stay, the dpflib recognizes different types. The reason actually is, that I've been noodling kind on a remote display running on a FPGA with attached USB FIFO with a much simpler protocol (stripped down netpp). And the 'hacked' SCSI protocol is what it implies: a hack :-)
But since there are no big speedups to expect on the AX206 DPFs, I'm open to discuss whether using another protocol on this HW makes sense at all..

Cheers,

- hackfin

hackfin Wrote:
-------------------------------------------------------
> sure, the old procotol will stay, the dpflib
> recognizes different types. The reason actually
> is, that I've been noodling kind on a remote
> display running on a FPGA with attached USB FIFO
> with a much simpler protocol (stripped down
> netpp). And the 'hacked' SCSI protocol is what it
> implies: a hack :-)
> But since there are no big speedups to expect on
> the AX206 DPFs, I'm open to discuss whether using
> another protocol on this HW makes sense at all..
>
> Cheers,
>
> - hackfin

If there are no significant speedups with the new protocol, I would like to keep the existing one. Okay its a hack - but works well. And, as I learned in the last few days, there are many folks out there still using dpflib 0.1alpha to access their dpfs. :-o
So we have to support this for a looooong time...

superelchi



Edited 1 time(s). Last edit at 04/25/2012 11:24AM by superelchi.

Hi ax206term,

had a short look at your code. Some suggestions:

Line 60:

static unsigned char colormap[8]={0,0,0};

should be

static unsigned int colormap[8];

Line 278:

        unsigned char rgb,rgb_fg=colormap[fg],rgb_bg=colormap[bg];
        int m,n;
        for (m=0;m<f->h;m++) { //Each font character if a rectangular array of pixels.
//m is the y-coordinate within the pixel array which ranges from 0..font height (f->h-1)
            unsigned char *p=pixels+(y+m)*(sw+sw)+x+x;
               
            for (n=0;n<f->w;n++) {
// n is the x-coordinate within the pixel array which ranges from 0..font width (f->w-1)
                rgb=(*d++=='#')?rgb_fg:rgb_bg;
                *p++=rgb++;
                *p++=rgb++;

should be

        unsigned int rgb,rgb_fg=colormap[fg],rgb_bg=colormap[bg];
        int m,n;
        for (m=0;m<f->h;m++) { //Each font character if a rectangular array of pixels.
//m is the y-coordinate within the pixel array which ranges from 0..font height (f->h-1)
            unsigned int *p=(unsigned int *)(pixels+(y+m)*(sw+sw)+x+x);
               
            for (n=0;n<f->w;n++) {
// n is the x-coordinate within the pixel array which ranges from 0..font width (f->w-1)
                rgb=(*d++=='#')?rgb_fg:rgb_bg;
                *p++=rgb;

Line 446:

pixels=(unsigned char*)malloc(sw*sh*3);

should be

pixels=(unsigned char*)malloc(sw*sh*2);

As I said - just a short look. Maybe I'm totally wrong...

superelchi



Edited 2 time(s). Last edit at 04/25/2012 11:33AM by superelchi.

if RGB565_S() returns a 16bit value then superelchi is correct that the backingstore should not be chars. I would use shorts or ints depending on what dpf_screen_blit() expects for the type of pixels parameter...

static short *pixels=NULL; // pixel buffer that is copied to device

...
static short colormap[8]={0,0,0};
...

if (use_dpf)
    {
        char *d=f->data;
        if (ch>32 && ch<127) d+=(f->w+1)*f->h*(ch-32);
        short rgb,rgb_fg=colormap[fg],rgb_bg=colormap[bg];
        int m,n;
        for (m=0;m<f->h;m++) { //Each font character if a rectangular array of pixels.
//m is the y-coordinate within the pixel array which ranges from 0..font height (f->h-1)
            short *p=pixels+(y+m)*sw+x;
               
            for (n=0;n<f->w;n++) {
// n is the x-coordinate within the pixel array which ranges from 0..font width (f->w-1)
                rgb=(*d++=='#')?rgb_fg:rgb_bg;
                *p++=rgb++; // just one
            }
            d++; // skip linefeed
        }
    }

...

pixels=(short*)malloc(sw*sh*sizeof(short));

-PG



Edited 1 time(s). Last edit at 04/25/2012 09:42PM by petergunn.

Thanks to all those who replied.

I tried various combinations of short,int and only managed to render garbage and ASCII 'art'.

I tried ls --color and this Python code and verified that blue appeared wrong. I have no idea if I'm supposed to use RGB565_S or something else like RGB565_0, RGB565_1. This is out of my comfort zone so somebody else has to fix the color problems.

Anyway

rote_vt_forkpty: command='/bin/bash --login' PID=-1

is rote_vt_forkpty bombing out while testing on PC. Once I hooked up the dpf to the dockstar, the correct result:

./st2205term --dpf --font=large --blink --keyboard=/dev/input/event0
INFO: using keymap from file /root/st2205term-0.10/us.kmap
INFO: using fontdata from file /root/st2205term-0.10/fonts.txt
INFO: picframe selection automatic (polling /dev/disk/by-id)
load_kmap(/root/st2205term-0.10/us.kmap) - loading key defintions
load_kmap(/root/st2205term-0.10/us.kmap) - 71 key defintions loaded
load_font(/root/st2205term-0.10/fonts.txt,2) - loading font defintion
Found AX206 DPF
Got LCD dimensions: 320x240
create_terminal 320x240 pixels => 40x15 chars
rote_vt_forkpty: command='/bin/bash --login' PID=6507
INFO: successfully connected to picframe
Opened device /dev/input/event0 (/dev/input/event0) => Microsoft Microsoft® 2.4GHz Transceiver v8.0

This code works for me as I have a usable console with some colors missing but I will live with that for now.

Maybe someone else could verify this on their ax206 dpf.

superelchi Wrote:

> If there are no significant speedups with the new
> protocol, I would like to keep the existing one.
These guys also use the current protocol: pydpf and Lou Cyfer's AX206 Python Demo. I hacked Lou Cyfer's code to run in Linux.

protocol_py Wrote:
-------------------------------------------------------
> superelchi Wrote:
>
> > If there are no significant speedups with the
> new
> > protocol, I would like to keep the existing
> one.
> These guys also use the current protocol:
> pydpf

My latest version of pydpf is based on recent dpflib.a but it includes a patch (amongst others) of py_device.c to upload RGBA pictures via Python directly (based on LCD4Linux patch code) and to check the DPF's resolution. Hence it is much easier to control the DPF with Python, as you know (!?) there are several Python DPF projects. I'm already in touch with superelchi, I hope these patches will be integrated when he has time.

cheers, irimi

ax206term Wrote:
-------------------------------------------------------
> I have
> no idea if I'm supposed to use RGB565_S or
> something else like RGB565_0, RGB565_1. This is
> out of my comfort zone so somebody else has to fix
> the color problems.
RGB565_0 and RGB565_1 turned out to be correct. I suspected the typecast to unsigned char did the trick. Enough of pointer arithmetic and binary math for now.

@petergunn: I took the liberty of bumping st2205term to ver. 0.11. I hope you don't mind.

Source and binaries

@ax206term
Wouldn't be simpler just name it ax206term rather than st2205term?

I just compiled code on Debian Squeeze i386 with dpflib from v0.200, and it doesn't work. I used

gcc -Wall -g -O2 -DHAVE_DPF -o st2205term st2205term.c -lrote -ldpf

and I get

             
INFO: using keymap from file /home/st2205term-0.10/us.kmap
INFO: using fontdata from file /home/st2205term-0.10/fonts.txt
INFO: picframe selection automatic (polling /dev/disk/by-id)
load_kmap(/home/st2205term-0.10/us.kmap) - loading key defintions
load_kmap(/home/st2205term-0.10/us.kmap) - 71 key defintions loaded
load_font(/home/st2205term-0.10/fonts.txt,0) - loading font defintion
Error: No matching USB device found!
WARN: failed to connect to picframe
Error: No matching USB device found!
WARN: failed to connect to picframe

Is it because I use "alternative firmware" (fw_blue.bin) rather than "hacked original firmware"?

Hi there!

I have a Pearl DPF with a AX206 Chip and I want to use it now as a "Terminal" or even better as a "Monitor" showing a VNC connection on my Dockstar..

Is this now possible and stable or does it need further development and improvements?!
And if this is possible how do I set this up?!.

Thank you in advance but with these DPFs I am a noob not knowing where to start , what to do and which way is the optimal for obtaining my goal showing a VNC instance on the DPF or a Terminal?!

Again, Thank you in advance!
Greetings Ron

My ax206 frame (looks like a pearl) doesnt seem to be supported...

dpf/src# sudo python hackit.py /dev/sg1
Reading flash...
done
No DPF found. Create a record or look for one
('20090504', 'Mar 13 2010\xff\xff\xff\xff\xff', 'ProcTbl6')
dpf/src# cd ../../dpf-ax
dpf-ax/fw# cp ../Debug/dpf.so .
dpf-ax/fw# sudo python detect.py /dev/sg1
Opening generic SCSI device '/dev/sg1'
Manufacturer: SST
Unknown Manufacturer
Got id[3]: bf, 25, 41
Unable to detect flash, just assuming 2MB size
Size        : 2 MB
dpf-ax/fw# lsusb
Bus 001 Device 005: ID 1908:0102

Any suggestions? I'm using dpfhack-0.1alpha.tgz and current svn trunk of dpf-ax

-PG

petergunn Wrote:
-------------------------------------------------------
> My ax206 frame (looks like a pearl) doesnt seem to
> be supported...
>
> Any suggestions? I'm using dpfhack-0.1alpha.tgz
> and current svn trunk of dpf-ax
>
> -PG

Use identify.py from the current svn branch. Hackit-py / detect.py are from older releases.
You need a full fw-dump for this.

superelchi



Edited 1 time(s). Last edit at 04/28/2012 11:43AM by superelchi.

Update: I tried to create a new profiles.py entry based on the pearl one and flashed that. I think its bricked now! :-(

Update: can still see it as usb0...

dpf-ax/fw# sudo ./hiddetach 1908:3318
dpf-ax/fw# sudo python detect.py usb0
Found AX206 DPF (bootloader)
Manufacturer: SST
Unknown Manufacturer
Got id[3]: bf, 25, 41
Unable to detect flash, just assuming 2MB size
Size        : 2 MB

Anyway to unbrick? I have a full.bin firmware dump.

I do have another ax206 frame - its a Mica 2.4" ...

detect.py and fulldump.py work...

dpf-ax/fw# sudo python detect.py /dev/sg1
Opening generic SCSI device '/dev/sg1'
Manufacturer: EON
Size        : 4 MB
dpf-ax/fw# python fulldump.py /dev/sg1
Opening generic SCSI device '/dev/sg1'
Manufacturer: EON
Size        : 4 MB
Reading 400000 bytes...
Wrote full.bin

but identify.py just hangs and never completes...

dpf-ax/fw# sudo python identify.py /dev/sg1

-PG



Edited 1 time(s). Last edit at 04/28/2012 11:54AM by petergunn.

Update: tried using restore.py but no luck...

dpf-ax/fw# sudo ./hiddetach 1908:3318
Detaching dpf at 1-1.2:1.0... done.
dpf-ax/fw# sudo python restore.py ../../dpf/fw/full.bin.20120428 
Found AX206 DPF (bootloader)
Manufacturer: SST
Unknown Manufacturer
Got id[3]: bf, 25, 41
Unable to detect flash, just assuming 2MB size
Size        : 2 MB
Erase full flash...
Flashing sector 0...
Flashing sector 1...
Flashing sector 2...
...
Flashing sector 30...
Flashing sector 31...
Executing applet..

Hmmm... I see identify.py uses a fw dump rather than a device... this is the output from the original dump...

dpf-ax/fw# python identify.py ../../dpf/fw/full.bin.20120428 
Looking for buildwin firmware....: Found (320x240 px).
Looking for known version info...: None.
Looking for Openwin..............: Found.
Looking for LcdIniTbl............: Found.
Looking for known signatures.....: None.

Sorry, no matching dpf found.

Unfortuantely I dont seem to be able to reflash the old firmware. If I take a new dump after reflashing I get...

dpf-ax/fw# sudo python restore.py ../../dpf/fw/full.bin.20120428 
Found AX206 DPF (bootloader)
Manufacturer: SST
Unknown Manufacturer
Got id[3]: bf, 25, 41
Unable to detect flash, just assuming 2MB size
Size        : 2 MB
Erase full flash...
Flashing sector 0...
Flashing sector 1...
Flashing sector 2...
...
Flashing sector 29...
Flashing sector 30...
Flashing sector 31...
Executing applet..
dpf-ax/fw# sudo ./hiddetach 1908:3318
Detaching dpf at 1-1.2:1.0... done.
dpf-ax/fw# sudo python fulldump.py usb0
Found AX206 DPF (bootloader)
Manufacturer: SST
Unknown Manufacturer
Got id[3]: bf, 25, 41
Unable to detect flash, just assuming 2MB size
Size        : 2 MB
Reading 200000 bytes...
Wrote full.bin
dpf-ax/fw# python identify.py full.bin
Looking for buildwin firmware....: Not found.

This in no buildwin firmware!
Traceback (most recent call last):
  File "identify.py", line 348, in <module>
    dpf, pm = recognize_dpf(data)
TypeError: 'NoneType' object is not iterable

So flash does not seem to be uploading.. still bricked :-(

-PG



Edited 2 time(s). Last edit at 04/28/2012 12:45PM by petergunn.

@petergunn
Do you use low quality USB cable that is included with ax206 photo frame? If yes, throw it away? Never use this cheap USB cables because it may permanently damage your device.

Post here your flash dump in order that superelchi could help you.

PS. There is also Windows tool (ProgSPI.exe) which can be used for reflashing. But you need to know what kind of flash chip you have. Usually you can know it by opening the device. :)

@hackfin: Could you release your vnc client code even if it is unfinished? I would like to have a go at hacking it.

@neon: The bulk of the adaptation for ax206 for st2205term heavily borrows from the rest of st2205term code and petergunn is the author so I will defer to his preference in any name change. If he decides to keep the name, then it shall stay st2205term.

Could you list lsusb output? Do you have a udev rule getting in the way? You need ID 1908:0102 in the lsusb output.

@BigRon:
Terminal is now supported for Pearl AX206 frames through st2205term-0.11. If your pearl frame is already hacked, it is trivial to get st2205term going. Otherwise, you'll need to compile the hacked firmware from hackfin from the dpf-ax tarball from sourceforge and flash it to the frame. Once that is done, you'll need these dependencies sorted out, ref: petergunn's notes, ie librote, libdpf

apt-get install libncurses5-dev libusb-dev
wget -nd http://downloads.sourceforge.net/project/rote/rote/rote-0.2.8/rote-0.2.8.tar.gz
tar xvfz rote-0.2.8.tar.gz
cd rote-0.2.8/
./configure && make && make install
cd ..
cp dpf-ax/libdpf.so /usr/local/lib/



@petergunn: I have better experience forcing the flash size with the -f flag for restore.py. You never mentioned what the frame display is showing. That will be a helpful hint of the current state of the frame. ProgSPI is another option which neon mentioned. 


This is good news once you get the flashing problem out of the way.


Looking for buildwin firmware....: Found (320x240 px).
Looking for known version info...: None.
Looking for Openwin..............: Found.
Looking for LcdIniTbl............: Found.
Looking for known signatures.....: None.

For reading, openschemes three articles are very helpful on the inner details of the frame.

I'm going to upload the st2205term-0.11 to the st2205term page but I cant seem to connect to Jeff's ftp server right now.

Regarding code forks - I really dont mind. Until I have a working ax206 based dpf its difficult to support anyway :-)

-PG



Edited 2 time(s). Last edit at 04/28/2012 09:24PM by petergunn.