Problematic Zephyr Glitch

docentore

Hi there,

I have this strange Zephyr with 4578 CB. I have the CoolRunner installed, ecc image flashed - boots to Xell almost instantly, got CPU key, prepared GG image - not booting to dashboard at all. Just won't glitch, but when I turn this on with eject - Xell in less than 3 seconds.

I tried Multibuilter, J-runner etc, no joy. I know that Zephyrs are the pain in the ar$e but I thought they if I can boot it to Xell it's all good, apparently not. Any thoughts?

TouchingVirus

Sounds like the old GPU issue from the JTAGs - something isn't engaging the GPU properly. Xell's 100% CPU based, so there's more than one case where it works fine, but actual dash booting doesn't.

docentore

TouchingVirus wrote: »

Sounds like the old GPU issue from the JTAGs - something isn't engaging the GPU properly. Xell's 100% CPU based, so there's more than one case where it works fine, but actual dash booting doesn't.

Sounds about right as it is rrod reflowed one, but original dash used to work ok.

TouchingVirus

docentore wrote: »

Sounds about right as it is rrod reflowed one, but original dash used to work ok.

Yeah, that's the typical use case all right. It's something like the IO on the GPU being busted, so the things that are needed to drive logic to force glitching over the GPU don't work. I've had two of those I had to abandon after 5 or 6 hours trying to get them to work Pretty sure the only way forward is a GPU transplant, which is probably not worth the effort any more

docentore

ah well, I'll give it another go during the week and if it won't glitch I'll leave it for parts.

wotzgoingon

Hey I know what is wrong. I had this problem before with a Jasper. Took me a while to figure it out. I had the exact symptoms you have, always booted xell but never hacked dashboard. First you boot into Xell and then count the number of "f" on the fusecount 07 line. And then enter that value manually in settings of which ever builder you are using under cfldv.

docentore

wotzgoingon wrote: »

Hey I know what is wrong. I had this problem before with a Jasper. Took me a while to figure it out. I had the exact symptoms you have, always booted xell but never hacked dashboard. First you boot into Xell and then count the number of "f" on the fusecount 07 line. And then enter that value manually in settings of which ever builder you are using under cfldv.

Wow, thanks. I'll try that tomorrow.

Myrddin

Sounds like a problem I had building a jtag file before - http://www.boards.ie/vbulletin/showpost.php?p=75915799&postcount=188

docentore

I've checked my original nand image with 360 flash tool, highest value is 50. All builder will allow me to use max 32. Back to the drawing board

wotzgoingon

docentore wrote: »

I've checked my original nand image with 360 flash tool, highest value is 50. All builder will allow me to use max 32. Back to the drawing board

That doesn't sound right. Count the "f" in Xell like I said.

Jimbobjoeyman

wotzgoingon wrote: »

docentore wrote: »

I've checked my original nand image with 360 flash tool, highest value is 50. All builder will allow me to use max 32. Back to the drawing board

That doesn't sound right. Count the "f" in Xell like I said.

Zephyrs in general can be just a pain at times.
I had one exactly the same not so long ago, bridging the point for the cap between GND and CPU-PLL-BYPASS got it to boot to the hacked dash.

It still didn't boot in an acceptable time but at least it booted to dash ,
Could be worth a try if you haven't already.

docentore

wotzgoingon wrote: »

That doesn't sound right. Count the "f" in Xell like I said.

I know, I want to count the f's in 7th and 8th lines, but this is leftover from few consoles I was working over the weekend and it is missing coolrunner chip atm.
Tomorrow I will install it again and give it another go. This might be it, as all builders would build the gg image with ldv=32 which seems be to large as well. there has to be some kind of corruption there.

@jimbo: I tried the cap as well, no difference. But even tirhout the cap it glitches almost instantly and boots to xell.

I will keep yous updated.

PS. I fried one falcon over the weekend as well - just to warn yous. I shut it down using FSD web interface and left it, but what happened there was ,the fans stopped working, but not the console. Cpu heatsink was hot as hell when I noticed it.

TouchingVirus

Jaysus, had it a modified SMC? The thermal cut off for the CPU should be around 90C with the default SMC, the console should "click" and then two light RROD after, killing power to the CPU/GPU

docentore

TouchingVirus wrote: »

Jaysus, had it a modified SMC? The thermal cut off for the CPU should be around 90C with the default SMC, the console should "click" and then two light RROD after, killing power to the CPU/GPU

I know, strange one isn't it? I suppose it is some kind of bug in FSD or thermal sensor got damaged during reflow.

J2G

docentore wrote: »

I know, strange one isn't it? I suppose it is some kind of bug in FSD or thermal sensor got damaged during reflow.

There is no bug like that in FSD ! bugs like that if any would be filtered out before, even if you took the beta updates there is another side to beta before the public one.
So somewhere along your repair on the falcon you scrapped or cut the temp trace, id doubt a reflow did it unless your a heatgun nut job that much heat to burn a trace would also kill the CPU.. or GPU
As it goes for your Zephyr if your using your original nanddump and building it with J-R then your ldv will be right no need to set sh** ! if its booting a normal dash then it will boot and image build. so if your soldering is a 100% you need to play a lot with your RST even trying different lengths 30awg can be good on a bitch Zephyr also for the record Zephyr is still very much the centre of testing as it is a troublesome bitch...;)

wotzgoingon

J2G wrote: »

As it goes for your Zephyr if your using your original nanddump and building it with J-R then your ldv will be right no need to set sh** !

I'm sorry but your totally wrong. It does not happen often, but it does happen, where you have to manually find the ldv yourself. Trust me as soon as docentore finds the fuseset value in Xell and manually enters then while building image. Once flashed he will boot hacked dashboard.

J2G

im wrong im testing this sh** everyday.... im in testing with J-Runner Dev maybe using other tools such as 360 Multi Builder i guess you would have to be adding ldv it is known, but if the original image, is the current image, ldv wont be a problem.
Maybe he should repeat whole process from start to finish using J-Runner its not hard to find on Team Xecuter .. and in the process he will have his KV_Info.txt along with Fuses.txt / cpukey.txt and much more packed into one folder when he is done flashing his nand.

docentore

J2G wrote: »

There is no bug like that in FSD ! bugs like that if any would be filtered out before, even if you took the beta updates there is another side to beta before the public one.
So somewhere along your repair on the falcon you scrapped or cut the temp trace, id doubt a reflow did it unless your a heatgun nut job that much heat to burn a trace would also kill the CPU.. or GPU
As it goes for your Zephyr if your using your original nanddump and building it with J-R then your ldv will be right no need to set sh** ! if its booting a normal dash then it will boot and image build. so if your soldering is a 100% you need to play a lot with your RST even trying different lengths 30awg can be good on a bitch Zephyr also for the record Zephyr is still very much the centre of testing as it is a troublesome bitch...;)

Thanks for the input but I need to explain few things:
1. Re: bugs, I'm not saying it has to be a bug, but as IT professional I can assure you many bugs go through alpha, beta, rc stages, this happens every day to commercial software. Why it couldn't happen to freeware coded and tested by volunteers?
2. Rapair was done on pro equipment with proper pre-heater, ir station etc, no heatguns involved, no traces scrapped. Believe me, I know what I'm saying.
3. This is what I'm saying, that the original nand might be corrupted, as flash tool shows incorrect ldv value.
4. J-runner uses the same Xebuild as all other builders, if xebuild decrypts the nand image with cpu key provided, all builders will get wrong ldv value. wotzgoion is right, I did some reading after his first post in this thread and it does happens a lot.
5. Soldering is 101%, if it was wrong it wouldn't glitch at all, right? As mentioned before it boots to Xell fine, meaning it glitches properly

Ok, off to fixing this Zephyr!

EDIT: lines 7, 8 are filled fully with f's, which gives total amount of 32. That what xebuild was showing. I just flashed original nanddump and it boots to ms dash no probs.

docentore

Ok, some update:
Supposedly ldv value can be as high as 80. All fuse lines between 7 and 11 represent ldv value. It is very unlikely for any one to update the xbox 80 times but ldv can show this. Mine shows 50 for some reason (all fuses in lines 7,8 and 9 are burned + 2 in line 10 = 3 * 16 + 2 50).
Maximum ldv value allowed by XeBuild is 32, doesn't matter if it will read it from nand or user will set it manually in ini file. Unless I will find a way to change this zephyr won't boot to hacked dash.

Because of this I had a look at Falcon. Good that I did. STBY_CLK wire got loose, probably when I was pulling out power in panic when finding out that xbox is overheating. I resoldered it and it boots fine! So happy days, Zephyr is dead, long live the Falcon!

docentore

So after 3 and a half months I decided to have another go. Firstly I prepared 6 different nand images created using different apps and named them try1.bin, try2.bin (this is where I did small mistake) and flashed them one by one.

At bin no 3 console glitched to dashboard!. Zephyr glitching in less than 10 seconds!

But I forgot what settings and app I used to create working image. Is there any way of checking this in case I want to update the rgh image?

Thanks.

(back to soldering sata cable, few fans etc)

EDIT: and its dead again, this time CR green light won't come on, faulty CR?

Myrddin

docentore wrote: »

EDIT: and its dead again, this time CR green light won't come on, faulty CR?

Its a Zephyr, they're made broken

TouchingVirus

docentore wrote: »

EDIT: and its dead again, this time CR green light won't come on, faulty CR?

The CR's green light only comes on when trying to glitch. It not coming on usually points to a dodgy wire but I have had a dead board before. Make sure it's not magically set the switch back to PRG

docentore

TouchingVirus wrote: »

The CR's green light only comes on when trying to glitch. It not coming on usually points to a dodgy wire but I have had a dead board before. Make sure it's not magically set the switch back to PRG

I redid all soldering with new cables, reprogrammed cr - no dice.
I'm going to order new board to see if this one died.

TouchingVirus

docentore wrote: »

I redid all soldering with new cables, reprogrammed cr - no dice.
I'm going to order new board to see if this one died.

I have one, if you're interested.

docentore

TouchingVirus wrote: »

I have one, if you're interested.

Pm'd