Memory mapped flash access breaks Broadcom NAND controller based access

[Florian Fainelli]

Hi Rafal,

On 8/31/23 08:30, Rafał Miłecki wrote:
> Hi,
> 
> Broadcom Northstar platform has SPI controller and NAND controller
> v6.1. Devices can come with serial or NAND flashes (or both).
> 
> To provide early access to configuration data (NVRAM) stored on flash
> Northstar provides MMIO mappings:
> #define SI_NS_NANDFLASH            0x1c000000    /* NorthStar NAND flash base */
> #define SI_NS_NORFLASH            0x1e000000    /* NorthStar NOR flash base */
> 
> It's possible to ioremap those and read flash content. Details:
> Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
> drivers/nvmem/brcm_nvram.c
> 
> The problem is that reading flash that way breaks NAND controller
> based access using brcmnand driver. A simple readb() triggers errors
> like:
> [  120.098439] SQUASHFS error: xz decompression failed, data probably corrupt
> [  120.105371] SQUASHFS error: Failed to read block 0x3b8c02: -5
> [  120.111158] SQUASHFS error: Unable to read metadata cache entry [3b8c00]
> [  120.117877] SQUASHFS error: Unable to read inode 0x6760785
> or
> [    3.120527] ubi0 error: 0xc04f0b3c: PEB 0 contains corrupted VID
> header, and the data does not contain all 0xFF
> [    3.130664] ubi0 error: 0xc04f0b4c: this may be a non-UBI PEB or a
> severe VID header corruption which requires manual inspection
> 
> I assume that whatever hardware provides MMIO based access it
> interferences with NAND controller.

Yes there is a good chance that the MMIO interface which uses the NAND 
controller underneath does not play ball when the NAND controller is in 
use. Even on non-Northstar chips, we do not seem to have designed the 
MMIO interface such that it would have a hardware enforced mutual 
exclusion mechanism.

> 
> Is that something that could be solved in brcmnand? Or should Linux
> just don't use MMIO post-booting (after brcmnand initializes)? Is
> there some generic cross-subsystem method to achieve that?

I suppose you could have a lock exposed by either driver and grabbed by 
both to serialize accesses? Unless there is a better way to do that 
which would be to cache all of the values on boot and then no longer 
touch the memory mapped interface?
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20230831/f3f06722/attachment.p7s>