- 精华
- 0
- 帖子
- 14
- 威望
- 0 点
- 积分
- 14 点
- 种子
- 0 点
- 注册时间
- 2012-7-16
- 最后登录
- 2014-8-21
|
NAND:Bad Blocks
Contents [hide]
1 What is a BLOCK?
2 What is a BAD BLOCK?
3 How to determine BAD BLOCKS?
4 What happens when a BAD BLOCK develops?
5 How does the Reserve Block Method work?
6 XBOX 16MB NAND BLOCK Management
7 When I read my nand I have Badblocks where is that data stored?
8 How would I remap the BadBlocks in the diagram with nandpro?
9 If using XeLLous to flash do I need to remap Badblocks?
10 I have a Badblock between blocks 0x000 and 0x050, and can’t boot into Xell (free60 version).
11 XBOX 256/512MB NAND BLOCK Management
12 Understanding 256/512 MB memory map, and Nandpro’s translation:
13 When I read my nand I have Badblocks where is that data stored?
14 How would I remap the BadBlocks in the diagram with nandpro?
15 If using XeLLous to flash do I need to remap Badblocks?
16 I have a Badblock between blocks 0x000 and 0x050, and can’t boot into Xell (free60 version).
What is a BLOCK?
A block is the smallest logically addressable unit of data that a specified device can transfer in an input/output operation. For XBOX 360s that is either 16KB or 132KB.
What is a BAD BLOCK?
Bad Blocks are blocks that contain one or more invalid bits whose reliability is not guaranteed. Bad Blocks may be present when the device is shipped, or may develop during the lifetime of the device.
How to determine BAD BLOCKS?
In one block there are n Pages, all have a fixed size of 528 Bytes (nomatter if the Block is 16K or 128K). Every Page has 16 Byte big ECC data at its end. The block itself does not have ECC data, only the pages have! In theory the whole block gets filled with zeros if its bad, practicly it's not like that. So, if the first 12 Bytes of the page's ECC data is nulled, the page is marked bad, so the whole block is aswell. The remaining 4 Bytes of the ECC is the CRC Data. If the first 12 Bytes of ECC is 0xFF the page has no data (empty, but NOT faulty) and if it hold anything else than 0x00 or 0xFF then the page is filled with data.
What happens when a BAD BLOCK develops?
There are two methods to replace the block.
1. Skip Block Method
2. Reserve Block Method
How does the Reserve Block Method work?
Blocks are not skipped but rather they are re-directed to a Reserved Block Area used specifically for Bad Block replacement. The Reserved Block Area also stores/saves the Bad Block Table that keeps track of the re-mapped “developed Bad Blocks”. Which method does the XBOX employ?
Short answer both. In 16MB nands the XBOX exclusively uses the Reserve Block Method, while in 256MB or 512MB nands it uses both. The MU area of the nand uses the Skip Block Method, while the area where the dash and kernel are stored uses the Reserve Block Method.
XBOX 16MB NAND BLOCK Management
If you noticed in the memory table above any Badblocks encountered are consecutively moved to the Reserved BadBlock Area. The first Bad Block(0x168) is moved to Block 0x3FF in the reserved area, the next(0x1F6) is moved to 0X3FE, and it continues until all Bad Blocks have been remapped.
When I read my nand I have Badblocks where is that data stored?
When reading your nand any Badblocks would have already been remapped to the reserve area. This is important to keep in mind, specifically when you encounter Badblocks where crucial data is kept such as blocks 0x001(Key Vault), 0x3DE(First Config Block), and 0x3DF(Second Config Block).
How would I remap the BadBlocks in the diagram with nandpro?
Assuming your attempting to flash the latest release of XBReboot named as ‘xbr.bin’. And have made a full-backup and have already injected your Key Vault and Configuration Blocks into ‘xbr.bin’. The commands would be as follow:
nandpro xbr.bin: -r16 badblock168.bin 168 1
nandpro xbr.bin: -w16 badblock168.bin 3FF 1
nandpro xbr.bin: -r16 badblock1F6.bin 1F6 1
nandpro xbr.bin: -w16 badblock1F6.bin 3FE 1
nandpro xbr.bin: -r16 badblock23A.bin 23A 1
nandpro xbr.bin: -w16 badblock23A.bin 3FD 1
nandpro xbr.bin: -r16 badblock308.bin 308 1
nandpro xbr.bin: -w16 badblock308.bin 3FC 1
If using XeLLous to flash do I need to remap Badblocks?
According to the XeLLous release notes no, it is suppose to be one of the main features of the update. That is not to say bugs might not be encountered. If you encounter suspicious issues, and believe it might be related to a bad flash, then I recommend flashing manually with nandpro or using trancy’s XBR-Flash for Linux.
I have a Badblock between blocks 0x000 and 0x050, and can’t boot into Xell (free60 version).
First of all ensure your using the free60 version of Xell. Next you will need to backup the location of the remapped BadBlocks like so (Remeber your first Badblock always goes to 3FF, and each following Badblock gets remapped as illustrated in the diagram):
nandpro lpt: -r16 backup3FF.bin 3FF 1
Assuming your first Badblock was at 0x010, you will need to remap the free60 Xell data that was intended to be stored in that block. Like this.
nandpro xell.bin: -r16 xell10.bin 10 1
nandpro lpt: -w16 xell10.bin 3FF 1
Lastly the bad block needs to erased to prevent any corruption:
nandpro lpt: -e16 10 1
XBOX 256/512MB NAND BLOCK Management
Understanding 256/512 MB memory map, and Nandpro’s translation:
The block size in 256/512 Nands is 132 KB (135168 Bytes). This is a little different then how Nandpro references and addresses blocks. No matter the Block size of your nand nandpro uses a block size of 16 KB that means that for every Badblock in the 256/512 MB nandpro will report 8 consecutive errors.
If you noticed in the memory table above any Badblocks encountered are consecutively moved to the Reserved BadBlock Area. The first Badblock (0x0F8) is moved to Block 0xFF8 (16 KB) or Block 0x1FF (132 KB) in the reserved area, any consecutive Badblocks would of been moved to blocks 0xFF0 (16 KB) or Block 0x1FE (132 KB) and so forth.
When I read my nand I have Badblocks where is that data stored?
When reading your nand any Badblocks would have already been remapped to the reserve area. This is important to keep in mind, specifically when you encounter Badblocks where crucial data is kept such as blocks 0x001(Key Vault), 0xEF7(Config Block),.
How would I remap the BadBlocks in the diagram with nandpro?
Assuming your attempting to flash the latest release of XBReboot named as ‘xbr.bin’. And have made a full-backup and have already injected your Key Vault and Configuration Blocks into ‘xbr.bin’. The commands would be as follow:
nandpro xbr.bin: -r16 badblockF8.bin F8 8
nandpro xbr.bin: -w16 badblockF8.bin FF8 8
Is 8 correct? Yes remember nandpro reference blocks in sizes of 16 KB, but 256/512 MB have a block size of 132 KB. 132/16 is equal to 8, that why you need to use 8.
If using XeLLous to flash do I need to remap Badblocks?
According to the XeLLous release notes no, it is suppose to be one of the main features of the update. That is not to say bugs might not be encountered. If you encounter suspicious issues, and believe it might be related to a bad flash, then I recommend flashing manually with nandpro or using trancy’s XBR-Flash for Linux.
I have a Badblock between blocks 0x000 and 0x050, and can’t boot into Xell (free60 version).
First of all ensure your using the free60 version of Xell. Next you will need to backup the location of the remapped BadBlocks like so (Remeber your first Badblock always goes to 0xFF8, and each following Badblock gets remapped to the spare):
nandpro lpt: -r256 backupFF8.bin FF8 8
Assuming your first Badblock was at 0x010 followed by seven more errors, you will need to remap the free60 Xell data that was intended to be stored in that block. Like this.
nandpro xell.bin: -r16 xell10.bin 10 8
nandpro lpt: -w16 xell10.bin FF8 8
Lastly the bad block needs to erased to prevent any corruption:
nandpro lpt: -e16 10 1 |
|
川公网安备 51019002005286号
楼主
发表于 2012-10-6 14:40 · 山西
