From: <Tudor.Ambarus@microchip.com>
To: <mika.westerberg@linux.intel.com>
Cc: <pratyush@kernel.org>, <michael@walle.cc>,
<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
<linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v2] mtd: spi-nor: gigadevice: Add support for gd25lr256e
Date: Tue, 22 Nov 2022 11:59:47 +0000 [thread overview]
Message-ID: <870780c6-6f2e-9b90-6540-2c408f206f6b@microchip.com> (raw)
In-Reply-To: <Y3yxDLw3n643Ivf2@black.fi.intel.com>
On 11/22/22 13:22, Mika Westerberg wrote:
cut
>> Here's the simple test:
>>
>> Run the test_qspi.sh script:
>> #!/bin/sh
>>
>> dd if=/dev/urandom of=./qspi_test bs=1M count=6
>> mtd_debug write /dev/mtd5 0 6291456 qspi_test
>> mtd_debug erase /dev/mtd5 0 6291456
>> mtd_debug read /dev/mtd5 0 6291456 qspi_read
>> hexdump qspi_read
>> mtd_debug write /dev/mtd5 0 6291456 qspi_test
>> mtd_debug read /dev/mtd5 0 6291456 qspi_read
>> sha1sum qspi_test qspi_read
>>
>> The two SHA-1 sums must be the same to pass this test.
>
> That SPI flash holds the system BIOS and I'm using it remotely now so
> there is no way to revive if something goes wrong so I wonder if it is
> OK to skip the above step?
sure, it's fine, yes. Did you test the locking part of your patch?
I'm asking because if you don't need the locking or you're not able to test
it, then you can use the spi-nor-generic driver introduced by Michael at
[1] and you won't need an entry for the flash at all.
>
cut
> These I was able to read:
>
> # cat /sys/bus/spi/devices/spi0.0/spi-nor/partname
> gd25lr256e
> # cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id
> c86719
> # cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer
> gigadevice
> # xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
> 53464450060103ff00060110300000ffc8000103900000ff84000102c000
> 00ff03000102e00000ffffffffffffffffffe520eaffffffff0f44eb086b
> 003b00bbfeffffffffff00ffffff44eb0c200f5210d800ff4362c9fe82e9
> 9c58ec6006337a757a7504bdd55c2906740008500001ffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffff002050169df9
> 8156d9c8ffffffffffffffffffffffffffffffffffffffffffffffffffff
> fffffffffffffffffffffffff38ff0ff215cdcffffffffffffffffffffff
> ffffffffffffffffffffffffffff389b96f0e1a6b2ff
Okay, thanks.
[1] https://lore.kernel.org/linux-mtd/166903807811.85501.6803386075881922742.b4-ty@microchip.com/T/#t
--
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2022-11-22 12:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-23 6:58 [PATCH v2] mtd: spi-nor: gigadevice: Add support for gd25lr256e Mika Westerberg
2022-11-21 15:03 ` Tudor.Ambarus
2022-11-22 11:22 ` Mika Westerberg
2022-11-22 11:59 ` Tudor.Ambarus [this message]
2022-11-22 12:25 ` Mika Westerberg
2022-11-22 12:51 ` Tudor.Ambarus
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=870780c6-6f2e-9b90-6540-2c408f206f6b@microchip.com \
--to=tudor.ambarus@microchip.com \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=mika.westerberg@linux.intel.com \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=vigneshr@ti.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox