From: Michael Walle <michael@walle.cc> To: Biju Das <biju.das.jz@bp.renesas.com> Cc: Mark Brown <broonie@kernel.org>, Miquel Raynal <miquel.raynal@bootlin.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, linux-spi@vger.kernel.org, linux-mtd@lists.infradead.org, Geert Uytterhoeven <geert+renesas@glider.be>, Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>, "biju.das.au" <biju.das.au@gmail.com>, linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH RFC 0/4] Add set_iofv() callback Date: Mon, 13 Nov 2023 15:37:21 +0100 [thread overview] Message-ID: <4c6674a6717152fc1a244d123a2db896@walle.cc> (raw) In-Reply-To: <TYCPR01MB1126990A40D40D8786CABFAAA86ACA@TYCPR01MB11269.jpnprd01.prod.outlook.com> Hi Biju, >> >> >> Thus I was saying, that we probably wont support that and the >> >> >> easiest fix should be to disable this behavior for the atmel flash >> >> >> (there was nv setting). >> >> > >> >> > The fix up is invoked only for quad mode, I believe it is safe to >> >> > add fixup for micron flash As it is the one deviating from normal >> >> > according to you, rather than adding fixup for generic flash like >> >> > ATMEL flash(Now Renesas flash) >> >> >> >> Could you please try setting bit 4 in the Nonvolatile Configuration >> >> Register (Table 7) and see if the problem goes away? >> > >> > You mean, if it works, we need to disable reset for all the boards, >> > maybe at bootloader level?? >> >> Not necessarily. First, just to confirm that it is actually the reset >> circuit. You can also compare the part numbers of the flash. There is >> a >> flash with IO3/RESET# and IO3/HOLD# (and a flash with a dedicated >> reset >> pin). >> >> If that's the case, it looks like a hardware bug on your board. You >> left >> the reset pin floating. So you'd also not be able to boot from the NOR >> flash, right? >> >> > OK, I will check that. Currently I have read that register and it is >> > showing a value Of 0xffbb. I need to do write operation. Before that >> > how do we recover flash, if something goes wrong during writing for NV >> > register? >> >> You should always be able to write that register from the bootloader. >> Maybe also through raw commands (like sspi in uboot). > > Just an update, now clearing bit4 on Micron flash, I am able to test > erase/read/write > Micron flash with IOFV state {3,3,3,3}. Not sure what went wrong > previously. > only thing I changed is related to enabling the QUAD spi mode by > disabling bit 2 and 3 on NV register. This enables QPI mode, that is the command is also expected to be transferred over the four IO lines. That's not something linux supports. We'll always send the command in single bit mode (the only exception is octal DTR mode). > This again result in boot failure as boot ROM expects extended SPI > mode. > Then restored the extended SPI mode by sending the command FFh (Power > Loss and Interface Rescue) > by booting from eMMC. > > At least one board with micron flash is now working with IOFV state > {3,3,3,3}. > I need to test more boards to confirm the behaviour. I'm still trying to make sense of this (and trying to figure out if we need something or not). So you have a MT25QU512ABB8E12-0SIT, which according to to Figure 4 and Figure 5 has a dedicated RESET# line and the IO3 is multiplexed with HOLD#. Thus, it seems the flash will go into hold mode if IO3 is not high during command phase. Wether this is a hardware bug? I'd tend to say yes. As with the RESET# you depend on the software/bootROM whatever to set the state of IO3 correctly. But it might depend on the SPI controller used etc. Maybe it will already drive IO3 high by default?! (and esp. what the bootROM is doing if that SoC is able to load the first stage bootloader from NOR). I still see two possible fixes here: (1) Disable HOLD#, either during board production, in your bootloader/TFA or by introducing a fixup for this flash in linux. (And configure your SPI controller to use IOFV state 3,3,3,3 as that should be the sane default). (2) Introduce a mechanism to spi_mem_op to control the unused bits (as explained in an earlier reply). Then somehow integrate that into the spi-nor micron driver to set IO3 to this pariticular value for this operation. Alternatively, fix your board to have a weak pull-up on IO3 so the IOFV state 3,3,3,3 will work. HTH, -michael
WARNING: multiple messages have this Message-ID (diff)
From: Michael Walle <michael@walle.cc> To: Biju Das <biju.das.jz@bp.renesas.com> Cc: Mark Brown <broonie@kernel.org>, Miquel Raynal <miquel.raynal@bootlin.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, linux-spi@vger.kernel.org, linux-mtd@lists.infradead.org, Geert Uytterhoeven <geert+renesas@glider.be>, Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>, "biju.das.au" <biju.das.au@gmail.com>, linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH RFC 0/4] Add set_iofv() callback Date: Mon, 13 Nov 2023 15:37:21 +0100 [thread overview] Message-ID: <4c6674a6717152fc1a244d123a2db896@walle.cc> (raw) In-Reply-To: <TYCPR01MB1126990A40D40D8786CABFAAA86ACA@TYCPR01MB11269.jpnprd01.prod.outlook.com> Hi Biju, >> >> >> Thus I was saying, that we probably wont support that and the >> >> >> easiest fix should be to disable this behavior for the atmel flash >> >> >> (there was nv setting). >> >> > >> >> > The fix up is invoked only for quad mode, I believe it is safe to >> >> > add fixup for micron flash As it is the one deviating from normal >> >> > according to you, rather than adding fixup for generic flash like >> >> > ATMEL flash(Now Renesas flash) >> >> >> >> Could you please try setting bit 4 in the Nonvolatile Configuration >> >> Register (Table 7) and see if the problem goes away? >> > >> > You mean, if it works, we need to disable reset for all the boards, >> > maybe at bootloader level?? >> >> Not necessarily. First, just to confirm that it is actually the reset >> circuit. You can also compare the part numbers of the flash. There is >> a >> flash with IO3/RESET# and IO3/HOLD# (and a flash with a dedicated >> reset >> pin). >> >> If that's the case, it looks like a hardware bug on your board. You >> left >> the reset pin floating. So you'd also not be able to boot from the NOR >> flash, right? >> >> > OK, I will check that. Currently I have read that register and it is >> > showing a value Of 0xffbb. I need to do write operation. Before that >> > how do we recover flash, if something goes wrong during writing for NV >> > register? >> >> You should always be able to write that register from the bootloader. >> Maybe also through raw commands (like sspi in uboot). > > Just an update, now clearing bit4 on Micron flash, I am able to test > erase/read/write > Micron flash with IOFV state {3,3,3,3}. Not sure what went wrong > previously. > only thing I changed is related to enabling the QUAD spi mode by > disabling bit 2 and 3 on NV register. This enables QPI mode, that is the command is also expected to be transferred over the four IO lines. That's not something linux supports. We'll always send the command in single bit mode (the only exception is octal DTR mode). > This again result in boot failure as boot ROM expects extended SPI > mode. > Then restored the extended SPI mode by sending the command FFh (Power > Loss and Interface Rescue) > by booting from eMMC. > > At least one board with micron flash is now working with IOFV state > {3,3,3,3}. > I need to test more boards to confirm the behaviour. I'm still trying to make sense of this (and trying to figure out if we need something or not). So you have a MT25QU512ABB8E12-0SIT, which according to to Figure 4 and Figure 5 has a dedicated RESET# line and the IO3 is multiplexed with HOLD#. Thus, it seems the flash will go into hold mode if IO3 is not high during command phase. Wether this is a hardware bug? I'd tend to say yes. As with the RESET# you depend on the software/bootROM whatever to set the state of IO3 correctly. But it might depend on the SPI controller used etc. Maybe it will already drive IO3 high by default?! (and esp. what the bootROM is doing if that SoC is able to load the first stage bootloader from NOR). I still see two possible fixes here: (1) Disable HOLD#, either during board production, in your bootloader/TFA or by introducing a fixup for this flash in linux. (And configure your SPI controller to use IOFV state 3,3,3,3 as that should be the sane default). (2) Introduce a mechanism to spi_mem_op to control the unused bits (as explained in an earlier reply). Then somehow integrate that into the spi-nor micron driver to set IO3 to this pariticular value for this operation. Alternatively, fix your board to have a weak pull-up on IO3 so the IOFV state 3,3,3,3 will work. HTH, -michael ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-11-13 14:37 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-08 17:11 [PATCH RFC 0/4] Add set_iofv() callback Biju Das 2023-11-08 17:11 ` Biju Das 2023-11-08 17:11 ` [PATCH RFC 1/4] spi: spi-mem: " Biju Das 2023-11-08 17:11 ` Biju Das 2023-11-09 7:56 ` Geert Uytterhoeven 2023-11-09 7:56 ` Geert Uytterhoeven 2023-11-09 8:28 ` Biju Das 2023-11-08 17:11 ` [PATCH RFC 2/4] mtd: spi-nor: Add post_sfdp() callback Biju Das 2023-11-08 17:11 ` Biju Das 2023-11-08 17:11 ` [PATCH RFC 3/4] memory: renesas-rpc-if: Add support for overriding IO fixed values Biju Das 2023-11-21 9:08 ` Krzysztof Kozlowski 2023-11-08 17:11 ` [PATCH RFC 4/4] spi: rpc-if: Add set_iofv() callback Biju Das 2023-11-09 9:01 ` [PATCH RFC 0/4] " Michael Walle 2023-11-09 9:01 ` Michael Walle 2023-11-09 10:04 ` Biju Das 2023-11-09 10:48 ` Michael Walle 2023-11-09 10:48 ` Michael Walle 2023-11-09 11:48 ` Biju Das 2023-11-09 12:40 ` Michael Walle 2023-11-09 12:40 ` Michael Walle 2023-11-09 18:02 ` Biju Das 2023-11-10 10:11 ` Michael Walle 2023-11-10 10:11 ` Michael Walle 2023-11-10 11:35 ` Biju Das 2023-11-11 12:26 ` Biju Das 2023-11-11 13:08 ` Biju Das 2023-11-13 14:04 ` Michael Walle 2023-11-13 14:04 ` Michael Walle 2023-11-13 14:27 ` Biju Das 2023-11-13 14:48 ` Michael Walle 2023-11-13 14:48 ` Michael Walle 2023-11-13 14:59 ` Biju Das 2023-11-13 15:10 ` Michael Walle 2023-11-13 15:10 ` Michael Walle 2023-11-13 15:55 ` Biju Das 2023-11-14 10:05 ` Michael Walle 2023-11-14 10:05 ` Michael Walle 2023-11-12 20:24 ` Biju Das 2023-11-13 14:37 ` Michael Walle [this message] 2023-11-13 14:37 ` Michael Walle 2023-11-13 14:47 ` Michael Walle 2023-11-13 14:47 ` Michael Walle
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4c6674a6717152fc1a244d123a2db896@walle.cc \ --to=michael@walle.cc \ --cc=biju.das.au@gmail.com \ --cc=biju.das.jz@bp.renesas.com \ --cc=broonie@kernel.org \ --cc=geert+renesas@glider.be \ --cc=krzysztof.kozlowski@linaro.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=miquel.raynal@bootlin.com \ --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.