linux-kernel - Re: [PATCH for 3.7] mtd: nand: fix Samsung SLC NAND identification regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 12 Nov 2012 12:53:44 +0000 (UTC)
From:	Peter Turczak <peter@...czak.de>
To:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH for 3.7] mtd: nand: fix Samsung SLC NAND identification regression

Hi Brian,

> This patch re-introduces a distinction between these old and new Samsung
> NAND by checking that the 6th byte is non-zero, allowing both old and
> new Samsung NAND to be detected properly.
Currently we're observing the same problem with our Samsung K9F2G08U0D nand 
device, but the patch provided does not resolve the issue.

Ours read back {0xec, 0xdc, 0x10, 0x95, 0x54, 0xec, 0xec, 0xdc}. The Samsung 
datasheet 
seems to be consistent with the routine called when neither Samsung or Hynix 
6 byte IDs are detected. 


>From your patch I deduce, maybe one could also check for 0xEC at the 6th byte
in order to find an old ID format?
Or maybe it might help to analyze the 2nd byte, as it is intended to be a
evice code. 
(   0xDC for K9F4G08U0D, 
    0xD3 for K9K8G08U0D,  
    0xDC for K9K8G08U1D 
and 0xD3 for K9WAG08U1D)
Anyway, it leads to a more convoluted code...

I would be very grateful to be hearing from you in this regard.

Best regards,
  Peter


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/