Project

General

Profile

Actions

BCM4751 » History » Revision 9

« Previous | Revision 9/33 (diff) | Next »
Paul Kocialkowski, 08/14/2012 01:46 PM


Broadcom4751GPS

Factory image files

The non-free files holding the GPS infos/code are the following:

/system/vendor/bin/gpsd
/system/vendor/lib/hw/gps.s5pc110.so
/system/vendor/etc/gps.xml
/system/etc/gps.conf

gps.xml parameters

We have tried to change some parameters in gps.xml to see how it behaves:

Parameter Original Changed to Result
acPortName /dev/s3c2410_serial1 /dev/s3c2410_serial42 The chip wasn't "booted"
gpioNStdbyPath /sys/class/sec/gps/GPS_PWR_EN/value /sys/class/sec/gps/GPS_PWR_EN/value2 The chip was booted
gpioNResetPath /sys/class/sec/gps/GPS_nRST/value /sys/class/sec/gps/GPS_nRST/value2 The chip was booted

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.

gps.s5pc110.so will actually order bootup via the socket, when the gps is requested by the Android framework. When it's not used anymore, it will request poweroff as well.

Protocol

According to the logs obtained from gpsd, the chip seems to be using the MEIF protocol at first, then a patch is sent and it starts using another protocol, which doesn't seem related to MEIF according to the logs (there are basically no more references to MEIF after uploading the patch). However, as we have no information about what MEIF is (it's a binary proprietary undocumented protocol), these are just guesses.
We decided to implement the first protocol under the name MEIF, but it could also be some sort of BCM4751-specific bootloader protocol that is in charge of making the patch upload.

The GPSD component is in charge of translating the second protocl to standard NMEA that is sent to the gps.s5pc110.so lib via the /dev/socket/gps Unix socket, created by GPSD.

Devices

Here is a list of the devices that are known to use the BCM4751 chip:

Device Vendor BCM4751 revision
Nexus S Google/Samsung 4751A1
Galaxy S I9000 Samsung 4751A2
Galaxy Tab P1000 Samsung ?
Nexus 7 Google/Asus ?

Free software implementation

On January 2012, the work to write a free software implementation that could handle the BCM4751 chip was started.
The main target is the Nexus S, even though it should work with few changes on other BCM4751 devices.

The code source is available at: https://gitorious.org/replicant/crespo-gps-utils

Current status

Part Status Comments
Serial setup DONE Magic is: termios.c_cflag = 0x800018b2;
MEIF parsing DONE
MEIF dispatch DONE
MEIF patch upload DONE Nexus S and Galaxy S patches differ

Utilities

Name Task Arguments
bcm4751_gpsd Main utility, boots the chip, send the patch, switch protocol None
bcm4751_test Deprecated utility, can be used for poweroff stop: poweroff the chip
bcm4751_hal Acts as the framework: permits to trace gps.s5pc110.so None
bcm4751_daemon Acts as (a fake) gpsd to the lib None
bcm4751_lib Acts as (a fake) lib to gpsd None

BCM4751 gpsd

This is where MEIF is implemented. It currently does the following:
  • Serial setup
  • Autobaud
  • MEIF reader loop
  • MEIF parsing
  • MEIF dispatch
  • MEIF patch upload
  • Protocol switch (sends unknown bytes in the second protocol to get a response)
  • Response dump

Sample output log:

Turning the GPS on...
Opening the GPS serial...
Sending autobaud...
Read 17 bytes
Read 32 bytes
MEIF message: MEIF_STATE_REPORT_MSG with 18 bytes of data:
[0000]   01 00 00 00 01 00 00 00   00 00 00 00 00 00 00 00   ........ ........
[0010]   1A 00                                               ..
Got a STATE_REPORT message

Read 23 bytes
Read 32 bytes
Read 16 bytes
Read 7 bytes
MEIF message: MEIF_CONFIG_VALUES_MSG with 70 bytes of data:
[0000]   02 00 01 00 01 00 40 00   01 00 02 00 00 00 00 00   ........ ........
[0010]   01 00 02 00 00 00 00 00   00 00 06 00 81 11 00 09   ........ ........
[0020]   07 07 D9 07 42 52 4F 41   44 43 4F 4D 00 00 00 00   ....BROA DCOM....
[0030]   00 00 00 00 34 37 35 31   41 31 00 00 00 00 00 00   ....4751 A1......
[0040]   00 00 00 00 B3 05                                   ......
Got config values:
    vendor: BROADCOM
    product: 4751A1

Sending the first part of the patch...
Sending 2054 bytes!
MEIF message: MEIF_SEND_PATCH_MSG with 2046 bytes of data:

Read 14 bytes
MEIF message: MEIF_NACK_MSG with 6 bytes of data:
[0000]   03 00 03 00 0F 00                                   ......
Got a NACK message
Reason is: MEIF_NACK_GARBAGE_RECEIVED

Read 12 bytes
MEIF message: MEIF_ACK_MSG with 4 bytes of data:
[0000]   04 01 0B 00                                         ....
Got an ACK message

Sending the second part of the patch...
Sending 706 bytes!
MEIF message: MEIF_SEND_PATCH_MSG with 698 bytes of data:

Read 12 bytes
MEIF message: MEIF_ACK_MSG with 4 bytes of data:
[0000]   05 02 0D 00                                         ....
Got an ACK message

Ready to switch protocol!
Sending unknown bytes!
Read 12 bytes:
[0000]   FE 00 FD 40 00 00 F1 B1   12 20 67 FC               ........ ..g.

Random notes with the new utility program

echo -n "ab" > /dev/s3c2410_serial1

produces:
Read 14 bytes:
[0000]   49 27 01 00 10 00 40 00   07 00 58 00 49 D0         I....... ..X.I.
Read 14 bytes:
[0000]   49 27 01 00 10 00 41 00   07 00 59 00 49 D0         I.....A. ..Y.I.
* The only thing that changes seem to be the 40->41 and the 58->59, so theses seem to be something like a sequence number....

Updated by Paul Kocialkowski over 12 years ago · 9 revisions

Also available in: PDF HTML TXT