|
jimbo70
|
 |
« on: July 31, 2011, 07:00:58 PM » |
|
I have a jtag'd jasper BB & it was working great for a few months & then out of no where it got the e71 error, secondary error of 1013. Normally that's just a corrupt dash update but pretty sure that's not my problem. I turned the console on one day & it booted into FSD as usual, I left it for a couple hours while I ftp'd some content to the external hard drive. When I came back to it the screen was dimmed as it usually is but when I went to use controller to wake it up it was just frozen. I had to press the power button on the console to turn it off. Immediately after it went off it turned itself right back on again & went to e71 & haven't seen the dash on it again since.
So far I've tried:
-removed attached harddrive, external harddrive, memory card, kinect, swapped power supply, all=e71
-reflashing the freeboot image=e71,
-rebuilt & reflashed freeboot image=e71,
-erased nand & reflashed freeboot back on it=e71,
-flashed orig nand image back on console=e71,
-tried removing jtag wires for the heck of it while orig nand was on it=e71.
I can boot to xellous by pressing the dvd button, if pressing the power button on console or on controller it goes straight to e71, does not even attempt to load dash.
I'm pretty pissed/disappointed being I figured I'd get a couple good years out a jasper & this happens to it. I have a falcon I'm using as a back up for now which is working well so far but would love to bring my jasper back to life.
If anyone has anything else I can try please share as I'm out of ideas & this thing is driving me crazy.
|
|
|
|
|
Logged
|
|
|
|
|
peshkohacka
|
|
« Reply #1 on: July 31, 2011, 07:50:40 PM » |
|
Given that your tried reflashing. Maybe you have a bad cable that when flashing is corrupting your files or the NAND itself have bad blocks or problems. Try properly creating an image (CB/CG) and make sure your CPU key is correct or in the worst possible case - find a donor image.
But i guess you didn't even bother search do you?
|
|
|
|
|
Logged
|
|
|
|
|
l_oliveira
|
|
« Reply #2 on: July 31, 2011, 09:53:02 PM » |
|
1013 (RoL lights)
=
01 00 01 11 (binary)
=
71 (decimal)
Nuff said.
|
|
|
|
|
Logged
|
 It's a Rough World |
|
|
|
jimbo70
|
|
« Reply #3 on: July 31, 2011, 10:12:38 PM » |
|
Given that your tried reflashing. Maybe you have a bad cable that when flashing is corrupting your files or the NAND itself have bad blocks or problems. Try properly creating an image (CB/CG) and make sure your CPU key is correct or in the worst possible case - find a donor image.
But i guess you didn't even bother search do you?
-Well given I've reflashed it with both my usb flasher & via xellous I think that may rule out the bad cable. -Also being I had it working fine for months I'm pretty sure my CPU key is correct. As far as your brilliant idea of searching...the only thing that I found via searching that I didn't already try was that some people had to reflow parts of their board to fix it. As ridiculous as that sounds being it's an e71 error & what I've already tried, it's starting to sound possible. But in your expertise I ask a question, my original nand didn't show any bad blocks, but if the nand has gotten 1 or 2 over time how can I see it's current condition? Xellous 'should' remap them while flashing that way if I recall correctly? |
|
|
|
« Last Edit: July 31, 2011, 10:15:44 PM by jimbo70 »
|
Logged
|
|
|
|
|
jimbo70
|
|
« Reply #4 on: July 31, 2011, 10:20:42 PM » |
|
1013 (RoL lights)
=
01 00 01 11 (binary)
=
71 (decimal)
Nuff said.
l_oliveira, from what I've seen of your postings on this board over time you seem to know your stuff & I know my skills are no where near what yours are, but you've kind of lost me on your post. Are you saying it has to be software related & that's it? I know 99.9% of e71 errors are software but the way this one went out & the fact that I've tried all the above steps is making me start to doubt that. |
|
|
|
|
Logged
|
|
|
|
|
cory1492
|
|
« Reply #5 on: July 31, 2011, 10:36:59 PM » |
|
All l_oliveira was saying is the ROL output matches the Exx screen output if you do the conversion. 0 = binary 00, 1= binary 01, 2 = binary 10, 3 = binary 11; so 1013 = binary 01 00 01 11, which when put in calc and converted to decimal from binary is 71. how can I see it's current condition?
Use an external flasher, flash an image to the machine. Immediately dump it after it's flashed. See if what you wrote matches 1:1 what you dumped. E71 occurs when dash.xex cannot load, which means it's still starting the second kernel, and still able to start the second kernel's xam... it just can't load dash.xex. E71 will also occur if you used an older than current fbbuild to include launch/lhelper xex, there was issues with the ini parse that caused only launch and not lhelper to be put into the image. |
|
|
|
|
Logged
|
|
|
|
|
jimbo70
|
|
« Reply #6 on: August 01, 2011, 05:15:19 PM » |
|
how can I see it's current condition?
Use an external flasher, flash an image to the machine. Immediately dump it after it's flashed. See if what you wrote matches 1:1 what you dumped. Can/should I use my original 512mb image for this or can I just use a 66mb freeboot image I have? So you're saying I can just use my usb spi flasher correct? And should I just flash the image & without even power cycling the 360 just read the whole image again then compare? Thanks for the input cory. |
|
|
|
|
Logged
|
|
|
|
|
cory1492
|
|
« Reply #7 on: August 01, 2011, 05:39:15 PM » |
|
Yep, just the system part is all you need to worry about. If you turn it on after flashing you lose the point of the test... the xbox modifies flash on nearly every boot. If you write it and get no errors, then dump it and get no errors... then compare the two and have differences, then remap the block where the differences are (and zerofill the old location, I'm betting there will be at least one difference in a block that dash.xex occupies) and see if that helps.
Also, you could try and just dump whatever you currently have and provide it to fbbuild 0.32 as nanddump.bin, and give the ini option to remap on ecc errors. If there is anything off it should remap it and not retain the error.
|
|
|
|
« Last Edit: August 01, 2011, 05:43:49 PM by cory1492 »
|
Logged
|
|
|
|
|
peshkohacka
|
|
« Reply #8 on: August 01, 2011, 07:55:54 PM » |
|
Given that your tried reflashing. Maybe you have a bad cable that when flashing is corrupting your files or the NAND itself have bad blocks or problems. Try properly creating an image (CB/CG) and make sure your CPU key is correct or in the worst possible case - find a donor image.
But i guess you didn't even bother search do you?
-Well given I've reflashed it with both my usb flasher & via xellous I think that may rule out the bad cable. -Also being I had it working fine for months I'm pretty sure my CPU key is correct. As far as your brilliant idea of searching...the only thing that I found via searching that I didn't already try was that some people had to reflow parts of their board to fix it. As ridiculous as that sounds being it's an e71 error & what I've already tried, it's starting to sound possible. But in your expertise I ask a question, my original nand didn't show any bad blocks, but if the nand has gotten 1 or 2 over time how can I see it's current condition? Xellous 'should' remap them while flashing that way if I recall correctly? Really, you have a problem and being arrogant to people that try and help you? Have fun fixing it. |
|
|
|
|
Logged
|
|
|
|
|
jimbo70
|
|
« Reply #9 on: August 01, 2011, 10:17:10 PM » |
|
Given that your tried reflashing. Maybe you have a bad cable that when flashing is corrupting your files or the NAND itself have bad blocks or problems. Try properly creating an image (CB/CG) and make sure your CPU key is correct or in the worst possible case - find a donor image.
But i guess you didn't even bother search do you?
-Well given I've reflashed it with both my usb flasher & via xellous I think that may rule out the bad cable. -Also being I had it working fine for months I'm pretty sure my CPU key is correct. As far as your brilliant idea of searching...the only thing that I found via searching that I didn't already try was that some people had to reflow parts of their board to fix it. As ridiculous as that sounds being it's an e71 error & what I've already tried, it's starting to sound possible. But in your expertise I ask a question, my original nand didn't show any bad blocks, but if the nand has gotten 1 or 2 over time how can I see it's current condition? Xellous 'should' remap them while flashing that way if I recall correctly? Really, you have a problem and being arrogant to people that try and help you? Have fun fixing it. Sorry about the arrogance it's just that some of the stuff you had suggested was ruled out in my original post. I'm open to all ideas here as I feel I've tried nearly everything with this console. I'm closer to a newb than a pro and realize that an e71 should be easy to fix but this one's not being so easy. And I have searched this forum as well as the internet with nothing that's worked past xell or xellous yet. |
|
|
|
|
Logged
|
|
|
|
|
boflc
|
|
« Reply #10 on: August 02, 2011, 12:23:33 PM » |
|
when you say you erased the nand, did you erase the whole thing, or just the system area?
it doesn't seem as as through you've yet done what cory recommended (the w/r/compare), so i'd underline that you really do need to try it. i'd add a fresh erase, too.
|
|
|
|
|
Logged
|
|
|
|
|
peshkohacka
|
|
« Reply #11 on: August 02, 2011, 04:35:08 PM » |
|
E71 is NAND related, maybe you've done too much write/erase and the nand itself is failing, or something is shorting one of the legs, or for some reason the data between the NAND is corrupted. Easiest way is to do a complete erase with NandPro, and try and recreate a new image only with your CPU key and generic files (fcrt,secdata,extended etc.) if that fails, you might consider replacing your nand.
Im not saying thats the reason, but if everything else fails the simplest conclusion usually is the right one.
|
|
|
|
|
Logged
|
|
|
|
|
jimbo70
|
|
« Reply #12 on: August 02, 2011, 04:42:43 PM » |
|
when you say you erased the nand, did you erase the whole thing, or just the system area?
it doesn't seem as as through you've yet done what cory recommended (the w/r/compare), so i'd underline that you really do need to try it. i'd add a fresh erase, too.
I did the nandpro usb: -e512 command a few weeks ago early on in my quest. I wrote a 64mb image to the console last night, then read it immediately afterwards (without power cycling the xbox or anything) and used "nandcompare" to compare what I wrote to it & what I read from it & it reported back: 4096 blocks in image(s), 0 non-matching blocks. Is there a different program I should use for checking the differences? I think the commands I used to write & read were: nandpro usb: -w64 freeboot.bin nandpro usb: -r64 nand1.bin I was really hoping to see at least 1 mismatch in there  Would it make any difference if I did the write & read immediately after doing the erase or would it still hold good being I did a few weeks ago? I only do this as a hobbyist for my own stuff (and sold one of these jtags a while ago), as I said before I don't claim to be a pro at all but I can usually follow directions pretty well. I've done 2 xenons, 1 falcon & 1 jasper with them all being successfully jtaged. I just rewired the falcon for the aud_clamp after getting e79's (which is working fine now) and this jasper is the only real issue I haven't been able to fix yet and of course this is the one I really expected to have the fewest problems with & keep running for a few years. |
|
|
|
|
Logged
|
|
|
|
|
jimbo70
|
|
« Reply #13 on: August 02, 2011, 04:46:54 PM » |
|
if that fails, you might consider replacing your nand.
This is one thing I'd seen mentioned in a couple other posts. I think the soldering involved in this might be a little beyond me, although I'd love to get it converted to a 16mb nand. Does anyone around here do this kind of thing for a reasonable price? I'll try scraping an image together as you mentioned after erasing again but the way this thing is acting I don't have high hopes for it. |
|
|
|
|
Logged
|
|
|
|
|
cory1492
|
|
« Reply #14 on: August 03, 2011, 12:40:44 AM » |
|
Use any method of binary compare to see 1:1; I'm trying to get you to diagnose the NAND/controller rather than whatever rab's tool happens to check. Use some secure hash algo like SHA or MD5, or actual binary compare with something like windows command line 'fc'
The SPI reads the same thing as the rest of the xbox, which is basically whatever the flash controller sees (if you are using a cygnos that access the chip directly then this sort of test may be useless) - so if your redump is 1:1 matching what you flashed it is highly unlikely the NAND itself is the culprit.
|
|
|
|
|
Logged
|
|
|
|
|
jimbo70
|
|
« Reply #15 on: August 03, 2011, 08:56:08 PM » |
|
Use any method of binary compare to see 1:1; I'm trying to get you to diagnose the NAND/controller rather than whatever rab's tool happens to check. Use some secure hash algo like SHA or MD5, or actual binary compare with something like windows command line 'fc'
Sorry about that. I think this is what you were talking about, if so it looks 1:1 to me. I wrote the updflash.bin & read back the flash.bin BTW, no I'm not using a cygnos chip.  |
|
|
|
« Last Edit: August 03, 2011, 08:59:53 PM by jimbo70 »
|
Logged
|
|
|
|
|
cory1492
|
|
« Reply #16 on: August 04, 2011, 01:24:33 AM » |
|
OK, so it seems the flash controller and the NAND are doing what they are supposed to. Can you extract dash.xex from that image and verify it is identical to the one the image is built with? That is a bit iffy as occasionally flash tool messes up and zerofills a chunk of some of the flash files, but if you do a raw extract of the file system it should match the files you built it with (aside from security files and ones like sysupdate.xexp.)
Unfortunately, considering how it initially failed, I'm beginning to suspect the memory is the fault... something that causes dash to corrupt so it can't decrypt and load, but that doesn't directly affect other areas of memory. You might be right that a reflow would be the fix, provided the image itself isn't corrupt in some way.
|
|
|
|
« Last Edit: August 04, 2011, 01:26:52 AM by cory1492 »
|
Logged
|
|
|
|
|
l_oliveira
|
|
« Reply #17 on: August 04, 2011, 07:37:49 AM » |
|
If you happen to have the original MS NAND for that unit, flash it an see if it operates properly. If it does, you can probably rule out RAM problems... Not ?
|
|
|
|
|
Logged
|
It's a Rough World |
|
|
|
boflc
|
|
« Reply #18 on: August 04, 2011, 09:49:44 AM » |
|
If you happen to have the original MS NAND for that unit, flash it an see if it operates properly. If it does, you can probably rule out RAM problems... Not ?
-flashed orig nand image back on console=e71,
-tried removing jtag wires for the heck of it while orig nand was on it=e71.
|
|
|
|
|
Logged
|
|
|
|
|
utar
|
|
« Reply #19 on: August 04, 2011, 10:33:22 AM » |
|
Does anyone know if the old Gentoo LiveCD from the original KK hack days has memtest as one of the boot options? I'm not in front of my box at the moment so I can't check.
If it does, given that Xell boots, I would suggest running that to see if it identifies any memory problems.
|
|
|
|
|
Logged
|
|
|
|
|
Dilber MC Theme by HarzeM