Welcome! Log In Create A New Profile

Advanced

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

Posted by petergunn 
Re: LCD screen for your dockstar (cheap! <$5)
April 22, 2012 06:36AM
Hi rotidude,

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

superelchi
Re: LCD screen for your dockstar (cheap! <$5)
April 22, 2012 06:42PM
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
ax206term
Re: LCD screen for your dockstar (cheap! <$5)
April 23, 2012 06:13AM
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
        }
    }	
Re: LCD screen for your dockstar (cheap! <$5)
April 23, 2012 06:26AM
FYI: new version (0.205) in svn. Firmware now works with dpflib 0.1alpha. No more segfaults.

superelchi
Re: LCD screen for your dockstar (cheap! <$5)
April 23, 2012 06:56PM
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 06:56PM by petergunn.
Re: LCD screen for your dockstar (cheap! <$5)
April 24, 2012 01:31AM
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
ax206term
Re: LCD screen for your dockstar (cheap! <$5)
April 24, 2012 08:05AM
~/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.
Re: LCD screen for your dockstar (cheap! <$5)
April 24, 2012 06:37PM
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 06:38PM by petergunn.
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 12:55AM
>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
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 01:03AM
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
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 02:03AM
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
ax206term
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 06:18AM
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
ax206term
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 06:34AM
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.
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 08:08AM
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
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 09:06AM
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 10:24AM by superelchi.
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 10:23AM
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 10:33AM by superelchi.
Re: LCD screen for your dockstar (cheap! <$5)
April 25, 2012 08:37PM
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 08:42PM by petergunn.
ax206term
Re: LCD screen for your dockstar (cheap! <$5)
April 26, 2012 08:01AM
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.
protocol_py
Re: LCD screen for your dockstar (cheap! <$5)
April 26, 2012 08:26AM
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.
irimi
Re: LCD screen for your dockstar (cheap! <$5)
April 27, 2012 02:47AM
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
Re: LCD screen for your dockstar (cheap! <$5)
April 27, 2012 04:01PM
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
neon
Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 01:40AM
@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"?
Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 02:17AM
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
Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 10:05AM
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
Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 10:42AM
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 10:43AM by superelchi.
Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 10:49AM
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 10:54AM by petergunn.
Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 11:20AM
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 11:45AM by petergunn.
neon
Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 01:42PM
@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. :)
ax206term
Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 07:17PM
@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.

Re: LCD screen for your dockstar (cheap! <$5)
April 28, 2012 08:23PM
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 08:24PM by petergunn.
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: