yashsingh1/xdaforums huggingface dataset:
[G Tablet General] fosser2:
I found the gpio enable code here. That is where I got the idea from. All its doing is enabling a gpio on boot. Thats really all it does kernel side. You can find what I referenced on lines 432-436 & 538.

I found the rest of the code in init.grouper.rc (nexus 7 init). It can be found here. Specifically on lines 211-221.
[G Tablet General] rajeevvp:
You'll need more than that bit of code to toggle the GPS GPIO line.

Those are just statements to init the GPIO from userpace--I wanted the kernel code. There should be kernel code to handle the read and writes to those files. Most likely, this will now be included along with the rest of the standard GPIO code bits. Have you merged that bit of Nexus 7 code into your kernel tree, or does that code already exist in the nVidia supplied kernel?
[G Tablet General] fosser2:
Ok I just said scrap that idea. I'm going back to the setup we had in ics. I have the gps working at kernel level and i can trigger it via echo 1 rom side. I'm just attempting to figure out why android itself won't "call" on the gps. Basically when I click Google maps or whatnot the gps doesn't turn on.

Here is the android gps lib we're using.

https://github.com/redeyedjedi/android_device_smba_common/blob/CM-10.1/libgps/gpslib.c

I believe the only thing that I'm missing is the "linker" and I'm hoping you can help with that. Thanks!
[G Tablet General] rajeevvp:
See this post.

The GPS API doesn't seem to have changed in Android 4.2. The logcat should tell us what's wrong.
[G Tablet General] fosser2:
Rajeevvp,

I have done some more digging into this.

# GPS
mkdir /data/gps
chown system system /data/gps
chmod 770 /data/gps
chown gps system /dev/ttyHS3
chmod 0664 /dev/ttyHS3

# GPS init
write /sys/class/gpio/export 171
write /sys/class/gpio/gpio171/value 0
write /sys/class/gpio/gpio171/direction out
chown gps system /sys/class/gpio/gpio171/value
chmod 0664 /sys/class/gpio/gpio171/value

That above code is actually all that is needed to control the gps power and is completely userspace. I can:

echo 1 > /sys/class/gpio/gpio171/value

and the gps will turn on. In doing this I was able to get rid of all the kernel level code (found in this commit).

https://github.com/fosser2/android-...mmit/8de057f954b23ea610de66f857bfa82ffacb8acb

Now, I also after more digging I discovered that the gps.tegra.so module was not even being built. I made the following changes and now it is being built.

https://github.com/redeyedjedi/andr...mmit/05e4ce49d18e6df34b8d19dd124d66199f1e7ccf

https://github.com/redeyedjedi/andr...mmit/da6a68d77095f5f055fb137851ec402efd6faea6

The issue that I am now having is that android is actually failing to boot so I cannot get any debugging enabled. Here is what I"m seeing on my debugger on bootup with gps.tegra.so built.

http://pastebin.com/3kCRZwQc

Thanks for the help

fosser2
[G Tablet General] rajeevvp:
So, the 3.1.x kernel has regularized the enabling or disabling of GPIO lines. This is good: no need for individual drivers to create their own (non-standard) enable/disable file in /sys now.

Those are kernel messages, and I can't determine anything wrong in them--except some process is repeatedly dying and being restarting. We need the logcat output to find out what's wrong with Android. If init is up (and it looks like it is) and if it has managed to start adbd, then adb logcat right from system boot-up should be possible.
[G Tablet General] fosser2:
I attempted to get logcat output. No luck there. For some reason it was not initialized. I'm not sure if it has something to do with how 4.2 disables adb and you have to re-enable it through the settings panel.
[G Tablet General] rajeevvp:
Doesn't 4.2 respect ro.debuggable and persist.service.adb.enable in /default.prop anymore?
[G Tablet General] fosser2:
I do have persist.service.adb.enable there. Line 65 of this file.

https://github.com/redeyedjedi/android_device_smba1002/blob/CM-10.1/device-smba1002.mk

As for ro.debuggable I will add that also. I'll see what output I can get then.
[G Tablet General] rajeevvp:
Is that making it into the /default.prop file; and is adbd also being started in one of the /init*.rc files?
[G Tablet General] fosser2:
Here is a copy of the extracted default.prop

http://pastebin.com/Q4CcDERL

From what I can tell its all there...

EDIT: I was able to get it connected. Here is an adb dump and a serial dump at the same time

ADB: https://dl.dropbox.com/u/25883802/gps_crash_log.txt

SERIAL: http://pastebin.com/MRr9kQhG

As a reminder here is the gps lib we are using https://github.com/redeyedjedi/android_device_smba_common/blob/CM-10.1/libgps/gpslib.c

EDIT2:

After more messing around...

Ok so I have the gps working on 4.2 the issue right now is with the on/off code. I used borkata's gpslib code found here. Using this code with no changes let me enable the gps. I had to manually turn the chip on via echo 1 but other than that it worked like it should have. So this leaves me to believe that the "on/off" code that you wrote has become obsolete w/ the new os and is the cause of the crash. I guess I'm attempting to figure out what we need to change to be able to once again use the chip in the latest OS. Thank you :)

EDIT3: digging through the code that you wrote. I was wondering if "gps_pfd" equaling -1 had something to do w/ the code that I set in the init.harmony.rc. Specifically I am focused on write /sys/class/gpio/gpio171/value 0. My code writes a "0" to the value file (formally known as power_on). Is that line interfering w/ what you are setting and possibly causing the crash? I did remove value 0 line from init.harmony.rc so I'm unsure of what is wrong.
[G Tablet General] rajeevvp:
That looks OK, except for the ro.secure=1 which will drop you into a non-superuser account (user: shell) when you do an adb shell. But, this won't affect log message retrieval.

Can I ask how? The output format certainly looks different.

system_server is clearly dying with a SIGSEGV for some reason. Segmentation Violations are indicative of memory errors: using uninitialized/freed memory, accessing memory outside of allocated address space, writing to read-only variables, ...

gpd_pfd just holds the file descriptor of the opened GPIO line toggle file. Plus, that variable cannot be seen outside the gpslib.c file, so it's not going to cause problems like you describe.

However, I would put back that write 0 statement in /init*.rc. Without looking at the kernel source, I don't know what the default value will be, but, best not to leave it "floating". Initialize it to 0.

To localize where the bug is, uncomment GPS_DEBUG, and put in debug statements using LOGV()/LOGE() at the beginning of all the Android interface functions. (If you don't know which these are, just put debug messages at the start of every function.) The compiler might complain about executing statements before doing variable initialization, but with modern compilers, the compilation should go through. And, for functions which already have a LOGV(), move that statement to the start of the function.
[G Tablet General] fosser2:
I booted a working rom and enabled ADB. Then I flashed the same exact rom over the top of the working one with only the gps.tegra.so added. That gave me adb access on boot like that. Its a bit of a hack way to do it but should give the same results.

The gps code that you added is causing the issue. I will attempt to add the debugging statements for the code that sets "value."
[G Tablet General] rajeevvp:
No--go belt-and-suspenders on this one. Add debug prints to all of the functions.
[G Tablet General] rajeevvp:
Simpler to just add gps.tegra.so using CWM post install, then.

What's the value of /data/property/persist.service.adb.enable?

Well, only technically. The actual reason is a lot more, er, stunning. Without going into the abstruse arcana of GCC, and linker implementation, and ELF ABI specs, at present let me just say: WTF, Google, WTF!?

The fix:

In the gpslib.c file, remove the const qualifier from the HAL_MODULE_INFO_SYM structure at the end of the file.
[G Tablet General] fosser2:
Borkata and myself actually just figured this out before I read this post to! Crazy that's what was causing the issue. I will let you know how everything is working in a day. I've been out doing lots of job interviews and it's kept me busy. As always I really appreciate your help. Thanks.

fosser2
[G Tablet General] rajeevvp:
That const qualifier business is only the proximate cause. The really dismaying thing (the ultimate cause, if you will) is how Google's violated the usually understood conventions for compile-time structures of this sort: that--barring things like linked-list implementations where you expect members of such compile-time allocated structures to be written into--they're almost always, by widespread convention, assumed to be read-only.

I wonder how many working GPS implementations have started failing in Android JB because of Google's flawed GPS HW interface library loading code, and because its linker can now walk and chew gum at the same time--ie. it now honours the compiler's request to make certain ELF data segments read-only.
[G Tablet General] fosser2:
Hey guys, for anyone that still follows this GPS thread our new DRH CM10.1 rom is live over on slatedroid. It will be posted on XDA in the next few days. It does have full gps support included (which is a first in a new rom). Thanks!
[G Tablet General] theteju:
How up to date this topic is. ?

I am using smoother bean . Is GPS working with the ROM?

Is the hardware list on the first page still the recommended?
[G Tablet General] fosser2:
GPS does not work with smoother bean. Our new CM10.1 rom does have GPS support. It will be posted on this forum in the next few days. To find it just Google " [ROM - 10.1] BETA DIRTY-BEAN 4.2.X - Team DRH (Update 02/22/13)" and it should be the first hit.
[G Tablet General] rajeevvp:
Actually, I've determined that GPS GPIO control should work on all current ROMs (using any of the 2.6.32.x, 2.6.39.x, or 3.1.10.x kernels) with the statements in post #510 and the latest native GPS HW source.

This is because the generic gpiolib code exists even in the 2.6.32.x kernel versions; and all the current kernels have been compiled with the needed config options (CONFIG_GPIOLIB, CONFIG_ARCH_REQUIRE_GPIOLIB, CONFIG_GPIO_SYSFS) to enable and use this generic gpiolib driver.

However, for kernels which already have a working gps_control driver, you'll have to disable this driver at kernel compile-time to make use of the sysfs-based generic GPIO control technique. Otherwise, the in-kernel driver will be holding onto the GPS GPIO line and the sysfs-based GPIO control will fail at the first statement in /init*.rc.
[G Tablet General] chowyungfatso:
Anyone actually test it with 4.2.X Dirty-Bean yet?

ROM works pretty well, so am thinking of putting GPS in my g tablet. Anyone have had a chance to test it?
[G Tablet General] fosser2:
Yes, just me afaik. But from my tests it has been working well.
[G Tablet General] RobBrownNZ:
Hi fosser2,

Thanks for all your work on this (and the Team DRH ROMs, of course). Also, sorry for posting something (almost) unrelated in this thread.

I want to do some non-Android coding on my G Tablet (using the nvidia Linux release) and I'd like to hook up a debug UART. I think I remember seeing someone had done this, but I can't find anything about it. Do you, or does anyone you know, have a debug UART connected? And could you point me at some details about it?

Or, if you don't have a debug UART, could you please tell me which UART the GPS module is connected to? (I have to admit I haven't searched for this yet, I imagine it won't be hard to find for myself).

Thanks for any help you can provide!

Cheers,

Rob.
[G Tablet General] fosser2:
You'll have to hop into the irc channel and catch me there.

freenode #gtab-kerneldev

I will go over it in detail there.
[G Tablet General] RobBrownNZ:
Thanks for the offer! I'll lurk in the channel, but we'll probably have time zone issues - I'm in New Zealand, at UTC+13 (dropping back to +12 in a couple of weeks).

By the way, I'm not new to this. I did a similar job with the Pandigital Novel (see my website and also a thread on SlateDroid if you're interested). Unfortunately I broke my Novel and now my G-Tablet is up for surgery!

To tell the truth, it's Team DRH's kernel work that's got my interest up. You seem to have the hardware under quite solid control and that's no small achievement. I want to build a MAME box, so the camera doesn't interest me, and everything I do want seems to be there.

If there's much discussion to be had around this, I'll probably start a new thread.

Cheers,

Rob.
[G Tablet General] lgfathom:
thanks for this fps addon.please reply me if i can use the source for my project.
[G Tablet General] fosser2:
What do you need from me?
[G Tablet General] allenpan:
the pic is dead can you re-upload it or pdf it?
[G Tablet General] twistedrotors:
Not sure if it's relevant, but the extra enable = 0 and enable =1 in my message were due to Maps or Navigation. Each time I started one of them they would add a couple lines to that output.

-John
[G Tablet General] twistedrotors:
Rajeevvp, I tired out your second set of instructions and still no love. My electronics work is primarily with simple microcontrollers (Arduino). So when I hook a serial GPS module up to the serial port of my Arduino the data goes there and I can tell the Arduino to look at the serial port for data.

Does it now seem like we have a physical disconnect between where (port) the Gtab is looking for GPS data and our serial GPS modules?

Thanks much for your help, software is NOT my forte at all!

-John

export PATH=/data/local/bin:$PATH
$ $su

# cat /sys/devices/platform/gps_control/enable
1# dmesg | fgrep gps_control
<4>[ 6.288111] gps_control: gps_control_init
<4>[ 6.292229] gps_control: gps_control_probe
<6>[ 6.296577] input: gps_control as /devices/virtual/input/input3
<4>[ 6.303299] gps_control: gps_control_probe success
<4>[ 164.432193] gps_control: gps_control_write_sysfs_enable() enable=1
# dmesg | fgrep /virtual
<6>[ 6.149295] input: so340010_kbd as /devices/virtual/input/input1
<6>[ 6.266788] input: nvodm_touch as /devices/virtual/input/input2
<6>[ 6.296577] input: gps_control as /devices/virtual/input/input3
<6>[ 6.308488] input: dummy_sensor as /devices/virtual/input/input4
<6>[ 6.314947] input: accelerometer as /devices/virtual/input/input5
<6>[ 6.327874] input: light_sensor as /devices/virtual/input/input6
# hexdump -C /dev/input/event1
00000000 ff 00 00 00 df e8 0d 00 01 00 66 00 01 00 00 00 |..........f.....|
00000010 00 01 00 00 28 82 00 00 01 00 66 00 00 00 00 00 |....(.....f.....|
# hexdump -C /dev/input/event3
^C
# stty speed 9600 < /dev/ttyS0
115200
# cat /dev/ttyS0
^C
# hexdump -C /dev/ttyS0
^C
# stty speed 9600 < /dev/ttyHS2
921600
# stty speed 9600 < /dev/ttyHS2
9600
# hexdump -C /dev/ttyHS2
# stty speed 9600 < /dev/ttyHS3
9600
# hexdump -C /dev/ttyHS3
^C
# stty speed 9600 < /dev/ttyHS1
9600
# hexdump -C /dev/ttyHS1
^C
# stty speed 9600 < /dev/ttyHS4
9600
#
^C
# hexdump -C /dev/ttyHS4
^C
# hexdump -C /dev/ttyHS4
^C
# hexdump -C /dev/ttyHS3
^C
# hexdump -C /dev/ttyHS2
# hexdump -C /dev/ttyHS1
^C
# hexdump -C /dev/ttyS0
^C
#
[G Tablet General] twistedrotors:
Fosser,

I noticed in the old thread by Chevy that he mentioned a schematic. Have you ever run across this schematic in your searches? If we had a schematic of the Gtabs mainboard this would be a HELLUVA lot easier! :p

I don't think U39 is between the GPS and the Gtabs CPU, but maybe something else is missing.

-John
[G Tablet General] rajeevvp:
If you're certain about this, that is good news. It means that that component of the software is good to go. It is enabling the GPS, trying to read the data (from which port we don't know yet), failing, and then disabling the GPS when it shuts down.

The other /dev/input/eventn device files are all being read by only one process, system_server:

$ su
# fuser /dev/input/event4
1058
# ps | fgrep 1058
system 1058 976 182452 55264 ffffffff afd0b77c S system_server

On my tablet though, nothing is using /dev/input/event3, even with the GPS GPIO enabled. What's the situation on your tablet with the GPS attached, as per the commands above?

Yeah, looks like you guys will have to trace the wires from the GPS data lines back to whatever it interfaces to on the gTablet motherboard.

Can you also check if enabling and disabling the GPS GPIO port using echo raises or lowers any lines on the GPS module or on whatever the module connects to?

If we can find out where the GPS data lines terminate, we can either see if there is already a driver for that interface (SDIO or serial port if we're lucky) or if there isn't, make a start at writing (or porting) a device driver for the new interface--if we can get the specs for the chips that drive it.

I'm the exact opposite.

John, you ran the hexdumps on /dev/input/event3 and the /dev/tty[H]Sn devices while Maps/Navigation was running, right?

And that is another interesting thing: I don't have /dev/ttyHS1 or HS2 on my gTablet. What's the difference, I wonder?
[G Tablet General] twistedrotors:
Yep, the last set of hexdumps I ran at the end was after I made sure that Maps was running. I noticed the extra HS ports when I did an ls in /dev (the extent of my software prowess) and I figured it couldn't hurt to try them out. That is absolutely fantastic news about the software though! Now, on to the "bad" news......

I've found at least one more missing piece of hardware. I broke out the trusty Fluke, stripped my Gtab down and went to work!

U34 on the bottom of the PCB is where both the TXA and RXA pins from the GPS module go.

So far I've only figured out that RXA goes to pin 1, GND on pin 2 and TXA to pin 8. I was hoping it would be obvious what kind of device it is, but I'm stumped. Edit: Thought maybe it was an UART to SPI interface of some kind. But every one that I've found is a minimum of 14 pins. Similar looking populated devices (U32, U11, U12) all seem to have ground on pin 1.

So far searching by the numbers marked on the top of those devices hasn't turned much up on Digikey or Google.

Right now, a high-res picture of this area inside a Malata Zpad with GPS installed is exactly what we need. Is there anyone on these boards with a Zpad with GPS? I'd buy them a couple beers if they'd crack open their case and take pictures! :D

I'll keep looking.

-John
[G Tablet General] twistedrotors:
Oops, forgot to reply to this section.

Yes, pretty certain that is what was happening. For event3, using your commands (with GPS attached) nothing was coming through.

-John
[G Tablet General] twistedrotors:
After scouring the internet all day for a phantom UART-to-"Gtab" adapter I changed up my thinking a little and I think I figured out what U34 is.

None of the UART adapters I found came in anything smaller than 14 pin packages and none of the SPI/I2C digital adapters seemed to have the right pin out for what I was looking for. This was driving me nuts! So I took a breather, a step back, had a beer and dumbed it down.

What if U34 is just a level shifter?

What if the Gtab CPU doesn't want the full 3.3v coming off the GPS so they need to drop it down to something lower. So I started looking around again and I think I found something suitable. http://focus.ti.com/docs/prod/folders/print/txs0102.html is a voltage-level translator that works in both directions. And the DCT and DCU packages have the right pinout. If my guessing is correct then A1 is the Gtab serial in and A2 is out. B1 is the GPS TXA and B2 is RXA as verified earlier. Curious about the Vcca voltage reference, I hooked the battery back up to my in-pieces Gtab and checked pin 3. Sure enough, 1.8 vdc. Pin 7 (Vccb) however did not have 3.3v on it. I'm not sure if this is important since the GPS module will accept voltages all the way down to 0.7vdc as a logic-high on it's input.

This is all just guessing at this point, but TI offers free samples and I've already ordered mine. Time to get the soldering iron warmed up!

-John
[G Tablet General] manikin13:
Nothing but an idle bystander right now, but this is by far the best thread in Gtab land right now - Hands downs, (even with 3.0 looming above us). I have neither the expertise in hardware or software to come up with what you guys or gals have come up with, but I am waiting with bated breath as to the outcome - hopefully positive.

I would gladly spend even upto 200$ trying to add a internal GPS to my gtab (myself) instead of giving in and buying a transformer.

Note: I currently have a working external bluetooth GPS solution, So I understand fosser's reasoning behind wanting an internal GPS solution. Nothing but nothing beats a self contained unit rather than multiple components.
[G Tablet General] fosser2:
I wish I had this schematic also... I have done everything I can to obtain it to no avail. I even emailed the ebay seller that originally sold that package...

I also got my hands on my multimeter, I will be doing some "discovering" tonight :p I will keep you all posted and check back regularly for the next few hrs.
[G Tablet General] rajeevvp:
So the interface to the gTablet is looking more and more likely to be a UART. Excellent.

Haven't been active on the boards long, so, can any of the readers of this thread tell me if the Malata Zpad kernel source (or patch, as for the gTablet) is available? I can get started on untangling the software side. Thanks.

John, can you tell me which command uses /dev/input/event3 and the /dev/tty[H]Sn devices, by running these commands below. Do it while you have Maps running:

$ su
# fuser /dev/input/event3
[I]nnnn[/I]
ps | fgrep [I]nnnn[/I]

The nnnn is the process ID that fuser prints of the process that is using the device. Do the above for the /dev/tty[H]Sn devices too.
[G Tablet General] fosser2:
This is what I really don't get. It has been confusing me from day #1.

I need to ask the seller that sold this to me if he minds if I share the info
It won't be fair to him.

I now have power to the chip and its working. When I click on the place app now it no longer just says wait but comes up with aps where to go. I just need to pick up a 1/4 watt 300 ohm resistor for the power to the active antenna and I will be ready to test.

I will try and keep you posted if it work as seller says it does.

-6.055chevy

Also I did find some mess-ups in my soldering job...typical noob. I have fixed all of those, but in the process managed to lose the ferrite bead. Dammit. Those things are small. I ordered 2 more :p for when I lose another. I also changed the wiring of the power. Before I was pulling 3.02v of power from the miniPCI-e bay and I now have switched to powering the chip from the U22 pin. I am pulling exactly 3.3v from that according to my multimeter. I will post pics whenever I get enough time to snag a camera. I will also post my findings through terminal in a bit.

Here's the picture. Of what I got so far.

It's weird but everything that looks "warped" is actually just flux that I have not cleaned off yet :p
[G Tablet General] twistedrotors:
I'm calling shenanigans until Chevy gets on here to prove me otherwise. :p

Lookin' good! And good info on the PCIe power supply not being up to the challenge.

When you get a chance I'd really love to see a pic of that active antenna and how it fits inside the case.

-John
[G Tablet General] fosser2:
ya...about that antenna... :p its gonna have issues but thats the last of my concern right now. It would fit fine if it had a longer cord.

-I'm retiring for the night also 1:07am :D
[G Tablet General] twistedrotors:
I will do this in the morning. Right now I'm too tired to put my Gtab back together. :D

-John

Edit: I couldn't wait till morning. :p

$ export PATH=/data/local/bin:$PATH
$su
# echo 1 > /sys/devices/platform/gps_control/enable
# cat /sys/devices/platform/gps_control/enable
1#

#fuser /dev/input/event3
979
#ps | fgrep 979
system 979 905 337040 46516 ffffffff afd0dbdc S system_server

# fuser /dev/ttyHS1

# fuser /dev/ttyHS2
1029
# ps | fgrep 1029
bluetooth 1029 1 828 372 c015384c afd0ea1c S /system/bin/bc_hciattach

# fuser /dev/ttyHS3
979
# ps | fgrep 979
system 979 905 337040 47048 ffffffff afd0dbdc S system_server

# fuser /dev/ttyHS4

# fuser /dev/ttyS0