Obuariver Goldmines | 20 Sep 19:54 2014

Dear Sir, We are gold mining company located in sub region of West Africa in San Pedro-Cote D'Ivoire looking for real and potential gold buyers and mandates to buy or market our gold nuggets, dust and Dore bars. We have been in the mining business in Cote D' Ivoire for many years and have good experience in international trade from West Africa. You can expect good clean deals through us as we have built a loyal clientele all across the world who are seeking gold from the West Africa region. Our prices are very attractive in the International market.We look forward to a good business relationship with your company. If you have any questions please call or email us anytime. We look forward to your prompt reply and are ready, willing and able to deliver upon your request. Best Regards, CHIEF.YAPI AMAN

Linux MTD discussion mailing list

hujianyang | 20 Sep 08:55 2014

[PATCH] UBIFS: Align the dump messages of SB_NODE

I found the dump messages of UBIFS_SB_NODE is not aligned. This
patch remove the extra space from the line which is retracted.

Signed-off-by: hujianyang <hujianyang <at> huawei.com>
 fs/ubifs/debug.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ubifs/debug.c b/fs/ubifs/debug.c
index 177b015..d0bcf92 100644
--- a/fs/ubifs/debug.c
+++ b/fs/ubifs/debug.c
 <at>  <at>  -334,9 +334,9  <at>  <at>  void ubifs_dump_node(const struct ubifs_info *c, const void *node)
 		pr_err("\tkey_fmt        %d (%s)\n",
 		       (int)sup->key_fmt, get_key_fmt(sup->key_fmt));
 		pr_err("\tflags          %#x\n", sup_flags);
-		pr_err("\t  big_lpt      %u\n",
+		pr_err("\tbig_lpt        %u\n",
 		       !!(sup_flags & UBIFS_FLG_BIGLPT));
-		pr_err("\t  space_fixup  %u\n",
+		pr_err("\tspace_fixup    %u\n",
 		       !!(sup_flags & UBIFS_FLG_SPACE_FIXUP));
 		pr_err("\tmin_io_size    %u\n", le32_to_cpu(sup->min_io_size));
 		pr_err("\tleb_size       %u\n", le32_to_cpu(sup->leb_size));


Linux MTD discussion mailing list
(Continue reading)

hujianyang | 20 Sep 06:59 2014

[PATCH RFC v3] ubi-utils: Introduce a utility ubidump

Hi all,

It's about two months after the pushing of my v2 patches. I'd like
to resend these v3 patches and discuss with you about the debugging
of UBIFS. I wish you are not tried with this stuff.

I have to say these v3 patches don't make a great difference with
the previous versions. Just simplify, I've removed ubi-level dump.
So the lpt-leb dump is not supported as before. I want to know if
we could start at this version and add other functionality step by




Changes in v3:
 - Remove ubi-level dump so we don't need to worry about how to
   get ubi-level info from an UBI device.
 - Read ubifs stuff by read() ops which is provided by UBI driver.

Linux MTD discussion mailing list

(Continue reading)

Richard Weinberger | 19 Sep 17:37 2014

[PATCH] UBI: Fix livelock in produce_free_peb()

The while loop in produce_free_peb() assumes that each work will produce a
free PEB. This is not true.
If ubi->works_count is 1 and the only scheduled work is the
wear_leveling_worker() produce_free_peb() can loop forever in case
nobody schedules an erase work.
Fix this issue by checking in the while loop whether work is scheduled.

Signed-off-by: Richard Weinberger <richard <at> nod.at>
 drivers/mtd/ubi/wl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 0509c8a..6add739 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
 <at>  <at>  -272,7 +272,7  <at>  <at>  static int produce_free_peb(struct ubi_device *ubi)
 	int err;

-	while (!ubi->free.rb_node) {
+	while (!ubi->free.rb_node && ubi->works_count) {

 		dbg_wl("do one work synchronously");


Linux MTD discussion mailing list
(Continue reading)

Robert Hurdle | 17 Sep 23:59 2014

Question about adding a NAND device


	I have ported some of u-boot to our board, and I am booting successfully from EEPROM.
	I am now in the process of adding the NAND and flash file system support for our non-standard
	flash interface (there's an FPGA interface between the software and the 1 giga-byte NAND) to
	u-boot and also to the Linux kernel.  In addition, it is our intention to support UBIFS on our board.

	It appears that I need to understand how the structures mtd_info and nand_chip (and whatever
	they point at) and code in nand_base.c work, in order to provide working routines at the NAND
	level.  I have looked at some of the files in u-boot/drivers/mtd/nand for other boards, and see
	a wide variety of models, no doubt based on the hardware differences.   Because of our FPGA
	interface, I need to have all commands to the NAND chip get re-packaged into commands that
	get passed to the FPGA.  Am I on the right path?  

	My other question is how long would one guess that this task would take for someone fairly
	competent, but uninitiated in UBIFS, UBI, MTD, NAND, etc. ?

	Any advice is appreciated.

	Thank you,

	Robert Hurdle
	Aitech Defense Systems (Space Division)

Linux MTD discussion mailing list

Aaron Sierra | 17 Sep 20:08 2014

[PATCH 2/2] mtd: physmap_of: Add non-obsolete map_rom probe

Previously, the only way to map a NOR device as a simple ROM was to
use the obsolete "direct-mapped" compatible binding (which further
requires device_type = "nor" and probe-type = "NOR" properties).

This patch adds an "mtd-rom" compatible binding to the "map_rom"
probe type.

Signed-off-by: Aaron Sierra <asierra <at> xes-inc.com>
 Documentation/devicetree/bindings/mtd/mtd-physmap.txt | 4 ++--
 drivers/mtd/maps/physmap_of.c                         | 4 ++++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
index 61c5ec8..6b9f680 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
 <at>  <at>  -4,8 +4,8  <at>  <at>  Flash chips (Memory Technology Devices) are often used for solid state
 file systems on embedded devices.

  - compatible : should contain the specific model of mtd chip(s)
-   used, if known, followed by either "cfi-flash", "jedec-flash"
-   or "mtd-ram".
+   used, if known, followed by either "cfi-flash", "jedec-flash",
+   "mtd-ram" or "mtd-rom".
  - reg : Address range(s) of the mtd chip(s)
    It's possible to (optionally) define multiple "reg" tuples so that
    non-identical chips can be described in one node.
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 63d82da..c1d21cb 100644
(Continue reading)

Aaron Sierra | 17 Sep 20:08 2014

[PATCH 1/2] mtd: physmap_of: Fix ROM support via OF

The "ROM" and unknown probe types within the obsolete "direct-mapped"
probe function used the nonexistent "mtd_rom" probe instead of the
intended "map_rom".

Signed-off-by: Aaron Sierra <asierra <at> xes-inc.com>
 drivers/mtd/maps/physmap_of.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 217c25d..63d82da 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
 <at>  <at>  -103,7 +103,7  <at>  <at>  static struct mtd_info *obsolete_probe(struct platform_device *dev,
 		if (strcmp(of_probe, "ROM") != 0)
 			dev_warn(&dev->dev, "obsolete_probe: don't know probe "
 				 "type '%s', mapping as rom\n", of_probe);
-		return do_map_probe("mtd_rom", map);
+		return do_map_probe("map_rom", map);



Linux MTD discussion mailing list

(Continue reading)

Rostislav Lisovy | 16 Sep 18:22 2014

Destructive nandtest?

I need to test a NAND flash on my embedded device running GNU/Linux.
I thought the nandtest utility will work just fine, however I hit some
unpleasant behavior.
My requirement is to perform a non-destructive test. The nandtest
utility seems to support it with the "-k, --keep  Restore existing
contents after test" option, however the reality is different.
The testing scenario (performed by the nandtest) is
* Backup the original eraseblock (EB) data
* Generate some random data
* Erase the EB
* Store the random data
* Read the stored data and compare with the generated buffer
* Erase the EB, Write the original content

Everything seems to make sense until we ask the question "what about the
OOB data?". Is the original OOB data saved? The answer is: No, it is
This will somehow work in cases the OOB stores only the ECC for the
written pages -- if we read the page (OOB contains the ECC), erase the
EB and then write the same page back, the OOB will once again contain
the same ECC. What if there will be some "extra data" stored in the OOB
(I think JFFS2 does this)? This data will be lost.

Another sneaky misbehavior is "restoring of erased pages". If the EB is
erased (all 0xFF), the nandtest reads the "data stored in the EB",
performs the tests and then restores the "data" back by filling all the
pages with 0xFF -- this will not only fill the OOB with ECC for the
newly written "data" but will deplete the "maximum per-page-write
limit" (which is either 1x after each erase or more if the sub-page
(Continue reading)

Atlant Schmidt | 16 Sep 16:04 2014

Does UBI LEB-level access interlock happily with UBIfs access?


  We use the ordinary MTD/UBI/UBIfs stack on our
  Embedded Linux system.

  For the purposes of scrubbing-out single bit errors,
  I'd like to read through all of the LEBs stored in the
  UBI device and whenever the ECC information indicates
  that any correctable errors occurred, I'd like to
  *RE-WRITE* that LEB (thereby forcing it to be scrubbed).
  (Note: I might do this page-by-page rather than LEB-

  But I would expect that because I'd have a hard
  (impossible?) time doing an atomic read/re-write of a
  LEB (or page), the UBIfs and my scrubber would interact
  badly with my scrubber eventually corrupting the UBIfs
  file system. Is there any easy way to interlock these
  accesses (from the UBIfs and from my UBI-level scrubber)?
  A way to temporarily suspend activity from the UBIfs?

  One kludge that might work is that I'm operating in a
  real-time environment. If I made my scrubbing requests
  from a very high priority (higher than the "System"
  tasks that run around Priority 50), could I be sure
  my read + rewrite scrubbing requests would at least
  enter the UBI's work queue immediately adjacent to
  each other (and without UBIfs requests intermingled)?

  Alternatively, I could probably dismount the UBIfs
(Continue reading)

Yegor Yefremov | 16 Sep 15:57 2014

MTD autorepartitioning

I've found an old discussion, that references following commits (mtd:
add BLKPG API based repartition support) and also this patch

What user space tool can I use to repartition my NAND flash? There is
no "master" /dev/mtdblock device, that I can pass to fdisk or do I see
it wrong?


Linux MTD discussion mailing list

Richard Weinberger | 16 Sep 09:48 2014

[PATCH] UBI: Fix possible deadlock in erase_worker()

If sync_erase() failes with EINTR, ENOMEM, EAGAIN or
EBUSY erase_worker() re-schedules the failed work.
This will lead to a deadlock because erase_worker() is called
with work_sem held in read mode. And schedule_erase() will take
this lock again.

Fix this issue by adding a locked flag to schedule_erase(),
it indicates whether the caller owns work_sem already.

[   16.571519] [ INFO: possible recursive locking detected ]
[   16.571519] 3.17.0-rc4+ #69 Not tainted
[   16.571519] ---------------------------------------------
[   16.571519] ubi_bgt0d/2607 is trying to acquire lock:
[   16.571519]  (&ubi->work_sem){.+.+..}, at: [<ffffffff8154eaee>] schedule_ubi_work+0x1e/0x40
[   16.571519]
[   16.571519] but task is already holding lock:
[   16.571519]  (&ubi->work_sem){.+.+..}, at: [<ffffffff8154e7ec>] do_work+0x3c/0x110
[   16.571519]
[   16.571519] other info that might help us debug this:
[   16.571519]  Possible unsafe locking scenario:
[   16.571519]
[   16.571519]        CPU0
[   16.571519]        ----
[   16.571519]   lock(&ubi->work_sem);
[   16.571519]   lock(&ubi->work_sem);
[   16.571519]
[   16.571519]  *** DEADLOCK ***
[   16.571519]
[   16.571519]  May be due to missing lock nesting notation
[   16.571519]
(Continue reading)