#464 Unexpected behavior of writing 512 page size NAND with `oob_only` mode

[wuwbobo2021]

As far as I know, the nand write command is handled by handle_nand_write_command in flash/nand/tcl.c, which initializes the input data structure through fileio module and calls nand_write_page which calls nand_write_page_raw under raw access mode (currrently the only available mode for S3C series MPUs), which simply calls nand_page_command before nand_write_data_page, and in nand_page_command there seems no support for writing 512 page size NAND with oob_only mode, while it supports reading with oob_only mode. But it does something without any warning.

Actually, this has caused a strange problem of damaging the first block at the specific write offset.

[wuwbobo2021]

Comparing the Samsung K9F1G08U0D (2048 + 64 page size) datasheet with that of K9F1G08U0C (512 + 16 page size), you can realize the significant difference of spare data handling.

• For the 2048 page size NAND flash, the spare area is selected by the highest column address.

• For the 512 page size NAND, there's no such a bit in the address sequence, but the spare area can be read by the NAND_CMD_READOOB command. The page program command supports loading 512 + 16 bytes at once, writing the page data with OOB, this means the OOB (spare area) cannot be handled alone here.

This probably means this operation cannot be supported for 512 page size devices, and we need something like this to be added in nand_page_command, flash/nand/core.c:

    if (oob_only && NAND_CMD_SEQIN == cmd && nand->page_size <= 512) {
        LOG_ERROR("writing with oob_only option is not supported for NAND flashes with 512 byte pagesize");
        return ERROR_NAND_OPERATION_FAILED;
    }

Still, I might need to figure out why the first block at the specific write offset is damaged in a K9F1G08U0C chip: some garbage data is written into the main area of the first page as well as the spare area, so it's marked bad because of the garbage data in the spare area; the erasure operation returned status 0xC1 which means a failure according to the chip datasheet. Before this failure, I have erased some false bad blocks (produced because of some misoperation of U-boot nand write.yaffs caused by wrong data+oob input format) successfully.