http://gbatemp.net/threads/nand-flash-dump-3ds-xl.350668/page-7
Post #126
There is one, i didn't have patience to find the other trough
http://gbatemp.net/threads/nand-flash-dump-3ds-xl.350668/page-7
Post #126
There is one, i didn't have patience to find the other trough
http://forum.gsmhosting.com/vbb/f83/emmc-pinout-1641243/#post9356818
the guy re-used e-MMC DAT0-7 and inserted a micro sd adapter instead using DAT0-3.
I'm seriously tempted to remove e-mmc nand and put a micro SD adapter instead. NAND testing would be much funnier this way
the guy re-used e-MMC DAT0-7 and inserted a micro sd adapter instead using DAT0-3.
I'm seriously tempted to remove e-mmc nand and put a micro SD adapter instead. NAND testing would be much funnier this way
yeah i thought that guy just got unlucky with soldering or something? who knows, but we can't say for certain that writing to the flash too much bricks your 3ds. (unless their is enough evidence)
vini9157, can you find the other one? when you have the patience
i tried to see but i couldn't find it, maybe i missed it
likely just a solder fuck up. people really shouldn't open their electronics and solder shit if they don't have the skills.
not that this is a hard solder job... especially on a 3DS XL. i did it half asleep at 2 am at night almost in the dark...
that rewriting the nand would damage it is of course ridiculous, it is rewritten by the 3DS itself continuously throughout using it!
the toshiba nand is likely rated for usage in the order of millions of rewrite cycles...
not that this is a hard solder job... especially on a 3DS XL. i did it half asleep at 2 am at night almost in the dark...
that rewriting the nand would damage it is of course ridiculous, it is rewritten by the 3DS itself continuously throughout using it!
the toshiba nand is likely rated for usage in the order of millions of rewrite cycles...
yeah i thought that guy just got unlucky with soldering or something? who knows, but we can't say for certain that writing to the flash too much bricks your 3ds. (unless their is enough evidence)
vini9157, can you find the other one? when you have the patience
sy but its 14 pages
don't worry
yeah like, i was under the impression accessing nand is what you are limited to do if something/most things are bricked. like ps3, you need to use a flasher. kindle, you need to use a flasher, i guess it is the same for many things, you just need to have access to the nand, and as long as you do that you are fine.
if we were dumping/writing the kernel from gateway (imagine), then yes, if it fails and it bricks, you are stuck.
but since we actually have access to the hardware, we are fine. (unless there is proof we are not)
well, the actual running kernel is just in-memory bits, ultimately loaded from the nand in the first place, so it's hard to brick that way too. only real way to brick the 3ds once you have a 3ds flash with valid nand dumps as back is to somehow screw up the actual bootloader I suppose. not sure if that is even possible.
I was thinking of wiring a micro USB port into one of the corners currently used for a strap. Then using some epoxy to hold it in place.
Then I would use a micro USB sync cable to connect it to an SD adapter, to my PC. Any thoughts?
Then I would use a micro USB sync cable to connect it to an SD adapter, to my PC. Any thoughts?
Does soldering the points to the built in SD port work? I haven't seen any details on this method.
I was thinking of wiring a micro USB port into one of the corners currently used for a strap. Then using some epoxy to hold it in place.
Then I would use a micro USB sync cable to connect it to an SD adapter, to my PC. Any thoughts?
Check post #67: http://gbatemp.net/threads/nand-flash-dump-3ds-xl.350668/page-4
remember software routines have some sort of anti-brick routines. (crc checks, if true one write, next page, if false, skip and mirror faulty page).
Compared to writing a huge block of data at once 1:1, that fails suddenly can corrupt the whole crc'd page (n:1), thus bricked that area onwards (bad crc).
I think the point is, if there is a bad block, even with a valid dump, you will just keep trying to write to that, and screwing up the whole thing as no remapping takes place. Where as with software (3ds updating), the bad block would be remapped to the reserved area and all would be fine. Least that's how I read it.
Same used to happen with the 360, before the software that flashed a hacked nand image was updated to handle it automatically, you had to remap bad blocks manually before flashing. If you didn't and the block was in a critical area=brick.
You still have to remap bad blocks in the image now,when you are writing via hardware flasher, although the software that prepares the image remaps the blocks for you these days.
Same used to happen with the 360, before the software that flashed a hacked nand image was updated to handle it automatically, you had to remap bad blocks manually before flashing. If you didn't and the block was in a critical area=brick.
You still have to remap bad blocks in the image now,when you are writing via hardware flasher, although the software that prepares the image remaps the blocks for you these days.
Exactly! and the moment you rewrite any NAND memory,(n address: 1 block -> n pages). To reach that page you have an address, that's crc'ed as whole block, then later as unique crc page. A valid crc means the existing data inside is either valid, or the physical block is ready to be written.
When a bad process (skips crc handling, electrical irrecoverable wear of cells, any other) mess up the current crc (block, page), you must try to read the block content first if possible, if not possible means the segment is dead hence, must be re-assigned, so when dereferencing the actual block, it's somewhere else. (unused area that's not available to user mode storage).
Now, as for the 3DS, the target NAND (SPI-mode micro controller), is the only one taking all these labors alone, as SD USB adaptors (with their own rules) vary, hence checkings could be from very nice, to a shoot in the dark. (didn't an user here reported his SD USB didn't write NAND, but could read?)
So yes, writing directly right now, depends entirely on the 3DS's NAND micro controller. A small fucked up bit, and a poorly handled "healthy" recovery sector, dirty line (bad solder), small electrical noise, etc could brick your NAND.
ah this really makes sense, thanks
although, are we sure this is how the 3ds does it? crc-ing the blocks etc? or is that done for basically every device?
but permanently brick? or just that you cannot flash back the dump it 'needs' until you fix the blocks etc, which we are not able to do yet.
so this will only happen if you make a dump, and after that, one of your blocks goes bad, right?
how often does a block go bad? can it ever become 'good' again?
To my knowledge, an emmc nand is having it's own controller cpu on board, just like a sd card is having one. If a block became bad, that controller will map it to another location of the internal flash memory area. For the host, the whole memory area still shows up as one continous storage block without bad blocks. The total size of the storage area can become a little smaller, but usually some spare blocks are set aside to replace defective ones. A normal nand chip like the one used in the wii behaves differently. There it's the firmware that should keep track of the defective blocks and avoid them.
Pc harddisks nowadays use the same technique. I remember the first xt harddisk that had a list with all the defective sectors. You had to enter those in the low level format software settings. Nowadays, a harddisk appears as a perfect device as bad sectors are also automatically remapped to other areas of the disk surface.
So basically, you shouldn't worry about your backup not fitting anymore due to new bad blocks on the eMMC nand. There won't be any.
Pc harddisks nowadays use the same technique. I remember the first xt harddisk that had a list with all the defective sectors. You had to enter those in the low level format software settings. Nowadays, a harddisk appears as a perfect device as bad sectors are also automatically remapped to other areas of the disk surface.
So basically, you shouldn't worry about your backup not fitting anymore due to new bad blocks on the eMMC nand. There won't be any.
yup. same with new 4gb xbox'es. all remapping handled by controller. you can't see any bad blocks in your dump.
in other words: if you dump NAND chip with programmer and same NAND using emmc controller - they will look differently. size will be different also. emmc controller hides space reserved and used for bad blocks remapping and outputs data "virtually" as perfect, it's not RAW dumps.
forgot to mention that controller also protects NAND chip as well and won't let you brick it during bad writing
Similar threads
- No one is chatting at the moment.
-
@
CameronCataclysm:
Why no blog posts about Nitendont going after Garry's Mod repos that have been up for a decade or 2? -
-
-
@
Xdqwerty:
Is it safe to update a modded ps3?
Can I play online in pirated games? (with ps3hen either enabled or not) -
-
-
-
-
-
@
Xdqwerty:
@salazarcosplay, I used apollo save tool to activate my ps3 offline so i could play a game that wasnt working
-
S @ salazarcosplay:from what I understood. you load up the piratged game. you the clear the syscalls, then you play
-
-
-
-
-
-
-
-
-
-
-
-
-
-
