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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 6 Jan 2016 14:23:40 +0800
From:	Jisheng Zhang <jszhang@...vell.com>
To:	Khoa Dang Pham <kpham@....com>
CC:	Mark Brown <broonie@...nel.org>, <linux-spi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [RFC] spi: dw: support setting tmode dynamically

Dear Khoa, Mark,

On Wed, 6 Jan 2016 08:45:38 +0700 Khoa Dang Pham wrote:

> Hi Mark,
> 
> May I provide a bit more info about the "EEPROM read" on this controller?
> 
> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
> by Synopsys, the EEPROM read is:
> 
> "When TMOD = 2‘b11, the transmit data is used to transmit an opcode and/or
> an address to the EEPROM
> device. Typically this takes three data frames (8-bit opcode followed by
> 8-bit upper address and 8-bit lower
> address). During the transmission of the opcode and address, no data is
> captured by the receive logic (as
> long as the DW_apb_ssi master is transmitting data on its txd line, data on
> the rxd line is ignored). The
> DW_apb_ssi master continues to transmit data until the transmit FIFO is
> empty. Therefore, you should
> ONLY have enough data frames in the transmit FIFO to supply the opcode and
> address to the EEPROM. If
> more data frames are in the transmit FIFO than are needed, then read data
> is lost.
> When the transmit FIFO becomes empty (all control information has been
> sent), data on the receive line
> (rxd) is valid and is stored in the receive FIFO; the txd output is held at
> a constant logic level. The serial
> transfer continues until the number of data frames received by the
> DW_apb_ssi master matches the value of
> the NDF field in the CTRLR1 register + 1."

I tried the following combinations:

1. "Transmit only" to send opcode and address, "Receive only" to read the
response

2. "Transmit and Receive" to send opcode and address, "Receive only" to read
the response

3. "Transmit and Receive" to send opcode and address, "Transmit and Receive"
to read the response

4. "Transmit and Receive" only to send opcode and address

None of the above succeed. I only succeed when using

5. EEPROM Read to send opcode, address. I can get the correct NOR flash
content from the response.

Thanks,
Jisheng

> 
> Regards,
> Khoa Pham
> 
> On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown  wrote:
> 
> > On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:  
> > > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:  
> > > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:  
> >  
> > > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is  
> > NULL, but we  
> > > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution  
> > is to add and  
> > > > > export one functions to set the tmode, then the nor flash driver  
> > call it  
> > > > > before reading and set back to SPI_TMOD_TR after done.  
> >  
> > > > What does this mean - what is TMOD and why do we need to set it to read
> > > > NOR flash?  I've no information on this controller...  
> >  
> > > TMOD is one field of DW_SPI_CTRL0. Its available value could be:  
> >  
> > > 0: Transmit and Receive
> > > 1: Transmit only
> > > 2: Receive only
> > > 3: EEPROM Read  
> >  
> > > If the one spi nor flash is connected to the SPI host, so far I can only  
> > succeed  
> > > to read the nor flash content after setting the TMOD field as 3.  
> >
> > Why?  What does this mean in practical terms at the hardware level, what
> > is "EEPROM read"?  It sounds like there's some bigger issue here.
> >  
> 

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ