Questions about MTD

Questions about MTD

[Dvir Oren]

I'm trying to use the MTD drivers to boot off a DiskOnChip 2000, 
and ran into the following problems:

1.  The flash has to be formatted with nftl_format in order for the 
MTD drivers to write successfully to the flash.  However, when I run 
nftl_format, it destroys the bios extension that allows booting from 
the flash.  I then try to run nftl_format /dev/mtd0 49152, to skip the 
first 48K, which hold the bios extension.  However, this seems to 
cause some problems:

a.  nftl_format in fact does not erase the first 48K, however it does 
delete the partition table.  As I understand it, the disk partition is in 
the first 512 bytes, so how can that be?

b.  When I try to create the partition, there are a lot of file system 
errors, possibly because I formatted starting at 49152.  It seems 
like nftl_format doesn't set the start of the device from after the first 
48k, which will then conflict.

2.  doc_loadbios doesn't seem to do what it's supposed to do.  
However, it does destroy the flash, allowing me to docpmap /e the 
flash, which will lead me to the next...

3.  erase seg faults.  Is erase supposed to do what docpmap /e 
does?

4.  Some odd problems when trying to dd the first 48k.  The 
partition table is not saved after removing the nftl module.  Only 
after writing it a second time does it get saved.

5.  One thing I don't understand:  even though everybody talks 
about the first 48k being the firmware, the firmware itself is less 
than 48k.  How does that work?  And what about the first 512bytes 
of the partition table?

Can anybody help?
Has anybody succeeded in booting off a DiskOnChip 2000 using 
the MTD drivers?

BTW:  The lilo I posted here a few weeks ago which was patched 
to work with MTD, probably will not work correctly.  I'll post here a 
new one soon,. if it interests anyone.

I was partially able to load LILO off /dev/nftla, however only from the 
MBR (not /dev/nftla1) - it seems like nftl_format destroys the MBR, 
or something like that.  I was not able to create a full boot from the 
flash, since the file system keeps getting trashed.

---------
Dvir Oren <dvir@lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Questions about MTD

[David Woodhouse]

dvir@lucidvon.com said:
>  a.  nftl_format in fact does not erase the first 48K, however it does
>  delete the partition table.  As I understand it, the disk partition
> is in  the first 512 bytes, so how can that be? 

In the beginning, there was an expanse of raw flash.

We set aside 49152 bytes of that for the firmware. The firmware may not 
actually take up all of that space, but it's allocated anyway.

The remainder of the flash is taken up with the actual NFTL filing system. 
This is a kind of filesystem which emulates a block device.

Your boot sector is actually in this block device, not on the first 512 bytes 
of the flash itself. When you overwrite the entire contents of the block 
device by using nftl_format, the boot sector is overwritten too - it's just 
like formatting a disk drive.

Think of it like low-level format and high-level format (remember old drives 
where you had to do that?)


> b.  When I try to create the partition, there are a lot of file system
>  errors, possibly because I formatted starting at 49152.  It seems
> like nftl_format doesn't set the start of the device from after the
> first  48k, which will then conflict. 

If this is after you've previously used nftl_format without specifying that 
you want it to start at byte 49152, then there's an NFTL header at the 
beginning of the flash which will be confusing things. 

Otherwise, I'm not sure, and I'd need a complete transcript of what you did, 
and the errors you way.

>  2.  doc_loadbios doesn't seem to do what it's supposed to do.
> However, it does destroy the flash, allowing me to docpmap /e the
> flash, which will lead me to the next...

The firmware that comes from M-Systems isn't supposed to be just loaded 
directly into the flash - which is what doc_loadbios does. You're supposed to 
spread out the first 8k of data over the first 16k of the flash, I think, 
putting 256 bytes of data at the beginning of each 512-byte page of flash.


dvir@lucidvon.com said:
> 3.  erase seg faults.  Is erase supposed to do what docpmap /e  does?

erase is supposed to completely clear the flash, and not do anything more. 
Isn't docpmap /e supposed to reformat it with NFTL again after doing that?

It shouldn't be segfaulting though - where's it doing it?


> 4.  Some odd problems when trying to dd the first 48k.  The  partition
> table is not saved after removing the nftl module.  Only  after
> writing it a second time does it get saved.

dd from where to where? Did you use the /dev/mtd0 device or /dev/nftla ?


dvir@lucidvon.com said:
> 5.  One thing I don't understand:  even though everybody talks  about
> the first 48k being the firmware, the firmware itself is less  than
> 48k.  How does that work? 

It's not using all the flash, because the IPL ROM doesn't know how to address 
the second half of each page of the flash - so it's wasting 8k (I think).

> And what about the first 512bytes  of the partition table? 

That's somewhere in the NFTL.


> Has anybody succeeded in booting off a DiskOnChip 2000 using  the MTD
> drivers?

Not yet. I have grub loading from DiskOnChip, but not then capable of getting 
a kernel off the NFTL.





--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Questions about MTD

[Bill Roman]

Dvir Oren wrote:
> 
> 3.  erase seg faults.  Is erase supposed to do what docpmap /e
> does?

You can supply a block number on the command line, and/or apply this patch:

diff -ur mtd-20000131.orig/util/erase.c mtd-20000131/util/erase.c
--- mtd-20000131.orig/util/erase.c      Tue Aug 17 15:57:08 1999
+++ mtd-20000131/util/erase.c   Wed Feb 23 10:23:19 2000
@@ -35,7 +35,7 @@
       erase.length = meminfo.erasesize;
       printf("Erasesize 0x%lx\n", meminfo.erasesize);
 
-      if (argc >= 2)
+      if (argc > 2)
              erase.start = atoi(argv[2]);
       else
              erase.start = 0;

Also, if you'd like nftl_format not to print gibberish for a usage message:

diff -ur mtd-20000131.orig/util/nftl_format.c mtd-20000131/util/nftl_format.c
--- mtd-20000131.orig/util/nftl_format.c        Fri Aug 20 08:31:01 1999
+++ mtd-20000131/util/nftl_format.c     Wed Feb 16 11:45:10 2000
@@ -107,7 +107,8 @@
        struct mtd_oob_buf oob = {0, 16, oobbuf};
 
    if (argc < 2) {
-          fprintf(stderr,"Usage: %s <mtddevice> [<start offset> [<size>]]\n");
+          fprintf(stderr,"Usage: %s <mtddevice> [<start offset> [<size>]]\n",
+                  argv[0]);
           return 1;
    }


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Questions about MTD

[David Woodhouse]

roman@alerton.com said:
>  You can supply a block number on the command line, and/or apply this
> patch:

Committed to CVS. Sorry, that seemed to have slipped the net last time you 
sent it to me.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Questions about MTD

[Oron Ogdan]

David W wrote :
> Isn't docpmap /e supposed to reformat it with NFTL again 
> after doing that?
> 
No it's just erasing the whole of the flash, Destroying the bad block 
table and all, This command is really low level command that should be
executed with care. You have to save the bad block table somehow. 

A better command to use is dformat /unformat

This will return the flash to it's virgin state (with the bad blocks marked
not in a table but on the units themselves) instead of just 

> It's not using all the flash, because the IPL ROM doesn't 
> know how to address 
> the second half of each page of the flash - so it's wasting 
> 8k (I think).
The reason is the NFTL media header has to start on a unit boundary
the firmware goes into just less then 6 units.

Oron

begin 600 winmail.dat
M>)\^(@T+`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<`
M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.````T`<#`!0`
M#0`1``D``0`6`0$@@`,`#@```-`'`P`4``T`$0`+``$`&`$!"8`!`"$````Y
M-S5!-CDP1$,Q1D1$,S$Q038T1$8P0S(U,$,Q,#`P,``3!P$$@`$`&0```%)%
M.B!1=65S=&EO;G,@86)O=70@351$(``<"`$-@`0``@````(``@`!`Y`&`(0(
M```R````"P`"``$````#`"X``````$``.0"P$PO579*_`1X`<``!````%0``
M`%%U97-T:6]N<R!A8F]U="!-5$0@``````(!<0`!````&P````&_DE:%B1[E
M\U_^,!'3J<H`8)>/?F,``36`L``"`0D0`0```/<"``#S`@``<P0``$Q:1G41
MGCN9`P`*`')C<&<Q,C7B,@-#=&5X!4$!`P'W_PJ``J0#Y`<3`H`/\P!0!%8_
M"%4'LA$E#E$#`0(`8VCA"L!S970R!@`&PQ$E]C,$1A.W,!(L$3,([PGWMCL8
M'PXP-1$B#&!C`%`S"PD!9#,V%E`+IB!$`&%V:60@5R!W,P-@#K`@.@JB"H`^
M()!)<VXG!4!D;PWP$0#`<"`O';!S=7",<&\4$!TP=&\@&"!M`A!R`,`%0&D%
M0`/P=`)H![!&5$P@86?W"W$*XQXB80&`$H$>P`N`9F<?\!/@=#\=YAWD3HL@
M$"#`)P0@:G5S!4"=!)!A`)`C`QVP=V@&\"D=L&]F):-F"V!S:%8L'.`'D'0#
M8'DE=F+N81TP`F`>T&LAY0&1)B&7`'`=,`=`;"<05&@$`/H@!:!M`X$=,"HQ
M&"`IP9QY(!>P!^`F('9E`R!/*F8C,A]@)@!U;"A!97<=Y`[`!9!U#K`=,"#S
M8Z$*P&4N(%D(8"`3X+LKX!_R<R]S)_LI)',#<+IE)@!W+P`=Y!WD02U1?P)`
M$H$L)R`0)/`=L"HQ9/$@52]U;B!4,@HJ$P/P^RG0("%T"'`#H":''_(DDWD=
M$')G(<$E`""0';`HSR#S)^L$(`#`<FL)@!WDKFX=D""P`Z!A,05B+B"_)D`W
M-#4`(,`$("6Q;100\FPKX',I.X$E`"L@'3#_)E$DXS(*'D$DHCM2)/`B\C\I
MP29Z+6`NP#0");))4/$A<%)/31ZQ!Y`>@AWFOFL[4`?@,;$?\B@P9!@@?P02
M'?4ELA00!:`ID1/@;*\F8"91*R`3T"`*L&<F/*P@+3%A)(1W)5!T(O)E'>8X
M**`H22,A"X!K_"DN->8=L"L1,7`#H"HQ]R6R(4,'@&0',"]0/E$2@?\3X#TQ
M+\$!D``@/'([P#SR[R@0"&`ID`K`>2C%)I(X@.9M21`8("!G0R$[@2`!WR3C
M)B`$$26Q`Z`V/.1*U5T=Y$\#8`N0'?-]5"``'@!"$`$````H````/#(R,S4Q
M+CDU,S4T-3(V,4!D979E;#(N87AI;VTN:6YT97)N86P^``,`WC_D!````P`)
M60$````#``"`""`&``````#`````````1@````!2A0``)VH!`!X``8`((`8`
M`````,````````!&`````%2%```!````!````#DN,``+`,N`""`&``````#`
M````````1@`````&A0````````,``H`((`8``````,````````!&``````&%
M````````"P`#@`@@!@``````P````````$8``````X4````````+``2`""`&
M``````#`````````1@`````.A0````````,`!8`((`8``````,````````!&
M`````!"%`````````P`&@`@@!@``````P````````$8`````$84````````#
M``>`""`&``````#`````````1@`````8A0```````!X`"(`((`8``````,``
M``````!&`````#:%```!`````0`````````>``F`""`&``````#`````````
M1@`````WA0```0````$`````````'@`*@`@@!@``````P````````$8`````
M.(4```$````!``````````,`\3\)!```'@`Q0`$````&````3U)/3D\````#
M`!I``````!X`,$`!````!@```$]23TY/`````P`90``````#`/T_Y`0```,`
M)@```````P`V```````#`(`0_____P(!1P`!````-@```&,]55,[83T@.W`]
M32U3>7-T96US.VP]35,M15A#2$%.1T4M,#`P,S(P,3$Q-S`Y6BTV.#(R````
M`@'Y/P$```!,`````````-RG0,C`0A`:M+D(`"LOX8(!`````````"]//4TM
M4UE35$5-4R]/53U414PM059)5B]#3CU214-)4$E%3E13+T-./4]23TY/`!X`
M^#\!````"P```$]R;VX@3V=D86X``!X`.$`!````!@```$]23TY/`````@'[
M/P$```!,`````````-RG0,C`0A`:M+D(`"LOX8(!`````````"]//4TM4UE3
M5$5-4R]/53U414PM059)5B]#3CU214-)4$E%3E13+T-./4]23TY/`!X`^C\!
M````"P```$]R;VX@3V=D86X``!X`.4`!````!@```$]23TY/````0``',.!`
M$M!=DK\!0``(,)`:AM9=DK\!'@`]``$````%````4D4Z(``````>`!T.`0``
M`!4```!1=65S=&EO;G,@86)O=70@351$(``````>`#40`0```#L````\0C$W
M.#DS,#4R03$W1#(Q,4$Y.#8P,#8P.3<X1C=%-C,P,31!,#4R1D!M86EL+FUS
M>7,N8V\N:6P^```+`"D```````L`(P```````P`&$%;@:MX#``<050(```,`
M$!```````P`1$``````>``@0`0```&4```!$059)1%=74D]413I)4TY41$]#
M4$U!4"]%4U504$]314143U)%1D]234%42517251(3D943$%'04E.049415)$
M3TE.1U1(050_3D])5%-*55-415)!4TE.1U1(15=(3TQ%3T94``````(!?P`!
M````.P```#Q",3<X.3,P-3)!,3=$,C$Q03DX-C`P-C`Y-SA&-T4V,S`Q-$$P
8-3)&0&UA:6PN;7-Y<RYC;RYI;#X``-?C
`
end


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Questions about MTD

[Kyle Harris]

Oron Ogdan wrote:
> 
> David W wrote :
> > Isn't docpmap /e supposed to reformat it with NFTL again
> > after doing that?
> >
> No it's just erasing the whole of the flash, Destroying the bad block
> table and all, This command is really low level command that should be
> executed with care. You have to save the bad block table somehow.
> 

I've seen reference to "saving the bad block table" in a couple of
places now. It seems that the file system should be able to dynamically
create/maintain the bad block table. Is this not true?

Just wondering... Kyle.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Questions about MTD

[Oron Ogdan]

Kyle Harris Wrote : 
> I've seen reference to "saving the bad block table" in a couple of
> places now. It seems that the file system should be able to 
> dynamically
> create/maintain the bad block table. Is this not true?
> 
No It's not true, The Bad Block table is static and should not change 
during the life cycle of the device. Just think of the possibility of
a power failure during the update to this table. 

When talking about new bad blocks that occur during the life cycle of the
device, it is very
hard to determine when a new "bad block" is really bad. Just think of 
situations such as power down, Noisy hardware etc. Our philosophy now
(in M-Systems) is marking new bed blocks only in the copy of the bad 
block table that resides in RAM. So further writes to this block will be 
prevented until the next reset. 

In the next reset, Either the block is bad and then the first write 
will fail again and further writes will be prevented, Or it's good and
then can be reused. 

Oron

begin 600 winmail.dat
M>)\^(@H.`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<`
M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.````T`<#`!0`
M$``+``@``0`2`0$@@`,`#@```-`'`P`4`!``"P`(``$`$@$!"8`!`"$```!#
M-S`V138Q13,P1D5$,S$Q03E#03`P-C`Y-SA&-T4V,P`O!P$$@`$`&````%)%
M.B!1=65S=&EO;G,@86)O=70@351$`/P'`0V`!``"`````@`"``$#D`8`X`@`
M`#,````#`#8```````,``(`((`8``````,````````!&`````%*%```G:@$`
M'@`!@`@@!@``````P````````$8`````5(4```$````$````.2XP``L`RX`(
M(`8``````,````````!&``````:%`````````P`"@`@@!@``````P```````
M`$8``````84````````+``.`""`&``````#`````````1@`````#A0``````
M``L`!(`((`8``````,````````!&``````Z%`````````P`%@`@@!@``````
MP````````$8`````$(4````````#``:`""`&``````#`````````1@`````1
MA0````````,`!X`((`8``````,````````!&`````!B%````````'@`(@`@@
M!@``````P````````$8`````-H4```$````!`````````!X`"8`((`8`````
M`,````````!&`````#>%```!`````0`````````>``J`""`&``````#`````
M````1@`````XA0```0````$``````````@$)$`$```!6`P``4@,``%4%``!,
M6D9U9:(8<0,`"@!R8W!G,3(UXC(#0W1E>`5!`0,!]_\*@`*D`^0'$P*`#_,`
M4`16/PA5![(1)0Y1`P$"`&-HX0K`<V5T,@8`!L,1)?8S!$83MS`2+!$S".\)
M][8[&!\.,#41(@Q@8P!0,PL)`60S-A90"Z8@2^!Y;&4@2`K`!1`$(&97`V`.
ML"`Z"N,*@#YP($DG=AT@%!`)\"`M&"!F!)`)\&,=('1OH"`B<V%V"X!G'^!B
M:!T@8F%D(-`7L&-.:Q_@`:`=$"(@"X`@-&$@!:!U"U`=(&]F#QXV"U$?P`0@
M;F]W+K<>H`5`'P%M!"`@H&$%0$T@HF8#$![A>7,.L&WU'O!H"&!L(0$=("&2
M'^+!'C9D>6YA;0W@!T`L;'D>-@4`923`92__`,`+@`&0(?$@KQT0(_$D@M<=
M@2/`)-%R"E`_'C8>-!9.(``D$"<K>"P@5/4IT4(@\4(A."'@!"`EH/<DP`W@
M(A!N(0`E]2N2$]&W('`=(!XT9`AQ('5L!I#Q'2!C>6,B@RFS`0`@4+,?P"/P
M2G4EH"LR;B%@23,E<&\$$&EB`Q!I7'1Y(J<B(#4P=Q*!9K\+<`I`&"`G@#'8
M(F!D*/'?'^(K0RJE'C0>-%<IT"FAO0=`:R!B`:`(8`5`;@?1]R#G)(4A0&,(
M<#=J,G\SA>\N`#6P+U(>T'(H-1/A(0`W'_$!``ZP<B?0.W`@=_<Z4B(@.W(B
M(.<AT00@*-&?*!$@TC/^'C0`D'1U+[%W`B`O<1K0:"(0!"`VE&1](]!N+@`M
M``0`-=!`8G=7"L`=(!0@8R/P3SSA</,K4!>P<V](D#70(\$>-#(H(?%-+0:P
M):)S*?LO4@#`<CK#.W,)@#OF`B#W0V$IE06@<#72*;<>-"$I/R24&"``D`$`
M!"`A\5)!ZDTC\%,@`&8(<"G!!<#^=P40#K`D@3BE(20#\"@0>R92'C1P&"`>
MT`(P2\%U_P(P`Q$IPCMP#M%/D10@.6SN22FD5+@N`$4UL%$"*</_(3-2`B#Q
M,`(IP2FD)3`4`+\%0%%#'B52DS;R(A!G*8+?,`)0S5*64W<N`$\%P#6P^2U1
M9V\$<"_R'C19(R?P_P.@)F$8(#0@"8`Y;%XP`B`%'C1]8D```!X`<``!````
M%````%%U97-T:6]N<R!A8F]U="!-5$0``@%Q``$````;`````;^2=!*5'N8%
M/_XP$=.IR@!@EX]^8P``5\\P``,`)@```````P`N```````+``(``0````,`
M"5D!````'@!"$`$````C````/#,X1#8R0T4Y+C0S0T,S,#$Y0&YE>'5S+71E
M8V@N;F5T/@```P#>/^0$```#`/T_Y`0``$``.0#0P_PB=I*_`0,`\3\)!```
M'@`Q0`$````&````3U)/3D\````#`!I``````!X`,$`!````!@```$]23TY/
M`````P`90``````#`(`0_____PL`\A`!`````@%'``$````V````8SU54SMA
M/2`[<#U-+5-Y<W1E;7,[;#U-4RU%6$-(04Y'12TP,#`S,C`Q-#$Q,#A:+3<R
M.#<````"`?D_`0```$P`````````W*=`R,!"$!JTN0@`*R_A@@$`````````
M+T\]32U365-414U3+T]5/51%3"U!5DE6+T-./5)%0TE0245.5%,O0TX]3U)/
M3D\`'@#X/P$````+````3W)O;B!/9V1A;@``'@`X0`$````&````3U)/3D\`
M```"`?L_`0```$P`````````W*=`R,!"$!JTN0@`*R_A@@$`````````+T\]
M32U365-414U3+T]5/51%3"U!5DE6+T-./5)%0TE0245.5%,O0TX]3U)/3D\`
M'@#Z/P$````+````3W)O;B!/9V1A;@``'@`Y0`$````&````3U)/3D\```!`
M``<PL"E6DW62OP%```@P`&(U(W:2OP$>`#T``0````4```!213H@`````!X`
M'0X!````%````%%U97-T:6]N<R!A8F]U="!-5$0`'@`U$`$````[````/$(Q
M-S@Y,S`U,D$Q-T0R,3%!.3@V,#`V,#DW.$8W138S,#$T03`U-#)`;6%I;"YM
M<WES+F-O+FEL/@``"P`I```````+`",```````,`!A"`Y4V8`P`'$`L#```#
M`!`0``````,`$1``````'@`($`$```!E````2UE,14A!4E))4U=23U1%.DE6
M15-%14Y2149%4D5.0T543R)3059)3D=42$5"041"3$]#2U1!0DQ%(DE.04-/
M55!,14]&4$Q!0T533D]72513145-4U1(05142$5&24Q%4UE35``````"`7\`
M`0```#L````\0C$W.#DS,#4R03$W1#(Q,4$Y.#8P,#8P.3<X1C=%-C,P,31!
9,#4T,D!M86EL+FUS>7,N8V\N:6P^``#Q^0==
`
end


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Questions about MTD

[Kyle Harris]

Oron Ogdan wrote:
> 
> Kyle Harris Wrote :
> > I've seen reference to "saving the bad block table" in a couple of
> > places now. It seems that the file system should be able to
> > dynamically
> > create/maintain the bad block table. Is this not true?
> >
> No It's not true, The Bad Block table is static and should not change
> during the life cycle of the device. Just think of the possibility of
> a power failure during the update to this table.
> 
> When talking about new bad blocks that occur during the life cycle of the
> device, it is very
> hard to determine when a new "bad block" is really bad. Just think of
> situations such as power down, Noisy hardware etc. Our philosophy now
> (in M-Systems) is marking new bed blocks only in the copy of the bad
> block table that resides in RAM. So further writes to this block will be
> prevented until the next reset.
> 
> In the next reset, Either the block is bad and then the first write
> will fail again and further writes will be prevented, Or it's good and
> then can be reused.

So will the device still work if the static table has been deleted?

Kyle.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Questions about MTD

[Dvir Oren]

> We set aside 49152 bytes of that for the firmware. The firmware may not 
> actually take up all of that space, but it's allocated anyway.
> 
> The remainder of the flash is taken up with the actual NFTL filing system. 
> This is a kind of filesystem which emulates a block device.
> 
> Your boot sector is actually in this block device, not on the first 512 bytes 
> of the flash itself. When you overwrite the entire contents of the block 

When I do dd if=/dev/nftla of=some_file bs=512 count=1, what do I 
get?
When I do dd if=/dev/mtd0 of=some_file bs=512 count=1, what do I 
get?


When I do dd if=/dev/nftla of=some_file bs=48k count=1, what do I 
get?
When I do dd if=/dev/mtd0 of=some_file bs=48k count=1, what do I 
get?

> If this is after you've previously used nftl_format without specifying that 
> you want it to start at byte 49152, then there's an NFTL header at the 
> beginning of the flash which will be confusing things. 
> 
> Otherwise, I'm not sure, and I'd need a complete transcript of what you did, 
> and the errors you way.

Suppose I take a brand new flash, run nftl_format /dev/mtd0 49152. 
 I then run fdisk /dev/nftla to create the partition, and then mke2fs 
/dev/nftla1, and then reboot, or remove the modules, and then 
insert them.  When I'll mount /dev/nftla1, it will be trashed.  Before I 
took out the module, I could mount, e2fsck, or whatever, and 
everything was fine.

I have some other weird problems:
I run nftl_format, create a partition, remove the module, then insert 
it, and I get an invalid partition.

And at some point the drivers compiled into the 2.3 kernel stopped 
writing nftla:  nftla1 after writing the partition table in fdisk.  The 
modules still do it.

> The firmware that comes from M-Systems isn't supposed to be just loaded 
> directly into the flash - which is what doc_loadbios does. You're supposed to 
> spread out the first 8k of data over the first 16k of the flash, I think, 
> putting 256 bytes of data at the beginning of each 512-byte page of flash.

Then what should I pass doc_loadbios, and why not simply dd (and 
to where should I dd, and from where should I dd)?

> Not yet. I have grub loading from DiskOnChip, but not then capable of getting 
> a kernel off the NFTL.

I posted here a lilo that should work with MTD.  I'll repost it.

> 
> 
> 
> 
> 
> --
> dwmw2
> 
> 
> 
> 




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Questions about MTD

[David Woodhouse]

dviro@ibm.net said:
>  When I do dd if=/dev/nftla of=some_file bs=512 count=1, what do I
> get?

This goes through the NFTL translation code, and you get the boot sector of 
the simulated hard disk.


> When I do dd if=/dev/mtd0 of=some_file bs=512 count=1, what do I
> get? 

The first 512 bytes of the raw data on the flash, which is the start of the 
firmware bootloader.


dviro@ibm.net said:
> Suppose I take a brand new flash, run nftl_format /dev/mtd0 49152. 
>  I then run fdisk /dev/nftla to create the partition, and then mke2fs
> /dev/nftla1, and then reboot, or remove the modules, and then  insert
> them.  When I'll mount /dev/nftla1, it will be trashed.  Before I
> took out the module, I could mount, e2fsck, or whatever, and
> everything was fine. 

You need to remove the NFTL module before using nftl_format, and then load it 
again afterwards. The NFTL code caches a lot of data about what blocks are 
stored where on the flash, and if you reformat the NFTL while it's loaded, 
you're going to confuse the hell out of it.


dviro@ibm.net said:
>  Then what should I pass doc_loadbios, and why not simply dd (and  to
> where should I dd, and from where should I dd)? 

doc_loadbios is almost the same as dd - it just erases the blocks before 
writing to them. 

You need to convert the DOC121.EXB file into the form in which it actually 
takes on the flash. It's probably easier to explain in pseudo-C than English:

	u_char buf[512];

	memset(buf,255,512);

	/* Split up the first 4Kb of data over the first 8Kb of flash */

	while (x<8192) {
		read(0,buf,256);
		write(1,buf,512);
		x += 512;
	}

	/* Add the rest */

	while (!eof) {
		read(0,buf,512);
		write(1,buf,512);
	}
	

I'm not sure if this is right, but it's something like that. Try comparing 
what you get by dd'ing 48Kb _from_ /dev/mtd0 with the data in the file.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Questions about MTD

[Oron Ogdan]

Kyle Harris Wrote:
> So will the device still work if the static table has been deleted?
> 
Yes and no, Yes after you format it again the bad block table will be empty,
So all blocks (including the originally bad ones will be used) which will
work 99.99% of the time. But No I would not go to manufacturing with such
devices. It can only be used for R&D and even this is pretty risky.

Oron

begin 600 winmail.dat
M>)\^(B(4`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<`
M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.````T`<#`!0`
M%@`S`!D``0!1`0$@@`,`#@```-`'`P`4`!8`,P`@``$`6`$!"8`!`"$````V
M13<U0C<S1#9$1D5$,S$Q038T1#0P0C$U,$,Q,#`P,``4!P$$@`$`&````%)%
M.B!1=65S=&EO;G,@86)O=70@351$`/P'`0V`!``"`````@`"``$#D`8`7`<`
M`#(````+``(``0````,`+@``````0``Y`#`YO0ZNDK\!'@!P``$````4````
M475E<W1I;VYS(&%B;W5T($U41``"`7$``0```!L````!OY*(X%&H.)(;_G01
MTZG*`&"7CWYC``CK.^```@$)$`$```#:`0``U@$``*8"``!,6D9UT6:=$P,`
M"@!R8W!G,3(UXC(#0W1E>`5!`0,!]_\*@`*D`^0'$P*`#_,`4`16/PA5![(1
M)0Y1`P$"`&-HX0K`<V5T,@8`!L,1)?8S!$83MS`2+!$S".\)][8[&!\.,#41
M(@Q@8P!0,PL)`60S-A90"Z8@2^!Y;&4@2`K`!1`$(+97`V`.L#H*H@J`/@8`
ME&\@`_!L`R!T:!T@30$`=@W@'2!S=![2=[D%L&L@!I`?`Q_`81_0OF,?``&@
M'1$3X`0@8@GA9Q]!'1`.L&0_'A8>%%D#!Y$`<&0@;F\L(%<CHP&`$H%Y"&`@
M`A!RRP#`!4!I!4!A9PMQ'P/,8F$D``)@;V,@4"%4HQ[#(?`@96T%,'DD0%\>
MD0=`)[$FT@0@*`N`8S4*0&0+@&<?`P6P:6=["X`HH7DF<P(@!Y$GAG6I%!!D
M*1ZP:`W@:!ZTT2`C.3DN+6`E*C`@A$,?T`>`+B!"=05`3F4>H$D@$75L)`(%
M0&=-'J!T'J`#@75F`-!T_PAQ*=$#\!\0'[`:T"R@'U3J<RZ`205`8P.1`B`J
MPN<KY"4R!_`F1"/3'V`B$?<?$!V!'8%P&"`"0"K0'7'8:WDN'A0>%$\#8`N0
M!1XC?3=0```>`$(0`0```",````\,SA$-C1&,3(N0S$Q1#=&,#9`;F5X=7,M
M=&5C:"YN970^```#`-X_Y`0```,`"5D!`````P``@`@@!@``````P```````
M`$8`````4H4``"=J`0`>``&`""`&``````#`````````1@````!4A0```0``
M``0````Y+C``"P#+@`@@!@``````P````````$8`````!H4````````#``*`
M""`&``````#`````````1@`````!A0````````L``X`((`8``````,``````
M``!&``````.%````````"P`$@`@@!@``````P````````$8`````#H4`````
M```#``6`""`&``````#`````````1@`````0A0````````,`!H`((`8`````
M`,````````!&`````!&%`````````P`'@`@@!@``````P````````$8`````
M&(4````````>``B`""`&``````#`````````1@`````VA0```0````$`````
M````'@`)@`@@!@``````P````````$8`````-X4```$````!`````````!X`
M"H`((`8``````,````````!&`````#B%```!`````0`````````#`/$_"00`
M`!X`,4`!````!@```$]23TY/`````P`:0``````>`#!``0````8```!/4D].
M3P````,`&4```````P#]/^0$```#`"8```````,`-@```````P"`$/____\"
M`4<``0```#8```!C/553.V$](#MP/4TM4WES=&5M<SML/4U3+4580TA!3D=%
M+3`P,#,R,#(P-3$R-5HM.#`Q-P````(!^3\!````3`````````#<IT#(P$(0
M&K2Y"``K+^&"`0`````````O3SU-+5-94U1%35,O3U4]5$5,+4%6258O0TX]
M4D5#25!)14Y44R]#3CU/4D].3P`>`/@_`0````L```!/<F]N($]G9&%N```>
M`#A``0````8```!/4D].3P````(!^S\!````3`````````#<IT#(P$(0&K2Y
M"``K+^&"`0`````````O3SU-+5-94U1%35,O3U4]5$5,+4%6258O0TX]4D5#
M25!)14Y44R]#3CU/4D].3P`>`/H_`0````L```!/<F]N($]G9&%N```>`#E`
M`0````8```!/4D].3P```$``!S#P[7T-KI*_`4``"##0=[42KI*_`1X`/0`!
M````!0```%)%.B``````'@`=#@$````4````475E<W1I;VYS(&%B;W5T($U4
M1``>`#40`0```#L````\0C$W.#DS,#4R03$W1#(Q,4$Y.#8P,#8P.3<X1C=%
M-C,P,31!,#4T-$!M86EL+FUS>7,N8V\N:6P^```+`"D```````L`(P``````
M`P`&$#@GP60#``<0,@$```,`$!```````P`1$``````>``@0`0```&4```!+
M64Q%2$%24DE35U)/5$4Z4T]724Q,5$A%1$5624-%4U1)3$Q73U)+24942$53
M5$%424-404),14A!4T)%14Y$14Q%5$5$/UE%4T%.1$Y/+%E%4T%&5$5264]5
M1D]234%4251!``````(!?P`!````.P```#Q",3<X.3,P-3)!,3=$,C$Q03DX
J-C`P-C`Y-SA&-T4V,S`Q-$$P-30T0&UA:6PN;7-Y<RYC;RYI;#X``--X
`
end


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Questions about MTD

[Kyle Harris]

Oron Ogdan wrote:
> 
> Kyle Harris Wrote:
> > So will the device still work if the static table has been deleted?
> >
> Yes and no, Yes after you format it again the bad block table will be empty,
> So all blocks (including the originally bad ones will be used) which will
> work 99.99% of the time. But No I would not go to manufacturing with such
> devices. It can only be used for R&D and even this is pretty risky.
> 

I don't mean to drag this on.... but I'd really like to understand this.
How are the original bad blocks determined (if they work 99.99% of the
time). Are they the bad blocks indicated by the virgin flash device
(e.g., Samsung indicates bad blocks by writing zero data to the first
page)? Or are they determined by some testing process? I'm guessing the
0.01% failure would be such that data is not retained, since if the
block fails on a write/verify it will simply be mapped as bad and
skipped.

Thanks for any additional info, Kyle.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Questions about MTD

[Oron Ogdan]

Dvir Oren Wrote :
> What happens if I already did docpmap /e, without saving any bad 
> block tables?
> 
> That is, I already did that, and then dformat, which claims 
> to rebuild 
> something (I can't recall ath the moment), and then everything 
> seems fine.  Is there something entirely bad with the flash I'm now 
> using?  Is there a way to rebuild the bad block table?

tough luck, You will never know what was the original table. If you are just
developing you have to remember there is a possibility you are using a bad
block. There is no way to rebuild the bad block table. This command was
removed from the next version of the DiskOnChip utilities and will not be
available to customer in the future. You can achieve the desired results
with dformat /unformat

> 
> Another question not related:
> 
> I have a flash that does not load the "True FFS" at boot time.  It 
> loads the "DOS Sockets", but not the "True FFS".  This makes the 
> flash unbootable.  When I did docpmap /e, it claims there is a fault 
> at some address.  Any ideas?

Docpmap /e does not look at the contents, it just brutally goes unit by unit
and deletes all. I will have to see the exact message but it could be a bad
DiskOnChip that has been traumatized somehow.

Oron

begin 600 winmail.dat
M>)\^(B(4`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<`
M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.````T`<#`!0`
M%@`S`!\``0!7`0$@@`,`#@```-`'`P`4`!8`,P`@``$`6`$!"8`!`"$````W
M,S<U0C<S1#9$1D5$,S$Q038T1#0P0C$U,$,Q,#`P,``#!P$$@`$`&0```%)%
M.B!1=65S=&EO;G,@86)O=70@351$(``<"`$-@`0``@````(``@`!`Y`&`)@)
M```R````"P`"``$````#`"X``````$``.0"`'M`1KI*_`1X`<``!````%0``
M`%%U97-T:6]N<R!A8F]U="!-5$0@``````(!<0`!````&P````&_DJ)"3J@X
MG[#^=!'3J<H`8)>/?F,``KP3$``"`0D0`0````<$```#!```708``$Q:1G7C
M.%A&`P`*`')C<&<Q,C7B,@-#=&5X!4$!`P'W_PJ``J0#Y`<3`H`/\P!0!%8_
M"%4'LA$E#E$#`0(`8VCA"L!S970R!@`&PQ$E]C,$1A.W,!(L$3,([PGWMCL8
M'PXP-1$B#&!C`%`S"PD!9#,V%E`+IB!$M'9I!<!/&"`#H%<#8-D.L"`Z"J(*
M@#X=@!/@<P5`$^!P<`GP!"`&D"`,22`'0!@@861Y(&AD:60@$&\-\`#`<"`@
M+V4L(`/P=&B3"&`%0'-A'0!N9Q^0^FX@`&(?X`KC'D("8"!PU&L@`9%L!Y`_
M'@8>!OY4'I($`"$`'XPA0!Z@(0#7`'`F,AUA9`(0<@#`)H%$=V@-X&@@8PMA
M;2,$(1X5=&\@&"!B=7L#$")X<P-P%"`GX"'A*'4?@&,`<"<%0!@@*R!L[P,@
M'J`H$";Q(`1@!X`",-(I)IEE=@20>2J4*=>+">`H<68+@&4N(!]P/P0@)O$8
M("I)+*$=$&5L5R(T(2(L(V8+8',H$$E@)VT@;F\'X!X&=:L`D"'@/R]Y82$0
M82``?RDI+#(B4B,9(]4>!"D@==YG*!`*0"-`(0!9"&`A$><KP2]`+:$@:S+"
M)]`>H<LTL"^C(`6P:6<+@`=`ZR-D+V!)'V!Y.'$*P!W0OFHS@`5``0`MH!>P
M<"'2_SNB$^`MH"D4!X`&T!*!+\23!``T@7!O!!!I8@,0_R$P(``[IC.#-($U
MYR]@).#_/I4RP#2O-;\O423@/M$%H-YM`X$Q<3H!/>%O+:`@0/\#4BPC+T`.
MT2VA`)`"(#I@RQ]@+#)$!`!K3PA`)^#_(,`A<#^"")`^X44R.+,=L'LB0#1Q
M=@MP"V`CD2D28_\\,2IA!<`+@#'4(7`(<"]1_SAB*R$?D!/0")`]@BQ!`0"'
M`)`8(2E!<W5L=`0@YS&3)T4@T'5N)U0VZB1(YD%)T2_1('$*4#Q`1T+_2=(Q
M`1Z@"8`=]QX&'X`]8_\TD#(D)E(@40>12=(7L")A$2PR(E1R"E`@1D;L4R(K
MX2)`;TGA,.`'@!\O8@5!'A56,CH4(D1/YP7Q(S$4(',B(0`I<`5`_TG25HPO
M8423`,!:,#H4'@;_,B1/L%>B.Q0><1UA'X`@+N<A,"@F/GEF84Z!(H<>H=,J
M4A^09&1.47,O85&0WR``(#`?T"/&'@1$('=5FOYO(U`>H2PR!:`","RA)4%[
M8$$\(V)6X`&0*\`@`&?W5;)/L&!!8B``:/,FL@$`_R.@#K`^X2O`.U$XE#UF
M+L&_+",.P`#0!4`'@2&@9T-A_R%Q8$((8"FA2A(B0T?Y55//$^`$(#XP'6%T
M<F&@)X&<:7I%\2I2(5!W+C;J%QU``B`>!'URP``>`$(0`0```"H````\,C`P
M,#`S,C`Q.#0T+E9!03(T-#`U0&UR96QA>2YM<WES+F-O+FEL/@````,`WC_D
M!````P`)60$````#``"`""`&``````#`````````1@````!2A0``)VH!`!X`
M`8`((`8``````,````````!&`````%2%```!````!````#DN,``+`,N`""`&
M``````#`````````1@`````&A0````````,``H`((`8``````,````````!&
M``````&%````````"P`#@`@@!@``````P````````$8``````X4````````+
M``2`""`&``````#`````````1@`````.A0````````,`!8`((`8``````,``
M``````!&`````!"%`````````P`&@`@@!@``````P````````$8`````$84`
M```````#``>`""`&``````#`````````1@`````8A0```````!X`"(`((`8`
M`````,````````!&`````#:%```!`````0`````````>``F`""`&``````#`
M````````1@`````WA0```0````$`````````'@`*@`@@!@``````P```````
M`$8`````.(4```$````!``````````,`\3\)!```'@`Q0`$````&````3U)/
M3D\````#`!I``````!X`,$`!````!@```$]23TY/`````P`90``````#`/T_
MY`0```,`)@```````P`V```````#`(`0_____P(!1P`!````-@```&,]55,[
M83T@.W`]32U3>7-T96US.VP]35,M15A#2$%.1T4M,#`P,S(P,C`U,3,Q6BTX
M,#$X`````@'Y/P$```!,`````````-RG0,C`0A`:M+D(`"LOX8(!````````
M`"]//4TM4UE35$5-4R]/53U414PM059)5B]#3CU214-)4$E%3E13+T-./4]2
M3TY/`!X`^#\!````"P```$]R;VX@3V=D86X``!X`.$`!````!@```$]23TY/
M`````@'[/P$```!,`````````-RG0,C`0A`:M+D(`"LOX8(!`````````"]/
M/4TM4UE35$5-4R]/53U414PM059)5B]#3CU214-)4$E%3E13+T-./4]23TY/
M`!X`^C\!````"P```$]R;VX@3V=D86X``!X`.4`!````!@```$]23TY/````
M0``',&#A20^NDK\!0``(,.!&QA*NDK\!'@`]``$````%````4D4Z(``````>
M`!T.`0```!4```!1=65S=&EO;G,@86)O=70@351$(``````>`#40`0```#L`
M```\0C$W.#DS,#4R03$W1#(Q,4$Y.#8P,#8P.3<X1C=%-C,P,31!,#4T-4!M
M86EL+FUS>7,N8V\N:6P^```+`"D```````L`(P```````P`&$$83?T,#``<0
MR@,```,`$!```````P`1$``````>``@0`0```&4```!$5DE23U)%3E=23U1%
M.E=(051(05!014Y3249)04Q214%$641)1$1/0U!-05`O12Q7251(3U544T%6
M24Y'04Y90D%$0DQ/0TM404),15,_5$A!5$E3+$E!3%)%04191$E$5$A!````
M``(!?P`!````.P```#Q",3<X.3,P-3)!,3=$,C$Q03DX-C`P-C`Y-SA&-T4V
>,S`Q-$$P-30U0&UA:6PN;7-Y<RYC;RYI;#X``+4S
`
end


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Questions about MTD

[Oron Ogdan]

Kyle Harris Wrote :
> I don't mean to drag this on.... but I'd really like to 
> understand this.
> How are the original bad blocks determined (if they work 99.99% of the
> time). Are they the bad blocks indicated by the virgin flash device
> (e.g., Samsung indicates bad blocks by writing zero data to the first
> page)? Or are they determined by some testing process? I'm 
> guessing the
> 0.01% failure would be such that data is not retained, since if the
> block fails on a write/verify it will simply be mapped as bad and
> skipped.

By all means it's great that you show interest :-), 

Toshiba / Samsung after manufacturing the device, Are putting the device
through extreme conditions (high / low temperature) and program each unit,
The ones that fail under these extreme conditions (data not verified
correctly, internal flash controller not returning success in it's status
register etc.) are considered bad. Usually in the DiskOnChip 2000 it's
between 0 - 0.2% of the units. On DiskOnChip Millennium it less then that
even. But most of these blocks would be just fine in the first couple of
thousands or writes and under normal conditions.

The way they mark bad blocks is by putting zeros in an otherwise completely
deleted or erased unit. We scan the units in a virgin media and never
program them or use them in the life cycle of the device.

Oron

begin 600 winmail.dat
M>)\^(@<,`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<`
M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.````T`<#`!4`
M#@`D``4``@`H`0$@@`,`#@```-`'`P`5``X`)``&``(`*0$!"8`!`"$````P
M.$)#,T)&,$8W1D5$,S$Q038T1$0P03(U,$,Q,#`P,``H!P$$@`$`&````%)%
M.B!1=65S=&EO;G,@86)O=70@351$`/P'`0V`!``"`````@`"``$#D`8`Y`D`
M`#(````+``(``0````,`+@``````0``Y`/"QJ`8RD[\!'@!P``$````4````
M475E<W1I;VYS(&%B;W5T($U41``"`7$``0```!L````!OY+ALZ]LTQLK_LD1
MTZG*`&"7CWYC`!/)L]```@$)$`$```!B!```7@0``+,&``!,6D9UK_H`MP,`
M"@!R8W!G,3(UXC(#0W1E>`5!`0,!]_\*@`*D`^0'$P*`#_,`4`16/PA5![(1
M)0Y1`P$"`&-HX0K`<V5T,@8`!L,1)?8S!$83MS`2+!$S".\)][8[&!\.,#41
M(@Q@8P!0,PL)`60S-A90"Z8@2^!Y;&4@2`K`!1`$(&97`V`.L"`Z"J(*@#[0
M($D@9`(@)P5`!X")`Y%T;QZP<F%G'V`6:!V!`B`N(&$@8G5A!4!))V0@&"`'
M0&S@>2!L:6L=(!]Q'B9T=6X$@7,!D"*P'^,NN1XF2&\'X`K`(=%H'2"Y!;!I
M9PN`!T`@H&$A$'$"8&]C:P0@`0`.L'+F;0N`"8`@*`:0))(A@()W!;!K(#DY
M+B>PKB4@,";S'B9T!W$I()"_!Q`D@R&`)*(E>0N`9`W@CF$.L"61*>1V:7(E
M$60@9@M@<V@F$2P`8X$H=RAE+F<N+`8!_&US(J`?T"KV!"`E>2N1[G<%$"D`
M+G%Z!)`?@2M`]F$?8B2B9BP0(O`>)@JPXF<I,#\@3P7`)&4A@'LF*2N1<P-P
M(=$'D#!3<%\#8"T0!!`RT"#P;2(79P\*4`00,&(H63`N,#$]*`!F"W`*0"1Q
M)V!U;/\ED1T@+E`3T!_A*T`PY!V!_FX=T"$A`9`F@BX`-O$M$'\JX"@[);,X
M0R`B)%`P$V7\+W8&<B&`,$`G4`,0`R`]`)!M"U`A@#DQ`,!P<)\FH2R0)6,C
M$1XF<VL%(/<_T2.5'B1"(8`A41\3*M&\="<$(`G!.=$YLWD(8'TT@&@D,0N`
M)D$T\1X`+:8I+@!!NE1O+*!I)7!T("\N%V$!@!*!`X%U^3A08W0(<3<4+,4N
M`"ER/G`@P#!32-@?X0-@=6?_++`.P1@@-+$%H"L!*0`"(/T$("@@`$M11O`7
ML`?@#K#O/R`$D"M`.)$I0'(U4@G`?RXP2W``T"RP(J`P0"X`5/\DLB:0!"`Y
MLSA2(I0DDA00_TM_3((P\SJ"/A,(D"$0!:'_&"!(4"%P+@!$TR4R+'1,`?]1
MP`;P'1`%P#J%"'`#`"YQ_SEA-9(JX4,T(O%(8`0@&"#/)1`B\!*!%"!C+DXA
M)'&_3`$`D`2!*V(E@""052Y0ER%3+$$DHD0$`&M/"$!Y(`!P(`'07(!#-#DP
M=*9W">$WX"`M-^$R*`;?3T,C@#+@`Z!;R4T^P0GP_0,`=380/H$=$`01)*%;
M8N\YT2S@"?`@D$(@P01@13'O*"11<26U.-=J6'!0<2:!]UM&,;-+\74+4"3!
M)O((8/YS(Q$@(07`/;,$(",24.0_.H`F8"5!3`A!JT^R=V'_*>,A@`#`)X$J
M2B_32=8PHN]7DP.1'=`DL'(#\4OB/R'_)C$A<0$`;E(A$`6Q3;$4$/=GHC!`
M()!7.4$K,%MD7I/_;0,K]@>`*Q`Q(",2)I`^$?].=R2A-A`%L5AP)(-@<5MD
MY2&@9DOA>6-EYDCV0:L7,O`"(!XD?7@@```>`$(0`0```",````\,SA$-D4U
M.#,N,T,R13$S,S1`;F5X=7,M=&5C:"YN970^```#`-X_Y`0```,`"5D!````
M`P``@`@@!@``````P````````$8`````4H4``"=J`0`>``&`""`&``````#`
M````````1@````!4A0```0````0````Y+C``"P#+@`@@!@``````P```````
M`$8`````!H4````````#``*`""`&``````#`````````1@`````!A0``````
M``L``X`((`8``````,````````!&``````.%````````"P`$@`@@!@``````
MP````````$8`````#H4````````#``6`""`&``````#`````````1@`````0
MA0````````,`!H`((`8``````,````````!&`````!&%`````````P`'@`@@
M!@``````P````````$8`````&(4````````>``B`""`&``````#`````````
M1@`````VA0```0````$`````````'@`)@`@@!@``````P````````$8`````
M-X4```$````!`````````!X`"H`((`8``````,````````!&`````#B%```!
M`````0`````````#`/$_"00``!X`,4`!````!@```$]23TY/`````P`:0```
M```>`#!``0````8```!/4D].3P````,`&4```````P#]/^0$```#`"8`````
M``,`-@```````P"`$/____\"`4<``0```#8```!C/553.V$](#MP/4TM4WES
M=&5M<SML/4U3+4580TA!3D=%+3`P,#,R,3$R,S8P-5HM.38V,`````(!^3\!
M````3`````````#<IT#(P$(0&K2Y"``K+^&"`0`````````O3SU-+5-94U1%
M35,O3U4]5$5,+4%6258O0TX]4D5#25!)14Y44R]#3CU/4D].3P`>`/@_`0``
M``L```!/<F]N($]G9&%N```>`#A``0````8```!/4D].3P````(!^S\!````
M3`````````#<IT#(P$(0&K2Y"``K+^&"`0`````````O3SU-+5-94U1%35,O
M3U4]5$5,+4%6258O0TX]4D5#25!)14Y44R]#3CU/4D].3P`>`/H_`0````L`
M``!/<F]N($]G9&%N```>`#E``0````8```!/4D].3P```$``!S"@_3,#,I._
M`4``"#!@N<(&,I._`1X`/0`!````!0```%)%.B``````'@`=#@$````4````
M475E<W1I;VYS(&%B;W5T($U41``>`#40`0```#L````\0C$W.#DS,#4R03$W
M1#(Q,4$Y.#8P,#8P.3<X1C=%-C,P,31!,#4U0T!M86EL+FUS>7,N8V\N:6P^
M```+`"D```````L`(P```````P`&$&J4K[`#``<0-`0```,`$!```````P`1
M$``````>``@0`0```&4```!+64Q%2$%24DE35U)/5$4Z241/3E1-14%.5$]$
M4D%'5$A)4T].0E54241214%,3%E,24M%5$]53D1%4E-404Y$5$A)4TA/5T%2
M151(14]224=)3D%,0D%$0DQ/0TM31$5415)-``````(!?P`!````.P```#Q"
M,3<X.3,P-3)!,3=$,C$Q03DX-C`P-C`Y-SA&-T4V,S`Q-$$P-35#0&UA:6PN
/;7-Y<RYC;RYI;#X``$I7
`
end


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org