lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACna6rz656H-K1hPaSGyOE+x4RKfqdUdnWKhff87n=0dvHB+fw@mail.gmail.com>
Date:	Sun, 8 Mar 2015 11:22:40 +0100
From:	Rafał Miłecki <zajec5@...il.com>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	Dmitry Torokhov <dtor@...gle.com>,
	Anatol Pomazao <anatol@...gle.com>,
	Ray Jui <rjui@...adcom.com>,
	Corneliu Doban <cdoban@...adcom.com>,
	Jonathan Richardson <jonathar@...adcom.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	bcm-kernel-feedback-list@...adcom.com,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kevin Cernekee <cernekee@...il.com>
Subject: Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support

On 8 March 2015 at 01:57, Brian Norris <computersforpeace@...il.com> 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:
https://dev.openwrt.org/browser/trunk/target/linux/bcm53xx/patches-3.18/420-mtd-bcm5301x_nand.patch

There are multiple places (data, OOB, reads, writes) with:

/* 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.

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ