Jump to content
RealModScene

BugReporter

Members
 View Profile  See their activity

  • Content Count

    4

  • Joined

  • Last visited

Posts posted by BugReporter

  3. Posted · Edited by BugReporter
    Cleaned it up a little adding BB Tags to make it easier to read

    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.

  4. Posted

    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

×
×
  • Create New...