Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support
From: Brian Norris
Date: Mon Mar 09 2015 - 14:04:46 EST
On Sun, Mar 08, 2015 at 11:22:40AM +0100, RafaÅ MiÅecki wrote:
> On 8 March 2015 at 01:57, Brian Norris <computersforpeace@xxxxxxxxx> wrote:
> > 2. Endianness is a known issue with at least one other platform. On many
> > chips (spanning MIPS LE, MIPS BE, and ARM LE), NAND has been integrated
> > such that data can just be read/programmed in the native endianness
> > through the FLASH_CACHE registers (as this driver does), but there are a
> > few (on ARM, LE) that require a be32_to_cpu()/cpu_to_be32() swap. I'm
> > considering supporting DT properties like one of the following:
> > brcm,nand-cache-be
> > brcm,nand-cache-big-endian
> > brcm,nand-cache-reverse-endian
> > You might also check (though I might actually be better equipped for
> > this) if there is a separate register that can tell the NAND data bus to
> > automatically endian-swap data into the native endianness. I know a lot
> > of the buses and peripherals in BCG, at least, are designed such that
> > either (1) they can work naturally in the CPU's native endianness or
> > else (2) they can be configured to swap endianness into either format.
> > But if such a register does not exist, then we'll definitely have to do
> > something like the DT property above.
> It seems there is such a magic register. Please take a look at bcm_nand.c:
> There are multiple places (data, OOB, reads, writes) with:
So you do data and OOB in little endian? At least that seems consistent.
> /* Set controller to Little Endian mode for copying */
> bcmnand_reg_awrite(ctrl, NANDC_IDM_APB_LITTLE_ENDIAN, 1);
> /* Return to Big Endian mode for commands etc */
> bcmnand_reg_awrite(ctrl, NANDC_IDM_APB_LITTLE_ENDIAN, 0);
> That register is 0x408, but it's in "agent" core (AKA wrapper), so
> it's separated mapping. I'm not sure what address is it right now, as
> we read them from the EROM.
> > Do the bad block markers look OK without extra endian swapping? I'm
> > wondering whether the swapping will have to occur on both the
> > FLASH_CACHE and SPARE_AREA registers.
> I don't know, I didn't try nand-on-flash-bbt.
You don't have to use on-flash BBT to notice. Without a flash-based BBT,
you should just be scanning for bad block markers on *every* boot. Do
you read factory-marked bad block markers correctly? Or maybe you see no
factory bad blocks?
Note that this is sometimes hard to tell, if the factory just programmed
the entire page + OOB to 0x00; then you obviously don't have to worry
about endianness. But if they programmed a word of 0xffffff00, then you
definitely do need to care!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/