[LEDE-DEV] [PATCH] ramips: Add patch to reset SPI flash to 3-byte addressing

Thu Mar 16 14:36:33 PDT 2017

On 03/05/2017 01:02 AM, Daniel Golle wrote:
> Hi,

Hi Daniel

> we've previously discussed [1] the patch on the mailing list and I
> believe that rather switching to 4-byte addressing mode we should
> rather use 4-byte opcodes instead because that would prevent the whole
> problem and provide a more reliable way to support large flash chips.
> This is also how it's done upstream and if there is a problem with
> that specific flash chip (maybe 4-byte opcodes don't work whatsoever)
> we should make sure that switching to 4-byte mode is really the only
> option we have. From Alex' answer I understood that backporting the
> upstream commit [3] didn't work for him.

The reason this didn't work is that the flash chip, Winbond 25Q256FVFG, 
does not support 4B opcodes for erase and write. I was able to boot up 
because the chip supports 4B opcodes for read.

Alex

> Can anyone else try if
> backporting commit [2] and [3] works as an alternative for them?
>
> Cheers
>
> Daniel
>
>
> [1] http://lists.infradead.org/pipermail/lede-dev/2017-January/005620.html
> [2] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=902cc69a0820252c84c6f7caed350882cea166ba
> [3] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3274ba26f27becfc4193ec6e229288140651f240
>
> On Sat, Mar 04, 2017 at 11:14:24PM +0100, davidea wrote:
>> what is the state of this patch?
>>
>> i have an mqmakers witi board with mt7621 and a spi flash mx25l6406 with
>> this beavior , when i reboot it , it's stop working until i power off and on
>> ...
>>
>> the spi flash seems do not have a reset pin
>>
>>
>> Il 30/01/2017 23:53, Alexandru Gagniuc ha scritto:
>>> This patch is designed to workaround an issue where an mt7620 will
>>> hang after a reboot. This happens because the bootrom gets confused
>>> when the SPI flash is left in 4-byte addressing mode. This change
>>> makes sure that we can reboot the system under normal circumstances,
>>> but does not protect against system crashes.
>>>
>>> Signed-off-by: Alexandru Gagniuc <alex.g at adaptrum.com>
>>> ---
>>>   ...Reset-chip-to-3-byte-addressing-on-system.patch | 65 ++++++++++++++++++++++
>>>   1 file changed, 65 insertions(+)
>>>   create mode 100644 target/linux/ramips/patches-4.4/0800-mtd-m25p80-Reset-chip-to-3-byte-addressing-on-system.patch
>>>
>>> diff --git a/target/linux/ramips/patches-4.4/0800-mtd-m25p80-Reset-chip-to-3-byte-addressing-on-system.patch b/target/linux/ramips/patches-4.4/0800-mtd-m25p80-Reset-chip-to-3-byte-addressing-on-system.patch
>>> new file mode 100644
>>> index 0000000..de4ee2c
>>> --- /dev/null
>>> +++ b/target/linux/ramips/patches-4.4/0800-mtd-m25p80-Reset-chip-to-3-byte-addressing-on-system.patch
>>> @@ -0,0 +1,65 @@
>>> +From 0f7fcc3dfc27a91e7672e9e589f3f558e8c41737 Mon Sep 17 00:00:00 2001
>>> +From: Alexandru Gagniuc <alex.g at adaptrum.com>
>>> +Date: Mon, 30 Jan 2017 13:30:33 -0800
>>> +Subject: [PATCH] mtd: m25p80: Reset chip to 3-byte addressing on system reboot
>>> +
>>> +Some SOCs can not handle 4-byte addressing in their mask ROM. On such
>>> +devices if we leave the SPI flash in 4-byte mode, then reboot the
>>> +system, the device will not boot.
>>> +
>>> +Some SoCs have a special output to reset all the on-board peripherals.
>>> +This pin should be connected to the !RESET pin of the flash as well.
>>> +Unfortunately, not all boards implement this. As a workaround for such
>>> +hardware, reset the SPI flash to 3-byte addressing mode. This does not
>>> +protect against system crashes, but it does allow the system to reboot
>>> +in the case of a normal reboot.
>>> +
>>> +Cc: Paul Fertser <fercerpav at gmail.com>
>>> +Signed-off-by: Alexandru Gagniuc <alex.g at adaptrum.com>
>>> +---
>>> + drivers/mtd/devices/m25p80.c | 15 +++++++++++++++
>>> + 1 file changed, 15 insertions(+)
>>> +
>>> +diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>>> +index fe9ceb7..2151975 100644
>>> +--- a/drivers/mtd/devices/m25p80.c
>>> ++++ b/drivers/mtd/devices/m25p80.c
>>> +@@ -27,6 +27,9 @@
>>> + #include <linux/spi/flash.h>
>>> + #include <linux/mtd/spi-nor.h>
>>> +
>>> ++#define OPCODE_RESET_ENABLE	0x66
>>> ++#define OPCODE_RESET		0x99
>>> ++
>>> + #define	MAX_CMD_SIZE		6
>>> + struct m25p {
>>> + 	struct spi_device	*spi;
>>> +@@ -168,6 +171,17 @@ static int m25p80_erase(struct spi_nor *nor, loff_t offset)
>>> + 	return 0;
>>> + }
>>> +
>>> ++void m25p80_reboot(struct mtd_info *mtd)
>>> ++{
>>> ++	struct spi_nor *nor = container_of(mtd, struct spi_nor, mtd);
>>> ++	struct m25p *flash = nor->priv;
>>> ++
>>> ++	flash->command[0] = OPCODE_RESET_ENABLE;
>>> ++	spi_write(flash->spi, flash->command, 1);
>>> ++	flash->command[0] = OPCODE_RESET;
>>> ++	spi_write(flash->spi, flash->command, 1);
>>> ++}
>>> ++
>>> + /*
>>> +  * board specific setup should have ensured the SPI clock used here
>>> +  * matches what the READ command supports, at least until this driver
>>> +@@ -197,6 +211,7 @@ static int m25p_probe(struct spi_device *spi)
>>> + 	nor->erase = m25p80_erase;
>>> + 	nor->write_reg = m25p80_write_reg;
>>> + 	nor->read_reg = m25p80_read_reg;
>>> ++	nor->mtd._reboot = m25p80_reboot;
>>> +
>>> + 	nor->dev = &spi->dev;
>>> + 	nor->flash_node = spi->dev.of_node;
>>> +--
>>> +2.9.3
>>> +
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev