Related
Ok, so we haven't had quite as much luck yet as we would have liked, but I think as we continue to try out different approaches we will have some luck. I think it might be beneficial for us to have a an overview of what has been tried and what has been attempted thus far. So here is a list of things people have tried (please feel free to add anything that I may have left out or accidentally overlooked).
Registry Edit to access Zune storage
I believe this was the first approach that people took to gaining access to the KIN, and this link provides a great walkthrough.
Bitpim
This is a pretty good overview of what has been attempted through Bitpim. Recently some have even tried using some other software, namely CDMA Workshop, (Look at the last post of the page.) I would suggest that we also try a couple more:
RevSkills
UniCDMA
Nvidia Tegra Flash
I forgot this when I first posted.
OpenZDK
This was another potential since much of the hardware, namely the processor is the same on both the kin and zune.
Looking for clues in the log files
To put it simply in the hidden menu there is an option to have system log s emailed to you. I tried reading through some and noticed some of the events and files that the KIN uses, but have not had any luck yet.
FTP
This link is the same as the link for the Log Files above.
Export/Import in hidden Menu
Once again, the linked used here is the same one for Log Files and FTP.
Please add anything that I may have left out, either different approaches or links to helpful information. I haven't had a chance to tinker with RevSkills too much yet, but it looks real promising.
Ah, we mods like these threads. Keep it up. Stickied.
The hidden import feature becomes active if you create a contact while using
qpst. It imports but I don't know where it put that info.
Interesting to note is that None of my phone entered contacts show up in qpst.
It is like that directory is mapped to some other place.
I was able to create directories and added txt files using qpst that remain even after power cycling the phone. I haven't found any of this using the phone yet.
I am getting the same results as you when I use the EFS manager and service programming. I can create files and make changes and they last after reboot.
I find it odd that when I export contacts from the hidden menu the file is visible in windows explorer if I have edited the registry as noted in the first post. I find this odd because everything else that is visible on the device using this method is related to the Zune, i.e. photos, music, and videos.
I have started looking back at some of the log files that I had the phone email me through the hidden menu and I have found some AT commands for the phone along with some other information. Here is a little bit of one file that I just started sorting through. The formatting isn't perfect because the log files have a lot of unreadable characters, but I have bolded files and commands. I also left everything in the case (upper and lower) as I found it in the file. The name of this file is:
MICROSOFT-PMX-DEBUGSTRINGPROVIDER-CHANNEL.02.clg
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_PRE_UPDATE
MPM_BB_USB_DRIVER_LOAD_UPDATE_EVENT, dwWaitTime: -1
MPM_Util:USB Client 1 has been Loaded
MPM_Util:USB Client 2 has been !UnLoaded!
CDMA Radio Updeate: Text stored version : v0.4.727
CDMA Radio Update:Registry Key version: v0.4.727
CDMA Radio Update: Current Modem version: v0.4.727
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_PRE_UPDATE
MPM_MainsSmThread
MPM_BB_UPDATE_REQ_EVENT - No modem update is needed
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_END_RSTISR_REQ_EVENT, dwWaitTime: -1
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_END_RSTISR_REQ_EVENT MODEM RESET ISR Init Completed.
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_POWER_ON_REQ_EVENT, dwWaitTime: -1
RILNDIS: GetPacketInterface Initialize = c117d634
Shutdown = c117c4e4
RILDrv : i : Accumulated response (1) : <cr><lf>
IOPTMODE: 6 <cr><lf>
RILDrv : i : Sending cmd: ATV0E0X3 <cr>
RILDrv : t : LoadEriData : Opening file
\RoamingIndicator\eri.bin
RILDrv : i : Accumulated response (1) : ATV0E0X3 <cr> 0 <cr>
RILDrv : t : LoadEriData:
\RoamingIndicator\eri.bin not exist. Err 0x00000002
RILDrv : i : Sending cmd:
AT+cstt=0, 1, 75, 85, 95, 100 <cr>
RILDrv : t : LoadEriData: Opening file
\Windows\eri.bin
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv : i : Sending cmd :
AT+CSTT=1,1,18,22,26,30 <cr>
PMIC Boot cookie: rb7262h
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv : i : Sending cmd :
AT+CSQT=1<cr>
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv:i: Sending cmd:
AT+GMI; +GMM; +GMR; +CKEYPAD?25<cr>
RILDrv:i: Accumulated response: +CKEYPAD:25
RILDrv:i: Accumulated response (2): equesting :
IUSBON, USBST, New PLMST, timestamp, 10, 2,2944 <cr><lf>
RILDrv:i:Accumulated response(1): +IQMIREADY <cr><lf>
+IUSBON<cr><lf>+IECHO: Requesting:IUSBON, USBST,
New PLMST, timestamp, 10, 2, 2944 <cr><lf>
RILDrv:i: ParseNotificationOEM: +IQMIREADY: SetEvent for QMI Init
RILDrv:i: Accumulated response(1): +IUSBON<cr><lf> +IECHO:
Requesting: IUSBON, USBST, New PLMST, timestamp, 10, 2, 2944<cr><lf>
RILDrv:i: Accumulated response(1): +IECHO:
Requesting: IUSBON, USBST, New PLMST, timestamp, 10, 2, 2944<cr><lf>
RilDrv:arseGetEquipmentInfo Modem Version: 727
I found out one more thing, if you use the s+l+power comination when the phone is powered off and connected to the computer another USB device is found. I just found this thanks to conflipper's early work We will have to come up with some sort of driver for this now.
Here is the name of the device and the hardware IDs
Microsoft Pink Bootstrap
USB\VID_045E&PID_2345&REV_0000
USB\VID_045E&PID_2345
I also just found this hardware id when having the computer turned off and plugged into the pc. When I hold down u+s+b+power Windows finds another device with the following name and hardware IDs (According to what I have found online this VID is Nvidia.) So this might be where we can use the tegra chipset stuff.
APX
USB\VID_0955&PID_7416&REV_0103
USB\VID_0955&PID_7416
Thought I would also add that my phone is currently unusable, but on the positive side, I wouldn't found those other two usb hardware IDs if this hadn't happened. Sidenote, I was using QPST Configuration program, and I right clicked on the my phone in the active phones tab. I then clicked on "Configure service to port mapping..." and added one property (unforturnately, I can no longer go back to the window because the program doesn't recognize my phone now). At this point, my phone rebooted and is now stuck trying to boot up.
I don't think it is completely bricked, but I fear that until we pull a rom it is probably useless because it is stuck in a constant cycle trying to reboot. The only way to stop this is to remove the battery. I have since tried using the various key combinations provided by conflipper and have found that the bootstrapper combination (s+l+power) would probably work if we had a rom. I then tried the hard reset combination (c+b+power) which initially looks like it might work but then it gets stuck in the cycle of rebooting.
I am going to continue working on it, hoping that somehow now that I might have some extra sort of access to hardware, but I am afraid my contributions may be limited until we are able to pull a rom.
Sorry to hear that. There has to be a way of getting it out of the loop.
RevSkills Hardware Log.
Diag Port Supported Command List.
7E - TRS FRM MSG supported.
5A - CHECK AKEY supported.
59 - EFS CMD supported.
58 - GET IS95B supported.
57 - SET MAX SUP CH supported.
56 - SUP WALSH CODES supported.
55 - FER INFO supported.
51 - GET FEATURES supported.
49 - READ PRL supported.
47 - UNKNOWN unknown response:
45 - GET CDMA RSSI unknown response:
44 - CHANGE SERIAL MODE unknown response:
43 - GET PARAMETER unknown response:
42 - UNKNOWN unknown response:
40 - SET PILOTS unknown response:
3F - GET STATE unknown response:
3E - UNKNOWN unknown response:
3D - CONF SLEEP unknown response:
3C - GET PACKET SEQNO unknown response:
22 - DISPLAY EMU supported.
04 - PEEK DWORD supported.
03 - PEEK WORD supported.
02 - PEEK BYTE supported.
01 - Show ESN supported.
00 - Version Info supported.
Click to expand...
Click to collapse
(the phone rebooted many times while doing this test, hence the unknown responses).
I tested more of the options provided by the free version of Revskills and it was kind of funny to see how the keyboard emulator worked, but only for numbers.
After all the reboots and so, i got some hex descriptions for errors in a new folder, called Err. Uploaded a new screenshot from that folder contents.
Easy CDMA just lets you browse the filesystem we already know.... not so much fun.
Little update.
You seem to be able to enter the recovery mode holding the U S B + power option but, as i tried right now, also using "Volume -" + power as stated for other tegra devices. Can't check if that loads ok on the computer, as i dont have the usb cable here right now.
OOPS I made a mistake. I am not seeing anything using windows 7 using u+S+B and power up. Should I disable zune, change registry for zune back to normal etc??
You shouldn't have to because the device has a different hardware id, so the drivers installed for the zune portion aren't applicable. Try turning your phone off, plugging in the usb cable and then using the key combinations. If the new hardware message box doesn't appear, you should still see an unkown device in device manager.
Also you have to hold the u+s+b+power for a few seconds before it will be recognized. When I have done this the screen stays blank on my phone and the only way I know it is working is through Windows.
Using Windows 7 OS. I had to uninstall the zune driver located in portable devices in the device manager then it found new APX device and i was able to point to the NVIDIA driver. Tried ruining the phone (Flashing android to it) as in another thread but it also got stuck on the flashing prompt. Restarted phone normally and the windows found another device and loaded the zune drivers back.
Incidently, holding the volume down and power on does the same as the U+S+B+Power and is easier on the fingers.
Thanks and keep up the great work.
I again may have spoken to soon. I cannot duplicate the above scenario anymore.
I also can no longer transfer pictures taken with my phone on to my pc. I can add pictures to the phone from pc and back but not the ones taken with the camera. Originally I could with zune software. The folders for uploaded pictures are different then the ones taken with the phone. I really think that I screwed something in the phone up by playing with qpst and others.
I'm not sure about what you did there, but in my testing & curiosity purposes trials, i wasnt able to alter the device (do a write to memory), so i doubt that qpst or the others did it for you.
Also, according to coinflipper notes, the kin has several layers, including the SBL that is the one operating with the os directly (the "Ms Pink bootstrap" device), not the recovery mode, which basically put us handling a modem....
I'm trying some things, but no results yet... gonna take some time....
I have changed the USB password and added contacts (somewhere) while writing to the device using qpst. I changed the password to 000001. Is this a different part of memory I am fooling with?
Thanks
I am not sure. I have no previous experience with any phone deving nor Qualcomm tools. Just pointed what coinflipper said.
I said "basically a modem", cause you got diag(nostics) mode within a com port, and some users (in other posts) showed logs with AT commands.
I'm working with some tools to connect to the device, but using the driver we all got (zune software). Not promising anything, just peeking around some tests.
@mcdietz
Here I pasted a public output of the linux command "lsusb -vv" (ultraverbose) where Kin (factory default settings) values are.
http://pastebin.com/rZscb9wz
Is useful for usb access to the kin. Use at will.
I have been testing usb connections to the kin devices (the ones we used in this forum) and i checked this:
Kin mode (normal Zune mode):
- Using MTP protocol:
-- You can browse files/folders/track related to Zune values using the lib-mtp tools in the system you like.
-- You can format the device (zune related folders) & delete zune files using the lib-mtp tools.
-- You can't download files from the device using the lib-mtp tools (kin doesn't allow you to)
-- You can't upload files to the device using the lib-mtp tools (kin doesn't allow you to)
- Using raw USB:
-- You can Write & Read values to the device (Kin VID 0x045e, PID 0x0641). Protocol allowed: MTP
Click to expand...
Click to collapse
Of course, Zune software does use this mode and is allowed to write to the filesystem. But that's because before doing so, it uses MTP protocol values to send and receive crypto values based on JANUS from Microsoft (Microsoft DRM for Mobile Devices) and after crypto relationships, the usb commands enable the "Connected" window at the Kin.
Capturing and replaying this values over usb does not work (ever) and does not work for the kin (had to try), so no go-go from here. Also, we cannot know if it would be able (dreaming after bypassing the DRM) to go outside the pictures/music/etc folders.
On the other hand, MTP tools reports that our little friend is able to reproduce the following files:
Firmware file
MediaCard
Abstract Playlist file
Abstract Album file
JPEG file
Microsoft Windows Media Video
MPEG-4 Part 14 Container Format (Audio+Video Emphasis)
Advanced Audio Coding (AAC)/MPEG-2 Part 7/MPEG-4 Part 3
MPEG-4 Part 14 Container Format (Audio Emphasis)
Microsoft Advanced Systems Format
Microsoft Windows Media Audio
ISO MPEG-1 Audio Layer 3
Click to expand...
Click to collapse
Where firmware is strange and good but the question is... how to upload the firmwares files (you can get zune firmwares from the net) to the zune software on the device (and run them)?.
It's more interesting when you notice that firmwares contain "Zboot.bin" which is "Tegra device bootloader" but, sadly, doesnt work with nvflash because of what I said below. Those updates are WinCE updates too...
APX mode (nvidia "flashing" mode), with or without Nvidia driver.
- Using nvflash
-- You can't start flashing due to writing to usb error
-- Following attemps block the nvflash and device access.
- Using raw USB:
-- You can't Write or Read values to the device (APX VID 0x0955, PID 0x7416). Protocol allowed: None
Click to expand...
Click to collapse
This matches the post where coinflipper told us that you cannot dump the rom image.
Microsoft Pink Bootstrap (No driver):
- Using raw USB:
-- You can Write & Read values to the device (Kin VID 0x045e, PID 0x2345). Protocol allowed: Unknown
-- Phone answers "01" to all the write requests i did (from "00" to "FF").
Click to expand...
Click to collapse
markspace. com/kin/
Here's some software that was developed for it, but I'm guessing it is only client end?
I'm not allowed to link, so assemble the spaces yourself please
The link for the download (direct) , being for Mac(only) is:
http://www.markspace.com/kin/download.php
But you must register to get an activation code from the main page (posted by shlhu). It will need internet access to activate the software during installation and reboot after it.
Requires Itunes (for audio sync), Iphoto (for image, also have started it once), and Quicktime (for video).
I tested it with a fresh installed Snow Leopard and i can say that it works. I dunno how it does (without zune installed), but it works.
Unfortunately, i wasnt able to analyze the usb transmission there, so i cant compare with the windows one. If it can skip the JANUS drm, then we may have a chance. If it is the same process as windows... we are done... lol.
Below is probably an excessive amount of explanation of everything I have dug up on this issue. If you aren’t interested in the details, the numbered points should be fine. The rest aims at assisting people who know more than me to possibly arrive at a solution as no one appeared interested in fixing it. So hopefully this info will show that this is indeed a problem and not the intended behavior for these devices.
So while bored and tired of signing into my school network every day, I spent a good chunk of Friday looking into the issue I and others have had of getting a random wifi MAC address every time we boot our phones. Initially, I just set out to attempt to lock in one of the random addresses until I wiped my phone. For that would be miles above it randomizing every boot. What I discovered, however, was that there is a great deal more to this issue than has been shared in any of the threads I have found. I will outline my findings below and then attempt to explain them in more detail.
There was a rumor floating around that Samsung/Google did this intentionally in order to avoid having to purchase a range of MAC addresses for these phones. This is decidedly FALSE and something I have never been able to accept, but now I have proof:
As shown in posts around the web, there exists code in the Kernel for generating a random MAC. What is not shown, however, is that this is simply a backup case if the kernel isn’t explicitly passed in a MAC. I was able to find my correct MAC in the HIDDEN file: “/factory/wifi/.mac.info”. This address was 1 higher than the Bluetooth MAC that is displayed which is how they are typically distributed to these devices, sequentially
This discovered MAC address has the first 3 digits of “2C:44:01” which seem to match the addresses reported for people who don’t have the randomizing issue. It also matches the address people have had before it changed to being random: (https://community.verizonwireless.com/thread/767358)
The findings indicate that this issue is entirely software based OR possible to fix in software, at the very least.
The bad news: I don’t actually have a solution for fixing the problem the ‘correct’ way, as it is likely an issue with the boot loader. That said, I think it is highly probable that given the MAC exists on disk, the kernel/rom could be modified to read it from there and provide a solid fix, at least temporarily.
If you know of this issue, you have likely seen the randomizing code in the kernel. What you haven’t seen, is the code that comes directly before it. I’ll try to explain it the best I can for those not versed in the wonders of C and pointers using the “//” comments as the actual code has none. I pulled the file from francos source as I had no desire to download the entire AOSP source.
/arch/arm/mach-omap2/board-tuna-wifi.c:
Code:
[COLOR="DarkGreen"]//This stores the mac address, it is set by DEFAULT to 00:90:4C:00:00:00
//and this is why all random MAC’s have the first 3 octets as 00:90:4C[/COLOR]
static unsigned char tuna_mac_addr[IFHWADDRLEN] = { 0,0x90,0x4c,0,0,0 };
[COLOR="DarkGreen"]//This function is passed in a string on the kernel command line
//which is SUPPOSED to hold the wifi cards MAC address[/COLOR]
static int __init tuna_mac_addr_setup(char *str)
{
char macstr[IFHWADDRLEN*3];
char *macptr = macstr;
char *token;
int i = 0;
[COLOR="DarkGreen"]//If the string passed in is empty, we exit, leaving the
//default address intact[/COLOR]
if (!str)
return 0;
pr_debug("wlan MAC = %s\n", str); [COLOR="DarkGreen"] //Print to dmesg the passed in string[/COLOR]
if (strlen(str) >= sizeof(macstr)) [COLOR="DarkGreen"]//If not in the correct format, exit[/COLOR]
return 0;
strcpy(macstr, str);
[COLOR="DarkGreen"]//Copy the MAC over one byte at a time and convert the string into a
//machine-readable value[/COLOR]
while ((token = strsep(&macptr, ":")) != NULL) {
unsigned long val;
int res;
if (i >= IFHWADDRLEN)
break;
res = strict_strtoul(token, 0x10, &val);
if (res < 0)
return 0;
tuna_mac_addr[i++] = (u8)val;
}
return 1;
}
[COLOR="DarkGreen"]//This function will correctly accept and set the MAC, IF it is passed one
//We will see shortly the problem lies in the fact that it is passed nothing
//and this causes a random MAC to be used[/COLOR]
Code:
[COLOR="DarkGreen"]//This function simply tells the linux kernel to call the above function with the
//value that it is passed in on the command line[/COLOR]
__setup("androidboot.macaddr=", tuna_mac_addr_setup);
Code:
[COLOR="DarkGreen"]//Now is the “offending code” as it has been put
//The code is fairly straightforward and simply checks
//that the correct arguments are passed and that it is on
//the intended hardware but…[/COLOR]
static int tuna_wifi_get_mac_addr(unsigned char *buf)
{
int type = omap4_tuna_get_type();
uint rand_mac;
if (type != TUNA_TYPE_TORO)
return -EINVAL;
if (!buf)
return -EFAULT;
[COLOR="DarkGreen"]//Now, this code DOES randomize the MAC address. But this is ONLY done
//if the default address as shown above is still set. This would mean that
//the first function was passed in nothing or that it was unable to parse what
//it was given correctly.[/COLOR]
if ((tuna_mac_addr[4] == 0) && (tuna_mac_addr[5] == 0)) {
srandom32((uint)jiffies);
rand_mac = random32();
tuna_mac_addr[3] = (unsigned char)rand_mac;
tuna_mac_addr[4] = (unsigned char)(rand_mac >> 8);
tuna_mac_addr[5] = (unsigned char)(rand_mac >> 16);
}
memcpy(buf, tuna_mac_addr, IFHWADDRLEN);
return 0;
}
So now we know that having a random MAC address is not intentional, or at least not the default behavior. Now we will take a step out, to the kernel command line which is the mechanism from which the kernel is intended to receive a MAC address. This can be found in the ‘dmesg’ log or often in crash reports. The great beauty of this is that it also includes the bootloader and radio versions which will allow us to determine if it is limited to certain bootloaders or is a universal problem. (# is replaced for paranoia to protect the innocent)
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMELA03 androidboot.baseband=I515.FA02 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.cdma=I515.FA02 androidboot.macaddr=
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMELA03 androidboot.baseband=I515.FA02 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.cdma=I515.FA02 androidboot.macaddr=2C:44:01:##:##:##
Already we can see important similarities and differences. My kernel command line (top) and this random log I found through Google both have the same EVERYTHING; 4.0.4 bootloader and radios. The glaring difference being that my ‘androidboot.macaddr’ is blank, and theirs is not. Here are a few more for completeness:
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMEKL01 androidboot.baseband=I9250XXKL1 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.macaddr=
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMEKJ10 androidboot.baseband= lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.macaddr=
Kernel command line: console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend androidboot.serialno=################ androidboot.bootloader=PRIMEKL01 androidboot.baseband=I515.EK04 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.cdma=I515.EK06 androidboot.macaddr=
Here we have a GSM nexus, unknown model, and a CDMA Nexus on 4.0.3 bootloaders and radios, all failing to pass in a mac. It is worth mentioning that I reflashed my nexus to 4.0.2 rom and bootloader/radios and locked the bootloader only to have the problem persist. From this it should be reasonable to conclude that this problem happens on most bootloader versions but is also not guaranteed to happen with any version. Admittedly, I don’t know any other way that arguments would be passed into the kernel other than the bootloader so more insight on this might be able to help in crafting a solution.
As I mentioned above, what I believe to be the correct MAC does exist on the phone under /factory/wifi/ in the hidden file ‘.mac.info’. Additionally, the Bluetooth MAC is under the file /factory/bluetooth/bt_addr. While I was unable to find a reference to the wifi mac, I did find a line for the Bluetooth mac under the root directory in ‘/init.tuna.rc’ Line 103: setprop ro.bt.btaddr_path “/factory/bluetooth/bt_addr”. My first guess would be that a fix can’t be as simple as adding a line to point a property to the correct wifi address, but before this I had never touched Android or Linux source so I would love to be wrong about this.
Finding all of this info took about an hour, failing to find a solution took a bit longer than that. Hopefully someone with some/any experience can find this useful and at the very least be on the lookout for a solution in their ongoing hacking and cracking. If you have any corrections or insight into all of this please share. As I mentioned, prior to this I had only the experience of using C/C++ and writing my own OS for a small board computer, but had never touched the Android/Linux source. If anything I said was wrong/incomplete/unclear, please please tell me!
Thanks for the doing a bunch of research on this! I have this issue and it's incredibly annoying as my workplace uses MAC filtering which requires me to sign-in again after every reboot!
Thanks. I just started getting this issue today.
it seems that the Kernal devs are including a little patch to their projects, Lean Kernel on Gummy 1.2.2 seems to have halted this randomizing, im still with a MAC that was left from the Randomiziation, but at least thats stopped for the time being on my Gnex, i found the .bin file on my phone one time that contained my original MAC, and it would be nice to do like i did with my Droid X with this exact issue.. (started on the DX when i flashed a CM rom on it. , just like the issue surfaced on my Gnex when i flashed a AOKP rom)
go do a google search for the randomizing issue (as of this date), you will see that there is a quick and dirty (but working) fix for this... if you are willing to run Lean Kernel
http://lmgtfy.com/?q=galaxy+nexus+random+wifi+MAC
I wouldn't call it a fix, but I have seen it and it should work well enough as a workaround until Samsung/Google can hopefully fix the underlying problem.
Franco also incorporated this fix into his kernel in the nightly updates. I agree it's not a perfect fix, but I don't really care what the MAC address is as long as I don't have to enable the WiFi every morning at work anymore!!
Does anyone know if you can use this info for creating a macchanger program just like what's available for desktop Linux?
It's kinda ironic that this is a bug for some people but it would be a great feature for me.
I want to be able to spoof MAC addresses because some public spaces give free internet access to wifi devices but only for a limited time.
Sent from my HSPA+ Nexus Prime using Tapatalk 2
Solved
I noticed today that my phone has this problem, and figured out how to solve it the "right" way (no kernel hacks). I'd like to share what I found.
This post mentions that the bootloader's "param" partition contains the wifi MAC address at offset 0x0c90. I dumped the param partition from my phone, opened it in a hex editor, and found nothing but zero bytes at that location. I inserted the correct MAC address there, flashed it back, and lo and behold, it shows up in the "androidboot.macaddr" option, and in the Android OS.
Here's a step-by-step, with a caveat: carelessly changing things in your param partition may brick your phone. The steps below worked for me, but be very careful that you're making the change in the right place.
Determine what your wifi MAC ought to be. As mentioned in the OP, it can be found in /factory/wifi/.mac.info, and it's probably one greater than your Bluetooth MAC, which you can find by turning on Bluetooth and looking in the phone's status screen in settings.
Dump your param partition to a file, using the directions here. (Ignore the lock/unlock stuff, though it's a good idea to unlock your bootloader before doing this. You only need to dump the partition once.)
Copy the param file to your computer and open it in a hex editor. (Or just use a hex editor on your phone, I guess.) If you don't have a hex editor, try HxD.
Go to address 0x0c90. You should find a bunch of zero bytes there. Enter your MAC address as a colon-separated ASCII string, just the way it's written in the .mac.info file, starting at 0x0c90. If you've done it correctly, you should've overwritten 17 bytes that were originally all zero, and the MAC address should be visible in your hex editor's ASCII view.
Save the modified file with a different name. (Don't overwrite the original.) Check that the file size hasn't changed: it should be exactly 8388608 bytes, the same as the unmodified one. If yours is bigger, it probably means you inserted new bytes rather than overwriting existing ones.
Flash the modified file back to your phone's param partition. You can do this with the "dd" command in the same way that you originally dumped it (just swap the "if=" and "of=" filenames), but I did it using fastboot, just to ensure that I could do it that way, in case the change somehow prevented Android from booting and I needed to flash the original params back. A command like "fastboot flash param param-modified.img" should do the trick, assuming your bootloader is unlocked.
Reboot the phone. If you did the previous step using fastboot, choose the "Restart bootloader" option to make sure the bootloader reads the modified params before you choose "Start" to boot Android.
Once booted, make sure your wifi is turned on, then go to Settings -> About phone -> Status, and check the MAC address to verify that the change worked. (If it didn't for some reason, I'd recommend flashing the original param file back, in case you accidentally changed the wrong thing.)
In case it's relevant, I'm using the PRIMELC03 bootloader from Verizon's JRO03O OTA.
There's nothing in /factory/wifi/ on my phone.. unless my file manager doesn't show hidden files even when it set to show hidden files
CodedChaos said:
There's nothing in /factory/wifi/ on my phone.. unless my file manager doesn't show hidden files even when it set to show hidden files
Click to expand...
Click to collapse
There is a file in mine.
Will the next nexus have a longer screen?
I like Mac spoofing, this should be a feature
Sent from my Galaxy Nexus using Tapatalk 2
Excellent! This worked great, thanks for the info. Ill update the OP at some point to add your info. Might even try to whip up a quick app to automate the process because this was the most crazy annoying problem I have encountered with my phone and I can't imagine how many people have had it. Thanks again!
Wyzard256 said:
I noticed today that my phone has this problem, and figured out how to solve it the "right" way (no kernel hacks). I'd like to share what I found.
This post mentions that the bootloader's "param" partition contains the wifi MAC address at offset 0x0c90. I dumped the param partition from my phone, opened it in a hex editor, and found nothing but zero bytes at that location. I inserted the correct MAC address there, flashed it back, and lo and behold, it shows up in the "androidboot.macaddr" option, and in the Android OS.
Here's a step-by-step, with a caveat: carelessly changing things in your param partition may brick your phone. The steps below worked for me, but be very careful that you're making the change in the right place.
Determine what your wifi MAC ought to be. As mentioned in the OP, it can be found in /factory/wifi/.mac.info, and it's probably one greater than your Bluetooth MAC, which you can find by turning on Bluetooth and looking in the phone's status screen in settings.
Dump your param partition to a file, using the directions here. (Ignore the lock/unlock stuff, though it's a good idea to unlock your bootloader before doing this. You only need to dump the partition once.)
Copy the param file to your computer and open it in a hex editor. (Or just use a hex editor on your phone, I guess.) If you don't have a hex editor, try HxD.
Go to address 0x0c90. You should find a bunch of zero bytes there. Enter your MAC address as a colon-separated ASCII string, just the way it's written in the .mac.info file, starting at 0x0c90. If you've done it correctly, you should've overwritten 17 bytes that were originally all zero, and the MAC address should be visible in your hex editor's ASCII view.
Save the modified file with a different name. (Don't overwrite the original.) Check that the file size hasn't changed: it should be exactly 8388608 bytes, the same as the unmodified one. If yours is bigger, it probably means you inserted new bytes rather than overwriting existing ones.
Flash the modified file back to your phone's param partition. You can do this with the "dd" command in the same way that you originally dumped it (just swap the "if=" and "of=" filenames), but I did it using fastboot, just to ensure that I could do it that way, in case the change somehow prevented Android from booting and I needed to flash the original params back. A command like "fastboot flash param param-modified.img" should do the trick, assuming your bootloader is unlocked.
Reboot the phone. If you did the previous step using fastboot, choose the "Restart bootloader" option to make sure the bootloader reads the modified params before you choose "Start" to boot Android.
Once booted, make sure your wifi is turned on, then go to Settings -> About phone -> Status, and check the MAC address to verify that the change worked. (If it didn't for some reason, I'd recommend flashing the original param file back, in case you accidentally changed the wrong thing.)
In case it's relevant, I'm using the PRIMELC03 bootloader from Verizon's JRO03O OTA.
Click to expand...
Click to collapse
OMG Thank you...This fixed my problem. Definitely worked for my randomizing MAC address on my Toroplus Galaxy Nexus.
Go to address 0x0c90. You should find a bunch of zero bytes there
^^ I did the param dump and there is no such address in the file.
wildtouch said:
Go to address 0x0c90. You should find a bunch of zero bytes there
^^ I did the param dump and there is no such address in the file.
Click to expand...
Click to collapse
Same here...
4.2.1 stock rooted
AHA! I have not used a hex editor since the Atari Falcon 030 days I just remembered that you dont do a normal Control-F to find 0x0c90 and you (depending on the editor) dont need the 0x... so after "Going To" 0c90 it jumped to the spot and I entered the MAC, saved the file, pushed to the sdcard, flashed it with dd and rebooted. BOOM! My MAC is now correct!
FTW, Thanks you so much Wyzard256!
So I'm curious - if I were to flash a full stock image using flash.all would it correct the MAC address randomization? I really don't trust myself with a hex editor.
Sent from my Galaxy Nexus using xda premium
Tried with the JDQ39 factory image, and indeed that does not correct the randomized MAC address. Oh well, guess I'll be random.
Sent from my Xoom using xda premium
This is pretty awesome. Wyzard256's post should be added to the OP and stickied though with a warning that it can be risky and may mess up your phone if you're not careful. I did it and I'm good.
Sent from my Galaxy Nexus using Tapatalk 2
orthonovum said:
AHA! I have not used a hex editor since the Atari Falcon 030 days I just remembered that you dont do a normal Control-F to find 0x0c90 and you (depending on the editor) dont need the 0x... so after "Going To" 0c90 it jumped to the spot and I entered the MAC, saved the file, pushed to the sdcard, flashed it with dd and rebooted. BOOM! My MAC is now correct!
Click to expand...
Click to collapse
I opened the param file using a Hex editor on my phone and I don't have this entry either - I have 00000c8d and 00000c96, but no 00000c90. I'd try editing one of those two but after the warning ("carelessly changing things in your param partition may brick your phone") I'm too scared to randomly edit it.
--Oh! I just randomly clicked. It looks like I can access 0x0c90 if I choose 0x8d and "scroll to the right" on this editor. So 0x0c90 only corresponds to one of the pairs of numbers in my MAC address - I ultimately need to edit 0x0c90 through 0x0c95, right?
Trying this out now...
It looks like it didn't work..? Maybe I did it wrong. Phone's not bricked though!
EDIT: It definitely didn't work - my MAC still starts with "00:90:4c" and changes every time I reboot.
The only thing I can think I did wrong was the re-uploading of the param file. I did the inverse dd method, explicitely:
Code:
adb shell
su
dd if=/sdcard/param.unlocked2.img of=/dev/block/platform/omap/omap_hsmmc.0/by-name/param
exit
exit
I had renamed the file to param.unlocked2.img. So does this look correct?
Hello,
since I'm new here, I cannot post to the specific forum. Anyway I'll just write everything here and ask politely to move my topic.
Yes, I'm another idiot, who bricked the touch screen by using the wrong tool... And that's how it started.
I disassembled the infamous FwTool that comes with Coby Kyros MID7022, EM73, Lark 70.2 and other tablets with Telechips TCC8803 and capacitive touch screen (based on SIS9209 chip). What I found until now:
FwTool uses a native library (SiS810IOjni) to communicate with TS over I2C
This library offers a few methods, like reading EEPROM, writing, screen recalibration
Now, more about EEPROM structure (names come from disassembled code):
Bootloader part 2: 0 - 12287 (12288 bytes)
Bootloader part 1: 12288 - 16383 (4096 bytes)
Phase 2: 16384 - 20479 (4096 bytes)
Phase 1: 20480 - 32767 (4096 bytes)
ZEUS: 32768 - ? (length determined by "flash_file_size - 32768")
The writing process itself doesn't disassemble too well unfortunately, but there are some known things:
The order of flashing inside FwTool is Phase 2, Phase 1, ZEUS, Bootloader part 1, Bootloader part 2
The write itself consists of RESET, WRITE_HEADER, QUERY, RESET, WRITE. This is not necessarily the proper order (bad disassembly).
Now, I'm still playing with FwTool and reverse-engineer it, but in a while I will need help from someone from the community, to provide me with the EEPROM image from their tablet, downloaded with my own application (under development). Don't worry, it will only READ memory, no writing. Anyone willing to help, please let me know. Any comments or feedback is highly appreciated.
Also, the whole process was done by me, but there is a post (http://forum.xda-developers.com/archive/index.php/t-1300624.html), where some other forum member tried to do this, but obviously didn't finish.
Let me know what you need and ill see off I can help
Sent from my HTC Desire using Tapatalk 2
flipside101 said:
Let me know what you need and ill see off I can help
Click to expand...
Click to collapse
Well, things look bad to be honest...
I bought a working touchscreen to do some flash copy, but it doesn't work that way... I can read the memory of a working TS, but because I have no memory map, I don't know where the actual flash memory is located.
I also tried to program some random data to the bricked touch screen - with no result.
To push things beyond this point - I need some kind of miracle... Or a datasheet, which is unobtainable (believe me, I tried).
Greetings... last day i opened six different coby MID7022.
It seems that Coby 7022 have two different hardware revisions. The (older?) revision use SIS IC as tochscreen controler... all of them worked fine after flashing it by fwnd. The new Revision have a Goodix GT801 TS Controler ... those who bricked the TS have this one.
THEBegga said:
Greetings... last day i opened six different coby MID7022.
It seems that Coby 7022 have two different hardware revisions. The (older?) revision use SIS IC as tochscreen controler... all of them worked fine after flashing it by fwnd. The new Revision have a Goodix GT801 TS Controler ... those who bricked the TS have this one.
Click to expand...
Click to collapse
Nope, it doesn't work that way. There are two different firmwares - touchscreen controller firmware and tablet firmware (FWDN - FirmWareDownLoader is the name of the utility for bulk-flashing. This is relevant unless there was no typo and there exists some utility called FWND). Bricking touchscreen happens when fwtool is used, which flashes TS Controller firmware. Reflashing with FWDN will not make it work, because FWDN does not flash TS firmware.
Sure, there may be other TS controllers than SiS, but still - I doubt that it changes anything...
Bricked screen remains bricked...
madman_xxx said:
Nope, it doesn't work that way. There are two different firmwares - touchscreen controller firmware and tablet firmware (FWDN - FirmWareDownLoader is the name of the utility for bulk-flashing. This is relevant unless there was no typo and there exists some utility called FWND). Bricking touchscreen happens when fwtool is used, which flashes TS Controller firmware. Reflashing with FWDN will not make it work, because FWDN does not flash TS firmware.
Sure, there may be other TS controllers than SiS, but still - I doubt that it changes anything...
Bricked screen remains bricked...
Click to expand...
Click to collapse
No, i connected the touchscreen cable to my custom atxmega32u4 board. The Pinout of this cable is very simple 3,3V,GND, two i²c wires and a Interupt pin INT which isn't connected to the TCC8803 stamp modul (there is a missing resistor...).
I send some configuration bytes (i get them from a gt801 kernel module and a very cryptic chinese datasheet) and then i was able to read the some touch vectors. Then i connected a usblab i2c watcher to the mainboard and flash it via fwdn. No cmd is send to the gt801!
I'm realy shure that FWND doesn't brick our touchscreens ...
in my opinion there are two reasons why the tochscreen stops working after flashing it via fwdn:
1. Missing init-routines in lk.rom (next days i get a mid7022 with v8 board and stock firmware...)
2. No Kernel drivers (maybe some kernel modul will fix it)
Hello.
My SGN2 have classic SDS symptoms (or maybe half SDS): Stuck at boot logo screen, recovery mode shows variuos of mount errors, and Odin fails to flash any file in download mode right after attempting to access NAND.
The device had rooted stock rom with Android 4.4.2 before of dying, and I can see the "product name" in download mode, so there's a possibility that actually it's not the famous sudden death syndrome, but some other kind of eMMC corruption.
After lots of search efforts which didn't lead me to an answer, I want to know from exprienced users if there's a known way to dump plain data out of the eMMC, with JTAG or eMMC reader / adapter, or other external equipment.
I saw in several tutorials that JTAG softwares have a read method. Does it access the direct sectors of the eMMC in low level, or it requires the same normal successful mounting in order to work?
Also, from what I understood, when mounting the eMMC with one of mentioned special devices, it's recognized on PC as a regular removable disk, similarly to a USB flash disk. Perhaps a program like "testdisk" will be able to achieve what I wish?
In addition, this woderful research thread mentions direct MMC commands that can be performed in some manner (I have no enough knowledge to understand how).
As @AdamOutler mentions in post #112 over there, he tried to develop a solution together with @Oranav and @Rebellos. Is there anyone who is familiar with this approach?
I'm mentioning also @Entropy512, @vim1, @AndreiLux and @E:V:A, which seem to have the knowledge according to that thread, hoping that someone can contribute to my thread here.
Thanks in advance for any help!
Meir
What recovery do you have? Does it have adb shell access through USB?
If so - you should be good to go with high level solution. If not, try flashing it with TWRP.
Mind you it might brick your phone "even more" if flashing fails somehwere in the middle.
It's possible to dump mmc using
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/dump.bin
(you need a SDcard mounted, so there's somewhere to dump to).
If my memory serves me well, if this is indeed a SDS - the eMMC will "freeze" once a broken memory block gets accessed. It will remain unresponsible until power-cycled - this can be done either by resetting the phone, or manipulating PMIC settings in the system.
So you'd want to read certain blocks from MMC - http://www.thelinuxdaily.com/2010/03/write-to-or-read-from-a-given-sector-using-dd/ and reboot your phone once you hit the bad one.
However, mind you, SDS was triggered by something. And that was a certain MMC command (TRIM) sent over during flashing by an unpatched system/recovery. Did this happen after some try to flash the device? It still might be some weird way of SDS or, as you said yourself, some other kind of corruption. The device itself is pretty old...
If you cannot reach it through recovery. We're talking another level of complexity.
JTAG would be your best shot, as it's fairly easily accessible and relatively easy to solder. It can break the CPU execution at any given moment, and then either upload a payload, or work directly through JTAG.
A payload would make the CPU configure eMMC and do the necessary stuff - like dumping parts of it to RAM (making it downloadable by JTAG, in process). JTAG could basically do the same, just slower. I am pretty sure there is a (most likely paid) software out there to do exactly that, but I have no experience with it whatsoever. I'm just familiar with the process.
It is also possible to hookup bare eMMC chip as a legacy SD card. But it's really tough (it's hard to imagine how small the chip connections really are, until you try to solder them). See my recent post about that:
http://forum.xda-developers.com/har...e-lumia-to-t2798431/post64703284#post64703284
Rebellos said:
What recovery do you have? Does it have adb shell access through USB?
If so - you should be good to go with high level solution. If not, try flashing it with TWRP.
Mind you it might brick your phone "even more" if flashing fails somehwere in the middle.
It's possible to dump mmc using
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/dump.bin
(you need a SDcard mounted, so there's somewhere to dump to).
If my memory serves me well, if this is indeed a SDS - the eMMC will "freeze" once a broken memory block gets accessed. It will remain unresponsible until power-cycled - this can be done either by resetting the phone, or manipulating PMIC settings in the system.
So you'd want to read certain blocks from MMC - http://www.thelinuxdaily.com/2010/03/write-to-or-read-from-a-given-sector-using-dd/ and reboot your phone once you hit the bad one.
However, mind you, SDS was triggered by something. And that was a certain MMC command (TRIM) sent over during flashing by an unpatched system/recovery. Did this happen after some try to flash the device? It still might be some weird way of SDS or, as you said yourself, some other kind of corruption. The device itself is pretty old...
If you cannot reach it through recovery. We're talking another level of complexity.
JTAG would be your best shot, as it's fairly easily accessible and relatively easy to solder. It can break the CPU execution at any given moment, and then either upload a payload, or work directly through JTAG.
A payload would make the CPU configure eMMC and do the necessary stuff - like dumping parts of it to RAM (making it downloadable by JTAG, in process). JTAG could basically do the same, just slower. I am pretty sure there is a (most likely paid) software out there to do exactly that, but I have no experience with it whatsoever. I'm just familiar with the process.
It is also possible to hookup bare eMMC chip as a legacy SD card. But it's really tough (it's hard to imagine how small the chip connections really are, until you try to solder them). See my recent post about that:
http://forum.xda-developers.com/har...e-lumia-to-t2798431/post64703284#post64703284
Click to expand...
Click to collapse
Hi Rebellos
What level of success do you think could be had with re-partitioning the emmc by trying to use the patched PIT's contained in the zip file "pits-N7100---FOR-EXPERTS-ONLY.zip" contained at the end of the thread http://forum.xda-developers.com/showthread.php?t=1667886
I can only get to download mode using USB jig. Otherwise screen shows "firmware encountered an error..." Regular flashing of stock PIT does not work. Phone never rooted and running stock 4.4.2. Just died one day.
Thanks in advance
have you search this error? I think no ! The forums are full with this error..... !!! a little bit Google "firmware encountered an error" and you have 447.000 Posts
and i have offered in last Post to help you with PM .... but no reaction
pls Do not say THX Press Button Thanks! it has helped................
Rebellos said:
What recovery do you have? Does it have adb shell access through USB?
If so - you should be good to go with high level solution. If not, try flashing it with TWRP.
Mind you it might brick your phone "even more" if flashing fails somehwere in the middle.
It's possible to dump mmc using
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/dump.bin
(you need a SDcard mounted, so there's somewhere to dump to).
If my memory serves me well, if this is indeed a SDS - the eMMC will "freeze" once a broken memory block gets accessed. It will remain unresponsible until power-cycled - this can be done either by resetting the phone, or manipulating PMIC settings in the system.
So you'd want to read certain blocks from MMC - http://www.thelinuxdaily.com/2010/03/write-to-or-read-from-a-given-sector-using-dd/ and reboot your phone once you hit the bad one.
However, mind you, SDS was triggered by something. And that was a certain MMC command (TRIM) sent over during flashing by an unpatched system/recovery. Did this happen after some try to flash the device? It still might be some weird way of SDS or, as you said yourself, some other kind of corruption. The device itself is pretty old...
If you cannot reach it through recovery. We're talking another level of complexity.
JTAG would be your best shot, as it's fairly easily accessible and relatively easy to solder. It can break the CPU execution at any given moment, and then either upload a payload, or work directly through JTAG.
A payload would make the CPU configure eMMC and do the necessary stuff - like dumping parts of it to RAM (making it downloadable by JTAG, in process). JTAG could basically do the same, just slower. I am pretty sure there is a (most likely paid) software out there to do exactly that, but I have no experience with it whatsoever. I'm just familiar with the process.
It is also possible to hookup bare eMMC chip as a legacy SD card. But it's really tough (it's hard to imagine how small the chip connections really are, until you try to solder them). See my recent post about that:
http://forum.xda-developers.com/har...e-lumia-to-t2798431/post64703284#post64703284
Click to expand...
Click to collapse
@Rebellos, I already have TWRP recovery, and I can access the device through adb, but it looks like it doesn't mount the external sdcard.
When I go to "Mount" menu in TWRP and press "External SDCard", I get this output in console:
Code:
[COLOR="Red"]E: Unable to mount '/external_sdcard'[/COLOR]
And this is "mount" output inside adb shell:
Code:
~ # ←[6nmount
mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,seclabel,relatime)
"cat /proc/devices" output:
Code:
~ # ←[6ncat /proc/devices
cat /proc/devices
Character devices:
1 mem
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
21 sg
29 fb
81 video4linux
89 i2c
108 ppp
116 alsa
128 ptm
136 pts
153 spi
180 usb
188 ttyUSB
189 usb_device
204 ttySAC
216 rfcomm
243 ump
244 mali
246 roccat
247 BaseRemoteCtl
248 media
249 ttyGS
250 usbmon
251 hsicctl
252 tzic
253 dia
254 rtc
Block devices:
1 ramdisk
259 blkext
7 loop
8 sd
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
179 mmc
254 device-mapper
"cat /proc/partitions" output:
Code:
~ # ←[6ncat /proc/partitions
cat /proc/partitions
major minor #blocks name
179 0 30657536 mmcblk0
179 1 30656512 mmcblk0p1
I tried to use the "dd" command you suggested in order to dump despite the above, and surprisingly, when I opened another terminal window, and used "kill" several times to track the "dd" progress, it showed in the first terminal:
Code:
~ # ←[6ndd if=/dev/block/mmcblk0 of=/sdcard/dump.bin
dd if=/dev/block/mmcblk0 of=/sdcard/dump.bin
1492162+0 records in
1492161+0 records out
763986432 bytes (728.6MB) copied, 53.898640 seconds, 13.5MB/s
2888160+0 records in
2888160+0 records out
1478737920 bytes (1.4GB) copied, 104.709910 seconds, 13.5MB/s
3251936+0 records in
3251936+0 records out
1664991232 bytes (1.5GB) copied, 118.393067 seconds, 13.4MB/s
3418080+0 records in
3418080+0 records out
1750056960 bytes (1.6GB) copied, 124.486490 seconds, 13.4MB/s
But then, as you predicted, the process suddenly halted, and the device restarted.
I connected the SD card directly to my PC and I couldn't see a file named "dump.bin".
And some weird thing- when I connect with adb again, the "mount" shows the same output, but "cat /proc/partitions", which listed "mmcblk0" and "mmcblk0p1" before, is now empty:
Code:
~ # ←[6ncat /proc/partitions
cat /proc/partitions
major minor #blocks name
Is it possible that the "dd" process damaged the mmc even more?
Okay, I found out what happened with "cat /proc/partitions", and apparently it's bad news.
It's always empty when the external sd card is not connected to the device, and not empty when it's connected.
I'm afraid that means that emmc partitions are not recognized at all..
So my only hope is using external boxes?
grwalker said:
Hi Rebellos
What level of success do you think could be had with re-partitioning the emmc by trying to use the patched PIT's contained in the zip file "pits-N7100---FOR-EXPERTS-ONLY.zip" contained at the end of the thread http://forum.xda-developers.com/showthread.php?t=1667886
I can only get to download mode using USB jig. Otherwise screen shows "firmware encountered an error..." Regular flashing of stock PIT does not work. Phone never rooted and running stock 4.4.2. Just died one day.
Thanks in advance
Click to expand...
Click to collapse
I think Josh from Mobiletechvideos was experimenting with that technique. It all depends on the block of eMMC that's damaged. If it's something around the beggining of the flash memory where bootloaders, GPT and PIT reside. It's probably impossible to walk-around with PIT patching. If it's somewhere further. It might be possible to fix it with patched PIT. Even if it worked, though - I wouldn't trust such device anymore when holding data.
MeiR_ct said:
Okay, I found out what happened with "cat /proc/partitions", and apparently it's bad news.
It's always empty when the external sd card is not connected to the device, and not empty when it's connected.
I'm afraid that means that emmc partitions are not recognized at all..
So my only hope is using external boxes?
Click to expand...
Click to collapse
Oh, sorry. I forgot to tell you - please post "dmesg" output if you can access the adb. But yeah, as far as I remember mmcblk0 should be eMMC, not external-sd. So it's a bad sign. But eMMC *must* be accessible because, obviously, bootloaders and recovery are being loaded succesfully from there.
About previous post - if mounting SD card failed (probably because TWRP expects to find it under mmcblk1 device node), you will be dumping files into RAM filesystem (this is how Linux behaves). SGS2 has, as far as I remember, 2GB of RAM. So after using all RAM available for in-memory rootfs, your phone crashed.
As long as you don't mix up "if" and "of" parameters of dd command - you shouldn't damage the device anymore.
What's more - when your recovery is already fully loaded into RAM and it occurs eMMC error - your phone shouldn't reboot, but rather burst out a load of errors into kernel log (dmesg). Kernel has no reason to panic as it can still execute.
Rebellos said:
Oh, sorry. I forgot to tell you - please post "dmesg" output if you can access the adb. But yeah, as far as I remember mmcblk0 should be eMMC, not external-sd. So it's a bad sign. But eMMC *must* be accessible because, obviously, bootloaders and recovery are being loaded succesfully from there.
About previous post - if mounting SD card failed (probably because TWRP expects to find it under mmcblk1 device node), you will be dumping files into RAM filesystem (this is how Linux behaves). SGS2 has, as far as I remember, 2GB of RAM. So after using all RAM available for in-memory rootfs, your phone crashed.
As long as you don't mix up "if" and "of" parameters of dd command - you shouldn't damage the device anymore.
What's more - when your recovery is already fully loaded into RAM and it occurs eMMC error - your phone shouldn't reboot, but rather burst out a load of errors into kernel log (dmesg). Kernel has no reason to panic as it can still execute.
Click to expand...
Click to collapse
2GB is clearly not enough, so I ended up using this guide to dump directly to PC, using "nc".
But as found out, it was an unneeded work, since I was dumping the external sd data (by the way, I found out when the size passed 16GB and was still increasing. Then I pulled out the micro sd and noticed that "cat /proc/partitions" is empty).
I have no idea why a sudden reboot occured when dumping to RAM, perhaps it's related to my issue?
The unfortunate fact is that currently I cannot dump anything from the emmc since it has no readable partitions.
Full dmesg output: http://hastebin.com/raw/pohunuhisu (was too long to fit here)
With grep of "mmc" (assuming these are the interesting ones):
Code:
~ # dmesg | grep mmc
dmesg | grep mmc
<5>[ 0.000000] c0 Kernel command line: console=ram loglevel=4 bootmode=2 sec_debug.level=0 sec_watchdog.sec_pet=5 androidboot.debug_level=0x4f4c [email protected] [email protected] [email protected] s3cfb.bootloaderfb=0x5ec00000 sysscope=0xee000000 lcdtype=1 consoleblank=0 lpj=3981312 vmalloc=176m oops=panic pmic_info=67 cordon=ba920e93ede2b6687252656e7f08332d connie=GT-N7100_OPEN_EUR_0c27b5455e10924c1fcfd032d76705c7 androidboot.emmc_checksum=3 androidboot.odin_download=1 androidboot.bootloader=N7100XXUFNL1 androidboot.selinux=enforcing androidboot.warranty_bit=1 androidboot.sec_atd.tty=/dev/ttySAC2 androidboot.serialno=4df1b7fc16e98fbf snd_soc_core.pmdown_time=1000
<6>[ 2.149294] c2 dw_mmc dw_mmc: clock source 0: sclk_dwmci (40000000 Hz)
<3>[ 2.150586] c2 mmc0: Version ID 0x5342240a.
<6>[ 2.150837] c2 mmc0: FIFO WMARK FOR RX 0x80 WX 0x40. ###########
<6>[ 2.152320] c2 mmc0: MSHCI controller on samsung-mshci [dw_mmc] using IDMA
<6>[ 2.152810] c2 s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (40000000 Hz)
<6>[ 2.153095] c2 mmc1: vtf_2.8v regulator found
<7>[ 2.153301] c2 Registered led device: mmc1::
<6>[ 2.154455] c0 sdhci_set_ios : MMC Card ON samsung-hsmmc
<6>[ 2.154508] c0 mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.2] using ADMA
<6>[ 2.154738] c0 mmc1: card removed.
<6>[ 2.154840] c0 s3c-sdhci s3c-sdhci.3: clock source 2: sclk_mmc (8800000 Hz)
<3>[ 2.154921] c0 mmc2: no vmmc regulator found
<7>[ 2.155208] c0 Registered led device: mmc2::
<6>[ 2.155460] c0 mmc2: SDHCI controller on samsung-hsmmc [s3c-sdhci.3] using ADMA
<3>[ 2.180888] c0 mmc0: cmd 52 response timeout error
<3>[ 2.181732] c0 mmc0: cmd 52 response timeout error
<3>[ 2.185774] c0 mmc0: cmd 8 response timeout error
<3>[ 2.186623] c0 mmc0: cmd 5 response timeout error
<3>[ 2.187458] c0 mmc0: cmd 5 response timeout error
<3>[ 2.188288] c0 mmc0: cmd 5 response timeout error
<3>[ 2.189119] c0 mmc0: cmd 5 response timeout error
<3>[ 2.189971] c0 mmc0: cmd 55 response timeout error
<3>[ 2.190886] c0 mmc0: cmd 55 response timeout error
<3>[ 2.191736] c0 mmc0: cmd 55 response timeout error
<3>[ 2.192589] c0 mmc0: cmd 55 response timeout error
<3>[ 2.211830] c0 mmc0: PERM_WRITE_PROTECT was set.
<6>[ 2.211866] c0 mmc0: VTU00M: 15010056545530304df1b7fc16e98fbf
<3>[ 2.290878] c0 mmc0: cmd 13 response timeout error
<6>[ 2.290975] c0 mmc0 : disable PON feature : ffffff92 : 00(10) : 00000000
<3>[ 2.291812] c0 mmc0: cmd 6 response timeout error
<3>[ 2.292644] c0 mmc0: cmd 6 response timeout error
<3>[ 2.293473] c0 mmc0: cmd 6 response timeout error
<3>[ 2.294305] c0 mmc0: cmd 6 response timeout error
<3>[ 2.294372] c0 mmc0: error -110 whilst initialising MMC card
<6>[ 2.329007] c2 sdhci_set_ios : MMC Card OFF samsung-hsmmc
It reboots when dumping to RAM fs because kernel runs out of memory and panics.
(Awesome idea with grep - much easier for me, when on mobile )
As suspected, though oddly. Internal eMMC controller is frozen already when recovery is running. The best shot would be power-cycling it through disabling and enabling the said vtf_2.8v regulator, hoping it doesn't power your CPU aswell. It can probably be done through sysfs. After that, another SDHCI driver probe should be somehow forced - I've got no idea how to do it without modifying kernel. But it might be doable. Try to do some lookup. I will aswell.
Remember dmesg is your best friend here. :3
//edit: Kernel patching itself is not an issue. Flashing it is, in your case. I suggest we try it as a last effort. Kexec, if supported by your current recovery kernel, is promising aswell.
Rebellos said:
It reboots when dumping to RAM fs because kernel runs out of memory and panics.
(Awesome idea with grep - much easier for me, when on mobile )
As suspected, though oddly. Internal eMMC controller is frozen already when recovery is running. The best shot would be power-cycling it through disabling and enabling the said vtf_2.8v regulator, hoping it doesn't power your CPU aswell. It can probably be done through sysfs. After that, another SDHCI driver probe should be somehow forced - I've got no idea how to do it without modifying kernel. But it might be doable. Try to do some lookup. I will aswell.
Remember dmesg is your best friend here. :3
//edit: Kernel patching itself is not an issue. Flashing it is, in your case. I suggest we try it as a last effort. Kexec, if supported by your current recovery kernel, is promising aswell.
Click to expand...
Click to collapse
First of all, I must thank you for your help and efforts so far.
My linux knowledge is quite low, so even before the driver task, I don't really know how to manipulate the vtf_2.8v regulator.
I made some search and saw there's a regulator interface API which should be accessed by some C language compiled script.
Code:
regulator_disable(regulator);
regulator_enable(regulator);
But I have no idea how to compile it correctly and initiate it after boot.
Can you please instruct me or to send me learning it from some tutorial?
Didn't Samsung fix this problem by releasing the kernel fix in Android 4.3?
It cannot be used from "script" nor "application". It's internal kernel API, accessible only from kernel space. You would need to either:
- modify kernel (sdhci driver, most notably), build it and then flash it over recovery (risky business with damaged eMMC, but you might end up doing that)
- modify kernel, build it and launch it with kexec (it is probably not supported by your recovery kernel)
- write a separate kernel module, build it into kernel module binary (.ko) and load it using insmod. It's probably the hardest solution.
//edit:
andrewKode said:
Didn't Samsung fix this problem by releasing the kernel fix in Android 4.3?
Click to expand...
Click to collapse
They supposedly did IIRC. That's why it might not be actually an SDS, but something quite similar.
//edit2:
Oh damn. I just looked at your dmesg again and realized my terrible mistake. VTF_2.8V regulates external SD card connection, not eMMC... It means I have currently not a real clue about how to access your eMMC without JTAG or something.
//edit3:
Here's the answer!
Dug out from publicly available N7100 schematics.
https://github.com/omnirom/android_...id-5.1/arch/arm/mach-exynos/mach-midas.c#L850
Deasserting this GPIO should power down both VMEM_VDD_2.8V and VMEM_VDDF_3.0V PMIC outputs. Which are powering eMMC.
This function controls the said pin:
https://github.com/omnirom/android_.../arch/arm/mach-exynos/setup-mshci-gpio.c#L154
It is called here:
https://github.com/omnirom/android_...0c1b6089d70/drivers/mmc/host/mshci-s3c.c#L585
You could try to suspend kernel (more info here: https://community.freescale.com/thread/261901) but it'll probably not suspend eMMC device, as it's not probed succesfully at all.
So a "proper" hack-around would power cycling eMMC around here:
https://github.com/omnirom/android_...0c1b6089d70/drivers/mmc/host/mshci-s3c.c#L366
by simply adding
Code:
pdata->set_power(pdev, 0); //power off
usleep(1000); //1ms sleep to make sure it is really powered down
pdata->set_power(pdev, 1); //power off
Then build the kernel + recovery and try to kexec it. If it fails, try flashing it and pray it won't break in the middle. Got no more ideas for now.
@Rebellos, I'm afraid that I'm quite lost here due to lack of knowledge.
I found a patched kernel zip for N7100 which includes kexec in this MultiROM MOD thread (kernel download for Touchwiz ROMs in post #2), and pushed it with adb to the device, but then the recovery failed to flash it, probably because the flashing process involves accessing those unmounting directories.
The questions is whether every kernel flashing will fail for the same reason.
If the alternative is to enable kexec support in my current kernel, I have no idea how to do it. =\
I'm a native Windows user, so unfortunately I don't know how to access each of the suggested methods.
You wont flash a thing using recovery, as it flashes stuff onto eMMC, which is already unaccessible.
I had Odin flashing in mind, but I forgot that you stated being unable to flash anything through Odin aswell. Got no viable solution for now then. If obtaining the data is urgent I recommend using a commercial recovery service or someone knowledgable with doing it through jtag.
I just figured eMMC could be power cycled using direct memory writes to GPIO control registers by any application. It still wouldnt get probed again by kernel though. I could try and develop aome walk-around solution but with my current time availability it would probably take weeks, if not months.
Okay, it's not so surprising for me that I cannot perform any recovery actions in the current state.
I contacted some recommended phone lab recently, for replacing the chip, and they said that they have an emmc reader to USB adapter.
I will try my luck there, hoping for a chance of recovering my data.
Thank you again for your time and help @Rebellos, I really appreciate it!
That's great to hear. I'm sorry couldn't help you more. Please let me know how did that go.
Rebellos said:
That's great to hear. I'm sorry couldn't help you more. Please let me know how did that go.
Click to expand...
Click to collapse
Frustration goes on!
It turned out that the lab still doesn't have mentioned eMMC to USB adapter, and it's on the way from a worldwide shipping.
The guy from the lab managed to detach the corrupted eMMC, but so far he didn't manage to revive the device after several attempts with new eMMCs.
He blames the eMMC cards supplier, but actually I'm afraid he damaged the motherboard during his attempts, although he has a very good reputation and experience handling this task.
The unfortunate is that other labs don't accept to touch the device in its current state, after someone else started the work.
He advised me to wait so he will try again, and there is nothing I can do about, since I don't have any special equipment.
It seems that instead of paying 50$ for a fix, I will have to move on to a new device, which means paying about 500$.
All I can hope is to be able to recover data from the detached eMMC card, while the guy will have the adapter.
MeiR_ct said:
Frustration goes on!
It turned out that the lab still doesn't have mentioned eMMC to USB adapter, and it's on the way from a worldwide shipping.
The guy from the lab managed to detach the corrupted eMMC, but so far he didn't manage to revive the device after several attempts with new eMMCs.
He blames the eMMC cards supplier, but actually I'm afraid he damaged the motherboard during his attempts, although he has a very good reputation and experience handling this task.
The unfortunate is that other labs don't accept to touch the device in its current state, after someone else started the work.
He advised me to wait so he will try again, and there is nothing I can do about, since I don't have any special equipment.
It seems that instead of paying 50$ for a fix, I will have to move on to a new device, which means paying about 500$.
All I can hope is to be able to recover data from the detached eMMC card, while the guy will have the adapter.
Click to expand...
Click to collapse
Hi MeiR_ct
Could this guy recover your data? please tell us how your story ended. I have a similar story.
br
ab1009 said:
Hi MeiR_ct
Could this guy recover your data? please tell us how your story ended. I have a similar story.
br
Click to expand...
Click to collapse
Hi ab1009, and sorry for the very late reply (noticed it just today).
In case it's still relevant for someone:
Unfortunately, the attempts to recover the eMMC card have failed.
I moved on to Galaxy Note 4 on that time, and later to Galaxy Note 8.
(Clearly proves that I'm an addicted and proud fan of Samsung Galaxy Note series )
There was a project for the Galaxy S3 which resulted in several repaired Phones. There are some attempts to port this approach to the Note 2, see: https://github.com/oranav/i9300_emmc_toolbox/issues/7
Ok, I have searched the internet and these forums for hours and have not seen an answer to this anywhere.
I can't believe I'm the only person who has ever wanted to know how to determine this information!
I repair Nexus 7 2013 as a hobby - usually with broken screens, but now and then buy a soft bricked one.
I have the same issue every time - trying to find what is the original build number when it is soft bricked and you can't access Recovery either. I have even tried to see if Asus has a cross reference of serial number to original build number - no they don't.
I use the Wug tool and so far the score is 3 saved, one that even has Wug stumped, and the one I'm working on tonight that I simply can't get to work.
I always have to guess and try versions. tonight I've tried the single version of 4.4.4 and 3 other version of 5 to 6. Each time the best that I can get is a sluggish boot that usually eventually freezes while trying to run setup. That is BEST CASE. Worst case would take pages to describe. It sort of works on lmy47v a little and not at all on any other build. Manufacture date is March 2015.
If I didn't know better, if this was a PC, I would say there is a bad RAM chip.
Regardless, I would feel a lot happier if I knew I was installing the right build which leads back to the original question - how do you find the original build if it's soft bricked?
Thanks to anybody who can answer this!
Do this:
PC: download TWRP image, e.g. twrp-2.8.6.0-flo.img
N7: boot in fastboot mode
PC run: fastboot boot twrp-2.8.6.0-flo.img
N7: in TWRP UI mount system
PC run: adb shell cat /system/build.prop > build.prop.txt
View build.prop.txt on PC:
Code:
ro.build.id=LMY48Y
ro.build.display.id=cm_flo-userdebug 5.1.1 LMY48Y ceb9c142ee test-keys
ro.build.version.incremental=ceb9c142ee
But why do you bother to restore "original build number"?
Most of them are locked and will lose all data in the process of unlocking.
Then why not flash the latest OS image?
k23m said:
Do this:
PC: download TWRP image, e.g. twrp-2.8.6.0-flo.img
N7: boot in fastboot mode
PC run: fastboot boot twrp-2.8.6.0-flo.img
N7: in TWRP UI mount system
PC run: adb shell cat /system/build.prop > build.prop.txt
View build.prop.txt on PC:
Code:
ro.build.id=LMY48Y
ro.build.display.id=cm_flo-userdebug 5.1.1 LMY48Y ceb9c142ee test-keys
ro.build.version.incremental=ceb9c142ee
But why do you bother to restore "original build number"?
Most of them are locked and will lose all data in the process of unlocking.
Then why not flash the latest OS image?
Click to expand...
Click to collapse
Thanks for your reply. No less complicated way to find that out eh? I'm afraid that's a bit over my head (or perhaps its just the way its worded - no offense intended). If it was PC, and particularly DOS, I would be laughing.
When nothing else was working on this particular tablet, I did try for the heck of it to use the Wug toolkit to root and install TWRP, and it would just lock up and never install - no error messages or anything.
As far as why not use the most recent image, there are lots of opinions, and the majority I have ever read says if you don't use the original build you will get all kinds of problems right up to completely bricking the device. Since you have to take every opinion with a grain of salt, it just seems to make sense to use what it came with. 2 out of 3 tablets I have been able to do that with I have be able to save. Only 1 where I used a random build worked.
consumer61 said:
No less complicated way to find that out eh?
Click to expand...
Click to collapse
The simplest way is to check it in stock recovery but you say it is not an option...
consumer61 said:
the majority I have ever read says if you don't use the original build you will get all kinds of problems right up to completely bricking the device
Click to expand...
Click to collapse
Please post a link to one of them.
k23m said:
Please post a link to one of them.
Click to expand...
Click to collapse
I wish I could. Just random things read from hundreds of pages over a couple of years, and of course when you look for them you can't find them. I have on and off been trying to find an answer to this question for over a year.
Even the wug toolkit encourages you to make a backup of your own system rather than re-flash a random stock image. Since as soon as you unlock you lose everything anyway, there hardly seems any purpose to a backup as opposed to just re-flashing with the newest version - ergo that also leads you to believe you need to use the exact version that was there before.
I don't discount the possibility that even though not said, what was actually meant was that each device model has a version specific to it. Again, that was never clearly said, I am just using logic based on your concept that you can install any image at all, with absolutely no issue.
consumer61 said:
I wish I could... when you look for them you can't find them.
...rather than re-flash a random stock image.
Click to expand...
Click to collapse
That's it, all those horror stories are from "random stock" flashers. If you choose wisely the very latest stock image then there is no danger whatsoever.
Let's talk about the latest case - is it unlocked already?
I was able to unlock, but could not access recovery - when booting to recovery it would still just sit at the Google logo.
In order, I tried from the list that comes up on the Wug tool, a 6.01 version, then lmy47v, then lmy48g, then finally thought I would try going back quite far since there was only one version for 4.4.4 - ktu84p, then finally lmy48t.
With tiny variations, all had the exact same result - no errors when wiping or reloading. The circling balls would just around as normal, then eventually grind to halt - moving a tiny bit every 5-30 seconds. After maybe an hour, sometimes you would finally get the normal "pick your language" screen, although most times, after about 30 min I would just shut it down and power it back on.
That would result in sometimes getting the "pick a language". Sometimes able to get as far as entering a gmail address, but the system would always lag - registering a touch many seconds after doing it. Once single time, I got a full boot up. Then it came up with the OTA as it should. ran it, and back to soft bricked.
Also a couple of the times I was able to get it to boot, as soon as you would reboot, it would be back to soft bricked.
Motherboard got exceptionally hot, and battery was down to 18% once, and 27% another time from full charge - so it was working abnormally hard
I have been playing with and building pc' etc since the Vic 20, C 64 and so on, and it behaves just like a bad RAM chip. I did find a post on here saying the Kingston/Toshiba chip can get corrupted and must be replaced, with a link to the same guy selling MB on ebay - can't remember his id on here, but here is the ebay sale:
http://www.ebay.ca/itm/121637666631?_trksid=p2055119.m1438.l2649&ssPageName=STRK:MEBIDX:IT
Overall this is similar behaviour although not quite as bad, as the other motherboard that stumped Wug. He finally said it must be hardware in that case, and I certainly tend to think the same thing here.
consumer61 said:
He finally said it must be hardware in that case, and I certainly tend to think the same thing here.
Click to expand...
Click to collapse
Let's find out exactly. As you are comfortable with DOS then the following should be piece of cake:
download twrp-2.8.6.0-flo.img from https://dl.twrp.me/flo/
go to Wug(NRT)\data folder - can you see fastboot.exe and adb.exe there?
boot the Nexus in fastboot mode (when off press power+vol.down), connect it to your PC
in Wug's data folder open a DOS command window and copy/paste: fastboot boot twrp-2.8.6.0-flo.img [Enter]
when TWRP is up and running, copy/paste in the DOS: adb shell dmesg > dmesg.txt [Enter]
you will find dmesg.txt in Wug's data folder
zip up the file and attach it to your next post
This is THE hardware log and another chance to play with DOS-like stuff :laugh:
Ok excellent instructions. (did tech support for years).
I had pulled the MB and replaced it, so I just switched it back.
Install TWRP worked fine. TWRP screen came up.
Typed command for the msg file, and dos error was "error: device '<null>' not found
I know of TWRP, but have never used it. I hit the centre button on the screen which brought up what appears may be an install log, and its full of errors.
Goes down over a full screen, but the common statement is:
"unable to find partition size for /boot" /recovery /misc and about 15 more lines.
Also other errors like unable to mount cache, data, system
I just took a photo of the screen but it seems you can't post actual images, only links to images stored on the internet, not something off your hard drive.
Just to let you know, I did try various spacing around the dmesg > dmesg.txt command just to be sure, same error every time.
Now that is from the TWRP screen with all the buttons on it. If you meant for me to open a certain function of TWRP, I didn't.
Regards,
UPDATE: had a brainwave and loaded up Wugfresh and device manger. Showed exclamation mark beside the device so re-installed adb driver. Now the log worked. It is only 64k, and both the twrp photo and the log file should be attached now.
I looked through the log, and even not knowing the internals of the system that well, only one part stood out as appearing bad:
<3>[ 0.277130] msm_gpiomux_install: write failure: -22
<3>[ 0.277221] msm_gpiomux_install: write failure: -22
<3>[ 0.277404] msm_gpiomux_install: write failure: -22
<3>[ 0.277496] msm_gpiomux_install: write failure: -22
<3>[ 0.277648] msm_gpiomux_install: write failure: -22
<3>[ 0.277740] msm_gpiomux_install: write failure: -22
<6>[ 0.278656] Registering gpio keys
<6>[ 0.278778] Reconfigure VOL_UP(GPIO155) and VOL_DOWN(GPIO189) with PMIC
<4>[ 0.278991] 8921_l17: Failed to create debugfs directory
<4>[ 0.280609] ------------[ cut here ]------------
<4>[ 0.280700] WARNING: at arch/arm/mach-msm/subsystem_restart.c:573 subsys_restart_init+0xd8/0x104()
<4>[ 0.280883] Modules linked in:
<4>[ 0.281066] [<c0015f44>] (unwind_backtrace+0x0/0x11c) from [<c007ae88>] (warn_slowpath_common+0x4c/0x64)
<4>[ 0.281250] [<c007ae88>] (warn_slowpath_common+0x4c/0x64) from [<c007aeb8>] (warn_slowpath_null+0x18/0x1c)
<4>[ 0.281433] [<c007aeb8>] (warn_slowpath_null+0x18/0x1c) from [<c0c0c600>] (subsys_restart_init+0xd8/0x104)
<4>[ 0.281616] [<c0c0c600>] (subsys_restart_init+0xd8/0x104) from [<c0008718>] (do_one_initcall+0x8c/0x15c)
<4>[ 0.281799] [<c0008718>] (do_one_initcall+0x8c/0x15c) from [<c0c00a24>] (kernel_init+0xe8/0x1a4)
<4>[ 0.281982] [<c0c00a24>] (kernel_init+0xe8/0x1a4) from [<c000fdf8>] (kernel_thread_exit+0x0/0x8)
<4>[ 0.282104] ---[ end trace ff63e6c2cba9c001 ]---
consumer61 said:
Typed command for the msg file, and dos error was "error: device '<null>' not found
Click to expand...
Click to collapse
When TWRP is running please type adb devices and it should respond like:
Code:
List of devices attached
087777e8 recovery
If not, re-plug USB cable, check Windows device manager for new hardware. You may need ADB driver but Wug would install it before.
Please upload the picture(s) to http://imgur.com/?noFlash
We don't need to interact with TWRP for this task at all.
Btw, TWRP was not flashed, but only temporarily booted so you may need to repeat it all over again.
Cheers
I suspect you were writing your reply above, as I updated the info. Please see the end of page 1 - the photo and the log file are attached.
simply put is was my mess up - adb had to be re-installed every time you plug a device in when running XP Pro. (Yes I know XP. Hate 7 and 8 and 10, but this is the last version where you had SOME semblance of control over your own computer lol)
Thanks!
consumer61 said:
I suspect you were writing your reply above, as I updated the info. Please see the end of page 1 - the photo and the log file are attached.
simply put is was my mess up - adb had to be re-installed every time you plug a device in when running XP Pro. (Yes I know XP. Hate 7 and 8 and 10, but this is the last version where you had SOME semblance of control over your own computer lol)
Thanks!
Click to expand...
Click to collapse
Yes.
I use Linux and ...XP too :highfive:
Please check my last post here.