Thomas Petazzoni | 10 Feb 14:54 2016
Gravatar

[PATCH v2] mtd: nand: pxa3xx_nand: add support for partial chunks

This commit is needed to properly support the 8-bits ECC configuration
with 4KB pages.

When pages larger than 2 KB are used on platforms using the PXA3xx
NAND controller, the reading/programming operations need to be split
in chunks of 2 KBs or less because the controller FIFO is limited to
about 2 KB (i.e a bit more than 2 KB to accomodate OOB data). Due to
this requirement, the data layout on NAND is a bit strange, with ECC
interleaved with data, at the end of each chunk.

When a 4-bits ECC configuration is used with 4 KB pages, the physical
data layout on the NAND looks like this:

| 2048 data | 32 spare | 30 ECC | 2048 data | 32 spare | 30 ECC |

So the data chunks have an equal size, 2080 bytes for each chunk,
which the driver supports properly.

When a 8-bits ECC configuration is used with 4KB pages, the physical
data layout on the NAND looks like this:

| 1024 data | 30 ECC | 1024 data | 30 ECC | 1024 data | 30 ECC | 1024 data | 30 ECC | 64 spare | 30 ECC |

So, the spare area is stored in its own chunk, which has a different
size than the other chunks. Since OOB is not used by UBIFS, the initial
implementation of the driver has chosen to not support reading this
additional "spare" chunk of data.

Unfortunately, Marvell has chosen to store the BBT signature in the
OOB area. Therefore, if the driver doesn't read this spare area, Linux
(Continue reading)

Nikita Nazarenko | 9 Feb 19:12 2016

[PATCH] mtd: spi-nor: Add support for ISSI is25lp128

Signed-off-by: Nikita Nazarenko <nnazarenko <at> radiofid.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ed0c19c..e0bb151 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
 <at>  <at>  -739,6 +739,7  <at>  <at>  static const struct flash_info spi_nor_ids[] = {

 	/* ISSI */
 	{ "is25cd512", INFO(0x7f9d20, 0, 32 * 1024,   2, SECT_4K) },
+	{ "is25lp128", INFO(0x9d6018, 0, 32 * 1024,   512, SECT_4K) },

 	/* Macronix */
 	{ "mx25l512e",   INFO(0xc22010, 0, 64 * 1024,   1, SECT_4K) },
--

-- 
2.7.0

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Jeff Stevens | 7 Feb 21:05 2016

hi Linux

Hello Linux

http://EngineeringLabSymposium.com/tip.php?guess=12hf1uar8f5s

Jeff

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Interfax Online | 4 Feb 17:49 2016
Picon

You have new fax, document 000145710

A new fax document for you.

Please check your fax document in the attachment to this e-mail.

Pages sent:      9
Fax name:        scan.000145710.doc
Processed in:    40 seconds
Scanned:         Thu, 4 Feb 2016 14:09:08 +0300
File size:       235 Kb
Author:          Chad Adams
Quality:         300 DPI

Thanks for using Interfax service!

Attachment (scan.000145710.zip): application/zip, 1983 bytes
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Mrs Machiko Kumiko | 29 Jan 12:59 2016
Picon

Yours Truely Mrs Machiko Kumiko

Hi Dear, 

I am Mrs Machiko Kumiko, from Japan, I Have Been Diagnosed with esophageal Cancer. 
I Have Chosen you to distribute my Funds to Charities homes in your Country, 
so if you wish to Carry out this humanitarian Work kindly Get back to me for FURTHER details. 

Yours Truely Mrs Machiko Kumiko

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Interfax Service | 29 Jan 10:38 2016
Picon

You have received a new fax, document 00943502

You have a new fax!

Scanned fax document is attached to this email.

Number of pages:    9
Scanned:            Fri, 29 Jan 2016 07:18:03 +0300
Scanned by:         Charles Montgomery
File name:          document.00943502.doc
Scan duration:      32 seconds
File size:          139 Kb
Resolution:         500 DPI

Thank you for using Interfax!

Attachment (document.00943502.zip): application/zip, 2012 bytes
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Szabó Tamás | 27 Jan 16:36 2016
Picon

JFFS2 deadlock

Hello all,

I work on an embedded system running Linux 3.10 and found a deadlock
situation between jffs2_readpage and jffs2_write.
The problem is present on the latest 4.4 kernel too and occurs when
two tasks want to access the same file, one reads and the other writes it.

The kernel stack traces for writer and reader in deadlock:

__switch_to+0x4c/0x98
sleep_on_page+0x10/0x24
__lock_page+0x8c/0x9c
find_lock_page+0x7c/0x94
grab_cache_page_write_begin+0x64/0xd8
jffs2_write_begin+0x6c/0x2ec
generic_file_buffered_write+0x188/0x258
__generic_file_aio_write+0x1e0/0x484
generic_file_aio_write+0x70/0xfc
do_sync_write+0x7c/0xd4
vfs_write+0xc8/0x1b0
SyS_write+0x4c/0xa8
ret_from_syscall+0x0/0x38

__switch_to+0x4c/0x98
jffs2_readpage+0x28/0x5c
generic_file_aio_read+0x22c/0x7a0
do_sync_read+0x7c/0xd4
vfs_read+0xb0/0x170
SyS_read+0x4c/0xa8
ret_from_syscall+0x0/0x38
(Continue reading)

Thomas Petazzoni | 27 Jan 14:32 2016
Gravatar

[PATCH] mtd: nand: pxa3xx_nand: add support for partial chunks

This commit is needed to properly support the 8-bits ECC configuration
with 4KB pages.

When pages larger than 2 KB are used on platforms using the PXA3xx
NAND controller, the reading/programming operations need to be split
in chunks of 2 KBs or less because the controller FIFO is limited to
about 2 KB (i.e a bit more than 2 KB to accomodate OOB data). Due to
this requirement, the data layout on NAND is a bit strange, with ECC
interleaved with data, at the end of each chunk.

When a 4-bits ECC configuration is used with 4 KB pages, the physical
data layout on the NAND looks like this:

| 2048 data | 32 spare | 30 ECC | 2048 data | 32 spare | 30 ECC |

So the data chunks have an equal size, 2080 bytes for each chunk,
which the driver supports properly.

When a 8-bits ECC configuration is used with 4KB pages, the physical
data layout on the NAND looks like this:

| 1024 data | 30 ECC | 1024 data | 30 ECC | 1024 data | 30 ECC | 1024 data | 30 ECC | 64 spare | 30 ECC |

So, the spare area is stored in its own chunk, which has a different
size than the other chunks. Since OOB is not used by UBIFS, the initial
implementation of the driver has chosen to not support reading this
additional "spare" chunk of data.

Unfortunately, Marvell has chosen to store the BBT signature in the
OOB area. Therefore, if the driver doesn't read this spare area, Linux
(Continue reading)

Rafał Miłecki | 27 Jan 08:58 2016
Picon

[PATCH] mtd: brcmnand: set initial ECC params based on info from HW

So far we were depending on nand_dt_init getting ECC info from DT and
setting it in ECC struct. It is possible to simply read this info from
hardware registers which makes adding support for new hardware way
easier (no more guessing & trying all combinations).
Please note it still gives a precedence to DT which was overwrite
whatever was initially set by the driver.

Signed-off-by: Rafał Miłecki <zajec5 <at> gmail.com>
---
It took me hours to figure out how to setup NAND on my D-Link DIR-885L.
This should be very helpful for ppl adding new devices support.
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
index 844fc07..f358cda 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
 <at>  <at>  -615,6 +615,17  <at>  <at>  static inline u32 brcmnand_ecc_level_mask(struct brcmnand_controller *ctrl)
 	return mask << NAND_ACC_CONTROL_ECC_SHIFT;
 }

+static int brcmnand_get_ecc_strength(struct brcmnand_host *host)
+{
+	struct brcmnand_controller *ctrl = host->ctrl;
+	u32 mask = brcmnand_ecc_level_mask(ctrl);
+	u16 acc_control_offs = brcmnand_cs_offset(ctrl, host->cs,
+						  BRCMNAND_CS_ACC_CONTROL);
+
(Continue reading)

Brian Norris | 26 Jan 22:36 2016
Picon

[mtd-utils PATCH] Makefile: install: don't look for scripts in BUILDDIR

Our ${SCRIPTS} (e.g., flash_eraseall) are not found in the build
directory; they should be found in their original location.

This fixes a typo in the Makefile refactoring, which caused 'make
install' to fail with messages like:

  make: *** No rule to make target '[...my source-build
directory...]/armv7a-cros-linux-gnueabi/misc-utils/flash_eraseall'. Stop.

because the install target is looking in the wrong place for
flash_eraseall.

Fixes: 7d81790ced34 ("mtd-utils: Restructure the mtd-utils source.")
Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
Cc: Dongsheng Yang <yangds.fnst <at> cn.fujitsu.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index bd9504ae72f0..977c9c5056ed 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -67,7 +67,7  <at>  <at>  endif
 	rm -f $(BUILDDIR)/include/version.h
 	$(MAKE) -C $(TESTS) clean

-install:: $(addprefix $(BUILDDIR)/,${BINS} ${SCRIPTS})
+install:: $(addprefix $(BUILDDIR)/,${BINS}) ${SCRIPTS}
 	mkdir -p ${DESTDIR}/${SBINDIR}
(Continue reading)

Jared Hulbert | 26 Jan 02:10 2016
Picon

PMEM, DAX, MTD, and the quest for the Theory of Everything

I'm not seeing any traffic connecting MTD, PMEM, and DAX.  Any
discussions I should be aware of?

MTD devices like SPI-NOR and the inevitable spillover into the
embedded market of 3D Xpoint and similar technologies are excluded
from the DAX game.  Considering all the years we spent playing with
XIP in MTD...   well that's what happens when you disengage for
several years.

A few thoughts...

#1 - MTD provides various ways to partition memory semantic devices as
reprogramable ROMs for storage of bootloaders, kernel, rootfs images,
etc.  Does PMEM have anything to learn from this?  Or does the MTD
layer have an opportunity to gain something by using PMEM standards?

#2 - MTD has had an API that allowed direct access (see point() in
struct mtd_info) and block-ish semantic access of persistent memory
devices since, I dunno, before bitkeeper?  Can we hook this up with
DAX?  Read Only should be "trivial" especially if someone else does
it. :)

#3 - There has long been a desire to merge MTD with the block
subsystem with some members of the MTD community.  PMEM seems to
create a precedent for a block interface on a device that isn't
fundamentally block based.  Also the direct_access() in block has been
legitimized with the recent DAX stuff.   Is it time now?

My vision here is to enable Read-Only DAX images of EXT4, AXFS, PRAMFS
on ROM/NOR devices in a standard DAX way.
(Continue reading)


Gmane