I have some trouble using Mifare Classic tags in combination with the Sony Xperia Z2 tablet (Model: SGP521 E1/B).
The device can't read the first sector of a Mifare Classic 4K chip using default null keys. I've seen this behaviour in multiple apps (including the official NXP TagInfo Android app).
This is what I'm trying to do:
Code:
card.getMifare().authenticateSectorWithKeyA(0, new byte[6]);
byte[] b = card.getMifare().readBlock(block); // for all blocks inside sector 0.
It should return the header of the tag. However, the Z2 returns 0x0.
This is the logcat output:
08-14 09:24:02.539 17532-17564/? E/BrcmNfcJni﹕ Mifare Classic detected
08-14 09:24:02.589 17532-17532/? E/NxpExtns﹕ Mifare : phLibNfc_GetKeyNumberMFC Key found
08-14 09:24:02.589 17532-17532/? E/NxpExtns﹕ Mifare : phLibNfc_GetKeyNumberMFC Key = 0x0
08-14 09:24:02.589 17532-17532/? E/NxpExtns﹕ Mifare : phLibNfc_GetKeyNumberMFC returning = 0x0
08-14 09:24:02.589 17532-17564/? E/BrcmNfcJni﹕ nativeNfcTag_doCheckNdefResult: unknown status=0xFF
08-14 09:24:02.589 17532-17564/? E/NxpExtns﹕ Error Sending msg to Extension Thread
Click to expand...
Click to collapse
I think it's a bug in the Z2's firmware, as it works on all other Android devices using a NXP NFC controller. Other tags like the NXP Mifare Ultralight are working properly on the Z2. I asked Sony, but they keep telling me that this is an Android related bug (not their problem).
I would like to know if I have a broken tablet. Can some people try to reproduce this problem? Used Mifare Classic tag is a Dutch public transport card, but it should do the same with different Mifare Classic tags.
Anyone?
bartju94 said:
I think it's a bug in the Z2's firmware, as it works on all other Android devices using a NXP NFC controller.
Click to expand...
Click to collapse
You can install CM11 or PAC on your tablet. If it is a Sony-related bug, it should vanish, then.
Similar issue on Sony Xperia T3 phone
I'm encountering a very similar issue of Sony Xperia T3 (D5103) running Android 4.4.4 using Mifare Classic 1k tags.
The problem I'm encountering is partial tag read/writes - i.e. when a read/write operation is interrupted by the user removing the tag before the operation is complete. This is resulting in the NFC stack getting stuck - after this happens, any further tags are not detected by the device. As a workaround, going to Settings and manually toggle NFC on/off or turning the screen on/off with the power button seems to fix the issue - both of these seem to reset the NFC stack and it starts to function again.
I've tested on numerous other devices and encountered no such issues. I'd upgrade the device to Lollipop, but no official Android 5.x release is out yet for the T3 and the Cyanogen-based ROMs report issues with camera and cellular data, both of which my app relies on.
Logcat output from failed partial write:
Code:
06-25 10:20:43.094: E/BrcmNfcJni(7260): Mifare Classic detected
06-25 10:20:43.094: D/NfcService(7260): Tag detected, notifying applications
06-25 10:20:43.114: D/NativeNfcTag(7260): Connect to a tech with a different handle
06-25 10:20:43.114: E/BrcmNfcJni(7260): setReconnectState = 0x0
06-25 10:20:43.124: E/BrcmNfcJni(7260): setReconnectState = 0x0
06-25 10:20:43.124: E/BrcmNfcJni(7260): setReconnectState = 0x0
06-25 10:20:43.134: E/BrcmNfcJni(7260): setReconnectState = 0x0
06-25 10:20:43.134: E/NxpExtns(7260): Mifare : phLibNfc_GetKeyNumberMFC Key found
06-25 10:20:43.134: E/NxpExtns(7260): Mifare : phLibNfc_GetKeyNumberMFC returning = 0x0 Key = 0x1
06-25 10:20:43.134: E/BrcmNfcJni(7260): nativeNfcTag_doCheckNdefResult: unknown status=0xFF
06-25 10:20:43.134: E/NxpExtns(7260): Error Sending msg to Extension Thread
06-25 10:20:43.134: D/NativeNfcTag(7260): Check NDEF Failed - status = 255
Related
Hi Guys,
what do you think, is it possible (would be possible) to use oFono/ofono-ril for the modem for our Wave? In theory oFono could be used with any modem that supports standard AT commands...
More info here: http://ofono.org/ and here http://gitorious.org/android-n900/ofono-ril/trees/gingerbread
Sadly Wave's CP doesn't support most of standard AT commands. :[
Rebellos said:
Sadly Wave's CP doesn't support most of standard AT commands. :[
Click to expand...
Click to collapse
heja Rebellos, dzieje się coś ciekawego w tej materii czy raczej możemy zapomnieć o andku na W 2 ?
pozdro z mazowsza
AT+CALC
Code:
Polecenie (tryb AT):
AT+CLAC
Odpowiedź:
AT+CLAC
&C
&D
&E
&F
&S
&V
&W
E
I
L
M
Q
V
X
Z
T
P
\Q
\S
\V
%V
D
A
H
O
S0
S2
S3
S4
S5
S6
S7
S8
S9
S10
S11
S30
S103
S104
+ICF
+IFC
+IPR
+GMI
+GMM
+GMR
+GCAP
+GSN
+DR
+DS
+WS46
+SYNCML
+BATGETLEVEL
+BATUPDATE
+BATGETTABLE
+UPLOADUNSET
+CRLP
+CV120
+CSSN
+CREG
+CGREG
+CFUN
+GCAP
+CSCS
+CSTA
+CR
+CEER
+CRC
+CMEE
+CGDCONT
+CGDSCONT
+CGTFT
+CGEQREQ
+CGEQMIN
+CGQREQ
+CGQMIN
+CGEREP
+CGPADDR
+CGDATA
+CGCLASS
+CGSMS
+CSMS
+CMGF
+CSAS
+CRES
+CSCA
+CSMP
+CSDH
+CSCB
+FDD
+FAR
+FCL
+FIT
+ES
+ESA
+CMOD
+CVHU
+ACSENSOR
+RTCCTEST
+KEYSHORT
+PROXIMIT
+GEOMAGSS
+FIRMVERS
+APPINSTALL
+APPUNINSTALL
+APPLAUNCH
+TKSHELL
+CSQ
+CBC
+CPAS
+CPIN
+CMEC
+CKPD
+CIND
+CMER
+CGATT
+CGACT
+CGCMOD
+CPBS
+CPBR
+CPBF
+CPBW
+CPMS
+CNMI
+CMGL
+CMGR
+CMGS
+CMSS
+CMGW
+CMGD
+CMGC
+CNMA
+CMMS
+FTS
+FRS
+FTH
+FRH
+FTM
+FRM
+CHUP
+CCFC
+CCUG
+COPS
+CLCK
+CPWD
+CPWC
+CUSD
+CAOC
+CACM
+CAMM
+CPUC
+CCWA
+CHLD
+CIMI
+CGMI
+CGMM
+CGMR
+CGSN
+CNUM
+CCLK
+CLVL
+CMUT
+CLCC
+COPN
+CPOL
+CPLS
+CTZR
+CCWE
+CTZU
+CLAC
+CLIP
+COLP
+CSGT
+CRMP
+CDIP
+CTFR
+CLIR
$QCSIMSTAT
$QCCNMI
$QCCLR
$QCDMG
$QCDMR
$QCDNSP
$QCDNSS
$QCTER
$QCSLOT
$QCPINSTAT
$QCPDPP
$QCPDPLT
$QCPWRDN
$QCDGEN
$BREW
$QCSYSMODE
$QCCTM
$SUSBC
$NWMDCHNG
$SHPSLEEP
Is it helpful?
nie dajcie umrzec temu projektowi nie dajcie
That's bad news if the CP doesn't support most of the standard AT commands... So this doesn't help at all?
anghelyi said:
Hi Guys,
what do you think, is it possible (would be possible) to use oFono/ofono-ril for the modem for our Wave? In theory oFono could be used with any modem that supports standard AT commands...
More info here: http://ofono.org/ and here http://gitorious.org/android-n900/ofono-ril/trees/gingerbread
Click to expand...
Click to collapse
What you're saying just doesn't make sense. Why would you wanna use a oFono RIL on a Samsung device?
The RIL is just used to channel (and translate) android java phone/sim/modem related commands to the lower hardware layer on/for the radio processor. Thus the vendor RIL need to apply to the hardware of THAT vendor (i.e.Samsung). Why re-invent the wheel?
Now, there are some exceptions due to the fact that the RIL code is fairly closed source (although GPL'd AFAIK ==> should be released), that there are some project(s) that would like to make a "Free RIL"...
BTW. All GSM modems support the "standard AT set" (or your phone would probably not work!) The tricky part is how to access it from outside the AOS & RIL. But that's another topic.
E:V:A said:
What you're saying just doesn't make sense. Why would you wanna use a oFono RIL on a Samsung device?
Click to expand...
Click to collapse
I don't get your point... oFono is a platform agnostic library for mobile apps, with a lot of supported modems (even with standard AT command support) and oFono RIL is a RIL implementation based on it. Why not to use it?If it works with the N9 why not try to build it for Wave?
E:V:A said:
Now, there are some exceptions due to the fact that the RIL code is fairly closed source (although GPL'd AFAIK ==> should be released), that there are some project(s) that would like to make a "Free RIL"...
BTW. All GSM modems support the "standard AT set" (or your phone would probably not work!) The tricky part is how to access it from outside the AOS & RIL. But that's another topic.
Click to expand...
Click to collapse
RIL isn't GPL, it's Apache License, like most of Android platform, so doesn't have to be released.
Yea, there actually are handlers for AT cmds inside of AMSS, but modem initialization, nor any more advanced usage can't be done with these alone.
Rebellos said:
RIL isn't GPL, it's Apache License, like most of Android platform, so doesn't have to be released.
Yea, there actually are handlers for AT cmds inside of AMSS, but modem initialization, nor any more advanced usage can't be done with these alone.
Click to expand...
Click to collapse
Rebellos, how this works? like.. the modem access is through AT and then call for the other things?
anghelyi said:
I don't get your point... oFono is a platform agnostic library for mobile apps, with a lot of supported modems (even with standard AT command support) and oFono RIL is a RIL implementation based on it. Why not to use it?If it works with the N9 why not try to build it for Wave?
Click to expand...
Click to collapse
Dammit! You're absolutely right. I did the classical error of not "following the f%&ing links" before posting! So I have obviously confused the oFono project with a completely different one... Actually this seem to be a very cool project! We should try to get some of these guys involved over here or vice verse.
anonimo1w said:
Rebellos, how this works? like.. the modem access is through AT and then call for the other things?
Click to expand...
Click to collapse
Try to be a little more specific. On many platforms the phone application processor (UI/UX) does much of its normal communication (phone calls, sms, sim etc) to/from the baseband processor (modem) via an AT interface. However, in many cases this AT interface is "embedded" in other transport layers like IPC, I2C or what have you. In addition, the actual physical control mechanisms (like putting modem to sleep/wake up, power save, RF power, booting, test modes etc.) are usually done through GPIO or other forms of UART. Honestly, it's quite a mess to explain, because there are many variations on how this is handled. (That's why they needed the RIL in the first place.) Finally, since I don't have a Wave, I don't know how that is done. I just know they use a Qualcomm modem... and some of their manuals are available.
In modern SHP based phones hierarchy of transport layers is like:
1) oneDRAM
2) SHP IPC protocol with packet types listed below: (as per Samsung Jet S8000)
Code:
typedef enum
{
FIFO_PKT_NONE = 0, // 0
FIFO_PKT_KEY, // 1
FIFO_PKT_SIM, // 2
FIFO_PKT_PROTO, // 3
FIFO_PKT_TAPI, // 4
FIFO_PKT_PHONESTATUS, // 5
FIFO_PKT_FILE, // 6
FIFO_PKT_LCD, // 7
FIFO_PKT_LED, // 8
FIFO_PKT_SOUND, // 9 Sound means voice here
FIFO_PKT_SOUND_DATA, // 10
FIFO_PKT_H324M, // 11
FIFO_PKT_AMR_DATA, // 12
FIFO_PKT_AMR_CTRL, // 13
FIFO_PKT_CLOCK, // 14
FIFO_PKT_BOOT, // 15
FIFO_PKT_FLIP, // 16
FIFO_PKT_SYSTEM, // 17
FIFO_PKT_USBPROTO, // 18
FIFO_PKT_USBFILE, // 19
FIFO_PKT_USBDIAG, // 20
FIFO_PKT_IRDAPROTO, // 21
FIFO_PKT_IRDAFILE, // 22
FIFO_PKT_IRDADIAG, // 23
FIFO_PKT_TIMER, // 24
FIFO_PKT_DEBUG, // 25
FIFO_PKT_DIAGNOSE, // 26
FIFO_PKT_SPECIAL_BOOT, // 27
FIFO_PKT_CALL_TIME, // 28
FIFO_PKT_ALARM, // 29
FIFO_PKT_FIFO_INTERNAL,// 30
FIFO_PKT_USBCRCPROTO, // 31
FIFO_PKT_USBCRCFILE, // 32
FIFO_PKT_USBCRCDIAG, // 33
FIFO_PKT_VIBRATOR, // 34
FIFO_PKT_AMLED, // 35 AppMgr LED
FIFO_PKT_AMVIB, // 36 AppMgr Vibrator
FIFO_PKT_AMLCD, // 37 AppMgr LCD Backlight
FIFO_PKT_DATA_PCSYNC,
FIFO_PKT_CTRLCMD_PCSYNC,
FIFO_PKT_DATA_WSSSYNC,
FIFO_PKT_TIME, // 41 TimeMgr
FIFO_PKT_DVB_H_CAS_SIM, // 42 DVB-H CAS SIM
FIFO_PKT_DVB_H_CAS_TEST,// 43 DVB-H CAS Test module.
FIFO_PKT_DVB_H_CAS, // 44 DVB-H CAS Common usage.
FIFO_PKT_DVB_H_CAS_IPS, // 45 DVB-H CAS IPS usage.
FIFO_PKT_DVB_H_DebugLevel, //46 receive debug level from MSM
FIFO_PKT_Forced_Assert, // 47
FIFO_PKT_MEMORY, // 48
FIFO_PKT_NV, // 49 // NvMgrLite
FIFO_PKT_LBS, // 50 LBS
FIFO_PKT_SIM_JSR177, // 51 S8000_JSR177_kjseo
FIFO_PKT_USER = 0x80,
FIFO_PKT_DVBH = FIFO_PKT_USER + 0x06,
FIFO_PKT_DVBH_SVC,
FIFO_PKT_DVB_H_LAYER1,
FIFO_PKT_DVB_PLAYER,
FIFO_PKT_AV_PLAYER,
FIFO_PKT_PH, // BB -> MM : Protocol Handler FIFO Type
FIFO_PKT_PH_LITE, // MM -> BB : Protocol Handler Lite FIFO Type
FIFO_PKT_FX = 0x90,
FIFO_PKT_BLUETOOTH ,
FIFO_PKT_TESTMODE, // Testmode
FIFO_PKT_DRV, // driver
FIFO_PKT_AGENT,
FIFO_PKT_DEVMGR,
FIFO_PKT_SECUREBOOT,
FIFO_PKT_MAX
} FifoType;
In Wave there are also few "service" packets added. Not sure for what are these.
Actually while in intialization of modem there are used SECUREBOOT, FM (direct access to Bada file system by CP), IPC_PACKET (not listed here or named differently) BOOT, SIM (managing sim contacts and logging) and some others. Packets that are managing telephony are PROTO and TAPI (telephony API)
TAPI packets does split into few subtypes
TAPI_TYPE_CALL = 0 //53 subtypes
TAPI_TYPE_NETTEXT = 1 //around 10 subtypes
TAPI_TYPE_NETWORK = 2 //23 subtypes
TAPI_TYPE_SS = 3 //48 subtypes
TAPI_TYPE_AT = 4 //34 subtypes
TAPI_TYPE_DMH = 5 //n subtypes, called API_IDs (must be nonzero)
TAPI_TYPE_CONFIG = 6 //n subtypes, called API_IDs (must be nonzero)
Click to expand...
Click to collapse
TAPI layer splits into contexts, which might be called "channels" for managing telephony functions
CALL (3 max)
NETTEXT (SMS/MMS, few allowed)
NETWORK (up to one)
SS (security related AFAIR)
AT (this is probably route of AT commands)
Click to expand...
Click to collapse
modem
i dont know this part but i want to know wave s8500 modem work or not ics 4.0.4?
yasotharan13 said:
i dont know this part but i want to know wave s8500 modem work or not ics 4.0.4?
Click to expand...
Click to collapse
stop annoying everyone!! it's not working yet!!
Hello,
I've compiled the latest version of libmtp (1.1.2) and installed properly. It seems that the device is recognized but still without the ability to connect to it. Here is the log. I got two different outputs. So I'll post both of them:
1.
Code:
libmtp version: 1.1.2
Listing raw device(s)
Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7510/Galaxy Tab 10.1/S2/GT-N7000/Galaxy Nexus.
Found 1 device(s):
Samsung: GT-P7510/Galaxy Tab 10.1/S2/GT-N7000/Galaxy Nexus (04e8:6860) @ bus 1, dev 12
Attempting to connect device(s)
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
inep: usb_get_endpoint_status(): No such device
outep: usb_get_endpoint_status(): No such device
usb_clear_halt() on IN endpoint: No such device
usb_clear_halt() on OUT endpoint: No such device
usb_clear_halt() on INTERRUPT endpoint: No such device
ignoring usb_claim_interface = -9ignoring usb_claim_interface = -22LIBMTP PANIC: failed to open session on second attempt
Unable to open raw device 0
OK.
2.
Code:
libmtp version: 1.1.2
Listing raw device(s)
Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7510/Galaxy Tab 10.1/S2/GT-N7000/Galaxy Nexus.
Found 1 device(s):
Samsung: GT-P7510/Galaxy Tab 10.1/S2/GT-N7000/Galaxy Nexus (04e8:6860) @ bus 1, dev 13
Attempting to connect device(s)
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
LIBMTP PANIC: failed to open session on second attempt
Unable to open raw device 0
OK.
I've read about a samsung-proprietary mtp protocol which would not work with libmtp. I hope those rumors are wrong, aren't they?
I'd really appreciate any help. I've been working on it for a couple of days and it starts really anoying me.
regards, hornby
I have the same issue. I am trying to connect my Linux Mint Debian machine to my SGS2 running CM9 nightly. Debian can see the device but communication is a nogo.
Here is mtp-detect:
Code:
~ $ mtp-detect
libmtp version: 1.1.2
Listing raw device(s)
Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7510/Galaxy Tab 10.1/S2/GT-N7000/Galaxy Nexus.
Found 1 device(s):
Samsung: GT-P7510/Galaxy Tab 10.1/S2/GT-N7000/Galaxy Nexus (04e8:6860) @ bus 1, dev 9
Attempting to connect device(s)
ignoring usb_claim_interface = -110Android device detected, assigning default bug flags
USB low-level info:
Using kernel interface "usbfs"
bcdUSB: 512
bDeviceClass: 0
bDeviceSubClass: 0
bDeviceProtocol: 0
idVendor: 04e8
idProduct: 6860
IN endpoint maxpacket: 512 bytes
OUT endpoint maxpacket: 512 bytes
Raw device info:
Bus location: 1
Device number: 9
Device entry info:
Vendor: Samsung
Vendor id: 0x04e8
Product: GT-P7510/Galaxy Tab 10.1/S2/GT-N7000/Galaxy Nexus
Vendor id: 0x6860
Device flags: 0x08008106
Device info:
Manufacturer: samsung
Model: GT-I9100
Device version: 1.0
Serial number: ????????
Vendor extension ID: 0x00000006
Vendor extension description: microsoft.com: 1.0; android.com: 1.0;
Detected object size: 64 bits
Extensions:
microsoft.com: 1.0
android.com: 1.0
Supported operations:
1001: get device info
1002: Open session
1003: Close session
1004: Get storage IDs
1005: Get storage info
1006: Get number of objects
1007: Get object handles
1008: Get object info
1009: Get object
100a: Get thumbnail
100b: Delete object
100c: Send object info
100d: Send object
1014: Get device property description
1015: Get device property value
1016: Set device property value
1017: Reset device property value
101b: Get partial object
9801: Get object properties supported
9802: Get object property description
9803: Get object property value
9804: Set object property value
9805: Get object property list
9810: Get object references
9811: Set object references
95c1: Unknown (95c1)
95c2: Unknown (95c2)
95c3: Unknown (95c3)
95c4: Unknown (95c4)
95c5: Unknown (95c5)
Events supported:
0x4002
0x4003
0x4004
0x4005
Device Properties Supported:
0xd401: Synchronization Partner
0xd402: Friendly Device Name
0x5003: Image Size
Playable File (Object) Types and Object Properties Supported:
3000: Undefined Type
3001: Association/Directory
3004: Text
3005: HTML
3008: MS Wave
3009: MP3
300b: MPEG
3801: JPEG
3802: TIFF EP
3807: GIF
3808: JFIF
380b: PNG
380d: TIFF
b901: WMA
b902: OGG
b903: AAC
b982: MP4
b983: MP2
b984: 3GP
ba05: Abstract Audio Video Playlist
ba10: WPL Playlist
ba11: M3U Playlist
ba14: PLS Playlist
ba82: XMLDocument
b906: FLAC
Storage Devices:
StorageID: 0x00010001
StorageType: 0x0003 fixed RAM storage
FilesystemType: 0x0002 generic hierarchical
AccessCapability: 0x0000 read/write
MaxCapacity: 12332314624
FreeSpaceInBytes: 6137163776
FreeSpaceInObjects: 1073741824
StorageDescription: Internal Storage
VolumeIdentifier: (null)
Special directories:
Default music folder: 0x0000001a
Default playlist folder: 0xffffffff
Default picture folder: 0x0000001f
Default video folder: 0xffffffff
Default organizer folder: 0xffffffff
Default zencast folder: 0xffffffff
Default album folder: 0xffffffff
Default text folder: 0xffffffff
MTP-specific device properties:
Friendly name: (NULL)
Synchronization partner: (NULL)
libmtp supported (playable) filetypes:
Folder
Text file
HTML file
RIFF WAVE file
ISO MPEG-1 Audio Layer 3
MPEG video stream
JPEG file
GIF bitmap file
JFIF file
Portable Network Graphics
TIFF bitmap file
Microsoft Windows Media Audio
Ogg container format
Advanced Audio Coding (AAC)/MPEG-2 Part 7/MPEG-4 Part 3
MPEG-4 Part 14 Container Format (Audio+Video Emphasis)
ISO MPEG-1 Audio Layer 2
Abstract Playlist file
XML file
Free Lossless Audio Codec (FLAC)
ERROR: Could not close session!
inep: usb_get_endpoint_status(): No such device
outep: usb_get_endpoint_status(): No such device
usb_clear_halt() on IN endpoint: No such device
usb_clear_halt() on OUT endpoint: No such device
usb_clear_halt() on INTERRUPT endpoint: No such device
OK.
Hi,
Anyway, I have had the Xperia Mini for a while now, and its formfactor is perfect. But I have had some troubles lately, and wondered if anyone else had encountered them (and found a fix?).
ZellyCream 4.0
Kappa 1.6 kernel.
SD card is a Sandisk Ultra 64 gb SDXC, partitioned into one small ext3 partition and the rest a FAT32 one.
Whenever charging the phone for a while, leaving it alone, it seems as if the SD Card falls asleep. And as soon as I start using the phone, all hell breaks loose - the log fills with errors of files not found - see here:
D/kernel ( 159): [25573.170745] mmc1: Controller has been reset
D/kernel ( 159): [25573.170837] mmc1: Worked around bug 1535304
E/kernel ( 159): [25573.181854] mmcblk0: error -110 sending status comand
E/kernel ( 159): [25573.181854] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
E/kernel ( 159): [25573.181884] mmcblk0: error -5 transferring data, sector 121207320, nr 56, card status 0x0
E/kernel ( 159): [25573.181884] end_request: I/O error, dev mmcblk0, sector 121207320
E/kernel ( 159): [25573.181945] mmc1: DMA channel flushed (0x80000004)
E/kernel ( 159): [25573.181976] Flush data: 0000c003 4fa96000 00000000 00400040 00080008 00000003
D/kernel ( 159): [25573.182037] mmc1: Controller has been reset
D/kernel ( 159): [25573.182098] mmc1: Worked around bug 1535304
E/kernel ( 159): [25573.190826] mmcblk0: error -110 sending status comand
E/kernel ( 159): [25573.190856] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
E/kernel ( 159): [25573.190856] mmcblk0: error -5 transferring data, sector 121207321, nr 55, card status 0x0
E/kernel ( 159): [25573.190887] end_request: I/O error, dev mmcblk0, sector 121207321
E/kernel ( 159): [25573.190917] mmc1: DMA channel flushed (0x80000004)
E/kernel ( 159): [25573.190917] Flush data: 0000c003 4fa96000 00000000 00400040 00080008 00000003
D/kernel ( 159): [25573.191009] mmc1: Controller has been reset
D/kernel ( 159): [25573.191070] mmc1: Worked around bug 1535304
E/kernel ( 159): [25573.199645] mmcblk0: error -110 sending status comand
E/kernel ( 159): [25573.199676] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
E/kernel ( 159): [25573.199676] mmcblk0: error -5 transferring data, sector 121207322, nr 54, card status 0x0
E/kernel ( 159): [25573.199707] end_request: I/O error, dev mmcblk0, sector 121207322
E/kernel ( 159): [25573.199737] mmc1: DMA channel flushed (0x80000004)
E/kernel ( 159): [25573.199737] Flush data: 0000c003 4fa96000 00000000 00400040 00080008 00000003
Click to expand...
Click to collapse
And so it repeats. Only recourse is to reboot phone, and all gets back to normal.
Other users having a similar phone (Xperia mini pro) have reported almost the same behaviour.
I have tested adding some tape to the physical SD Card to increase contact in its slot - no result. I have tested with an old 16 gb card - which worked A-OK. I have checked the eMMC to see if there are memory faults in the phone - no.
What I was wondering, and which probably only a kernel dev would know more about is this:
There has been some discussions on a maemo-forum and here about timings for the SD Cards in the kernel drivers.
http://maemo.org/community/maemo-users/n900_microsd_card_i-o_errors_and_corruption/
http://forum.xda-developers.com/showpost.php?p=17033833&postcount=5563
Specifically what was said was that
In linux kernel sources
Code:
drivers/mmc/host/omap_hsmmc.c
replace the
set_data_timeout function with this one:
Code:
static void set_data_timeout(struct omap_hsmmc_host *host,
unsigned int timeout_ns,
unsigned int timeout_clks)
{
uint32_t reg;
reg = OMAP_HSMMC_READ(host->base, SYSCTL);
reg &= ~DTO_MASK;
reg |= DTO << DTO_SHIFT;
OMAP_HSMMC_WRITE(host->base, SYSCTL, reg);
}
Basically, it changes it to use the default DTO value of 0xE rather
than trying to calculate dynamic DTO based on the particular SD card
timings and characteristics. I read this advice on the linux-omap
mailing list from someone having the same problem (but with different
hardware).
I don't know if it's a problem in the driver DTO calculation logic, or
bad metadata in the SD cards causing that logic to be flawed. The same
workaround is done in other drivers for standard SD cards, too. Some
question why bother to change the DTO at all, if 0xE works with all of
them.
After a month using it like this, I have no problems. My SD card works
fine, no corruption.
Click to expand...
Click to collapse
Another discussion at the maemo forums:
14 (0xA) is the standard DTO setting for SD cards. The omap_hsmmc driver tries to use some logic to dynamically change DTO based on the card timings but apparently this logic is buggy, or perhaps certain cards return bad timing information when the driver requests it. It affects all devices which use this driver, not just the N900, and other devices with other drivers too. The suggestion to use DTO=14 came from Texas Instruments, so it should be safe for all. Forcing DTO to 14 is the fix/workaround for all kinds of SD drivers. Apparently it is quite a common problem.
Click to expand...
Click to collapse
http://talk.maemo.org/showthread.php?t=72789
Now, I have taken a look at the source for Kappa 1.6,
https://github.com/KaSt/Kappa/blob/master/drivers/mmc/host/omap_hsmmc.c
and if I read the code correctly, it is not even remotely like the example given in the maemo-solution. It looks like the old Maemo code people were trying to improve:
Code:
static void set_data_timeout(struct omap_hsmmc_host *host,
unsigned int timeout_ns,
unsigned int timeout_clks)
{
unsigned int timeout, cycle_ns;
uint32_t reg, clkd, dto = 0;
reg = OMAP_HSMMC_READ(host->base, SYSCTL);
clkd = (reg & CLKD_MASK) >> CLKD_SHIFT;
if (clkd == 0)
clkd = 1;
cycle_ns = 1000000000 / (clk_get_rate(host->fclk) / clkd);
timeout = timeout_ns / cycle_ns;
timeout += timeout_clks;
if (timeout) {
while ((timeout & 0x80000000) == 0) {
dto += 1;
timeout <<= 1;
}
dto = 31 - dto;
timeout <<= 1;
if (timeout && dto)
dto += 1;
if (dto >= 13)
dto -= 13;
else
dto = 0;
if (dto > 14)
dto = 14;
}
reg &= ~DTO_MASK;
reg |= dto << DTO_SHIFT;
OMAP_HSMMC_WRITE(host->base, SYSCTL, reg);
}
The Maemo code from 2011 looks like this
Code:
static void set_data_timeout(struct omap_hsmmc_host *host,
unsigned int timeout_ns,
unsigned int timeout_clks)
{
unsigned int timeout, cycle_ns;
uint32_t reg, clkd, dto = 0;
reg = OMAP_HSMMC_READ(host->base, SYSCTL);
clkd = (reg & CLKD_MASK) >> CLKD_SHIFT;
if (clkd == 0)
clkd = 1;
cycle_ns = 1000000000 / (clk_get_rate(host->fclk) / clkd);
timeout = timeout_ns / cycle_ns;
timeout += timeout_clks;
if (timeout) {
while ((timeout & 0x80000000) == 0) {
dto += 1;
timeout <<= 1;
}
dto = 31 - dto;
timeout <<= 1;
if (timeout && dto)
dto += 1;
if (dto >= 13)
dto -= 13;
else
dto = 0;
if (dto > 14)
dto = 14;
}
reg &= ~DTO_MASK;
reg |= dto << DTO_SHIFT;
OMAP_HSMMC_WRITE(host->base, SYSCTL, reg);
}
http://gitorious.org/meego-device-adaptation/n900_kernel/blobs/master/drivers/mmc/host/omap_hsmmc.c
Now, my simple thought, and bear with me, I am no coder, just someone who likes to probe as far as I can in my hardware related troubles:
Could it be the case that more people with this kernel Kappa 1.6 and SD card Sandisk 64 gb, have had similar problems, and that the solution is modifying the kernel code?
Thanks BTW to all devs who have made my phone and so much more last longer.
Edited 130710 to include samples of Kappa code and Maemo code
Edited 130711 to remove some weird formatting
Try changing Rom's
Sent from my WT19i using xda app-developers app
?
Have U Tried Using another Kernel?try extended stock kernel
I have contacted Kast about the possible improvement of the kernel.
Kast kindly pointed out that there are more people with the same problem, and gave a link to a discussion where the OP had the exact same log:
http://forum.xda-developers.com/showthread.php?t=1945401
Re the suggestion to change kernel:
Yes, but I have taken a look at some other kernel sources and all have the same code in question. So changing kernel to one with presumably the same driver would change nothing. I prefer letting all variables stay the same (card, ROM, phone) and trying out the possible solution of having a kernel which does not compute the DTO the way it is done now.
It could be that the kernel drivers are correctly made, but that there are cards which fall out of spec and do not play well with that correct way of doing things.
Hmmm..even if the kernel driver are correctly made, those SD card aren't made to work on mid-range phone....only high-end phone can use those card without any problem....beside those card are mostly for camera use....
you can change kernel or change rom but in the end your card is just wont work with it....
Hmm. There is an ongoing effort to try to generate exFat-support here at XDA, and by others outside in the Linux-world, so I would not think that it simply is a matter of the cards being incompatible with oldish hardware. Simply put, the cards will not unleash their full potential except for when formatted to exFat and driven by an exFat driver.
But that is outside the scope of my thought here. You see, I am completely satisfied with not having huge write/read speeds, or not having support for +4gb files because FAT32 won't allow it. I just think that it would be nice to have a phone that can handle the 64gb cards wo, as it seems is the case, ejecting the card.
Now, another lead: some people trying out a solution for exFat support in this thread also experience this spontaneous eject:
This works fine for me, but from time to time it seems like my 64GB Sandisk somehow gets ejected and rescanned.. during that time it seems to not recognize the SD card..
Click to expand...
Click to collapse
I have the same problem with or without this patch - to me it seems to be when phone is asleep or docked.
Click to expand...
Click to collapse
So a another question has emerged for me: does the solution proposed by GSeeker, DoomLord and the others in the thread above have anything to do with the kernel driver code in omap_hsmmc.c?
Hi, I am having issues with a Huawei modem E173u-1 on my tablet Archos 101 g9 8gb
driver not found.
Can you help me, pls?
USB_ModeSwitch log from Wed Apr 09 17:50:44 PKT 2014
Raw args from udev: 1-1/1-1:1.0
Using top device dir /sys/bus/usb/devices/1-1
----------------
USB values from sysfs:
manufacturer HUAWEI
product HUAWEI Mobile
serial
----------------
bNumConfigurations is 1 - don't check for active configuration
SCSI attributes not needed, moving on
checking config: /data/data/de.draisberghof.pppwidget/app_tmp/12d1.14fe
! matched. Reading config data
devList 1:
config: TargetVendor set to 12d1
config: TargetProduct set to 1506
Driver module is "option", ID path is /sys/bus/usb-serial/drivers/option1
Logger is: /system/bin/log
Command to be run:
usb_modeswitch -I -W -D -s 20 -u -1 -b 1 -g 2 -v 12d1 -p 14fe -f $cB
Verbose debug output of usb_modeswitch and libusb follows
(Note that some USB errors are to be expected in the process)
--------------------------------
Reading long config from command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.4 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x12d1
DefaultProduct= 0x14fe
TargetVendor= 0x12d1
TargetProduct= 0x1506
TargetClass= not set
TargetProductList=""
DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint= not set
MessageContent="55534243123456780000000000000011062000000100000000000000000000"
NeedResponse=0
ResponseEndpoint= not set
InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode enabled
Use given bus/device number: 001/002 ...
Looking for default devices ...
bus/device number matched
searching devices, found USB ID 12d1:14fe
found matching vendor ID
found matching product ID
adding device
Found device in default mode, class or configuration (1)
Skipping the check for the current configuration
Using interface number 0
Using endpoints 0x01 (out) and 0x81 (in)
USB description data (for identification)
-------------------------
Manufacturer: HUAWEI
Product: HUAWEI Mobile
Serial No.: not provided
-------------------------
Looking for active driver ...
OK, driver found; name unknown, limitation of libusb1
OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Resetting response endpoint 0x81
Could not reset endpoint (probably harmless): -34
Resetting message endpoint 0x01
Could not reset endpoint (probably harmless): -6
Device is gone, skipping any further commands
Bus/dev search active, referring success check to wrapper. Bye.
ok:busdev
--------------------------------
(end of usb_modeswitch output)
Checking success of mode switch for max. 20 seconds ...
Waiting for device file system (1 sec.) ...
Waiting for device file system (2 sec.) ...
Waiting for device file system (3 sec.) ...
Waiting for device file system (4 sec.) ...
Waiting for device file system (5 sec.) ...
Waiting for device file system (6 sec.) ...
Waiting for device file system (7 sec.) ...
Reading attributes ...
Mode switch has completed
Mode switching was successful, found 12d1:1506 (HUAWEI: HUAWEI Mobile)
Device class of first interface is ff
Now checking for bound driver ...
No driver has bound to interface 0 yet
Module loader is /sbin/insmod
Trying to find and install main driver module "option"
Trying to find module "option"
Loading support module /lib/modules/usb_wwan.ko
Error: insmod: cannot insert '/lib/modules/usb_wwan.ko': Invalid module format (-1): Exec
format error
Loading main driver module "option"
Error: insmod: cannot insert '/lib/modules/option.ko': Invalid module format (-1): Exec
format error
Falling back to "usbserial"
Module "usb_serial" not found, can't do more here
Driver binding seems to have failed
All done, exiting
please answer!!!
i'm solved the problem by replacing the nucleus
Hey guys and gals,
I've been doing some unwholesome DEX bytecode patching on an app. Frequently I'll want to patch a function(which returns Boolean) to do an early return, with a hardcoded value that I want. Normally, this could be accomplished by assembling:
12 00 const/4 v0, 0
0f 00 return v0
This used to work all well and good up until Oreo. Now, the same approach will sometimes trip a verification error on Oreo:
Code:
AndroidRuntime: java.lang.VerifyError: Verifier rejected class blah: boolean blah.foo(java.lang.Object) failed to verify: boolean blah.foo(java.lang.Object): [0x3] register v0 has type Undefined but expected Boolean return-1nr on invalid register v0 (declaration of 'blah.foo' appears in blahblahblah.dex)
In the original code I'm patching, v0 *is* the register that would normally be used to return a Boolean type. I was under the impression that Booleans were internally implemented using ints at the VM level, and that you could just move a 0 or a 1 into a register and return it as Boolean. Yet with Oreo, the bytecode verifier is somehow now able to infer data types from the bytecode?? I realize how weird this sounds, but the above error seems to imply exactly this (unless I'm missing something here)??
So, questions for people:
* Does anyone know the means by which the bytecode verifier in the VM infers the data types of virtual registers (or at least, of primitive values being returned)?
* Does anyone know how to 'trick' the verifier into thinking a particular virtual register is holding a Boolean type, even though the given virtual register was last written using a 'const' (0x12) instruction? (Yeah, I know how ridiculous this sounds. I can't even type this question with a straight face...)
Thanks!
Argh. Looking at https://android.googlesource.com/platform/dalvik.git/+/android-4.1.1_r3/vm/analysis/CodeVerify.cpp, it looks like register types are set based on type-specific get/put instructions. But in addition to iget-boolean / iput-boolean, it is possible to move a constant into a register and treat THAT as a Boolean directly. But why would the VM freak out if one of these were to be returned?