fbBuild 0.11 - New freeboot and new Dashlaunch 2.06

[artik]

keropi, I have EXACTLY smae issue here tried all what I know, E71 .... One of my firend told me to use http://www.logic-sunrise.com/telechargement-168979-easy-freeboot-12611-update.html but can't test it now. Any other suggestions are welcome. Can give my .bin + CPU for anyone who want to help us.

[gab76]

WTH am I doing wrong  I still get E71 on boot , after the logo animation....

I have a jasper16a 360 , and a fully working Freeboot 9199 image. (if I flash back the 9199 image all work perfect)

So what I did is this:

1. used 360 flash tool and grabbed from the 9199 image: smc_dec.bin , smc_config.bin , kv_dec.bin , rename to smc.bin/kv.bin and put in /mydata/
2. edit both txt's with my cpu key and 1BL key
3. put the 126111 files in /data/ , to double check the sfv verification completes, all files are present and correct
4. I run: " fbbuild -c jasper -d mydata updflash.bin"
5. image created OK, booting into xellous and writting fine (there is a badblock in 0x90)
6. power cycle
7. E71 !!! 

I have tried remapping 0x90 to 3FF , makes no difference. If I write again the 9199 image the machine works perfect... what am I doing wrong???!

I know many people in your situation.
E71 with one or more badblocks, after remap manually, xellous, flash360, xbrflash, E71 or freeze in startup screen 

[keropi]

@cory1492:

I gave it a shot , took the updflash.bin that I build, read block90 , write null to 0x90 and write block90 to 3FF ... flashed via xellous , same E71 error...
this is not the problem, since flashing the 9199 image works perfect without any remapping or null blocks...
I don't know what else to try to be honest... 

sometimes ive noticed when flashtool lists NO bad blocks but xell or flash360 does its just a software marked bad block .. in essence it see's it and wants to remap it for you but the solution is to NOT let it remap it..    flash xell back to the system then xellous..   burn your updflash.bin to a cdr and flash it over that way thru the dvd drive   ive had this issue in the past with FB032 and a few falcons/jaspers that didnt want the bad block remapped..  it seemed to work and fix the e71 issues i was plauged by on a xenon as well..

I have done that too, burned a 12611 image on CDRW that has a manually remapped 0x90->3FF . Xellous flashed it and same E71 ...

@artik:
I have tried that too my friend, makes no difference for me... does your nand have any bad blocks too?

@gab76: sad news... 

[artik]

Yes, I have 1 bad block ..... On both 360 ! unlucky I'm ....

[keropi]

I am sure a dev will fix this ... I do hope so! 

[cory1492]

I am sure a dev will fix this ... I do hope so!  

Perhaps a dev has already been trying to diagnose the problem for you? (link) Not like I don't know anything about NAND and how 360 is using it...

That said, 3 things are still left unconfirmed...
- are you sure smc_config is good and from that machine? Open the built image that gives you E71 in flash tool and check the smc config under file menu, if it comes up it should be good.
- have you tried remap without using one of the automated flashers doing any of the flashing? (ie: write whole image via nandpro/SPI, with 0x0 filled data in the bad block)
- are you pulling the power cord out after flashing each time? Turning it off is NOT enough when LBA are moved (ie: from xell image to freeboot image.

It has nothing to do with luck, it has everything to do with it being unable to load dash.xex. TBH it sounds like you've been trying the same things over and over again, and one definition of insanity is "trying the same thing but expecting different results."

One other off the wall thing to try, is to build an image with compatible dash launch launch.xex and lhelper.xex in the /data dir, then provide an ini with a default item set to something that exists on your machine... if it boots you're homebrew it will give you the opportunity to use something like xexmenu to FTP into flash and see if the flash file contents still matches what you built the image with (personally I'm betting dash.xex will have data from the original 0x90 block location in it instead of the proper remap data.)

[tataniko]

Without proper flashconfig(00023010) we can't remap badblocks and flash well.
Hope fix.
Thanks

[sandoqanu]

@techisgood148

if you read in my post the 2-nd command was fbBuild.exe -c MOTHERBOARD -d data -b 1BL KEY -p CPU_KEY updflash.bin, so fbbuild will look into data folder instead of my data folder

[Harbinger076]

@cory1492:

I gave it a shot , took the updflash.bin that I build, read block90 , write null to 0x90 and write block90 to 3FF ... flashed via xellous , same E71 error...
this is not the problem, since flashing the 9199 image works perfect without any remapping or null blocks...
I don't know what else to try to be honest... 

sometimes ive noticed when flashtool lists NO bad blocks but xell or flash360 does its just a software marked bad block .. in essence it see's it and wants to remap it for you but the solution is to NOT let it remap it..    flash xell back to the system then xellous..   burn your updflash.bin to a cdr and flash it over that way thru the dvd drive   ive had this issue in the past with FB032 and a few falcons/jaspers that didnt want the bad block remapped..  it seemed to work and fix the e71 issues i was plauged by on a xenon as well..

I have done that too, burned a 12611 image on CDRW that has a manually remapped 0x90->3FF . Xellous flashed it and same E71 ...

@artik:
I have tried that too my friend, makes no difference for me... does your nand have any bad blocks too?

@gab76: sad news... 

no do not remap it at all put on cd and let iti flash

[Razkar]

Did you try to extract the KV and config from your actual nand and reinject them in a origin nand from another console
The two nand must have the same Kernel (probably 7371) otherwise it won't work
I do that for a 512nand it works perfectly

[keropi]

Perhaps a dev has already been trying to diagnose the problem for you? (link) Not like I don't know anything about NAND and how 360 is using it...

it goes without saying that I am grateful for your time spent (and anyone else's for that matter!!!)  
I fear though that this is something wrong with fbbuild...

That said, 3 things are still left unconfirmed...
- are you sure smc_config is good and from that machine? Open the built image that gives you E71 in flash tool and check the smc config under file menu, if it comes up it should be good.

I am using the freeboot9199 image that works for many months on this specific 360. it is as old as freeboot0.032 itself and rock solid. I cannot see any reason why it does not work.

- have you tried remap without using one of the automated flashers doing any of the flashing? (ie: write whole image via nandpro/SPI, with 0x0 filled data in the bad block)

yes I have tried that , with manually remapping 0x90 and letting xellous/flash360/xbr flash take care of that. I have even tried writing only 0x90 with nandpro to 3FF after flashing is done. Erasing 0x90 just gave a 202 error. Also tried having 0x90 to 3FE and 3FD without success. Writing to 0x90 even your null block is an eror202.

- are you pulling the power cord out after flashing each time? Turning it off is NOT enough when LBA are moved (ie: from xell image to freeboot image.

yes I am doing a complete power cycle, 360 gets disconnected from the plug.

It has nothing to do with luck, it has everything to do with it being unable to load dash.xex. TBH it sounds like you've been trying the same things over and over again, and one definition of insanity is "trying the same thing but expecting different results."

yeah basically all I am doing is the same thing but with different software and relocation methods..   what else is there expect trying to get it work?  

One other off the wall thing to try, is to build an image with compatible dash launch launch.xex and lhelper.xex in the /data dir, then provide an ini with a default item set to something that exists on your machine... if it boots you're homebrew it will give you the opportunity to use something like xexmenu to FTP into flash and see if the flash file contents still matches what you built the image with (personally I'm betting dash.xex will have data from the original 0x90 block location in it instead of the proper remap data.)

so basically you are saying to install dashlaunch patch? I don't really get how to do what you describe... ie make the machine boot with the 12611 image but load another dashlaunch.xex

if you think it can help you, I can gratefully send you my working 9199.image and keys etc for my console, along with the image I have built so you can check it yourself....

@Harbinger076
I will try that, why not... it is only a 1min procedure... but I fear it will not work at all, since that specific method expects to find manually relocated bad blocks

@Razkar: I have tried that with the 12161 image that works on my 2nd jasper16a ... did not help

[techisgood148]

@techisgood148

if you read in my post the 2-nd command was fbBuild.exe -c MOTHERBOARD -d data -b 1BL KEY -p CPU_KEY updflash.bin, so fbbuild will look into data folder instead of my data folder

@sandoqanu:
Oh, now I see, that does work too -
I found it useful keeping them separated, it didn't even occur to me to point it to the same (data) folder! - I figured since I need to do this process for more than one xbox, it's easier to switch to different "per console" files if everything is not mixed together - since fbBuild already uses the "data" folder for 12611 f/s files, I leave that alone and just point to the folder corresponding to "whichever console's" separate folder for the rest... sorry if I made "something out of nothing" 

P.S. Doing it 'your way' does have its benefits too - it's just the one folder to deal with, no worries about what goes where...

[l_oliveira]

lol flashing a donor dump to a console with replaced to original kv and config will yield nothing useful.


Also, leave the security files out for less hassle. It will work fine if you provide only smc.bin, kv.bin and smc_config.bin.   In that case, the security files will be generated from scratch.
Anyway, it's DUMB to use the rebooter online as it makes up odd/obviously manipulated pairing data. 
Since it's not going to be used online, there's no point on bothering with the security files.


Let the cheating fools be caught in less than 30 minutes now.

[ddxcb]

lol flashing a donor dump to a console with replaced to original kv and config will yield nothing useful.


Also, leave the security files out for less hassle. It will work fine if you provide only smc.bin, kv.bin and smc_config.bin.   In that case, the security files will be generated from scratch.
Anyway, it's DUMB to use the rebooter online as it makes up odd/obviously manipulated pairing data. 
Since it's not going to be used online, there's no point on bothering with the security files.


Let the cheating fools be caught in less than 30 minutes now.

this, I didnt bother putting the secdata.bin and other files on my flash, as there is no point.

[tataniko]

Anybody cant wait, here is a solution:

1. Goto xellous, flash clear image(no bad sector remap in image)
2. After succesfully flashed, power down.
3. Wait, power on
4. Go Xellous back
5. Dump flash over http.
6. Compare clear image and dumpflash.
7. We can see, the real bad sectors, and the corrupted one.
8. With hex editor remap bad sectors in clear image step by step from end.
9. Burn cd, and flash xellous.

[Harbinger076]

@keropi

There have been a number of situations that i've encountered where i either manually or have xell remap bad blocks and the update will e71 (pre 12611 dash) upon powering up.. this did my head in for hours and days even weeks combined with all the systems..  eventually these few were found even though with badblocks if they were remapped in any way the system would NOT function..  these systems are still going strong to this day with unmapped bad blocks by just putting the update on a cd and using this method xell will not remap them..

as you said its a 1 min ordeal and is definately worth a shot..  create your image un-remapped and burn it to a cdr and flash it over xell.

[keropi]

will do tomorrow Harbinger076 , as for today I fuxx0red my nand (had the bright idea to boot gentoo, erase my nand with xbrflasher and then copy updflash.bin from usb... halfway linuz froze and now my nand is empty   ) so I need to put xell in it again via lpt ... the one pc in my home that has a parallel port runs win7/x64 ... will report tomorrow from my office  

edit: you mean xellous , not xell right?

[ZerOneX]

Without proper flashconfig(00023010) we can't remap badblocks and flash well.
Hope fix.
Thanks

I just did 2 jaspers 16a (23010) image using fbbuild and both of them are working like a charm, I did not get your point!!

[keropi]

ZerOneX, any of your jaspers with bad blocks?

[l_oliveira]

XeLLous README file suggest that one should not remap badblocks on files to be flashed through it.