[EXT] Re: Issues with SPI NOR flash

[Aaron Williams]

Hi,

I forgot to add that the host does use 4 byte mode, but with the reset this 
works.

-Aaron

On Tuesday, February 12, 2019 12:18:45 AM PST Cédric Le Goater wrote:
> External Email
> 
> ----------------------------------------------------------------------
> Hello,
> 
> On 2/11/19 11:57 PM, Andrew Jeffery wrote:
> > Hi Aaron,
> > 
> > On Tue, 8 Jan 2019, at 21:52, Aaron Williams wrote:
> >> Hi all,
> >> 
> >> I'm running into a problem with the SPI NOR connected to our host
> >> processor. We're using a Macronix MX25L25645GMI-08G connected to the
> >> spi1 device on an AST2500. This device is muxed between our host
> >> processor and the BMC. When our host processor is powered off, the BMC
> >> has exclusive access to it.
> yes but there could be different (incompatible) states in the SPI controller
> drivers on each kernel (BMC, Host) and in the flash module as well. That is
> why having only one side doing the control is usually preferred.
> 
> >> Anyway, the behavior is that I can read the SPI NOR without any
> >> difficulty,
> >> however, when I write to it the SPI nor appears to be filled with
> >> garbage.
> >> I had to guess, I'd guess that the SPI driver is not waiting for the SPI
> >> NOR to complete the write operation before moving to the next block.
> 
> When the host is powered off, you seem to be able to read the PNOR
> correctly, (I assume you did the write from the host side then) but the
> first write from the BMC trashes the contents ?
> 
> >> Here is the relevant section from our device tree:
> >> 
> >> &spi1 {
> >> 
> >> 	status = "okay";
> >> 	flash at 0 {
> >> 	
> >> 		status = "okay";
> >> 		compatible = "jedec,spi-nor", "spi-nor";
> >> 		label = "host";
> >> 		m25p,fast-read;
> >> 		spi-tx-bus-width = <1>;
> >> 		spi-rx-bus-width = <1>;
> >> 		spi-max-frequency = <50000000>;
> >> 		partitions {
> >> 		
> >> 			compatible = "fixed-partitions";
> >> 			#address-cells = <1>;
> >> 			#size-cells = <1>;
> >> 			
> >> 			bootloader at 0 {
> >> 			
> >> 				reg = <0x0 0x1000000>;
> >> 				label = "host-
> >> 
> >> bootloader";
> >> 
> >> 			};
> >> 			kernel at 1000000 {
> >> 			
> >> 				reg = <0x1000000
> >> 
> >> 0x1000000>;
> >> 
> >> 				label = "host-kernel";
> >> 			
> >> 			};
> >> 		
> >> 		};
> >> 	
> >> 	};
> >> 
> >> };
> >> 
> >> Note that our host is also running 4.19 and has no trouble writing to the
> >> SPI NOR. The corruption seems worse when flashcp is used compared to
> >> just cp. I noticed that flashcp writes in 4K blocks. The Macronix device
> >> has a 256 byte page buffer. I have tried slowing down the bus to 5MHz
> >> and that made no difference. Note that we are currently using single bit
> >> mode for both the host and BMC processors for this flash, though we plan
> >> to move to move to QPI on the host processor later.
> 
> What about 4BYTE mode ? have you checked in which mode the flash device is
> left by the host ? That could be a problem.
> 
> C.
> 
> >> Before the write operation the host processor has not had any access to
> >> the
> >> SPI NOR. The host is powered down and the BMC is rebooted to force a
> >> clean
> >> state.
> > 
> > Did you find the problem? I've added Cédric to Cc in case you haven't - he
> > should be able to answer questions about the flash stack.
> > Andrew

-- 
Aaron Williams
Senior Software Engineer
Marvell Semiconductor, Inc.
(408) 943-7198	(510) 789-8988 (cell)