SM Controllers and Different Page Layouts Between Planes

SM Controllers and Different Page Layouts Between Planes

During our research into data recovery methods for devices using Silicon Motion (SM) controllers, we identified an unusual behavior that appears under certain conditions.
The issue involves different page layouts between planes.

Why Does This Happen?

NAND memory frequently contains physical defects—some bytes or columns within a plane may be damaged.

Despite these defects, such NAND chips are still usable because certain controllers are designed to operate even when columns are faulty.
SM controllers are one such family.

SM controllers typically handle bad columns in a straightforward manner: they simply skip the damaged columns, which results in a shifted physical page structure after bad-column removal.


Unusual Behavior: Different Page Layouts

In some devices, removing the bad columns results in different page layouts across planes.
Although the data area size remains identical in all planes, the ECC size may vary.

Example:

Planes 0, 1, 2 → ECC = 118 bytes

Plane 3 → ECC = 116 bytes

Such discrepancies prevent direct multi-plane merging in the Unite element.




Steps Required to Extract the Data
1. Detect ECC and Build Page Layouts Separately for Each Plane

Each plane must be processed independently:

a. identify the ECC region

b. determine the data/ECC boundary

c. define the final page layout for that plane

d. find XOR key for all Planes

This ensures that block-level reconstruction uses the correct, per-plane page structure.





2. Reconstruct Logical Block Order for Each Plane

Once layouts are defined, reconstruct blocks per plane:

a. detect block headers and LBN positions

b. validate block order

c. build a clean logical block sequence

The output should be one logical image per plane, each containing correctly ordered blocks based on its own page layout.
When this is performed in the Block Manager element, the data area of the logical image will be exported in the proper sequence.





3. Determine the Data Allocation Type Between Planes

Open all bitmaps in the XOR elements in sync mode and compare data patterns across planes.






If data patterns and LBNs match:

→ Page-based interleaving
→ Images must be united by pages


Unite by Pages (Page-Based Allocation)

When page layouts differ between planes (e.g., differing ECC sizes), they cannot be unified directly inside the Unite element.
To enable page-level merging, follow this procedure:

Export only the data area for each plane using the Block Manager, as described above.

Verify the prerequisites for page-based merging:

a. all logical images must contain the same set of blocks

b. all logical images must have identical total size

c. Determine the data-area size per physical page:


For page sizes > 16 KB (e.g., 17664, 18432): use 16384 bytes (16 × 1024)

For page sizes > 8 KB (e.g., 8832, 9216): use 8192 bytes (8 × 1024)


d. Merge the images using the data-area size as the interleaving step when uniting images in page mode.






If patterns and LBNs different:

→ Non-page-based allocation
→ Images must be concatenated by full size





Concatenation (No Page-Based Allocation)

If allocation between planes is not page-based:

a. use the Concatenate element

b. join images strictly by their full logical size


Conclusion

SM controllers may generate different page layouts between planes due to their internal bad-column handling mechanisms. Although the data area remains uniform, variations in ECC size require independent processing for each plane.

By detecting ECC separately, reconstructing block order per plane, and exporting only the clean data area before merging, reliable data reconstruction is achievable even in cases with layout inconsistencies. Correctly determining the allocation type—page-based interleaving or full-size concatenation—is essential for accurate final reconstruction.


Thank you for reading! 
Lukasz Pietrzykowski, Rusolut Team

    • Related Articles

    • Silicon Motion(SM) controllers - Data recovery

      We can find plenty of NAND controllers on the market and without any doubt one of the most popular is SiliconMotion.  These controllers found their use in all kinds of flash devices, starting from USB flash drives, SD cards, monolithic devices, and ...

    • 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 ...

    • 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 ...

    • VNR Silicon Motion AI XOR

      When you work with devices based on modern Silicon Motion controllers, it is essential to separate a dump by planes. Before separating the planes, it's necessary to determine how many planes exist per crystal/dump. There are two methods to verify the ...

    • Missing data planes in TSOP48, LGA52, BGA132 and BGA152 Sandisk chips.

      This article shows the way how to extract all data from TSOP48, LGA52, and BGA132/152 Sandisk memory chips when the configuration and dump size are correct, but half of the dump is still empty. Usually, if a NAND memory chip has 2 or 4 crystals, ...