[HW Mod] Manual 3G/4G conversion - Xoom Android Development
This thread is dedicated to manually upgrading the Xoom's hardware to support 3G/4G without waiting for Motorola. Thread will be updated as progress is made.
As you probably are all aware, Motorola will be rolling out 4G upgrades to the Xoom in time. For those who are unwilling to wait, there may be a solution. This is strictly at the theoretical stage for the time being so I'm not expecting it to be smooth sailing. Here is the posited idea.
For those who have pulled apart or have seen the internals of the Xoom, you will have noticed a dummy PCI Express card slot in the top left corner. This is the proposed slot for the 4G upgrade card when big M gets around to it. If you are an international user who purchased one (like me) before the GSM models rolled out, and can't wait slash don't want to be locked down to a specific carrier using only the 700 or 1900 bands, this is the mod for you.
Sierra Wireless manufactures 3G/4G/GPS combo cards based on the PCI Interface. Their cards are fully supported under the Linux kernel and what's better is that most of these cards run on an MSM7XXX chipset. The cards can be purchased here,
http://www.sierrawireless.com/en/productsandservices/AirPrime/Wireless_Modules/High-speed.aspx
For international users, the models of interest here are ones that support both LTE and HSPA+. The offered frequency bands are much more flexible with these cards as most of them are quad or penta band. (Pent. for LTE).
The sim slot is already wired to the PCI bus so connecting the two interfaces should not be a problem, but again, highly theoretical. Though I am yet to purchase one of these cards and test it for myself, I have taken the liberty to compile the make file from the site and have placed it into /lib/modules and it seems to be recognised without problems. I am confident there shouldn't be any problems though as the MSM 7200 is an officially supported chipset under android.
There may of course be other applications for this slot. For example, it may be possible to expand the already generous storage we have using PCI express SSD cards. Or it can be used to add newer WiFi protocols as they become available with new pci based network cards. Maybe even NFC if a peripheral exists. Again this thread will be updated as progress is made so please be patient.
Looks and sounds like it is doable found this bit also http://news.vzw.com/news/2011/01/pr2011-01-04h.html but these things cost about 200$ so I don't know how excited i'd be to drop $200 when i can get it free from Motorola whenever they decide to pony up and do these upgrades.
760hacker said:
Looks and sounds like it is doable found this bit also http://news.vzw.com/news/2011/01/pr2011-01-04h.html but these things cost about 200$ so I don't know how excited i'd be to drop $200 when i can get it free from Motorola whenever they decide to pony up and do these upgrades.
Click to expand...
Click to collapse
Well I'm willing to put money on the fact they'll be on ebay for under $70 soon. The high speed 14.4mbps cards can be found for ~$45-50 at the moment.
have you been able to find them anywhere online? I have only seen them on one site so far and they aren't in stock.
http://www.pwsstore.com/mc7750.aspx
Do they wifi xooms have the pci slot too?
Sent from Motorola Atrix on TELUS.
760hacker said:
have you been able to find them anywhere online? I have only seen them on one site so far and they aren't in stock.
http://www.pwsstore.com/mc7750.aspx
Click to expand...
Click to collapse
No I haven't. But ebay would probably have them pretty soon.
mafiaboy01 said:
Do they wifi xooms have the pci slot too?
Sent from Motorola Atrix on TELUS.
Click to expand...
Click to collapse
I'm not sure. The main issue on the wifi xoom will be the sim card slot. I'm not sure if there is a slot on top of the sd card like the 3G models. If there is, it would be entirely possible.
ayilm1 said:
This thread is dedicated to manually upgrading the Xoom's hardware to support 3G/4G without waiting for Motorola. Thread will be updated as progress is made.
As you probably are all aware, Motorola will be rolling out 4G upgrades to the Xoom in time. For those who are unwilling to wait, there may be a solution. This is strictly at the theoretical stage for the time being so I'm not expecting it to be smooth sailing. Here is the posited idea.
.
.
.
.
.
Click to expand...
Click to collapse
For those who acquired the wifi only, do you think it'll be possible?
Cheers!
ayilm1 said:
No I haven't. But ebay would probably have them pretty soon.
I'm not sure. The main issue on the wifi xoom will be the sim card slot. I'm not sure if there is a slot on top of the sd card like the 3G models. If there is, it would be entirely possible.
Click to expand...
Click to collapse
I can confirm that there is a sim card slot on top of the sd-card, just checked my Wifi Xoom..
What a co-incidence. The actual modem of the "Sierra 595U CDMA Data Card" is actually a Sierra Wireless 5620(? don't quote me on that, I'm away from my desk right now) Mini-PCI card. When I switched from CDMA data to WiMax I took the 595U apart and put the M-PCI card aside.
So Sunday, after remembering there's support for the LTE modem (code-named "Wrigley") in the latest update's kernel, I grabbed my Torx-5 driver, pulled the back off, and replaced the dummy card with my Sierra Wireless card (which still works, but is unactivated). There should be enough common commands (since it's running on the internal USB interface, not the m-PCI one) to let any software at least see the card's in there (even though the result of "ATI" won't return anything near the same between the modems, so no full init would be done).
I commented-out a line in the init.stingray.rc file which explicitly turns off power to the Wrigley device until the LTE upgrade is ready, but there were no signs of the Sierra device in the system (however, I forgot to run an "lsusb" or equivalent before I stopped working on it and re-commented-out the line to save power on my Xoom).
I did notice when poking around that there appeared to be a RIL device entry for a high-priority radio (or thereabouts) that was shown to be explicitly disabled, but I suspect that since there's probably no Settings->Wireless entry that more software will also be required as well as the new hardware (for example, the LTE devices will need to be able to have some support software to copy the MEID contents of the SIM card into the radio).
I can play with it a bit more this week, but I do suspect there's a fair amount of software that gets installed by VZ that comes from Moto as well.
What IS nice is that LTE card also does CDMA/GSM 3G (well, it's really all "3G", but that's a discussion for somewhere else ) 'cause I'd really like to put this device on GSM/UMTS networks, too, and I think that should be fairly easy to hack once the rest of the SW goes in.
ayilm1 said:
The sim slot is already wired to the PCI bus so connecting the two interfaces
Click to expand...
Click to collapse
You have this from a good source, or is it conjecture? I'd always imagined the SIM slot would have been attached to one of those 4 "mystery" serial ports that comes up when the kernel boots, so the GSM models (which use the QCT 6600 chip the CDMA models have but with different radio SW) could also read the SIM card.
(I'd kill for a schematic for this thing!)
I have taken the liberty to compile the make file from the site and have placed it into /lib/modules and it seems to be recognised without problems.
Click to expand...
Click to collapse
Interesting. I'll have to take a look at that site's source code, but if you look at init.stingray.rc post-3.1-update it appears that it's all being controlled by the USB serial driver, with no extra kernel support (save GPIOs for power, which is now in there) required.
Do you have the "dmesg" output from when you "insmod"ed that driver?
mafiaboy01 said:
Do they wifi xooms have the pci slot too?
Click to expand...
Click to collapse
IIRC someone on XDA opened theirs and the board has the pads for the slot but the slot's not physically there. It could be added, I suppose, if one's proficient with soldering.
kcrudup said:
IIRC someone on XDA opened theirs and the board has the pads for the slot but the slot's not physically there. It could be added, I suppose, if one's proficient with soldering.
Click to expand...
Click to collapse
Well sounds douable if the software is available.
Sent from Motorola Atrix on TELUS.
The sim card tray would have to already be connected with the card bus. Motorola's not going to do any soldering when you send in the xoom are they?
ayilm1 said:
The sim card tray would have to already be connected with the card bus.
Click to expand...
Click to collapse
I'm sure it's connected- the issue is where.
It seems to me- and this is merely speculation, but makes sense- that if they were to wire the SIM-card pins straight to the mini-PCI slot (and is that even possible- most of the assignment of those pins predate the current crop of modem cards) then how would they handle the case of the 3G models on GSM/UMTS networks, which also need to be able to read the SIM, but pass that information onto the on-board Qualcomm MDM6600 3G-radio chip.
I'm almost sure- but again- guessing- that the SIM card is wired to one of the myriad serial ports that we have off the Tegra chip:
Code:
<6>[ 17.788307] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
<6>[ 17.789411] tegra_uart.0: ttyHS0 at I/O 0x0 (irq = 68) is a unknown
<6>[ 17.789732] Registered UART port ttyHS0
<6>[ 17.789855] tegra_uart.2: ttyHS2 at I/O 0x0 (irq = 78) is a unknown
<6>[ 17.790204] Registered UART port ttyHS2
<6>[ 17.790329] tegra_uart.3: ttyHS3 at I/O 0x0 (irq = 122) is a unknown
<6>[ 17.790571] Registered UART port ttyHS3
<6>[ 17.790761] tegra_uart.4: ttyHS4 at I/O 0x0 (irq = 123) is a unknown
<6>[ 17.791009] Registered UART port ttyHS4
<6>[ 17.791254] Initialized tegra uart driver
ttyHS0 is the (internal) serial console, ttyHS2 is the BCM4329 Bluetooth (and the Qualcomm radio reports itself as a set of seperate series of USB-serial ports) so what are the other two ports for?
Somewhere around the office i have a spec about the SIM-card data format and how to get at it; I might play around with the ports and see if any of 'em return anything sensible.
kcrudup said:
You have this from a good source, or is it conjecture? I'd always imagined the SIM slot would have been attached to one of those 4 "mystery" serial ports that comes up when the kernel boots, so the GSM models (which use the QCT 6600 chip the CDMA models have but with different radio SW) could also read the SIM card.
(I'd kill for a schematic for this thing!)
Interesting. I'll have to take a look at that site's source code, but if you look at init.stingray.rc post-3.1-update it appears that it's all being controlled by the USB serial driver, with no extra kernel support (save GPIOs for power, which is now in there) required.
Do you have the "dmesg" output from when you "insmod"ed that driver?
Click to expand...
Click to collapse
Not quite an schematic, but they DID tore down the Xoom:
http://www.ifixit.com/Teardown/Motorola-Xoom-Teardown/4989/1
hatanakaf said:
Not quite a schematic
Click to expand...
Click to collapse
Not even close, and I imagine everyone here's already seen that when it came out two months ago.
So, anyway, since y'all got me started I did a little more investigation. My current CDMA-only card apparently has a different power/status/initialization sequence than whatever LTE card will go in there, as when I powered it up and down there was no change to the USB device enumeration:
Code:
# echo powerup > /sys/class/radio/wrigley/command
# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 002 Device 002: ID 22b8:2a70
# lsusb -v
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 002 Device 002: ID 22b8:2a70
# echo shutdown > /sys/class/radio/wrigley/command
# lsusb -v
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 002 Device 002: ID 22b8:2a70
# exit
... nor much change in the kernel output (this is with DEBUG turned on in the "Wrigley" driver):
Code:
<6>[ 109.685537] wrigley_command: user command = powerup
<7>[ 109.685637] wrigley_do_powerup: enter
<7>[ 109.685687] wrigley_do_powerup: set disable high
<7>[ 109.685776] wrigley_do_powerup: reset value = 1
<7>[ 109.685825] wrigley_do_powerup: started wrigley in normal mode
[... snip ...]
<6>[ 132.235998] wrigley_command: user command = shutdown
<6>[ 132.236282] wrigley_do_powerdown: powering down
<7>[ 132.236543] wrigley_do_powerdown: reset value = 1
<7>[ 132.345266] wrigley_do_powerdown: reset value = 1
<7>[ 132.455461] wrigley_do_powerdown: reset value = 1
<7>[ 132.565078] wrigley_do_powerdown: reset value = 1
<7>[ 132.675386] wrigley_do_powerdown: reset value = 1
<7>[ 132.785252] wrigley_do_powerdown: reset value = 1
<7>[ 132.895479] wrigley_do_powerdown: reset value = 1
<7>[ 133.005067] wrigley_do_powerdown: reset value = 1
<7>[ 133.115580] wrigley_do_powerdown: reset value = 1
<7>[ 133.225524] wrigley_do_powerdown: reset value = 1
So it looks like trying to probe around with a similar card for demonstration purposes won't get us anywhere.
kcrudup said:
So, anyway, since y'all got me started I did a little more investigation. My current CDMA-only card apparently has a different power/status/initialization sequence than whatever LTE card will go in there, as when I powered it up and down there was no change to the USB device enumeration:
Code:
# echo powerup > /sys/class/radio/wrigley/command
# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 002 Device 002: ID 22b8:2a70
# lsusb -v
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 002 Device 002: ID 22b8:2a70
# echo shutdown > /sys/class/radio/wrigley/command
# lsusb -v
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 002 Device 002: ID 22b8:2a70
# exit
... nor much change in the kernel output (this is with DEBUG turned on in the "Wrigley" driver):
Code:
<6>[ 109.685537] wrigley_command: user command = powerup
<7>[ 109.685637] wrigley_do_powerup: enter
<7>[ 109.685687] wrigley_do_powerup: set disable high
<7>[ 109.685776] wrigley_do_powerup: reset value = 1
<7>[ 109.685825] wrigley_do_powerup: started wrigley in normal mode
[... snip ...]
<6>[ 132.235998] wrigley_command: user command = shutdown
<6>[ 132.236282] wrigley_do_powerdown: powering down
<7>[ 132.236543] wrigley_do_powerdown: reset value = 1
<7>[ 132.345266] wrigley_do_powerdown: reset value = 1
<7>[ 132.455461] wrigley_do_powerdown: reset value = 1
<7>[ 132.565078] wrigley_do_powerdown: reset value = 1
<7>[ 132.675386] wrigley_do_powerdown: reset value = 1
<7>[ 132.785252] wrigley_do_powerdown: reset value = 1
<7>[ 132.895479] wrigley_do_powerdown: reset value = 1
<7>[ 133.005067] wrigley_do_powerdown: reset value = 1
<7>[ 133.115580] wrigley_do_powerdown: reset value = 1
<7>[ 133.225524] wrigley_do_powerdown: reset value = 1
So it looks like trying to probe around with a similar card for demonstration purposes won't get us anywhere.
Click to expand...
Click to collapse
Are you sure the current LTE card even runs through USB? I am sure you already know this but just in case, the current slot only contains a dummy card. If the present radio in the Xoom doesn't appear attached under USB then maybe it isn't even run through that bus.
ayilm1 said:
Are you sure the current LTE card even runs through USB? I am sure you already know this but just in case, the current slot only contains a dummy card.
Click to expand...
Click to collapse
I'm gonna stop writing this stuff if y'all aren't gonna read it
A-hem:
kcrudup said:
I grabbed my Torx-5 driver, pulled the back off, and replaced the dummy card with my Sierra Wireless card
Click to expand...
Click to collapse
But yes, the control interface appears to be USB. From /init.stingray.rc:
Code:
service gadget-lte-modem /system/bin/tty2ttyd /dev/ttyACM0 /dev/ttyGS0 0 512
oneshot
disabled
The "ttyACM0" here is the name given out to USB "ACM" devices, i.e., modems and such. Now there's always the possibility that the card will attach to the PCI bus, bring along it's own USB host-controller driver and represent itself as an ACM device that way, but that's somewhat unlikely, IMO.
kcrudup said:
... if they were to wire the SIM-card pins straight to the mini-PCI slot (and is that even possible- most of the assignment of those pins predate the current crop of modem cards)
Click to expand...
Click to collapse
I might be wrong about this- I just re-opened the case on the Sierra Wireless 595U, and it turns out that there's an option for having a SIM-card in there for GSM/UMTS variants of this device- and there's a chip on-board which is there apparently to control the SIM card, but I dunno how it interfaces to the device (i.e., feeds to the mini-PCI bus, or is another USB-serial device).
I gotta start reading some specs!
Related
WMP11 cant find Storage Card Solution *FIX*
http://support.microsoft.com/kb/931621/en-us my RAID array took a dump on me so it will be awhile till I can test this, let me know if it works. via ppcthoughts.com *edit* I updated the heremes FAQ in the Wiki with this info, should I place it somewhere else in the wiki?
Worked for me like a charm. This is windows vista premium edition. spiritofseth said: http://support.microsoft.com/kb/931621/en-us my RAID array took a dump on me so it will be awhile till I can test this, let me know if it works. via ppcthoughts.com Click to expand... Click to collapse
I get an error message that says: "The update does not apply to your system" I am running Vista Premium Edition too, but still cannot sync files to the data card in my 8525. Anyone else run into this problem?
spiritofseth said: my RAID array took a dump on me so it will be awhile till I can test this... Click to expand... Click to collapse IDE platters wazn't made for RAID... SCSI platters are... ?Glitch
?Glitch said: IDE platters wazn't made for RAID... SCSI platters are... ?Glitch Click to expand... Click to collapse lol the platters are basically the same , the disk controller/driver motors and buffers are the big diff. besides my array was SATA. what happened is that my old nforce board had a fan over the southbridge that stopped functioning. it overheated and begin working erratically until it just stopped. this is a big piss off cause that board isnt available anymore and i lost the array. so I upgraded to a pentium d 925/ 4coredual-vsta board from asrock. got to keep my old geforce 6600 and can upgrade slowly. I had to use my backup computer with unbuntu and my powerbook for a little over a week. it wasnt a super experience but it worked. then on top of all that my DSL modem died! I have a cisco adsl modem on its way but now Im using a backup dsl modem.
spiritofseth said: lol the platters are basically the same , the disk controller/driver motors and buffers are the big diff. besides my array was SATA. what happened is that my old nforce board had a fan over the southbridge that stopped functioning. it overheated and begin working erratically until it just stopped. this is a big piss off cause that board isnt available anymore and i lost the array. so I upgraded to a pentium d 925/ 4coredual-vsta board from asrock. got to keep my old geforce 6600 and can upgrade slowly. I had to use my backup computer with unbuntu and my powerbook for a little over a week. it wasnt a super experience but it worked. then on top of all that my DSL modem died! I have a cisco adsl modem on its way but now Im using a backup dsl modem. Click to expand... Click to collapse I've run MySQL, MSSQL, Access, Alpha ISAM on x86 TSR, all on Adaptec/Promise RAID IDE/SATA and Adaptec, Perc, Compaq, DPT... RAID SCSI all under business application, monitor the bad sector count as they rise on IDE/SATA, SCSI just keeps truckin... Then there was always the little problem with the raid tables being stored on the drive under IDE/SATA media, when the disk is full, the tables get overwritten... -Nice feature for creating more disk space... It has been my experience that cheaper media cannot take the pounding of constant writes when OS flushes cache to disk, beyond that, the features of the cheaper raid solution just don't fall within mission critical requirements. ?Glitch
it really depends on the manufactuer. google just finished a drive reliability study concluding that there was no real difference between any particular drive manufacturers enterprise and consumer drives as far as reliability go. I have had only 1 consumer hard drive fail on me in over 10 years. all I had to do was mount it upside down though and it keeps on trucking. the diff between scsi and ide are in the way the controller writes data to the disk and reads. the platters are for the most part the same. more expensive drives have better motors heads and on board controllers and warranties. in either case it was not the drives that failed it was the nforce raid controller that overheated.
Post your hardware details from Odin Mode (gathering SAV related info)
Turn off your phone, Press and hold Vol Down and Power to get into Odin mode and post the details. ALSO COULD YOU PLEASE POST WHETHER YOU ARE EXPERIENCING VOLUME / 900MHZ RADIO RELATED ISSUES OR NOT Board Name: tuna REV 9 Board Rev: HSPA - 9 Boot Type: USB MMC1 Device Type: HS Build Date: Oct 30 2011 12:32:21 please also include what network you are with, or what network the secondary phone is on that you tested with if you conducted this test
oscillik said: If you are experiencing the Volume / 900MHz radio issue please post your details here: Turn off your phone, Press and hold Vol Down and Power to get into Odin mode and post the details. Mine are as follows: Board Name: tuna REV 9 Board Rev: HSPA - 9 Boot Type: USB MMC1 Device Type: HS Build Date: Oct 30 2011 12:32:21 Click to expand... Click to collapse EXACTLY the same as yours.
So far It seems my phone DOES'NT suffer from SAV but here are my details anyway: board name : tuna REV 9 board rev : hspa - 9 boot type : usb mmc1 device type: hs build date : oct 30 2011 12:32:21 Same as the above 2 posts Build date seems to be exactly the same down to the second. Maybe it refers to when the firmware was compiled? //EDIT: Tested again and my handset does indeed have the problem
juicytuna said: So far It seems my phone DOES'NT suffer from SAV but here are my details anyway: board name : tuna REV 9 board rev : hspa - 9 boot type : usb mmc1 device type: hs build date : oct 30 2011 12:32:21 Same as the above 2 posts Build date seems to be exactly the same down to the second. Maybe it refers to when the firmware was compiled? Click to expand... Click to collapse i have edited the title to reflect a more ambiguous data collection, rather than just getting a biased collection of data only from people that are experiencing the issue. it would be good to find out if people who aren't experiencing it have different details. thanks for your post.
oscillik said: Turn off your phone, Press and hold Vol Down and Power to get into Odin mode and post the details. ALSO COULD YOU PLEASE POST WHETHER YOU ARE EXPERIENCING VOLUME / 900MHZ RADIO RELATED ISSUES OR NOT Board Name: tuna REV 9 Board Rev: HSPA - 9 Boot Type: USB MMC1 Device Type: HS Build Date: Oct 30 2011 12:32:21 Click to expand... Click to collapse My details are also the same as these and I'm experiencing the volume problem.
I know this isn't related to your post, but just thought I'd let you know. Apparently the problem has been "fixed" by Google and Samsung with an update. P3Droid reports it has been fixed and he's supposedly running the new version, 4.0.2. "And now I'm one of very few people who is running Android 4.0.2.....Can't wait to see how this runs"
dnlsmy said: I know this isn't related to your post, but just thought I'd let you know. Apparently the problem has been "fixed" by Google and Samsung with an update. P3Droid reports it has been fixed and he's supposedly running the new version, 4.0.2. "And now I'm one of very few people who is running Android 4.0.2.....Can't wait to see how this runs" Click to expand... Click to collapse this is related to the Verizon version of the Galaxy Nexus and in no way relates to the current issues.
Now that SIM-free handsets are being shipped, it is good to bring this thread forward again. I'll add a link to the other thread too.
Board Name: tuna REV 9 Board Rev: HSPA - 9 Boot Type: USB MMC1 Device Type: HS Build Date: Oct 30 2011 12:32:21 No issues here with Volume, tried it with a wildfire and galaxy. No issues, but i'll keep an eye on it. Version 4.0.1
I've contacted Clove and asked if they can provide the information from one of the devices they claim to have tested and found no issues with. Hopefully they'll reply but we'll have to wait and see.
Tung_meister said: I've contacted Clove and asked if they can provide the information from one of the devices they claim to have tested and found no issues with. Hopefully they'll reply but we'll have to wait and see. Click to expand... Click to collapse handtec found faults im sure clove is affected to, id be willing to bet the odin info will be identical to the P4U stock
OMAP-Samsung HW Information Board Name : tuna REV 9 Board Rev : HSPA - 9 Boot Type : USB MMC1 Device Type: HS Build Date : Oct 30 2011 12:32:21 Phone checked with HTC Desire on Vodafone, no flip outs here !!
birdster said: OMAP-Samsung HW Information Board Name : tuna REV 9 Board Rev : HSPA - 9 Boot Type : USB MMC1 Device Type: HS Build Date : Oct 30 2011 12:32:21 Phone checked with HTC Desire on Vodafone, no flip outs here !! Click to expand... Click to collapse I hope you don't take this as offensive, but considering the overwhelming evidence that supports the theory that the entire current batch of handsets in the UK are suffering from this problem, would you please be willing to record a video showing that your handset isn't suffering from this problem? In this video, could you also prove that the secondary handset is operating on 2G Vodafone? I don't mean to come across as disbelieving, but we need cold hard facts here, and considering that the evidence thus far is conclusive with an issue with the entire batch, it seems incredible that you are not experiencing the problem.
Board Name: tuna REV 9 Board Rev: HSPA - 9 Boot Type: USB MMC1 Device Type: HS Build Date: Oct 30 2011 12:32:21 Issue replicated Galaxy Nexus on o2 (Running in 2g mode). Phone was brought "SIM Free" from O2 store, Leeds. Nexus One on o2 (Running in 2g mode) With Nexus One left in "3G" mode, issue did NOT replicate - we only saw the problem with the phone in 2g mode. Followed youtube video, held Neuxs One over volume button then made a call on Nexus One. Volume rocker went whacky! Maybe worth people including carrier information on their posts as well just to confirm those without the issue don't see it due to carrier.
updated original post to request network information too
OMAP-Samsung HW Information Board Name : tuna REV 9 Board Rev : HSPA - 9 Boot Type : USB MMC1 Device Type: HS Build Date : Oct 30 2011 12:32:21 However I am NOT suffering from the issues that have been mention Network Orange. Handset purchase from P4U. Need to complete some tests to be 100% certain thou.
oscillik said: I hope you don't take this as offensive, but considering the overwhelming evidence that supports the theory that the entire current batch of handsets in the UK are suffering from this problem, would you please be willing to record a video showing that your handset isn't suffering from this problem? In this video, could you also prove that the secondary handset is operating on 2G Vodafone? I don't mean to come across as disbelieving, but we need cold hard facts here, and considering that the evidence thus far is conclusive with an issue with the entire batch, it seems incredible that you are not experiencing the problem. Click to expand... Click to collapse No offence taken, ive just tested again for ages, moving the desire near the vol switches and all over, i got it to freak out twice in 2 mins, just seems the desire must be shielded more than most, sorry for the confusion, I placed it right next door to the GN just like in the video and mine didnt freak doing it that way !!
birdster said: No offence taken, ive just tested again for ages, moving the desire near the vol switches and all over, i got it to freak out twice in 2 mins, just seems the desire must be shielded more than most, sorry for the confusion, I placed it right next door to the GN just like in the video and mine didnt freak doing it that way !! Click to expand... Click to collapse ahh I see, as I suspected!
Tiggerbits said: OMAP-Samsung HW Information Board Name : tuna REV 9 Board Rev : HSPA - 9 Boot Type : USB MMC1 Device Type: HS Build Date : Oct 30 2011 12:32:21 However I am NOT suffering from the issues that have been mention Network Orange. Handset purchase from P4U. Need to complete some tests to be 100% certain thou. Click to expand... Click to collapse Unless you are using a SIM card that operates on 900MHz (O2, Vodafone, giffgaff, Tesco Mobile) then you wouldn't see this issue. You can follow the example here to see if your handset is affected, by using a secondary phone that is forced into 2G mode and runs on a 900MHz network
Board Name: tuna REV 9 Board Rev: HSPA - 9 Boot Type: USB MMC1 Device Type: HS Build Date: Oct 30 2011 12:32:21 I'm Orange and have not had the volume bug but I can provoke it with a GS2 on vodafone in 2G mode, it took me many attempts but it did eventually cause the volume bug.
UART Location How-To
As much as I despise Qualcomm's lock down practices, I must admit that the Qualcomm processor is pretty darn solid. There aren't too many problems with Qualcrapp . However, that's now and I've got some information which may help some of you out in the future. I did some hacking last night on a live stream with a few other XDA members from this and other forums. The goal was to find the UART location on the AT&T Galaxy S3. Why, you might ask, would this be useful? During kernel and bootloader development, sometimes the device won't boot to the point where you can obtain logs to determine the problem. UART can provide the realtime eyes-on that you need to troubleshoot such problems. So the process was as follows... On a rooted device, pull the kernel. Extract it. Add command line parameters to enable UART. Code: console=ttyHSL0,115200n8 loglevel=9 Recompress into a boot.img. upload with Heimdall. Teardown the device. Adb shell into the device. Execute the following code so you push data through the UART port and know if the device has locked up. Code: su while [ 0 ]; do date| tee /dev/ttyHSL0; busybox sleep .5; done After that, you can locate the UART port by probing at 115200bps. The TX from the board (your RX lead] is placed 2nd from the bottom on the battery side of the board. RX is either the one above that or middle on the other side. Video: In the video, at about 5 minutes in, I said I didn't know what the 31 value was... and the kmesg logs were pretty thin.. Well, turns out they are the kernel message levels. For full logging, change that to 987654321. Samsung usually uses the 9 identifier to represent shell access . So, I hope this helps. UART provides eyes before any other method of debugging (aside from JTAG) begins to work. UART is the first thing to do in order to make a device into a development board.
Forgot to mention.. There is surely a switch in the PARAMS to enable early bootloader logging. This is yet to be found.
Thanks Adam, amazingly helpful as usual
Wow awesome dude, good work! You never dissappoint haha. Sent from my SAMSUNG-SGH-I747 using xda premium
I haven't watched the video yet because the loading is soooo slow. Is it possible to uart in to the headphone jack on this device? We were able to do this on the Atrix 4G.
upndwn4par said: I haven't watched the video yet because the loading is soooo slow. Is it possible to uart in to the headphone jack on this device? We were able to do this on the Atrix 4G. Click to expand... Click to collapse No. If anything were possible it would be the USB port.
AdamOutler said: As much as I despise Qualcomm's lock down practices, I must admit that the Qualcomm processor is pretty darn solid. There aren't too many problems with Qualcrapp . Click to expand... Click to collapse Wasn't fully aware they had lock down practices. Could you say more about that? Like what is it? What did they do? Thanks. Aaron Swartz, Rest in Pixels.
I try to find the UART port on an APQ8064(Mi2 and Nexus4 are using it). Just one question: how can I probe uart? just random connecting my RX to any pins on the board? Can't this completely break the hardware?
[Q] Can anyone with linux and an DINC 2 help me?
I purchased a "new open box" DINC 2 running Android 2.3.4 and can not get it to connect to my linux PC. I have tried multiple micro-USB cables but it will not connect. lsusb does not recognize the phone. Could someone on linux run lsusb with the phone connected and tell me if the device shows in lsusb. I suspect the phones usb port may be INOP. Thanks
LSUSB output with a working USB should look like: Bus 002 Device 013: ID 0bb4:0ff9 High Tech Computer Corp. Just in case anyone stumbles on this later.
Phone to emulate Mifare Ultralight card?
Hi guys, So my room at uni uses a VingCard locking system and the card (when I read it using my Galaxy S4 (I'm running Android 4.4+)) is a Mifare Ultralight. The card reads fine on my phone, is there any way I can use my phone to emulate the ID of the card so my phone can open the lock to my room? The reason why I'm asking is because I've lost my card 2-3 times now and my uni charge me £20 to replace the card each time. This would save me a lot of hassle (and money) so any help would be appreciated. I've spent a while researching and looking around for a way to get my phone to emulate the card but it's looking unlikely so far. A little detail I extracted from the locking company's website on the type of cards they use: RFID Specifications: 13,56MHz technology Compatible with the following standards: - ISO 14.443A (MIFARE) - ISO 14.443B - ISO 15.693 Compatible with Near Field Communication (NFC) standards
Your phone generates a unique ID every time it's scanned. I once read about certain phones (I believe it was a Nexus) on which you could flash a custom firmware for the chip that allowed card emulation but by default it's not possible.
there are already countless threads about that, even with the same chips, you could look them up because there most probably will be already a solution
Vashiru said: Your phone generates a unique ID every time it's scanned. Click to expand... Click to collapse If your phone uses PN53x NFC chip then in card emulation mode the first UID byte (UID0) is hardwired to 0x08. For MIFARE Ultralight emulation you need UID0 = 0x04. This problem is solved in EMUTAG Emulator on emutag.com.