[EXT] Re: Issues with SPI NOR flash

[Aaron Williams]

Hi,

In this case, only one side controls it at a time. The drivers are 
incompatible. The BMC relinquishes control before the SOC is powered on and 
cannot access it again until after the SOC is powered off. By using unbind and 
bind on the BMC it allows the BMC to reinitialize the SPI NOR into the proper 
mode when it binds (after the SOC is powered off). There is also a reset 
control line driven by the BMC to the SPI NOR as well.

So the procedure is when power is on to the SOC the BMC cannot access the SPI 
NOR (there is also a mux). When the SOC is powered off the SPI NOR is reset 
and the mux switches to the BMC which then binds the driver to the SPI NOR, 
initializing it so it can write to the SPI NOR.

Reads don't seem to be a problem when switching between the SOC and the BMC 
and the SOC has hardware support for arbitration but this is not used (and the 
current BMC driver lacks support for doing arbitration).

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