Hi guys,
I'm trying to connect Lumia 920 to the Linux (actually, to the RaspBian Linux, running on the Raspberry Pi).
I've correctly installed bluetooth on RPi and successfully paired RPi with Lumia. I've took sources of the simple RFCOMM server (actualy, I don't need more - just some simple text exchange) from http://people.csail.mit.edu/albert/bluez-intro/
For WP8 I've used (slight modified) sources from http://developer.nokia.com/Communit...nces_via_Bluetooth_and_NFC_on_Windows_Phone_8
On the client (WP8) side, the function await socket.ConnectAsync(rpiHostName,"1"); working correctly and returns no error (and RPi status in the bluetooth settings is "Connected"). Also, I can send strings (bytes) to the socket without errors. But on the server side (http://people.csail.mit.edu/albert/bluez-intro/x502.html#rfcomm-server.c), execution get stuck at:
Code:
// accept one connection
client = accept(s, (struct sockaddr *)&rem_addr, &opt);
Do you have any ideas/working samples?
Thanks!
I'd make some examples if I had a Raspberry Pi. This is pretty awesome that you're able to do this... Imagine the possibilities.
snickler, the RPi is really cheap; it costs just $40 from Amazon with free shipping. And device is ready to go: you just need a sd-card, and any cell phone power adaptor, that's all!
You may plug an USB hub, WiFi/BT dongles, keyboard, mouse or a webcam. Or connect it to TV by HDMI cable and use as media player (it can drive full HD video).
He-he, and it's open source; no (stupid) restrictions as on WP
P.S. I'm trying to build a small home robot to entertain my little princess (no, I'm lying actually: I entertain myself in the first place ).
Well, if you posted more code, I'm sure we could help you. However, it's pretty hard to do so when we have no idea how it works .
Sunius1 said:
Well, if you posted more code, I'm sure we could help you. However, it's pretty hard to do so when we have no idea how it works .
Click to expand...
Click to collapse
Sure, of course! https://www.dropbox.com/s/4fyp7nxgvlgkamb/bt.zip
Linux folder contains very simple linux socket server. IP part is working fine but not a BT. You may comment all RPi related stuff (currently I'm awaiting for the motor shield so the wiringPi commands just turn switching light diodes connected to GPIO ) and run server on the regular Linux box.
WP8 folder contains simple WP8 app (also working via IP or BT). IP part is working just fine (currently no advanced error handling implemented but it's OK for proto) but I can't communicate with Linux via BT
I've checked the code. Everything looks fine except the bind part on the server:
Code:
bind_return = ::bind ( m_sock, ( struct sockaddr * ) &m_addrBt, sizeof ( [b]m_addrIp[/b] ) );
Also, I couldn't find the documentation for it, so I'm not sure you're using bdaddr_t correctly.
Other than that, make sure nothing is listening to that port on the RaspberryPi - since the phone reports it connected successfully - it might have connected to some other application.
Yes, you right. It's mistyping, my fault (the sizes are different). Thanks! Can't try now, still working at office...
Sunius1, could you try this code on Linux (with correction)? And could you share yours (correct, I hope so ) /etc/bluetooth/* configuration files (I mean, what I should have in /etc/bluetooth/ to get this code working). I'm not a "Linux guy" unfortunately...
BTW, could you please provide any (even very simple) code to communicate between WP8 and Linux via Bluetooth (RFCOMM, L2CAP, etc.)?
Tried with code correction (proper structure size); unfortunately it doesn't helps MS tutorials are full of "how to connect windows phone to windows phone". Can't find anything about WP and Linux
Yeees! I've solved it!
The issue is solved by choosing port 5! I've run the sdptool on the RPi (output bellow) and discover that channels 1-4 are used by the damn WP... And (that is ridiculous!) nobody (yeah, that's right - MSFT's, damn "experts") at the MS or Nokia's forums never mentioned that!
So, I've changed the RF channel from "1" (this - damn f&*%ng lammahs! - mentioned at all (but very rare!) examples) to "5" and get strong and reliable connection!
Anybody, feel free to use posted (above, a few posts up) code; probably later I'll post whole projects (for WP & RPi Linux) on codeplex or github.
Code:
[email protected] ~/hobo/socket $ sdptool browse 54:79:75:C9:13:FA
Browsing 54:79:75:C9:13:FA ...
Service Name: Service Discovery
Service Description: Publishes services to remote devices
Service Provider: Microsoft
Service RecHandle: 0x0
Service Class ID List:
"SDP Server" (0x1000)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
"SDP" (0x0001)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Service Name: Device ID Service Record
Service Description: Device ID Service Record
Service RecHandle: 0x10000
Service Class ID List:
"PnP Information" (0x1200)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
"SDP" (0x0001)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Service Name: Object Push Profile
Service RecHandle: 0x10001
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
"OBEX" (0x0008)
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100
Service Name: Microsoft Windows Audio Source
Service RecHandle: 0x10002
Service Class ID List:
"Audio Source" (0x110a)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 25
"AVDTP" (0x0019)
uint16: 0x102
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Advanced Audio" (0x110d)
Version: 0x0102
Service Name: Voice Gateway
Service RecHandle: 0x10003
Service Class ID List:
"Handsfree Audio Gateway" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 2
Profile Descriptor List:
"Handsfree" (0x111e)
Version: 0x0105
Service Name: Phone Book Access PSE
Service RecHandle: 0x10004
Service Class ID List:
"Phonebook Access - PSE" (0x112f)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
"OBEX" (0x0008)
Profile Descriptor List:
"Phonebook Access" (0x1130)
Version: 0x0101
Service Name: BtSoftAp Service
Service RecHandle: 0x10005
Service Class ID List:
UUID 128: 232e51d8-91ff-4c24-ac0f-9ee055da30a5
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 4
Profile Descriptor List:
"" (0x232e51d8-91ff-4c24-ac0f-9ee055da30a5)
Version: 0x0100
Service Name: Audio Video Remote Control Profile
Service RecHandle: 0x10006
Service Class ID List:
"AV Remote Target" (0x110c)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 23
"AVCTP" (0x0017)
uint16: 0x103
Profile Descriptor List:
"AV Remote" (0x110e)
Version: 0x0104
Awesome! Glad you've solved it. I'm not running linux so I can't share those files, unfortunately. I just looked at the code from Windows .
Thanks, man! There are a few more small issues (4 example, when you trying to reconnect to the already connected device, the ConnectAsync method fails - looks like a MS "experts" never tested that issue - and, AFAIK there is no API to solve it ) but it's OK I've got my motor shield today and the next big task is to let my little "guy" to move free in the house
Did you look at Winsock API? It's huge, it can achieve much more things than you can do through regular C# sockets. AND it's wholly available on Windows Phone 8.
Thanks for suggestion but my current solution with StreamSocket (yes, I know it lacks a lot of features) satisfy my needs on 99.9%
I don't need something more sophisticated: my goal is to use WP as a "robot remote control", to manually controlling the chassis and choose and run HoBo's programs (coming soon).
Related
The New BT STACK(BCHS) has Release at 31 May 2006 , Can anybody find the setup file ?
the old BCHS ver.107 ( 1107 ) , See:
O2 MINI NEW BLUETOOTH STOCK.
The New one is ver.1740 , Description :
Release Description BCHS 15.1.0
Thanks !!
ps: Sorry !!! It's " Stack " , Not " Stock " ...
The Release File contains:
The 15.1 serie contains the following new features:
- The Phone Book Access Profile has been added
- The device side of the HID-profile has been added
- In the AV, FTC, OPC, BPP, CM and SC it is now possible to cancel an
action started by:
AV_CONNECT_REQ
FTC_CONNECT_REQ
OPC_CONNECT_REQ
BPP_CONNECT_REQ
CM_SDC_SEARCH_REQ
CM_SDC_UUID128_SEARCH_REQ
SC_BOND_REQ
Besides the new features a number of bugfixes has also been addressed in this release.
Below a short description of the content of the bugfixs that has been solved in this release is listed.
Release 15.1.0
--------------
Introduction
------------
The 15.1.0 release contain a number of bugfixes and improvments as liste
above.
And more old Release.......
link doesnt work....
Link brings up error "you dont not have the authorization to download this content"
I am very interested in seeing this!
It is a stack, you ...!
Hey Chatty,
i'm interested to see whether or not this updated version of the bluetooth stack (that i'm already using) has any of the bugs fixed that the original had.
If you looked at the old stack and the amount of attention it got maybe you should just let people follow what interests them and if you dont like it ... DONT READ IT!
People have the right to read what they want and say what they want! But they should be able to do it with out have someone personally attack them, ESPECIALLY IF THAT PERSON HAS NOTHING CONSTRUCTIVE TO ADD TO THE CONVERSATION!
Anyway
enjoy your night Chatty and relax a little!
we love ya anyway
Nice edit Chatty!
The Release File :
The 15.1 serie contains the following new features:
- The Phone Book Access Profile has been added
- The device side of the HID-profile has been added
- In the AV, FTC, OPC, BPP, CM and SC it is now possible to cancel an
action started by:
AV_CONNECT_REQ
FTC_CONNECT_REQ
OPC_CONNECT_REQ
BPP_CONNECT_REQ
CM_SDC_SEARCH_REQ
CM_SDC_UUID128_SEARCH_REQ
SC_BOND_REQ
Besides the new features a number of bugfixes has also been addressed in this release.
Below a short description of the content of the bugfixs that has been solved in this release is listed.
Release 15.1.0
--------------
Introduction
------------
The 15.1.0 release contain a number of bugfixes and improvments as liste
above.
Bugfixes
------------------
D-0095 Fixed problem in ./common.h with endian dependend macro's for
bytestream manipulation. The macros have been made endia
independent.
D-0307 Linux: Using BCHS in the Linux Kernel mode, the scheduler did
not correctly clean up the timed event queue upon shutdown.
D-0419 Linux: Using BCHS in the Linux User mode, the scheduler did
not correctly clean up the timed event queue upon shutdown.
D-0578 Linux: In the Linux kernel port, it must be possible to
specify an alternate panic handler, such that special
platform/application specific handling can be performed
instead of the default BCHS sched_panic() function.
D-0717 Linux: The Linux userspace USB driver must support the new
kernel-driver interfaces for Reset and EnterDFU.
D-0797 Linux: The Linux kernel USB driver supports a
non-documented customer-supplied "extra" interface to augment
the standard USB driver
D-0804 Linux: It is now possible to setup maximum number of
outstanding ISOC frames in the USB driver at runtime, instead
of having to define it at compile time.
D-0805 Linux: The Linux kernel USB driver is slow due to inefficient
URB usage pattern and too many payload copying.
D-0863 Linux: The Linux kernel driver will sometimes crash when being
unloaded.
D-0879 Linux kernel: Crashes/oopses have been seen to occur when
loading/unloading the USB driver multiple times.
D-0888 Linux: If the Linux kernel BSL (PAN) network interface was
loaded, but not configured (ie. not connected), the module
would crash on unload/unregister.
D-0901 Linux kernel: The USB driver must support the UsbDrv_Reset()
API call required by the USB interface.
D-0904 Linux kernel: The USB driver keeps too much track of the
outstanding URBs.
D-0959 All demo applications: Added "-A <bluetooth-address>" command
line argument for all demo applications. This option can be
used to skip device inquery in the demo application.
D-1017 Linux: The verify_area() Linux kernel API function has been
deprecated since at least Linux version 2.6.11 and completely
removed from at least version 2.6.14. The function access_ok()
should be used instead.
D-1082 Fixed problem in ./common.h with endian dependend macro's for
bytestream manipulation. The macros have been made endia
independent.
D-1100 OBEX/Common: Corrected miscalculation of unicode string length
D-1107 Linux USB: Fixed a problem in the Linux USB driver where a
transfer buffer was allocated based on a predefined value
instead of the value defined by the device
D-1155 BPPS: Support for mandatory features has been completed,
including status and referenced object channel has been
included.
D-1235 Linux USB: Fixed a problem in the Linux USB driver where URB's
could be leaked.
D-1238 Linux: The USB-driver can now handle a warm-reset so it is
possible to use USB ROM devices.
D-1239 Bootstrap: now possible to also use bootstrap when using USB.
A new Library is created for use with USB. The library name
is bccmd_boot_strap_usb.lib for windows and
libbccmd_boot_strap_usb.a for Linux. The old
bccmd_boot_strap-library still contains the serial boot strap
implementation.
D-1254 HFG: Disabling of status indicators using the AT+CMER is now
implemented.
D-1259 HFG: The actual status indicator values are now stored in the
HFG separately for each connection.
D-1265 Linux: The default BCHS sched_panic() now generates a kernel
stack dump when using the Linux kernel BCHS port.
D-1269 In BCHS version 15.0.0 the OBEX profiles writes the total file
size erroneous. This has now been fixed
D-1277 PAN DEMO: updated to prompt user for passkey instead of using
a fixed value.
D-1284 SBC: An overflow could occur in the decoded SBC sound
D-1432 samples, if the sound was played with maximum amplitude at the
time of encoding
D-1293 OBEX/FTC,OPC: The FTC and OPC profiles has had a general code
cleanup.
D-1297 OBEX/OPC: The prim->bodyType in the opcPutReq library function
is only assigned a value if the bodyType in the lib call is
not NULL. I.e. the bodyType contains garbage when arriving in
OPC profile resulting in a crash when OPC pfree it. This has
when fixed so the library set it to NULL.
D-1298 BPP: Could not initiate two requests on different channels at
the same time. This is now fixed.
D-1299 HFG: If the connection was disconnected during a service
search, it was not possible to initiate any further connections
from the HFG since service search resources were not released.
D-1300 Build: Problem compiling without
EXCLUDE_EXCEPTION_HANDLER_MODULE but with ENABLE_SHUTDOWN has
been solved.
D-1305 JSR82: Cancelling an inquiry through the JSR-82 layer led to a
delayed access violation in some cases, because a timed event
was not cancelled. The timed event is now removed when an
inquiry is cancelled.
D-1306 HFG: Fixed problem with Ring request
D-1310 OBEX/FTP: The FTP client API have been updated so the Get and
Put signal describes the new interface
D-1313 Linux: It is now possible to use bootstrapping when running in
the Linux User to kernel mode split.
D-1329 Changed the page scan mode to HCI_PAGE_SCAN_MODE_MANDATORY.
D-1339 Build: The WIN macro has been replaced by the build-in _WIN32
D-1340,D-1341 macro for windows builds. WIN is no longer needed.
D-1344 AV: Avoided AV forcing link to active in case of sniff request
by remote device.
D-1345 DUNC demo app.: Added menu item for hanging up a call and
updated the AT command call setup sequence
D-1350 SC: The SC module does not called sc_db_write() if the peer
device updates a link link which already exits. This has been
fixed so the sc_db_write() function is called when the link
key is updated.
D-1351 SC: If a peer device initiates a connection while the local
device is in high security mode, the class of device parameter
in a SC_BOND_IND msg is zero. A fixed has been made so this
parameter is valid in this situation.
D-1357 BCCMD: Removed memleak in SetPcmChannel
D-1360 VDP-Demo: SD_IFACEQUEUE added to tasks.c
D-1361 VDP-Demo: Alignment set to 8 byte
D-1364 Optimized the HID parser.
D-1365 HFG: When an incoming connection from a headset is initiated
at the same time of a connect request from the application it
is possible that both connections will fail.
D-1367 VDP demo: In order for properly interfacing the external video
library demuxing functions, BCHS libraries and the demo
application must be built using the same alignment as the
external library alignment. Instructions on how to do so has
been added in the demo description.
D-1371 HFG: Fixed handling of AT+CHLD=? in profile and Demo app.
D-1372 VDP Demo: ScPasskeyResSend updated to use proper result format.
D-1373 JSR82: An ill-behaved, threaded Java program could cause rfcomm
packets from the JSR-82 layer to arrive out-of-order. A message
queue has been added to handle this.
D-1374 VDP-Demo: If multiple media packets were sent in the same l2cap
packet then a temporary buffer was freed, causing an error.
This pfree has been removed.
D-1376 OBEX/OPC: If the OPC put an object which need to be spilt up in
multiple OBEX packets, the OPC is some cases keeps sending the
OBEX headers(name, type length).
D-1379 DUNC demo app.: Added response to port negotiation.
D-1380 CM: Under rare condition the Connection Manager could restore
its local queues when it is not allow to. The consequences of
this are that it can send more than one signal to the lower
layer and in worst case a dead lock could happen.
This has been fixed.
D-1381 JSR82: The inquiry procedure of the JSR-82 layer requests names
for all found devices. This has been changed to only request
names when requested from application layer.
The inquiry is now usable for selectService implemented in
upper layer.
D-1382 TCS: The SDP record of the TCS GW contained an incorrect value
of the protocol descriptor list. This incorrect value
(UUID TCS-BIN) has been changed to the correct value
(UUID TCS-BIN-CORDLESS)
D-1389 BPP: Removed potential memory leak when sending document to
printer, by pfreeing printContent.
D-1410 JSR-82: The inquiry procedure may cause a segmentation fault
if no device names are fetched during this. The event
responsible is now properly cleaned up.
D-1411 HFG-Demo: Cleaned up the handsfree demo application and removed
some macro re-definitions.
D-1416 OBEX/OPC: If the OBEX clients (FTC, OPC, BIPC) is release while
setup an OBEX connection their could go into a state where it
has not possible to make a new OBEX connection. This has now
been fixed.
D-1417 OPC: Removed potential memory leak when putting an object to
the server, by pfreeing the object received by the application.
D-1418 OPS: If an OBEX PUT packet includes a type header the OPS
profile did write an invalid byte into the OBEX PUT packet,
which made the rest of it invalid. This has now been fixed so
an invalid byte is not put into the OBEX PUT packet.
D-1420 HFG: HfgAtCmeErrorSend has been added to the Hfg-lib file.
D-1421 HFG: Library function HfgAtCopsSend now returns the correct
structure.
D-1423 BPP: Added description of docTypeLength and printContentLength
in API.
D-1424 HF: Fixed compilation problem when ADVANCED_HF was deined and
new SCO interface is used.
D-1426 BPPS: Activation issue for the BPPS profilemanager solved.
D-1428 BCSP: Fixed problem in BCSP where it was not possible to
initialise BCSP multiple times.
D-1429 Linux kernel: The USB driver should adjust the SCO packet size
after the VOICE_SETTING in usr_config.h.
D-1435 DUNC: Corrected 'maxMsgSize' assignment in the DUNC_STATUS_IND
primitive
D-1438 Handsfree: Fixed interoperability issue with some car kits that
does not follow HFP specification
D-1440 HFG: Fixed problem with incoming and outgoing connection at the
same time
D-1444 AV: Update of the AV API document so it now also states that
the AV profile supports video streaming
D-1445 AV: The description of the roleType parameter in the
AV_STATUS_IND message was wrong. This has been corrected so
the description matches the parameter
D-1446 HIDH Demo: The second parameter of the
HidhConnectAcceptReqSend(...) call in the HIDH demo is invalid.
D-1447 Handsfree: Updated default values for eSCO connections.
D-1456 AVRCP: Update of AVRCP API description, particularly connection
establishment issues.
D-1457 Build: It is now possible to compile BCHS with the
EXCLUDE_BCHS_L2CA_MODULE and/or EXCLUDE_BCHS_RFC_MODULE
compiler defines.
D-1463 BCHS: BCHS has been updated to support RFCOMM so it may be used
together with the 21d Firmware version
D-1467 AVRCP: Prevented forcing connection out of low power mode when
low power was changed by remote device
D-1473 Build: Problem compiling without
EXCLUDE_EXCEPTION_HANDLER_MODULE but with ROM_BUILD_ENABLE
has been solved.
D-1476 HFG: Transmission of callheld status indicator from the HFG is
added.
D-1477 HFG: Fixed the supported features written in service record.
D-1478 BPP-Client: Added description of
BPP_CONNECT_IND and BPP_CONNECT_RES which was missing in the
API documentation (bchs-api-023_obex_bpp_client_api)
D-1482 HFP: PICS document has been updated
D-1488 Corestack: Fixed an issue where the max_frame_size field of an
RFC_START_CFM contained the locally requested value and not the
negotiated value.
D-1489 TCS-Demo: Fixed the GW part of TCS demo application. The GW did
not respond with an alert message due to an imporperly set
variable.
D-1491 FTS: Added low power mode control.
D-1494 HFG: Updated HFG to mutually exclude RING and audio connections
for HSP according to ESR1 E2112.
D-1500 JSR82: For short local names, the JSR-82 layer would read
outside of the string, due to an incorrect cast. The name is
now copied properly.
D-1501 BPP: Made sure that BPP can be activated in NULL state.
D-1502 BPP: Only perform one SDC attribute search during BPP connect.
D-1503 BPP: Fixed problem with handling channels disconnecting in
random order in BPP.
D-1505 The following two compiler defines is added to usr_config.h:
PAGE_SCAN_TYPE
INQUIRY_SCAN_TYPE
These defines allow the customer to select which Page Scan Type
and Inquiry Scan Type BCHS is using.
D-1506 SAPS: Added Bluetooth address of remote device for incoming
connections to the SAPS_CONNECT_IND.
D-1507 BPP: Removed possibility of getting an incorrect structured
OBEX packet on the BPP Object Channel.
D-1509 TCS: Added support for the Samsung SIT105EW access point in the
terminal part of TCS
D-1515 HF: Updated API document with some missing lib. functions.
D-1516 CM: Added more error code mappings from HCI-error codes to
BCHS error codes.
D-1518 Optimized the HID parser
D-1519 HFG: Updated API document with some missing lib. functions.
D-1521 JSR-82: L2CAP connections may leave remaining data when Java
application is closed. This caused new connections in a new
Java application to fail. This data is now cleared.
D-1524 BPP: Corrected the security setting for BPP Object Channel to
none.
D-1525 Obex/Push App: Removed the references to C-code files in
profile_mangers etc. directories and insert the use of
libraries instead.
D-1526 BPP: Corrected the requested max OBEX packet size for BPP Job
and Status Channel.
D-1527 BPP: Added description of channelId and ConnectionId to
documentation of BPP_DISCONNECT_IND.
D-1530 BPP: Added extra security so BPP only accepts incoming Object
Channel connections from a connected printer.
D-1532 HFG: Fixed handling audio request when signals are crossing
D-1533 SC: The cod is zero in the SC_PASSKEY_IND and SC_BOND_IND in
the scenario where:
A successful bond has been made between dev 1) and dev 2).
If dev 2) debonds dev 1) and dev 1) afterwards initiate a
connection to dev 2) then dev 2) will initiate a new bond
sequence against dev 1) and in this case the SC_PASSKEY_IND
will popup with a cod=0 at dev 1).
This has been fixed now by adding a read to the SC_DB if cod=0.
D-1534 HFG/HF: Fixed error in SCO negotiation if application specified
eSCO parameters
D-1535 Changed default sniff mode parameters to 40 in order to follow
the BT spec.
D-1544 BIP: Optimized the BIP code and removed some bugs.
D-1545 AV,FTC,OPC,BPP,CM,SC: A new feature was been made which allowed
the application to cancel a:
AV_CONNECT_REQ
FTC_CONNECT_REQ
OPC_CONNECT_REQ
BPP_CONNECT_REQ
CM_SDC_SEARCH_REQ
CM_SDC_UUID128_SEARCH_REQ
SC_BOND_REQ
D-1547 OBEX/SYNC: Who header length corrected from (10 to 9) in the
obex-sync-server.
D-1548 The compiler define DEFAULT_LINK_SUPERVISION_TIMEOUT has been
added to usr_config.h.
This allows to adjust the default link supervision timeout for
all new ACL links created.
D-1550 OBEX/SYNC: Who header length corrected from (10 to 9) in the
obex-sync-server.
D-1552 SBC:When the SBC decoder decodes an audio signal, encoded with
max amplitude, the output signal occasionally drops to zero at
the peak values. This has been fixed now by fine tuning the
final scaling boarders.
D-1555 BPP: Fixed converter error in BPP related to getEvent,
getJobAttributes, and cancelJob, so it does not forget the
number zero.
D-1559 BCHS: Removed the use of put_message_in, put_message_at and
cancel_timed_message. These functions are planned to be removed
from the BCHS scheduler in the future (date of removal has not
been fixed yet)
D-1560 FTC: In BCHS 15.0.4 FTC always request the link to go to
ACTIVE mode even if it is already in this mode. This has been
change so FTC only request to go to ACTIVE mode if the link is
not in this mode.
D-1561 BPP: Now possible to cancel a job without getting a
disconnection in BPP.
D-1563 CM: In the situations where a peer device releases its L2CAP
connection before it has been configured, the connection
Manager (CM) could go into a state where it keeps rejecting
incoming connection attempts. This has now been fixed
D-1565 TCS: Lib functions has been updated to use bchs_msg_transport
which makes it more easy to split applications from BCHS.
D-1566 Linux: The library: sc_db-file was not built for Linux. This
has now been fixed.
D-1571 HIDD: The device side of the HID profile has now been
implemented conforming to the specifications.
D-1573 Handsfree: Memory leak when a AT command is not encoded as it
should has been fixed.
D-1576 API document updated with additional description, including
examples of how to use library functions.
D-1577 API documentation is updated with additional information on new
library functions and example on how to use all library are
added.
D-1578 PAN: Now only possible to build PAN for HCI and not RFC,
because PAN is only to be runned on HCI-builds.
D-1579 JSR-82: If the JSR-82 layer received a disconnect from the
remote device on an L2CAP connection while sending data,
it could enter a state where it would stop responding to any
signals sent to it. This issue has been cleared up.
D-1581 Handsfree: The body and the data fields are now switched so
that the contents are according to the API document.
D-1583 Handsfree: Length value of the body and the data fields is now
corrected so that the 0-terminations is also included.
D-1584 HFG: Format changed for CIND response, so that the call_setup
element is closed properly.
D-1585 HFG Demo App: OK is now send after HFG demo app has all +CLCC
results to HF.
D-1587 SDP: The SDP layer now does full comparison for 128bit UUIDS,
allowing searches for non-bluetooth (e.g. JSR-82 Java)
applications.
Note: This fix has only been applied to HCI builds.
D-1588 AV: When unregistering the service record when running as
SINK the wrong service record was used. This has now been fixed
D-1595 BCSP: Added init of timer ID to avoid cancelling already
expired timers
D-1597 HF: Fixed problem with string handling for +CLCC. and +CNUM.
D-1600 obex/fts: The connection-ID was wrongly set to 0xFFFFFFFF when
a connection was terminated. This has now been fixed so the
correct connection ID is returned.
D-1605 Handsfree: In the unsolicited +CLIP message send form the HFG a
needed space is added after the ":" so that the message now is
+CLIP: xx, where xx is a number.
D-1606 Handsfree: In different unsolicited message send form the HFG a
needed space is added after the ":" so that the message now
is +CLIP: xx, where xx is a number.
D-1608 Handsfree: The support AT-functions are corrected so that they
are according to the AT specification format.
D-1611 Handsfree: The errors in the function HfSendHfCmeeInd have been
corrected. It is not able to handle a space after :
(example:+CME ERROR: 32) and the digits send in the error code
are not mixed up any more so that a received code is send
corecltly to the app.
D-1613 Handsfree: Implemented signal interface is corrected so that
COPS function will work in HF and HFG API is updated for
HFG_COPS_RES.
D-1614 Linux kernel: The USB driver should have the functionality to
bring the interface into DFU mode.
D-1615 Changed default sniff mode parameters to 40 in order to follow
the BT spec. in the
bchs-api-005_connection_mgm_api documentation
D-1618 HF: Function HfSendClccInd is now able to handle space after :
D-1620 Linux: The userspace part of the USB driver does not support
entering DFU mode or USB reset.
D-1622 Phone Book Access Profile is implemented according version 1.0
of the specification.
The profile has two modules:
PAC is the client side e.g. Car kits
PAS is server side e.g. Mobile phones.
D-1628 BCHS has now been updated to support the BC3MM AV-router
v1.2.2 solution.
D-1630 SPP: Made API for changing low power mode on SPP connections
D-1632 SBC: The SBC decoder has undergone a minor optimization round
to improve the general decoder MIPS performance.
D-1634 CM: If the Connection Manager(CM) receives an incoming L2CAP
connection while the local message l2cap_connect_accept_req is
stored on a local queue, the CM will reject the incoming L2CAP
connection.
This has been changes so if a l2cap_connect_accept_req message
is stored the incoming L2CAP connection is also stored. In this
way the CM will not reject it.
D-1636 BPP: A cancel connect attempt can no longer result in a
BPP_CLOSE_SEARCH_IND.
D-1637 BPP: Made sure that the abort timer is cancelled if a
disconnection happens simultaneous.
D-1641 BPP: Fixed problem with uninitialised memory when using Object
Channel.
D-1642 FTS now sends CmModeChangeReq (for LINK_STATUS_CONNECTED)ONLY
once on rx of CM_DATA_IND while NOT in LINK_STATUS_CONNECTED
and obex is connected.
D-1644 FTS now sends CmModeChangeReq (for LINK_STATUS_CONNECTED)ONLY
once on rx of CM_DATA_IND while NOT in LINK_STATUS_CONNECTED
and obex is connected.
D-1647 Linux: The Linux userspace UART driver now correctly perform
the pthread shutdown sequence.
D-1648 In BCHS 15.0.5 FTC will request the link to go to ACTIVE mode
even if it is already in this mode. This only happens if FTC
receives a FTC_CANCEL_CONNECT_REQ in connected state.
This has been change so FTC only request to go to ACTIVE mode
if the link is not in this mode.
D-1649 Linux USB: A memory leak has been found in the Linux userspace
USB driver in the UsbDrv_Rx() function, where the rx-queue
element itself was not freed after the data has been send to
the stack.
D-1655 Linux user: The USB driver does not use the correct pthread
shutdown sequence.
D-1659 PAC: Added handling for low power mode and cancel connect.
D-1664 HIDH: solved free of non allocated data
D-1665 SPP Demo App: mapping between client and instance number made
more intuitive
D-1672 SAP: Updated Service record for SAP server to be compatible
with WinCE devices
D-1673 FTC: FTC accidently uses more than one timer to control
lowpower. This has been fixed so FTC only use one timer to
control this.
D-1674 HIDH: When calling HIDHConnectReqSend(..) with SdpInfo as a
NULL pointer undefined Memory access is read. This has now been
fixed.
D-1677 HFG: New signal "HFG_STATUS_INDICATOR_SET_REQ" is created to
enable the application to update the actual status indicator on
all link at the same time and in any state of the HFG.
D-1679 AV: Av app. will now receive a negative connect confirm also
when a cancel connect arrives too late to make actual cancel -
when the connection establishement is done but has not yet been
reported to app.
D-1680 An incorrect offset calculation that caused searches for more
than one 128 bit UUID to fail has been fixed.
Note: This fix has only been applied to HCI builds.
D-1681 HIDH: When HIDH luses the connection and should automatically
reconnect. If the reconnect fails, a HIDH_CONNECT_CFM is send
to the application instead of a HIDH_DISCONNECT_IND. This is
Fixed.
D-1682 HIDH: A problem in the HIDH package fragmentation routing which
did not work for packages larger than the MTU size has been
fixed.
D-1685 OBEX: Optimize the OBEX profiles so the clients release the
connection and the servers send a response code with error, if
the peer device sends an OBEX packet larger than agree on.
D-1688 TCS: Doing shutdown the tcs_deinit function did not pfree the
payload in a CM_L2CA_CONNECTIONLESS_DATA_IND_T message, causing
a potential memory leak. This has now been fixed.
D-1691 HIDH: Problems with Connect Accept and Reconnect Flag and
Virtual Cable Flag are True and Normally Connectable Flag is
False. This has been fixed.
D-1694 HIDH: Fixed a memory leak in HIDH which occured when packages
bigger that the MTU size was send. The user payload was then
not free'ed. This is now free'ed.
D-1704 OBEX documentation: Added connected state to the sequence
overview diagram.
D-1740 CM: In BCHS 15.0.6 TCS_IFACEQUEUE were hardcoded into the
Connection Manager (CM). If TCS_IFACEQUEUE were removed from
the bchs_task.h bchs could not compile.
This has now been fixed.
quite list there! will be interesting to see what the possibilities for the magician shall be!
Thanks for the heads up and i look forward to reading more
now to wait for the cab file...
The most important question for me: Will the modem work now?
Good!
Only two questions:
1) When it can be downloaded? From where?
2) That HUGE list of improvements it's really confusing. What is this new stack going to do respect the previous? It's worth install it?
Really thanks to people like wensonlau that discover interessant unpgrades to the magician
Cheers, MocciJ
still no working download to this hotly anticpated release?
What a pity... no one got access.
Was hoping this would make my Magaician work better with my Pioneer Bluetooth head unit....damn dissapointed it hasn't emerged.
UP
where?
I didn't say, I uploaded it. I just meant to put this thread to the top.
Can Anybody please tell me if this works fro Prophet (Xda neo), too ?
I have some Problems with my HT-820....
@meisterlampe2000: just try the older version and you'll know. Or just read the thread about the old version. How to find it? Use the SEARCH function!
SO kind of you !
I`ve read everything now, didn`t expect a different answer from you !
I hope to find a Link to that new Stack soon - Would be nice to listen to Music withoput interruptions.
THX
New version V9 of C# IDE Mobile
C# IDE Mobile is an application (totally free) that I've developed to be able to develop with C#/.NET2CF directly on the Pocket PC-Windows Mobile 5/6 (it doesn't require the .NET SDK, you don't need a desktop computer).
You can download the new version at:
http://www.geocities.com/hrowson/wm5_software/index.htm
or from my personal page:
http://www.geocities.com/hrowson/index.htm
This new version mainly adds the following improvements:
- Fixed issue with declaring size of initialised array (like in "new int[2]{4,6};")
- It is no longer necessary to fully qualify locally declared class names (before you needed to write like "TestNS.MyClass" even if you were already in "TestNS")
- Fixed bug with logical operators on enum types (for example on button.Anchor = AnchorStyles.Bottom | AnchorStyles.Right);
- Manual casting is now supported. Usually, C# IDE Mobile auto casts when possible, but for example, in "int test = (int)AnchorStyles.Bottom" manual cast is necessary. Also, this avoids removing casts required in VS.
- Fixed bug with multiple "if"/"else if"/"else" structures
- "static" keyword now works for arrays and generics, also fixed a problem with indexed assignments
- Added support for nested classes (like System.Windows.Forms.ListView+SelectedIndexCollection)
- Added support for double type
- Improved comment and string parsing (to avoid "//" making a mess in strings)
Harvey
Thanx, looks great
Took me the whole damn night but.... Got it working like a charm
Why isn't there any touchscreen driver in freebsd i could use the protocol from..
I ended up writing it all.. Kernel driver for touchscreen and hardware control, make up a protocol for absolute-input device plus xorg input driver to make it all work there.
It was fun.. it's the first freebsd 8 and xorg input driver i've written..
Kernel driver detects double tab, hold (to right click) and swipes (8 directions)
Swipes left/right give me diverent workspaces, up/down i'll make it do scrolling.
Also i'm building gestures in the driver.. like a circle will rotate Xorg
Some running information;
Shift# uname -a
FreeBSD Shift.parawebs.nl 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 [email protected]:/usr/obj/usr/src/sys/GENERIC i386
Shift# ls -l /dev/ts0
crw------- 1 root wheel 0, 42 Dec 10 14:10 /dev/ts0
Shift# sysctl -a | grep ts\.0
dev.ts.0.%desc: HTC Shift Touchscreen
dev.ts.0.%driver: ts
dev.ts.0.%location: handle=\_SB_.PCI0.SBRG.EC2_
dev.ts.0.%pnpinfo: _HID=PNP0CC0 _UID=0
dev.ts.0.%parent: acpi0
Shift# pciconf -lv
[email protected]:0:0:0: class=0x060000 card=0x10015567 chip=0x27a08086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM Controller'
class = bridge
subclass = HOST-PCI
[email protected]:0:2:0: class=0x030000 card=0x10015567 chip=0x27a28086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile 945GM/GU Express Integrated Graphics Controller'
class = display
subclass = VGA
[email protected]:0:2:1: class=0x038000 card=0x10015567 chip=0x27a68086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile 945GM/GU Express Integrated Graphics Controller'
class = display
[email protected]:0:27:0: class=0x040300 card=0x10015567 chip=0x27d88086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) High Definition Audio'
class = multimedia
subclass = HDA
[email protected]:0:29:0: class=0x0c0300 card=0x10015567 chip=0x27c88086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB Universal Host Controller'
class = serial bus
subclass = USB
[email protected]:0:29:1: class=0x0c0300 card=0x10015567 chip=0x27c98086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB Universal Host Controller'
class = serial bus
subclass = USB
[email protected]:0:29:2: class=0x0c0300 card=0x10015567 chip=0x27ca8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB Universal Host Controller'
class = serial bus
subclass = USB
[email protected]:0:29:7: class=0x0c0320 card=0x10015567 chip=0x27cc8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller'
class = serial bus
subclass = USB
[email protected]:0:30:0: class=0x060401 card=0x10015567 chip=0x24488086 rev=0xe2 hdr=0x01
vendor = 'Intel Corporation'
device = '82801 Family (ICH2/3/4/5/6/7/8/9-M) Hub Interface to PCI Bridge'
class = bridge
subclass = PCI-PCI
[email protected]:0:31:0: class=0x060100 card=0x10015567 chip=0x27b98086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801GBM (ICH7-M) LPC Interface Controller'
class = bridge
subclass = PCI-ISA
[email protected]:0:31:1: class=0x01018a card=0x10015567 chip=0x27df8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) Ultra ATA Storage Controller'
class = mass storage
subclass = ATA
[email protected]:0:31:3: class=0x0c0500 card=0x10015567 chip=0x27da8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) SMBus Controller'
class = serial bus
subclass = SMBus
[email protected]:1:6:0: class=0x080500 card=0x44332211 chip=0x47431947 rev=0x09 hdr=0x00
class = base peripheral
subclass = SD host controller
Shift# usbconfig list
ugen0.1: <UHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen1.1: <UHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1: <UHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1: <EHCI root HUB Intel> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen3.2: <USB 2.0 Camera Sonix Technology Co., Ltd.> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen0.2: <Fingerprint Sensor vendor 0x08ff> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.3: <product 0x005a vendor 0x0409> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen3.4: <product 0x7720 vendor 0x0b95> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen2.2: <product 0x0001 vendor 0x0a12> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
Shift# kldstat
Id Refs Address Size Name
1 38 0xc0400000 b6dfe0 kernel
2 1 0xc0f6e000 1b7b4 snd_hda.ko
3 2 0xc0f8a000 567c0 sound.ko
4 1 0xc0fe1000 4340 ichsmb.ko
5 2 0xc0fe6000 2c8c smbus.ko
6 1 0xc0fe9000 3d80 ichwd.ko
7 1 0xc0fed000 6778 ng_ubt.ko
8 6 0xc0ff4000 d9f4 netgraph.ko
9 2 0xc1002000 df6c ng_hci.ko
10 4 0xc1010000 23a0 ng_bluetooth.ko
11 1 0xc1013000 2d60 ts.ko
12 1 0xc4cb9000 9000 i915.ko
13 1 0xc4cd0000 14000 drm.ko
14 1 0xc6597000 f000 ng_l2cap.ko
15 1 0xc65a8000 21000 ng_btsocket.ko
16 1 0xc65d3000 4000 ng_socket.ko
Touchscreen works perfect now.. after a bit of needed sleep i found out what i was doing wrong with the button mapping and fixed it.
I can now move stuff (windows), select stuff (make selection box), double-tap to double click and hold to right click
Swipes are registered in the kernel module but not yet sent to xorg (swipe screen to scroll / select workspace)
Bluetooth works;
Shift# hccontrol inquiry
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:21:09:d8:d1:2e
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 0x2
Page Scan Mode: 00
Class: 5a:02:0c
Clock offset: 0x170c
Inquiry complete. Status: No error [00]
G-Sensor: I will write a driver for it this weekend.
Fingerprint reader: I'll try and make this one too.
High resolution: Need to decompile some stuff to find out how to trigger it.
3G: will work on it in the weekend
WiFi: Can't seem to activate mine anymore.. i'm guessing a hardware defect
I'm keeping the touchscreen kernel module & driver in alpha status while cleaning it up and add a few more features.
If anyone FreeBSD lover wants to try this on his/her shift contact me for alpha the drivers.
Also if more ppl like to help making drivers for the shift.. you are welcome!
More updates will follow here when i get more stuff working
I'm ecstatic about this. Keep up the good work.
wouhou great news!
Hi,
do you plan to release your drivers ?
i m really interested
thanks a lot
That is really great work
Im not a *nix user , but I understand the beauty of what you are doing!
Great job!
hi do you have news ?
i m really interested
thanks
okay, this is really nice,
is there any possibility to port this to fedora or ubuntu?
i really like those distro's.
nevertheless i would like to look into your sources after you finish cleanup,
i'm cheering for you!
Forgot about this topic
Hi there,
Sorry i kinda forgot this topic.
My Shift is still running FreeBSD and it still runs fine.
I'll pack the drivers and upload them here for anyone to mess with.
Touchscreen kernel module
Here is the kernel module to create the /dev/ts0 device for userland to talk to.
There's also a simple control utility to change some button settings/timings in the module on the fly.
You need to move the ts folders to the kernel source tree in the right location.
/usr/src/sys/modules
and
/usr/src/sys/dev
then type
cd /usr/src/sys/modules/ts && make && make install && kldload ts
To compile the control utility type
gcc tscontrol.c -o tscontrol
ps. the swipe debug messages are still visible in this version.. you may want to change that in ts.c before you compile it
I'll upload the xorg input driver in a minute.
xorg driver for ts module
Here is the xorg input driver that talks to my kernel module via /dev/ts0.
Extract it and type
cd ParaTouch && make && make install
add it to your xorg.conf like this;
Code:
Section "InputDevice"
Identifier "TouchScreen"
Driver "void" # oops i forgot to rename the sceleton :(
Option "Buttons" "5"
Option "ZAxisMapping" "4 5"
Option "MinX" "15"
Option "MaxX" "2000"
Option "MinY" "110"
Option "MaxY" "1940"
Option "Device" "/dev/ts0"
EndSection
Calibrate with changing MinX -- MaxY.
(the forum only accepts zip archives so i had to zip the tar)
Wow amazing work. Had to join this silly forum just to download your code.
Has this been made available to the FreeBSD base? I think there are a lot of folks over there who would be quite interested.
segfault007 said:
Had to join this silly forum just to download your code.
Click to expand...
Click to collapse
Wow. Classy.
This "silly" forum was the only way for you to get that code.
But apparently that didn't register when you wrote your post.
*shakes head*
Very very nice!!!
I know this is kinda an old thread at this point but if you are still monitoring it, I was wondering if you knew/know if this driver will work with other touchscreens?
Reason I ask is I have a Samsung Q1 Ultra that I would love to load FBSD on, the only thing holding me back is no working touchscreen. I was intending to use it as a Media Remote locked on a web page that does the actual "work"
Right now I am using Linux on it but would MUCH MUCH prefer to use FBSD instead as I really prefer FBSD over linux
BSD for SurfacePro
Hi OS,
Do you know how this can be done for the Surface Pro? Using say... PC-BSD.
thanks,
Anan
Do want
I would be fascinated to see this running - BSD has always been my preference
Curious, I'm not familiar with the Shift, is it an android device?
Intel / Infineon XMM6260 & X-GOLD 626 Modem Hack-Pack Release!
After several unsuccessful months of trying to get my phone (application) to
talk AT-commands with the baseband processor (BP), I've had to learn a lot of
hardware and internal Android and OEM based tricks and secrets. Although this
have not been enough to make anything of practical use, it is definitely worth
sharing. If not at least some more talented people may be able to continue
where I have left of...
Now, it should be immediately stated that there is nothing revolutionary
in here, apart the Infineon manual for tuning your GSM modem, using the
AT CLI and GTI sequencer. This is something that could potentially be very
useful for better understanding the advanced features that the modem
platform incorporates. However, it is also a sure way of making a an
expensive brick out of your phone! You have been warned...
Brief Modem Description
The XMM6260 is the "platform" that consists of:
The X-GOLD 626 baseband processor
The SMARTi UE2 RF-transceiver DSP
The 3GPP Release 7 HSPA+ protocol stack with:
Downlink: Category 14, Uplink: Category 7
The X-GOLD 626 baseband processor (labelled "PMB 9811") is communicating
with the DSP RF-tranceiver chip called SMARTi-UE2 (labelled "PBM 5712 A1"),
using a communication interface that corresponds to the MIPI DigRF-3G
(V.3.09) standard. Through this protocol the BP can control some or all
aspects of the RF DSP.
Alternative Names
Infineon IFX6260
Intel IMC6260
Intel XMM626
Some other devices using this platform:
Code:
- Lava XOLO X900 [Phone] FCC ID: ???
- Lenovo K800 [Tablet/Pad] FCC ID: ???
- LG-P920 (LG ?) [Phone] FCC ID: BEJP920
- LG-P925 (LG Optimus 3D?) [Phone] FCC ID: BEJP925
- Huawei E369 (3G Hi-Universe) [USB 3G Modem] FCC ID: QISE369 (Russian distrubutor: Merlion)
- Huawei MU733/MU739 [PC/CE Module] FCC ID: QISMU739
- Samsung Galaxy Nexus (I9200) [Phone] FCC ID: ???
Other devices that may (!?) also contain the X-GOLD 626:
---------------------------------------------------------
- LG Optimus 4X HD [Phone] FCC ID: ???
- HTC One X [Phone] FCC ID: ???
- Huawei Ascend D Quad [Phone] FCC ID: QIS ???
- Huawei E392 (E392u-511) [LTE Multi-mode USB stick] FCC ID: QISE392U-511
- Huawei E353 (E352s-6) [HSPA+ USB stick] FCC ID: QIS ???
Hack-Pack Content
Code:
- Pictures/Diagrams:
- XMM6260 colored pinout map
- XMM6260 mounted in a Samsung Galaxy S2
- SMARTi UE DSP RF-tranceiver chip mounted in the SGS-2
- IPC xxxxxx stuff
- Infineon PhoneTools testing program
- Raw 1byte greyscale PNG of modem.bin from XXKI1
- PDF files/documents:
- ITA-RF-Adjustment-GSM (XMM6260 Specification)
- Infineon MIPI-HSI Product Brief
- X-GOLD 616 Product Brief
- Fairchild FSA9280/88A USB/UART switch/MUX datasheet
- Similar Modem AT sets/documents:
- AT_Command_Set_3GPP-TS-27007-940.pdf
- AT_Command_Set_AMOD_HSPA.pdf
- AT_Command_Set_Gobi.pdf
- AT_Command_Set_Motorola_XM7200S.pdf
- AT_Command_Set_Teltonika_TM3.pdf
- AT_Command_Set_iWOW_TR-900.pdf
- Text Files:
- 3GPP 27.007 AT-list
- XMM6260 official AT-set
- XMM6260 internal AT-set
- XMM6260 homebrew specifications
+ X-GOLD 626 Modem pinouts
+ MUX pinouts
+ AP connections (SGS2)
+ AP relevant info
- Strings of modem.bin (stock firmware image: [B]XXKI1[/B])
- Strings of drexe
- Strings of rild
- Strings of libril.so
- Strings of libsec-ril.so
- GT-I9100 stock (GB 2.3.4) binary files:
(Taken from: PDA:[B]XWKI4[/B], Phone:[B]XXKI1[/B])
- libKiesDataRouter.so
- libril.so
- libsec-ril.so
- libsecril-client.so
- drexe
- rild
- Android hardware hacking binaries (tools):
- dbus-monitor
- dbus-send
- hciconfig
- hcidump
- hcitool
- i2cdetect
- i2cdump
- i2cget
- i2cset
- ipcfilter
- ipcdump
- ipctool
- procmem
- showmap
- showslab
- strace
- tcpdump
- viewmem
+ various other content
Download Here! (57.72 MB)
The modem firmware referred to and studied can be
found here (Modem.bin.7z) or here, under "XXKI1".-------------------------------------------------------------------------------
DISCLAIMER:
All the material in this collection was found on internet by
appropriate Google-Fu and/or by laborious manual creation.
Nothing is stolen or reversed, so I am not held responsible
for the origin or problems affiliated with the use of these
documents, programs or other binaries.
-------------------------------------------------------------------------------
If you are a developer or other corporate official of Intel or Infineon:
Please contact your superiors and ask them to release the proper
datasheets and documentation of these products to the public.
Why? Because:
It would significantly increase the sales of your hardware, by promoting
a much more open approach to hardware development. There are currently
more than 10 open-sourced and open-hardware smartphone projects around
the world, who would benefit from the use of a more modern baseband than
what is currently and openly available.
.
It would significantly promote your hardware in front of your competitors,
as your company would be the first one to open up your documentation to the
public. Thus increasing public technical knowledge of your hardware, which
would ultimately lead to you having an easier time to find qualified
developers that cost you less!
.
It would significantly reduce the cost and time for firmware development,
while increasing the firmware code-quality and compatibility, as you
would be able to benefit from the large community and knowledge from
other professional developers as well as hardware-hackers.
(Yes, there are several bugs found in your firmware, but since there is
no way to report and discuss these with your developers, they will
continue to cost you money and head-scratching for all developers
having to deal with your platform.)
.
Your competitive advantage due to 1-3, would promote new and better
future hardware developments, that would not only benefit your
company/business but also society as a whole.
.
Its simply the right thing to do!
The thread where all this become crisply relevant is this one:
[A][SGS2][Serial] How to talk to the Modem with AT commands
There you will find all documents which I have found to date, which
is essentially none. At least nothing that can be of ANY practical use.
UPDATE: [2012-04-17]
As soon as I get a chance I'll update the HackPack (HP) with new data regarding the MUX
and some other hardware used in the SGS2. This data, as presented within HP, is simply wrong!
Reserved 2 me 3
Awesome info I was also thinking looking at the ServiceMode application in the SGS2 could provide interesting information. BTW, do you know if the X-GOLD has a diagnostic mode similar to the one usually found in Qualcomm modems?
xd.bx said:
Awesome info I was also thinking looking at the ServiceMode application in the SGS2 could provide interesting information. BTW, do you know if the X-GOLD has a diagnostic mode similar to the one usually found in Qualcomm modems?
Click to expand...
Click to collapse
Thanks! The ServiceMode app is mostly interesting because its code actually reside inside the Modem firmware, where the java app is acting as a wrapper. I'm not familiar with the Qualcomm modems, could you elaborate on what that "diagnostic mode" does? (The x-gold firmware is FULL of various modes. Just depends on what you want to do, and to get the proper documentation on how to use it!)
Just found ... a bit older, but still very interesting
http://hwplatform.googlecode.com/svn/trunk/Infineon/
RNC States from libsec-ril.so
Hi
Very valuable information! Does anyone have an idea about how to get the information displayed from serviceMode programatically? Looks like most of it is being polled directly to the libsec-ril.so. In my case I'm interested in obtaining information about the RNC states on the handset
Thanks for this information
Thanks for the info E:V:A. I did quite some figuring out about the Radio/DSP unit of the Nokia DCT3 back in the day and also the GSM protocol (anyone remember Project Blacksphere / OpenGPA?).
Things have likely come a long way since then. One thing that is clearly different is that the baseband processor is completely isolated from the application processor. In the DCT3 there was one ARM processor that drove both the user interface and parts of the GSM protocol, and connected to a DSP for the low-level radio stuff.
I wonder how other things have changed with 3G. I may get back in the game. This will give me an headstart
Memory map and boot process
It appears that modem.bin consists of multiple partitions that are loaded separately at bootup of the device, reflecting the modem boot up sequence in libsec-ril.so:
Code:
Offset Size Address Description
0x000000 0x00f000 0x00800000 PSI
0x00f000 0x019000 0x60000000? EBL
0x028000 0x9d8000 0x60300000 Main image
0x9ff800 0x000800 Used for verification (buliding ReqSecStart command)?
0xa00000 0x200000 0x60e80000 NV data (file contains default data)
0xc00000 0x000200 Unused?
Offset is offset in file, address is flash/ram offset on device. Whereabouts about the EBL are a bit unknown, address 0x60000000 is based on a guess the others are sure.
Also I did an attempt at constructing the run-time memory map of the device, based on static analysis but as I've not found a way yet to actually probe it there are quite a few question marks.
Code:
Device memory map:
0x00000000 RAM/ROM? (what is here?)
0x00080000 PSI bootloader *RAM*
0x40000000 Flash (what is flashed here?)
0x60000000? Code (EBL)
0x60100000 Flash
0x60300000 Code (Flash)
0x60e80000 NVram data (Flash)
0xe0000000 Peripheral mapping for memory-mapped I/O (256MB)
0xffff0000 Memory (initial stack)
As for I/O devices in peripheral mapping, my understanding is still very limited and based on the bootloader only. I have a longer list of addresses from static analysis, but as I can't yet label anything it is pointless to publish. As usual, the upper bits (how many? 8?) select which peripheral, the lower bits (20?) select a port within that peripheral.
Code:
0xe4d00164 ? status bits
0xe4d00384 ? status bits
0xe8000070 ? status bits
Entry points:
Code:
Offset Address Description
0x000000 0x00080000 Boot loader
0x00f400 0x60000000? EBL
0x1a8000 0x60480000 Main stack
I'm trying to run this in QEMU and created a basic environment, but as my understanding of ARM kernel space (interrupt handling, timers, etc) is very limited, it currently gets stuck in a loop waiting for some other thread (or interrupt handler) to update an address.
just thought it might be of interest and help - http---en.samaanet.com/?p=2390
direct link:
http://en.samaanet.com/?p=2390
Polarfuchs said:
direct link:
http://en.samaanet.com/?p=2390
Click to expand...
Click to collapse
That's a direct rip-off of my XDA thread!
Any more posts with such links will be removed!
How should I know, I just posted the link as "service" because the user above me could't post links.
I've been informed that the download link doesn't work. i will upload again as soon as I have time...
Really interesting stuff you have got here.
One thing I've been searching for a while now: I own a Galaxy Nexus, which has a XMM6260 modem. Samsung had on their stock ROM a feature in service mode where you can check the power modes of the 3G data connection. Since the Galaxy S2 has the same modem, thus it should be possible to get that feature.
I'm interested in this stuff because my Galaxy Nexus likes to drain like crazy on the 3G network that I use and I suspect that it has to do with the 3G data power modes. 3G+wifi is extremely efficient in power use but 3G+mobile date is al big battery hog.
I hope you post a working link soon, than I can start reading this stuff.
Seems like this might be the best place to ask this... I also asked in the "fun with AT commands" thread so my apologies up front for the spam.
I'm looking for a fastboot friendly radio baseband I can flash with a 4.2.1 friendly RIL. This may be more than what I actually need but I've got a full telephony build of the Nexus 7 3G going and while SMS and MMS are fully functional I'm getting a CME ERROR: 4 when I try to do voice dialing and don't see anything coming in via logcat on an inbound call.
The mobile plan I'm using is full voice capable and verified as functional.
Doing a strings of the included RIL (libxgold-ril.so) shows all the necessary voice functions listed (although I guess this could be a false positive if it is interface based).
The modem mounts up on /dev/ttyACM0 and I'm able to do all the basics with radiooptions, except voice dialing and answering of course.
Any pointers / advice / direction would be greatly appreciated... coming up to speed real quick in this area.
XGold626 One X Pinout
I have removed my BB CPU and here is the pinout if it helps anyone
How to start?
I'm a rookie so is anyone can provide a step-by-step tutorial about how to send AT commands to the baseband processor directly? Right now I only can use i2cdetect to list i2c channels, but how to do next?
Thanks,
Andong
XGold 626 Reversing
witchspace said:
It appears that modem.bin consists of multiple partitions that are loaded separately at bootup of the device, reflecting the modem boot up sequence in libsec-ril.so:
[snip]
Click to expand...
Click to collapse
Hi!
Nice work. I'm working on reversing the xgold626 baseband as well. Specifically, I'm looking at the NELK2 baseband for my GT-i9300.
Perhaps we could join forces? Anyone else working on reversing the xgold626 baseband is welcome to contact me as well.
I'm reachable at: je at clevcode.org, or on my ircd (irc.clevcode.org, port 7000, SSL, nick je).
Cheers,
Joel
witchspace said:
It appears that modem.bin consists of multiple partitions that are loaded separately at bootup of the device, reflecting the modem boot up sequence in libsec-ril.so:...
I'm trying to run this in QEMU and created a basic environment, but as my understanding of ARM kernel space (interrupt handling, timers, etc) is very limited, it currently gets stuck in a loop waiting for some other thread (or interrupt handler) to update an address.
Click to expand...
Click to collapse
clevcoder said:
Specifically, I'm looking at the NELK2 baseband for my GT-i9300. Perhaps we could join forces? Anyone else working on reversing the xgold626 baseband is welcome to contact me as well.
Click to expand...
Click to collapse
Yep, that is very interesting. Send me PM if there are more interest in pursuing this further! What's the primary interest of doing this?
Hi,
I am currently trying to write an application that connects to a bluetooth module and sends it some data.
At the moment the app is capable of doing the following things:
- enable/detect bluetooth
- discover devices
- create a socket
However, once the socket is created I try to use the connect() method. This method failes every time, giving me the following errors :
get bluetooth service() called with no bluetooth manager callback
DISCOVERY_COMP_EVT slot id:4, failed to find channle, status:1, scn:0
invalid rfc slot id 4
java.io.IOException: read failed, socket might closed or timeout, read ret: -1
at android.bluetooth.BluetoothSocket.readAll(BluetoothSocket.java:505)
at android.bluetooth.BluetoothSocket.readInt(BluetoothSocket.java:516)
at android.bluetooth.BluetoothSocket.connect(BluetoothSocket.java:320)
at app.bluetooth.bluetoothcommunicationv1.ConnectThread.run(ConnectThread.java:53)
ConnectThread.java line 53 is this line :
mmSocket.connect();
where mmSocket is a BluetoothSocket
I have tried to fix these erros in various ways but I havent found a single solution that works for me, so I was hoping someone has had this problem before and remembers how he/she fixed it.
I have been looking around at the examples that can be found at the android development site, watched a youtube tutorial series, found some code on git but they all use the code that can be found in the google API about bluetooth.
And it is this code that is not working for me.
I am a new user so apparently I am not allowed to post links, the code I am using is found on the Bluetooth API page from google (connecting as a client).
I could really use some help to get me back on track with my app.