Memory mapped flash access breaks Broadcom NAND controller based access

[Scott Branden]

HI Rafal,


On Thu, Aug 31, 2023 at 8:30 AM Rafał Miłecki <zajec5 at gmail.com> 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.
>
> 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?
Yes, you should just not use MMIO post-booting.  The NAND driver is
sufficient for all uses cases is it not?

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