From: Patrick Williams <hidden> Date: 2021-12-29 14:33:44
The aspeed-smc can have multiple SPI devices attached to it in the
device tree. If one of the devices is missing or failing the entire
probe will fail and all MTD devices under the controller will be
removed. On OpenBMC this results in a kernel panic due to missing
rootfs:
[ 0.538774] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency
[ 0.540471] aspeed-smc 1e620000.spi: w25q01jv-iq (131072 Kbytes)
[ 0.540750] aspeed-smc 1e620000.spi: CE0 window [ 0x20000000 - 0x28000000 ] 128MB
[ 0.540943] aspeed-smc 1e620000.spi: CE1 window [ 0x28000000 - 0x2c000000 ] 64MB
[ 0.541143] aspeed-smc 1e620000.spi: read control register: 203b0041
[ 0.581442] 5 fixed-partitions partitions found on MTD device bmc
[ 0.581625] Creating 5 MTD partitions on "bmc":
[ 0.581854] 0x000000000000-0x0000000e0000 : "u-boot"
[ 0.584472] 0x0000000e0000-0x000000100000 : "u-boot-env"
[ 0.586468] 0x000000100000-0x000000a00000 : "kernel"
[ 0.588465] 0x000000a00000-0x000006000000 : "rofs"
[ 0.590552] 0x000006000000-0x000008000000 : "rwfs"
[ 0.592605] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency
[ 0.592801] aspeed-smc 1e620000.spi: unrecognized JEDEC id bytes: 00 00 00 00 00 00
[ 0.593039] Deleting MTD partitions on "bmc":
[ 0.593175] Deleting u-boot MTD partition
[ 0.637929] Deleting u-boot-env MTD partition
[ 0.829527] Deleting kernel MTD partition
[ 0.856902] Freeing initrd memory: 1032K
[ 0.866428] Deleting rofs MTD partition
[ 0.906264] Deleting rwfs MTD partition
[ 0.986628] aspeed-smc 1e620000.spi: Aspeed SMC probe failed -2
[ 0.986929] aspeed-smc: probe of 1e620000.spi failed with error -2
...
[ 2.936719] /dev/mtdblock: Can't open blockdev
mount: mounting /dev/mtdblock on run/initramfs/ro failed: No such file or directory
[ 2.963030] MTD: Couldn't look up '/dev/mtdblock': -2
mount: mounting /dev/mtdblock on run/initramfs/rw failed: No such file or directory
Mounting read-write /dev/mtdblock filesystem failed. Please fix and run
mount /dev/mtdblock run/initramfs/rw -t jffs2 -o rw
or perform a factory reset with the clean-rwfs-filesystem option.
Fatal error, triggering kernel panic!
[ 3.013047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
Many BMC designs have two flash chips so that they can handle a hardware
failure of one of them. If one chip failed, it doesn't do any good to
have redundancy if they all get removed anyhow.
Improve the resilience of the probe function to handle one of the
children being missing or failed. Only in the case where all children
fail to probe should the controller be failed out.
Signed-off-by: Patrick Williams <redacted>
---
drivers/mtd/spi-nor/controllers/aspeed-smc.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
The aspeed-smc can have multiple SPI devices attached to it in the
device tree. If one of the devices is missing or failing the entire
probe will fail and all MTD devices under the controller will be
removed. On OpenBMC this results in a kernel panic due to missing
rootfs:
[ 0.538774] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency
[ 0.540471] aspeed-smc 1e620000.spi: w25q01jv-iq (131072 Kbytes)
[ 0.540750] aspeed-smc 1e620000.spi: CE0 window [ 0x20000000 - 0x28000000 ] 128MB
[ 0.540943] aspeed-smc 1e620000.spi: CE1 window [ 0x28000000 - 0x2c000000 ] 64MB
[ 0.541143] aspeed-smc 1e620000.spi: read control register: 203b0041
[ 0.581442] 5 fixed-partitions partitions found on MTD device bmc
[ 0.581625] Creating 5 MTD partitions on "bmc":
[ 0.581854] 0x000000000000-0x0000000e0000 : "u-boot"
[ 0.584472] 0x0000000e0000-0x000000100000 : "u-boot-env"
[ 0.586468] 0x000000100000-0x000000a00000 : "kernel"
[ 0.588465] 0x000000a00000-0x000006000000 : "rofs"
[ 0.590552] 0x000006000000-0x000008000000 : "rwfs"
[ 0.592605] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency
[ 0.592801] aspeed-smc 1e620000.spi: unrecognized JEDEC id bytes: 00 00 00 00 00 00
[ 0.593039] Deleting MTD partitions on "bmc":
[ 0.593175] Deleting u-boot MTD partition
[ 0.637929] Deleting u-boot-env MTD partition
[ 0.829527] Deleting kernel MTD partition
[ 0.856902] Freeing initrd memory: 1032K
[ 0.866428] Deleting rofs MTD partition
[ 0.906264] Deleting rwfs MTD partition
[ 0.986628] aspeed-smc 1e620000.spi: Aspeed SMC probe failed -2
[ 0.986929] aspeed-smc: probe of 1e620000.spi failed with error -2
...
[ 2.936719] /dev/mtdblock: Can't open blockdev
mount: mounting /dev/mtdblock on run/initramfs/ro failed: No such file or directory
[ 2.963030] MTD: Couldn't look up '/dev/mtdblock': -2
mount: mounting /dev/mtdblock on run/initramfs/rw failed: No such file or directory
Mounting read-write /dev/mtdblock filesystem failed. Please fix and run
mount /dev/mtdblock run/initramfs/rw -t jffs2 -o rw
or perform a factory reset with the clean-rwfs-filesystem option.
Fatal error, triggering kernel panic!
[ 3.013047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
Many BMC designs have two flash chips so that they can handle a hardware
failure of one of them. If one chip failed, it doesn't do any good to
have redundancy if they all get removed anyhow.
Improve the resilience of the probe function to handle one of the
children being missing or failed. Only in the case where all children
fail to probe should the controller be failed out.
From: Patrick Williams <hidden> Date: 2021-12-30 15:29:53
On Wed, Dec 29, 2021 at 11:04:13PM +0530, Pratyush Yadav wrote:
Hi,
On 29/12/21 08:33AM, Patrick Williams wrote:
The patch itself looks fine to me but we no longer want to maintain
drivers under drivers/mtd/spi-nor/controllers/. They should be moved to
implement the SPI MEM API (under drivers/spi/).
Is the linux-aspeed community aware of this? Are you saying you don't want to
take fixes for their driver into the MTD tree? Can it be pulled into the Aspeed
tree?
Could you please volunteer to do the conversion for this driver?
I'm not personally going to be able to get to it for at least the next 3 months.
It looks like we don't have a dedicated maintainer for this driver other than
Joel by nature of him being listed as the maintainer of "ARM/ASPEED MACHINE
SUPPORT". I'm not sure if Aspeed themselves are planning on doing the necessary
refactoring here.
Joel, are you aware of this driver using a deprecated implementation? Were
there anyone planning to do the reworks that you are aware of? I'd like to get
this fix at least into the OpenBMC kernel tree because I'm seeing this fail in
the real world.
--
Patrick Williams
Hi Patrick,
On 30/12/21 09:29AM, Patrick Williams wrote:
On Wed, Dec 29, 2021 at 11:04:13PM +0530, Pratyush Yadav wrote:
quoted
Hi,
On 29/12/21 08:33AM, Patrick Williams wrote:
quoted
The patch itself looks fine to me but we no longer want to maintain
drivers under drivers/mtd/spi-nor/controllers/. They should be moved to
implement the SPI MEM API (under drivers/spi/).
Is the linux-aspeed community aware of this? Are you saying you don't want to
take fixes for their driver into the MTD tree? Can it be pulled into the Aspeed
tree?
I am fine with taking in bug fixes but no longer want to take in any new
features. My main intention was to nudge you to convert it to SPI MEM
regardless of whether this is a bug fix or a new feature, because
eventually we want to get rid of drivers/mtd/spi-nor/controllers/ and
the API that comes along with it.
As for your patch, I certainly don't want it to go via the aspeed tree.
It should go via the MTD tree or not at all. I am not quite sure if this
counts as a bug fix or a new feature though.
quoted
Could you please volunteer to do the conversion for this driver?
I'm not personally going to be able to get to it for at least the next 3 months.
It looks like we don't have a dedicated maintainer for this driver other than
Joel by nature of him being listed as the maintainer of "ARM/ASPEED MACHINE
SUPPORT". I'm not sure if Aspeed themselves are planning on doing the necessary
refactoring here.
Joel, are you aware of this driver using a deprecated implementation? Were
there anyone planning to do the reworks that you are aware of? I'd like to get
this fix at least into the OpenBMC kernel tree because I'm seeing this fail in
the real world.
Hello,
p.yadav@ti.com wrote on Fri, 31 Dec 2021 15:56:25 +0530:
Hi Patrick,
On 30/12/21 09:29AM, Patrick Williams wrote:
quoted
On Wed, Dec 29, 2021 at 11:04:13PM +0530, Pratyush Yadav wrote:
quoted
Hi,
On 29/12/21 08:33AM, Patrick Williams wrote:
quoted
The patch itself looks fine to me but we no longer want to maintain
drivers under drivers/mtd/spi-nor/controllers/. They should be moved to
implement the SPI MEM API (under drivers/spi/).
Is the linux-aspeed community aware of this? Are you saying you don't want to
take fixes for their driver into the MTD tree? Can it be pulled into the Aspeed
tree?
I am fine with taking in bug fixes but no longer want to take in any new
features. My main intention was to nudge you to convert it to SPI MEM
regardless of whether this is a bug fix or a new feature, because
eventually we want to get rid of drivers/mtd/spi-nor/controllers/ and
the API that comes along with it.
I totally agree with Pratyush here, we no longer want to support the
spi-nor controller API so if, as you say, there are boards failing
in the field, it means there are still users and these users must be
warned that at some point we might discontinue the support of these
drivers if it becomes too painful.
As for your patch, I certainly don't want it to go via the aspeed tree.
Definitely, no.
It should go via the MTD tree or not at all. I am not quite sure if this
counts as a bug fix or a new feature though.
quoted
quoted
Could you please volunteer to do the conversion for this driver?
I'm not personally going to be able to get to it for at least the next 3 months.
It looks like we don't have a dedicated maintainer for this driver other than
Joel by nature of him being listed as the maintainer of "ARM/ASPEED MACHINE
SUPPORT". I'm not sure if Aspeed themselves are planning on doing the necessary
refactoring here.
Joel, are you aware of this driver using a deprecated implementation? Were
there anyone planning to do the reworks that you are aware of? I'd like to get
this fix at least into the OpenBMC kernel tree because I'm seeing this fail in
the real world.
From: Patrick Williams <hidden> Date: 2022-01-04 18:20:35
Hi Miquel,
On Mon, Jan 03, 2022 at 05:17:21PM +0100, Miquel Raynal wrote:
quoted
I am fine with taking in bug fixes but no longer want to take in any new
features. My main intention was to nudge you to convert it to SPI MEM
regardless of whether this is a bug fix or a new feature, because
eventually we want to get rid of drivers/mtd/spi-nor/controllers/ and
the API that comes along with it.
I totally agree with Pratyush here, we no longer want to support the
spi-nor controller API so if, as you say, there are boards failing
in the field, it means there are still users and these users must be
warned that at some point we might discontinue the support of these
drivers if it becomes too painful.
Your response here makes it seem like you don't realize the scope of this
driver. There are probably, by my estimates, on the order of 10s of millions of
deployed systems using this driver in the world. The vast majority of servers
in the world use an AST2400, AST2500, or AST2600 chip, which needs this driver
in order access its own flash storage device. Both OpenBMC and most of the
proprietary alternatives use this driver.
The company I work for has a LOT of systems using this code. After I made this
fix, for a new design being developed, it was pointed out to me that our ODM ran
into this problem a few years ago and we've been really bad about upstreaming
those fixes. For this new system I'm trying to keep us on top of all
upstreaming efforts.
To me the inability to access your own storage, resulting in a kernel panic, is
a pretty serious issue. Bug or feature I guess is always in the eye of the
beholder though. I think this is pretty valuable to get in, from an impact
standpoint, and pretty minimal in terms of maintenance efforts on the
maintainers part.
I had an offline discussion with someone who knew more history on this driver.
My understanding is that the linux-aspeed team is aware of this being deprecated
but that there was some missing support for interface training that nobody has
gotten around to write? If that is the case this really isn't even a "simple"
port to a new API at this point.
--
Patrick Williams
Hi Miquel,
On Mon, Jan 03, 2022 at 05:17:21PM +0100, Miquel Raynal wrote:
quoted
quoted
I am fine with taking in bug fixes but no longer want to take in any new
features. My main intention was to nudge you to convert it to SPI MEM
regardless of whether this is a bug fix or a new feature, because
eventually we want to get rid of drivers/mtd/spi-nor/controllers/ and
the API that comes along with it.
I totally agree with Pratyush here, we no longer want to support the
spi-nor controller API so if, as you say, there are boards failing
in the field, it means there are still users and these users must be
warned that at some point we might discontinue the support of these
drivers if it becomes too painful.
Your response here makes it seem like you don't realize the scope of this
driver. There are probably, by my estimates, on the order of 10s of millions of
deployed systems using this driver in the world. The vast majority of servers
in the world use an AST2400, AST2500, or AST2600 chip, which needs this driver
in order access its own flash storage device. Both OpenBMC and most of the
proprietary alternatives use this driver.
Then we should easily be able to find people willing to spend a couple
days on updating the driver :-)
The company I work for has a LOT of systems using this code. After I made this
fix, for a new design being developed, it was pointed out to me that our ODM ran
into this problem a few years ago and we've been really bad about upstreaming
those fixes. For this new system I'm trying to keep us on top of all
upstreaming efforts.
If a company wants to use an upstream kernel for their systems I think
they should invest into maintaining the drivers they are using.
To me the inability to access your own storage, resulting in a kernel panic, is
a pretty serious issue. Bug or feature I guess is always in the eye of the
One option you always have is to disable the bad flash in your device
tree. I don't see why you would want to keep a flash that does not work
enabled anyway.
beholder though. I think this is pretty valuable to get in, from an impact
standpoint, and pretty minimal in terms of maintenance efforts on the
maintainers part.
Yes, I agree that your patch itself has fairly low maintenance burden. I
would not be too opposed to taking it in. But for the driver as a whole,
that is indeed a maintenance burden since we have to carry code in SPI
NOR to support it which makes adding new features a bit tricky.
We had a discussion along these lines for old unmaintained flashes in
SPI NOR. The idea then was to warn the people who touched code related
to those flashes that they can either update it or we will drop the
flashes after X releases. They would still work on older kernels of
course, but if there are any upstream users they would have to update
the code or live without the flashes.
I would like to use the same approach for the controllers API as well.
We can't keep carrying around legacy code forever just because a
device/driver has no active developers. If people want to use some
driver in the upstream kernel, they should help maintain it.
I had an offline discussion with someone who knew more history on this driver.
My understanding is that the linux-aspeed team is aware of this being deprecated
but that there was some missing support for interface training that nobody has
gotten around to write? If that is the case this really isn't even a "simple"
port to a new API at this point.
Unless the controller needs some unique feature (I don't think it does
on a quick glance), the conversion should not be too difficult. For any
experienced developer, even if they are unfamiliar with the SPI MEM API,
I don't think it should take more than 2-3 days to do the conversion.
The code to program the registers would stay the same, all that needs to
change is the API through which it is accessed.
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, 2021-12-29 at 14:33:33 UTC, Patrick Williams wrote:
The aspeed-smc can have multiple SPI devices attached to it in the
device tree. If one of the devices is missing or failing the entire
probe will fail and all MTD devices under the controller will be
removed. On OpenBMC this results in a kernel panic due to missing
rootfs:
[ 0.538774] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency
[ 0.540471] aspeed-smc 1e620000.spi: w25q01jv-iq (131072 Kbytes)
[ 0.540750] aspeed-smc 1e620000.spi: CE0 window [ 0x20000000 - 0x28000000 ] 128MB
[ 0.540943] aspeed-smc 1e620000.spi: CE1 window [ 0x28000000 - 0x2c000000 ] 64MB
[ 0.541143] aspeed-smc 1e620000.spi: read control register: 203b0041
[ 0.581442] 5 fixed-partitions partitions found on MTD device bmc
[ 0.581625] Creating 5 MTD partitions on "bmc":
[ 0.581854] 0x000000000000-0x0000000e0000 : "u-boot"
[ 0.584472] 0x0000000e0000-0x000000100000 : "u-boot-env"
[ 0.586468] 0x000000100000-0x000000a00000 : "kernel"
[ 0.588465] 0x000000a00000-0x000006000000 : "rofs"
[ 0.590552] 0x000006000000-0x000008000000 : "rwfs"
[ 0.592605] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency
[ 0.592801] aspeed-smc 1e620000.spi: unrecognized JEDEC id bytes: 00 00 00 00 00 00
[ 0.593039] Deleting MTD partitions on "bmc":
[ 0.593175] Deleting u-boot MTD partition
[ 0.637929] Deleting u-boot-env MTD partition
[ 0.829527] Deleting kernel MTD partition
[ 0.856902] Freeing initrd memory: 1032K
[ 0.866428] Deleting rofs MTD partition
[ 0.906264] Deleting rwfs MTD partition
[ 0.986628] aspeed-smc 1e620000.spi: Aspeed SMC probe failed -2
[ 0.986929] aspeed-smc: probe of 1e620000.spi failed with error -2
...
[ 2.936719] /dev/mtdblock: Can't open blockdev
mount: mounting /dev/mtdblock on run/initramfs/ro failed: No such file or directory
[ 2.963030] MTD: Couldn't look up '/dev/mtdblock': -2
mount: mounting /dev/mtdblock on run/initramfs/rw failed: No such file or directory
Mounting read-write /dev/mtdblock filesystem failed. Please fix and run
mount /dev/mtdblock run/initramfs/rw -t jffs2 -o rw
or perform a factory reset with the clean-rwfs-filesystem option.
Fatal error, triggering kernel panic!
[ 3.013047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
Many BMC designs have two flash chips so that they can handle a hardware
failure of one of them. If one chip failed, it doesn't do any good to
have redundancy if they all get removed anyhow.
Improve the resilience of the probe function to handle one of the
children being missing or failed. Only in the case where all children
fail to probe should the controller be failed out.
Signed-off-by: Patrick Williams <redacted>
From: Cédric Le Goater <clg@kaod.org> Date: 2022-01-23 23:02:47
quoted
I had an offline discussion with someone who knew more history on this driver.
My understanding is that the linux-aspeed team is aware of this being deprecated
but that there was some missing support for interface training that nobody has
gotten around to write? If that is the case this really isn't even a "simple"
port to a new API at this point.
Unless the controller needs some unique feature (I don't think it does
on a quick glance), the conversion should not be too difficult. For any
experienced developer, even if they are unfamiliar with the SPI MEM API,
I don't think it should take more than 2-3 days to do the conversion.
The code to program the registers would stay the same, all that needs to
change is the API through which it is accessed.
Writing a spimem driver is not a problem, I think people have done
that in house. Aspeed has one for AST2600. We have one for u-boot
I wrote sometime ago. I even have one for Linux but training comes
with ugly hacks to fit in the current stack.
All Aspeed SoCs need training and that has been the problem for the
last 4 years or so because we can not do training without knowing
a minimum about the flash being trained :/ The previous framework
offered a way to do a first scan and tune the delay settings
afterwards. It worked pretty well on AST2400, AST2500 and AST2600
even if more complex.
One alternative was to include the setting in the DT but the flash
modules are not always soldered on the boards, at least on OpenPOWER
systems which have sockets for them. The board are large, the wires
long, the need is real, some chips freak out if not tuned correctly.
spimem needs an extension I think. Sorry I have not been able to
push that forward. Lack of time and other tasks to address on the
host side of the machine. This is really a software problem, we
have the HW procedures ready. If a spimem expert could get involved
to make a few proposals, I would be happy to help and do some testing.
QEMU models are good enough for the software part. We can do the
training validation on real HW when ready.
Thanks,
C.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I had an offline discussion with someone who knew more history on this driver.
My understanding is that the linux-aspeed team is aware of this being deprecated
but that there was some missing support for interface training that nobody has
gotten around to write? If that is the case this really isn't even a "simple"
port to a new API at this point.
Unless the controller needs some unique feature (I don't think it does
on a quick glance), the conversion should not be too difficult. For any
experienced developer, even if they are unfamiliar with the SPI MEM API,
I don't think it should take more than 2-3 days to do the conversion.
The code to program the registers would stay the same, all that needs to
change is the API through which it is accessed.
Writing a spimem driver is not a problem, I think people have done
that in house. Aspeed has one for AST2600. We have one for u-boot
I wrote sometime ago. I even have one for Linux but training comes
with ugly hacks to fit in the current stack.
All Aspeed SoCs need training and that has been the problem for the
last 4 years or so because we can not do training without knowing
a minimum about the flash being trained :/ The previous framework
offered a way to do a first scan and tune the delay settings
afterwards. It worked pretty well on AST2400, AST2500 and AST2600
even if more complex.
One alternative was to include the setting in the DT but the flash
modules are not always soldered on the boards, at least on OpenPOWER
systems which have sockets for them. The board are large, the wires
long, the need is real, some chips freak out if not tuned correctly.
spimem needs an extension I think. Sorry I have not been able to
push that forward. Lack of time and other tasks to address on the
host side of the machine. This is really a software problem, we
have the HW procedures ready. If a spimem expert could get involved
to make a few proposals, I would be happy to help and do some testing.
QEMU models are good enough for the software part. We can do the
training validation on real HW when ready.
What information about the flash do you need for this training? I
proposed a patch series [0] some time ago trying to implement training
for TI SoCs. It did not get merged but I do intend to respin it and get
it through. Would this API work for your tuning as well?
Also, I am curious how your training works. What data do you read for
training delays? Where is it stored? In our case we need to flash a
known pattern at some location (which is passed in via DT). Do you need
to run it for every read transaction or just once after the flash is
initialized?
[0] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=233504&state=%2A&archive=both
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Cédric Le Goater <clg@kaod.org> Date: 2022-01-24 18:43:17
quoted
spimem needs an extension I think. Sorry I have not been able to
push that forward. Lack of time and other tasks to address on the
host side of the machine. This is really a software problem, we
have the HW procedures ready. If a spimem expert could get involved
to make a few proposals, I would be happy to help and do some testing.
QEMU models are good enough for the software part. We can do the
training validation on real HW when ready.
What information about the flash do you need for this training?
Last time I looked, we lacked some post_init handler to setup a slave:
configure the registers defining the AHB windows for each flash
slave and perform the read timing calibration. calibration should
only be done once.
See how the aspeed_spi_flash_init() routine doing the calibration
is hooked up under aspeed_spi_claim_bus() in the u-boot driver :
https://github.com/openbmc/u-boot/blob/v2019.04-aspeed-openbmc/drivers/spi/aspeed_spi.c
Not good enough for upstream, Linux would be the same :/
I proposed a patch series [0] some time ago trying to implement training
for TI SoCs. It did not get merged but I do intend to respin it and get
it through. Would this API work for your tuning as well?
I will take a look.
Also, I am curious how your training works. What data do you read for
training delays? Where is it stored?
The driver reads the first 16K at slow speed (that's why we need a
basic minimal setup of the slave) and checks if the buffer is valid
enough for the calibration :
https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c#L998
it then performs reads by changing the frequency and delays and
compares results with the initial default buffer.
if not, then the driver stays in a safe mode (slow).
In our case we need to flash a
known pattern at some location (which is passed in via DT). Do you need
to run it for every read transaction or just once after the flash is
initialized?
Just once because it is a heavy process. See the debug outputs below.
Once we have good read timings and frequency, there is no need to do
it each time.
spimem needs an extension I think. Sorry I have not been able to
push that forward. Lack of time and other tasks to address on the
host side of the machine. This is really a software problem, we
have the HW procedures ready. If a spimem expert could get involved
to make a few proposals, I would be happy to help and do some testing.
QEMU models are good enough for the software part. We can do the
training validation on real HW when ready.
What information about the flash do you need for this training?
Last time I looked, we lacked some post_init handler to setup a slave:
configure the registers defining the AHB windows for each flash
slave and perform the read timing calibration. calibration should
only be done once.
See how the aspeed_spi_flash_init() routine doing the calibration
is hooked up under aspeed_spi_claim_bus() in the u-boot driver :
My patch series should provide a hook for doing the calibration _after_
the flash is initialized.
I proposed a patch series [0] some time ago trying to implement training
for TI SoCs. It did not get merged but I do intend to respin it and get
it through. Would this API work for your tuning as well?
I will take a look.
quoted
Also, I am curious how your training works. What data do you read for
training delays? Where is it stored?
This seems similar to the tuning I implemented, except mine uses a
pre-defined pattern at a pre-defined location.
if not, then the driver stays in a safe mode (slow).
Same for my patches.
quoted
In our case we need to flash a
known pattern at some location (which is passed in via DT). Do you need
to run it for every read transaction or just once after the flash is
initialized?
Just once because it is a heavy process. See the debug outputs below.
Once we have good read timings and frequency, there is no need to do
it each time.
It looks very similar to the tuning I implemented in my patch series.
You should be able to use those APIs for your tuning as well. But it
should not block the SPI MEM port. The current upstream driver does not
seem to implement this tuning anyway.
From: Cédric Le Goater <clg@kaod.org> Date: 2022-02-07 20:19:12
Hello,
On 1/24/22 21:37, Pratyush Yadav wrote:
On 24/01/22 07:34PM, Cédric Le Goater wrote:
quoted
quoted
quoted
spimem needs an extension I think. Sorry I have not been able to
push that forward. Lack of time and other tasks to address on the
host side of the machine. This is really a software problem, we
have the HW procedures ready. If a spimem expert could get involved
to make a few proposals, I would be happy to help and do some testing.
QEMU models are good enough for the software part. We can do the
training validation on real HW when ready.
What information about the flash do you need for this training?
Last time I looked, we lacked some post_init handler to setup a slave:
configure the registers defining the AHB windows for each flash
slave and perform the read timing calibration. calibration should
only be done once.
See how the aspeed_spi_flash_init() routine doing the calibration
is hooked up under aspeed_spi_claim_bus() in the u-boot driver :
My patch series should provide a hook for doing the calibration _after_
the flash is initialized.
You can also use the .dirmap_create handler. The flash device has
been scanned when called and the size is available in the spi-mem
dirmap descriptor.
I reworked the current Aspeed driver with this approach and it
seems sufficient for read calibration.
Thanks,
C.
I proposed a patch series [0] some time ago trying to implement training
for TI SoCs. It did not get merged but I do intend to respin it and get
it through. Would this API work for your tuning as well?
I will take a look.
quoted
Also, I am curious how your training works. What data do you read for
training delays? Where is it stored?
This seems similar to the tuning I implemented, except mine uses a
pre-defined pattern at a pre-defined location.
quoted
if not, then the driver stays in a safe mode (slow).
Same for my patches.
quoted
quoted
In our case we need to flash a
known pattern at some location (which is passed in via DT). Do you need
to run it for every read transaction or just once after the flash is
initialized?
Just once because it is a heavy process. See the debug outputs below.
Once we have good read timings and frequency, there is no need to do
it each time.
It looks very similar to the tuning I implemented in my patch series.
You should be able to use those APIs for your tuning as well. But it
should not block the SPI MEM port. The current upstream driver does not
seem to implement this tuning anyway.
spimem needs an extension I think. Sorry I have not been able to
push that forward. Lack of time and other tasks to address on the
host side of the machine. This is really a software problem, we
have the HW procedures ready. If a spimem expert could get involved
to make a few proposals, I would be happy to help and do some testing.
QEMU models are good enough for the software part. We can do the
training validation on real HW when ready.
What information about the flash do you need for this training?
Last time I looked, we lacked some post_init handler to setup a slave:
configure the registers defining the AHB windows for each flash
slave and perform the read timing calibration. calibration should
only be done once.
See how the aspeed_spi_flash_init() routine doing the calibration
is hooked up under aspeed_spi_claim_bus() in the u-boot driver :
My patch series should provide a hook for doing the calibration _after_
the flash is initialized.
You can also use the .dirmap_create handler. The flash device has
been scanned when called and the size is available in the spi-mem
dirmap descriptor.
I feel uncomfortable doing that since the API does not actually make
this guarantee. Who knows if a future change will violate that
assumption. That is why I added a new API call to explicitly mark the
flash as ready. I suppose you can get the op from the .dirmap_create
handler, but I guess we can debate that over the patches.
I reworked the current Aspeed driver with this approach and it
seems sufficient for read calibration.
Thanks,
C.