BCM4751 » History » Version 5
Paul Kocialkowski, 02/18/2012 12:50 AM
1 | 1 | Paul Kocialkowski | h1. Broadcom4751GPS |
---|---|---|---|
2 | |||
3 | h2. Files |
||
4 | |||
5 | 2 | Paul Kocialkowski | The non-free files holding the GPS infos/code are the following: |
6 | 1 | Paul Kocialkowski | <pre> |
7 | /system/vendor/bin/gpsd |
||
8 | /system/vendor/lib/hw/gps.s5pc110.so |
||
9 | /system/vendor/etc/gps.xml |
||
10 | /system/etc/gps.conf |
||
11 | </pre> |
||
12 | 2 | Paul Kocialkowski | |
13 | h2. Protocol |
||
14 | |||
15 | Apparently, the protocol that is used by the chip to provide the GPS infos is MEIF. The GPSD component is in charge of translating that to standard NMEA that is sent to the gps.s5pc110.so lib via the /dev/socket/gps Unix socket, created by GPSD. |
||
16 | |||
17 | h2. Attempts |
||
18 | |||
19 | We have written code to read data from the correct serial interface: https://gitorious.org/replicant/crespo-gps-utils |
||
20 | |||
21 | It currently doesn't work: it fails to somehow boot the chip. Though, it works after starting gpsd once and stopping it. It must be doing some kind of magic code to start the chip. |
||
22 | |||
23 | h3. Related gps.xml parameters |
||
24 | |||
25 | We have tried to change some parameters in gps.xml to see how it behaves: |
||
26 | |||
27 | |_. Parameter |_. Original |_. Changed to |_. Result | |
||
28 | | acPortName | /dev/s3c2410_serial1 | /dev/s3c2410_serial42 | The chip wasn't "booted" | |
||
29 | | gpioNStdbyPath | /sys/class/sec/gps/GPS_PWR_EN/value | /sys/class/sec/gps/GPS_PWR_EN/value2 | The chip was booted | |
||
30 | | gpioNResetPath | /sys/class/sec/gps/GPS_nRST/value | /sys/class/sec/gps/GPS_nRST/value2 | The chip was booted | |
||
31 | 3 | Paul Kocialkowski | |
32 | After all, it seems that when the gpsd binary is running without the gps.s5pc110.so library, the chip isn't started (our test utility doesn't work) whereas when the library is running and connects to the socket when it is created by starting gpsd, the chip is booted. The init code is probably in gps.s5pc110.so then. |
||
33 | 4 | Paul Kocialkowski | |
34 | Things to try: |
||
35 | * intercept what is going on through the /dev/socket/gps socket |
||
36 | * emulate gpsd to the lib |
||
37 | 5 | Paul Kocialkowski | |
38 | h3. Tracing the HAL that will run the library |
||
39 | |||
40 | Piece of the trace that actually makes the gps chip available: |
||
41 | <pre> |
||
42 | 536 syscall_983045(0x100fff00, 0xa798, 0, 0x40, 0x100fff00, 0x80003b51, 0x800082e0, 0xf0005, 0x10000000, 0x80003b51, 0x100000, 0x1, 0, 0x100ffee8, 0xafd11e24, 0xafd0c81c, 0x60000010, 0x100fff00, 0x2f028, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0 |
||
43 | 536 ipc_subcall(0x2, 0xa798, 0, 0x40) = 12 |
||
44 | 536 fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR) |
||
45 | 536 fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 |
||
46 | 536 semop(0xc, 0x1, 0x5, 0x100ffe70) = 0 |
||
47 | 536 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) |
||
48 | 536 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 |
||
49 | 536 semop(0xc, 0x1, 0x3, 0x100ffe70) = 0 |
||
50 | 536 semget(0xc, 0x100ffea0, 0x2, 0xffffffff <unfinished ...> |
||
51 | </pre> |