回复：Handling soft reset on mt7261 SoC with 32M flash

回复：Handling soft reset on mt7261 SoC with 32M flash

[Tymon]

I think sending “0x66 0x99” to mx25l256 is a proper way to fix the issue,
because this action does not change the bit-mode of spi flash and it only work
when user reboot the system.

------------------
Regards,

banglang huang
 


------------------ 原始邮件 ------------------
发件人: "Dominik Menke";<dom@digineo.de>;
发送时间: 2016年11月18日(星期五) 晚上10:20
收件人: "linux-mtd"<linux-mtd@lists.infradead.org>; 
主题: Handling soft reset on mt7261 Soc with 32M flash

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: 回复：Handling soft reset on mt7261 SoC with 32M flash

[Marek Vasut]

On 11/23/2016 05:53 AM, Tymon wrote:
> I think sending “0x66 0x99” to mx25l256 is a proper way to fix the issue,
> because this action does not change the bit-mode of spi flash and it only work
> when user reboot the system.

Since there is no context here, I cannot really comment, but is this
about SPI NOR being in 4-byte addressing mode and bootrom which does
not support it? If so, what happens if you press reset button on the
device ? SPI NOR remains in undefined mode and bootrom won't read the
bootloader from it. The only real fix is to implement CORRECT dedicated
SPI NOR reset logic.

> ------------------
> Regards,
> 
> banglang huang
>  
> 
> 
> ------------------ 原始邮件 ------------------
> 发件人: "Dominik Menke";<dom@digineo.de>;
> 发送时间: 2016年11月18日(星期五) 晚上10:20
> 收件人: "linux-mtd"<linux-mtd@lists.infradead.org>; 
> 主题: Handling soft reset on mt7261 Soc with 32M flash
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 


-- 
Best regards,
Marek Vasut

Re: 回复： 回复：Handling soft reset on mt7261 SoC with 32M flash

[Marek Vasut]

On 11/28/2016 02:34 AM, Tymon wrote:
> The real reason had been described : when the flash size > 16MB, the SPI bus must
> be configured to use 4-byte mode. The problem arised after a soft reset, when the SoC
> expects the SPI to be in 3-byte addressing mode, but then can't communicate with the flash.
> 
> http://lists.infradead.org/pipermail/linux-mtd/2016-November/070368.html

Well yes, it's the same problem, over and over again. Some flashes have
dedicated 4-byte opcodes.

btw please stop top-posting.

> ------------------ 原始邮件 ------------------
> 发件人: "Marek Vasut";<marek.vasut@gmail.com>;
> 发送时间: 2016年11月25日(星期五) 晚上10:15
> 收件人: "Tymon"<banglang.huang@foxmail.com>; "linux-mtd"<linux-mtd@lists.infradead.org>; 
> 主题: Re: 回复：Handling soft reset on mt7261 SoC with 32M flash
> 
> On 11/23/2016 05:53 AM, Tymon wrote:
>> I think sending “0x66 0x99” to mx25l256 is a proper way to fix the issue,
>> because this action does not change the bit-mode of spi flash and it only work
>> when user reboot the system.
> 
> Since there is no context here, I cannot really comment, but is this
> about SPI NOR being in 4-byte addressing mode and bootrom which does
> not support it? If so, what happens if you press reset button on the
> device ? SPI NOR remains in undefined mode and bootrom won't read the
> bootloader from it. The only real fix is to implement CORRECT dedicated
> SPI NOR reset logic.
> 
>> ------------------
>> Regards,
>>
>> banglang huang
>>  
>>
>>
>> ------------------ 原始邮件 ------------------
>> 发件人: "Dominik Menke";<dom@digineo.de>;
>> 发送时间: 2016年11月18日(星期五) 晚上10:20
>> 收件人: "linux-mtd"<linux-mtd@lists.infradead.org>; 
>> 主题: Handling soft reset on mt7261 Soc with 32M flash
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
> 
> 


-- 
Best regards,
Marek Vasut