On Thursday 27 August 2009 02:59:34 Hu Mingkai-B21284 wrote: > From: Mike Frysinger [mailto:vap...@gentoo.org] > > On Thursday 27 August 2009 02:27:30 Hu Mingkai-B21284 wrote: > > > > but what if you dont know the length of the transaction ahead of > > > > time ? if you look at the spi flash framework, it'll write a few > > > > bytes (like the opcode to read the status > > > > register) and then it'll just keep reading 1 byte at a time (polling > > > > the status register). there is no way of knowing the length ahead > > > > of time. most of the SPI code in u-boot operates this way. > > > > > > So the driver use the length passed by SPI flash read function. > > > If the length is greater than the max value that is limited by the > > > transaction length register's bitfiled, the driver couldn't read > > > anything. > > > > the length used by the first read covers just the length of > > the opcode, not any of the data returned by the part > > > > as long as your driver rejects all of these things, it'll be > > detected at runtime and it should be fine to merge -mike > > So the driver combine the opcode length and the data length together, > then pass to spi_xfer(for eSPI) . When return the read results, skip the > first opcode length bytes.
you dont get it ... there is no data length. the code does: spi_write(~3 bytes for opcode, BEGIN flag); while (1) { spi_read(read 1 data byte); check_result(); } end_spi_transaction(); there is no "data length" which means your controller cannot support the SPI flash framework -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot