[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211223002225.3738385-1-f.fainelli@gmail.com>
Date: Wed, 22 Dec 2021 16:22:16 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: linux-mtd@...ts.infradead.org
Cc: Florian Fainelli <f.fainelli@...il.com>,
Rafał Miłecki <zajec5@...il.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Brian Norris <computersforpeace@...il.com>,
Kamal Dasu <kdasu.kdev@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Cai Huoqing <caihuoqing@...du.com>,
Colin Ian King <colin.king@...el.com>,
linux-kernel@...r.kernel.org (open list),
linux-wireless@...r.kernel.org (open list:BROADCOM SPECIFIC AMBA DRIVER
(BCMA)),
bcm-kernel-feedback-list@...adcom.com (open list:BROADCOM STB NAND
FLASH DRIVER)
Subject: [PATCH 0/9] BCMA support for brcmnand
Hi all,
This patch series adds support for the BRCMNAND controller revision 3.4
embedded in MIPS-based SoCs such as 5357, typically found in the Netgear
WNR3500L v2 and other kinds of Wi-Fi routers. The upstream platform that
uses this controller is under arch/mips/bcm47xx/ and does not use Device
Tree (and probably never will by now). BCMA (Broadcom AMBA) is a special
kind of discoverable memory mapped interface which requires the use of
special accessors to read from/write to the hardware block.
The integration of brcmnand into that SoC is a bit quirky in that every
register offering byte level data about the flash (OOB, device ID, etc.)
requires byte swapping. The command shift should also have been 24, but
is in fact 0, took me a while to understand why no reads were actually
working because of that.
This has been tested with Linux 5.10.82 and Linus' master with OpenWrt
and confirmed that the squashfs + jffs2 overlay that OpenWrt creates is
entirely functional and that written data is made persistent.
There are a number of open questions:
- the flash that is used is a s34ml01g100tf100 part which is said to be
ONFI 1.0 compliant however the ONFI signature is not ONFI, but the
device ID of the flash as if read with address 0, is that a known
issue?
- because no ONFI detection is taking place we fallback to the
identification table matching, but there is no default ECC
size/strength filed by the rawnand framework, probably made largely
worse by the absence of a suitable Device Tree information?
Florian Fainelli (9):
mtd: rawnand: brcmnand: Allow SoC to provide I/O operations
mtd: rawnand: brcmnand: Assign soc as early as possible
mtd: rawnand: brcmnand: Avoid pdev in brcmnand_init_cs()
mtd: rawnand: brcmnand: Move OF operations out of brcmnand_init_cs()
mtd: rawnand: brcmnand: Allow working without interrupts
mtd: rawnand: brcmnand: Add platform data structure for BCMA
mtd: rawnand: brcmnand: Allow platform data instantation
mtd: rawnand: brcmnand: BCMA controller uses command shift of 0
mtd: rawnand: brcmnand: Add BCMA shim
MAINTAINERS | 1 +
drivers/bcma/driver_chipcommon_nflash.c | 17 ++-
drivers/mtd/nand/raw/Kconfig | 11 ++
drivers/mtd/nand/raw/brcmnand/Makefile | 2 +
drivers/mtd/nand/raw/brcmnand/bcma_nand.c | 131 ++++++++++++++++++
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 142 +++++++++++++-------
drivers/mtd/nand/raw/brcmnand/brcmnand.h | 23 ++++
include/linux/bcma/bcma_driver_chipcommon.h | 5 +
include/linux/platform_data/brcmnand.h | 12 ++
9 files changed, 291 insertions(+), 53 deletions(-)
create mode 100644 drivers/mtd/nand/raw/brcmnand/bcma_nand.c
create mode 100644 include/linux/platform_data/brcmnand.h
--
2.25.1
Powered by blists - more mailing lists