New firmware for GSL1680

[sergk...@gmail.com]

Hello.

Could anyone share or describe the way how to extract it firmware for GSL1680 on 8" with 800x1280?

What I have - rooted Android and binaries of kenel module (driver) fw is inside.
Also I have original fw from Windows 8.1.

More technical details for Linux Guru: I need assistance of extracting from ELFfile .data segment declared their static (constant) values.

Look at the objdump

objdump -t gslx68x_ts.ko  | grep gsl_config
00000140 g     O .data    0000035c gsl_config_data_id_gsl_customer
000054a0 g     O .data    00000800 gsl_config_data_id_I81_GSL3676B_8001280_OGS_SG
00005ca0 g     O .data    00000800 gsl_config_data_id_I802_GSL3676B_8001280_OGS_SG
000064a0 g     O .data    00000800 gsl_config_data_id_I802_GSL3676B_8001280_OGS_DZ
00004ca0 g     O .data    00000800 gsl_config_data_id_I100_GSL3692_1280800_GG_SG
000044a0 g     O .data    00000800 gsl_config_data_id_I89_GSL3676B_19201200_OGS_SG
000034a0 g     O .data    00000800 gsl_config_data_id_I71_GSL1686F_1024600_PG_XLL
000024a0 g     O .data    00000800 gsl_config_data_id_I86_GSL3676B_8001280_PG_FC
00001ca0 g     O .data    00000800 gsl_config_data_id_I86_GSL3676B_8001280_OGS_SG
00002ca0 g     O .data    00000800 gsl_config_data_id_I706_GSL1686_OGS_6001024_DZ_70F2
00003ca0 g     O .data    00000800 gsl_config_data_id_I89_GSL3676B_19201200_OGS_DZ
00000ca0 g     O .data    00000800 gsl_config_data_id_I101_GSL3692_1280800_GG_FC_FC101S123
000014a0 g     O .data    00000800 gsl_config_data_id_I86_GSL3676B_8001280_PG_FC_W
000004a0 g     O .data    00000800 gsl_config_data_id_I892_GSL3676B_8001280_OGS_SG

objdump -x gslx68x_ts.ko | grep .data

I am attaching linux driver module to this message. If it is needed windows fw file - please let me know - I will send it too.
PS: Suppose this helps to have more fw for new screen!
RELOCATION RECORDS FOR [.data]:
00000040 R_386_32          gsl_config_data_id_gsl_customer
00000044 R_386_32          gsl_config_data_id_I81_GSL3676B_8001280_OGS_SG
00000048 R_386_32          gsl_config_data_id_I802_GSL3676B_8001280_OGS_SG
0000004c R_386_32          gsl_config_data_id_I802_GSL3676B_8001280_OGS_DZ
00000050 R_386_32          gsl_config_data_id_I100_GSL3692_1280800_GG_SG
00000054 R_386_32          gsl_config_data_id_I89_GSL3676B_19201200_OGS_SG
00000058 R_386_32          gsl_config_data_id_I71_GSL1686F_1024600_PG_XLL
0000005c R_386_32          gsl_config_data_id_I86_GSL3676B_8001280_PG_FC
00000060 R_386_32          gsl_config_data_id_I86_GSL3676B_8001280_OGS_SG
00000064 R_386_32          gsl_config_data_id_I706_GSL1686_OGS_6001024_DZ_70F2
00000068 R_386_32          gsl_config_data_id_I89_GSL3676B_19201200_OGS_DZ
0000006c R_386_32          gsl_config_data_id_I101_GSL3692_1280800_GG_FC_FC101S123
00000070 R_386_32          gsl_config_data_id_I86_GSL3676B_8001280_PG_FC_W
00000074 R_386_32          gsl_config_data_id_I892_GSL3676B_8001280_OGS_SG

Kind regards,
      Serge Kolotylo.

[Alexis Jeandet]

Hi,

You can do it with readelf and dd, it's not straight forward, you need to find the symbol offset(table offset + symbol ofset) and size in the file then you dump it with dd.
I made a graphical tool to make this easier:
https://hephaistos.lpp.polytechnique.fr/redmine/projects/execut/wiki
You have the choice between sources, rpm for fedora and static Win32 exe.

Best regards,
Alexis.

[Priit Laes]

On Sun, 2015-05-17 at 18:31 -0700, sergk...@gmail.com wrote:
> Hello.
>
> Could anyone share or describe the way how to extract it firmware for
> GSL1680 on 8" with 800x1280?

Did you check our wiki: http://linux-sunxi.org/GSL1680 ?

It includes link to the following repository which should have all you
need:
https://gitorious.org/gslx680-for-sunxi

> --
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
> linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Michal Suchanek]

On 18 May 2015 at 09:59, Priit Laes <pl...@plaes.org> wrote:
> On Sun, 2015-05-17 at 18:31 -0700, sergk...@gmail.com wrote:
>> Hello.
>>
>> Could anyone share or describe the way how to extract it firmware for
>> GSL1680 on 8" with 800x1280?
>
> Did you check our wiki: http://linux-sunxi.org/GSL1680 ?
>
> It includes link to the following repository which should have all you
> need:
> https://gitorious.org/gslx680-for-sunxi
>

That unfortunately somehow does not work for me but reportedly it does
work for some people.

Regarding firmware extraction - some newer drivers print a message in
dmesg which firmware they loaded so that might be hint which one to
try first.

Thanks

Michal

[sergk...@gmail.com]

"Given extracted firmware from an Android driver for a 7inch A13 tablet."
Thanks, I will try this https://code.google.com/p/yuandao-n90-window-dual-core-2/source/browse/drivers/input/touchscreen/gslx680_ts.h
BUT
in my case it is Chuwi vi8 super Baytrail tablet with 8" screen size 1280x800.
Som I am not sure that this is exactly what I need.

[sergk...@gmail.com]

"Regarding firmware extraction - some newer drivers print a message in
dmesg which firmware they loaded so that might be hint which one to
try first.

Thanks

Michal

"

Thanks but unfortunately in my case there is nothing in dmesg besides fw_loading and fw_loaded, also fw is not loaded from external file it is builtin in .ko file.

[raste...@gmail.com]

Check if you have the i2c tools in your android system, and try to use them to dump the firmware from the running chip. You should be able to do it by reading registers 00 to 7F for each 128-byte block, and writting in register 0xF0 the page you want to read.

[sergk...@gmail.com]

Thanks,

Am I understand right  - all I need - it is just open .ko file, jumb to symbols page and choose needed variable (4ex:  GSLX680_FW_I81_GSL3676B_8001280_OGS_SG) and choose "export to binary" and as result I will get my firmware?
In that case  = declarations exists in .rodata and .data. ;-) of course I will try both, but would like to understand = which is correct.

Regards,
       Serge.

[sergk...@gmail.com]

Could you please explain more detailed this portion by reading registers 00 to 7F for each 128-byte block.

Questions:

1) Does it enough only one 128-byte block?
2) How to determine how much such 128byte blocks should be read and where is the finish?

[Sergio Costas]

I would read all the 256 pages, and dump all them to my chip.

-- 
Nos leemos
		         RASTER    (Linux user #228804)
ras...@rastersoft.com              http://www.rastersoft.com

[sergk...@gmail.com]

To ALL:

Could anyone share binary static linked i2c tools for Baytrail x86 (i386) Android? If I understand right simply PC-i386/i686 i2c-tool package will not work?

On Monday, May 18, 2015 at 11:52:13 AM UTC+3, raste...@gmail.com wrote:

[Michal Suchanek]

On 18 May 2015 at 11:15, <sergk...@gmail.com> wrote:
> To ALL:
>
> Could anyone share binary static linked i2c tools for Baytrail x86 (i386)
> Android? If I understand right simply PC-i386/i686 i2c-tool package will not
> work?

You can try but most likely you will have to rebuild i2c tools
statically. There is some crunchgen or what it's called BSD tool which
converts dynamic binaries to static but I am not sure how much BSD
specific it is. Never tried it on Linux.

Thanks

Michal

[Michal Suchanek]

Hello,

On 18 May 2015 at 10:49, <raste...@gmail.com> wrote:
> Check if you have the i2c tools in your android system, and try to use them to dump the firmware from the running chip. You should be able to do it by reading registers 00 to 7F for each 128-byte block, and writting in register 0xF0 the page you want to read.

Is there no special support needed in the kernel for reading the i2c
from userspace?

There is also that annoyance that some kernels protect i2c addresses
taken by a kernel driver form userspace access even when the userspace
access is in general enabled.

I guess I will try to dump the registers and compare to the firmware
blobs on the tablets I have.

Connecting directly to the i2c bus on the PCB might not be quite nice
on anything other than A13 since both the SoC and the Silead chip have
no externally visible pins so figuring out where the i2c is might be
quite difficult.

Thanks

Michal

[sergk...@gmail.com]

1 more moment regarding extracting FW:

1st - really THANKS for such great visual tool!

2nd, ;-) I would like to share with community the way how to do extracting with just simple linux tools (my experience), so

what we have - we have module .ko file.
and any Linux console
1) Lets look which type it is with file -s
file -s gslx68x_ts.ko
gslx68x_ts.ko: ELF 32-bit LSB  relocatable, Intel 80386, version 1 (SYSV), BuildID[sha1]=bd38533d698d51d8e343010888638c68ed28fd92, not stripped

2) Sounds good - from now our toolset are: objdump and readelf.

3) Lets guess constant names - for example lets use strings gslx68x_ts.ko | less
as result we have seen strings with prefix  GSLX680_FW
thats definitely what we are looking for!
4) From 2 we remember that we need to analyze elf file.
Briefly - usually constants and static vars are resided in .rodata section and .data section of the elf. Constants usually in .rodata.
5) Lets exam if it is so - I just used objdump -x  gslx68x_ts.ko | grep GSL - this means to read all headers of the  sections and display what is inside.
as result we see that all GSLX680 vars are resided inside .rodata
 the final step = just extract their binary values.
what we do next
6) take the segment .rodata start adress inside our module .ko file
readelf -e gslx68x_ts.ko or the same readelf -h -l -S gslx68x_ts.ko   - look into 5th column (offset of this segment inside .ko file) and for row .rodata
ot the same even more simple objdump -h ./gslx68x_ts.ko   - column "File"
7) Than, open .ko in any hex editor and jump to segment start adress  - as result you will see the 1st byte of .rodata segment  = 0000c8a0   (remember this value is like 0 = begining of the segment!)
 8 .rodata       000866f0  00000000  00000000  0000c8a0  2**5

8) from the symbol table determine the offset of the var inside segment readelf -s ./gslx68x_ts.ko  | grep FW

61: 0000b840 37224 OBJECT  LOCAL  DEFAULT   13 GSLX680_FW_I81_GSL3676B_8

We need 2nd and 3rd column. 2 = offset=0000b840 inside segment of the var value, 3d = length in bytes of the var = 37224
So begining of the var will be (start inside .ko file) from the such hex: 0000c8a0 (segment adress inside .ko) + 0000b840 (variable offset inside segment) = 180e0 (total adress of the begining of var inside .ko) -
9) So to grab var  = just jump to the 180e0 and copy from there 37224 bytes. or you could  for example using dd or dd rescue instead hex editor.

this portion (9) howto use dd and ddrescue is well documented, so I will not detalize it.

Regards,
       Serge Kolotylo.

                       


On Monday, May 18, 2015 at 9:46:55 AM UTC+3, Alexis Jeandet wrote:

[sergk...@gmail.com]

:( Unfortunately still no success. I have grabbed from .module ko from .rodata binaries for
GSLX680_FW_TEST
GSLX680_FW_gsl_customer
GSLX680_FW_I81_GSL3676B_8001280_OGS_SG
GSLX680_FW_I802_GSL3676B_8001280_OGS_SG
GSLX680_FW_I802_GSL3676B_8001280_OGS_DZ
GSLX680_FW_I100_GSL3692_1280800_GG_SG
GSLX680_FW_I89_GSL3676B_19201200_OGS_SG
GSLX680_FW_I71_GSL1686F_1024600_PG_XLL
FW_I89_GSL3676B_19201200_OGS_DZ
GSLX680_FW_I86_GSL3676B_8001280_PG_FC_W

and have tried each of them  - there is no required resolution 1280x800 from chip! in .ko file there are some other portions of data like

gsl_config_data_id_I81_GSL3676B_8001280_OGS_SG
gsl_config_data_id_I802_GSL3676B_8001280_OGS_SG
gsl_config_data_id_I802_GSL3676B_8001280_OGS_DZ
gsl_config_data_id_I100_GSL3692_1280800_GG_SG
gsl_config_data_id_I89_GSL3676B_19201200_OGS_SG
gsl_config_data_id_I71_GSL1686F_1024600_PG_XLL
gsl_config_data_id_I86_GSL3676B_8001280_PG_FC
gsl_config_data_id_I86_GSL3676B_8001280_OGS_SG
gsl_config_data_id_I706_GSL1686_OGS_6001024_DZ_70F2
gsl_config_data_id_I89_GSL3676B_19201200_OGS_DZ
gsl_config_data_id_I101_GSL3692_1280800_GG_FC_FC101S123
gsl_config_data_id_I86_GSL3676B_8001280_PG_FC_W
gsl_config_data_id_I892_GSL3676B_8001280_OGS_SG
gsl_alg_id_main

Looks like it is matter to do something before sending FW or in such data structure inside linux module it is not complete FW.
FW from https://code.google.com/p/yuandao-n90-window-dual-core-2/source/browse/drivers/input/touchscreen/gslx680_ts.h  on my Chuwi vi8 super (8" 1280x800) also does not work, completely even no reaction :(

So assuming - could anyone help to move forward with the following:

Question 1) from mentioned above yundao FW in text form there are comments to some values in FW - it is possible to fix existing FW, that for example sends 1725x1200 coordinates  just with correction some portions of this FW?

Question 2): Statically linked binary i2cdump for Android x86    =  I think, that my farther steps will be in direction pointed by Sergio Costas - I will try to grab under Android loaded into chip FW with i2ctools (still need statically linked  binaries for Baytrail x86 Android).

Question 3) I have Windows 8.1 too on my tablet and have firmware file from my tablet Silead.fw. It is able to load it, but still the same problem - resolution ot touch is not 1280x800 instead chip returns on this FW somthing like 1725x1120
looks like it is not enough to have just file with FW, you should correctly load it :( but what to do as init  - it is still a question

[sergk...@gmail.com]

Sergio,
Please help to make it clear - the logic of gsl1680 FW:

Is it organized in chunks of 128 byte? and if so - does it mean that current firmware = you should switch to the correct block of 128 byte between loaded set of such 128 byte blocks?

[Michal Suchanek]

Hello,

On 19 May 2015 at 09:37, <sergk...@gmail.com> wrote:
> Sergio,
> Please help to make it clear - the logic of gsl1680 FW:
>
> Is it organized in chunks of 128 byte? and if so - does it mean that current
> firmware = you should switch to the correct block of 128 byte between loaded
> set of such 128 byte blocks?

The firmware is some random data that is sent over i2c and written to
the GSL configuration registers.

Some of the earlier modules had full i2c communication dump in the
form of 1-byte address 1-integer data.

Some had part of this dump with some values (like screen resolution)
computed dynamically and not stored in the firmware dump.

It seems that the configuration registers are organized in pages and
writing a particular register switches the accessible page.

Obviously, if you have a dump like this it can contain the writes to
page change register and contain multiple configuration pages in one
blob.

There is even a GSL datasheet that explains the details of the
protocol. It does not explain the content of the configuration area,
however.

Also see http://linux-sunxi.org/GSL1680

HTH

Michal

[sergk...@gmail.com]

Sorry but your post makes it more weird.
According https://linux-sunxi.org/GSL1680 page GSL1680 controller stores Firmware in 0x00-0x7F: these registers are used to load portions of the firmware
This is only 128 8bit = 1byte registers. 
So main question is - does this registers = 128 1 byte registers store the whole firmware?

If so - then why firmware files for example from Windows 8.1 or even extracted from mentioned above .ko file are more than 128 byte? (32KB extracted from .ko and 104KB for windows fw).

Or I missunderstand the logic, and 128 registers just used to load chunks of the firmware into RAM and through this registers there is iteraction with firmware code resided in RAM?

What is the logic of working of controller chip with firmware?

For example = why when I am loading firmware Silead.fw taken from my tablet from Windows 8.1  with ported Sergio Costas user space driver for GSL1680 I could not!!!! get correct feedback (coordinates that are read from 0x84-0x87 ) for my 1280x800 touch? I have response for all but not 1280x800, acrtually weird coordinates like 1725x1120 or something close.

[Michal Suchanek]

On 19 May 2015 at 11:39, <sergk...@gmail.com> wrote:
> Sorry but your post makes it more weird.
> According https://linux-sunxi.org/GSL1680 page GSL1680 controller stores
> Firmware in 0x00-0x7F: these registers are used to load portions of the
> firmware
> This is only 128 8bit = 1byte registers.
> So main question is - does this registers = 128 1 byte registers store the
> whole firmware?

That's one page of the configuration which is 128 bytes or 32 integers.

Writing the page register gives access (read or write) to different pages.

So one blob might have multiple such pages or the firmware can be
composed of multiple pages stored in multiple blobs. Also there is
nothing stopping the driver writing the registers again after sending
the blob patching/adjusting some values or leaving them out from the
blob and sending them separately.

>
> What is the logic of working of controller chip with firmware?
>
> For example = why when I am loading firmware Silead.fw taken from my tablet
> from Windows 8.1 with ported Sergio Costas user space driver for GSL1680 I
> could not!!!! get correct feedback (coordinates that are read from 0x84-0x87
> ) for my 1280x800 touch? I have response for all but not 1280x800, acrtually
> weird coordinates like 1725x1120 or something close.

The logic is that with the chip configurable you can save on PCB
design because you can design traces as convenient and configure which
trace connects where in firmware. The obvious result is that without
correct configuration the chip is useless so dumb non-configurable
chips are a win when dealing with non-cooperative vendors.

Thanks

Michal

[sergk...@gmail.com]

"On Tuesday, May 19, 2015 at 12:53:43 PM UTC+3, Michal Suchanek wrote:
That's one page of the configuration which is 128 bytes or 32 integers.
Writing the page register gives access (read or write) to different pages.
So one blob might have multiple such pages or the firmware can be
composed of multiple pages stored in multiple blobs"

Still not clear - where does stored these blobs?

0x00-0x7F = 128 items 128 * x =1 byte registers. So physically chip could reside only 128 byte.
0xF0: PAGE register. Contains the memory page number currently mapped in the 0x00-0x7F registers.


What is logic of these  Page register and 0x00-0x7F registers?

Am I right that firmware is loaded into ram splitted by 128 byte pages and 0xF0 register contains a set of adressed in RAM of such 128 byte chunks?

[Michal Suchanek]

Yes, that's what the datasheet says. F0 stores a page number and each
page has different set of registers to map to 00-7F. The chip has more
memory than can be accessible through i2c at any given time due to the
i2c 1 byte address limit so it uses paging to make more data
accessible.

Thanks

Michal

[sergk...@gmail.com]

Thank you for make it clear.

;-) Lets transform this knowledge into practical result!


I have successfully compiled i2c-tools for x86 Android.
So, what is the exact command line to grab all loaded into GSL 1680 chip firmware?

i2cbus or i2cget? and how to use it , How via this toolset I could enumerate all 256 chunks of 128 bytes using information that chip resides on 0x40 I2c adress, dev is /dev/i2c-3, Page register is 0xF0 (8 bit too, so holds 256 addresses) and registers that store current 128 chunk are 0x00-0x7F

Cheers,
       Serge.

[sergk...@gmail.com]

I would like to rise up topic into the following direction: Lets try to dump currently loaded firmware for GSL1680 on Adroid.

From the theory on https://linux-sunxi.org/GSL1680

Chip is located on I2C bus on 0x040 address
Firmware is reading/writing from/into chip via set of chunks, each 128 byte.
Number of the chunk is located in the oxF0 register

"0xF0: PAGE register. Contains the memory page number currently mapped in the 0x00-0x7F registers. "

Current chunk is located inside set of registers:0x00-0x7F: these registers are used to load portions of the firmware
Im my case physical device is tablet Chuwi Vi8 super (Baytrail z2735f with 8" 1280x800) under Android 4.4.x and with GSL1680 located at /dev/i2c-4 I2C  bus.

So my question to community is - what are EXACT commands to READ currently loaded FW intro the GSL1680.


What I have tried based on Sergio Costas recommendations:

Variant 1: Using i2cset and i2cget
Step 1) Setting Page Register=number of chunk to be read, lets say I read 5th chunk

i2cset -f -y 4 0x040 0xf0 0x05 b

Step 2) Reading 128 bytes chunk( 0-127 registers)
actually I wrote script, but the main idea is read each register separately

the command for reading register data I have used:  lets say I would like to read the last 128th byte of the chunk - its address is 0x7F

i2cread -f -y 4 0x040 0x7F b

Variant 2: using i2cset and i2cdump

 Step 1) Setting Page Register=number of chunk to be read, lets say I read 5th chunk

i2cset -f -y 4 0x040 0xf0 0x05 b

Step 2) Read all chunk at once

i2cdump -f -y 4 0x040 -r 0x00-0x7F b


PROBLEMS:  Variant1: On the running Android with working touch screen very often I could NOT read via i2cget data and more over repeating reading makes NO RESULT. For example
i2cset -f -y 4 0x040 0xf0 0x05 b

i2cread -f -y 4 0x040 0x00 b - OK
i2cread -f -y 4 0x040 0x01 b - error - repeat - OK
i2cread -f -y 4 0x040 0x02 b - error -repeat - OK
i2cread -f -y 4 0x040 0x03 b - error -repeat-eror - stuch with this! :(

Variant 2:
         On the running Android with working touch screen
on the step2 = i2cdump -f -y 4 0x040 -r 0x00-0x7F b   
it returns portion of data but on the screen there are many XX bytes  (byte with value XX)- that I do not even know what it is - is it not able to read or something like forced conversion non displayed  hex value to displaying symbols inside i2cdump during outputing to terminal?


So ASSUMING: Is these variants correct? May be it should be done in another way? Why there are such problems and how to read existing loaded FW?  - I need to dump it all.

[Michal Suchanek]

Hello,

On 20 May 2015 at 10:55, <sergk...@gmail.com> wrote:

> i2cdump -f -y 4 0x040 -r 0x00-0x7F b
>
>
> PROBLEMS: Variant1: On the running Android with working touch screen very
> often I could NOT read via i2cget data and more over repeating reading makes
> NO RESULT. For example
> i2cset -f -y 4 0x040 0xf0 0x05 b
>
> i2cread -f -y 4 0x040 0x00 b - OK
> i2cread -f -y 4 0x040 0x01 b - error - repeat - OK
> i2cread -f -y 4 0x040 0x02 b - error -repeat - OK
> i2cread -f -y 4 0x040 0x03 b - error -repeat-eror - stuch with this! :(
>
> Variant 2:
> On the running Android with working touch screen
> on the step2 = i2cdump -f -y 4 0x040 -r 0x00-0x7F b
> it returns portion of data but on the screen there are many XX bytes (byte
> with value XX)- that I do not even know what it is - is it not able to read
> or something like forced conversion non displayed hex value to displaying
> symbols inside i2cdump during outputing to terminal?
>
>
> So ASSUMING: Is these variants correct? May be it should be done in another
> way? Why there are such problems and how to read existing loaded FW? - I
> need to dump it all.
>

For some reason the values are set in 4byte chunks (32bit integers) so
maybe try reading integers rather than bytes. Unfortunately, i2cget
does not seem to support 32bit values.

Thanks

Michal

[sergk...@gmail.com]

Ok,
So fresh news and summary.

Many many thanks to Sergio Costas for his work and assistance. He wrote and published FW extractor. I suppose it will be useful for someone trying to make it works GSL1680.
In my case, Chuwi Vi8 super (baytrail architecture) it looks that chinese developers put in this tablet touch screen with higher resolution than display resolution.
It means that what I have extracted from .ko elf file from the begining and what I have taken from Win 8.1 Silead.fw and what I've got with Sergio Costas's extractor - all these firmwares returns weird resolution 1145x1725 (may be allittle mistake ;-) due my fingers, but I think that I note it as correctly as I can).
So, in case for Chuwi Vi8 super, baytrail architecture - the solution is still the same - add rescaling correlation to Sergio Costa's user space driver.

Also I have not yet analyzed all working firmware files that I have but for me it looks weird that different size firmware works in the same manner. (in case of user space driver it is important the size of FW because the more it is the more its time consuming for loading it).

It will be good to disassemble firmware for GSL1680 to understand what is it, I saw in some variants of firmware some comments to some portion of bytes (unfortunately in weird char layouts, probably chinese or closely).

With best regards,
                   Serge Kolotylo.