Ühel kenal päeval, T, 03.06.2014 kell 20:10, kirjutas Joe Burmeister: > yer!!! \o/ > > I'll add your firmware to the others. > > I take it this is still with the 3.0 kernel? > Can you humour me and try 3.4 with the suspend and Android stuff removed? > It is works with Android without the untested Android and suspend stuff, > I'll just drop them, and I don't have the guilt of carry code I've not > tested. > > You are welcome and thank you for working it through with me. Not only > have a got another firmware out of it but the tools are improved. :-)
Could you please add a page to Linux-sunxi wiki about this driver? Just a stub would suffice that would mention the repository, tools and where to download the firmware blobs. Thanks :) > Joe > > > On 03/06/14 19:38, eynstyn...@gmail.com wrote: > > Great news! > > > > It works! Backwards... Basically the board was the 3rd in that list > > (INET_66V), but that's an easy fix in the script.bin with the x y order. > > > > Here's the firmware for 420TPC: > > https://www.dropbox.com/s/7fz9i74l8rp70pk/420TPC.fw > > > > Thank you for this amazing tool and driver port! > > Stay tuned as I'll be dd'ing an SDCARD image very soon once other drivers > > sorted out and distro deemed ready. > > > > > > On Tuesday, 3 June 2014 14:08:38 UTC-4, eynst...@gmail.com wrote: > >> Full dmesg of TPC now: > >> https://www.dropbox.com/s/m9bv990gcjzn6rt/dmesg.txt > >> > >> So after you cut the fw, 14 blocks? Hmmm, this is almost a go. > >> I'll try out fw_extractor and fw_info again and see which file makes it > >> work. Other source code I've seen needs firmware + config. > >> > >> The 3.4 kernel continued to bug out and state i2c not idle so scrapped it > >> and went 3.0.76. Interesting is that enabling/disabling early_suspend in > >> this kernel doesn't make much difference other than the fact that > >> early_suspend had in the past corrupted many of my SDCARDs! This kernel > >> seems to behave well and load android/linux compiled drivers no problem. > >> 8188eu wifi is messed, but that's another story and different prob. > >> > >> Compiled the driver and it registered an input device! > >> After that, it went on to the firmware download process, lagged a bit > >> because of the large file being passed (wrong firmware) and I am betting > >> if the right file is passed this will work and should see output with "cat > >> /dev/input/event3" > >> > >> The original script.bin contained other touch firmware ctp names. > >> In android, the init basically loads all those drivers until the right one > >> just works. The inet_ctp module does nothing more than check for the right > >> ctp_name because the gslx680 was ctp12_name in the script.bin and it's > >> usually just ctp_name. inet_ctp isn't needed, it doesn't contain any > >> firmware. > >> > >> > >> On Tuesday, 3 June 2014 07:42:23 UTC-4, Joe Burmeister wrote: > >>> Input, nom nom nom! > >>> > >>> > >>> > >>> I cut by {0x7c,0xFFFFFF16} termination I get 14 blocks. > >>> > >>> > >>> > >>> Which is interesting because doing "strings" on your android driver I see: > >>> > >>> > >>> > >>> Downlaod GSL1680E_FW_86VS_INET > >>> > >>> Downlaod GSL1680E_FW_86VSH_INET > >>> > >>> Downlaod GSL1680E_FW_66V_M4302_INET_V2 > >>> > >>> Downlaod GSL3680_FW_shenghexiang0072 > >>> > >>> Downlaod GSL1680D_FW_86VSH_INET > >>> > >>> Downlaod GSL1680D_FW_86VS_INET > >>> > >>> Downlaod GSLx680_FW_85V_M501V > >>> > >>> Downlaod GSL1680_FW_newdingshengwei_1 > >>> > >>> Downlaod GSLx680_FW_86FV_M728_TOPSUN_C0801 > >>> > >>> Downlaod GSLx680_FW_NEWDINGSHENGWEI_OGS_4 > >>> > >>> Downlaod GSL1680_FW_newdingshengwei_5 > >>> > >>> Downlaod GSL1680_FW_TOPSUN_OGS_G7009 > >>> > >>> Downlaod GSLX680_FW_86V_TOPSUN_OGS > >>> > >>> Downlaod GSL1680_FW_haina > >>> > >>> > >>> > >>> Which is what you listed at one point. > >>> > >>> > >>> > >>> But only two of the blocks have information that I have any information > >>> > >>> about (and that information could of course be wrong). > >>> > >>> > >>> > >>> However, if I run this new extractor against my own firmware. It cuts it > >>> > >>> up into multiple ones, only one of which has information we know. > >>> > >>> And all but one of them work on their own. So I've taken the working one > >>> > >>> that still has the known information in it. > >>> > >>> > >>> > >>> My android driver doesn't have the handy little list of the different > >>> > >>> contained firmwares though. > >>> > >>> > >>> > >>> Anyway, updated the extractor. Thank you very much. :-) > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> In your android driver 000a5f00-000b27b0 really does look like there is > >>> > >>> firmware for something. It just doesn't look like a GSLX680. > >>> > >>> > >>> > >>> I can well believe the suspend stuff shouldn't still be in there, again > >>> > >>> a left over from the port that I wasn't using. > >>> > >>> Early suspend could well be a problem. Just remove it. > >>> > >>> > >>> > >>> Joe > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On 02/06/14 18:33, eynstyn...@gmail.com wrote: > >>> > >>>> ============= Extraction of the 2 files ============== > >>>> TPC 5 point touch firmware 800x480: > >>>> https://www.dropbox.com/meta_dl/eyJzdWJfcGF0aCI6ICIiLCAidGVzdF9saW5rIjogZmFsc2UsICJzZXJ2ZXIiOiAiZGwuZHJvcGJveHVzZXJjb250ZW50LmNvbSIsICJpdGVtX2lkIjogbnVsbCwgImlzX2RpciI6IGZhbHNlLCAidGtleSI6ICIzOWRrajFjamw0MTJ1d24ifQ/AAKIoE8LVcuSgujNz0kc8Ao27eniAftE09TUtg2cpQ1WGQ?dl=1 > >>>> TPC 10 point touch firmware 1280x800: > >>>> https://www.dropbox.com/meta_dl/eyJzdWJfcGF0aCI6ICIiLCAidGVzdF9saW5rIjogZmFsc2UsICJzZXJ2ZXIiOiAiZGwuZHJvcGJveHVzZXJjb250ZW50LmNvbSIsICJpdGVtX2lkIjogbnVsbCwgImlzX2RpciI6IGZhbHNlLCAidGtleSI6ICIzNGs1ajN1MDhvZzJmc2QifQ/AAKoqqQ6bWxc0Sa-m6CO0Z4J3REyDthtO-HmK2lZusscWA?dl=1 > >>>> I do not believe there are 7 firmwares, because from my understanding a > >>>> firmware footer visually ends with many 0xFFFFFFF so if I counted > >>>> correctly, there are only 2 and the rest of the data is configuration. > >>>> After extracting just those two, I get 2 different screen resolutions > >>>> and more parameters like 10 point touch, 1280x800 for the bigger screen > >>>> of course. > >>>> The end footer in this case is 7C 00 00 00 16 FF FF FF {0x7c,0xFFFFFF16} > >>>> In a hex editor, I scanned instances of 0xC0FFA5A5 (Common object file > >>>> format) as this seems to be a marker. It does start with 0xF0 and 0x03 > >>>> but it's read in reverse so "F0 00 00 00 03 00 00 00 00 00 00 00 C0 FF > >>>> A5 A5". In the android driver when I dmesg in android not linux, the > >>>> driver looks for those bytes during the firmware download process and > >>>> outputs them to screen. > >>>> So it appears that it uses an 800x480 touch screen resolution on an LDPI > >>>> 480x272 screen resolution which is actually 1024x768 in script.bin's > >>>> screen_output_mode parameter. > >>>> By the way 3.4 removed early_suspend and 3.0.76 has it. > >>>> Could early_suspend have anything to do with this? > >>>> On Monday, 2 June 2014 11:13:35 UTC-4, Joe Burmeister wrote: > >>>>> The firmware from extractor does look too big. > >>>>> You said before you found it was multiple ones, and knew what they > >>>>> where. > >>>>> How did you do that? All I've got to go on is if the data continues to > >>>>> follows the rules for the GSLx680 register+value pairs. Writing to a > >>>>> page written to before is all I can think to go on, and that I wouldn't > >>>>> trust. > >>>>> At 0x000a5f00 there is what looks like firmware. BUT very quickly the > >>>>> register numbers are beyond 8 bit, which doesn't fit with what I thought > >>>>> we knew about the GXLx680. It also doesn't start with GSLx680's page > >>>>> control register. The GSLx680 uses a paged register scheme, with f0 > >>>>> being the page control register. So normally the first thing the > >>>>> firmware does is set the page the first page of data is for. So I'm > >>>>> wondering if what looks like a small secondary firmware isn't for the > >>>>> GSLx680. Or if the GSLx680 does unpaged registering when the register > >>>>> numbers are beyond 8bit, which is new to me. If it is firmware, we need > >>>>> to find out about it. Is it a new to us way of doing GSLx680 firmware, > >>>>> after or alongside the main firmware? Is it for a different chip > >>>>> altogether? If so, what and how do we load this firmware on it, etc etc > >>>>> etc. All of which could be pretty painful to work through. > >>>>> A data sheet for the GSLx680 could make all this so much easier! > >>>>> Let me know how your wakeup investigations go, patches are always most > >>>>> welcome. :-) > >>>>> Joe > >>>>> On 02/06/14 14:12, eynstyn...@gmail.com wrote: > >>>>>> From 420TPC running Android 4.1 > >>>>>> https://www.dropbox.com/s/ahzqp78us9vre9x/gslx680.ko > >>>>>> Interesting you mention about the build. I changed the kernel from 3.4 > >>>>>> to 3.0.76 (and there are many of them) > >>>>>> and the android drivers inet_ctp and gslx680 force modprobed without > >>>>>> kpanic. > >>>>>> The only thing is now it's no longer reporting STOP or i2c state not > >>>>>> idle, but > >>>>>> instead incomplete xfer (0x20) and incomplete xfer (0x48) right after > >>>>>> a blurb > >>>>>> ctp_init_platform_resource: tp_reset request gpio failed! > >>>>>> It however did read the script.bin parameters correctly like > >>>>>> ctp_exchange_x_y_flag etc. > >>>>>> The error 0x48 is about wakeup. Device probably didn't wake so nothing > >>>>>> got sent. > >>>>>> If this passes, then the touchscreen should be active and the > >>>>>> following incomplete xfer (0x20) <-- tons of these messages might > >>>>>> actually send legit data over the bus. I think those xfers were to > >>>>>> download the firmware. > >>>>>> So gonna enable some debugging on the i2c and pinpoint this. > >>>>>> Then if this works, try out the linux driver compilation and see how > >>>>>> it differs in output. > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
