Different Page Layouts in Devices with CBM Controllers
It is a rare situation, but sometimes in CBM-controlled devices with bad columns, we encounter a problem where the ECC does not fit perfectly.
The best way to explain this issue is through a real-world case.
In the example below, the chip has 4 physical planes, and the bad columns were removed correctly.
The best way to explain this issue is through a real-world case.
In the example below, the chip has 4 physical planes, and the bad columns were removed correctly.
However, during the ECC search process, VNR detects codewords with different ECC sizes—one being 110 bytes and another 116 bytes.
To prove that both ECC sizes are valid, we can see that for blocks where the 116-byte ECC doesn't fit, the 110-byte ECC fits correctly.
1. Separation of Planes
The first step to solving the issue is to separate the planes into offset elements.
This is easy to do in VNR using the "Divide" tool found in the toolbar under the offsets section.
In this tool, you simply need to specify how many planes are in the NAND.
In our case, there are 4 planes (as found in the BCR element), so we divide accordingly.
The first step to solving the issue is to separate the planes into offset elements.
This is easy to do in VNR using the "Divide" tool found in the toolbar under the offsets section.
In this tool, you simply need to specify how many planes are in the NAND.
In our case, there are 4 planes (as found in the BCR element), so we divide accordingly.
After using the divide tool, we get 4 offset elements with separated planes.
To make things more clear, we can assign custom names to each plane.
2. Custom ECC
Once the planes are separated, the next step is to find the correct ECC for each one.
ECC analysis shows a high match rate for one plane, and one ECC configuration fits all data blocks in that plane.
3. Custom Page Layout
The third step is to determine the custom page layout for each plane.
As shown, two planes have codewords with a 116-byte ECC, and the other two with a 110-byte ECC.
The data area and spare area (SA) sizes remain the same across all planes.
The third step is to determine the custom page layout for each plane.
As shown, two planes have codewords with a 116-byte ECC, and the other two with a 110-byte ECC.
The data area and spare area (SA) sizes remain the same across all planes.
4. XOR Detection
Once each plane has a correctly determined page layout, the fourth step is XOR detection.
CBM controllers generally come in two variants:
One that uses only static XOR
One that uses both static and dynamic XOR
In both cases, static XOR is needed first. To find it, we use the XOR Analyzer.
Once each plane has a correctly determined page layout, the fourth step is XOR detection.
CBM controllers generally come in two variants:
One that uses only static XOR
One that uses both static and dynamic XOR
In both cases, static XOR is needed first. To find it, we use the XOR Analyzer.
Even if ECC sizes differ, the number of data areas per page remains consistent across planes.
For pages around 8–9KB, there are 8 data areas of 1024 bytes each.
For pages around 16–18KB, there are 16 such areas.
So with CBM controllers, it’s possible to copy the XOR element and apply it across all planes.
A critical point is that the page layouts differ between the planes.
To match the XOR to the layout, click the bulb icon after connecting the XOR.
This will auto-adjust the XOR to the custom page layout.
5. Page Allocation
In rare cases, CBM controllers use multi-plane page allocation.
This means data is saved simultaneously into two or four planes.
To check for this, open all XOR or dynamic XOR elements at the same page address.
Then compare the data blocks.
Between planes with allocation, the data patterns will look similar.
In rare cases, CBM controllers use multi-plane page allocation.
This means data is saved simultaneously into two or four planes.
To check for this, open all XOR or dynamic XOR elements at the same page address.
Then compare the data blocks.
Between planes with allocation, the data patterns will look similar.
As shown, planes 0 and 1 have similar patterns, and planes 2 and 3 also match each other (but differ from planes 0 and 1).
This indicates that data was allocated between planes 0–1 and planes 2–3.
To reconstruct the allocation—even with different page layouts—we focus only on the data area.
So the next step is to extract the data areas from each plane.
Then, connect the elements.
Where page allocation is detected, unite the data areas by page size:
If the page is 8–9KB: unite by 8192 bytes (8 × 1024)
If the page is 16–18KB: unite by 16384 bytes (16 × 1024)
In our case, the page size is 9216 bytes, so the data areas from planes 0 and 1 are united using 8192 bytes, and the same goes for planes 2 and 3.
Then merge both unified elements by dump size:
(If data differs between planes, it may be necessary to unite all data areas by dump size.)
6. Data Scan
CBM controllers do not use Logical Block Numbers (LBN), so the data appears mixed.
For such cases, we use the File Assembler tool.
Because the block size cannot be automatically determined, use the "Arranged blocks" option for scanning.
Then start the scan and extract the data:
Conclusions:
Devices with CBM controllers can occasionally use different page layouts across planes, particularly when bad columns are present.
This can result in different ECC sizes (e.g., 110 vs. 116 bytes) even within the same chip.
In such cases:
Separate planes using the Divide tool.
Identify the correct ECC for each plane individually.
Create custom page layouts to match each ECC structure.
Apply XOR appropriately—adjusting it to match page layout differences.
Rebuild page allocation, focusing only on the data area and matching by correct byte sizes.
Use the File Assembler with "Arranged blocks" for effective data recovery.
Understanding and adapting to these layout and ECC differences is crucial for successful data recovery from CBM-based NAND devices.
Related Articles
Xored Bad Columns in SM2685 and Some SM Monolithic Devices
In most cases, Silicon Motion (SM) controllers with NAND memory and bad columns are relatively simple to handle. The typical steps - dividing planes, removing bad columns for each plane, and generating a custom XOR - are the same and are described in ...NAND Bad Columns. Bad Column Remover
Each time during the chip-off data recovery, after the physical image extraction, and before any further step, it's necessary to check the quality of the dump. Due that memory chips are being read physically, the extracted dump may contain defects. ...AU Monolith Devices with Bad Pages
In the market for USB flash drives, many monolithic devices can be found. Often, these devices contain Alcor Micro (AU) controllers. While most of them function in a standard way, some exhibit unique characteristics. It is possible applied XOR, bit ...NAND Bad Columns analysis and removal
Every crystal of modern NAND chip consists of several planes. Typically, it consists of 2 or 4 planes. The plane consists of an array of memory cells grouped into pages and blocks. Planes are connected so that Plane 0 is composed of even physical ...Chipsbank(CBM) Adaptive XOR
Majority of NAND controllers which we can find in removable flash devices are using simple static XOR keys. Except the controllers which are using dynamic XOR keys there are also Chipsbank controllers which are using sophisticated adaptive scrambling ...