* [PATCH] Do not oops when configured flash size is less then chip size
@ 2006-05-11 15:20 Leon Woestenberg
2006-05-11 15:52 ` David Vrabel
0 siblings, 1 reply; 10+ messages in thread
From: Leon Woestenberg @ 2006-05-11 15:20 UTC (permalink / raw)
To: linux-mtd
[-- Attachment #1: Type: text/plain, Size: 4805 bytes --]
Hello all,
please review this patch for inclusion. It is against the MTD GIT tree.
Prevents an oops (see kernel boot log below) in case the flash area
size is configured too small (or, if you order a larger than default
Flash population for your board :-)
--
Leon
Uncompressing Linux...................................................................................
done, booting the kernel.
Linux version 2.6.16 (buytenh@phi.wantstofly.org) (gcc version 4.0.1)
#1 Mon Mar 20 13:52:40 CET 2006
CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T)
Machine: Glomation GESBC-9312-sx
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists
Kernel command line: console=ttyAM0,57600,8n1
PID hash table entries: 512 (order: 9, 8192 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 32MB 32MB = 64MB total
Memory: 62176KB available (2132K code, 409K data, 84K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NetWinder Floating Point Emulator V0.97 (extended precision)
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
io scheduler noop registered
io scheduler deadline registered (default)
ep93xx_wdt: EP93XX watchdog, driver version 0.3 (nCS1 disable detected)
Serial: AMBA driver $Revision: 1.41 $
apb:uart1: ttyAM0 at MMIO 0x808c0000 (irq = 52) is a AMBA
apb:uart2: ttyAM1 at MMIO 0x808d0000 (irq = 54) is a AMBA
apb:uart3: ttyAM2 at MMIO 0x808e0000 (irq = 55) is a AMBA
ep93xx_eth: version 2.8 2005-11-08 Cirrus Logic
ep93xx_eth: #0 at 0xfef10000 IRQ:39
ep93xx_eth: using random number 00:d0:69:40:2b:13 as MAC, don't forget
to assign a valid MAC later!
physmap flash device: 800000 at 60000000
phys_mapped_flash: Found 2 x16 devices at 0x0 in 32-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in phys_mapped_flash at offset 0x1fc0000
Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = c0004000
[00000004] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0
PC is at _raw_spin_lock+0x14/0x134
LR is at _spin_lock+0x10/0x14
pc : [<c01161dc>] lr : [<c01f5904>] Not tainted
sp : c0307eb4 ip : c0307ee0 fp : c0307edc
r10: c5c98c98 r9 : 01fc0000 r8 : c0247c70
r7 : c5c2007c r6 : 00000000 r5 : 01fc0000 r4 : c5c98c60
r3 : dead4ead r2 : 00000000 r1 : 00000000 r0 : 00000000
Flags: nzcv IRQs on FIQs on Mode SVC_32 Segment kernel
Control: C000717F Table: 00004000 DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc0306250)
Stack: (0xc0307eb4 to 0xc0308000)
7ea0: c0307ec0 c5c98c60 01fc0000
7ec0: 00000000 c5c2007c c0247c70 c5c98c98 c0307eec c0307ee0 c01f5904 c01161d8
7ee0: c0307f34 c0307ef0 c01502e4 c01f5904 00040000 c5c98c60 00000000 00040000
7f00: 00000000 01fc0000 00000000 01fc0000 c001c134 00000000 c5c2007c 00000000
7f20: 00000000 c5c2007c c0307f90 c0307f38 c0140850 c0150210 c0307f60 c7081000
7f40: 00000000 c013f478 00000000 c028f8f0 c7081000 00000000 c02478cc c0307f78
7f60: 00000000 00000000 c02478cc c001c134 00000000 c5c2007c 00000000 00000000
7f80: c028f8f0 c0307fb8 c0307f94 c013f478 c01407cc c028f8f0 00000000 c028f8f4
7fa0: 00000000 00000000 00000000 c0307fd8 c0307fbc c0014d70 c013f410 c0306000
7fc0: c0019a60 00000000 00000000 c0307ff4 c0307fdc c001d0dc c0014ca4 00000000
7fe0: 00000000 00000000 00000000 c0307ff8 c003a180 c001d068 c0307ff8 c0307ff8
Backtrace:
[<c01161c8>] (_raw_spin_lock+0x0/0x134) from [<c01f5904>] (_spin_lock+0x10/0x14)
[<c01f58f4>] (_spin_lock+0x0/0x14) from [<c01502e4>]
(cfi_intelext_read+0xe4/0x2b8)
[<c0150200>] (cfi_intelext_read+0x0/0x2b8) from [<c0140850>]
(parse_redboot_partitions+0x94/0x3f0)
[<c01407bc>] (parse_redboot_partitions+0x0/0x3f0) from [<c013f478>]
(parse_mtd_partitions+0x78/0xf4)
[<c013f400>] (parse_mtd_partitions+0x0/0xf4) from [<c0014d70>]
(init_physmap+0xdc/0x180)
[<c0014c94>] (init_physmap+0x0/0x180) from [<c001d0dc>] (init+0x84/0x20c)
r7 = 00000000 r6 = 00000000 r5 = C0019A60 r4 = C0306000
[<c001d058>] (init+0x0/0x20c) from [<c003a180>] (do_exit+0x0/0x7e0)
r6 = 00000000 r5 = 00000000 r4 = 00000000
Code: e92dddf0 e24cb004 e24dd004 e59f3104 (e5902004)
<0>Kernel panic - not syncing: Attempted to kill init!
[-- Attachment #2: prevent_chip_size_exceeds_config_oops.patch --]
[-- Type: text/x-patch, Size: 994 bytes --]
[MTD] CHIPS: Do not oops when configured flash size is less then chip size
My kernel oopsed when the on-board flash chips where quadruple the size of the
platform default physmap_map.size. Turned out that max_chips becomes zero,
resulting in an oops later in locking chip->mutex being non-initialized.
Full debug trace available.
Signed-off-by: Leon Woestenberg <leonw@mailcan.com>
diff --git a/drivers/mtd/chips/gen_probe.c b/drivers/mtd/chips/gen_probe.c
index 9b252d2..9b7f82b 100644
--- a/drivers/mtd/chips/gen_probe.c
+++ b/drivers/mtd/chips/gen_probe.c
@@ -100,6 +100,11 @@ #endif
* Align bitmap storage size to full byte.
*/
max_chips = map->size >> cfi.chipshift;
+ if (max_chips == 0) {
+ printk(KERN_WARNING "Single flash chip size exceeds the configured flash area size. Check your kernel configuration.\n");
+ kfree(cfi.cfiq);
+ return NULL;
+ }
mapsize = (max_chips / 8) + ((max_chips % 8) ? 1 : 0);
chip_map = kmalloc(mapsize, GFP_KERNEL);
if (!chip_map) {
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] Do not oops when configured flash size is less then chip size
2006-05-11 15:20 [PATCH] Do not oops when configured flash size is less then chip size Leon Woestenberg
@ 2006-05-11 15:52 ` David Vrabel
2006-05-11 16:03 ` Leon Woestenberg
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: David Vrabel @ 2006-05-11 15:52 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: linux-mtd
Leon Woestenberg wrote:
>
> [MTD] CHIPS: Do not oops when configured flash size is less then chip size
>
> My kernel oopsed when the on-board flash chips where quadruple the size of the
> platform default physmap_map.size. Turned out that max_chips becomes zero,
> resulting in an oops later in locking chip->mutex being non-initialized.
> --- a/drivers/mtd/chips/gen_probe.c
> +++ b/drivers/mtd/chips/gen_probe.c
> @@ -100,6 +100,11 @@ #endif
> * Align bitmap storage size to full byte.
> */
> max_chips = map->size >> cfi.chipshift;
> + if (max_chips == 0) {
> + printk(KERN_WARNING "Single flash chip size exceeds the configured flash area size. Check your kernel configuration.\n");
This sounds like a valid, if unlikely, board configuration. e.g., a
board with chips fitted that are larger than the chip-select memory window.
It might be better to pretend such configuration is a single chip that's
smaller than it physically is.
Maybe something as simple as:
/* there's at least one chip present */
max_chips = max(map->size >> cfi.chipshift, 1);
?
David Vrabel
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] Do not oops when configured flash size is less then chip size
2006-05-11 15:52 ` David Vrabel
@ 2006-05-11 16:03 ` Leon Woestenberg
2006-05-12 0:28 ` David Woodhouse
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Leon Woestenberg @ 2006-05-11 16:03 UTC (permalink / raw)
To: David Vrabel, linux-mtd
Hello David,
On 5/11/06, David Vrabel <dvrabel@arcom.com> wrote:
> Leon Woestenberg wrote:
> >
> > [MTD] CHIPS: Do not oops when configured flash size is less then chip size
> >
> > My kernel oopsed when the on-board flash chips where quadruple the size of the
> > platform default physmap_map.size. Turned out that max_chips becomes zero,
>
> This sounds like a valid, if unlikely, board configuration. e.g., a
> board with chips fitted that are larger than the chip-select memory window.
>
Yes and no; many (development) boards come with different memory
sizes. A simple fix is that the platform should deal with the largest
common size, but this has only temporal meaning.
> It might be better to pretend such configuration is a single chip that's
> smaller than it physically is.
Yes, but the fact is MTD subsystem will not handle this case, so we
better bail out and warn the user. See the bootlog with your proposed
fixed below. Havoc occurs elsewhere.
Best regards,
--
Leon
...
Single flash chip size exceeds the configured flash size. Assuming at
least one chip.
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in phys_mapped_flash at offset 0x1fc0000
Unable to handle kernel paging request at virtual address c8840000
pgd = c0004000
[c8840000] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0
PC is at _memcpy_fromio+0x14/0x2c
LR is at cfi_intelext_read+0x244/0x2d0
pc : [<c0022958>] lr : [<c0150004>] Not tainted
sp : c02dbeb4 ip : 00000001 fp : c02dbec0
r10: c5c420e4 r9 : 01fc0000 r8 : c023d5c0
r7 : 00000000 r6 : 00000000 r5 : 01fc0000 r4 : 01fc0000
r3 : 00000000 r2 : 00040000 r1 : c8840000 r0 : c7081000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment kernel
Control: C000717F Table: 00004000 DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc02da198)
Stack: (0xc02dbeb4 to 0xc02dc000)
bea0: c02dbf08 c02dbec4 c0150004
bec0: c0022954 00040000 c5c420ac 00000000 00040000 00000000 01fc0000 00000000
bee0: 01fc0000 c001b584 00000000 c5c43ca4 00000000 00000000 c0285a40 c02dbf64
bf00: c02dbf0c c013ffcc c014fdd0 c02dbf34 c7081000 00000000 00000000 c0285a40
bf20: c5c43ca4 c7081000 00000000 c023d1c4 c02dbf4c 00000000 00000000 c023d1c4
bf40: c001b584 00000000 c5c43ca4 00000000 00000000 c0285a40 c02dbf8c c02dbf68
bf60: c013ebfc c013ff44 c0285a40 00000000 c0285a44 00000000 00000000 00000000
bf80: c02dbfac c02dbf90 c001487c c013eb94 c0019414 c0018ea8 c02da000 00000000
bfa0: c02dbff4 c02dbfb0 c001c0e0 c001479c 00000000 00000000 c001c058 c0038fbc
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 c02dbff8 c0038fbc c001c068 c02dbff8 c02dbff8
Backtrace:
[<c0022944>] (_memcpy_fromio+0x0/0x2c) from [<c0150004>]
(cfi_intelext_read+0x244/0x2d0)
[<c014fdc0>] (cfi_intelext_read+0x0/0x2d0) from [<c013ffcc>]
(parse_redboot_partitions+0x98/0x3f0)
[<c013ff34>] (parse_redboot_partitions+0x0/0x3f0) from [<c013ebfc>]
(parse_mtd_partitions+0x78/0xf4)
[<c013eb84>] (parse_mtd_partitions+0x0/0xf4) from [<c001487c>]
(init_physmap+0xf0/0x19c)
[<c001478c>] (init_physmap+0x0/0x19c) from [<c001c0e0>] (init+0x88/0x264)
r7 = 00000000 r6 = C02DA000 r5 = C0018EA8 r4 = C0019414
[<c001c058>] (init+0x0/0x264) from [<c0038fbc>] (do_exit+0x0/0x81c)
r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000
Code: e92dd800 e24cb004 e3a0c000 ea000001 (e4d13001)
<0>Kernel panic - not syncing: Attempted to kill init!
CTRL-A Z for help | 57600 8N1 | NOR | Minicom 2.1 | VT102 | Offline
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] Do not oops when configured flash size is less then chip size
2006-05-11 15:52 ` David Vrabel
2006-05-11 16:03 ` Leon Woestenberg
@ 2006-05-12 0:28 ` David Woodhouse
2006-05-12 22:40 ` Leon Woestenberg
2006-05-12 18:18 ` Peter Hanson
2006-05-13 11:22 ` David Woodhouse
3 siblings, 1 reply; 10+ messages in thread
From: David Woodhouse @ 2006-05-12 0:28 UTC (permalink / raw)
To: David Vrabel; +Cc: Leon Woestenberg, linux-mtd
On Thu, 2006-05-11 at 16:52 +0100, David Vrabel wrote:
> This sounds like a valid, if unlikely, board configuration. e.g., a
> board with chips fitted that are larger than the chip-select memory
> window.
An alternative plan is to (warn and) artificially reduce mtd->size so
that it fits in the map. That way, you at least get to use the region of
the flash that you can address.
--
dwmw2
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Do not oops when configured flash size is less then chip size
2006-05-12 0:28 ` David Woodhouse
@ 2006-05-12 22:40 ` Leon Woestenberg
0 siblings, 0 replies; 10+ messages in thread
From: Leon Woestenberg @ 2006-05-12 22:40 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
Hello all,
On 5/12/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2006-05-11 at 16:52 +0100, David Vrabel wrote:
> > This sounds like a valid, if unlikely, board configuration. e.g., a
> > board with chips fitted that are larger than the chip-select memory
> > window.
>
> An alternative plan is to (warn and) artificially reduce mtd->size so
> that it fits in the map. That way, you at least get to use the region of
> the flash that you can address.
>
Thanks for reviewing my problem description and patch.
I did indeed try a few things to make this automagically work, but
then decided that this clashed with the definition of the 'fixed flash
size configuration' in the kernel configuration.
(And I am not familiar enough with the MTD code to just twiddle with
variables of which I have no idea about subtle assumptions and/or
interdependencies within MTD.)
Instead, I think just warning the user properly is the best solution.
Regards,
Leon.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Do not oops when configured flash size is less then chip size
2006-05-11 15:52 ` David Vrabel
2006-05-11 16:03 ` Leon Woestenberg
2006-05-12 0:28 ` David Woodhouse
@ 2006-05-12 18:18 ` Peter Hanson
2006-05-13 11:22 ` David Woodhouse
3 siblings, 0 replies; 10+ messages in thread
From: Peter Hanson @ 2006-05-12 18:18 UTC (permalink / raw)
To: David Vrabel; +Cc: Leon Woestenberg, linux-mtd
On 5/11/06, David Vrabel <dvrabel@arcom.com> wrote:
> Leon Woestenberg wrote:
[snip]
> This sounds like a valid, if unlikely, board configuration. e.g., a
> board with chips fitted that are larger than the chip-select memory window.
[/snip]
Not so very unlikely. A product update may call for lashing upgraded
flash chips into a clunky old design. MPC82xx chips are still
shipping, and their legacy ROM chip selects are smaller than many
modern flash chips.
Mind you, I'm not saying MTD _should_ support such nonsense. But one
definition of `driver' is `n. Software written to paper over the flaws
of your brain dead hardware.'
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Do not oops when configured flash size is less then chip size
2006-05-11 15:52 ` David Vrabel
` (2 preceding siblings ...)
2006-05-12 18:18 ` Peter Hanson
@ 2006-05-13 11:22 ` David Woodhouse
2006-05-13 13:23 ` Leon Woestenberg
3 siblings, 1 reply; 10+ messages in thread
From: David Woodhouse @ 2006-05-13 11:22 UTC (permalink / raw)
To: David Vrabel; +Cc: Leon Woestenberg, linux-mtd
On Thu, 2006-05-11 at 16:52 +0100, David Vrabel wrote:
> This sounds like a valid, if unlikely, board configuration. e.g., a
> board with chips fitted that are larger than the chip-select memory
> window.
>
> It might be better to pretend such configuration is a single chip
> that's smaller than it physically is.
Yes, I agree.
> Maybe something as simple as:
>
> /* there's at least one chip present */
> max_chips = max(map->size >> cfi.chipshift, 1);
>
> ?
You also need to reduce mtd->size after you've done the probe.
And while we're at it, we'll slap Deepak around a little bit and stop
using byte arrays with the Linux bitops.
Please could you test this for me?
diff --git a/drivers/mtd/chips/gen_probe.c b/drivers/mtd/chips/gen_probe.c
index 9b252d2..9915ab8 100644
--- a/drivers/mtd/chips/gen_probe.c
+++ b/drivers/mtd/chips/gen_probe.c
@@ -37,8 +37,14 @@ struct mtd_info *mtd_do_chip_probe(struc
if (!mtd)
mtd = check_cmd_set(map, 0); /* Then the secondary */
- if (mtd)
+ if (mtd) {
+ if (mtd->size > map->size) {
+ printk(KERN_WARNING "Reducing visibility of %dKiB chip to %dKiB\n",
+ mtd->size >> 10, map->size >> 10);
+ mtd->size = map->size;
+ }
return mtd;
+ }
printk(KERN_WARNING"gen_probe: No supported Vendor Command Set found\n");
@@ -100,7 +106,12 @@ #endif
* Align bitmap storage size to full byte.
*/
max_chips = map->size >> cfi.chipshift;
- mapsize = (max_chips / 8) + ((max_chips % 8) ? 1 : 0);
+ if (!max_chips) {
+ printk(KERN_WARNING "NOR chip too large to fit in mapping. Attempting to cope...\n");
+ max_chips = 1;
+ }
+
+ mapsize = (max_chips + BITS_PER_LONG-1) / BITS_PER_LONG;
chip_map = kmalloc(mapsize, GFP_KERNEL);
if (!chip_map) {
printk(KERN_WARNING "%s: kmalloc failed for CFI chip map\n", map->name);
--
dwmw2
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] Do not oops when configured flash size is less then chip size
2006-05-13 11:22 ` David Woodhouse
@ 2006-05-13 13:23 ` Leon Woestenberg
2006-05-15 20:04 ` Leon Woestenberg
0 siblings, 1 reply; 10+ messages in thread
From: Leon Woestenberg @ 2006-05-13 13:23 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
Hello David W, David V et al,
On 5/13/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2006-05-11 at 16:52 +0100, David Vrabel wrote:
> > It might be better to pretend such configuration is a single chip
> > that's smaller than it physically is.
> Yes, I agree.
> You also need to reduce mtd->size after you've done the probe.
> Please could you test this for me?
>
I cannot perform tests from userspace yet on the flash devices, but I
have tested two kernel boots (one with the size set too small, one
with the correct size).
The right code paths seem to be taken, and it solves the issue. See
the 'too small' boot (that oopsed earlier) below.
I had to change the last formatter in printk from %d to %lu to prevent
a compiler warning:
drivers/mtd/chips/gen_probe.c:43: warning: format '%d' expects type
'int', but argument 3 has type 'long unsigned int'
Thanks and with the best regards,
Leon.
p.s. I hope this kernel log comes through with proper newlines.
Linux version 2.6.17-rc3 (leon@dhcppc7) (gcc version 4.0.1) #63 Sat
May 13 15:09:10 CEST 2006
CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T)
Machine: Glomation GESBC-9312-sx
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists
Kernel command line: console=ttyAM0,57600,8n1 initrd=10M@0x300000 root=/dev/ram0
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 32MB 32MB = 64MB total
Memory: 62408KB available (1932K code, 429K data, 92K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
physmap_configure()
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
io scheduler noop registered
io scheduler cfq registered (default)
ep93xx_wdt: EP93XX watchdog, driver version 0.3 (nCS1 disable detected)
Serial: AMBA driver $Revision: 1.41 $
apb:uart1: ttyAM0 at MMIO 0x808c0000 (irq = 52) is a AMBA
apb:uart2: ttyAM1 at MMIO 0x808d0000 (irq = 54) is a AMBA
uart-pl010: probe of apb:uart3 failed with error -16
RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize
ep93xx_eth: version 2.8 2005-11-08 Cirrus Logic
ep93xx_eth: #0 at 0xfef10000 IRQ:39
ep93xx_eth: using random number 00:d0:69:40:2b:13 as MAC, don't forget
to assign a valid MAC later!
physmap flash device: physmap_map.size 0x800000 at physmap_map.phys 0x60000000
physmap flash device: CONFIG_MTD_PHYSMAP_LEN:0x800000 at
CONFIG_MTD_PHYSMAP_START:0x60000000
cfi_probe_chip
Number of erase regions: 1
Primary Vendor Command Set: 0001 (Intel/Sharp Extended)
Primary Algorithm Table at 0031
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 256 �s
Maximum byte/word write timeout: 1024 �s
Typical full buffer write timeout: 256 �s
Maximum full buffer write timeout: 1024 �s
Typical block erase timeout: 2048 ms
Maximum block erase timeout: 16384 ms
Chip erase not supported
Device size: 0x1000000 bytes (16 MiB)
Flash Device Interface description: 0x0002
- supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x20
Number of Erase Block Regions: 1
Erase Region #0: BlockSize 0x20000 bytes, 128 blocks
phys_mapped_flash: Found 2 x16 devices at 0x0 in 32-bit bank!!
NOR chip too large to fit in mapping. Attempting to cope... <<<<
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Reducing visibility of 32768KiB chip to 8192KiB <<<<
cmdlinepart partition parsing not available
Searching for RedBoot partition table in phys_mapped_flash at offset 0x7c0000
No RedBoot partition table detected in phys_mapped_flash
mtd: Giving out device 0 to phys_mapped_flash
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/net/rtl8150.c: rtl8150 based usb-ethernet driver v0.6.2 (2004/08/27)
usbcore: registered new driver rtl8150
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
usbcore: registered new driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
ep93xx-rtc ep93xx-rtc: rtc intf: sysfs
ep93xx-rtc ep93xx-rtc: rtc intf: proc
ep93xx-rtc ep93xx-rtc: rtc intf: dev (254:0)
ep93xx-rtc ep93xx-rtc: rtc core: registered ep93xx as rtc0
i2c /dev entries driver
NET: Registered protocol family 2
IP route cache hash table entries: 512 (order: -1, 2048 bytes)
TCP established hash table entries: 2048 (order: 3, 32768 bytes)
TCP bind hash table entries: 1024 (order: 2, 20480 bytes)
TCP: Hash tables configured (established 2048 bind 1024)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
ep93xx-rtc ep93xx-rtc: setting the system clock to 1970-01-01 00:00:38 (38)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
--
Leon
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Do not oops when configured flash size is less then chip size
2006-05-13 13:23 ` Leon Woestenberg
@ 2006-05-15 20:04 ` Leon Woestenberg
2006-05-15 21:54 ` David Woodhouse
0 siblings, 1 reply; 10+ messages in thread
From: Leon Woestenberg @ 2006-05-15 20:04 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
Hello David,
On 5/13/06, Leon Woestenberg <leon.woestenberg@gmail.com> wrote:
> Hello David W, David V et al,
>
> On 5/13/06, David Woodhouse <dwmw2@infradead.org> wrote:
> > Please could you test this for me?
> The right code paths seem to be taken, and it solves the issue. See
> the 'too small' boot (that oopsed earlier) below.
>
> I had to change the last formatter in printk from %d to %lu to prevent
> a compiler warning:
>
I am curious if this made it into your MTD GIT tree, so I can flag
this issue as being "streamed up for mainline"? :-)
Regards, thanks,
Leon.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-05-15 21:54 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-11 15:20 [PATCH] Do not oops when configured flash size is less then chip size Leon Woestenberg
2006-05-11 15:52 ` David Vrabel
2006-05-11 16:03 ` Leon Woestenberg
2006-05-12 0:28 ` David Woodhouse
2006-05-12 22:40 ` Leon Woestenberg
2006-05-12 18:18 ` Peter Hanson
2006-05-13 11:22 ` David Woodhouse
2006-05-13 13:23 ` Leon Woestenberg
2006-05-15 20:04 ` Leon Woestenberg
2006-05-15 21:54 ` David Woodhouse
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox