yashsingh1/xdaforums huggingface dataset:
[NFC Hacking] oxplot:
Seeing how my technical expertise is lacking in revving the binaries, etc., I thought I contribute by asking NXP nicely, to provide us with the source code.
[NFC Hacking] oxplot:
I got a reply back to file a tech support ticket - did so. Will keep you posted.
[NFC Hacking] heydabop:
Look at this change that was just merged into CM11

http://review.cyanogenmod.org/#/c/69594/

"Adding NXP NCI Hal implementation"

Sounds like we might be getting somewhere!

Compiling a build for my find7 now
[NFC Hacking] abuttino:
First of 4 commits.. Hmm wonder what the others will entail
[NFC Hacking] osm0sis:
Actually looks like it's a squashed commit of all 4. :)

I'm forwarding it to a couple clever GN ROM devs who've expressed interest in getting NFC HCE working for our PN544. :good:
[NFC Hacking] heydabop:
Yep, the referenced change IDs don't exist in gerrit, so I assume it's a bunch of commits smashed into one change.
[NFC Hacking] ajm786:
This is certainly good news, and took long enough. :) Hopefully, it gets working on our HLTEs.
[NFC Hacking] heydabop:
So going off of this https://github.com/CyanogenMod/andr...mmit/446d55284f5b39417efdf77be2c843fc14c0ff6b it they may only be building it for the bacon right now. I may try giving my find7 the same config just to see what the outcome is. Tho I guess it's a pn547 vs a pn544... However, the change makes references to pn54x, as do recent changes in AOSP gerrit.
[NFC Hacking] ajm786:
It was probably just tested on the bacon. However, I checked the changelog for my phone, the HTLE, and the commit is there.

http://www.cmxlog.com/11/hlte/
[NFC Hacking] heydabop:
Yes, because that commit isn't device specific. However, to actually build the files of that commit, your device's BoardConfig.mk must set BOARD_NFC_CHIPSET to equal pn547, which the HLTE does not do, so it won't be built into an HLTE build.
[NFC Hacking] osm0sis:
I could be wrong, but I think that is just where you specify what your chipset is, and doesn't necessarily have to be "pn547" for the build; the other part of that commit looks like what makes it build.

Edit: Nope you're right. ;)

Android.mk:

ifeq ($(BOARD_NFC_CHIPSET),pn547)
include $(LOCAL_PATH)/halimpl/pn54x/hal.mk
else
...

That'd be easy to workaround though. You could add an "or pn544" to see how much they managed to generalize it.
[NFC Hacking] TheWhisp:
I tried this on my Express 2 with pn547. First, the firmware lib from 4.2 (non-nci stack) was outdated. I took a newer one from a Sony device (NCI stack). Now the firmware could be updated. However, I ran into some other issues. (too old nfcee, NCI version mismatch - according to logs).

The kernel driver is, I assume, quite generic (by Trusted).

Sent from my SM-G3815
[NFC Hacking] blueether:
Giving this a shot on the Z-Ultra GPe, pn544 will report back on the outcome. [MENTION=3526949]heydabop[/MENTION] got the AOSP changes?
[NFC Hacking] heydabop:
I was actually looking at this more earlier today and noticed the AOSP change and CM change differ some. There's also another related AOSP change that didn't seem to be in CM at all, tho I couldn't tell if it actually mattered. I'll get the exact changes tomorrow

Sent from my Oppo Find 7A
[NFC Hacking] Entropy512:
Last I checked, despite saying "PN54x" it really only does PN547.

I can tell you without a doubt that the NCI HALs on bacon fail spectacularly on Find 7/7a. But now that there is source for this stuff, it could be more useful.

Edit: I'm going to look into what differences there are if you configure it for PN65T - maybe this is PN544-backwards-compatible

Edit 2: There's references in the source to crespo... If I can't figure out how to get it to work with a 544 it's going to be a massive DAFUQ?
[NFC Hacking] Entropy512:
So far, the source-based HAL behaves just like the OnePlus blob - one of the commands causes the chip to seem to hang, with any further attempts to interact with it returning NFCSTATUS_BUSY.

I may still be missing some configuration item though. At least now I have source so I can trace through what it's doing.
[NFC Hacking] TheWhisp:
Any ideas why I get this "nfcc is too old, failed to reset nfcc". Been stuck on this for a while. I assume nfcc stands for NFC chip?

I/BrcmNfcNfa( 3797): NCI version mismatch!!:0x10 != 0x00
E/BrcmNfcNfa( 3797): NFCC version is too old
E/BrcmNfcNfa( 3797): Failed to reset NFCC

Sent from my SM-G3815
[NFC Hacking] Entropy512:
Weird, I don't recall seeing that in my logs but I could have screwed up in reading through them.

I'm 90% certain that is the HAL saying that the chip is too old.
[NFC Hacking] osm0sis:
Looks like the wrong drivers, considering it says Brcm. :good:
[NFC Hacking] TheWhisp:
Broadcom is the author of NCI stack.

According to the developer that pushed the source to AOSP, the first CORE_RESET_CMD returns bad value, meaning that obviously something doesn't work properly, my best guess is firmware.

D/NxpFwDnld( 1074): @@@/system/vendor/firmware/libpn547_fw.so
D/NxpFwDnld( 1074): FW Image Length - ImageInfoLen 34654
D/NxpFwDnld( 1074): FW Image Info Pointer - pImageInfo 5f8080ec
D/NxpFwDnld( 1074): MW Major Version Num - 2
D/NxpFwDnld( 1074): MW Minor Version Num - 5
D/NxpFwDnld( 1074): FW Major Version Num - 1
D/NxpFwDnld( 1074): FW Minor Version Num - 12
D/NxpFwDnld( 1074): FW Image Length - 34654
D/NxpFwDnld( 1074): FW Image Info Pointer - 5f8080ec
D/NxpHal ( 1074): FW version for FW file = 0x112
D/NxpHal ( 1074): FW version from device = 0x60315

The firmware version on device seems suspicious.
[NFC Hacking] Entropy512:
Hmm, interesting. What might be useful is adding debugging to a "classic" PN544 NFC stack (the one in AOSP) to print out firmware version.

Are you talking about Mr. Liao at NXP? The stack is named pn54x - but can he confirm this actually supports anything other than a PN547?
[NFC Hacking] TheWhisp:
I sent him full logcat and he then replied, I quote, "unfortunately your device doesn't qualify for CM11". I'm not sure what he meant by that but he hasn't responded after that.

Theoretically, shouldn't the device's FW be the same as the FW on lib? If I use the same lib that is used to download firmware on stock ROM. Or the firmware is preloaded in factory and never has been updated?

Sent from my SM-G3815
[NFC Hacking] Entropy512:
Huh? I'm confused, why is an AOSP contributor talking about CM11? Who exactly did you contact?

One problem is, as you can tell from the name, the firmware library's name implies that it is intended for a PN547. That's one of the big open questions here - the patchset pushed to AOSP calls it "pn54x" however a lot of aspects of the patchset imply that it's only for PN547 and not PN544.

The libpn544_fw.so used by the "old" NFC HALs and the libpn547_fw.so used by "new" HALs seem to be significantly different from each other - more evidence this patchset isn't meant for PN544 devices.

The problem is that the only device actually USING this HAL so far is a PN547 device - the OnePlus One. There's basically no documentation/reference implementation for using it with a PN544, except for line 26 of https://android-review.googlesource.com/#/c/103142/1/halimpl/pn54x/Android.mk - This is really weird since it has crespo/herring stuff, but crespo/herring (Nexus S) hasn't been supported by AOSP for 2-3 major Android revisions.
[NFC Hacking] TheWhisp:
I mentioned that in the e-mail I sent him [to Jizhou Liao]

Actually, a Sony device is also using it: https://github.com/TheMuppets/propr...11.0/castor_windy/proprietary/vendor/firmware (if you didn't meant the open sourced stack)

Perhaps the Crespo code is just a leftover, I mean, maybe they tried to make it work for pn544 using it as a test device or something.

Based on this "-DNXP_PN547C1_DOWNLOAD" flag and https://github.com/CyanogenMod/andr....0/halimpl/pn54x/dnld/phNxpNciHal_Dnld.c#L583

it seems there are even 2 versions of pn547 - C1 and C2
[NFC Hacking] Entropy512:
OK, so Z2 family has the 547. hlte (Note 3) has it too I believe.

As to C1/C2 - yeah, the 544 apparently had quite a variety of revisions too. https://plus.google.com/+AndrewDodd/posts/BeH79KUW4ey
[NFC Hacking] azreark1:
So I've been following this thread hoping to hear some good news, and though I've read some semi positive looking replies lately, I wonder why it seems such a big deal that NXP can't just fix this problem from their end? There's missing functionality and it seems they don't want to fix it...but by keeping everything closed source it prevents someone else from fixing too. Is nfc in phones a guarded secret or something?
[NFC Hacking] Entropy512:
Plenty of companies believe that their driver interfaces are some deep dark secret that needs protection. It has been this way for years.
[NFC Hacking] gk1984:
What ever came of the OP politely asking for assistance from NXP support?
[NFC Hacking] Entropy512:
Nothing, except possibly this NXP submission to AOSP which still doesn't help 544 users.
[NFC Hacking] gk1984:
Then we need to let NXP their generous contribution is broken...
[NFC Hacking] Entropy512:
Not necessarily broken... Just not applicable to older (but very common) chipsets. All newer devices are moving to the 547 which this does support.

Honestly, their submission is already fairly broken as it is, their HAL naming scheme is completely nonsensical
[NFC Hacking] oxplot:
Thanks guys for working on this.

Assuming NXP's contribution was in response to the tech support ticket I filed a while back (although it seems unlikely as it was within a week of my ticket), then it's worthwhile to letting them know more is needed.

From reading the comments so far, I see that the new code's support for PN544 is evidently non-existent and even for PN547 it's not looking very good. Is there anything specific that I should mention in addition to get a faster response?
[NFC Hacking] Lu X:
They have 5 days to respond you didn't get any informations?

PS: it's look like SimplyTapp (wallet, like google wallet, from CM guys) working fine with all NXP and Broadcom chipsets, is it possible?
[NFC Hacking] oxplot:
Nope, they haven't replied yet.
[NFC Hacking] Lu X:
We are saved, android 4.4.4 give us HCE support :)
[NFC Hacking] heydabop:
If I'm not mistaken, this entire thread is about getting things to work on 4.4.4.
[NFC Hacking] Lu X:
Last 2 pages was about it. Read all thread.
[NFC Hacking] osm0sis:
If you read it thoroughly you'd see the majority of the chips/devices we care about still don't have it.
[NFC Hacking] Lu X:
Most posts were here before 4.4.4 did you check all chips after update? I've checked 3 so far and they have HCE support nów. I read every single post here.
[NFC Hacking] osm0sis:
I believe the verdict from the previous few pages was still that the pn547 chips may have some added support, closed or open now but every pn544 device is still currently screwed. That's a lot of devices!
[NFC Hacking] Entropy512:
Correct. PN544 devices that OFFICIALLY received 4.4 have HCE support via some closed-source libraries.

So far no one has successfully gotten those closed-source libraries to "play nice" with an open-source firmware, or transplant them to another device - so people on devices with PN544 chips that never got official 4.4 are screwed, as is anyone wanting to run a source-built firmware package.

4.4.4 brought NOTHING that wasn't present in earlier 4.4 releases as far as HCE goes. (The PN547 stuff is in AOSP master, which has nothing to do with 4.4.4 - 4.4.4 only contained a few small security fixes.)
[NFC Hacking] osm0sis:
Hah! Both of the new iPhone 6s have NXP pn544 controllers! Obviously not a dead chip yet!

NXP needs to get their **** together for Android and open source that sucker. :rolleyes:
[NFC Hacking] gk1984:
Apple really is behind...
[NFC Hacking] Entropy512:
Interesting. Well, we know it supports HCE (See HTC M7 with KitKat) - it's just closed-source so far. Which isn't a problem for Apple.

ALSO - Based on what I've seen so far, Apple Pay is not using HCE. It appears quite similar, actually, to the original first-generation Wallet solution. (Using an SE with credentials that come directly from the payment card issuer, as opposed to a "proxy card" like second-gen Wallet with SE and third-gen HCE Wallet.)
[NFC Hacking] gzowner:
so we assume this hack has been dropped?
[NFC Hacking] Entropy512:
What hack? There was never anything working on PN544, not even terribad hacks like attempts to swap entire blobsets from a device that had it.
[NFC Hacking] ajm786:
This looks a bit promising for my phone at least (HLTE).

http://review.cyanogenmod.org/#/c/74099/
[NFC Hacking] Entropy512:
Your device has a PN547 (same chip as the OnePlus One), so I'm actually surprised it isn't already working.

PN544 devices are the ones that have issues with HCE.
[NFC Hacking] ajm786:
I've always been under the impression that all NXP chips that have a PN54x chip has not ever worked under AOSP other than the bacon (OnePlus One).
[NFC Hacking] Entropy512:
You obviously haven't read this thread at all in the past month... NXP pushed PN547 support to AOSP back in July or August. Even before that, there is lots of documentation that the 547 is NCI-compliant, so worst case you need the appropriate HAL blob. But the 547 is rare - hlte and bacon, along with maybe Sony Z2, are the only devices I know of that have it. Everything else either has a Broadcom chip or a 544.

It's the 544 family (which are not NCI compliant) that are the problem as far as HCE.
[NFC Hacking] ajm786:
I really want NFC to work on my device, and I actually do read this thread (subscribe to it actually), so that was a bit uncalled for.

I guess it's a bit of confusion for me, because I'm reading that on the T-mobile HLTE variant (which I have), Samsung used a different NFC chip for no real reason. Let me see if I can cook up the thread discussing that.

Also:

http://review.cyanogenmod.org/#/c/74100/
[NFC Hacking] raddatt:
Just came across this article; as a noob, I wonder what it means for us?

http://www.eetimes.com/author.asp?section_id=36&doc_id=1324531

Sent from my Oppo N1 using ugly ass XDA app.
[NFC Hacking] ProperNoun:
They're talking up the next iteration of their hardware so... it doesn't really mean anything for us or other current devices.

BTW, I checked out the source for LP and from what I can tell we are still screwed with NXP chips. Last commits were from early this year and no mention of hce at all.
[NFC Hacking] Entropy512:
Pointless. Every NXP NFC chipset since the PN544 has included an option for hardware SE (PN65N in the case of the 544 if I recall correctly). For various reasons, Google moved AWAY from this. In fact, the biggest change with Lollipop was a complete REMOVAL of the remnants of embedded SE support, since the only thing that ever used it (Wallet) doesn't any more in favor of HCE.

The whole point of HCE is to not require that additional hardware component.
[NFC Hacking] sddfdds:
so this dream is pretty much dead, isnt it?
[NFC Hacking] TXKSSnapper:
https://github.com/CyanogenMod/andr...mmit/bd72931dd0b21dc85a075008351c6426eec741c6

This commit to CM is building the open source nfc hal for the pn544. I haven't looked too much into it, but it does have mentions of card emulation in the source. Is this any different than things people have been trying in this thread? Sorry if this is something obvious or thats already been mentioned.
[NFC Hacking] Entropy512:
The PN544 NFC "HAL" in AOSP is actually just a blob that contains various configuration data and not much else. The real HAL (that actually talks to the hardware) is elsewhere.

Also, Host Card Emulation is a specific subset of the categories of Card Emulation. The PN544 has always had card emulation - it's just that Android has never supported Host Card Emulation on that hardware, or at least, not in opensource form. The card emulation comment you see there is related to how devices with an embedded or SIM-based secure element behave when a reader's RF field is present.

Nearly everything in that "HAL" got moved to human-readable configuration files with the NCI HAL (used by Broadcom chips and the PN547)
[NFC Hacking] blueether:
Has anyone looked at the aosp and kernel that Sony has released for the xperia Z1 and up family? I bleve that card hosting works in the US on the ZUltra and Z1. Hopefully Sony release the code. Also the binary blobs from the Z1 on their dev site?

sonyxperiadev on github
[NFC Hacking] Entropy512:
I believe the ZU had a 544, and does have HCE-capable NFC, but it's the closed-source NFC stack. Sony's AOSP uses the "legacy" opensource stack which lacks HCE.

The kernel has no relevance here, it's just a pretty basic I2C passthrough (so basic that the driver is the same for 544 and 547, even though the HALs are totally different).

For various reasons, the Sony stack is even harder to transplant than others - so far, no one has done a successful blob transplant of a closed-source HCE stack.
[NFC Hacking] mrhamed:
I've an OnePlus CM11S44 with NXP PN547 NFC chip but doesn't detect MIFARE ISO/IEC 14443 now :( (by manufacture doc:

this chip support for all released NFC standards in Reader/writer, card and Peer to Peer modes (ISO14443-A, B, F, ISO18092, FeliCa, MIFARE, ISO15693)

)

So I belief that is software problem, can any body help me to solve this?
[NFC Hacking] enigma9o7:
Any chance CM12/Lollipop addresses this? Or still no google pay with Android 5?
[NFC Hacking] Wetzel402:
Unless Google adds the driver to AOSP it won't happen. I'm running CM12 on my Note II and NFC is working but there are no options for tap and pay in Google Wallet.
[NFC Hacking] enigma9o7:
Hmm okay that's different. CM11 has the options for tap to pay, it just doesn't work. But if NFC is working for you (in CM12) for other things, wouldn't that mean there are in fact drivers for the chip, so that's one step closer to tap-to-pay, right? Anyways I don't fully understand, just hoping...
[NFC Hacking] Wetzel402:
My understanding, and someone can correct me if I'm wrong, is that the generic AOSP driver allows basic NFC function for our specific chipset but that tap and pay requires a proprietary driver from NXP. Until said driver is added to the AOSP, we are without tap and pay capability.
[NFC Hacking] jmondi:
Not completely correct.

My understanding is that currently there are 2 different NXP chips which use two different stacks.

pn544 used libnfc-nxp stack binary patched by NXP to add HCE support (no support in AOSP for HCE)

pn547 uses libnfc-nci, which is from broadcom but uses standard NCI command sets, with HCE support already in-place in AOSP code.

There has been investigations to establish if pn544 could be made NCI-compliant through firmware upgrade, but it seems like it is not working, thus no HCE support for pn544, binary patched images excluded.

pn547 have HCE support, but it seems like Ttp capabilities are still missing for some Google choice

Sorry to resurrect the thread with a new question: how does all of this relates to the HCI based infrastructure in Linux kernel (drivers/nfc) ?

Android support, afaik, is completely userspace, using a trivial i2c-dev kernel driver as interface. Is this correct? Where is the i2c-dev driver for pn544/547? It shouldn't be in drivers/nfc/ tree right?

Thank you
[NFC Hacking] thermatk:
Binaries!

TapToPay is working in GPE and no HCE present in CM12, of course.

Isn't it possible to use some blobs from Sony Z Ultra GPE Lollipop stock ROM in custom ROMs?

GPE should be pretty close to AOSP. I have MultiROM with both GPE and CM 12 installed, I can try to move the blobs between them if you say where they are :)
[NFC Hacking] bgcngm:
I see lots of experts in what it concerns to NFC and wonder if someone could shed a light on my issue. I am porting CM to M8 Dual SIM which has exactly the same NFC chip (PN544) than standard M8. Without no changes to M8 device tree, in respect to NFC, I am seeing this on a logcat:

I/NfcService( 2787): Enabling NFC
D/NFCJNI ( 2787): Start Initialization
[COLOR="Red"]E/NFC-HCI ( 2787): Could not open /vendor/firmware/libpn544_fw.so or /system/lib/libpn544_fw.so
W/NFC ( 2787): Firmware image not available: this device might be running old NFC firmware!
[/COLOR]D/NFCJNI ( 2787): NFC capabilities: HAL = 8150100, FW = b10129, HW = 620003, Model = 11, HCI = 1, Full_FW = 1, Rev = 41, FW Update Info = 0
D/NFCJNI ( 2787): phLibNfc_SE_GetSecureElementList()
D/NFCJNI ( 2787):
D/NFCJNI ( 2787): > Number of Secure Element(s) : 1
D/NFCJNI ( 2787): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI ( 2787): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI ( 2787): NFC Initialized

The error is gone after taking that proprietary file from the stock ROM:

D/NFCJNI ( 2904): Start Initialization
D/NFCJNI ( 2904): NFC capabilities: HAL = 8150100, FW = b10129, HW = 620003, Model = 11, HCI = 1, Full_FW = 1, Rev = 41, FW Update Info = 0
D/NFCJNI ( 2904): phLibNfc_SE_GetSecureElementList()
D/NFCJNI ( 2904):
D/NFCJNI ( 2904): > Number of Secure Element(s) : 1
D/NFCJNI ( 2904): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI ( 2904): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI ( 2904): NFC Initialized

NFC seems to initialize correctly in both cases, but I can't exchange data with other devices. I was not expecting this kind of issue at all because standard M8 has the same NFC chip.
[NFC Hacking] bobberkarl:
Same!

I have exactly the same problem with my xperia SP C5306. It was originally on Android 4.3. I used CM12 then CM11. I have the Nfc, but i can't use HCE. I don't have the libpn544_fw.so so i can't tell it it would change anything.
[NFC Hacking] bgcngm:
Despite the fact that you can't use HCE (already explained why in previous posts) do you have NFC working at all?
[NFC Hacking] Wetzel402:
My Note II on CM12.1 has working NFC but tap and pay will not work due to the HCE proprietary driver issues.
[NFC Hacking] bgcngm:
[MENTION=591147]Entropy512[/MENTION], did you find out how to identify the chip model/revision? I can't get over the NFC issue on M8 Dual SIM (read here) and I wanted to be sure what chip this phone has. In a logcat taken on a regular M8 we have:

NFC capabilities: HAL = 8150100, FW = b10126, HW = 620003, Model = 1, HCI = 1, Full_FW = 1, Rev = 38, FW Update Info = 0

Comparing with logcat from M8 dual SIM variant we can notice the following differences:

NFC capabilities: HAL = 8150100, FW = [COLOR="red"]b10129[/COLOR], HW = 620003, Model = [COLOR="Red"]11[/COLOR], HCI = 1, Full_FW = 1, Rev = [COLOR="red"]41[/COLOR], FW Update Info = 0

First of all, FW version is different, but judging by the HW id, I would say it is the same chip (PN544), but what does model id indicates?
[NFC Hacking] BizzKid:
After watching this video: www_youtube_com/watch?v=VeA3saGffCc

an interesting thought came to my mind.

I have Samsung S3 GT-I9301 NFC enabled with NXP PN544 chip without HCE support.

And what if i can buy original Samsung S4 battery with Broadcom BCM20794 NFC chip,

unstick the chip from that battery and stick it on s3 battery instead of the nxp chip?

Samsung s4 battery is a little bit larger in width dimension: link-to-xda-thread.

Whould Galaxy S3 i9301 work with that new chip?

Seems like the chip has only two contacts. o_0

How does it interact with the phone?
[NFC Hacking] liflyand:
Try and tell us is it works or not.

I have S3 neo too and im very eager for using tap and pay on it.
[NFC Hacking] BizzKid:
Several days ago i went to samsung shop and tried to attach the battery from galaxy S5 to my S3 phone.

Turned on the power and tried to read NFC tag that i had with me. The tag was read successfully. It's a pity that they (the shop) didn't have wireless pay (nfc paywave) to try. But it seems that android 4.4 firmware has drivers to work with broadcom NFC chip that S5 battery has (S4 battery has too).

ASAP i'll try to find any way to use S5 battery to pay with NFC paywave to make sure it works.

Next step is to buy S4 battery (cause it's most similar in dimentions to S3 one) with broadcom NFC chip on it and try to carefully disconnect the chip to attach it then to S3 battery instead of NXP PN544 chip that S3 battery has.

Does anyone tried to disassemble batteries with NFC? How to disconnect NFC chip without any damage to it?