* Re: Problems with r/w on mtdblock0
@ 2000-12-06 2:45 Ian
0 siblings, 0 replies; 18+ messages in thread
From: Ian @ 2000-12-06 2:45 UTC (permalink / raw)
To: Ollie Lho; +Cc: mtd
> Of course it WILL BEHAVIOR THIS WAY !!!!
What is /dev/mtd0 ?
Is it a "raw" device ... do I see unhindered access to the DoC Millennium, or am
I being processed in some way (maybe address mapped) .. ?
> The DoC has an NAND flash chip in side. For NAND flash chip
> you can only turn each bit form 1 to 0 by WRITE operation,
> not the other way around. The only way to turn a 0 bit to 1
> is by a ERASE operation. This is why I have to erase the first
> few Erase Blocks befor writing the DoC in my loaddoc script.
>
> # Erase the first 128 pages of the DoC,
> # 128 pages == 128 page * 512 bytes per page == 1 MB
> ./erase /dev/mtd0 0 128
>
> # Use dd to (zero) pad linuxbios.strip to 63 KB
> dd conv=sync bs=63k if=$LINUXBIOS/util/config/winfast/linuxbios.strip
> of=linuxbios.block
>
> # Use dd to wrtie IPL to the first and second pages (page 0, 1) on the DoC
> # N.B. if you are using 2.4.0-test10 and later kernel, the conv=notrunc
> # is neceressary.
> dd if=$LINUXBIOS/util/config/winfast/docipl of=/dev/mtd0 conv=notrunc
> dd if=$LINUXBIOS/util/config/winfast/docipl of=/dev/mtd0 seek=1 conv=notrunc
>
>
> Ollie
>
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
>
--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
@ 2000-12-06 4:33 Ian
0 siblings, 0 replies; 18+ messages in thread
From: Ian @ 2000-12-06 4:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: mtd
Check this out ...
bash# dd if=/dev/mtdblock0 of=crap count=1 bs=16384
end_request: I/O error, dev 1f:00 (mtdblock), sector 0
end_request: I/O error, dev 1f:00 (mtdblock), sector 8
end_request: I/O error, dev 1f:00 (mtdblock), sector 16
end_request: I/O error, dev 1f:00 (mtdblock), sector 24
dd: /dev/mtdblock0: Input/output error
0+0 records in
0+0 records out
bash#
.. thoughts?
----- Original Message -----
>From: "Nicolas Pitre" <nico@cam.org>
>To: "Ian" <Relativity@HumanHeuristic.com>
>Subject: Re: Problems with r/w on mtdblock0
>Date: Tue, 05 Dec 2000 21:52:37 -0500
>
>
>
> On Wed, 6 Dec 2000, Ian wrote:
>
> >
> > Well, that's how this started;
> >
> >
> > > bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
> > > end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> > > dd: /dev/mtdblock0: Input/output error
> > > 1+0 records in
> > > 0+0 records out
> > >
> > > bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
> > > end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> > > /bin/dd: /dev/mtdblock0: Input/output error
> > > 0+0 records in
> > > 0+0 records out
>
> The above should be considered as a mtdblock bug IMHO.
>
> > .. and Ollie said ...
> >
> > > The /dev/mtdblockN device the the "block device" node for MTD devices.
> > > In the DoC case, it can only read/write data in 8KB block (the erase size).
> > > You can not read/write 512B on itm it will get "cached" by the driver. If
>
> It shouldn't matter. The driver will actually write 8k if that's the erase
> size regardless of the size of your access.
>
> > > you are playing with the IPL stuff, WRITE TO /dev/mtd0.
>
> Hmmm.... What's IPL?
>
> > ... which then started a series of questions about whether or not its being cached
> > and I'm just rebooting too soon, if that's possible.
>
> No it's not, unless you actually reboot before dd return to the shell
> prompt.
>
> > *BUT* .. as above .. I'm getting
> > errors to that device (that I didn't used to).
>
> ... and that you shouldn't.
>
> I just don't have any hardware with DiskOnChip or NAND flash to test and fix
> the problem... therefore I'm not aware of the difference with NOR flash as
> far as the block interface is concerned.
>
> Any hints someone?
>
>
>
> Nicolas
>
>
--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
@ 2000-12-06 3:07 Ian
0 siblings, 0 replies; 18+ messages in thread
From: Ian @ 2000-12-06 3:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: mtd, linuxbios
> The above should be considered as a mtdblock bug IMHO.
As long as its not my own doofusness ... but I can't see how ...
> It shouldn't matter. The driver will actually write 8k if that's the erase
> size regardless of the size of your access.
Yeah ... that's what I reckon too ... but Ollie's part of (if not all of) the DoC
writing team ... so I try not to doubt it (the software's) ability :)
> > > you are playing with the IPL stuff, WRITE TO /dev/mtd0.
> Hmmm.... What's IPL?
Initial program loader ... there's a bunch of us @ linuxBIOS taking these things
and sticking them into the Motherboard's BIOS socket, then booting linux off of
it. Unfortunately, I'm the only guy *not* doing that at night .. because mines
broken :-(
> No it's not, unless you actually reboot before dd return to the shell
> prompt.
Yeah .. that's what I would've thought .. (after yesterday's thread).
> ... and that you shouldn't.
>
> I just don't have any hardware with DiskOnChip or NAND flash to test and fix
> the problem... therefore I'm not aware of the difference with NOR flash as
> far as the block interface is concerned.
>
> Any hints someone?
If you want me to try things and send you results, I'm cool with that. I'd *rather* be
writing to the block device (at least you should be able to "sync" it).
--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
@ 2000-12-06 2:28 Ian
2000-12-06 2:52 ` Nicolas Pitre
0 siblings, 1 reply; 18+ messages in thread
From: Ian @ 2000-12-06 2:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: mtd, linuxbios
Well, that's how this started;
> bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
> end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> dd: /dev/mtdblock0: Input/output error
> 1+0 records in
> 0+0 records out
>
> bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
> end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> /bin/dd: /dev/mtdblock0: Input/output error
> 0+0 records in
> 0+0 records out
.. and Ollie said ...
> The /dev/mtdblockN device the the "block device" node for MTD devices.
> In the DoC case, it can only read/write data in 8KB block (the erase size).
> You can not read/write 512B on itm it will get "cached" by the driver. If
> you are playing with the IPL stuff, WRITE TO /dev/mtd0.
... which then started a series of questions about whether or not its being cached
and I'm just rebooting too soon, if that's possible. *BUT* .. as above .. I'm getting
errors to that device (that I didn't used to).
See my next message (I'm currently writing) re access level via /dev/mtd0 ...
.. but then all of this thread is irrelevant (to me) if I can get my BIOS warez onto
the chip at the right location (which it appears the doc_loadbios has done), but
I still don't get my BIOS app touched ... so something still isn't sitting right ...
I'm doing testing at the moment ... there *shouldn't* be a driver error ... I'm
stickin' with the Wookie defence ... ;)
> However using /dev/mtdblock0 should produce the same result as if you wrote
> to a disk partition or a file. The latest MTD block interface always erase
> the flash region it is going to write to. Even for large erase sectors the
> code is backing the entire sector, patching the data to write into it and
> eventually rewriting the whole sector back.
>
> So doing
>
> dd if=some_file of=/dev/mtdblock0 bs=512 count=1
>
> or even
>
> cp foobar.fs /dev/mtdblock1
>
> should just work. If it doesn't then there is a bug. It actually works
> just fine with NOR flash devices.
>
>
> Nicolas
>
--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
2000-12-06 2:28 Ian
@ 2000-12-06 2:52 ` Nicolas Pitre
0 siblings, 0 replies; 18+ messages in thread
From: Nicolas Pitre @ 2000-12-06 2:52 UTC (permalink / raw)
To: Ian; +Cc: mtd, linuxbios
On Wed, 6 Dec 2000, Ian wrote:
>
> Well, that's how this started;
>
>
> > bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
> > end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> > dd: /dev/mtdblock0: Input/output error
> > 1+0 records in
> > 0+0 records out
> >
> > bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
> > end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> > /bin/dd: /dev/mtdblock0: Input/output error
> > 0+0 records in
> > 0+0 records out
The above should be considered as a mtdblock bug IMHO.
> .. and Ollie said ...
>
> > The /dev/mtdblockN device the the "block device" node for MTD devices.
> > In the DoC case, it can only read/write data in 8KB block (the erase size).
> > You can not read/write 512B on itm it will get "cached" by the driver. If
It shouldn't matter. The driver will actually write 8k if that's the erase
size regardless of the size of your access.
> > you are playing with the IPL stuff, WRITE TO /dev/mtd0.
Hmmm.... What's IPL?
> ... which then started a series of questions about whether or not its being cached
> and I'm just rebooting too soon, if that's possible.
No it's not, unless you actually reboot before dd return to the shell
prompt.
> *BUT* .. as above .. I'm getting
> errors to that device (that I didn't used to).
... and that you shouldn't.
I just don't have any hardware with DiskOnChip or NAND flash to test and fix
the problem... therefore I'm not aware of the difference with NOR flash as
far as the block interface is concerned.
Any hints someone?
Nicolas
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
@ 2000-12-06 0:19 Ian
2000-12-06 0:41 ` Ollie Lho
0 siblings, 1 reply; 18+ messages in thread
From: Ian @ 2000-12-06 0:19 UTC (permalink / raw)
To: Ronald G Minnich; +Cc: mtd, linuxbios
Ok - I have more info (and I retract my self-scumbagging from yesterday :-)
In the cases where you can "dd if=any_file of=/dev/mtd0 bs=512 count=1" and
get *no* change in the DoC content (verified with a "hexdump -v /dec/mtd0") ..
If you, instead, try a "doc_loadbios /dev/mtd0 any_file" you should see your
"any_file" contents stick to /dev/mtd0's content. See here, result of;
#cat crt0.bin crt0.bin > bios
#doc_loadbios /dev/mtd0 bios
#hdexdump -v /dev/mtd0 | more
0000000 69b0 80e6 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 0000 0000 0000 0000 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000090 0000 0000 0000 0000 0000 0000 0000 0000
00000a0 0000 0000 0000 0000 0000 0000 0000 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 0000 0000 0000 0000 0000 0000 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100 0000 0000 0000 0000 0000 0000 0000 0000
0000110 0000 0000 0000 0000 0000 0000 0000 0000
0000120 0000 0000 0000 0000 0000 0000 0000 0000
0000130 0000 0000 0000 0000 0000 0000 0000 0000
0000140 0000 0000 0000 0000 0000 0000 0000 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
0000160 0000 0000 0000 0000 0000 0000 0000 0000
0000170 0000 0000 0000 0000 0000 0000 0000 0000
0000180 0000 0000 0000 0000 0000 0000 0000 0000
0000190 0000 0000 0000 0000 0000 0000 0000 0000
00001a0 0000 0000 0000 0000 0000 0000 0000 0000
00001b0 0000 0000 0000 0000 0000 0000 0000 0000
00001c0 0000 0000 0000 0000 0000 0000 0000 0000
00001d0 0000 0000 0000 0000 0000 0000 0000 0000
00001e0 0000 0000 0000 0000 0000 0000 0000 0000
00001f0 00ea 0000 f4fe 0000 0000 0000 0000 ffff
0000200 69b0 80e6 0000 0000 0000 0000 0000 0000
0000210 0000 0000 0000 0000 0000 0000 0000 0000
0000220 0000 0000 0000 0000 0000 0000 0000 0000
0000230 0000 0000 0000 0000 0000 0000 0000 0000
0000240 0000 0000 0000 0000 0000 0000 0000 0000
0000250 0000 0000 0000 0000 0000 0000 0000 0000
0000260 0000 0000 0000 0000 0000 0000 0000 0000
0000270 0000 0000 0000 0000 0000 0000 0000 0000
0000280 0000 0000 0000 0000 0000 0000 0000 0000
0000290 0000 0000 0000 0000 0000 0000 0000 0000
00002a0 0000 0000 0000 0000 0000 0000 0000 0000
00002b0 0000 0000 0000 0000 0000 0000 0000 0000
00002c0 0000 0000 0000 0000 0000 0000 0000 0000
00002d0 0000 0000 0000 0000 0000 0000 0000 0000
00002e0 0000 0000 0000 0000 0000 0000 0000 0000
00002f0 0000 0000 0000 0000 0000 0000 0000 0000
0000300 0000 0000 0000 0000 0000 0000 0000 0000
0000310 0000 0000 0000 0000 0000 0000 0000 0000
0000320 0000 0000 0000 0000 0000 0000 0000 0000
0000330 0000 0000 0000 0000 0000 0000 0000 0000
0000340 0000 0000 0000 0000 0000 0000 0000 0000
0000350 0000 0000 0000 0000 0000 0000 0000 0000
0000360 0000 0000 0000 0000 0000 0000 0000 0000
0000370 0000 0000 0000 0000 0000 0000 0000 0000
0000380 0000 0000 0000 0000 0000 0000 0000 0000
0000390 0000 0000 0000 0000 0000 0000 0000 0000
00003a0 0000 0000 0000 0000 0000 0000 0000 0000
00003b0 0000 0000 0000 0000 0000 0000 0000 0000
00003c0 0000 0000 0000 0000 0000 0000 0000 0000
00003d0 0000 0000 0000 0000 0000 0000 0000 0000
00003e0 0000 0000 0000 0000 0000 0000 0000 0000
00003f0 00ea 0000 f4fe 0000 0000 0000 0000 ffff
However! If you *then* do a dd and transfer any_other_file
into /dev/mtd0, the new contents are logically "and"ed with
the old contents of /dev/mtd0. Ie;
#dd if=doc_loadbios of=/dev/mtd0 bs=512 count=2
#hexdump -v /dev/mtd0 | more
0000000 4130 0044 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 0000 0000 0000 0000 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000090 0000 0000 0000 0000 0000 0000 0000 0000
00000a0 0000 0000 0000 0000 0000 0000 0000 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 0000 0000 0000 0000 0000 0000 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100 0000 0000 0000 0000 0000 0000 0000 0000
0000110 0000 0000 0000 0000 0000 0000 0000 0000
0000120 0000 0000 0000 0000 0000 0000 0000 0000
0000130 0000 0000 0000 0000 0000 0000 0000 0000
0000140 0000 0000 0000 0000 0000 0000 0000 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
0000160 0000 0000 0000 0000 0000 0000 0000 0000
0000170 0000 0000 0000 0000 0000 0000 0000 0000
0000180 0000 0000 0000 0000 0000 0000 0000 0000
0000190 0000 0000 0000 0000 0000 0000 0000 0000
00001a0 0000 0000 0000 0000 0000 0000 0000 0000
00001b0 0000 0000 0000 0000 0000 0000 0000 0000
00001c0 0000 0000 0000 0000 0000 0000 0000 0000
00001d0 0000 0000 0000 0000 0000 0000 0000 0000
00001e0 0000 0000 0000 0000 0000 0000 0000 0000
00001f0 0022 0000 0012 0000 0000 0000 0000 0804
0000200 0020 0000 0000 0000 0000 0000 0000 0000
0000210 0000 0000 0000 0000 0000 0000 0000 0000
0000220 0000 0000 0000 0000 0000 0000 0000 0000
0000230 0000 0000 0000 0000 0000 0000 0000 0000
0000240 0000 0000 0000 0000 0000 0000 0000 0000
0000250 0000 0000 0000 0000 0000 0000 0000 0000
0000260 0000 0000 0000 0000 0000 0000 0000 0000
0000270 0000 0000 0000 0000 0000 0000 0000 0000
0000280 0000 0000 0000 0000 0000 0000 0000 0000
0000290 0000 0000 0000 0000 0000 0000 0000 0000
00002a0 0000 0000 0000 0000 0000 0000 0000 0000
00002b0 0000 0000 0000 0000 0000 0000 0000 0000
00002c0 0000 0000 0000 0000 0000 0000 0000 0000
00002d0 0000 0000 0000 0000 0000 0000 0000 0000
00002e0 0000 0000 0000 0000 0000 0000 0000 0000
00002f0 0000 0000 0000 0000 0000 0000 0000 0000
0000300 0000 0000 0000 0000 0000 0000 0000 0000
0000310 0000 0000 0000 0000 0000 0000 0000 0000
0000320 0000 0000 0000 0000 0000 0000 0000 0000
0000330 0000 0000 0000 0000 0000 0000 0000 0000
0000340 0000 0000 0000 0000 0000 0000 0000 0000
0000350 0000 0000 0000 0000 0000 0000 0000 0000
0000360 0000 0000 0000 0000 0000 0000 0000 0000
0000370 0000 0000 0000 0000 0000 0000 0000 0000
0000380 0000 0000 0000 0000 0000 0000 0000 0000
0000390 0000 0000 0000 0000 0000 0000 0000 0000
00003a0 0000 0000 0000 0000 0000 0000 0000 0000
00003b0 0000 0000 0000 0000 0000 0000 0000 0000
00003c0 0000 0000 0000 0000 0000 0000 0000 0000
00003d0 0000 0000 0000 0000 0000 0000 0000 0000
00003e0 0000 0000 0000 0000 0000 0000 0000 0000
00003f0 0028 0000 0406 0000 0000 0000 0000 0000
So if I take a hexdump of the first line of the "doc_loadbios" binary;
#hexdump -v doc_loadbios | more
0000000 457f 464c 0101 0001 0000 0000 0000 0000
.. the first line of my bios image;
#hdexdump -v bios | more
0000000 69b0 80e6 0000 0000 0000 0000 0000 0000
.. and "and" the two;
0110100110110000 = 69b0h
0100010101111111 = 4575h
================
0100000100110000
... I get the first word displayed by /dev/mtd0 after the dd (see above)
0100000100110000 = 4130h
Is /dev/mtd0 supposed to behave like this, or have I just rediscovered a
deliberate "feature" ... ?
> I was confused too. All I can tell you is I have seen cases where the
> write doesn't "stick".
>
> ron
--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
2000-12-06 0:19 Ian
@ 2000-12-06 0:41 ` Ollie Lho
2000-12-06 2:18 ` Nicolas Pitre
0 siblings, 1 reply; 18+ messages in thread
From: Ollie Lho @ 2000-12-06 0:41 UTC (permalink / raw)
To: Ian; +Cc: Ronald G Minnich, mtd, linuxbios
Ian wrote:
>
> However! If you *then* do a dd and transfer any_other_file
> into /dev/mtd0, the new contents are logically "and"ed with
> the old contents of /dev/mtd0. Ie;
>
>
> So if I take a hexdump of the first line of the "doc_loadbios" binary;
> #hexdump -v doc_loadbios | more
> 0000000 457f 464c 0101 0001 0000 0000 0000 0000
>
> .. the first line of my bios image;
> #hdexdump -v bios | more
> 0000000 69b0 80e6 0000 0000 0000 0000 0000 0000
>
> .. and "and" the two;
> 0110100110110000 = 69b0h
> 0100010101111111 = 4575h
> ================
> 0100000100110000
>
> ... I get the first word displayed by /dev/mtd0 after the dd (see above)
> 0100000100110000 = 4130h
>
> Is /dev/mtd0 supposed to behave like this, or have I just rediscovered a
> deliberate "feature" ... ?
>
Of course it WILL BEHAVIOR THIS WAY !!!!
The DoC has an NAND flash chip in side. For NAND flash chip
you can only turn each bit form 1 to 0 by WRITE operation,
not the other way around. The only way to turn a 0 bit to 1
is by a ERASE operation. This is why I have to erase the first
few Erase Blocks befor writing the DoC in my loaddoc script.
# Erase the first 128 pages of the DoC,
# 128 pages == 128 page * 512 bytes per page == 1 MB
./erase /dev/mtd0 0 128
# Use dd to (zero) pad linuxbios.strip to 63 KB
dd conv=sync bs=63k if=$LINUXBIOS/util/config/winfast/linuxbios.strip \
of=linuxbios.block
# Use dd to wrtie IPL to the first and second pages (page 0, 1) on the DoC
# N.B. if you are using 2.4.0-test10 and later kernel, the conv=notrunc
# is neceressary.
dd if=$LINUXBIOS/util/config/winfast/docipl of=/dev/mtd0 conv=notrunc
dd if=$LINUXBIOS/util/config/winfast/docipl of=/dev/mtd0 seek=1 conv=notrunc
Ollie
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
2000-12-06 0:41 ` Ollie Lho
@ 2000-12-06 2:18 ` Nicolas Pitre
0 siblings, 0 replies; 18+ messages in thread
From: Nicolas Pitre @ 2000-12-06 2:18 UTC (permalink / raw)
To: Ollie Lho; +Cc: Ian, Ronald G Minnich, mtd, linuxbios
On Wed, 6 Dec 2000, Ollie Lho wrote:
> Ian wrote:
> >
>
> > However! If you *then* do a dd and transfer any_other_file
> > into /dev/mtd0, the new contents are logically "and"ed with
> > the old contents of /dev/mtd0. Ie;
> >
> >
> > So if I take a hexdump of the first line of the "doc_loadbios" binary;
> > #hexdump -v doc_loadbios | more
> > 0000000 457f 464c 0101 0001 0000 0000 0000 0000
> >
> > .. the first line of my bios image;
> > #hdexdump -v bios | more
> > 0000000 69b0 80e6 0000 0000 0000 0000 0000 0000
> >
> > .. and "and" the two;
> > 0110100110110000 = 69b0h
> > 0100010101111111 = 4575h
> > ================
> > 0100000100110000
> >
> > ... I get the first word displayed by /dev/mtd0 after the dd (see above)
> > 0100000100110000 = 4130h
> >
> > Is /dev/mtd0 supposed to behave like this, or have I just rediscovered a
> > deliberate "feature" ... ?
> >
>
>
> Of course it WILL BEHAVIOR THIS WAY !!!!
>
> The DoC has an NAND flash chip in side. For NAND flash chip
> you can only turn each bit form 1 to 0 by WRITE operation,
> not the other way around. The only way to turn a 0 bit to 1
> is by a ERASE operation.
However using /dev/mtdblock0 should produce the same result as if you wrote
to a disk partition or a file. The latest MTD block interface always erase
the flash region it is going to write to. Even for large erase sectors the
code is backing the entire sector, patching the data to write into it and
eventually rewriting the whole sector back.
So doing
dd if=some_file of=/dev/mtdblock0 bs=512 count=1
or even
cp foobar.fs /dev/mtdblock1
should just work. If it doesn't then there is a bug. It actually works
just fine with NOR flash devices.
Nicolas
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
@ 2000-12-05 1:54 Ian
2000-12-05 9:15 ` David Woodhouse
2000-12-05 14:50 ` Ronald G Minnich
0 siblings, 2 replies; 18+ messages in thread
From: Ian @ 2000-12-05 1:54 UTC (permalink / raw)
To: ollie; +Cc: mtd, linuxbios
I am a scumbag. I have just re-run it up as modules and redone my test, and the data *is*
sticking .. and *is* surviving reboots. I have no idea how it failed my previous test
(considering I'm using the same test scripts and configs).
I apologise profusely for this tripe .. and will retest my "inbuilt" scenario aswell ...
<whipping back with rosaries>
I will not post to public mailling lists after 18hours of programming ..
I will not post to public mailling lists after 18hours of programming ..
I will not post to public mailling lists after 18hours of programming ..
<etc ad nauseum>
If the inbuilt stuff isn't problematic, then I'll go back to Hamish's suggestions ..
'night.
----- Original Message -----
>From: "Ian" <Relativity@humanheuristic.com>
>To: <mtd@infradead.org>
>Subject: Re: Problems with r/w on mtdblock0
>Date: Tue, 05 Dec 2000 10:42:34 +1000
>
>
>
>
> I can also confirm that this problem exists when compiled as modules (and also with
> the #define DOC_SINGLE_DRIVER commented out).
>
>
> It isn't recent. Before this mornings attempts I was using a CVS from about 4-5days
> ago and it was in that bundle that I noticed it (I'm pretty sure it was pre the combo
> mods that Ollie did)
>
>
>
> ----- Original Message -----
> >From: "Ian" <Relativity@humanheuristic.com>
> >To: <mtd@infradead.org>
> >Subject: Problems with r/w on mtdblock0
> >Date: Tue, 05 Dec 2000 08:36:59 +1000
> >
> >
> >
> > Have I done something wrong to get this error?
> >
> > bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
> > end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> > dd: /dev/mtdblock0: Input/output error
> > 1+0 records in
> > 0+0 records out
> >
> > bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
> > end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> > /bin/dd: /dev/mtdblock0: Input/output error
> > 0+0 records in
> > 0+0 records out
> >
> >
> > I have no problems reading and writing to nftla on my DoC Millennium ... just
> > not the block device.
> >
> > NB: I'm trying to use the block device, because dd'ing to the first and second
> > 512bytes of the character device, while appearing successful, does not "stick".
> > A hexdump immediately after a dd shows no sign of the dd data.
> >
> > Note, too, that dd'ing to a non existent DoC yields a different error;
> > bash# /bin/dd if=/dev/mtdblock1 of=/dev/null bs=512 count=1
> > /bin/dd: /dev/mtdblock1: No such device
> >
> > brw-r--r-- 1 root root 31, 0 Dec 4 20:14 /dev/mtdblock0
> > brw-r--r-- 1 root root 31, 1 Dec 4 20:14 /dev/mtdblock1
> >
> >
> > Erm;
> > bash# cat /proc/mtd
> > mtd0: 00800000 "DiskOnChip Millennium"
> >
> > is that supposed to be the memory location for the DoC ?
> >
> >
> > Boot process (My DoC drivers are compiled internally to the kernel, *not* as modules)
> > Initializing MTD Layer
> > M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
> > DiskOnChip Millennium found at address 0xDC000
> > Flash chip found: Manufacture ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
> > 1 flash chips found. Total DiskOnChip size: 8 Mbytes
> >
> >
> >
> >
> > --
> > http://HumanHeuristic.com/
> > "Bringing people together in a world full of computers"
> >
> >
> >
> > To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
> >
>
> --
> http://HumanHeuristic.com/
> "Bringing people together in a world full of computers"
>
>
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
>
--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
2000-12-05 1:54 Ian
@ 2000-12-05 9:15 ` David Woodhouse
2000-12-05 14:50 ` Ronald G Minnich
1 sibling, 0 replies; 18+ messages in thread
From: David Woodhouse @ 2000-12-05 9:15 UTC (permalink / raw)
To: Ian; +Cc: ollie, mtd, linuxbios
Relativity@HumanHeuristic.com said:
> I am a scumbag. I have just re-run it up as modules and redone my
> test, and the data *is* sticking .. and *is* surviving reboots. I
> have no idea how it failed my previous test (considering I'm using
> the same test scripts and configs).
The way I normally program stuff into the DiskOnChip is with the
'doc_loadbios' program - which uses the character device, does MEMERASE
ioctls to make room for the image you tell it to load, then writes the
image.
--
dwmw2
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
2000-12-05 1:54 Ian
2000-12-05 9:15 ` David Woodhouse
@ 2000-12-05 14:50 ` Ronald G Minnich
2000-12-05 14:54 ` David Woodhouse
1 sibling, 1 reply; 18+ messages in thread
From: Ronald G Minnich @ 2000-12-05 14:50 UTC (permalink / raw)
To: Ian; +Cc: ollie, mtd, linuxbios
On Tue, 5 Dec 2000, Ian wrote:
> I have just re-run it up as modules and redone my test, and the data
> *is* sticking .. and *is* surviving reboots. I have no idea how it
> failed my previous test (considering I'm using the same test scripts
> and configs).
I've had this happen. Don't worry about it.
ron
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
2000-12-05 14:50 ` Ronald G Minnich
@ 2000-12-05 14:54 ` David Woodhouse
2000-12-05 15:34 ` Nicolas Pitre
0 siblings, 1 reply; 18+ messages in thread
From: David Woodhouse @ 2000-12-05 14:54 UTC (permalink / raw)
To: Ronald G Minnich; +Cc: Ian, ollie, mtd, linuxbios
rminnich@lanl.gov said:
> I've had this happen. Don't worry about it.
If you writing stuff to the mtdblock device and then reboot immediately,
you may be rebooting before the kernel thread actually completes the write.
I'm not sure if it makes you wait on close() or not. P'raps it should.
Using doc_loadbios on the chardevice should be reliable.
--
dwmw2
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
2000-12-05 14:54 ` David Woodhouse
@ 2000-12-05 15:34 ` Nicolas Pitre
2000-12-05 15:36 ` David Woodhouse
0 siblings, 1 reply; 18+ messages in thread
From: Nicolas Pitre @ 2000-12-05 15:34 UTC (permalink / raw)
To: David Woodhouse; +Cc: Ronald G Minnich, Ian, ollie, mtd, linuxbios
On Tue, 5 Dec 2000, David Woodhouse wrote:
>
> rminnich@lanl.gov said:
> > I've had this happen. Don't worry about it.
>
> If you writing stuff to the mtdblock device and then reboot immediately,
> you may be rebooting before the kernel thread actually completes the write.
> I'm not sure if it makes you wait on close() or not. P'raps it should.
It does.
Nicolas
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problems with r/w on mtdblock0
@ 2000-12-05 0:42 Ian
0 siblings, 0 replies; 18+ messages in thread
From: Ian @ 2000-12-05 0:42 UTC (permalink / raw)
To: mtd
I can also confirm that this problem exists when compiled as modules (and also with
the #define DOC_SINGLE_DRIVER commented out).
It isn't recent. Before this mornings attempts I was using a CVS from about 4-5days
ago and it was in that bundle that I noticed it (I'm pretty sure it was pre the combo
mods that Ollie did)
----- Original Message -----
>From: "Ian" <Relativity@humanheuristic.com>
>To: <mtd@infradead.org>
>Subject: Problems with r/w on mtdblock0
>Date: Tue, 05 Dec 2000 08:36:59 +1000
>
>
>
> Have I done something wrong to get this error?
>
> bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
> end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> dd: /dev/mtdblock0: Input/output error
> 1+0 records in
> 0+0 records out
>
> bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
> end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> /bin/dd: /dev/mtdblock0: Input/output error
> 0+0 records in
> 0+0 records out
>
>
> I have no problems reading and writing to nftla on my DoC Millennium ... just
> not the block device.
>
> NB: I'm trying to use the block device, because dd'ing to the first and second
> 512bytes of the character device, while appearing successful, does not "stick".
> A hexdump immediately after a dd shows no sign of the dd data.
>
> Note, too, that dd'ing to a non existent DoC yields a different error;
> bash# /bin/dd if=/dev/mtdblock1 of=/dev/null bs=512 count=1
> /bin/dd: /dev/mtdblock1: No such device
>
> brw-r--r-- 1 root root 31, 0 Dec 4 20:14 /dev/mtdblock0
> brw-r--r-- 1 root root 31, 1 Dec 4 20:14 /dev/mtdblock1
>
>
> Erm;
> bash# cat /proc/mtd
> mtd0: 00800000 "DiskOnChip Millennium"
>
> is that supposed to be the memory location for the DoC ?
>
>
> Boot process (My DoC drivers are compiled internally to the kernel, *not* as modules)
> Initializing MTD Layer
> M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
> DiskOnChip Millennium found at address 0xDC000
> Flash chip found: Manufacture ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
> 1 flash chips found. Total DiskOnChip size: 8 Mbytes
>
>
>
>
> --
> http://HumanHeuristic.com/
> "Bringing people together in a world full of computers"
>
>
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
>
--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
* Problems with r/w on mtdblock0
@ 2000-12-04 22:36 Ian
2000-12-05 1:10 ` Ollie Lho
0 siblings, 1 reply; 18+ messages in thread
From: Ian @ 2000-12-04 22:36 UTC (permalink / raw)
To: mtd
Have I done something wrong to get this error?
bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
end_request: I/O error, dev 1f:00 (mtdblock), sector 0
dd: /dev/mtdblock0: Input/output error
1+0 records in
0+0 records out
bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
end_request: I/O error, dev 1f:00 (mtdblock), sector 0
/bin/dd: /dev/mtdblock0: Input/output error
0+0 records in
0+0 records out
I have no problems reading and writing to nftla on my DoC Millennium ... just
not the block device.
NB: I'm trying to use the block device, because dd'ing to the first and second
512bytes of the character device, while appearing successful, does not "stick".
A hexdump immediately after a dd shows no sign of the dd data.
Note, too, that dd'ing to a non existent DoC yields a different error;
bash# /bin/dd if=/dev/mtdblock1 of=/dev/null bs=512 count=1
/bin/dd: /dev/mtdblock1: No such device
brw-r--r-- 1 root root 31, 0 Dec 4 20:14 /dev/mtdblock0
brw-r--r-- 1 root root 31, 1 Dec 4 20:14 /dev/mtdblock1
Erm;
bash# cat /proc/mtd
mtd0: 00800000 "DiskOnChip Millennium"
is that supposed to be the memory location for the DoC ?
Boot process (My DoC drivers are compiled internally to the kernel, *not* as modules)
Initializing MTD Layer
M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
DiskOnChip Millennium found at address 0xDC000
Flash chip found: Manufacture ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
1 flash chips found. Total DiskOnChip size: 8 Mbytes
--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Problems with r/w on mtdblock0
2000-12-04 22:36 Ian
@ 2000-12-05 1:10 ` Ollie Lho
0 siblings, 0 replies; 18+ messages in thread
From: Ollie Lho @ 2000-12-05 1:10 UTC (permalink / raw)
To: Ian; +Cc: mtd
Ian wrote:
>
> Have I done something wrong to get this error?
>
> bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
> end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> dd: /dev/mtdblock0: Input/output error
> 1+0 records in
> 0+0 records out
>
> bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
> end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> /bin/dd: /dev/mtdblock0: Input/output error
> 0+0 records in
> 0+0 records out
>
> I have no problems reading and writing to nftla on my DoC Millennium ... just
> not the block device.
>
Ian,
The /dev/mtdblockN device the the "block device" node for MTD devices.
In the DoC case, it can only read/write data in 8KB block (the erase size).
You can not read/write 512B on itm it will get "cached" by the driver. If
you are playing with the IPL stuff, WRITE TO /dev/mtd0.
Ollie
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2000-12-06 4:33 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-12-06 2:45 Problems with r/w on mtdblock0 Ian
-- strict thread matches above, loose matches on Subject: below --
2000-12-06 4:33 Ian
2000-12-06 3:07 Ian
2000-12-06 2:28 Ian
2000-12-06 2:52 ` Nicolas Pitre
2000-12-06 0:19 Ian
2000-12-06 0:41 ` Ollie Lho
2000-12-06 2:18 ` Nicolas Pitre
2000-12-05 1:54 Ian
2000-12-05 9:15 ` David Woodhouse
2000-12-05 14:50 ` Ronald G Minnich
2000-12-05 14:54 ` David Woodhouse
2000-12-05 15:34 ` Nicolas Pitre
2000-12-05 15:36 ` David Woodhouse
2000-12-05 19:38 ` Ronald G Minnich
2000-12-05 0:42 Ian
2000-12-04 22:36 Ian
2000-12-05 1:10 ` Ollie Lho
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox