Database Info

Strange... behaviour ?

Greetings,
Im getting a really odd problem with my kaiser. I turned it off yesterday nad connected the charger... the cellphone turned on, but showed me that screen that appears when we are flashing it (4 horizontal bars, red, green, blue, white)... (!!!)
Inside the red bar, I can read:
KAIS130 MFG
SPL-1.0.OlipPof
CPLD-8
Inside the white bar:
Serial
Funny thing is, the phone won´t turn off, I have to remove the battery. After leaving it without the battery for 60 to 120 seconds, I placed the battery again and turned it on... and it booted normally.
Now, most of the time it will boot into the color bars. Any ideas about what is going on ?? Please help... can´t use the phone!

Same thing.....sort of.
I had the same behavior on my Tilt for a while. I did find that if I plugged a usb cable into the phone, or put pressure on the USB port while booting, it would boot normally. It did this for about a week and then started booting normally all the time. The only thing I can think of that I changed that week was upgrading the radio. I upgraded to the 1.64.08.21 radio.
The screen you are seeing is the boot loader screen. When it comes on, does it flash a message real quickly that says something like "image file not found"? That is what mine was doing.
You may also want to check out this thread. http://forum.xda-developers.com/showthread.php?t=344402

StealthNet said:
Greetings,
Im getting a really odd problem with my kaiser. I turned it off yesterday nad connected the charger... the cellphone turned on, but showed me that screen that appears when we are flashing it (4 horizontal bars, red, green, blue, white)... (!!!)
Inside the red bar, I can read:
KAIS130 MFG
SPL-1.0.OlipPof
CPLD-8
Inside the white bar:
Serial
Funny thing is, the phone won´t turn off, I have to remove the battery. After leaving it without the battery for 60 to 120 seconds, I placed the battery again and turned it on... and it booted normally.
Now, most of the time it will boot into the color bars. Any ideas about what is going on ?? Please help... can´t use the phone!
Click to expand...
Click to collapse
You probably have a messed up bootloader, you can fix it. I had this last week. Check the stickys above. The key program to fix it is mtty, make sure read a lot about it.
check the "Flashing your device section"
http://wiki.xda-developers.com/index.php?pagename=KaiserFAQ
that should help

Well... I tried using mtty, but it won´t work. I suppose it will work only on Windows XP machines right ?
I tried in two machines (Vista 64 and Vista 32) wihtout luck.
I tried reverting the ROM back to OEM, including the bootloader. I successfully flashed this one, but Im still getting the 3 color bootloader.
Thing is, it still reads the same
Inside the red bar, I can read:
KAIS130 MFG
SPL-1.0.OlipPof
CPLD-8
Inside the white bar:
Serial
After reading the forums, I found out that I´ll get out of this problem by using MTTY, and that I should simply issue a " boot" command.
Is that right ?
If so, my only problem now is to get a Windows XP machine... because I can´t get MTTY to show an USB option to connect to. Already tried configuring activesync, killing the processes, without success.
Ideas ?

StealthNet said:
Well... I tried using mtty, but it won´t work. I suppose it will work only on Windows XP machines right ?
I tried in two machines (Vista 64 and Vista 32) wihtout luck.
I tried reverting the ROM back to OEM, including the bootloader. I successfully flashed this one, but Im still getting the 3 color bootloader.
Thing is, it still reads the same
Inside the red bar, I can read:
KAIS130 MFG
SPL-1.0.OlipPof
CPLD-8
Inside the white bar:
Serial
After reading the forums, I found out that I´ll get out of this problem by using MTTY, and that I should simply issue a " boot" command.
Is that right ?
If so, my only problem now is to get a Windows XP machine... because I can´t get MTTY to show an USB option to connect to. Already tried configuring activesync, killing the processes, without success.
Ideas ?
Click to expand...
Click to collapse
Yea, you are right, only works on XP. I couldn't get it to work on my Vista Box, had to use my gf XP laptop. goodluck, you should be fine once you find one.

Ok,,, not starting to get worried.
Connected to a MTTY, issued the boot command.
Received this as an outpout:
Cmd>boot
Fill RSVD information for block 288 to 309
Storage start sector=0xA680, total sector=0x10C40
Storage start block=687, total block=1073
Total Bad Block in CE: 0
Erase physical block from 975 to 2032
formatstorage Bad block found: 1658
formatstorage Bad block found: 1659
formatstorage Bad block found: 1918
si backup: Erase physical block from 2032 to 2048
No card inserted
OEMIPLInit clear 10MB ext RAM
OEMGetUpdateMode
OEMTranslateBaseAddress 23 80000000 80000000
IPLMSG:0x8:INFO: Loading image ...
IPLMSG:0x9:INFO: Jumping to image...
OEMLaunchImage crc of Mini-Kernel:0x7EB8DBEB
OEMLaunchImage 80000000
Jump to Physical Address 10300000
Now it boots, the bootloader screen appears rapidly, and it fades to white...

... removed the USB cable, the device turned off. Connected it again and the bootloader appeared again.
Any ideas ?

Since I successfully flashed the way in to the default OEM ROM, and I think my problem is related to the bootloader, I tried flashing HardSPL 3.56.
It flashed, rebooted, and booted nicely into WM 6.1 (default version out from this ROM).
The first automatic customization happened as it was supposed to... and it rebooted... into bootloader argh!!
Removed the battery, waited 120 seconds, boot the phone. Working so far. Now, it has a 50%/50% of getting a bootloader or booting correctly.
Any other ideas ?? Man, tell me about a strange thing...

Since there are more with the same problem, but they are discussing it in another thread from L26, I think it's ok to auto moderate this one

Just to point out that the problem is solved (I think) - read here -> http://forum.xda-developers.com/showthread.php?p=2415437#post2415437

Kaiser repeatedly rebooting itself

I have had a long weekend of reading and searching forums and need some help. I have managed to solve by previous issue of my Kaiser getting stuck in the tricolor screen.
Used the mtty file to reboot.
I have Hard SPL and now loaded Duttys Diamond V9. It took a number of efforts to get it to load but I was able to do this after loading the original HTC 6.1 Rom
Now i have a new problem with my Kaiser continually rebooting. This happens no matter which ROM I flash with. Can anyone help me.

skipball said:
I have had a long weekend of reading and searching forums and need some help. ...snip...
Now i have a new problem with my Kaiser continually rebooting. ...snip....
Click to expand...
Click to collapse
Just a guess - but you may have some bad blocks that are in the boot loader area.
Here is what I would do -
1. try loading a different ROM and see if that solves the problem (it seems as if you have already done this)
2. if you continue to have this issue I would send a message to either JOCKY or GSLEON3 - PM them and let them know what your issue is. Theya re the best at this sort of thing.
Good luck,
Bill

Honestly,
What I would do is flash back to original ROM and bring it back to the store if you still have your warranty... As I think this could indeed be a physical issue, might not be resolvable with software,
Regards,

Have you tried...
Did you HR prior to flash as well as after the flash? I had this happen once and now I always HR prior to flash and after Flash. Sometimes multiple HR's prior and post just because I am neurotic. Did you try removing the SIM card? Or maybe try using a different radio. Sometimes this behavior can be a radio issue. If you are using one of Dutty’s ROM, try using the Polaris radio. Try re-flashing the radio first, THEN re-flash your Dutty ROM and see if that helps. Probably a compatibility issue between the ROM and Radio, no? Maybe?
Anyway, hope this helps. I know it is frustrating.
~Gwen

Hrm,
I get this sometimes too. I'm thinking perhaps its an issue with one of your today screen plugins...I am sure that's what has caused it on my device before.

Syphon Filter said:
Hrm,
I get this sometimes too. I'm thinking perhaps its an issue with one of your today screen plugins...I am sure that's what has caused it on my device before.
Click to expand...
Click to collapse
I doubt that it is a today screen plug-in. If im understanding this correctly his Kaiser reboots b4 it even loads WM, so it wouldnt be a today screen issue.

Not Entirely
zeezee said:
I doubt that it is a today screen plug-in. If im understanding this correctly his Kaiser reboots b4 it even loads WM, so it wouldnt be a today screen issue.
Click to expand...
Click to collapse
Actually, he never said it would not boot into WM. He said that he finally got the dutty ROM to load and NOW his kaiser reboots continually which is why I posted what I posted. I didn't see where he said that it resets before it even loads WM. Although his second to last line does leave me wondering if he means that no matter what ROM he flashes it resets before WM OR if he means that he can flash ROMS, get to WM and then has the reset problem. The latter would be indicative of a today plugin.
~Gwen

Thanks for the replies.
It boots before and after the windows screen and is inconsistent.
Could it be a problem in the boot loader? I did have to flash the first couple of times from the tricolor screen.
I have also had problems with the soft reset button. It now seems to be ok after the last flash but prior i could not get the unit to hard or soft reset.
Here is what i get when i enter tricolor screen and run mtty
Cmd>set 14 0
Cmd>task 28
Format start
Fill RSVD information for block 288 to 309
Storage start sector=0xA480, total sector=0x10E40
Storage start block=679, total block=1081
Total Bad Block in CE: 0
Erase physical block from 967 to 2032
si backup: Erase physical block from 2032 to 2048
Format end
Cmd>boot
InitDisplay: Display_Chip=1
Fill RSVD information for block 288 to 309
Storage start sector=0xA480, total sector=0x10E40
Storage start block=679, total block=1081
Total Bad Block in CE: 0
Erase physical block from 967 to 2032
si backup: Erase physical block from 2032 to 2048
No card inserted
OSSIPreLoad ++
R 1.58.25.17
G 25.69.30.05H
D 3.55.00.00

skipball said:
Thanks for the replies.
It boots before and after the windows screen and is inconsistent.
Could it be a problem in the boot loader? I did have to flash the first couple of times from the tricolor screen.
I have also had problems with the soft reset button. It now seems to be ok after the last flash but prior i could not get the unit to hard or soft reset.
Click to expand...
Click to collapse
I'd strongly suggest try a different radio that's got good reputation for your OS.
Or could it also be dirt in the soft reset hole? I don't know...

ok I have now returned my phone to its original state. I Followed the procedures outlines in Sirsycho post (thanks)
http://forum.xda-developers.com/showthread.php?t=335568
It now appears the phone has stabilised.
Although I have managed to kill my original Battery in the process. Lucky for the back up battery.
The device is still rebooting so I guess there is a bigger problem then I can sort out
Is there a possibility that my soft reset button could have issues. It is definitely only working randomly!

For diamond we have L26 V9 ROM and Dutty V1 ROM. Which one of these do you have?

skipball said:
ok I have now returned my phone to its original state. I Followed the procedures outlines in Sirsycho post (thanks)
http://forum.xda-developers.com/showthread.php?t=335568
It now appears the phone has stabilised.
Although I have managed to kill my original Battery in the process. Lucky for the back up battery.
The device is still rebooting so I guess there is a bigger problem then I can sort out
Is there a possibility that my soft reset button could have issues. It is definitely only working randomly!
Click to expand...
Click to collapse
Mine will reboot randomly if I'm using Opera Mobile 9.5 beta or have it open. That happened to me with both the Laurentius and Dutty ROMs. I'm using the new HTC ROM that was posted over the weekend with the new radio and haven't done a lot of browsing but it hasn't happened yet.

skipball said:
I have had a long weekend of reading and searching forums and need some help. I have managed to solve by previous issue of my Kaiser getting stuck in the tricolor screen.
Used the mtty file to reboot.
I have Hard SPL and now loaded Duttys Diamond V9. It took a number of efforts to get it to load but I was able to do this after loading the original HTC 6.1 Rom
Now i have a new problem with my Kaiser continually rebooting. This happens no matter which ROM I flash with. Can anyone help me.
Click to expand...
Click to collapse
Not sure if this is the issue, but I loaded Dutty's Diamond not long ago, and my Kaiser reset every time I opened WMP. There's been a few reports of it, although some haven't had that problem. Loading a WMP cab does NOT fix it for me (again, some have had luck, other's haven't).

@skipball
sounds to me like this could be hardware related .. maybe your soft reset button is stuck pushed in ... just a theory. If the phone is reverted back to original state you could always return for warranty/replacement.

I returned my phone to its original state (I hope LOL!) and will send it back to HTC. It is still rebooting.

Bad Block on Kaiser (Task 2a?)

OK, so I've been having problems flashing lately, I keep getting an error 226 Flash Write. So I got MTTY and ran 'info 8' (i think) and it shows that I have a bad block. Now from what I'm reading, running a 'Task 2a' can "fix" bad blocks. Although it seems this is only in Oli's HardSPL. I've also read references saying not to ever run Task 2a because it will format everything off the phone and probably give you a brick. Before I read that though I saw another post saying to run it, so I tried it and it does nothing. Apparently this command has been taken out in v3 of SPL. So what's the story? Someone has to know...how can I fix this bad block so I can flash normally again. I'm currently running JockyW's 3.29 HSPL but I can switch to another version if that will let me fix my problem.
PLEASE HELP!!

schwags said:
OK, so I've been having problems flashing lately, I keep getting an error 226 Flash Write. So I got MTTY and ran 'info 8' (i think) and it shows that I have a bad block. Now from what I'm reading, running a 'Task 2a' can "fix" bad blocks. Although it seems this is only in Oli's HardSPL. I've also read references saying not to ever run Task 2a because it will format everything off the phone and probably give you a brick. Before I read that though I saw another post saying to run it, so I tried it and it does nothing. Apparently this command has been taken out in v3 of SPL. So what's the story? Someone has to know...how can I fix this bad block so I can flash normally again. I'm currently running JockyW's 3.29 HSPL but I can switch to another version if that will let me fix my problem.
PLEASE HELP!!
Click to expand...
Click to collapse
Post your info 8, some bad blocks are OK. Let's have a look at it
the task 2a is part of the MFG SPL's only pof's V1 and jockyw2001 1.1 Hard SPLs have MFG commands, that's why you have to use V1 or 1.1.
Before you do a task 2a you must make sure you are security unlocked. Otherwise it will be a brick.
Ta
Dave

Well I'm thinking that this one is not supposed to be there, hence the flash write errors I've been getting all the time. Thanks in advance! Also, where can I download the tool to unlock my device so I don't brick it. Here is a look:
Cmd>info 8
--- 2K bytes sector version ---
DEVICE NAME=samsung_k9k2g08
DEVICE ID=0xAA
DEVICE MAKER ID=0xEC
PAGE SIZE=0x800
TOTAL PAGE SIZE=0x840
BLOCK COUNT=0x800
BLOCK PAGE=0x40
Checking block information
BLOCK 2 (0x2) is reversed block
BLOCK 3 (0x3) is reversed block
BLOCK 4 (0x4) is reversed block
BLOCK 5 (0x5) is reversed block
BLOCK 7 (0x7) is reversed block
BLOCK 8 (0x8) is reversed block
BLOCK 9 (0x9) is reversed block
BLOCK 12 (0xC) is reversed block
BLOCK 13 (0xD) is reversed block
BLOCK 14 (0xE) is reversed block
BLOCK 15 (0xF) is reversed block
BLOCK 20 (0x14) is reversed block
BLOCK 1305 (0x519) is bad block
Partition[0], type=0x20, start=0x2, total=0x63E
Partition[1], type=0x23, start=0x640, total=0x740
Partition[2], type=0x25, start=0xD80, total=0x8D80
Partition[3], type=0x4, start=0x9B00, total=0x117C0
CE Total Length(with sector info) = 0x4DCD800
CE CheckSum Length(without sector info) = 0x4D80000

I'll assume that that bad block is indeed a bad block. (I could be wrong)
First things first security unlock your device: http://forum.xda-developers.com/showthread.php?t=361236&highlight=FrankenKaiser
Test the Security unlock status: http://forum.xda-developers.com/showpost.php?p=2580429&postcount=198
The next bit I am not 100% clear on...
FrankenKaiser will be able to re-install the SPL with 1.56: http://forum.xda-developers.com/showthread.php?t=394584&highlight=FrankenKaiser
But I don't know if you need to do a task 2a, or is FrankenKaiser does that for you. Also if you do a task 2a, can you just then use FrankenKaiser, or is there another step?
I suppose you could follow the FrankenKaiser instructions and then do an info 8 and see if that fixed it.
EDIT:
maybe you could ask GSLEON3 to have a read of this first, he's done it all before?
Ta
Dave

I'll take a look as soon as I get a moment. Task2a will NOT fix bad blocks. At least not on a Kaiser, so unless you are sporting a Hermes, leave task 2a alone. (For now at least)
There are several other commands that we can try, but you'll need my or Jocks mfg SPL & a little MSN Messenger walk thru time. PM me with a live/msn messenger address, or add [email protected].

Definitely leave t2a & FrankenK alone! Contact me.

Cheers.
I'll have to catch up on all this stuff one day rather than just reading and guessing
Dave

GSLEON3 said:
I'll take a look as soon as I get a moment. Task2a will NOT fix bad blocks. At least not on a Kaiser, so unless you are sporting a Hermes, leave task 2a alone. (For now at least)
There are several other commands that we can try, but you'll need my or Jocks mfg SPL & a little MSN Messenger walk thru time. PM me with a live/msn messenger address, or add [email protected].
Click to expand...
Click to collapse
Alright, I've got JockyW's 1.1 HSPL on here and my device is now officially security unlocked. Please contact me so I can fix this thing! Thanks

Well crap, I guess I really should've listened being that you put it in HUGE text but I didn't. I tried task 2a because i figured if it didn't work there wouldn't be any harm. I think I've bricked it....Now it powers on (I get the green light) but nothing ever comes on the screen. I think there's no SPL on there at all anymore or something. Anyone know a way to fix this or am I pretty much screwed now?

schwags said:
Well crap, I guess I really should've listened being that you put it in HUGE text but I didn't. I tried task 2a because i figured if it didn't work there wouldn't be any harm. I think I've bricked it....Now it powers on (I get the green light) but nothing ever comes on the screen. I think there's no SPL on there at all anymore or something. Anyone know a way to fix this or am I pretty much screwed now?
Click to expand...
Click to collapse
Now it's time for Franken Kaiser, me thinks
Hopefully you can recover your device. So long as the bad block's don't get in the way.
Ta
Dave

Can FrankenKaiser fix even if I have nothing coming up on the screen? I've installed the MotoQ drivers and it does show up when I plug it into my PC, but nothing is ever on the screen, no SPL I think. I'll try it...

schwags said:
Can FrankenKaiser fix even if I have nothing coming up on the screen? I've installed the MotoQ drivers and it does show up when I plug it into my PC, but nothing is ever on the screen, no SPL I think. I'll try it...
Click to expand...
Click to collapse
That's where Franken Kaiser came from... GSLEON3 did a task 2a and bricked his device for a few month's 'til jockyw fixed it.
Dave

schwags said:
Can FrankenKaiser fix even if I have nothing coming up on the screen? I've installed the MotoQ drivers and it does show up when I plug it into my PC, but nothing is ever on the screen, no SPL I think. I'll try it...
Click to expand...
Click to collapse
YOU CAN ONLY DO FRANKENKAISER IF YOU HAVE THE RIGHT RADIO INSTALLED. If the last radio you had was 1.65.17.10 or 1.64.08.21, you can scour the threads for the Frankenkaiser version for these. If not, pm jockyw2001 and he'll customize one for you just ask nicely
EDIT: and FYI IT CAN FIX BAD BLOCKS, if you're lucky enough. I had 3, two was fixed, 1 was left no matter how many task 2a I did.

pfcsabre said:
YOU CAN ONLY DO FRANKENKAISER IF YOU HAVE THE RIGHT RADIO INSTALLED. If not, pm jockyw2001
Click to expand...
Click to collapse
Well that's my problem, I can get through SOME of the steps, I can still connect in MTTY, but my radio WAS 1.27.12.11. I'm not sure if the task2a wiped it out. I'll try contacting Jockyw

pfcsabre said:
YOU CAN ONLY DO FRANKENKAISER IF YOU HAVE THE RIGHT RADIO INSTALLED. If not, pm jockyw2001
Click to expand...
Click to collapse
No disrespect, but are you sure? This thread make no mention of it.
Dave

DaveShaw said:
No disrespect, but are you sure? This thread make no mention of it.
Dave
Click to expand...
Click to collapse
I had been installing Frankenkaiser for the nth time, and been too dumb enough to make mistakes of putting the wrong version before doing task 2a-- so, yeah

You can format bad blocks in two minutes with a MFG based SPL & MTTY. No need for FrankenKaiser.

Well I posted a PM to jocky, hopefully he can help. I'm just stuck here now. Very stupid mistake. I will be in some severe trouble if I can't fix it.
EDIT: PROBLEM SOLVED! I'm reflashing to my Kaiser right now. Thanks everyone for your help! GSLEON, would you still be willing to help if I have bad blocks? I'll be checking for that shortly.

GSLEON3 said:
You can format bad blocks in two minutes with a MFG based SPL & MTTY. No need for FrankenKaiser.
Click to expand...
Click to collapse
OK GSLEON, I will not be impatient this time. Whenever you have time to help, or if you could just detail me some instructions in a PM or something that would work too. Thanks
Just for reference...as GSLEON said this did NOT fix my bad block. After doing task2a and FrankenKaiser'ing my device back to life the same bad block is still there.

HI
Since 4 days i cant wake up my kaiser. Its turn off it self when windows mobile screen appears
I have don 3 or 4 hard resent and nothing. I have connection with pc,and I've do the mem test with mtty.
Code:
1 BLOCK 0 (0x0) is reversed block
2 BLOCK 1 (0x1) is reversed block
3 BLOCK 2 (0x2) is reversed block
4 BLOCK 8 (0x8) is reversed block
5 BLOCK 9 (0x9) is reversed block
6 BLOCK 278 (0x116) is bad block
7 Partition[0], type=0x20, start=0x2, total=0x63E
8 Partition[1], type=0x23, start=0x640, total=0x700
9 Partition[2], type=0x25, start=0xD40, total=0x7D80
10 Partition[3], type=0x4, start=0x8AC0, total=0x12800
I have 1 bad block ;/ Can someone help me pls and tell me exacly what must I do?
Sorry for my poor english

solving hardspl hanging at 0% while flashing + video

I am really having a hard time flashing trying to flash hardspl on my Kaiser.
I have searched, followed guides (http://forum.xda-developers.com/showthread.php?t=433835) , watched videos (http://tiltmobility.com/how-to-flash-a-rom-video-new-version/) but I keep having troubles. I hope people can help me solve it and then this topic can be linked to from tutorials as a troubleshooting solution.
The problem: when flashing hardspl the actual flashing hangs at 0% in the white screen.
Here is what I have done:
- I have removed sim, sd card and battery (for 10 minutes)
- tried the all in one unlock app by olipro (the softspl version does not work)
- tried multiple softspl versions only 1.56 seems to get to the flashing (white screen)
- tried multiple hardspl installer versions
- have done a hard reset
- tried with and without phone password
- Tried another pc
About the phone:
- It is a kais130
- dutch orange branded wm6.0 (other/newer roms not available, reason for unlocking)
- sim unlocked with the original unlock code from the operator
About the pc:
- windows xp dutch
- sp3 with all updates
- activesync 4.5.0 build 5096
- syncing is not a problem
other posts by other people who had this problem either gave up or never posted a solution.
Here is a youtube movie with a demo of the problem, skip to about 3.30 to see the error, the rest is just showing what i did to get to the 0% error: http://www.youtube.com/watch?v=Nbik4E7vqqU
edit: at 4:45 it also shows the error the flash app shows on my pc screen.

2. Pull out the battery and reinsert it (this step IS important) *DONT turn phone back on yet*
9. Unplug the usb cable for 30 seconds and then Replug (phone will not re-sync but still says "USB" on the screen)
10. Right click on the Activesync icon in the bottom corner icon on the computer, goto connection settings, deselect "Allow USB connections" and click "ok"
I noticed that you either didnt do number 2 and did 9 & 10 backwards. redoing it this way.

zelendel said:
2. Pull out the battery and reinsert it (this step IS important) *DONT turn phone back on yet*
9. Unplug the usb cable for 30 seconds and then Replug (phone will not re-sync but still says "USB" on the screen)
10. Right click on the Activesync icon in the bottom corner icon on the computer, goto connection settings, deselect "Allow USB connections" and click "ok"
I noticed that you either didnt do number 2 and did 9 & 10 backwards. redoing it this way.
Click to expand...
Click to collapse
thank you for looking into this case.
as of #2 you can see the sim and sd card laying on the left they are already removed before turning the phone on. inserting the removed battery is the begin if the video (though looks awkward with one hand)
9 and 10 could be backwards on this try, some tutorials reverse this i think. i think the critical part here is it being disabled before you start the flashing. i will try once more and report back but i think that is not the problem.
EDIT:
tried it again this time doing 9 and 10 in the correct order but also on a different machine. just in case windows vista works better (always nice to use other peoples laptops for experimenting)
machine info:
- windows vista SP2 dutch with all updates
- mobile device centre 6.1
- starting hardspl with right-click > run as administrator
anything else i can try?

ok continuing to get more info from my device.
i am now using jumpspl + MTTY. using "info 8" i got this info
Code:
Cmd>info 8
--- 2K bytes sector version ---
DEVICE NAME=samsung_k9k2g08
DEVICE ID=0xAA
DEVICE MAKER ID=0xEC
PAGE SIZE=0x800
TOTAL PAGE SIZE=0x840
BLOCK COUNT=0x800
BLOCK PAGE=0x40
Checking block information
BLOCK 0 (0x0) is reversed block
BLOCK 1 (0x1) is reversed block
BLOCK 2 (0x2) is reversed block
BLOCK 8 (0x8) is reversed block
BLOCK 9 (0x9) is reversed block
BLOCK 10 (0xA) is reversed block
BLOCK 11 (0xB) is reversed block
BLOCK 16 (0x10) is reversed block
BLOCK 17 (0x11) is reversed block
BLOCK 18 (0x12) is reversed block
BLOCK 19 (0x13) is reversed block
BLOCK 623 (0x26F) is bad block
Partition[0], type=0x20, start=0x2, total=0x63E
Partition[1], type=0x23, start=0x640, total=0x700
Partition[2], type=0x25, start=0xD40, total=0x8B40
Partition[3], type=0x4, start=0x9880, total=0x11A40
CE Total Length(with sector info) = 0x4C8C400
CE CheckSum Length(without sector info) = 0x4C40000
Cmd>
now this "BLOCK 623 (0x26F) is bad block" seems .... bad ... is it? now what to do?
edit: everyone seems to have bad blocks, it is normal :S
other results from mtty:
- getdevinfo:
Code:
GetDevInfo: Get CID OK
HTCSKAIS1300OAG0HTCE
info2:
Code:
Card inserted
don't know what card is inserted but it ain't a sim or sd card, after this command mtty and/or my phone crashes

after more fiddling around in my phone i notice the amount of call time (incoming/outgoing calls) is still at the level it was before the hard reset. is this normal or did my hard reset go wrong?

fixed (sort of)
just a little message for future people with this problem (and used the search).
a friend of mine was planning on selling his tytnII and i was still having this ****ty problem, so we swapped phones.
the other one (dutch vodafone) had no troubles installing hardslp, it was a breeze.
unlocking was easy and i am now looking for rom's. so i hope nobody else aver has this problem, pm'ing me for a solution will not get you results

Same Problem
Today im trying to do the same thing with my kaiser... and i have the same problem... i did a lot of research, i guess im gonna give up

eltoze said:
Today im trying to do the same thing with my kaiser... and i have the same problem... i did a lot of research, i guess im gonna give up
Click to expand...
Click to collapse
Device's reserved kernel storage has bad block and thats why it causes your phone to stall at 0%.
Try installing android kernel, if you already have Hardspl v3.29 or higher. If it gets installed you can run OS from SD card

can someone help me? I flash my tytn without using the hard spl, and now caught in the smart mobility screen. what do I do?
Thanks ......

eMMC sudden death research

Update from Feb 17th:
Samsung has started to upgrade eMMC firmwares on the field - only for GT-I9100 for now.
See post #79 for additional details.
Update from Feb 13th:
If you want to dump the eMMC's RAM yourself, go ahead to post #72.
I'm looking for a dump of firmware revision 0xf7 if you've got one.
-----------------------
Since it's very likely that the recent eMMC firmware patch by Samsung is their patch for the "sudden death" issue, it would be very nice to understand what is really going on there.
According to a leaked moviNAND datasheet, it seems that MMC CMD62 is vendor-specific command that moviNAND implements.
If you issue CMD62(0xEFAC62EC), then CMD62(0xCCEE) - you can read a "Smart report". To exit this mode, issue CMD62(0xEFAC62EC), then CMD62(0xDECCEE).
So what are they doing in their patch?
1. Whenever an MMC is attached:a. If it is "VTU00M", revision 0xf1, they read a Smart report.
b. The DWORD at Smart[324:328] represents a date (little-endian); if it is not 0x20120413, they don't patch the firmware. (Maybe only chips from 2012/04/13 are buggy?)​2. If the chip is buggy, whenever an MMC is attached or the device is resumed:a. Issue CMD62(0xEFAC62EC) CMD62(0x10210000) to enter RAM write mode. Now you can write to RAM by issuing MMC_ERASE_GROUP_START(Address to write) MMC_ERASE_GROUP_END(Value to be written) MMC_ERASE(0).
b. *(0x40300) = 10 B5 03 4A 90 47 00 28 00 D1 FE E7 10 BD 00 00 73 9D 05 00
c. *(0x5C7EA) = E3 F7 89 FD
d. Exit RAM write mode by issuing CMD62(0xEFAC62EC) CMD62(0xDECCEE).​10 B5 looks like a common Thumb push (in ARM architecture). Disassembling the bytes that they write to 0x40300 yields the following code:
Code:
ROM:00040300 PUSH {R4,LR}
ROM:00040302 LDR R2, =0x59D73
ROM:00040304 BLX R2
ROM:00040306 CMP R0, #0
ROM:00040308 BNE locret_4030C
ROM:0004030A
ROM:0004030A loc_4030A ; CODE XREF: ROM:loc_4030Aj
ROM:0004030A B loc_4030A
ROM:0004030C ; ---------------------------------------------------------------------------
ROM:0004030C
ROM:0004030C locret_4030C ; CODE XREF: ROM:00040308j
ROM:0004030C POP {R4,PC}
ROM:0004030C ; ---------------------------------------------------------------------
Disassembling what they write to 0x5C7EA yields this:
Code:
ROM:0005C7EA BL 0x40300
Looks like it is indeed Thumb code.
If we could dump the eMMC RAM, we would understand what has been changed.
By inspecting some code, it seems that we know how to dump the eMMC RAM:
Look at the function mmc_set_wearlevel_page in line 206. It patches the RAM (using the method mentioned before), then it validates what it has written (in lines 255-290). Seems that the procedure to read the RAM is as following:
1. CMD62(0xEFAC62EC) CMD62(0x10210002) to enter RAM reading mode
2. MMC_ERASE_GROUP_START(Address to read) MMC_ERASE_GROUP_END(Length to read) MMC_ERASE(0)
3. MMC_READ_SINGLE_BLOCK to read the data
4. CMD62(0xEFAC62EC) CMD62(0xDECCEE) to exit RAM reading mode
I don't want to run this on my device, because I'm afraid - messing with the eMMC doesn't sound like a very good idea on my device (I don't have a spare one).
Does someone have a development device which he doesn't mind to risk, and want to dump the eMMC firmware from it?

Oranav said:
Since it's very likely that the recent eMMC firmware patch by Samsung is their patch for the "sudden death" issue, it would be very nice to understand what is really going on there.
According to a leaked moviNAND datasheet, it seems that MMC CMD62 is vendor-specific command that moviNAND implements.
If you issue CMD62(0xEFAC62EC), then CMD62(0xCCEE) - you can read a "Smart report". To exit this mode, issue CMD62(0xEFAC62EC), then CMD62(0xDECCEE).
So what are they doing in their patch?
1. Whenever an MMC is attached:a. If it is "VTU00M", revision 0xf1, they read a Smart report.
b. The DWORD at Smart[324:328] represents a date (little-endian); if it is not 0x20120413, they don't patch the firmware. (Maybe only chips from 2012/04/13 are buggy?)​2. If the chip is buggy, whenever an MMC is attached or the device is resumed:a. Issue CMD62(0xEFAC62EC) CMD62(0x10210000) to enter RAM write mode. Now you can write to RAM by issuing MMC_ERASE_GROUP_START(Address to write) MMC_ERASE_GROUP_END(Value to be written) MMC_ERASE(0).
b. *(0x40300) = 10 B5 03 4A 90 47 00 28 00 D1 FE E7 10 BD 00 00 73 9D 05 00
c. *(0x5C7EA) = E3 F7 89 FD
d. Exit RAM write mode by issuing CMD62(0xEFAC62EC) CMD62(0xDECCEE).​10 B5 looks like a common Thumb push (in ARM architecture). Disassembling the bytes that they write to 0x40300 yields the following code:
Code:
ROM:00040300 PUSH {R4,LR}
ROM:00040302 LDR R2, =0x59D73
ROM:00040304 BLX R2
ROM:00040306 CMP R0, #0
ROM:00040308 BNE locret_4030C
ROM:0004030A
ROM:0004030A loc_4030A ; CODE XREF: ROM:loc_4030Aj
ROM:0004030A B loc_4030A
ROM:0004030C ; ---------------------------------------------------------------------------
ROM:0004030C
ROM:0004030C locret_4030C ; CODE XREF: ROM:00040308j
ROM:0004030C POP {R4,PC}
ROM:0004030C ; ---------------------------------------------------------------------
Disassembling what they write to 0x5C7EA yields this:
Code:
ROM:0005C7EA BL 0x40300
Looks like it is indeed Thumb code.
If we could dump the eMMC RAM, we would understand what has been changed.
By inspecting some code, it seems that we know how to dump the eMMC RAM:
Look at the function mmc_set_wearlevel_page in line 206. It patches the RAM (using the method mentioned before), then it validates what it has written (in lines 255-290). Seems that the procedure to read the RAM is as following:
1. CMD62(0xEFAC62EC) CMD62(0x10210002) to enter RAM reading mode
2. MMC_ERASE_GROUP_START(Address to read) MMC_ERASE_GROUP_END(Length to read) MMC_ERASE(0)
3. MMC_READ_SINGLE_BLOCK to read the data
4. CMD62(0xEFAC62EC) CMD62(0xDECCEE) to exit RAM reading mode
I don't want to run this on my device, because I'm afraid - messing with the eMMC doesn't sound like a very good idea on my device (I don't have a spare one).
Does someone have a development device which he doesn't mind to risk, and want to dump the eMMC firmware from it?
Click to expand...
Click to collapse
:crying: --> **Ultimate GS3 sudden death thread** :crying:
Just wanted to link to a prior thread with some information/testing that as been done. Completely understand if you nuke it because it doesn't meet the proper criteria or is way to noobish to be posted here. Anyway, just though it _might_ help, so giving it a shot..

So I decided to do a small RAM dump after all.
Before the patch, 0x5C7EA reads FD F7 C2 FA, which is "BL 0x59D72".
As I thought, they replace a function call to the new one.
I will dump function 0x59D72 later this week.

Oranav said:
So I decided to do a small RAM dump after all.
Before the patch, 0x5C7EA reads FD F7 C2 FA, which is "BL 0x59D72".
As I thought, they replace a function call to the new one.
I will dump function 0x59D72 later this week.
Click to expand...
Click to collapse
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli

odewdney said:
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli
Click to expand...
Click to collapse
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.

odewdney said:
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli
Click to expand...
Click to collapse
Right, haven't spotted this. Thanks for the observation.
Self preservation sounds possible.
Rob2222 said:
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.
Click to expand...
Click to collapse
This could be possible - this patch looks like a quick and dirty fix, so maybe they didn't have the time to properly fix this. Instead, they just avoid the bug absolutely (with the cost of data corruption).
But I don't think this would cause lockups - I believe the chip has a watchdog...
All in all, I think the best thing we can do right now is to dump the whole firmware out of it. I will do it soon.

there is also a chance that this is just a temporary workaround to prevent further bricking - until there is a final fix.
As of now we asume that this is the fix as it directly adresses the eMMC in concern, but all this is just based on asumptions.

Rob2222 said:
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.
Click to expand...
Click to collapse
I think we can prove that the fix is actualy locking into loop ,but you must risk your phone :/ . If you are in ->
1) Flash back to older version without the fix
2) Wait and pray
a) If your phone dies --> the guys were right about the fix and the loop
b) If it stays alive ,then ...
We wont know for sure ,but your phone is maybe in the "perfect" condition for the test :/ .
(Sorry if this makes no sence)

@ivan:
Sorry, can't do that. Cause of high air humidity my humidity indicator is already a little soaked. Cause of the warranty-repair reports in out local forums I am not sure if I would get warranty. I think theres a fair chance, that they would deny my warranty. Cause of that I don't want to take any extra risk. I am on unrooted stock at the moment, cause of that.
@Oranav:
In our local forum we get some reports about a rising count of locks and restarts on S3's in the last time. Some like my freeze.
It also seems that after a while this problems gets better and even disappear completely.
Cause of that I am thinking, if it could be, that the fix maybe locks the eMMC if it finds a bad data structure, then this locks maybe could bring a phone-freeze (already stated that), and in the same time it repairs the data structure in this block with the bad data structure.
At least this would explain some rising count of freezes with the fix and the point, that the freezes become less and less over time.
I have no idea if it's that way, I just wanted to post it as theory to think about.
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
BR
Robert

Rob2222 said:
I have no idea if it's that way, I just wanted to post it as theory to think about.
Click to expand...
Click to collapse
The problem is that there are too many theories imaginable, but I can't think of no way to prove them but to reverse engineer the MoviNAND firmware.
Rob2222 said:
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
Click to expand...
Click to collapse
Certainly not. Watchdogs are slow, drivers running on a Cortex-A9 are blazing fast.
But I do think Linux's MMC driver can handle device restarts during an MMC operation.

Rob2222 said:
@ivan:
Sorry, can't do that. Cause of high air humidity my humidity indicator is already a little soaked. Cause of the warranty-repair reports in out local forums I am not sure if I would get warranty. I think theres a fair chance, that they would deny my warranty. Cause of that I don't want to take any extra risk. I am on unrooted stock at the moment, cause of that.
@Oranav:
In our local forum we get some reports about a rising count of locks and restarts on S3's in the last time. Some like my freeze.
It also seems that after a while this problems gets better and even disappear completely.
Cause of that I am thinking, if it could be, that the fix maybe locks the eMMC if it finds a bad data structure, then this locks maybe could bring a phone-freeze (already stated that), and in the same time it repairs the data structure in this block with the bad data structure.
At least this would explain some rising count of freezes with the fix and the point, that the freezes become less and less over time.
I have no idea if it's that way, I just wanted to post it as theory to think about.
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
BR
Robert
Click to expand...
Click to collapse
if those freezes are really caused by the firmware fix, I don't see how the would disappear over time...
I mean if it really is the case that the fix trades data corruption for eMMC survival, it would make sense to see freezes... but depending on what data is affected, they should only be treatable by reinstalling the affected app or deleting its data/cache.
updated theory:
for all we know the error condition where the eMMC dies is quite rare, since most devices have been used for month before they passed away. So under the assumption that the error condition appears randomly and that there is a chance of data corruption every time the condition appears with fixed kernel, we could expect to see freezes and other problems some time after the fix was applied. So that would explain the raising number of freezes reported. Furthermore I'd assume that people getting freezes would try to do something about it, like reinstalling/deleting apps wiping caches and/or data... or even reflashing, thus repairing the corrupted data. So freezes would disappear.
Wait, doesn't most evidence point to the fact that the error condition does NOT appear in a random fashion, since there were no cases in the beginning, and then a lot all of a sudden? Well, it might be that this is just the way we perceive the issue. Maybe there were cases before, but they weren't reported... phones died, people sent them in, got new ones and went on with their lives. But after some time the issue got known... bloggers wrote about it... and so on... people realized their phones died because of a wider problem... voila, steep raise in reported cases. Also the number of dying S3s would simply rise by a rising number of overall S3s, I mean Samsung kept selling phones, right?
But even under the assumption the bug is related to wear-levelling and not random, here is another idea: I have no clue how the algorithms work, but maybe it uses some sort of pseudo-random data to do whatever, with the same seed on all eMMCs... and thus all of them go through the same series of numbers. And now imagine the error condition is only triggered by a specific number or number set (say someone screwed up a boundary condition). Under this theory the error condition wouldn't appear randomly, but after a certain amount of write ops (or something).
Another question I asked myself is: shouldn't there be cases were data corruption does damage beyond all repair except for reflashing?
Well, it might be, but it seems reasonable to assume that it is a lot less likely than user-data corruption, since most critical files on the phone shouldn't be opened writeable (or are on a read-only mounted partition in the first place), hence shouldn't be affected by ****-ups during writes.
Like the previous poster I want to add that this is most likely all bull****... but it is what came to my mind looking for a theory that supports the data we got.

Okay, got a RAM dump
I won't post it here (or anywhere else for that matter) because I don't want to get sued by Samsung.
I might release a kernel which allows you to dump the RAM yourself if there's enough demand, but I don't want to right now, because:
1. The code is ugly as hell, not implemented as a kernel module, not thread-safe etc.
2. It is highly dangerous (messing with the eMMC chip - I really don't know how much stable this thing is), so if you want to do it on your device, you should be an expert. In that case, you can write the code yourself (with little effort)
Anyway, I hope the FTL is Whimory, since I'm familiar with it. Would be easier.
I'll let you know if I find anything interesting.
PS I've attached a little teaser. (Yes, this is the patched function. 0x40300 is red because I've opened a partial RAM dump.)
EDIT - Some initial results:
0. The CPU is a Cortex-M3.
1. No strings at all Just some uninteresting release asserts ("REL_ASSERT")
2. Found the Smart Report generator function -> found the MMC command handlers.
3. Most MMC commands handlers are stored in a function table. There are 3 special commands: MMC60, MMC62, MMC64. Depends on the arguments these special commands are provided, they modify the function table (this is the so called "vendor mode").
4. There are a lot of possible arguments for MMC62, not the only ones we know.
5. If you trace back the function they patch all the way up the call stack, you get to MMC24 and MMC25 handler. These commands are MMC_WRITE_BLOCK and MMC_WRITE_MULTIPLE_BLOCK. Since the function they patch is deep down the call stack, it's very likely that it is the wear level.
Anyway, because of the lack of strings I guess it would be very hard to truly understand the SDS bug we're facing

Odp: eMMC sudden death research
i cant say i have an idea whats going on inside emmc but usually in this case of mistakes/failures debug or diagnostics code is used for release.
maybe some debug info repeatedly written triggers wear levelling failure
so fix has to simply disable it

Awesome research.
So we're dealing with bug in exactly the same eMMC subsystem as in faulty SGS2 eMMC chips, but in device that was released after proving SGS2 eMMCs to be faulty.
Oranav, for some reason I cannot send you PMs. Could you send me your dump? Does your eMMC come from faulty serie?

Hi all, after reading this thread, I am now scared....
I have a Note 2 N7100 which is running ARHD V8.0 with Perseus Kernel V31.2 and TWRP recovery 3.2.2.3
The above all include the fix for SDS and Exynos hole.
I have been running the device for nearly 1 week I think. Last night I fully charged my phone, used it for 3 minutes surfing the forum (chrome) via wifi connection. After 3 minutes, I left the phone on the table for 3 hours. The only running app is Viber... when I tried to wake the phone up, it did wake up but it froze... no button worked, I tried for about 2 minutes... nothing worked except the power button which booted the device.
This is weird, never experienced this before... I am now scared the phone will die unexpectedly.

owl74 said:
Hi all, after reading this thread, I am now scared....
I have a Note 2 N7100 which is running ARHD V8.0 with Perseus Kernel V31.2 and TWRP recovery 3.2.2.3
The above all include the fix for SDS and Exynos hole.
I have been running the device for nearly 1 week I think. Last night I fully charged my phone, used it for 3 minutes surfing the forum (chrome) via wifi connection. After 3 minutes, I left the phone on the table for 3 hours. The only running app is Viber... when I tried to wake the phone up, it did wake up but it froze... no button worked, I tried for about 2 minutes... nothing worked except the power button which booted the device.
This is weird, never experienced this before... I am now scared the phone will die unexpectedly.
Click to expand...
Click to collapse
How long were you using the system before you had updated to the 'fix'? None the less, it does not necessarily mean that the phone is getting near to the SDS. I have had a few android phones which would sometimes reboot or hang for other reasons.

I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Rebellos, I enabled the private messaging system for me. I do have the faulty chip.
Sent from my GT-I9300 using xda app-developers app

Oranav said:
I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Click to expand...
Click to collapse
Damn Oranav, nice work!
So does it mean you get a total screen freeze? Every time?
BR
Robert

thealgorithm said:
How long were you using the system before you had updated to the 'fix'? None the less, it does not necessarily mean that the phone is getting near to the SDS. I have had a few android phones which would sometimes reboot or hang for other reasons.
Click to expand...
Click to collapse
About 2 weeks. Forgot to mention i reebooted the phone before I charged it. I will return this phone before it dies on me.... I think I will get an S3 but I will check if it has a new chip... otherwise I will return again and stick to my desire hd which is already running S3 rom....
---------- Post added at 02:24 PM ---------- Previous post was at 02:22 PM ----------
Oranav said:
I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Rebellos, I enabled the private messaging system for me. I do have the faulty chip.
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
So everyone's speculation is right about thw fix causing the freeze...

AW: eMMC sudden death research
Suppose this fix addresses wear leveling. If firmwares without this fix wear out the eMMC would then not the device still boot and then crash? As far as I know flash is still readable but not writable any more when worn out. Could it be that the wear leveling algorithm has a problem so that after some time it replaces cells from the bootloader and that causes the death?
In short: I want to know if it had a negative effect using the old firmware for some time because that old software caused extreme aging for the eMMC.