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

superelchi Wrote:
>
> BTW: got dx21334 working. Needs some polishing,
> but will be ready in a couple of days (I hope).
>
> superelchi

You are amazing! Wow,great!

superelchi Wrote:
> BTW: got dx21334 working. Needs some polishing,
> but will be ready in a couple of days (I hope).
>
> superelchi

Thank you very much. expect news

superelchi Wrote:
-------------------------------------------------------
> For example: my ax206dpf graphlcd driver for VDR
> supports up to 4 displays which can be logically
> arranged to simulate a bigger display. Say: 2 hor
> landscape x 2 vert landscape = 640 x 480 pixel or
> 4 hor portrait = 320 x 960 pixel. By assigning
> different serials and an udev rule you can make
> sure first display ist upper left, second upper
> right, or whatever.
Do you have a sample udev rule? I looked at the graphlcd ax206dpf driver, it might be possible to extend multiple displays to other userland programs like st2205term.

ax206geek Wrote:
> Do you have a sample udev rule? I looked at the
> graphlcd ax206dpf driver, it might be possible to
> extend multiple displays to other userland
> programs like st2205term.
No, sorry no working udev rule at hand. It was a request from users over at the i-have-a-dreambox forum. Never used different serials myself.
But connecting more than one display works without an udev rule. Libdpf will access the first (by linux) detected display as "USB0", second one as "USB1", etc. The only problem is, that the order of detection may change on next reboot or if a display is connected/disconnected. I would guess that the detection order can be fixed with an udev rule and different serials (anyone done this?).
Another possibilty: let udev assign each display to a device like /dev/dpf0, /dev/dpf1, etc. based on its serial. I think this is much cleaner, but we have to change libdpf for this to work...

superelchi

Okay, here we go: test firmware for the two different dx21334 dpfs.

@gabychan
Please test the firmware fw_disp_dx21334a_gabychan.zip

@C4Vette
Please test the firmware fw_disp_dx21334b_C4Vette.zip

superelchi

EDIT: deleted test fw.



Edited 1 time(s). Last edit at 06/02/2012 05:31AM by superelchi.

superelchi Wrote:
-------------------------------------------------------

> fw_disp_dx21334a_gabychan.zip


Perfect superelchi, Good Info Menu

Thank you so much

Hello,

i have a quite different question:

I did svn co of the latest version of lcd4linux, which is quite a little bit newer then the version used in dpf-ax:

1189 vs 1142.

In the newer version of lcd4linux there is also some code for DPF displays.

When i run ./configure of lcd4linux --with-plugins=DPF it starts complaining about missing libdpf/libdpf.h.

According to some googling dpflib/dpf.h should be the right one. But the question is where to put it that ./configure won't complain.

/usr/include/libdpf/libdpf.h won't work.

It's als mentioned to put dpflib.o to /usr/lib.

So my question is, did anyone succeed to compile latest lcd4linux with DPF support?

Thanks for your replies ...

and also thanks to superelchi he helped me with some DPF available in german amazon store :-)

superelchi Wrote:
-------------------------------------------------------
> Okay, here we go: test firmware for the two
> different dx21334 dpfs.
>
> @gabychan
> Please test the firmware
> fw_disp_dx21334a_gabychan.zip
>
> @C4Vette
> Please test the firmware
> fw_disp_dx21334b_C4Vette.zip
>
> superelchi

FYI. I bought a DPF from "link-delight-fr" on eBay (item 160792780280) and the "LcdIniTbl" CRC matches the one from the stock "dx21334b" firmware. I flashed the firmware that you made for C4Vette and it works. Thanks.

SUPERelchi (deserved with the capitals!), you're the best!

The FW works and I'm very happy. Thank you very much.

Ed



Edited 1 time(s). Last edit at 06/01/2012 01:58PM by C4Vette.

Tim Wrote:
-------------------------------------------------------
> FYI. I bought a DPF from "link-delight-fr" on eBay
> (item 160792780280) and the "LcdIniTbl" CRC
> matches the one from the stock "dx21334b"
> firmware. I flashed the firmware that you made for
> C4Vette and it works. Thanks.

Here is the stock firmware from my "dx21334b" compatible DPF.

zoolander Wrote:
-------------------------------------------------------
> So my question is, did anyone succeed to compile
> latest lcd4linux with DPF support?
>
I managed to find the authors of the patch, see these:
1. lcd4linux changeset
2. lcd4linux mailing list thread
3. patches
The dpf.h is renamed to libdpf.h and this patch expects to find libdpf directory inside the lcd4linux folder. In fact there are more changes to dpflib.c/dpf.h

+int dpf_copy(ADDR dst, unsigned char *src, unsigned short n)
+{
+	unsigned char *cmd = g_excmd;
+
+	cmd[6] = 0x01; // memory_write
+	cmd[7] = dst;
+	cmd[8] = dst >> 8;
+	cmd[9] = n;
+	cmd[10] = n >> 8;
+
+	return wrap_scsi(g_dpf, cmd, sizeof(g_excmd), DIR_OUT, src, n);
+}
+
+int set_screen(DPFContext *h, const unsigned char *col)
+{
+	unsigned char *cmd = g_excmd;
+
+	unsigned short len = 128 * 64;
+
+	cmd[6] = 0xff;
+	cmd[7] = col[0];
+	cmd[8] = col[1];
+	cmd[9] = len;
+	cmd[10] = len >> 8;
+
+	return wrap_scsi(h, cmd, sizeof(g_excmd), DIR_IN, 0, 0);
+}
+
+int write_screen(DPFContext *h, const unsigned char *buf, unsigned int len)
+{
+	unsigned char *cmd = g_excmd;
+	unsigned int l;
+	unsigned char factor;
+
+	if (len > 0xffff) {
+		factor = 2; l = len >> 1;
+	} else {
+		factor = 1; l = len;
+	}
+
+	cmd[6] = 0x11;
+	cmd[7] = factor;
+	cmd[8] = 0;
+	cmd[9] = l;
+	cmd[10] = l >> 8;
+
+	return wrap_scsi(h, cmd, sizeof(g_excmd), DIR_OUT,
+		(unsigned char*) buf, len);
+}
+
+
+void dpf_writefb(DPFContext *h, unsigned char *buffer)
+{
+	int len;
+
+	len = h->width * h->height * h->bpp;
+	write_screen(h, buffer, len);
+}
+
+void dpf_backlight(DPFContext *h, int on)
+{
+
+}
+

I managed to compile this version of lcd4linux by hand editing. But I think the correct way to do this is to merge the changes back to dpflib in dpf-ax.

Hello ax206term,

thanks a lot for quick reply :-)

Are the any plans to merge this changes back in future?

And just for some basic understanding ... I applied the patch you mentioned to lcd4linux and compared the libdpf.h with the original one ... there are quite some more changes or?

diff libdpf.h dpf.h
7a8,9
> #include "usbuser.h"
> #include "spiflash.h"
11,12c13,17
< #define MODE_USB 0x00  ///< libusb operation mode (hacked)
< #define MODE_SG  0x01  ///< generic device mode (original)
---
> #define MODE_SG     0x00  ///< generic device mode (original)
> #define MODE_USB    0x01  ///< libusb operation mode (hacked)
> #define MODE_USBHID 0x02  ///< libusb HID boot mode
>
> #define FLAG_CAN_LOCK 0x80  ///< Has the locking feature (new firmware)
21a27
>       DEVERR_UNSUPP,
24a31,48
> struct dpf_context;
> #define DPFHANDLE struct dpf_context *
>
> typedef struct {
>       int (*mem_read)(DPFHANDLE h, unsigned char *buf, ADDR offset, int len);
>       int (*mem_write)(DPFHANDLE h,
>               ADDR dst, const unsigned char *buf, unsigned short n);
>       int (*go)(DPFHANDLE h, ADDR start);
>       int (*bootstrap)(DPFHANDLE h,
>               ADDR dest, unsigned char *src, unsigned short n, ADDR start);
>       int (*flash_probe)(DPFHANDLE h, unsigned char *id);
>       int (*flash_cmd)(DPFHANDLE h, int command, int cmdlen, ADDR addr);
>       int (*flash_status)(DPFHANDLE h, uint8_t *status);
>       int (*flash_read)(DPFHANDLE h, uint8_t *buf, ADDR offset, int len);
>       int (*flash_writechunk)(DPFHANDLE h,
>               const uint8_t *buf, ADDR offset, int len);
>       int (*flash_lock)(DPFHANDLE h, char enable);
> } AccessMethods;
28a53
>       unsigned char flags;
32a58
>       AccessMethods methods;
43c69,82
< #define DPFHANDLE struct dpf_context *
---
>
> /** A value proxy for the property API */
> typedef struct dpf_proxy {
>       union {
>               short   integer;
>               char   *sequence;
>       } value;
>       char type;
> } DPFValue;
>
> enum {
>       TYPE_INTEGER,
>       TYPE_STRING,
> };
54c93,100
< /*
---
> /** Set color register
>  * \param rgb     RGB tuple */
> int dpf_setcol(DPFHANDLE h, const unsigned char *rgb);
>
> /** Blit data to screen
>  *
>  * \param buf     buffer to 16 bpp RGB 565 image data
>  * \param rect    rectangle tuple: [x0, y0, x1, y1]
56d101
< void dpf_writefb(DPFHANDLE h, unsigned char *fb);
60,63c105,109
< /*
< Turn the backlight on or off
< */
< void dpf_backlight(DPFHANDLE h, int on);
---
> /** Set property on DPF
>  * \param token       Property token
>  * \param value       Pointer to value
>  */
> int dpf_setproperty(DPFHANDLE h, int token, const DPFValue *value);
73c119
< usb_dev_handle *dpf_usb_open(void);
---
> int dpf_usb_open(int index, usb_dev_handle **u);
74a121,128
> int usb_rawread(usb_dev_handle *dev, unsigned char *buf, int len);
> int usb_rawwrite(usb_dev_handle *dev, const unsigned char *buf, int len);
> int probe(DPFHANDLE h);
>
> ////////////////////////////////////////////////////////////////////////////
> // Bootloader functionality
>
> int bl_go(DPFContext *dpf, uint16_t jmpoffset);
82,83c136,140
< int read_mem(DPFHANDLE h, unsigned char *buf, ADDR offset, int len);
< int write_mem(DPFHANDLE h, const char *hexfile);
---
> int read_mem(DPFHANDLE h, unsigned char *buf, ADDR src, unsigned short len);
> int write_mem(DPFHANDLE h,
>       ADDR dst, const unsigned char *buf, unsigned short len);
>
> int load_hexfile(DPFHANDLE h, const char *hexfile);
85a143,145
> int dpf_bootstrap(DPFHANDLE h,
>       ADDR dst, unsigned char *src, unsigned short n, ADDR start);
>
88a149
> int flash_erase_full(DPFHANDLE h);
92c153
< int load_ihx(const char *fname, unsigned char *data,
---
> int load_ihx(DPFHANDLE h, const char *fname, unsigned char *data,
108c169
< int dpf_copy(ADDR dst, unsigned char *src, unsigned short n);
---
> #define RGB565_S(r, g, b) ((RGB565_0(r, g, b) << 8) | RGB565_1(r, g, b))
110c171,173
< int set_screen(DPFHANDLE h, const unsigned char *col);
---
> int dpfcpy(ADDR dst, unsigned char *src, unsigned short n);
>
> // int clr_screen(DPFHANDLE h, const unsigned char *col);
121c184,188
< #define OFFSET_RESOLUTION 0x23   ///< w[2]:LE : Resolution X, Y
---
> // FIXME: Should be 0x0020, once we have the firmware replaced
> #define OFFSET_PROPS 0x3f0020   ///< w[2]:LE : Resolution X, Y
>
>
>

and as I see there have to be some more files in libdpf folder or?

FYI: new version 0.310 in svn.

* Support for frequency controlled backlight.
* New models:
- dx21334a
- dx21334b

@gabychan
@c4Vette
@Tim
I did some fine tuning of the brightness control. The brightness in the test firmware did not match the original brighness (much too bright). Please discard the the test firmware from my earlier post and use the attatched one.

superelchi

superelchi Wrote:
-------------------------------------------------------
> I did some fine tuning of the brightness control.
> The brightness in the test firmware did not match
> the original brighness (much too bright). Please
> discard the the test firmware from my earlier post
> and use the attatched one.

Thanks. I flashed the new firmware but the brightness control is acting weird.

1 -> 2 (gets brighter)
2 -> 3 (gets brighter, after a quick bright flash)
3 -> 4 (gets darker)
4 -> 5 (gets brighter, after a quick bright flash)
5 -> 6 (gets darker)
6 -> 7 (no change)
7 -> 8 (gets brighter)
8 -> 9 (no change)
9 -> 10 (gets darker)
10 -> 11 (no change)
11 -> 12 (gets brighter)
12 -> 13 (no change)
13 -> 14 (gets brighter)
14 -> 15 (gets brighter)
15 -> 16 (gets brighter)
16 -> 17 (gets brighter)
17 -> 18 (gets brighter)
18 -> 19 (gets darker)
19 -> 20 (no change)
20 -> 21 (no change)

The two quick bright flashes also happen when going from 6 to 5 and from 4 to 3.

Tim Wrote:
-------------------------------------------------------
>
> Thanks. I flashed the new firmware but the
> brightness control is acting weird.
>

I know. :-)

These "no change / gets darker / gets brighter" steps are the same with the original firmware (at least on my dx21334) . Seems to me that these frequence controlled backlights are not really a perfect match for the ax206.

The flashes happen only with the dpf-ax firmware. Hadn't find a cure for them until now. But its a small inconvenience, visible only on brightness changes. And - how often do you do this?

superelchi

superelchi Wrote:
-------------------------------------------------------
> The flashes happen only with the dpf-ax firmware.
> Hadn't find a cure for them until now. But its a
> small inconvenience, visible only on brightness
> changes. And - how often do you do this?

If I disable the timer before changing the per/pwm/con values and enable it afterwards then the brightness control acts almost, if not, identical to my stock firmware. I also noticed that brightness setting 20 and 21 use different per/pwm values in my stock firmware than what you use in dpf-ax.

_custom_backlighttbl::
  .db  0x00, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12
  .db  0x13, 0x14, 0x15, 0x17, 0x1b, 0x1f, 0x23, 0x27, 0x2b, 0x2d
  .db  0x3c, 0x3f
_custom_backlighttbl_len::  .db  22

_custom_backlighttbl2::
  .db  0x00, 0x03, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0a, 0x0b, 0x0b
  .db  0x0c, 0x0c, 0x0d, 0x0d, 0x0f, 0x11, 0x13, 0x15, 0x17, 0x18
  .db  0x1c, 0x1d
_custom_backlighttbl2_len::  .db  22

zoolander Wrote:
-------------------------------------------------------
> Are the any plans to merge this changes back in
> future?
>
> And just for some basic understanding ... I
> applied the patch you mentioned to lcd4linux and
> compared the libdpf.h with the original one ...
> there are quite some more changes or?
>
> and as I see there have to be some more files in
> libdpf folder or?
1. Somebody has to work through the changes and then submit the patch to dpf-ax for merging.
2. Likewise, lcd4linux has to be reworked to be consistent with these changes. I prefer the st2205 method of locating the library in /usr/local/lib rather than within lcd4linux

if test "$ST2205" = "yes"; then
   if test "$has_st2205" = "true"; then
      GRAPHIC="yes"
      DRIVERS="$DRIVERS drv_st2205.o"
      DRVLIBS="$DRVLIBS -L/usr/local/lib -lst2205"

$as_echo "#define WITH_ST2205 1" >>confdefs.h

   else
      { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: st2205.h not found: st2205 driver disabled" >&5
$as_echo "$as_me: WARNING: st2205.h not found: st2205 driver disabled" >&2;}
   fi
fi

The mplayer ax206 patch somewhere in this thread follows a similar approach.
@zoolander: Perhaps you want to take on this?

Tim Wrote:
-------------------------------------------------------
>
> If I disable the timer before changing the
> per/pwm/con values and enable it afterwards then
> the brightness control acts almost, if not,
> identical to my stock firmware. I also noticed
> that brightness setting 20 and 21 use different
> per/pwm values in my stock firmware than what you
> use in dpf-ax.
>

The original fw-dumps for dx21334a&b both had these wretched backlight tables, so I used them. Anyway, I like yours better, even if I see no real difference on my dx21334. :-)
I also added the timer disable / enable to suppress the white flashes. Had this in before but deleted it, because its not a real fix. Instead of white flashes now you have black flashes. :-o But granted, these are much harder to spot.
Fixes commited to svn.

superelchi

ax206term Wrote:
-------------------------------------------------------
> zoolander Wrote:
> --------------------------------------------------
> -----
> > Are the any plans to merge this changes back in
> > future?
> >
> > And just for some basic understanding ... I
> > applied the patch you mentioned to lcd4linux
> and
> > compared the libdpf.h with the original one ...
> > there are quite some more changes or?
> >
> > and as I see there have to be some more files
> in
> > libdpf folder or?
> 1. Somebody has to work through the changes and
> then submit the patch to dpf-ax for merging.
> 2. Likewise, lcd4linux has to be reworked to be
> consistent with these changes. I prefer the st2205
> method of locating the library in /usr/local/lib
> rather than within lcd4linux
>
> -- SNIP --

> The mplayer ax206 patch somewhere in this thread
> follows a similar approach.
> @zoolander: Perhaps you want to take on this?

I see no need to patch libdpf.

Every basic function needed to write a lcd4linux driver (or any other) is already there. Wrappers for higher level functions should definitly be done in the driver. Have a look at hackfin's lcd4linux patch (lcd4linux-svn1142-dpf.patch). It already includes the library locating code ax206term suggests.
But - as I said before: integrating dpflib in its current state into an existing project is really a mess (sorry again, hackfin). What we need is to convert libdpf to a shared library like "libdpf-ax.so". This shared lib and its headers can be installed to standard location like /usr/local/lib and /usr/local/include. Did a rough version of this a while ago, but never found the time to finish it (yet)...

Only after this is done it makes sense to think about integrating it into lcd4linux svn.

superelchi

Hello,

just wanted to confirm that the following devices are working:

Technaxx Keypix @ Amazon with firmware: coby_dp151_white

and

2.4" LCD Digital Photo/Picture Frame/Album 16MB @ ebay with firmware: focal

Thanks to all the ax-206 hackers ...

Zoolander

Hi!
I've been trying to get this to work with a screen a brought a while back but I always end up going round in circles.

http://www.dealextreme.com/p/1-5-lcd-rechargeable-digital-usb-photo-frame-keychain-white-107-picture-memory-storage-27893
Result from dmesg:

scsi 0:0:0:0: CD-ROM            buildwin  Photo Frame     1.01 PQ: 0 ANSI: 2
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 0:0:0:0: Attached scsi CD-ROM sr0
usb 1-1.2.1: reset full speed USB device number 6 using dwc_otg
usb 1-1.2.1: USB disconnect, device number 6
usb 1-1.2.1: new full speed USB device number 7 using dwc_otg
usb 1-1.2.1: New USB device found, idVendor=1908, idProduct=3318
usb 1-1.2.1: New USB device strings: Mfr=2, Product=1, SerialNumber=3
usb 1-1.2.1: Product: BL206v1.0.0
usb 1-1.2.1: Manufacturer: BUILDWIN
usb 1-1.2.1: SerialNumber: 000001
generic-usb 0003:1908:3318.0002: timeout initializing reports
generic-usb 0003:1908:3318.0002: hiddev0: USB HID v2.01 Device [BUILDWIN BL206v1.0.0] on usb-bcm2708_usb-1.2.1/input0

I've tried various ways to do this and lots of different versions of st2205 etc but there is always something which doesn't detect or compile or something.
Perhaps I just need pointing in the right direction to the current set of instructions, I just don't know. Anyway, any help would be appreciated.

I've got a dump of my firmware and I'm able to use AX206_HW_Bootflasher and ProgSPI.exe to flash it, so even a dump of some hacked firmware would probably help.

Thanks.

Looks like the same dpf I have.
I got it running with ProgSPI.exe and fw_disp_blue.bin
After flashing it should come-up with some eyes :) and a working menu.

Ed

Yeah I thought it was close. I'll see if I can generate the file (my linux install just imploded - so recovering that now).
I did manage to load it with a similar one:
"Pearl DPF hackfin portrait 0.12devel firmware.bin"
Using ProgSPI.exe. It displays "something" with the colours all wrong and I think flipped. Pressing menu, gives white screen.

So it was close, but not good enough it seems.

Thanks for the tip...been tearing my hair out trying this.

Do you have the fw_disp_blue.bin file available? That would be one less thing to mess around with.

meltwater Wrote:
-------------------------------------------------------
> Do you have the fw_disp_blue.bin file available?
> That would be one less thing to mess around with.


attached the newest fw for your display.

superelchi

Thank you!
I finally worked out that you have to select "update" from the settings menu! I now have "eyes" and menu.

Massive thanks guys, you've no idea how long I've been trying to get this working and failing.

I kept getting
sdcc: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by sdcc)
When I tried to build and couldn't find a package to fix it (building on a Raspberry Pi, which is probably half the problem).

Hello, I've got a cheap DPF from ebay (http://www.ebay.com/itm/280828187564) and I can't seem to make it work with any firmware that compiles by default in latest trunk of dpf-ax. The best result so far was that the screen flashed weirdly for a second showing what was in the display's video RAM (or somewhere else) prior to entering bootloader mode from stock firmware and then it went dark-blue/violet. I wouldn't mind some pointers as to how could I go about making the right firmware image for flashing. As far as I understand, this DPF only uses a different LCD initialization procedure than other DPFs and it needs disassembling and manually looking up memory addresses/instructions to properly initialize the screen. However, I've no idea what to change in ./src/ to make it work. Could anyone help me, please?

sairon@ntbk-ubuntu:~/dpf-ax/trunk/fw$ sudo python detect.py /dev/sg3
Opening generic SCSI device '/dev/sg3'
Manufacturer: Apple
Size        : 1 MB

sairon@ntbk-ubuntu:~/dpf-ax/trunk/fw$ sudo python identify.py full.bin
Looking for firmware.............: Found (buildwin, 128x128 px).
Looking for known version info...: None.
Looking for Openwin..............:
OpenWin        at 0x1280 (0x0006a0), len 0x3c, CRC = 0xfa7b6f9c
Written to openwin_tmp.bin.
Looking for LcdIniTbl............:
Module 37:
LcdInit !NOTBL! at 0x1330 (0x048800)
Module 51:
LcdScheduleTbl  at 0x156d (0x04a1ad), len 0x00
Invalid LcdIniTbl!
None.
WARNING: This is no "standard" buildwin software!
Looking for known signatures.....:
None.

Sorry, no matching dpf found.

Here's the stock firmware:
http://dl.dropbox.com/u/62238161/dpf_ebay_abeyerr_fulldump.bin
And some info that SPI Programmer spit out:
http://dl.dropbox.com/u/62238161/spiprog_log.txt

I've also dd'd the jump table from stock firmware from offset 0x80 to 0x220 in case it'll be needed.

sairon@ntbk-ubuntu:~/dpf-ax/trunk$ hexdump -C tbl.bin 
00000000  50 72 6f 63 54 62 6c 33  0b 30 0b b1 1c 06 00 00  |ProcTbl3.0......|
00000010  0b 2a 0d 27 dc 06 00 00  0b 2a 0c e7 dc 08 00 00  |.*.'.....*......|
00000020  0b 2a 0d 18 9a 0a 00 00  0e 00 0e 7c 88 0c 00 00  |.*.........|....|
00000030  0b 2a 0c 9c 04 0d 00 00  0b 2a 0c 65 08 12 00 00  |.*.......*.e....|
00000040  0b 30 0d fd 44 13 00 00  0c 80 10 a2 12 16 00 00  |.0..D...........|
00000050  0b 30 0c b5 34 1a 00 00  0b 30 0f 61 ba 1b 00 00  |.0..4....0.a....|
00000060  0b 30 0c 53 ec 1f 00 00  0b 30 0f c6 2c 23 00 00  |.0.S.....0..,#..|
00000070  0b 30 0e 67 c2 27 00 00  0b 30 0c 55 5c 2c 00 00  |.0.g.'...0.U\,..|
00000080  0b 30 0b 5d 82 2d 00 00  0b 30 0d 45 b0 2d 00 00  |.0.].-...0.E.-..|
00000090  0b 30 0f 84 64 30 00 00  0b 30 0f cf b8 34 00 00  |.0..d0...0...4..|
000000a0  0b 30 0e 66 58 39 00 00  0b 30 0f b4 8e 3c 00 00  |.0.fX9...0...<..|
000000b0  0b 30 0f ca 12 41 00 00  0b 30 0e f4 ac 45 00 00  |.0...A...0...E..|
000000c0  0b 30 0f 92 70 49 00 00  0b 30 0f 46 d2 4d 00 00  |.0..pI...0.F.M..|
000000d0  0b 30 0f 11 e8 51 00 00  0b 30 0d bb ca 55 00 00  |.0...Q...0...U..|
000000e0  0b 30 10 fa 56 58 00 00  0b 30 10 63 20 5e 00 00  |.0..VX...0.c ^..|
000000f0  0b 30 0d 71 54 63 00 00  0b 30 10 4d 96 65 00 00  |.0.qTc...0.M.e..|
00000100  0b 30 0e 2f ce 6c 00 00  0b 30 0e 2b ce 6f 00 00  |.0./.l...0.+.o..|
00000110  0b 30 0e b3 ca 72 00 00  0b 30 0e 55 4e 76 00 00  |.0...r...0.UNv..|
00000120  0b 30 0f 79 74 79 00 00  0b 30 0f be 00 88 04 00  |.0.yty...0......|
00000130  0b 30 0b bb 26 8e 04 00  0b 30 0b 62 8e 8c 04 00  |.0..&....0.b....|
00000140  0b 30 0b 90 c0 8c 04 00  0b 30 0c 35 20 8d 04 00  |.0.......0.5 ...|
00000150  0b 30 0c 91 fa 2a 00 00  0b 30 10 ec b2 8e 04 00  |.0...*...0......|
00000160  0b 30 0c 50 6e 94 04 00  0b 30 0e 8c 8e 95 04 00  |.0.Pn....0......|
00000170  0b 30 10 13 ea 98 04 00  0b 30 0c d2 ce 9d 04 00  |.0.......0......|
00000180  0b 30 0d 4b 10 21 00 00  0b 2a 0b fa 38 11 00 00  |.0.K.!...*..8...|
00000190  0b 30 0d 4a b4 6a 00 00  0b 30 0d 6e 70 9f 04 00  |.0.J.j...0.np...|
000001a0  2d 45 6e 64 54 62 6c 2d  ff ff ff ff ff ff ff ff  |-EndTbl-........|

Hi sairon,

please try attached firmware.

superelchi

Thanks superelchi, that was quick!
It woked (kind of) but the screen was too dark. I think the contrast settings are wrong or something.

I'm trying to build a new firmware from vendor's official SDK, will report back with my findings.