On Thu, 2013-09-12 at 14:43 +0100, Mark Brown wrote: > > > I only know what's in the patch that you have also received, but it > > seems to be a table of commands. To send a given command to the flash, > > you write the actual command to the some slot in the LUT, then 'trigger' > > it by writing its index to another register. > > OK, so the LUT itself isn't a generic mtd thing, though the commands > it's apparently sending are? Kind of. Imagine you have a controller with a set of SRAM buffers for transmit data. One might normally imagine that when you get a request to make a transaction, you'd load the data-to-be-sent into one of the buffers, then trigger a "send from buffer <X>". Not so in this case. The controller driver appears "know", in advance, what commands are going to be sent. It preloads its buffers (the LUT) with what it *expects* us to send, and when we make a request it'll just trigger a send from the appropriate buffer. And it will crap itself if we actually try to send anything *different*. Or so I understand it. So to go back to your question: the commands that it "knows" we are going to send are indeed specific to (one particular type of) SPI NOR flash. But there's nothing on the MTD side which justifies that assumption. Even if you use a different type of SPI NOR flash which uses different opcodes for its commands, this broken scheme will fall over. Unless, as I say, I've completely misunderstood what's going on here. Huang? -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
