J-Runner bug, Create Xell-Reloaded for Jasper 512/BB?

muffpotter

Junior Member
Sep 21, 2005
18
0
Hi,

please tell me that i'm doing something wrong.

I have a R-JTAG(AUD_CLAMP) and DemoN(with BB upgrade kit) installed in my Arcade Jasper 512MB and I am trying to create a Xell-Reloaded image for quite some time now.

What I do:
- Load Source using a copy of my stock nand(which is 512MB large since J-Runner crashes on me when I try to just extract the necessary 64MB)
- change Motherboard to Jasper16MB
- check Aud_Clamp
- check R-Jtag
- Create Xell-Reloaded
- erase DemoN flash using Advanced
- Write Xell-Reloaded

Now that is what happens:
J-Runner creates a file jasper_hack_aud_clamp.bin with the size of 1,351,680 bytes and flashes it to the DemoN on board flash, which is fine.
I can even use the Read Nand function to make sure the flash content is exactly as the file.
The J-Runner log shows NO invalid block after the flash process.
I should mention that when I try to boot this image the post monitor tells me I get stuck in 69 - KEY_VAULT

Now to the strange part:
With that jasper_hack_aud_clamp.bin still in the DemoN flash , when I flash it again (without erasing the flash) I suddenly get an 'invalid block' error 0x1 which is exactly where the key vault is stored in jasper_hack_aud_clamp.bin.

It gets even more weird:
I can reproduce the steps mentioned above on two different DemoN's.

To top things:
Still without erasing the flash, when I remap the invalid block to 0x3ff using the Advanced DemoN/Fusion write, everything seems fine but booting the box will still get me stuck in post 69 - KEY_VAULT.

Still getting better:
Not erasing the flash I try to flash it again with the Advanced DemoN/Fusion write when I suddenly get the 'invalid block 0x3ff' message and I can see also that J-Runner remapped it to 0x3fe.
If I try to flash once more then J-Runner crashes reproduceable.

I can repeat the above steps on both my DemoN bords(one installed, one connected via micro usb) over and over again after having erased the DemoN flash first.

Why I think it's a J-Runner bug:
I inspected the block starting at 0x4200 in the jasper_hack_aud_clamp.bin and also the 16 byte long ECC from all the 32 pages of that block 0x1 (KEY_VAULT).They are all set to 'invalid' with the fifth's byte not set to 0xff. According to the hynax datasheet this should only be the case with bad blocks caused by the production of the chip.

I somehow got my box booting into Xell but honestly, I don't know how this was even possible and I remember that the boot screen complained about an invalid KEY_VAULT and wouldn't show the DVD-Key.

I'm right now trying to figure out how to calculate the wrong ECC for the KEY_VAULT myself and get a working Xell image.

Hopefully there will be a fixed version of J-Runner soon.
 

Attachments

Last edited:

Martin C

VIP Member
Jan 10, 2004
35,981
0
Scotland, UK
www.team-xecuter.com
It sounds like you have a bad block on the DemoN NAND.

Erase the DemoN, then write the jasper_hack_aud_clamp.bin using the advanced write (demon/Fusion - handles bad blocks).

You get errors on 0x3ff and 0x1 as J-R reads the validity of ECC in each block. 0x1 was remapped badly to 0x3ff which then tells the app there's a problem there too. Carry out the above and if that doesn't work, let me know. It's fairly simple to resolve (which I might add, any pro installer should know how to do).
 

muffpotter

Junior Member
Sep 21, 2005
18
0
No i'm sorry, I don't have bad blocks trust me.
How are the odds that the same bad blocks occur on two different DemoN's?
Besides, the Xell image contains the calculated ECC's and they are just wrong for that one block 0x1.
J-Runner places the 0xFF to the wrong offset overwriting the block number and then calculates the CRC wrong.
 

Martin C

VIP Member
Jan 10, 2004
35,981
0
Scotland, UK
www.team-xecuter.com

muffpotter

Junior Member
Sep 21, 2005
18
0
Ok, here's the J-Runner log...
Code:
===================================================
24 March 2014 11:30:53
J-Runner v0.3 Beta (4) Started

WARNING! - Your selected working directory already contains files!
You can view these files by using 'Show Working Folder' Button

Checking Files
Finished Checking Files
DEMON
Hardware   : Demon Phat
Firmware   : 1.4
Flash ID   : 0x73AD Hynix (16MiB - Small block)
Flash Size : 0x400 blocks of 0x4200 bytes
Erasing Whole Nand
Done!
in 0:00 min:sec
Initializing Jasper512bb_1.bin..
Jasper 512MB
Jtag Selected
Nand Initialization Finished
Aud_Clamp Selected
R-Jtag Selected
Jasper 16MB Manually Selected
Patching Jasper version 2.3 SMC at offset 0x12BA
XeLL file created Successfully jasper_hack_aud_clamp.bin
Hardware   : Demon Phat
Firmware   : 1.4
Flash ID   : 0x73AD Hynix (16MiB - Small block)
Flash Size : 0x400 blocks of 0x4200 bytes
Invalid Blocks : 
Writing Nand
Starting remapping process
Done!
in 0:03 min:sec
Patching Jasper version 2.3 SMC at offset 0x12BA
XeLL file created Successfully jasper_hack_aud_clamp.bin
Hardware   : Demon Phat
Firmware   : 1.4
Flash ID   : 0x73AD Hynix (16MiB - Small block)
Flash Size : 0x400 blocks of 0x4200 bytes
Invalid Blocks : 0x1 
Writing Nand
Starting remapping process
Remapping Block 0x1 @ 0x3FF
Done!
in 0:03 min:sec
Patching Jasper version 2.3 SMC at offset 0x12BA
XeLL file created Successfully jasper_hack_aud_clamp.bin
Hardware   : Demon Phat
Firmware   : 1.4
Flash ID   : 0x73AD Hynix (16MiB - Small block)
Flash Size : 0x400 blocks of 0x4200 bytes
Invalid Blocks : 0x1 0x3FF 
Writing Nand
Starting remapping process
Remapping Block 0x1 @ 0x3FF
Remapping Block 0x3FF @ 0x3FE
Done!
in 0:03 min:sec
Whatever I do in J-Runner after this makes it crash.
I can repeat the steps every time after having erased the flash before.
And I can do that on two different DemoN boards.

I attached the Xell image. If you check it, you will see that all 32 ECC's in block 0x1 are wrong.
So, if I flash the first time to an erased flash all will go fine.
Then the flash contains that invalid block 0x1 of the wrong Xell image, which leads to an invalid block at 0x1 when I flash again.
This new flash process will remap the block 0x1 to 0x3ff which is why I get all of a sudden two invalid blocks when I flash a third time and so on.
After the third flash, which shows invalid blocks 0x1, 0x3ff and 0x3fe, J-Runner will crash whatever I do.

I hope this helps to figure it out.
Thank you for investigating.
 

muffpotter

Junior Member
Sep 21, 2005
18
0
Here we go...
No bad blocks in the stock nand.

JR_bad_blocks_tab.jpg

Btw.
I took some time to correct the ECC's of said block 0x1 and flashed it to the DemoN but only to see that after reading it back to a file the ECC's were wrong again :(
Looks like the write flash functions calculate the ECC again and don't use the ones already contained.
 

muffpotter

Junior Member
Sep 21, 2005
18
0
I used a KV from a Falcon stock nand, inserted it into the Jasper Xell image and then flashed.
I checked with Read Nand and the data was flashed correctly.
I am now running into the dreaded E 79 all the time.
Post is complete to 79 - LOAD_XAM.
The debug led isn't on.

Please, please don't tell me my R-Jtag wiring is wrong and this happens because I used the KV from a Falcon.

Code:
===================================================
24 March 2014 13:20:58
J-Runner v0.3 Beta (4) Started

WARNING! - Your selected working directory already contains files!
You can view these files by using 'Show Working Folder' Button

Checking Files
Finished Checking Files
Initializing jasper_hack_aud_clamp_KV-Falcon16MB.bin..
Header is wrong..
Jasper SB
Jtag Selected
Nand Initialization Finished
DEMON
Hardware   : Demon Phat
Firmware   : 1.4
Flash ID   : 0x73AD Hynix (16MiB - Small block)
Flash Size : 0x400 blocks of 0x4200 bytes
Erasing Whole Nand
Done!
in 0:00 min:sec
Hardware   : Demon Phat
Firmware   : 1.4
Flash ID   : 0x73AD Hynix (16MiB - Small block)
Flash Size : 0x400 blocks of 0x4200 bytes
Invalid Blocks : 
Writing Nand
Starting remapping process
Done!
in 0:03 min:sec
Reading Nand to C:\Users\engr\Desktop\Installer\xbox360\J-Runner\output\nanddump1.bin
DEMON
Hardware   : Demon Phat
Firmware   : 1.4
Flash ID   : 0x73AD Hynix (16MiB - Small block)
Flash Size : 0x400 blocks of 0x4200 bytes
Reading Nand
Done!
in 0:20 min:sec
Initializing nanddump1.bin..
Header is wrong..
Jasper SB
Nand Initialization Finished
 

Martin C

VIP Member
Jan 10, 2004
35,981
0
Scotland, UK
www.team-xecuter.com
Sure - you don't even need to replace the KV if you're getting the CPU key. Early RGX ECC images had a fixed KV but we changed J-Runner to inject your own in the event of you making a mistake and losing your original dump.
 

muffpotter

Junior Member
Sep 21, 2005
18
0
Geezus, that didn't even cross my mind. So I will just correct the ECC of the KV in my stock nand and all will we fine.
I just wonder how it is possible that the original nand has the ECC errors in the KV block since I can boot from it just fine.

Anyways, just to make sure, E 79 doesn't mean the jumper settings should be tweaked but the soldering/wiring is wrong, right?
 

Martin C

VIP Member
Jan 10, 2004
35,981
0
Scotland, UK
www.team-xecuter.com
You don't even need to touch the stock NAND. J-Runner will sort that all for you once you have the CPU key.

Read my sticky on troubleshooting R-JTAG when POST gets past 2E, as it should offer suggestions on things to check.
 

muffpotter

Junior Member
Sep 21, 2005
18
0
I went through my Jtag wiring again and found it ok even with the TDI/TMS resistance, so I decided to create an XeBuild Image with the ECC corrected stock nand binary.
What can I say, it booted just ok into the dash after only a few glitch attempts.
When I did the same with the original stock nand binary (without correcting the KV block ECC) it would give me E 79 all the time.
So this makes me wonder if there might be some other reasons, apart from the JTag wiring, that cause E 79.

Would it be big trouble to have J-Runner read the KV from the stock nand but recalculate the ECC to make sure it is correct?
Or at least to NOT overwrite a modified KV when writing the flash, that would help very much I guess.

I have a feeling that the bad ECC in the KV section of an original nand is there on purpose to make things a little more challenging.

If it wasn't for the sheer luck of my console booting into Xell just once (I still have no clue how that did work) which let me grab the CPU key, I would sit now with a non glitchable console.

Is there anyone else out there with the same issue of an invalid block 0x1 in the stock nand?

Ok ok, I will stop 'ranting' now......

Attached is an image of the xell boot screen where you can see that weird message about the kv and a totally wrong mac-address.

Xell-boot-screen2-nokey-800x600.jpg


Thank you again for listening....
 

Martin C

VIP Member
Jan 10, 2004
35,981
0
Scotland, UK
www.team-xecuter.com
Yeah - it couldn't decrypt the KV (due to a problem with it) and that's what you get.

It wouldn't be an un-glitchable console. Like I said, understanding about Keyvaults, bad block management and how J-Runner deals with BB images wouldn't be an issue for any pro installer. I will remind you that the DemoN is intended for professional installation and that's not restricted to soldering. ANY xell image you build and write will have the same data in it, regardless of where it's written to. Therefore you may find there's actually something quirky with the KV in this console - nothing prevents you from writing another KV from another console in its place and then just using the advanced xebuild option to replace the DVD key.