BCM4751 » History » Revision 9
Revision 8 (Denis 'GNUtoo' Carikli, 08/13/2012 01:28 AM) → Revision 9/33 (Paul Kocialkowski, 08/14/2012 01:46 PM)
h1. Broadcom4751GPS h2. Factory image files Files The non-free files holding the GPS infos/code are the following: <pre> /system/vendor/bin/gpsd /system/vendor/lib/hw/gps.s5pc110.so /system/vendor/etc/gps.xml /system/etc/gps.conf </pre> h2. Protocol 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. h2. Attempts We have written code to read data from the correct serial interface: https://gitorious.org/replicant/crespo-gps-utils 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. h3. Related 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. h2. 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 init code is probably 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. then. h2. Devices Here is a list of the devices that are known Things to use the BCM4751 chip: |_. Device |_. Vendor |_. BCM4751 revision | try: | Nexus S | Google/Samsung | 4751A1 | | Galaxy S I9000 | Samsung | 4751A2 | | Galaxy Tab P1000 | Samsung | ? | | Nexus 7 | Google/Asus | ? | h2. 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 * intercept what is the Nexus S, even though it should work with few changes going on other BCM4751 devices. The code source is available at: https://gitorious.org/replicant/crespo-gps-utils h3. Current status |_. Part |_. Status |_. Comments | | Serial setup | "DONE":https://gitorious.org/replicant/crespo-gps-utils/commit/e4f94e901b9b4c5fef5642ad9580863fc2bfe336 | Magic is: @termios.c_cflag = 0x800018b2;@ | | MEIF parsing | "DONE":https://gitorious.org/replicant/crespo-gps-utils/commit/927c1c92dd092cec8c56351bf663101183f19076 | | | MEIF dispatch | "DONE":https://gitorious.org/replicant/crespo-gps-utils/commit/f952dde8f3a29634be1c8fa19b8eed367c1ad878 | | | MEIF patch upload | "DONE":https://gitorious.org/replicant/crespo-gps-utils/commit/9a5827778189b7e0f91879430a4e160567ee6bbd | Nexus S and Galaxy S patches differ | h3. Utilities |_. Name |_. Task |_. Arguments | | bcm4751_gpsd | Main utility, boots through the chip, send the patch, switch protocol | None | /dev/socket/gps socket | 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) * emulate gpsd to the lib | None | | bcm4751_lib | Acts as (a fake) lib to gpsd | None | h3. BCM4751 gpsd This is where MEIF is implemented. It currently does Tracing the following: * Serial setup * Autobaud * MEIF reader loop * MEIF parsing * MEIF dispatch * MEIF patch upload * Protocol switch (sends unknown bytes in HAL that will run the second protocol to get a response) * Response dump library Sample output log: <pre> Turning Piece of the GPS on... Opening trace that actually makes the GPS serial... gps chip available: Sending autobaud... <pre> Read 17 bytes 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 Read 32 bytes MEIF message: MEIF_STATE_REPORT_MSG with 18 bytes of data: [0000] 536 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ........ ........ ipc_subcall(0x2, 0xa798, 0, 0x40) = 12 [0010] 536 1A 00 .. fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR) 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] 536 02 00 01 00 01 00 40 00 01 00 02 00 00 00 00 00 ........ ........ fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 [0010] 536 01 00 02 00 00 00 00 00 00 00 06 00 81 11 00 09 ........ ........ semop(0xc, 0x1, 0x5, 0x100ffe70) = 0 [0020] 536 07 07 D9 07 42 52 4F 41 44 43 4F 4D 00 00 00 00 ....BROA DCOM.... fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) [0030] 536 00 00 00 00 34 37 35 31 41 31 00 00 00 00 00 00 ....4751 A1...... fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 [0040] 536 00 00 00 00 B3 05 ...... semop(0xc, 0x1, 0x3, 0x100ffe70) = 0 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] 536 03 00 03 00 0F 00 ...... semget(0xc, 0x100ffea0, 0x2, 0xffffffff <unfinished ...> Got a NACK message Reason is: MEIF_NACK_GARBAGE_RECEIVED </pre> Read 12 bytes syscall_983045 = __NR_ARM_set_tls 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 function to switch protocol! Sending unknown bytes! Read 12 bytes: [0000] FE 00 FD 40 00 00 F1 B1 12 20 67 FC ........ ..g. </pre> use is: __set_tls h3. Random notes with the new utility program <pre> echo -n "ab" > /dev/s3c2410_serial1 </pre> produces: <pre> 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. </pre> * 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....