subject:"Re\: Macronix Flash\-Chip Block Protection Clearing 5.10er"

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

2021-12-27 Thread Nick

Is fixed by:
https://github.com/openwrt/openwrt/pull/4882

On 12/25/21 22:02, Nick wrote:

Thanks for your answer, but it did not help. :/
I will look at the change-log again and see if something changed.

On 12/25/21 19:46, David Bauer wrote:

Hi Nick,

On 12/25/21 16:49, Nick wrote:
The flash-chip mx25l6405d that is contained in the Ubiquity
Nanostation M5 (XM) is not able to write to the flash with kernel
5.10. Probably, caused by invalid block protection clearing. For
example the logread contains a lot of those messages:

jffs2: Newly-erased block contained word 0x19852003 at offset
0x0025

Can you try to modify "spi_nor_get_sr_tb_mask" to always return 0?

Having a quick look at the code, there is no check if TB and BP3 bit
conflict. Furthermore, the MXIC chip does not seem to have a TB bit
at all.

I could imagine this either writes the wrong value to the register or
does not unlock at all, as it interprets the range of the lock
incorrectly.

Just a assumption, did not have a closer look.

Best
David

I added a patch with the help of blocktrron for the 5.4er kernel
[0]. This patch is not applied in the 5.10er since a lot of rewrites
happened upstream. However, the underlying issue is the missing 4th
block protection bit that was not cleared. In upstream Linux you
typically set SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_B for that kind of
flash chips in drivers/mtd/spi-nor/macronix.c [1]. I added this for
the mx25l6405d, but it did not help. I also tried to backport the
("mtd: spi-nor: keep lock bits if they are non-volatile") fix and
setting "CONFIG_MTD_SPI_NOR_SWP_DISABLE", but it also did not help.
Did I miss something?

[0] -
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b

[1] -
https://github.com/torvalds/linux/commit/7ea40b54e83baed17d85567cfae56175def39a55#diff-f749d5111926f3afbd8d869c577cb314fb690186ba42a2538a87e5ea7725929e

[2] -
https://gist.github.com/PolynomialDivision/0c420c6bfcfd681cffa7aac9f346d262
[3] -
https://github.com/PolynomialDivision/openwrt/blob/984f1c84e8d087a9fa0117d5502b8e19a2a35b98/target/linux/generic/backport-5.10/409-v5.11-mtd-spi-nor-keep-lock-bits-if-they-are-non-volatile.patch

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

2021-12-26 Thread Nick

I think I fixed it accidentally by this PR:
https://github.com/openwrt/openwrt/pull/4879

The flash memory is not enough anymore using 5.10. I would be happy if
it could be merged, soon. Otherwise ubnt-xm targets are broken in master.

Bests
Nick

On 12/25/21 22:02, Nick wrote:

Thanks for your answer, but it did not help. :/
I will look at the change-log again and see if something changed.

On 12/25/21 19:46, David Bauer wrote:

Hi Nick,

jffs2: Newly-erased block contained word 0x19852003 at offset
0x0025

Can you try to modify "spi_nor_get_sr_tb_mask" to always return 0?

Having a quick look at the code, there is no check if TB and BP3 bit
conflict. Furthermore, the MXIC chip does not seem to have a TB bit
at all.

I could imagine this either writes the wrong value to the register or
does not unlock at all, as it interprets the range of the lock
incorrectly.

Just a assumption, did not have a closer look.

Best
David

[0] -
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b

[1] -
https://github.com/torvalds/linux/commit/7ea40b54e83baed17d85567cfae56175def39a55#diff-f749d5111926f3afbd8d869c577cb314fb690186ba42a2538a87e5ea7725929e

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

2021-12-25 Thread Nick

Thanks for your answer, but it did not help. :/
I will look at the change-log again and see if something changed.

On 12/25/21 19:46, David Bauer wrote:

Hi Nick,

jffs2: Newly-erased block contained word 0x19852003 at offset
0x0025

Can you try to modify "spi_nor_get_sr_tb_mask" to always return 0?

Having a quick look at the code, there is no check if TB and BP3 bit
conflict. Furthermore, the MXIC chip does not seem to have a TB bit at
all.

I could imagine this either writes the wrong value to the register or
does not unlock at all, as it interprets the range of the lock
incorrectly.

Just a assumption, did not have a closer look.

Best
David

I added a patch with the help of blocktrron for the 5.4er kernel [0].
This patch is not applied in the 5.10er since a lot of rewrites
happened upstream. However, the underlying issue is the missing 4th
block protection bit that was not cleared. In upstream Linux you
typically set SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_B for that kind of
flash chips in drivers/mtd/spi-nor/macronix.c [1]. I added this for
the mx25l6405d, but it did not help. I also tried to backport the
("mtd: spi-nor: keep lock bits if they are non-volatile") fix and
setting "CONFIG_MTD_SPI_NOR_SWP_DISABLE", but it also did not help.
Did I miss something?

[0] -
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b

[1] -
https://github.com/torvalds/linux/commit/7ea40b54e83baed17d85567cfae56175def39a55#diff-f749d5111926f3afbd8d869c577cb314fb690186ba42a2538a87e5ea7725929e

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

2021-12-25 Thread David Bauer

Hi Nick,

On 12/25/21 16:49, Nick wrote:
The flash-chip mx25l6405d that is contained in the Ubiquity Nanostation
M5 (XM) is not able to write to the flash with kernel 5.10. Probably,
caused by invalid block protection clearing. For example the logread
contains a lot of those messages:

jffs2: Newly-erased block contained word 0x19852003 at offset
0x0025

Can you try to modify "spi_nor_get_sr_tb_mask" to always return 0?

Having a quick look at the code, there is no check if TB and BP3 bit
conflict. Furthermore, the MXIC chip does not seem to have a TB bit at all.

I could imagine this either writes the wrong value to the register or
does not unlock at all, as it interprets the range of the lock incorrectly.

Just a assumption, did not have a closer look.

Best
David

I added a patch with the help of blocktrron for the 5.4er kernel [0].
This patch is not applied in the 5.10er since a lot of rewrites happened
upstream. However, the underlying issue is the missing 4th block
protection bit that was not cleared. In upstream Linux you typically set
SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_B for that kind of flash chips in
drivers/mtd/spi-nor/macronix.c [1]. I added this for the mx25l6405d, but
it did not help. I also tried to backport the ("mtd: spi-nor: keep lock
bits if they are non-volatile") fix and setting
"CONFIG_MTD_SPI_NOR_SWP_DISABLE", but it also did not help. Did I miss
something?

[0] -
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b

[1] -
https://github.com/torvalds/linux/commit/7ea40b54e83baed17d85567cfae56175def39a55#diff-f749d5111926f3afbd8d869c577cb314fb690186ba42a2538a87e5ea7725929e

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

4 matches

Site Navigation

Mail list logo

Footer information