Re: [PATCH] Revert "mtd: spi-nor: Add a post BFPT fixup for MX25L25635E"
Andrew Jeffery
andrew at aj.id.au
Wed Apr 17 16:22:58 AEST 2019
On Wed, 17 Apr 2019, at 15:41, Cédric Le Goater wrote:
> On 4/17/19 7:45 AM, Andrew Jeffery wrote:
> > This reverts commit 2bffa65da43e399079dad5947c6aa9ab3cfa4ad4.
> >
> > 5.0.x fails to boot on Witherspoon machines after an AC-cycle, with the
> > following error:
> >
> >> [ 4.337766] ubi0: default fastmap pool size: 25
> >> [ 4.342321] ubi0: default fastmap WL pool size: 12
> >> [ 4.347232] ubi0: attaching mtd3
> >> [ 4.361487] ubi0: scanning is finished
> >> [ 4.365525] ubi0 error: ubi_read_volume_table: the layout volume was not found
> >> [ 4.372989] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd3, error -22
> >> [ 4.380193] UBI error: cannot attach mtd3
> >
> > Which leads to:
> >
> >> [ 4.553478] VFS: Cannot open root device "ubiblock0_1" or unknown-block(0,0): error -6
> >> [ 4.561550] Please append a correct "root=" boot option; here are the available partitions:
> >> [ 4.570029] 1f00 32768 mtdblock0
> >> [ 4.570038] (driver?)
> >> [ 4.576671] 1f01 384 mtdblock1
> >> [ 4.576680] (driver?)
> >> [ 4.583234] 1f02 128 mtdblock2
> >> [ 4.583240] (driver?)
> >> [ 4.589883] 1f03 32256 mtdblock3
> >> [ 4.589892] (driver?)
> >> [ 4.596520] 1f04 32768 mtdblock4
> >> [ 4.596529] (driver?)
> >> [ 4.603080] 1f05 384 mtdblock5
> >> [ 4.603085] (driver?)
> >> [ 4.609711] 1f06 128 mtdblock6
> >> [ 4.609719] (driver?)
> >> [ 4.616338] 1f07 32256 mtdblock7
> >> [ 4.616347] (driver?)
> >> [ 4.622901] 1f08 131072 mtdblock8
> >> [ 4.622907] (driver?)
> >> [ 4.629539] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> >
> > A hint is provided earlier in the boot process:
> >
> >> [ 0.920597] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency
> >> [ 0.926753] aspeed-smc 1e620000.spi: mx25l25635e (32768 Kbytes)
> >> [ 0.932704] aspeed-smc 1e620000.spi: CE0 window [ 0x20000000 - 0x22000000 ] 32MB
> >> [ 0.940230] aspeed-smc 1e620000.spi: CE1 window [ 0x22000000 - 0x2a000000 ] 128MB
> >> [ 0.947812] aspeed-smc 1e620000.spi: read control register: 203c0641
> >> [ 1.435022] 3 fixed-partitions partitions found on MTD device bmc
> >> [ 1.441249] Creating 3 MTD partitions on "bmc":
> >> [ 1.445911] 0x000000000000-0x000000060000 : "u-boot"
> >> [ 1.455264] 0x000000060000-0x000000080000 : "u-boot-env"
> >> [ 1.465042] 0x000000080000-0x000002000000 : "obmc-ubi"
> >> [ 1.474914] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency
> >> [ 1.481102] aspeed-smc 1e620000.spi: mx25l25635e (32768 Kbytes)
> >> [ 1.487175] aspeed-smc 1e620000.spi: CE1 window [ 0x22000000 - 0x24000000 ] 32MB
> >> [ 1.494592] aspeed-smc 1e620000.spi: CE2 window [ 0x24000000 - 0x2c000000 ] 128MB
> >> [ 1.502173] aspeed-smc 1e620000.spi: read control register: 203c0041
> >> [ 1.705799] aspeed-smc 1e620000.spi: No good frequency, using dumb slow
> >> [ 1.717393] 3 fixed-partitions partitions found on MTD device alt-bmc
> >> [ 1.723851] Creating 3 MTD partitions on "alt-bmc":
> >> [ 1.728890] 0x000000000000-0x000000060000 : "alt-u-boot"
> >> [ 1.738950] 0x000000060000-0x000000080000 : "alt-u-boot-env"
> >> [ 1.748975] 0x000000080000-0x000002000000 : "alt-obmc-ubi"
> >
> > Specifically, the control register state is exposed as:
> >
> >> [ 0.947812] aspeed-smc 1e620000.spi: read control register: 203c0641
> >
> > The 0x3c opcode translates to DREAD4B for the mx25l25635f part, which is
> > what is detected. The post BFPT fixup implemented in commit 2bffa65da43e
> > ("mtd: spi-nor: Add a post BFPT fixup for MX25L25635E") detects the 'e'
> > vs 'f' part based on the reported support for
> > BFPT_DWORD5_FAST_READ_4_4_4, which implies 4B opcodes are supported
> > (e.g. DREAD4B), however the aspeed-smc driver fails to put the
> > controller into the right addressing mode to support sending DREAD4B, and
> > so we reach a bad state.
>
> It's more complex than that but I haven't quite cornered the problem.
>
> When doing the link training, the first read for the golden image is
> done in slow mode and it misses the first byte for some reason. So the
> gold image is incorrect (cough) but other images are correct (cough cough)
>
> Why is this first byte being dropped is the question. The flash module
> might have entered 4B mode ? is it expecting a dummy ?
>
> For the moment, this is fine for a workaround but we will need to fully
> support 4B opcodes (which we do without training). Another solution is
> to use the kernel command line switch "optimize_read=false" and all
> works fine, perfectly fine. Which is kind of frustrating.
Hmm, okay. Sounds like I didn't track it down as well as I thought then.
I figured we'd need to set CONTROL_IO_DUAL_ADDR_DATA to send a
DREAD4B, but we never put the controller into that mode: there's only
one call to aspeed_smc_set_io_mode(), in aspeed_smc_read_user(),
which is only called if `io_mode == CONTROL_IO_DUAL_DATA` holds,
and we set the IO mode to CONTROL_IO_DUAL_DATA.
Suggestions for rewording the commit message? Should I just replace
some of it with your words above?
Andrew
>
> Thanks for the patch.
>
> C.
>
>
> >
> > In the interim, revert the upstream patch adding 'e' vs 'f' detection to
> > avoid sending 4B opcodes.
> >
> > The revert has been tested on a freshly flashed and power-cycled
> > Witherspoon, both with and without the patch applied, confirming the
> > broken behaviour in the former case and a successful boot in the latter.
> >
> > Cc: Andrew Geissler <geissonator at gmail.com>
> > Reported-by: George Keishing <gkeishin at in.ibm.com>
> > Investigated-by: Cédric Le Goater <clg at kaod.org>
> > Investigated-by: Eddie James <eajames at linux.ibm.com>
> > Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 29 +----------------------------
> > 1 file changed, 1 insertion(+), 28 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index 5a5a47651bf9..9f85ab5fc569 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -1681,31 +1681,6 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor)
> > .addr_width = 3, \
> > .flags = SPI_NOR_NO_FR | SPI_S3AN,
> >
> > -static int
> > -mx25l25635_post_bfpt_fixups(struct spi_nor *nor,
> > - const struct sfdp_parameter_header *bfpt_header,
> > - const struct sfdp_bfpt *bfpt,
> > - struct spi_nor_flash_parameter *params)
> > -{
> > - /*
> > - * MX25L25635F supports 4B opcodes but MX25L25635E does not.
> > - * Unfortunately, Macronix has re-used the same JEDEC ID for both
> > - * variants which prevents us from defining a new entry in the parts
> > - * table.
> > - * We need a way to differentiate MX25L25635E and MX25L25635F, and it
> > - * seems that the F version advertises support for Fast Read 4-4-4 in
> > - * its BFPT table.
> > - */
> > - if (bfpt->dwords[BFPT_DWORD(5)] & BFPT_DWORD5_FAST_READ_4_4_4)
> > - nor->flags |= SNOR_F_4B_OPCODES;
> > -
> > - return 0;
> > -}
> > -
> > -static struct spi_nor_fixups mx25l25635_fixups = {
> > - .post_bfpt = mx25l25635_post_bfpt_fixups,
> > -};
> > -
> > /* NOTE: double check command sets and memory organization when you add
> > * more nor chips. This current list focusses on newer chips, which
> > * have been converging on command sets which including JEDEC ID.
> > @@ -1843,9 +1818,7 @@ static const struct flash_info spi_nor_ids[] = {
> > { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
> > { "mx25u12835f", INFO(0xc22538, 0, 64 * 1024, 256,
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > - { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512,
> > - SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> > - .fixups = &mx25l25635_fixups },
> > + { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "mx25u25635f", INFO(0xc22539, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_4B_OPCODES) },
> > { "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
> > { "mx66l51235f", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> >
>
>
More information about the openbmc
mailing list