As far as I know, the ARM that nandpro uses has a implementation of xsvf player that relies on buffering the xsvf to the ARM memory... I think the error codes are these (the one you indicate, 0x3, could suggest a wiring issue - but I'm guessing the xsvf is simply too big for the ARMs available memory for this function):

There are plenty of ready made parallel port or usb to jtag adapters that work directly with the xilinx impact programming software, most can be found for around 10-40USD - if you have a parallel port its just a matter of a very few components (resistors, wire, parallel port connector) to make an extremely simple parallel port programmer that can work with impact (programming the .jed directly instead of converting to svf/xsvf), I beleive gligli included a schematic with the original rgh release for it. Until I purchased a buffered one, I was using this schematic to program cpld/fpga via impact. No coding your own program needed at all.

Don't worry about the bad blocks that it showed there too much, it's just reporting the result of reading the block before it attempted to change it - which of course shows you the same result as before - if you were to run it again now with the same image it should only show the two blocks that were bad in your original image. Typically a true bad block should never try to get erased this variation of the tool was meant to help when artificial bad blocks happen, like those that you ran into, and shouldn't be used regularly - the normal rawflash built into current xell will never touch a block that is marked as bad, which is as it should be.

Nothing to do with dash launch at all...

Somewhere in your process one of the tools copied the bad blocks as is from their original location to the remap location, and now you have 0x222 and 0x23e marked as bad, as well as their default remap locations 0x3ff and 0x3fe (which would happen if you just copied the already bad data to those blocks and wrote it without checking.) So in effect, you remapped a bad block, then marked the destination as bad too... my guess is NAND flasher 1.2.0 did this when it tried to remap blocks for you or something similar.

E79 literally means xam.xex is corrupt, so one of those bad blocks or both have xam.xex data in them and it can't find it or is using the data in the bad block because the remap is no good which has the effect of breaking xam.xex so it can't be loaded, which gives you a nifty E79 error screen.

You can do one of two things at this point... you can re-remap to 0x3fd and 0x3fc (by making an image with no remaps at all, then manually moving the two bad blocks to those instead, or by dumping what is currently in the NAND and using THAT to make a new image - use rawflash to write that image) or you can try to clear those 'fake' software marked bad blocks at 0x3FF and 0x3FE. I will PM you a link to a rawflash elf that will attempt to erase bad blocks, and you can choose if you wish to try it or go the other route.

edit:/ forgot to mention, if you try to clear bad blocks by writing the image with the elf, make sure after you write the image that you shut the machine off and then unplug it from the back of the console for 10 or so seconds before trying to boot it.

Once you have the cpu key you can use normal stuff... it's recovering the cpu key first that has always been the problem with these new dashes.

Or... you could just try to find things like (note the post I put there is only 10 days old...  )
http://www.xboxhacker.org/index.php?topic=18145.msg136372#msg136372

or the MUCH older:
http://www.xboxhacker.org/index.php?topic=16108.msg119217#msg119217

Xell shows you the hardware CPU key on jtags. Open flashdmp with a hex editor, the 16 bytes at 0x99AA0 is the CPU key used to build that image.

Yep, you only need a good ground, not two good grounds.

H27UBG8T2ATR is definitely 4G.

I had a similar problem twice, the first time the cause was too long wires to the SD reader (I now use 6 inch), the second time was due to a poor ground to the system clock crystal.

You can get a teensy 2.0+ for around $20 from various suppliers (PJRC, ebay) and use Norway, I've done it with a micropendous (very similar to teensy 2.0+) I got off a ebay seller in my country and it works great albeit slow - and even fits inside the PS3 so it can be left installed. Something like the STM32F4-DISCOVERY board is also dirt cheap and has a NOR/NAND controller built in, but lacks pre-made code to do what you want.

The ft2232hq might be able to do it, have you had a look to see how many IO lines it has available and if they'll be enough for PS3 NOR? I saw a dev board that seems to have 42 pins broken out, plus a few more for ground and such - honestly that is the biggest constraint for NOR is whether you've got the patience to implement NOR through GPIO and you have enough pins on your board broken out to handle it. IIRC I had about 38 or 39 wires to put the teensy on my slim PS3.

Yes, the first 0x100 bytes of FCRT.bin is a digital signature, one we do not have the private keys for meaning we cannot modify the data and sign new data for a console. Having the decrypted data and the way to 1:1 encrypt it again does not mean we can make *new* data for people that lost FCRT - so, keep in mind the data is signed, it cannot be transferred between consoles without resigning, and any changes break the digital signature.

The code there to decrypt and verify the decrypted result, is the same as what xbox does to decrypt and verify it apart from the RSA signature. I am not aware of any flash tool that does this (verify the RSA signature) and have not seen any public flash tool that can decrypt fcrt.bin.

It's too... what?   

The code there uses the same libs IIRC that flash tool does, it's just C and not C++.

Something like this would probably work (I haven't tested this iteration, but I did test a previous one this is based on)... keep in mind this data is also signed to the console.

http://db.tt/qfw5Y0vF
same file as before
ala_PSP_RAW_NAND_0.5fin_p1.zip

If fcrt is good, xebuild will be able to decrypt it and verify it, and will tell you it's good. A corona kv will likely have the flags that say "fcrt is required for this console" (the nofcrt addon patch removes this requirement but does nothing to make retail game disks work on newer drive models which seem to now require fcrt challenge to unlock game disks, the first consoles with fcrt do not seem to have this restriction) and donor fcrt (afaik) simply won't work as the data is paired between the console and drive like the dvd key, as well as signed.

You followed the instructions at this link to the letter?
http://support.xbox.com/en-US/xbox-360/settings-and-initial-setup/image-on-your-tv-is-unclear

For example, if you don't let a wireless controller sync (in this case the top left segment will light solid as it must be controller 1) before holding the buttons it will not read the buttons until you release them and press them again, so let it sync before holding. In fact, I'd suggest testing the reset on the screen that works to make sure you are getting it right before trying it on the projector again. I know the one time I had to do it with a wireless controller, it took me a few tries to get it to work.

Good luck sockdip

http://www.xboxhacker.org/index.php?topic=16926.0
If you want to see a previous discussion on this topic.

If you have a cygnos E and dig around on the cygnos forums a little you'll find some modified CPLD source I posted and other discussion on this subject; basically you can pull a lead off the USB LED to get the glitch chips to enable/disable that way - no relays needed. I can also say demon works well in this regard, though I've not tried any RGH2 things myself besides trinity.

Hrm how best to explain. Really what you are looking for is a corrupt firmware file in the redump of whatever you wrote that would not boot. Testing this on the dump of what would boot isn't going to help much. Only certain corrupt files will cause an explicit Exx error screen, while when others are corrupt or missing you get infinite boot logo or a boot logo that runs for a while then freezes suddenly.

The simple fact is that since 9199 firmware files have grown in size, and now take up more of your flash which is probably why you didn't see this problem in 9199. You keep mentioning that block 351 - what is the contents of it when you redump? If it's not 0x0 filled (especially in byte 0x205) but is also present in the remap area, often the console will ignore the remap and depending where the block is the result is precisely what you are seeing - in this case it's recommended to reflash the entire block with 0x0 filled data, and only that block.

Please run down your process and let us know how you are getting to a non-booting state, it may help someone spot something that is amiss.

Keep in mind, what I said to do was actually binary compare between the file you wrote and the file you read back (without attempting to turn the console on between write and read) not to use any other tools like flash tool or degraded to tell you what is going on.

There is also one other surefire check to do if a soft bad block (a block that went bad after the NAND was produced only gets marked as bad but not restricted unless the software enforces it for erase/write, which none of the SPI programmer software does really) is in question, write an image and without attempting to boot the machine after writing dump it back and do a binary compare to make sure what you wrote is exactly what you dumped. The only exception is factory bad blocks, their contents will always read as 0x0 filled no matter what you try to do to them - any other diffs indicate single or multiple bit errors in a given block and potentially unmarked but unreliable blocks - all it takes is a single bit to be wrong for a xex in flash to be bad and thus unable to load.