Nandpro issues with XBR

[iLLNESS]

It seems more and more now i'm seeing numerous people having issues with flashing XBR_3 using nandpro.

there has been a multitude of users claiming that when writing the bin that when flashed with nandpro, the 360 didnt work, worked just fine when using lflash.

I can't say for sure the hardware the people are using, but i'm assuming it LPT most the time. I personally haven't experienced this myself but i'm sure one day i will.

So, if you're having the issue, currently the only workarounds are avoiding nandpro and using lflash to write, or write the default xbr bin and then flash kv and config directly to nand.

it's pretty hard to rule out nandpro virtual device as the issue as that is being used to create the bin for lflash which has worked, and its hard to rule out the writing of the kv and config itself with nandpro. it just seems really weird.

anyone have any details on whats going on? i'm just seeing this alot, and figure it's worth it to bring to some others attention.

so again a quick breakdown.
injecting kv and config to xbr_3 bin and writing with nandpro == fail
flashing xbr_3 bin and writing with nandpro, then writing kv and config directly to nand == success
injecting kv and config to xbr_3 and writing with lflash == success.

it's pretty hard to troubleshoot but some people have been spending hours/days flashing/reading/reflashing/etc and the only thing in the end that works is writing kv and config to nand, or using lflash.

[crimpshrine]

So what other options do large block nand users have to try at this point?

Since lflash is not an option for 256/512 big block nands, or did I miss something and it is now..

[iLLNESS]

it is not

but, you can write the kv and config directly to the nand with nandpro if you do come across this issue.

nandpro works just fine, but, sometimes it seems when injecting kv and config it does not work correctly.

[utar]

This doesn't really make sense to me.

I did option 3 (lflash) on my xenon which worked great.  I didn't try options 1 or 2.

The only possible explanation (apart from user error) is a bug in  nandpro, but surely the same bug if it existed would manifest when writing to a virtual device or the nand itself?  Anyway we know the images generated by nandpro (generated using a virtual device) are good because they work when used with lflash.


Utar

[crimpshrine]

Personally I have not run into any issues injecting the keyvault or config into XBR before flashing with nandpro.

These users that report that when they inject the config and keystore before flashing should read those bytes back off the Nand and compare it to what they injected.  If they match, and then the manually write those straight to the Nand and magically their 360 boots XBR then, it makes no sense to me.

[wolfson8471]

I can confirm the first and second points made by "iLLNESS" breakdown.  Agreed there are multi layer dependencies to why these types of issues arise but its still good to discuss, nevertheless I found nandpro extremely useful, thank you to whoever coded it (looking at a post Tiros maybe??)     Details of my experience here  > http://www.xboxhacker.org/index.php?topic=13534.0

[crimpshrine]

I can confirm the first and second points made by "iLLNESS" breakdown.  Agreed there are multi layer dependencies to why these types of issues arise but its still good to discuss, nevertheless I found nandpro extremely useful, thank you to whoever coded it (looking at a post Tiros maybe??)     Details of my experience here  > http://www.xboxhacker.org/index.php?topic=13534.0

I read your experience.. odd to say the least.

It sounds similar to an experience I have had with 1 specific 360.  I think I tried that combination already with this troublesome one I have here, but am going to try one more time with just flashing stock XBR #3 and then following up with writing the keyvault and config directly to their locations before trying to boot it.

[crimpshrine]

Can either of you explain why Nandpro does this:

C:\nand>nandpro lpt: -w16 rawkv.bin 1 1
NandPro v2.0b by Tiros

Testing LPT device address:0378
FlashConfig:00AA3020
512MB Nand Detected
Using LPT device at address:0378
Starting Block:0x000001
Ending   Block:0x000001
Configured for Large Block Nand
Writing
File: rawkv.bin FileLen:4200 Blocks:1
0007

It counted 1, then 2, then 3, then 4 till it got to 7 then quit.

Shouldn't it JUST be doing 0001 then quitting??

If I READ from the nand it JUST lists 0001 on the screen.

C:\nand>nandpro lpt: -r16 xbrkey2.bin 1 1
NandPro v2.0b by Tiros

Testing LPT device address:0378
FlashConfig:00AA3020
512MB Nand Detected
Using LPT device at address:0378
Starting Block:0x000001
Ending   Block:0x000001
Configured for Large Block Nand
Reading
0001

When I did the rawconfig:

C:\nand>nandpro lpt: -w16 rawconfig.bin ef7 2
NandPro v2.0b by Tiros

Testing LPT device address:0378
FlashConfig:00AA3020
512MB Nand Detected
Using LPT device at address:0378
Starting Block:0x000EF7
Ending   Block:0x000EF8
Configured for Large Block Nand
Writing
File: rawconfig.bin FileLen:8400 Blocks:2
0EFF

It started at 0EF0, then wrote to: 0EF1, 0EF2, 0EF3, 0EF4, 0EF5, 0EF6, 0EF7, 0EF8 all the way to 0EFF then quit.

It says STARTING BLOCK:0x000EF7, so why did it start at 0EF0??

When I READ from the nand the config:

C:\nand>nandpro lpt: -r16 xbrconfig.bin ef7 2
NandPro v2.0b by Tiros

Testing LPT device address:0378
FlashConfig:00AA3020
512MB Nand Detected
Using LPT device at address:0378
Starting Block:0x000EF7
Ending   Block:0x000EF8
Configured for Large Block Nand
Reading
0EF8

So it read 0EF7 and then 0EF8 then quit

Is this the way it is supposed to be working? It looks like it is writing over different areas then when it reads.

This is nandpro 2.0b

[Arakon]

why in the world are you trying to write to a large block nand with w16?

[wimpie007]

I have seen this behaviour also with my jasper256.
Writing config blocks doesn't write 2 blocks, but 16...

Question: reading my config blocks with "nandpro orig: -r256 rawconfig ef7 2" reads back almost all FF.
Does ef7-ef8 mostly exists of FF's?

regards,

[iLLNESS]

I have seen this behaviour also with my jasper256.
Writing config blocks doesn't write 2 blocks, but 16...

Question: reading my config blocks with "nandpro orig: -r256 rawconfig ef7 2" reads back almost all FF.
Does ef7-ef8 mostly exists of FF's?

regards,

yes. there isn't much data in the config.

as well, i can also confirm nandpro's issue with not writing the blocks correctly for big block like mentioned above.
it never ever writes only 1 or two blocks, its always doing a big chunk.

[wimpie007]

Maybe this had to do with ecc memory, and recalculating checksums?

[crimpshrine]

why in the world are you trying to write to a large block nand with w16?

It does the same no matter what I specify there.  Even if I use -w512 it still displays that it writes the same number of blocks. (more then when read with the same command)

[Tiros]

it's pretty hard to rule out nandpro virtual device as the issue as that is being used to create the bin for lflash which has worked,

Yet thats exactly the problem
Its a little more difficult to detect the fash configuration from a file than to simply read the controller to get it.
This is why injecting config and kv right into the flash, sometimes works better than injecting into the vnand device.
So Id guess youd have to call it a bug
But no worries, its been fixed
Also adding a bit of code that will read the input pin until it reads the same twice for each bit in. Hopefully this will allow a better reading for lpt users with very little additional execution time. Look for these features in nandpro20c, very soon.
Another thing, if you are having trouble reading, and often dont get matching reads, your interface is marginal. You cant really expect to write reliably if you cant read reliabely.