drivers/mtd/mtdoops.c: In function ‘mtdoops_console_sync’:
drivers/mtd/mtdoops.c:329: error: implicit declaration of function ‘in_interrupt’
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=9829
I found and solved the problem, at line 115 of drivers/mtd/chips/gen_probe.c
(kernel 2.6.24): mapsize value must be calculated in bytes, not in long.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
Acked-by: Joern Engel <joern@logfs.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Implement the panic_write function for the onenand driver. This waits
for any active command to complete/timeout, performs the write, waits
for it to complete and then returns.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
When the MTD provides a panic_write function, use it.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
MTDs are well suited for logging critical data and the mtdoops driver
allows kernel panics/oops to be written to flash in a blackbox flight
recorder fashion allowing better debugging and analysis of crashes.
Any kernel oops in user context can be easily handled since the kernel
continues as normal and any queued mtd writes are scheduled. Any kernel
oops in interrupt context results in a panic and the delayed writes will
not be scheduled however. The existing mtd->write function cannot be
called in interrupt context so these messages can never be written to
flash.
This patch adds a panic_write function pointer that drivers can
optionally implement which can be called in interrupt context. It is
only intended to be called when its known the kernel is about to panic
and we need to write to succeed. Since the kernel is not going to be
running for much longer, this function can break locks and delay to
ensure the write succeeds (but not sleep).
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Nick Spence <nick.spence@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
I have been prime author and maintainer of block2mtd from day one, but
neither MAINTAINERS nor the module source makes this fact clear. And while
I'm at it, update my email addresses tree-wide, as the old address
currently bounces and change my name to "joern" as unicode will likely
continue to cause trouble until the end of this century.
Signed-off-by: Joern Engel <joern@lazybastard.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch extends the physmap mapping driver to support multiple
resources for non-identical NOR chips that will be concatenated together
when selected.
This is needed for example for Intel 48F4400 512MBit chips, since they
consist of 2 single different NOR chips with different geometries. The
first (lower) one has botton boot sectors and the 2nd (upper) has top
boot sectors. This currently isn't handled correctly by calling the
physmap driver once with only one resource covering both chips in one
memory region. The same geometrie is used for both chips.
With this patch the following resource structure can be used to
describe the 48F4400 chip correctly:
static struct resource board_nor_resource[] = {
[0] = {
.start = 0xf8000000,
.end = 0xfbffffff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 0xfc000000,
.end = 0xffffffff,
.flags = IORESOURCE_MEM,
}
};
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
There is no suspend/resume operation in NFC driver at all, currently.
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
With CONFIG_MTD_PARTITIONS not set, got this:
drivers/mtd/nand/plat_nand.c:113: warning: unused variable 'pdata'
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Patch for unlocking all Intel flash that has instant locking on power up.
The patch has been tested on Intel M18, P30 and J3D Strata Flash.
1. The automatic unlocking can be disabled for a particular partition
in the map or the command line.
a. For the bit mask in the map it should look like:
.mask_flags = MTD_POWERUP_LOCK,
b. For the command line parsing it should look like:
mtdparts=0x80000(bootloader)lk
2. This will only unlock parts with instant individual block locking.
Intel parts with legacy unlocking will not be unlocked.
Signed-off-by: Justin Treon <justin_treon@yahoo.com>
Signed-off-by: Jared Hulbert <jaredeh@gmail.com>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Call parse_mtd_partitions before checking board's partition_info, so
that "mtdparts=" option can override board's default setting.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Various minor cleaups to mtdoops:
* Don't support the mtd->erasesize < OOPS_PAGE_SIZE case
* Tweak printks and make the device mtdoops connects to more visible
* CON_PRINTBUFFER flag is uneeded
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Add a spinlock to ensure writes to the mtdoops buffer memory are
sequential and don't race.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Writing to the flash needs to be done in a workqueue. The console
write functions may be called in any context which can lead to
lockups otherwise.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Add further error return code checks to the mtdoops driver.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
drivers/mtd/devices/lart.c:119:#define FLASH_DEVICE_16mbit_BOTTOM 0x88f488f4
As was, unless "manufacturer != FLASH_MANUFACTURER" this returned true
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
drivers/mtd/ubi/scan.c: In function 'ubi_scan':
drivers/mtd/ubi/scan.c:772: warning: 'ec' may be used uninitialized in this function
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
drivers/mtd/ubi/wl.c:746: warning: 'pe' may be used uninitialized in this function
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
This is just not necessary. We re-write whole layout copy, so
the old contents cannot show up again sice scan process will
drop it.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
In function onenand_verify_oob, local variable oobbuf shall be unsigned char.
In the case of a value is >= 0x80, it's unequal in comparing the value in an unsigned char and signed char.
Signed-off-by: Sheng Yongjie (Sam) <samsheng@trident.com.cn>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Consolidate OneNAND operation order as OneNAND Spec.
It also doesn't break previous operation order.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
The single-bit error correction was, well, incorrect. For determing which
bit to correct it was using P1' P2' P4' P8' instead of P1 P2 P4 P8, and
it was using P16' P32' P64' P128' P256' P512' P1024' P2048' instead of
P16 P32 P64 P128 P256 P512 P1024 P2048.
Signed-off-by: Matt Reimer <mreimer@vpop.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Instead of passing vol_id to all functions and then find
struct ubi_volume, pass struct ubi_volume pointer.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Since we do not change semantics of seek(), changing the file
pointer while updating does not make much sense.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Add more information about layout volume to make userspace tools
use the macros instead of constants. Also rename UBI_LAYOUT_VOL_ID
to make it consistent with other macros.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Old gcc complains:
CC drivers/mtd/ubi/wl.o
drivers/mtd/ubi/wl.c: In function 'wear_leveling_worker':
drivers/mtd/ubi/wl.c:746: warning: 'pe' may be used uninitialized in this function
CC drivers/mtd/ubi/scan.o
drivers/mtd/ubi/scan.c: In function 'ubi_scan':
drivers/mtd/ubi/scan.c:772: warning: 'ec' may be used uninitialized in this function
drivers/mtd/ubi/scan.c:772: note: 'ec' was declared here
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Since the data offset parameter was removed, the size of
the parameters array is now 2, not 3.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
The problem: NAND flashes have different amount of initial bad physical
eraseblocks (marked as bad by the manufacturer). For example, for 256MiB
Samsung OneNAND flash there might be from 0 to 40 bad initial eraseblocks,
which is about 2%. When UBI is used as the base system, one needs to know
the exact amount of good physical eraseblocks, because this number is
needed to create the UBI image which is put to the devices during
production. But this number is not know, which forces us to use the
minimum number of good physical eraseblocks. And UBI additionally
reserves some percentage of physical eraseblocks for bad block handling
(default is 1%), so we have 1-3% of PEBs reserved at the end, depending
on the amount of initial bad PEBs. But it is desired to always have
1% (or more, depending on the configuration).
Solution: this patch adds an "auto-resize" flag to the volume table.
The volume which has the "auto-resize" flag will automatically be re-sized
(enlarged) on the first UBI initialization. UBI clears the flag when
the volume is re-sized. Only one volume may have the "auto-resize" flag.
So, the production UBI image may have one volume with "auto-resize"
flag set, and its size is automatically adjusted on the first boot
of the device.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
David Woodhouse