xeBuild v1.01 Options

[Xbox-Scene]

xeBuild v1.01 Posted by XanTium | February 21 22:47 EST | News Category: Xbox360

Team xeBuild released a new version of xeBuild (a single application for building glitch, jtag and clean retail images) adding support for the 14717 kernel. What's new/fixed: * adds 14717 * trinity CB_B patches updated to allow glitch image booting on official 14717 updated slims, requires having CPU key before building image. Updated fats will likely require new CPLD timing, if you wish to continue to glitch a fat for the time being it's advised to not apply any update ] 14699. * included xells updated to xell reloaded v0.991 built 2012-02-19. See xell_info folder for usage info and changelog, or find newer builds at libxenon.org -note that for xebuild, jtag images use xell-2f not xell-1f * added devkit image building (WIP, see info below) * added bigffs jasper type (see info below) * added a small helper app, ini_creator.exe that will create a basic .ini file with crcs for xebuild when batches of files are dropped onto it, ready for sorting * bug fixes Full Change log: - minor bugs fixed (extended.bin, kiosk button not displaying) - invalid secdata.bin and extended.bin will be cleanly recreated instead of failing build - can now accept decrypted kv.bin without messing it up - fixed a bug with long version strings in firmware .ini files - fixed fatal exception when patch file is not found - added -i flag to specify additional addon component for ini/patch file name - corrected nandmu warning to only say xebuild will attempt to keep this data when the option is set - added additional jasper build mode jasperbigffs, results in a non-standard and much larger system file area (approx 32MiB larger) - patch slot address for glitch/retail images is now dynamically assigned (first block after xell/first block after CE) - devkit image building added - if pairing value can't be found in dump CF/CG it will attempt to be extracted from CB - smc size and address made dynamic (mainly for corona+) - corrected typo/problem with FAT bitmap creation - cache decrypted keyvault, refine messages regarding FCRT and output dvdkey at the end - logs/outputs expected/possible fuse values for console sequence bytes in CB - add dvdkey to ini and -o, to set dvd key in keyvault before writing it to the new image - fixed a possibly critical bug when parsing nanddump.bin FS entry - correct EU/AUS smc game region output - nanddump flash controller detect recoded, now only requires block 0 be not remapped - fixed unhandled exception when -o option that requires = did not have = - updated bl patches for all jtag machines and trinity (rgh fat doesn't need) to remove smc size = 0x3000 limit - fixed bug that was causing 2nd patch slot on retail builds to contain unneeded data - added fuse mask output while processing CB - added 14717 - added patch to trinity 9188 CB_B to bypass fuseline 2 revocation check Official Site: n/a (by 'Team xeBuild') Download: n/a (might be illegal under DMCA/EUCD) News-Source: xbins.org

[krizalid]

Regarding...

* trinity CB_B patches updated to allow glitch image booting on official 14717 updated slims

Does this version of xeBuild make the image_00000000.ecc file to boot xell to obtain CPU key and fuses or do we have to wait for an update version of that tool?

[Swizzy]

Regarding...
Does this version of xeBuild make the image_00000000.ecc file to boot xell to obtain CPU key and fuses or do we have to wait for an update version of that tool?

That's for xeBuild only, which makes full nand images, it does NOT make ECC images so you'll have to wait for that...

[kopyone]

Updated fats will likely require new CPLD timing, if you wish to continue to glitch a fat for the time being it's advised to not apply any update ] 14699.

I have a fat jasper that is already glitched and on 14699. Does this mean i should not install this xebuild with the new dash? Or is this just for the unglitched fat consoles that should not be updated before glitching?

Sorry, just a little confused.

[kero]

Got the warning when building:

'Could not find a non-zero CF LDV to use, setting it to 1 but that may be incorrect!"

Is there anywhere i can find out what exactly this error means?

[kero]

Got the warning when building:

'Could not find a non-zero CF LDV to use, setting it to 1 but that may be incorrect!"

Is there anywhere i can find out what exactly this error means?

Found the info: J-Tag images dont care what this value so i can ignore this warning

; byte 0x21f of decrypted CF (also is the count of 0xF in fuse rows 7 and 8)
; if you provide a nanddump.bin with the correct ldv value, there is no reason to fill this in
; jtag images won't care what this value is set to, but glitch and retail images require this to match CPU fuses
; valid values are 1 - 32, leave blank to set to 0 for devkit images

[uN0pEn]

Thank you for your hard work Team xeBuild. I will give it a try!

This post has been edited by uN0pEn: Feb 24 2012, 05:58 PM