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
| ||
|
Date: Thu, 29 Oct 2015 18:34:21 +0100 From: Boris Brezillon <boris.brezillon@...e-electrons.com> To: Marek Vasut <marex@...x.de> Cc: Robert Jarzmik <robert.jarzmik@...e.fr>, Brian Norris <computersforpeace@...il.com>, linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org, Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>, Scott Wood <scottwood@...escale.com>, Josh Wu <josh.wu@...el.com>, Kyungmin Park <kyungmin.park@...sung.com>, Han Xu <han.xu@...escale.com>, Huang Shijie <shijie.huang@....com> Subject: Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node On Thu, 29 Oct 2015 18:23:47 +0100 Marek Vasut <marex@...x.de> wrote: > On Thursday, October 29, 2015 at 08:24:48 AM, Boris Brezillon wrote: > > Hi Robert, > > Hi! > > > On Thu, 29 Oct 2015 07:32:33 +0100 > > > > Robert Jarzmik <robert.jarzmik@...e.fr> wrote: > > > Marek Vasut <marex@...x.de> writes: > > > >> Isn't there the case of a single NAND controller with 2 identical > > > >> chips, each a 8 bit NAND chip, and the controller aggregating them to > > > >> offer the OS a single 16-bit NAND chip ? > > > > Honestly, I don't know how this can possibly work, do you have a real > > example of that use case. > > > > Here are a few reasons making it impossible: > > > > 1/ NAND are accessed using specific command sequences, and those > > commands and addresses cycles are sent on through the data bus (AFAIR > > only the lower 8bits of a 16bits bus are used for those > > command/address cycles), so even if you connect the CLE/ALE/CS/RB pins > > on both chips, the one connected on the MSB side of the data bus will > > just receive garbage during the command/address sequences, and your > > program/read operations won't work > > Unless you duplicate the command to both MSB and LSB. Except it's now how devices supporting 16 bits data bus are supposed to work, which means your NAND controller will probably not be able to send the command/address value on the higher 8 bits... > > > 2/ NAND chips can have bad blocks, so even if you were able to address > > 2 chips (which according to #1 is impossible), you might try to write > > on a bad block on the chip connected on the MSB side of the data bus. > > This one is a valid problem. The other valid issue here is where the > command might fail on one chip and pass on the other. > > > 3/ There probably are plenty of other reasons why this is not > > possible ;-). > > It's possible, implementable, but a really bad idea. Possible and implementable, maybe with an adapted software stack and a customized NAND controller. I know you're working on emulating flash devices using FPGA, so the next step is to create a new NAND controller IP supporting that kind of stuff and adding support for this feature to the NAND framework ;-). Anyway, it"s definitely a bad idea. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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/
Powered by blists - more mailing lists