On Thu, Sep 12, 2013 at 03:03:16PM +0100, David Woodhouse wrote: > 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. Yes, that was pretty much my understanding of what was going on here - clearly the way the driver is currently figuring out what the commands are isn't good enough. > 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. Right, the specific opcodes do need to variable at least and should be being provided by the driver for the flash - but is the generic format of the commands and requirement to send them abstractable? Given that it's apparently been baked into hardware and based on having a quick scan through drivers/mtd/devices I'd guess so but... > Unless, as I say, I've completely misunderstood what's going on here. > Huang? ...like you say some clarity would be good.
Attachment:
signature.asc
Description: Digital signature
