[PATCH] u-boot from nand and skip bad block

michael trimarchi at gandalf.sssup.it
Sun Apr 13 22:50:52 CEST 2008


For s3c2410 the code use the 0x50 command for read the extra byte and
the 5 byte is the code to read (0xf mask is for 16 byte of extra byte)

For s3c2442 the read is on the 2048 as reported by documentation:
"All device locations are erased(FFh) except locations where the initial 
invalid block(s)
information is written prior to shipping. The
initial invalid block(s) status is defined by the 1st byte in the spare 
Samsung makes sure that either the 1st or 2nd page of every
initial invalid block has non-FFh data at the column address of 2048."
It is correct to use the page size. If you see at the code for the 
s3c2410 the command
is different. I think that the test is corrent. So the test is done on 
first page (addr)
and second page (addr + PAGE_SIZE)

Regards Michael

Andy Green wrote:
> Hash: SHA1
> Somebody in the thread at some point said:
> | Hi,
> |
> | I have rebased the patch to the latest git.
> Thanks a lot, the patch went in easily and was signed-off-by too :-)  So
> I stuck it on the andy branch.
> Reading through the patch, if I understood it it will only do something
> on GTA01 which has CONFIG_S3C2410 defined.  GTA02 has CONFIG_S3C2442 set
> instead... in cpu/arm920t/s3c24x0/nand_read.c:
> #if defined(CONFIG_S3C2410)
> /* configuration for 2410 with 512byte sized flash */
> #define NAND_PAGE_SIZE        512
> #define BAD_BLOCK_OFFSET    5    <===== patched this
> #define NAND_BLOCK_MASK        (NAND_PAGE_SIZE - 1)
> #define NAND_BLOCK_SIZE        0x4000
> #else
> /* configuration for 2440 with 2048byte sized flash */
> #define NAND_5_ADDR_CYCLE
> #define NAND_PAGE_SIZE        2048
> #define BAD_BLOCK_OFFSET    NAND_PAGE_SIZE  <=== not this.. is ok?
> #define    NAND_BLOCK_MASK        (NAND_PAGE_SIZE - 1)
> #define NAND_BLOCK_SIZE        (NAND_PAGE_SIZE * 64)
> #endif
> On GTA02, we get BAD_BLOCK_OFFSET ---> NAND_PAGE_SIZE... is that OK or
> should it too be changed like BAD_BLOCK_OFFSET went to 5 from 517 in the
> CONFIG_S3C2410 case?  Just curious about if CONFIG_S3C2442 / GTA02 has
> whatever problem it is we fix here for CONFIG_S3C2410 / GTA01 as well.
> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> gnAAn0WX+Aix/w5ODJ6jdufzjbyOMwvt
> =CAA8

More information about the openmoko-kernel mailing list