DO NOT USE INTERNAL MEMORY ON A BIG BLOCK JASPER!

[idog]

Just wanted to add (just for experimenting on my own JTAG-ed 256MB Jasper).

Fresh out of it's package, done the initial setup and created a profile on the (internal) MU.
Then deleted the profile from the MU.

Hooked up Olimex, did a complete dump, verify, yadayadayada. Flashed back XBR3 for BB with extracted KV and CONFIG from dumped bin.

Then experimented a bit. Created a profile on the MU, installed XeXMenu 1.1 Live on the MU. Even installed a small XBLA game on the MU.
Gamed a bit (making savegames on the MU). No problems whatsoever, been doing this a few days now and zero issues.

Exactly what should I experience ? Corruption in what way ?

(if $#!t hits the fan, I'll just flash back the dump again, so no worries), but I'm just curious as to why I'm not having any difficulties using the MU this way.

(I might add, that I only had one bad block while dumping :

Code:

Looking for usb interface device
FlashConfig:008A3020
256MB Nand Detected
Starting Block:0x000000
Ending   Block:0x003FFF
Configured for Large Block Nand
Error: 250 reading block 36B0
Error: 210 reading block 36B1
Error: 210 reading block 36B2
Error: 210 reading block 36B3
Error: 210 reading block 36B4
Error: 210 reading block 36B5
Error: 210 reading block 36B6
Error: 210 reading block 36B7

[crimpshrine]

Fill up the MU and you can make it happen right away.

Otherwise it's a game of chance every time you save to it.

[MagnusHydra]

Thank you for the info everyone. I had mine reformatted my 512 before Installed XBR 1 and then 3. I've never saved to it and only change the name before installing xbr. It has 1 bad block in it I know for sure but I can't remember where. I've been using the 512 ever since XBR came out for the 512. I really started using it once xbr 3 came out. I always used the HDD and never the MU to save stuff. I see I might want ot stop using it until this issue is fix. So again thank you!

[ReverseAffect]

thought!......<yes thought....

do you think this is because being the mu area, same as the external ones,that it's does some kinda secure checking for valid files?
maybe, this wasn't taken out when the xbr came along. and either doesn't know what to do with this info,
or something gets written to a block in that area and affects this,(causing corruption)whereas the signed normal file it bypasses writing to the block (because it checked valid)
kinda like secdata. won't be altered unless the drive dvd-drive is disconnected....
(MU area gets altered because, not a valid file(s) format for the 360....even people with 0 error,
full nands read/write have this problem, not just the bad-block people.
I ain't saying, I'm just saying

[Marko_pt]

I have been going back and forth with some people on this. I hope someone will sticky it and lock this for now.

[30:01:10:13:23] <Redline99> because xbr_3 screwed up the block numbers
[30:01:10:13:23] <mastag21> i just trash the MU partition
[30:01:10:13:23] <Redline99> its difficult to explain
[30:01:10:13:23] <mastag21> i always delete MU partition
[30:01:10:13:23] <mastag21> too many people's systems been getting fubar
[30:01:10:13:23] <Redline99> but I will release a new bbm when a new xbr is released
[30:01:10:13:23] <Redline99> MU is not usable, using it at all screws up flash

Straight from Redline99 =)

For your information, to delete the MU partition using multiple methods:

nandpro lpt: -e256 1001
nandpro lpt: -r512 1001

in UsbJtagNT do a:

flshdct 0
"erase 4200000 1ce00000" for 512MB




flshdct 0
"erase 4200000 e700000" for 256MB

for 512mb nand should't be "nandpro lpt: -e512 1001" ?

is there another way fast do delete this?

[d4m4n]

The commands are
nandpro usb: -e256 1001
or
nandpro usb: -e512 1001

The erase is very fast. Much faster than reading so can be done fast with LPT cable.

[Marko_pt]

The commands are
nandpro usb: -e256 1001
or
nandpro usb: -e512 1001

The erase is very fast. Much faster than reading so can be done fast with LPT cable.

thank very much for the quick answer, i already done it. it apears on the consola UNFORMATTED right.


should we always have to delete this partition or can we use it? i flashed my xbr with xellous and i injected xellous in xbr but now my console dont but xellous.

ins't suposed that XBR_Jasper_6723_256_512_8955_1.bin already come with xell to boot with EJECT?

[Arakon]

_1 = first version, old, outdated.

once a real big block XBR comes out, the save partition will be usable.

[Marko_pt]

_1 = first version, old, outdated.

once a real big block XBR comes out, the save partition will be usable.

you're right, stupid me lol, with so many files here i haven't see that. thanks.

[Neptune]

[30:01:10:13:23] <Redline99> because xbr_3 screwed up the block numbers
[30:01:10:13:23] <mastag21> i just trash the MU partition
[30:01:10:13:23] <Redline99> its difficult to explain
[30:01:10:13:23] <mastag21> i always delete MU partition
[30:01:10:13:23] <mastag21> too many people's systems been getting fubar
[30:01:10:13:23] <Redline99> but I will release a new bbm when a new xbr is released
[30:01:10:13:23] <Redline99> MU is not usable, using it at all screws up flash

Straight from Redline99 =)

To clarify, the xbr_3 for large block is a hybrid image meaning it has some parts from a small block and some parts from a large block.  The block numbering issue is not directly related to the MU issue. It causes issues with apps such as bad block mover. The MU corrupting thing something else.  The nand is not an easy structure to mess with and it is a long learning curve for everyone.  So just be patient and I'm sure issues will be addressed as quickly as possible. 

I will re-release bad block mover for large block when a new xbr for large block is released that is not a hybrid.  The issue is that it cannot remap blocks from the "hybrid" section reliably because the block ids are not valid. So even if they are remapped it seems that they cannot be located without metadata fixes.  This can be done, but its better to just wait for a new xbr that isn't a hybrid.

This begs the question

How do we remap bad blocks then? Manually or otherwise.

[Maniaxx]

What about Freeboot 0.032? Can we use the internal MU now? I think i installed the avatars there already.

[doveman]

Apparently there's a Dashlaunch patch that allows the use of the MU now.

I haven't tried it myself.

[Maniaxx]

I'm using that patch already. No errors so far but ppl telling you might need to fill up the MU to trigger the bug.

[l_oliveira]

I'm using that patch already. No errors so far but ppl telling you might need to fill up the MU to trigger the bug.

This almost make me want to transform my jasper 16 into jasper 512 (lol)

[cory1492]

No errors so far but ppl telling you might need to fill up the MU to trigger the bug.

Nope, it can occur any time a block is written. It is more likely to occur (99.9% in tests) if you format, fill , format again, then start writing to it (it has to do with kernel's wear leveling.) The dash launch patch adjusts how many blocks are set aside at the beginning of NAND for the bootloaders - personally I can't confirm how stable the drivers are on a retail/non-jtag unit, but there is no longer any problem with the NAND MU corrupting bootloaders.

l_oliveira : did you convert from large flash to 16M before? If not one would need to confirm a big block controller in the machine before swapping NAND (good block 0xFF is in spare byte[0] on big block controller dumps.)

[l_oliveira]

l_oliveira : did you convert from large flash to 16M before? If not one would need to confirm a big block controller in the machine before swapping NAND (good block 0xFF is in spare byte[0] on big block controller dumps.)

Several times. I changed the jumpers, and replaced the flash chip.  I then extracted the files from the console flash dump but then when I went to generate the new freeboot image I used an SMC of a 16MB jasper.
Not a single problem. It worked when I used XBR too and XBR was simpler as I only needed to flash the keyvault back.

Edit:

As people might be interested on this here's a quick "howto":

Take the nand from a 3RLOD Xenon, wipe it with the E command from nandpro (while it's on the Xenon mobo is fine, just hook the SPI on it. doesn't matter if it's not JTAG-able)
Move it to your Jasper, copy the strap resistors positions so they look exactly the same as the ones on the Xenon.
Take SMC from a 16MB Jasper, put within your freeboot files and change the make command on ibuild to make a 16mb jasper image.

Flash it with nandpro and be happy.

Erasing the NAND before moving to the Jasper is IMPORTANT as it erases the Xenon SMC from the flash (which would "brick" the southbridge and block the use of the SPI port).

[Maniaxx]

Why is it necessary to swap the chips and not just 'copy the strap resistors positions'? Can't we make a 16x16M flash out of it?

[l_oliveira]

If you move the resistors, the XBOX360 will not even power on because it won't be able to read the NAND. Small block vs large block and address ranges are different due to different block sizes.


There's no way around swapping the chips.