Issues with SPI NOR flash

Cédric Le Goater clg at kaod.org
Tue Feb 12 19:18:20 AEDT 2019


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
> 



More information about the openbmc mailing list