Project

General

Profile

BCM4751 » History » Revision 24

Revision 23 (Denis 'GNUtoo' Carikli, 12/04/2012 02:29 PM) → Revision 24/33 (Paul Kocialkowski, 07/01/2015 08:52 AM)

h1. BCM4751 Broadcom4751GPS 

 h2. Factory image 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> 

 h3. 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 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. 

 h2. 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 or 4751A2 | 
 | Galaxy S I9000 | Samsung | 4751A2 | 
 | Galaxy Tab P1000 | Samsung | ? | 
 | Galaxy Tab 8.9 P7300/P7310 | Samsung | 4751A2 | 
 | Nexus 7 | Google/Asus | ? | 

 The bCM4751 chip exists under the following revisions: 4751A0, 4751A1, 4751A2, 47511A0 

 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 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 

 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 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 | 

 h3. 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: 
 <pre> 
 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. 
 </pre> 

 h3. BCM4751 patch 

 In order to use the same protocol as the non-free gpsd, a patch needs to be sent. It is hardcoded in the non-free gpsd binary. 
 Note that we don't know what that patch exactly is nor what it does. In any case, it must be considered as the propriety of Broadcom (or Samsung maybe) and falls under the non-free gpsd license. 

 Here are notes on how to extract the patch from various non-free gpsd binaries: 
 |_. Device |_. Source |_. GPSD MD5 |_. Offset |_. Length |_. dd command | 
 | Nexus S | CM 9.0.0 | 4a6c0027e530b5b8a346153a355ef8e3 | 0x15DDEA | 2738 bytes | dd skip=1433066 count=2738 if=gpsd of=bcm4751a1.fw bs=1 | 
 | Galaxy S | CM 9.1.0 | 4a6c0027e530b5b8a346153a355ef8e3 | 0x15E89E | 6406 bytes | dd skip=1435806 count=6406 if=gpsd of=bcm4751a2.fw bs=1 | 

 The @bcm4751_gpsd@ utility will attempt to read the patch from @/data/bcm4751a1.fw@ or @/data/bcm4751a2.fw@ 

 h4. Post protocol switching 

 Sending this string: 
 "\xfe\x00\xfd\x6f\x3a\x01\x00\x00\x00\x00\x34\xfc" 
 many times makes some other string appear on the serial port... 
 <pre> 
 fe 00 fd 0f ff 07 06 00 00 01 54 fc 
 fe 00 fd 0f ff 08 06 00 00 01 1c fc 
 </pre> 
 Here's the decoding of the first bytes: 
 <pre> 
 ff00 = 8bytes 
 fe00 = 12bytes 
 fe01 = 16bytes 
 fe02 = 20bytes 
 fe03 = 24bytes 
 fe04 = 28bytes 
 fe05 = 32bytes 
 fe06 = 36bytes 
 fe07 = 40bytes 
 </pre> 

  * fc seem an end marker and 54/c1 a checksum.... 
  * 07,08 seem a sequence number, if I do it right after booting the chip it starts with 01 

 h5. howto 
 run that python program: 
 <pre> 
 print "\xfe\x00\xfd\x6f\x3a\x01\x00\x00\x00\x00\x34\xfc" 
 </pre> 
 like that 
 <pre>python foo.py > serial.txt</pre> 
 <pre>adb push serial.txt /sdcard/</pre> 
 on target: 
 <pre>hexdump -C /dev/s3c2410_serial1</pre> 
 <pre>cat /sdcard/serial.txt > /dev/s3c2410_serial1</pre>