xeBuild 1.15, xeBuild GUI 2.096 and Dashlaunch 3.15 released with 17349 support

[Chrishockey55 129]

 

17349 anyone? The latest builds of XeBuild by Team xeBuild, XeBuild GUI by Swizzy and DashLaunch by c0z have been released with support for the latest update by Microsoft.

Click bellow to download these great releases.

http://www.realmodscene.com/index.php?/topic/5391-xebuild-115-17349-kernel-support-added/

http://www.realmodscene.com/index.php?/topic/5392-dashlaunch-315-17349-kernel-support-added/

[felida 1651]

 

17349 anyone? The latest builds of XeBuild by Team xeBuild, XeBuild GUI by Swizzy and DashLaunch by c0z have been released with support for the latest update by Microsoft.

Click bellow to download these great releases.

http://www.realmodscene.com/index.php?/topic/5391-xebuild-115-17349-kernel-support-added/

http://www.realmodscene.com/index.php?/topic/5392-dashlaunch-315-17349-kernel-support-added/

thanks for the update ;-)

[Fabricio Messias De Godoi 97]

this giving almost all times fatal crash Intercepted while playing a game

[armantaleser 25]

anyone tried the 2TB External HDD capabilities?

btw, what software we can use to view the 2TB External HDD content? Unlike the fat32 format it was easy to drag and drop games from Windows OS.

[gavin_darkglider 1559]

USB Xtaf browser, or horizon. Really any software that worked before for reading that stuff.

[Swizzy 2079]

this giving almost all times fatal crash Intercepted while playing a game

What game are you getting that with? it's most likely something stupid... make sure you do NOT have ANY plugins etc. loaded which could cause the problem...

[armantaleser 25]

anyone confirm the Horizon can read 2TB xbox format please?

[Swizzy 2079]

anyone confirm the Horizon can read 2TB xbox format please?

Just try it?

Worst case, you'll just have to use something on your box instead

I've read some that they no longer have a USBMU on the drive, instead they have a hidden directory "Content"

** Edit: **

so, i just checked, now a days they just put the hidden directory on the harddrive, there's nothing more to it, just "Content" directly on the USB

[Chrishockey55 129]

Just try it?

Worst case, you'll just have to use something on your box instead

I've read some that they no longer have a USBMU on the drive, instead they have a hidden directory "Content"

** Edit: **

so, i just checked, now a days they just put the hidden directory on the harddrive, there's nothing more to it, just "Content" directly on the USB

 

anyone confirm the Horizon can read 2TB xbox format please?

I actually reached out to one of the devs a few weeks ago. This is the response i got

" Horizon was updated to support the new dashboard update. If it doesn't detect the drive, create a "Content" folder in the root of it using Windows Explorer."

Hope that answered your question o.O

[armantaleser 25]

thanks man. I was worried if I format my 2TB External HDD and cannot be viewed in windows. The result I cant use the usb 3.0 transfer speed.

 

other question:

If I update to 17349 using the NXE not using xebuild. What will happen to my jtag console? will I get Ban?

[Swizzy 2079]

thanks man. I was worried if I format my 2TB External HDD and cannot be viewed in windows. The result I cant use the usb 3.0 transfer speed.

 

other question:

If I update to 17349 using the NXE not using xebuild. What will happen to my jtag console? will I get Ban?

You will get a retail console that may or may not work... Bottom line, DO NOT DO IT!

xeBuild was made for a reason...

[armantaleser 25]

btw, my console won't format my 2TB External HD.

[2Ceedz 40]

hmmmmm...should be a work around, put a hidden 'content' folder on the drive....but weird if updated it should do it, correct? 

[Swizzy 2079]

btw, my console won't format my 2TB External HD.

Do you have 17349 installed? i had my HDD be NTFS and formatted on the console... it rebuilt the entire partition table and formatted the drive for me, i might try to do that on window and just make the folder see if that works, it should... i don't think it really matters if the folder is hidden or not tho

[2Ceedz 40]

Do you have 17349 installed? i had my HDD be NTFS and formatted on the console... it rebuilt the entire partition table and formatted the drive for me, i might try to do that on window and just make the folder see if that works, it should... i don't think it really matters if the folder is hidden or not tho

Yeah, im not on the update yet...and not formatting my drive (in fact all i need is the content folder probably-which i already had for GoDs off external.)  But did see that info and know the xbox puts it in hidden so wasnt 100% on that.....so, if /when i update...my box should pick up my external content folder immediately? (If i still have formatted to fat32?)

[BugReporter 0]

This release (xeBuild v1.15.709) is most certainly faulty:

Building a jasper256 image out of a nanddump throws the following error:

extracted nanddump\xenonclatin.xtt (0x11b000 bytes) (crc32: 0x5cb33297 ini: 0xd5d17ff5)

******WARNING: 'xenonclatin.xtt' crc32: 0x5cb33297 expected: 0xd5d17ff5
***** could not read file 'xenonclatin.xtt' *****

******* ERROR: critical firmware file missing, cannot proceed!
 

There has probably something gone wrong with the extraction routine. Former versions of xebuild can extract and check the file 'xenonclatin.xtt' OK. Manually extracting the file and putting it in the firmwarefolder '17349' will workaround this problem.

Could the author please check and fix this issue?!

 

xebuild is used like this:

xebuild.exe -t jtag -c jasper256 -f 17349 -d mydata.jasper jasper-17349.bin

[Swizzy 2079]

This release (xeBuild v1.15.709) is most certainly faulty:

Building a jasper256 image out of a nanddump throws the following error:

extracted nanddump\xenonclatin.xtt (0x11b000 bytes) (crc32: 0x5cb33297 ini: 0xd5d17ff5)

******WARNING: 'xenonclatin.xtt' crc32: 0x5cb33297 expected: 0xd5d17ff5

***** could not read file 'xenonclatin.xtt' *****

******* ERROR: critical firmware file missing, cannot proceed!

 

There has probably something gone wrong with the extraction routine. Former versions of xebuild can extract and check the file 'xenonclatin.xtt' OK. Manually extracting the file and putting it in the firmwarefolder '17349' will workaround this problem.

Could the author please check and fix this issue?!

 

xebuild is used like this:

xebuild.exe -t jtag -c jasper256 -f 17349 -d mydata.jasper jasper-17349.bin

Can you send me the dump you tried this with so i can verify that it is indeed a bug with xeBuild? and also check that it's fixed once we've found where the problem is exactly...

[BugReporter 0]

I would but, as you know, there is private information in the dump which i am not willing to share.
These files need to be in the 17349 folder to build a jasper256 jtag image:

08.03.2000  09:29         1.159.168 xenonclatin.xtt
08.03.2000  09:29         1.736.704 xenonjklatin.xtt
08.03.2000  09:29           589.824 ximedic.xex

A colleague tried to build a jasper glitch image and also got errors, so its independent of the image type.
Surprisingly i and he could build a 16mb falcon glitch image like this:

xebuild.exe -t glitch -c falcon -f 17349 -d mydata.falcon falcon-17349.bin

There seems to be also a problem with the bad block remapping. For instance If i use the whole dump, including the 256mb flash storage, i get the following differences in the logfiles:
The whole jasper dump has really only 2 bad blocks at 0x1a, 0x151.

using the short dump (64mb):

nanddump header checks passed OK!
Loading NAND dump (0x4200000 bytes)...done!
Detecting NAND controller type from dump data...
    NAND dump is from a big block machine
    NAND dump uses big block controller
parsing dump into user and spare...
bad block at 0x1a (raw offset 0x35a000), block ignored


bad block at 0x151 (raw offset 0x2b71000), block ignored
done!
cleaning up stray remaps
block 0x1a had no remap, assigning remap block 0x1ff
block 0x151 had no remap, assigning remap block 0x1fe


done!
--remap summary--
0: source: 0x001a dest: 0x01ff
1: source: 0x0151 dest: 0x01fe

using the full dump:

nanddump header checks passed OK!
Loading NAND dump (0x4200000 bytes)...done!
Detecting NAND controller type from dump data...
    NAND dump is from a big block machine
    NAND dump uses big block controller
parsing dump into user and spare...
bad block at 0x1a (raw offset 0x35a000), block ignored
ECD error at block 0xd1 (raw offset 0x1af1000), block will be remapped
ECD error at block 0xd9 (raw offset 0x1bf9000), block will be remapped
bad block at 0x151 (raw offset 0x2b71000), block ignored
done!
cleaning up stray remaps
block 0x1a had no remap, assigning remap block 0x1ff
block 0xd1 had no remap, assigning remap block 0x1fe
block 0xd9 had no remap, assigning remap block 0x1fd
block 0x151 had no remap, assigning remap block 0x1fc
done!
--remap summary--
0: source: 0x001a dest: 0x01ff
1: source: 0x00d1 dest: 0x01fe
2: source: 0x00d9 dest: 0x01fd
3: source: 0x0151 dest: 0x01fc

This behaviour makes no sense.

I diffed the logfiles of old (1.14) and new (1.15) xebuild versions and got more strange differences:
old:

MobileB.dat found at block 0x99, page 0x8 (page 0x1328), size 2048 (0x800) bytes
MobileC.dat found at block 0x345, page 0x0 (page 0x68a0), size 512 (0x200) bytes
MobileD.dat found at block 0x100, page 0x10 (page 0x2010), size 2048 (0x800) bytes
MobileE.dat found at block 0x97, page 0x0 (page 0x12e0), size 2048 (0x800) bytes
Statistics.settings found at page 0x7bc0, size 4096 (0x1000) bytes
Manufacturing.data found at page 0x7bc0, size 4096 (0x1000) bytes
seeking FSRoot...fsroot found at block 0x98, page 0x0 (page 0x1300) raw offset 0x1300

new:

Scanning for mobile data and fsroot...Mobiles found:
    fsroot      version 102 found at offset 0x00260000 len 0x4000 page 0x00001300
    mobileB.dat version 45 found at offset 0x00265000 len 0x0800 page 0x00001328
    mobileC.dat version 01 found at offset 0x00d14600 len 0x0200 page 0x000068a3
    mobileD.dat version 01 found at offset 0x00402000 len 0x0800 page 0x00002010
    mobileE.dat version 02 found at offset 0x0025c000 len 0x0800 page 0x000012e0
extracting MobileB.dat from page 0x1328 (offset 0x265000), size 2048 (0x800) bytes
extracting MobileC.dat from page 0x68a3 (offset 0xd14600), size 512 (0x200) bytes
extracting MobileD.dat from page 0x2010 (offset 0x402000), size 2048 (0x800) bytes
extracting MobileE.dat from page 0x12e0 (offset 0x25c000), size 2048 (0x800) bytes
Statistics.settings found at offset 0xf78000, size 4096 (0x1000) bytes

 
This is missing in the new log:
 

Manufacturing.data found, adding from previous parse
    adding Manufacturing.data at raw offset 0xf74000 len 0x1000 (end 0xf75000)

 
Strangely this is output in the logfile if not using the workaround of manually extracting the files:

crl.bin found in sector 0x343 size 0x9b0...verify failed! Discarding data.
extended.bin found in sector 0x346 size 0x4000...verify failed! Discarding data.
secdata.bin found in sector 0x344 size 0x400...verify failed! Discarding data.

Edited May 24, 2015 by BugReporter
Cleaned it up a little adding BB Tags to make it easier to read

[Swizzy 2079]

Yes, i know about the per-console data, but i'm one of the developers behind this whole thing, you blindly trust our software with your dump as it's your only option (i assume?) but, you don't trust me not to steal your data to fix the issue? Anyways, if you don't want to share your dump with me, that's fine... we'll just have to find someone that actually do trust me... which have the same issue as you do

I don't have a big block jasper anymore, and if both consoles are of this model (and not 16MB model) it's a BB Jasper specific issue which requires that we have such a dump to check against, the flash layout isn't the same for 16MB, BB Jasper and MMC Corona, beyond that, Xenon, Zephyr and Falcon share the exact same structure of everything while Jasper, Trinity and NAND Corona have a different structure (they're the same between 16MB Jasper, Trinity and NAND Corona)

Edited May 23, 2015 by Swizzy

[nexus 6]

Hi Swizzy

 

I previously successfully updated two jasperbb boxes with the update server.

 

However after reading this thread I tried to build a image from scratch and I am also getting:

******WARNING: 'xenonclatin.xtt' crc32: 0x5cb33297 expected: 0xd5d17ff5
***** could not read file 'xenonclatin.xtt' *****

I'm using the command line:

xebuild -t jtag -d mydata -c jasper512 -f 17349

I'm happy to provide you the original nanddump I am using if that would help.  Do you want to PM me details of how to get it to you?

 

 

nexus

 

 

 

[Swizzy 2079]

Hi Swizzy

 

I previously successfully updated two jasperbb boxes with the update server.

 

However after reading this thread I tried to build a image from scratch and I am also getting:

******WARNING: 'xenonclatin.xtt' crc32: 0x5cb33297 expected: 0xd5d17ff5
***** could not read file 'xenonclatin.xtt' *****

I'm using the command line:

xebuild -t jtag -d mydata -c jasper512 -f 17349

I'm happy to provide you the original nanddump I am using if that would help.  Do you want to PM me details of how to get it to you?

 

 

nexus

You can use any filesharing service you trust and send me the link in a PM

When you say it worked using update server, was that using xeBuild 1.15 or 1.14?

[nexus 6]

Swizzy

 

I have PM you.

The update server was on 1.15.  I note the log file includes "found (19) 'xenonclatin.xtt' crc: 0xd5d17ff5".  There were no errors with the update server on either of the two boxes which I updated.

 

Nexus

[Swizzy 2079]

Swizzy

 

I have PM you.

The update server was on 1.15.  I note the log file includes "found (19) 'xenonclatin.xtt' crc: 0xd5d17ff5".  There were no errors with the update server on either of the two boxes which I updated.

 

Nexus

If memory serves me right, that is because the update server extracts the data on the console itself, reading from the flash filesystem, meaning it won't have this bug... but, that is atleast some good news, can you also do me a favor and test if it works with xeBuild GUI 2.096? it should work fine using that, as it have these files pre-extracted in the common folder

[nexus 6]

The xeBuild log complains about the following:

******WARNING: 'xenonclatin.xtt' crc32: 0x5cb33297 expected: 0xd5d17ff5

******WARNING: 'xenonjklatin.xtt' crc32: 0x70660678 expected: 0xdde4a14c

******WARNING: 'ximedic.xex' crc32: 0x9f1cbe75 expected: 0x1d992bfb

However it does build an image.

 

[BugReporter 0]

It is no matter of trust, i just do not want to share the console specific data with anybody.

There is also no need to share the original dump to debug the tool. Just use xebuild (better use an older version) to create the desired jasper dump. This enables you to recreate the problems (admittedly not all) with xebuild 1.15. I checked this too.