* kernel messages from INFTL
@ 2005-06-21 22:06 Andre
2005-06-22 22:59 ` Andre
2005-06-30 6:30 ` Greg Ungerer
0 siblings, 2 replies; 6+ messages in thread
From: Andre @ 2005-06-21 22:06 UTC (permalink / raw)
To: linux-mtd; +Cc: fabrice.bellard, tglx, dwmw2, gerg
First of all, thank you Thomas for your help on trying to get my
diskonchip2000 to be recognized by linuxmtd.
After enabling the right config flags in the kernel, I can now mount my
diskonchip2000.
There were some messages during the initial loading of the inftl module that
frightened me a bit. Here is the entire output from dmesg:
==================
DiskOnChip found at 0xd0000
Detected 3 chips per floor.
NAND device: Manufacturer ID: 0xec, Chip ID: 0x79 (Samsung NAND 128MiB 3,3V
8-bit)
3 NAND chips detected
Bad block table not found for chip 0
Bad block table not found for chip 0
Found DiskOnChip BNAND Media Header at 0x4000
bootRecordID = BNAND
NoOfBootImageBlocks = 0
NoOfBinaryPartitions = 1
NoOfBDTLPartitions = 1
BlockMultiplerBits = 0
FormatFlgs = 1
OsakVersion = 5.1.4.0
PercentUsed = 98
PARTITION[0] ->
virtualUnits = 4
firstUnit = 2
lastUnit = 5
flags = 0x20000000
spareUnits = 0
PARTITION[1] ->
virtualUnits = 24072
firstUnit = 11
lastUnit = 24575
flags = 0xc0000000
spareUnits = 2
Creating 2 MTD partitions on "DiskOnChip 2000 (INFTL Model)":
0x00008000-0x00018000 : " DiskOnChip BDK partition"
0x0002c000-0x18000000 : " DiskOnChip BDTL partition"
<Andre> looks ok up until here
INFTL: inftlcore.c $Revision: 1.18 $, inftlmount.c $Revision: 1.16 $
INFTL: corrupt block 10588 in chain 10588, chain length 0, erase mark 0x0?
INFTL: formatting chain at block 10588
INFTL: formatting block 10588
INFTL: error while formatting block 10588
INFTL: corrupt block 15274 in chain 15274, chain length 0, erase mark 0x0?
INFTL: formatting chain at block 15274
INFTL: formatting block 15274
INFTL: error while formatting block 15274
INFTL: corrupt block 21286 in chain 21286, chain length 0, erase mark 0x0?
INFTL: formatting chain at block 21286
INFTL: formatting block 21286
INFTL: error while formatting block 21286
INFTL: corrupt block 24574 in chain 24574, chain length 0, erase mark
0xffff?
INFTL: formatting chain at block 24574
INFTL: formatting block 24574
INFTL: corrupt block 24575 in chain 24575, chain length 0, erase mark
0xffff?
INFTL: formatting chain at block 24575
INFTL: formatting block 24575
inftla: inftla1
==================
The INFTL messages do not appear on subsequent loads of the inftl module.
Can somebody please explain what happened, i.e. should I be concerned?
/proc/mtd:
mtd0: 18000000 00004000 "DiskOnChip 2000 (INFTL Model)"
mtd1: 00010000 00004000 " DiskOnChip BDK partition"
mtd2: 17fd4000 00004000 " DiskOnChip BDTL partition"
cheers,
Andre
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel messages from INFTL
2005-06-21 22:06 kernel messages from INFTL Andre
@ 2005-06-22 22:59 ` Andre
2005-06-30 6:30 ` Greg Ungerer
1 sibling, 0 replies; 6+ messages in thread
From: Andre @ 2005-06-22 22:59 UTC (permalink / raw)
To: linux-mtd
> INFTL: inftlcore.c $Revision: 1.18 $, inftlmount.c $Revision: 1.16 $
> INFTL: corrupt block 10588 in chain 10588, chain length 0, erase mark
> 0x0? INFTL: formatting chain at block 10588
> INFTL: formatting block 10588
> INFTL: error while formatting block 10588
> INFTL: corrupt block 15274 in chain 15274, chain length 0, erase mark
> 0x0? INFTL: formatting chain at block 15274
> INFTL: formatting block 15274
> INFTL: error while formatting block 15274
> INFTL: corrupt block 21286 in chain 21286, chain length 0, erase mark
> 0x0? INFTL: formatting chain at block 21286
> INFTL: formatting block 21286
> INFTL: error while formatting block 21286
> INFTL: corrupt block 24574 in chain 24574, chain length 0, erase mark
> 0xffff?
> INFTL: formatting chain at block 24574
> INFTL: formatting block 24574
> INFTL: corrupt block 24575 in chain 24575, chain length 0, erase mark
> 0xffff?
> INFTL: formatting chain at block 24575
> INFTL: formatting block 24575
> inftla: inftla1
Turns out that I can't boot my system anymore with the diskonchip memory
range enabled in the BIOS. Somehow mtd did something to the boot sector on
the doc2000. Upon inspecting the diskonchip2000 with m-sys dos utilities it
turns out that the bad block table info cannot be found anymore, and all
this time I assumed that the inftl mount operation would be non-destructive.
Can one of you guru's please advise how to proceed from here? Is my doc now
hosed?
Andre
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel messages from INFTL
2005-06-21 22:06 kernel messages from INFTL Andre
2005-06-22 22:59 ` Andre
@ 2005-06-30 6:30 ` Greg Ungerer
2005-06-30 17:52 ` Andre
1 sibling, 1 reply; 6+ messages in thread
From: Greg Ungerer @ 2005-06-30 6:30 UTC (permalink / raw)
To: Andre; +Cc: dwmw2, tglx, linux-mtd, fabrice.bellard
Hi Andre,
Andre wrote:
> First of all, thank you Thomas for your help on trying to get my
> diskonchip2000 to be recognized by linuxmtd.
>
> After enabling the right config flags in the kernel, I can now mount my
> diskonchip2000.
>
> There were some messages during the initial loading of the inftl module that
> frightened me a bit. Here is the entire output from dmesg:
> ==================
> DiskOnChip found at 0xd0000
> Detected 3 chips per floor.
> NAND device: Manufacturer ID: 0xec, Chip ID: 0x79 (Samsung NAND 128MiB 3,3V
> 8-bit)
> 3 NAND chips detected
> Bad block table not found for chip 0
> Bad block table not found for chip 0
> Found DiskOnChip BNAND Media Header at 0x4000
> bootRecordID = BNAND
> NoOfBootImageBlocks = 0
> NoOfBinaryPartitions = 1
> NoOfBDTLPartitions = 1
> BlockMultiplerBits = 0
> FormatFlgs = 1
> OsakVersion = 5.1.4.0
> PercentUsed = 98
> PARTITION[0] ->
> virtualUnits = 4
> firstUnit = 2
> lastUnit = 5
> flags = 0x20000000
> spareUnits = 0
> PARTITION[1] ->
> virtualUnits = 24072
> firstUnit = 11
> lastUnit = 24575
> flags = 0xc0000000
> spareUnits = 2
> Creating 2 MTD partitions on "DiskOnChip 2000 (INFTL Model)":
> 0x00008000-0x00018000 : " DiskOnChip BDK partition"
> 0x0002c000-0x18000000 : " DiskOnChip BDTL partition"
>
> <Andre> looks ok up until here
>
> INFTL: inftlcore.c $Revision: 1.18 $, inftlmount.c $Revision: 1.16 $
> INFTL: corrupt block 10588 in chain 10588, chain length 0, erase mark 0x0?
> INFTL: formatting chain at block 10588
> INFTL: formatting block 10588
> INFTL: error while formatting block 10588
> INFTL: corrupt block 15274 in chain 15274, chain length 0, erase mark 0x0?
> INFTL: formatting chain at block 15274
> INFTL: formatting block 15274
> INFTL: error while formatting block 15274
> INFTL: corrupt block 21286 in chain 21286, chain length 0, erase mark 0x0?
> INFTL: formatting chain at block 21286
> INFTL: formatting block 21286
> INFTL: error while formatting block 21286
> INFTL: corrupt block 24574 in chain 24574, chain length 0, erase mark
> 0xffff?
> INFTL: formatting chain at block 24574
> INFTL: formatting block 24574
> INFTL: corrupt block 24575 in chain 24575, chain length 0, erase mark
> 0xffff?
> INFTL: formatting chain at block 24575
> INFTL: formatting block 24575
> inftla: inftla1
> ==================
> The INFTL messages do not appear on subsequent loads of the inftl module.
> Can somebody please explain what happened, i.e. should I be concerned?
The INFTL code is telling you that it didn't think the chains
where logically correct. So it went ahead and tried to fix them up.
Once fixed you should not see any messages on the next boot (as
you didn't). Certainly not normal (or good).
I take it you are running this on a device that was formatted
using the M-systems tools?
What kernel version are you using here?
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel messages from INFTL
2005-06-30 6:30 ` Greg Ungerer
@ 2005-06-30 17:52 ` Andre
2005-07-05 4:55 ` Greg Ungerer
0 siblings, 1 reply; 6+ messages in thread
From: Andre @ 2005-06-30 17:52 UTC (permalink / raw)
To: Greg Ungerer; +Cc: dwmw2, tglx, linux-mtd, fabrice.bellard
Hi Greg,
Greg Ungerer wrote:
> Hi Andre,
>
> Andre wrote:
>> First of all, thank you Thomas for your help on trying to get my
>> diskonchip2000 to be recognized by linuxmtd.
>>
>> After enabling the right config flags in the kernel, I can now mount
>> my diskonchip2000.
>>
>> There were some messages during the initial loading of the inftl
>> module that frightened me a bit. Here is the entire output from
>> dmesg: ==================
>> DiskOnChip found at 0xd0000
>> Detected 3 chips per floor.
>> NAND device: Manufacturer ID: 0xec, Chip ID: 0x79 (Samsung NAND
>> 128MiB 3,3V 8-bit)
>> 3 NAND chips detected
>> Bad block table not found for chip 0
>> Bad block table not found for chip 0
>> Found DiskOnChip BNAND Media Header at 0x4000
>> bootRecordID = BNAND
>> NoOfBootImageBlocks = 0
>> NoOfBinaryPartitions = 1
>> NoOfBDTLPartitions = 1
>> BlockMultiplerBits = 0
>> FormatFlgs = 1
>> OsakVersion = 5.1.4.0
>> PercentUsed = 98
>> PARTITION[0] ->
>> virtualUnits = 4
>> firstUnit = 2
>> lastUnit = 5
>> flags = 0x20000000
>> spareUnits = 0
>> PARTITION[1] ->
>> virtualUnits = 24072
>> firstUnit = 11
>> lastUnit = 24575
>> flags = 0xc0000000
>> spareUnits = 2
>> Creating 2 MTD partitions on "DiskOnChip 2000 (INFTL Model)":
>> 0x00008000-0x00018000 : " DiskOnChip BDK partition"
>> 0x0002c000-0x18000000 : " DiskOnChip BDTL partition"
>>
>> <Andre> looks ok up until here
>>
>> INFTL: inftlcore.c $Revision: 1.18 $, inftlmount.c $Revision: 1.16 $
>> INFTL: corrupt block 10588 in chain 10588, chain length 0, erase
>> mark 0x0? INFTL: formatting chain at block 10588
>> INFTL: formatting block 10588
>> INFTL: error while formatting block 10588
>> INFTL: corrupt block 15274 in chain 15274, chain length 0, erase
>> mark 0x0? INFTL: formatting chain at block 15274
>> INFTL: formatting block 15274
>> INFTL: error while formatting block 15274
>> INFTL: corrupt block 21286 in chain 21286, chain length 0, erase
>> mark 0x0? INFTL: formatting chain at block 21286
>> INFTL: formatting block 21286
>> INFTL: error while formatting block 21286
>> INFTL: corrupt block 24574 in chain 24574, chain length 0, erase mark
>> 0xffff?
>> INFTL: formatting chain at block 24574
>> INFTL: formatting block 24574
>> INFTL: corrupt block 24575 in chain 24575, chain length 0, erase mark
>> 0xffff?
>> INFTL: formatting chain at block 24575
>> INFTL: formatting block 24575
>> inftla: inftla1
>> ==================
>> The INFTL messages do not appear on subsequent loads of the inftl
>> module. Can somebody please explain what happened, i.e. should I be
>> concerned?
>
> The INFTL code is telling you that it didn't think the chains
> where logically correct. So it went ahead and tried to fix them up.
> Once fixed you should not see any messages on the next boot (as
> you didn't). Certainly not normal (or good).
The device really started to act up on subsequent boot and I couldn't even
format it anymore with m-sys tools. The dformat utility complained about not
being able to find the bad block table.
> I take it you are running this on a device that was formatted
> using the M-systems tools?
correct
> What kernel version are you using here?
stock 2.6.11 with mtd 20050612 snapshot.
Thanks for your reply,
Andre
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel messages from INFTL
2005-06-30 17:52 ` Andre
@ 2005-07-05 4:55 ` Greg Ungerer
2005-07-06 17:01 ` Andre
0 siblings, 1 reply; 6+ messages in thread
From: Greg Ungerer @ 2005-07-05 4:55 UTC (permalink / raw)
To: Andre; +Cc: dwmw2, tglx, linux-mtd, fabrice.bellard
Hi Andre,
Andre wrote:
> Greg Ungerer wrote:
>>Andre wrote:
[snip]
>>>INFTL: formatting chain at block 24574
>>>INFTL: formatting block 24574
>>>INFTL: corrupt block 24575 in chain 24575, chain length 0, erase mark
>>>0xffff?
>>>INFTL: formatting chain at block 24575
>>>INFTL: formatting block 24575
>>> inftla: inftla1
>>>==================
>>>The INFTL messages do not appear on subsequent loads of the inftl
>>>module. Can somebody please explain what happened, i.e. should I be
>>>concerned?
>>
>>The INFTL code is telling you that it didn't think the chains
>>where logically correct. So it went ahead and tried to fix them up.
>>Once fixed you should not see any messages on the next boot (as
>>you didn't). Certainly not normal (or good).
>
>
> The device really started to act up on subsequent boot and I couldn't even
> format it anymore with m-sys tools. The dformat utility complained about not
> being able to find the bad block table.
My best guess is that the bad block info is stored differently than
what the current INFTL code can deal with then. I have only used it
on the Disk-on-chip Millenium+ parts, and the bad block table is stored
in the factory reserved region on those parts (which I believe is
different to their other DoC parts).
Can you fully restore it with the M-systems tools?
You will need to debug the INFTL init logic and figure out what how
the initial block layout is different.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel messages from INFTL
2005-07-05 4:55 ` Greg Ungerer
@ 2005-07-06 17:01 ` Andre
0 siblings, 0 replies; 6+ messages in thread
From: Andre @ 2005-07-06 17:01 UTC (permalink / raw)
To: Greg Ungerer; +Cc: dwmw2, tglx, linux-mtd, fabrice.bellard
[snip]
>>>> INFTL: formatting chain at block 24574
>>>> INFTL: formatting block 24574
>>>> INFTL: corrupt block 24575 in chain 24575, chain length 0, erase
>>>> mark 0xffff?
>>>> INFTL: formatting chain at block 24575
>>>> INFTL: formatting block 24575
>>>> inftla: inftla1
>>>> ==================
>>>> The INFTL messages do not appear on subsequent loads of the inftl
>>>> module. Can somebody please explain what happened, i.e. should I be
>>>> concerned?
>>>
>>> The INFTL code is telling you that it didn't think the chains
>>> where logically correct. So it went ahead and tried to fix them up.
>>> Once fixed you should not see any messages on the next boot (as
>>> you didn't). Certainly not normal (or good).
>>
>>
>> The device really started to act up on subsequent boot and I
>> couldn't even format it anymore with m-sys tools. The dformat
>> utility complained about not being able to find the bad block table.
>
> My best guess is that the bad block info is stored differently than
> what the current INFTL code can deal with then. I have only used it
> on the Disk-on-chip Millenium+ parts, and the bad block table is
> stored in the factory reserved region on those parts (which I believe
> is different to their other DoC parts).
here is a link to somebody else that is using the exact same part, although
he is experiencing different problems:
http://thread.gmane.org/gmane.linux.drivers.mtd/12814
Can you tell from this where the bad block table is stored?
> Can you fully restore it with the M-systems tools?
no, format wouldn't work anymore and I couldn't boot the system with the DoC
installed because of some corruption in the boot sector - the BIOS would
complain and would hang, so I decided to send it back to the supplier for
replacement.
>
> You will need to debug the INFTL init logic and figure out what how
> the initial block layout is different.
There is just one thing I would like to know: starting with an m-sys
formatted device, does linux-mtd touch anything on the device during the
inftl mount? The inftl debug messages seem to indicate that certain
'formatting' operations are taking place. Maybe I am overly protective, but
shouldn't 'mount' be a read-only operation?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-07-06 16:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-21 22:06 kernel messages from INFTL Andre
2005-06-22 22:59 ` Andre
2005-06-30 6:30 ` Greg Ungerer
2005-06-30 17:52 ` Andre
2005-07-05 4:55 ` Greg Ungerer
2005-07-06 17:01 ` Andre
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.