Hi Michael, Correct, for the SE connected through NFC-WI/S2C, the NFC controller has > three modes: off, wired and virtual mode. Off means that there is no > communication with the secure element. Wired mode means that the secure > element is visible to the application processor as if it was a > (contactless) smartcard connected to the RF reader. Virtual mode means > that the secure element is visible to external readers as if the phone > were a contactless smartcard. > > That's right.
> From what I've read in the PN544 User Manual, I don't think that there > is an equvalent for the wired mode with SWP/HCI (I would be happy to be > proven wrong). Usually for the "wired mode", the contact interface of > the UICC would be used so it wouldn't really make sense if the NFC > controller allowed for an additional* channel between the UICC and the > application processor. > > *) "Additional" once the RIL supported APDU exchange with the UICC. > > Well, here is where the *phHal4Nfc_Switch_Swp_Mode() *comes*. *It is analog to the *phHal4Nfc_Switch_SMX_Mode() *which is used to set the wired mode to work with the SmartMX. In function *phLibNfc_SE_SetMode() *when told to enable wired mode it ignores to enable it if secure element is UICC instead of SmartMX. In this last case it uses *phHal4Nfc_Switch_SMX_Mode() *with the parameter *eSmartMx_Wired. *I modified the function to use *phHal4Nfc_Switch_Swp_Mode() *with parameter *eSWP_Switch_On *(this parameter has an incorrect value by default, it must be enabled by using nemik's patches). This function (phHal4Hnfc_Switch_Swp_Mode()) succeeds, which makes me think there could be a "wired" SWP mode. Although the SWP mode is enabled, no SE seems to be detected this way. When opening SMX in wired mode from *com_android_nfc_NativeNfcSecureElement_doOpenSecureElementConnection() *the callback is called twice after calling *phLibNfc_SE_SetMode(). *However if SWP is enabled (using external SE element) callback is only called once after *phLibNfc_SE_SetMode(). *If we avoid waiting for second callback * phLibNfc_RemoteDev_Connect()* always fails (internally no SE has been discovered). When it comes to RIL issue. I patched the sources with SEEK diffs too but rild daemon crashes. SEEK mantainers say it is due to baseband processor not implementing required (AT+CSIM, AT+CCHO, AT+CCHC, AT+CGLA) commands ( http://code.google.com/p/seek-for-android/wiki/UICCSupport). Is there any way to reverse engineer baseband firmware or get access to a modified version implementing those commands? Or has anyone discovered whether Samsung has other propietary commands achieving the same results (raw APDU exchange with SIM/UICC)? regards, Fernando > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
