Skip to content

Commit

Permalink
Revert "Add SMI NAND driver"
Browse files Browse the repository at this point in the history 
This reverts commit b1521a1.
  • Loading branch information
@popcornmix
popcornmix committed Apr 2, 2019
1 parent 92e316d commit 72ce5a4
Show file tree
Hide file tree
Showing 4 changed files with 0 additions and 308 deletions.
42 changes: 0 additions & 42 deletions Documentation/devicetree/bindings/mtd/brcm,bcm2835-smi-nand.txt
View file

This file was deleted.

7 changes: 0 additions & 7 deletions drivers/mtd/nand/raw/Kconfig
View file
Original file line number Diff line number Diff line change
Expand Up @@ -40,13 +40,6 @@ config MTD_SM_COMMON
tristate
default n

config MTD_NAND_BCM2835_SMI
tristate "Use Broadcom's Secondary Memory Interface as a NAND controller (BCM283x)"
depends on BCM2835_SMI
default m
help
Uses the BCM2835's SMI peripheral as a NAND controller.

config MTD_NAND_DENALI
tristate

Expand Down
1 change: 0 additions & 1 deletion drivers/mtd/nand/raw/Makefile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,6 @@ obj-$(CONFIG_MTD_NAND_DENALI) += denali.o
obj-$(CONFIG_MTD_NAND_DENALI_PCI) += denali_pci.o
obj-$(CONFIG_MTD_NAND_DENALI_DT) += denali_dt.o
obj-$(CONFIG_MTD_NAND_AU1550) += au1550nd.o
obj-$(CONFIG_MTD_NAND_BCM2835_SMI) += bcm2835_smi_nand.o
obj-$(CONFIG_MTD_NAND_S3C2410) += s3c2410.o
obj-$(CONFIG_MTD_NAND_TANGO) += tango_nand.o
obj-$(CONFIG_MTD_NAND_DAVINCI) += davinci_nand.o
Expand Down
258 changes: 0 additions & 258 deletions drivers/mtd/nand/raw/bcm2835_smi_nand.c
View file

This file was deleted.

8 comments on commit 72ce5a4

@TheCrazyT
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@popcornmix

Today I wanted to experiment with smi-nand-overlay to dump a nand-chip connected to the smi-pins of the raspberry pi.
I was wondering about missing messages in dmesg.
Later i found out that this module was removed.

I don't understand why this module was removed while smi-nand-overlay.dts https://github.com/raspberrypi/linux/blob/rpi-5.10.y/arch/arm/boot/dts/overlays/smi-nand-overlay.dts still exists.
Maybe i'm misunderstanding something?

I also don't understand why:
sudo dtoverlay -v smi-nand
won't fail while "bcm2835-smi-nand" clearly does not exist on kernel 5.10.17-v7+ .

Was this code removed because it wasn't working, or because nobody used it?

@popcornmix
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was dropped due to conflicts when moving to the newer kernel.
And it's not been re-added as no one was using it.
You are the first to notice after it was dropped 2.5 years ago.
The overlay should have ideally have been removed.

You could try re-adding it back
git cherry-pick 9e5e1dc0
but I suspect it will need some fixing up.

@TheCrazyT
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@popcornmix

Thanks, i used that code and modified it to work with the current kernel.
Sadly it seems that the SMI interface is not reliable enough.
It sometimes seems to skip some read bytes.

For example the full Id of my nand is:
ADh DCh 10h 95h 54h

But it gets:
ADh 10h 95h 54h

Changing the timings a bit I got it to:
ADh DCh 95h 54h

Of course that causes problems detecting other nand-settings like OOB-size.
Cheating by disabling ecc made my driver work and i could use nanddump.
The dump itself contains readable strings.
Problem is that the dump itself is different every time.(sometimes missing some bytes)

Any Idea what could cause that problem?
(first i thought it is a pin connection mistake but i double checked that)

PS:
Wish there would have been a better documentation about that SMI interface on the internet :(

@popcornmix
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Wren6991 any suggestions?

@TheCrazyT
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@popcornmix
@Wren6991

I made some progress today, but only with a workaround.

i changed the following line:
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/mtd/nand/raw/nand_base.c#L1582
to use read_buf instead:
chip->legacy.read_buf(chip, id, len);

and changed:
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/mtd/nand/raw/nand_base.c#L4723
to:
ret = nand_readid_op(chip, 0, id_data, 5);

Now its successfully detecting my chip.
Well thats enough for the good news.

The bad news is that there seems to be a problem on reading small buffers.
I'm not shure if using an odd number like 5 changes the behaviour on bcm2835_smi_read_buf.

Another bad thing I noticed is that nanddump crashes silently.
dmesg shows the following: https://gist.github.com/TheCrazyT/77b19e074f9679da0c9eedd054de1f7c
"bcm2835_smi_read_buf" is inside that stacktrace so i believe there must be something wrong in it.

@Wren6991
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is your flash device attached over a 16 bit or 8 bit bus? Doing raw byte operations with SMI width of 16 is not going to go well, which may be why you saw a difference when patching the multiple read_byte()s with a single read_buf(). Even for 8-bit bus width, there is a difference in how the bytes modulo 4 are handled versus the main bulk of the transfer, since the SMI FIFO is 32 bits wide, which might be another reason you get different results with a single 5-byte call. It's hard to guess what is going on without more information or some logs.

This code did work at one point, but was not maintained and/or used.

@TheCrazyT
Copy link

@TheCrazyT TheCrazyT commented on 72ce5a4 Apr 9, 2021 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Wren6991

I'm using a 8 bit bus.

kern.log shows some additional information about my new problem:

Apr  9 16:02:28 raspberrypi kernel: [  132.146111] bcm2835-dma 3f007000.dma: dma_sync_wait: timeout!
Apr  9 16:02:28 raspberrypi kernel: [  132.146129] smi-bcm2835 3f600000.smi: SMI context dump: DMA timeout!
Apr  9 16:02:28 raspberrypi kernel: [  132.146141] smi-bcm2835 3f600000.smi: SMICS:  0xfc006005
Apr  9 16:02:28 raspberrypi kernel: [  132.146149] smi-bcm2835 3f600000.smi: SMIL:   0x000000f8
Apr  9 16:02:28 raspberrypi kernel: [  132.146157] smi-bcm2835 3f600000.smi: SMIDSR: 0x2010100b
Apr  9 16:02:28 raspberrypi kernel: [  132.146164] smi-bcm2835 3f600000.smi: SMIDSW: 0x2050100b
Apr  9 16:02:28 raspberrypi kernel: [  132.146172] smi-bcm2835 3f600000.smi: SMIDC:  0x10820fff
Apr  9 16:02:28 raspberrypi kernel: [  132.146181] smi-bcm2835 3f600000.smi: SMIFD:  0x00001f3e
Apr  9 16:02:28 raspberrypi kernel: [  132.146188] smi-bcm2835 3f600000.smi:  
Apr  9 16:02:28 raspberrypi kernel: [  132.146200] smi-bcm2835 3f600000.smi: SMI context dump: WARNING: read FIFO not empty at start of read call.
Apr  9 16:02:28 raspberrypi kernel: [  132.146208] smi-bcm2835 3f600000.smi: SMICS:  0xfc006005
Apr  9 16:02:28 raspberrypi kernel: [  132.146215] smi-bcm2835 3f600000.smi: SMIL:   0x000000f8
Apr  9 16:02:28 raspberrypi kernel: [  132.146223] smi-bcm2835 3f600000.smi: SMIDSR: 0x2010100b
Apr  9 16:02:28 raspberrypi kernel: [  132.146231] smi-bcm2835 3f600000.smi: SMIDSW: 0x2050100b
Apr  9 16:02:28 raspberrypi kernel: [  132.146238] smi-bcm2835 3f600000.smi: SMIDC:  0x10820fff
Apr  9 16:02:28 raspberrypi kernel: [  132.146246] smi-bcm2835 3f600000.smi: SMIFD:  0x00001f3e
Apr  9 16:02:28 raspberrypi kernel: [  132.146253] smi-bcm2835 3f600000.smi:

Wonder what could cause the "DMA timeout".
Looks like I'm running from one problem to another.

Btw.:
Currently it looks like all the blocks are marked as bad for some reason.
Earlier I was atleast able to use nanddump by luck, but now I'm not so lucky anymore.

Update:

Figured out that crash problem.
I was accidently setting:
smi_settings->dma_read_thresh = 0x3f;
because I thought It might have any impact on my main problem.

Now my only problem left is the skipped-byte problem during nanddump (that also causes alot of "uncorrectable bitflip(s)").
Hopefully I find a solution to this :-( .

@TheCrazyT
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to let you know, the skipping byte problem seems to be hardware related.
I was able to stabilize it a bit with a 200pF capacitor between read enable pin and ground.
Still not perfect and i guess its different depending on setup and settings.
(I can only estimate the amount of bytes skipped by the amount of 0xFF-bytes at the end of a read page of the nand by using nanddump with oob-data)

My digital oscilloscope was not much of a help since it seems to change the result while attached to the nand-chip.
But using it without anything attached I'm able to see some unusual spikes on gpio 6(SOE) that maybe could trigger some read instructions.

Please sign in to comment.