Hi BBUK,
Some serious work there.
I'd love patches thank you. I've not got much spare time to throw at
this any more, so patches are most welcome in any form.
Readelf is a really good idea, I'll have a look at that in the next few
days or so if I can find a free few hours in the evening.
Getting the right firmware for the device is nearly always the sticking
point, so anything that makes this better is a big win.
Thank you for your work, already been most helpful and that's before any
possible patches. :-)
Joe
On 31/08/14 21:09, BBUK wrote:
Dear all
I managed to get this driver and Sergio's userspace one working on an
A20 tablet (a A70x). I thought to post back with my findings.
First of all although fw_extractor does a great job, there is not a
lot of consistency in how firmwares in the Android kernel driver start
and finish and so it is natural that it is going to be misguided for
some firmwares (I found firmwares that started f0 00 00 00 97 00 00
00, f0 00 00 00 03 00 00 00 and f0 00 00 00 00 00 00 00 and I found
firmwares that ended both 7c 00 00 00 00 00 00 00 as well as 7c 00 00
00 16 ff ff ff). The most reliable way I found of identifying the
start and end of each firmware was to use "readelf -s" to extract the
lengths of the objects directly (I used "readelf -s | grep -i fw" but
bear in mind that I was running on an arm system and readelf may not
necessarily produce correct results with arm binaries on an x86 system
unless you tell it that you are dealing with an arm binary. Actually,
that might be an idea to update fw_extractor to use readelf ... hmm.
When working out which firmware to use, the gslx680 does not seem to
like being uploaded with different firmwares and will stop responding
(neither driver will, however, report any errors). It took me about
20 hours to work this out! If you try a firmware the device must be
fully switched off (a reboot is not sufficient) before trying another one.
For me, non-working firmwares just produced no output.
Fourthly, as identified earlier, the i2c incomplete xfer stuff is
caused by a recent(ish) patch to the 3.4 sunxi kernel changing the
default transfer speed to 100khz. The file to change is
arch/arm/plat-sunxi/include/plat/i2c.h (towards the end). I think the
patch should be reverted. This certainly affected Joe's driver
(kernel). I did not investigate whether the change to the default
speed was needed for Sergio's (user space) driver.
Fifthly, for Joe's driver, the previous comment about 'With A20, I
think you should remove "IRQF_TRIGGER_FALLING |"' is important.
Finally, thanks to both Joe and Sergio. Great work, saved me a bunch
of time. In passing, I identified some possibly useful changes to
both drivers, are you accepting pull requests?
Have fun
BBUK
--
You received this message because you are subscribed to a topic in the
Google Groups "linux-sunxi" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
