Hardware RO & delays [DOC2000]

Hardware RO & delays [DOC2000]

[Dvir Oren]

Two questions this time:

1.  Is there a way to tell the flash (DoC2000) to mark a certain part 
of it as read only?  I know I can mount a certain partition as read 
only, but can I protect it at a lower level?

2.  Does the driver block the system?  I'm experience delays in 
sending udp packets over ethernet for periods of 50-300 
miliseconds.  I have a function that is supposed to send every 
several miliseconds a packets, and when going over the logs, I 
once in a while see a packet that is delayed for several tens of 
miliseconds, which is not acceptable by me.  Any ideas?

David, does the driver block the system?




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

Re: Hardware RO & delays [DOC2000]

[Brendan J Simon]

Dvir Oren wrote:

> 2.  Does the driver block the system?  I'm experience delays in
> sending udp packets over ethernet for periods of 50-300
> miliseconds.  I have a function that is supposed to send every
> several miliseconds a packets, and when going over the logs, I
> once in a while see a packet that is delayed for several tens of
> miliseconds, which is not acceptable by me.  Any ideas?
>
> David, does the driver block the system?

Are you sure it is the DOC drivers ?  Could it be something else ?
Highly loaded ethernet network with lots of collisions which forces the
ethernet card to back off it's transmissions ?

If you are not using a Real Time Operating System (like RT-Linux or
KURT) then you are not guaranteed to have processes run with any
determinism.

Brendan Simon.




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

Re: Hardware RO & delays [DOC2000]

[Dvir Oren]

> Are you sure it is the DOC drivers ?  Could it be something else ?
> Highly loaded ethernet network with lots of collisions which forces the
> ethernet card to back off it's transmissions ?

No.  I'm not sure it's the flash.  However, these delays don't happen 
on a standard PC that doesn't have flash (of course, there are 
several hundred other differences), but it does occur on a "network 
computer" that has no hard disk and uses flash.

> If you are not using a Real Time Operating System (like RT-Linux or
> KURT) then you are not guaranteed to have processes run with any
> determinism.

The system doesn't really need to be real time, it can suffer small 
delays.  


---------
Dvir Oren <dvir@lucidvon.com>
Lucid VON Ltd. <http://www.lucidvon.com>
Twin Towers 2,     Suite 406,     P.O.Box 159
35 Jabotinsky street, Ramat-Gan 52511, ISRAEL
Tel:+972 3 6137214         Fax:+972 3 6137215


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

Re: Hardware RO & delays [DOC2000]

[David Woodhouse]

dviro@lucidvon.com said:
>  1.  Is there a way to tell the flash (DoC2000) to mark a certain part
>  of it as read only?  I know I can mount a certain partition as read
> only, but can I protect it at a lower level?

Not per partition, but per NFTL. Yes - if you modify nftl.c to register the 
blockdevice as readonly, then refuse to process any writes to that device, 
you'll be fine.

You can have more than one NFTL 'drive' on each DiskOnChip, arccording to my 
reading of the specifications - although I'm not sure if the firmware will see 
both of them. You might need to make sure the boot drive is the first one on 
the DiskOnChip, so that the BIOS sees it. 


> 2.  Does the driver block the system?  I'm experience delays in
> sending udp packets over ethernet for periods of 50-300  miliseconds.
> I have a function that is supposed to send every  several miliseconds
> a packets, and when going over the logs, I  once in a while see a
> packet that is delayed for several tens of  miliseconds, which is not
> acceptable by me.

Yes, it does all its flash access, even waiting for erases to finish, with 
interrupts disabled.

> Any ideas? 

Yes. I know exactly how I'm going to thread it, and lock the device / each 
chip etc. against multiple accesses. I just haven't done it yet.



--
dwmw2




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

Re: Hardware RO & delays [DOC2000]

[Dvir Oren]

> >  1.  Is there a way to tell the flash (DoC2000) to mark a certain part
> >  of it as read only?  I know I can mount a certain partition as read
> > only, but can I protect it at a lower level?

> Not per partition, but per NFTL. Yes - if you modify nftl.c to register the 
> blockdevice as readonly, then refuse to process any writes to that device, 
> you'll be fine.

What's the difference between per partition and per NFTL?  Do you 
mean that there should be /dev/nftla1 and /dev/nftlb1, as opposed 
to /dev/nftla1 and /dev/nftla2?

Is there a way to tell the flash chip itself not to touch certain areas?

> > 2.  Does the driver block the system?  I'm experience delays in

> Yes, it does all its flash access, even waiting for erases to finish, with 
> interrupts disabled.

Do you know if this is true for M-Systems' driver as well?

Are the interrupts disabled during read operations as well?  Could it 
be that the driver disables the interrupts even if the flash is not 
mounted?

How long does it take it to finish?


---------
Dvir Oren <dvir@lucidvon.com>
Lucid VON Ltd. <http://www.lucidvon.com>
Twin Towers 2,     Suite 406,     P.O.Box 159
35 Jabotinsky street, Ramat-Gan 52511, ISRAEL
Tel:+972 3 6137214         Fax:+972 3 6137215


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

Re: Hardware RO & delays [DOC2000]

[David Woodhouse]

dviro@lucidvon.com said:
> What's the difference between per partition and per NFTL?  Do you
> mean that there should be /dev/nftla1 and /dev/nftlb1, as opposed  to /
> dev/nftla1 and /dev/nftla2?

Yes. Of course you don't need more than one NFTL if you can have _all_ your 
filesystem read-only.

> Is there a way to tell the flash chip itself not to touch certain
> areas? 

Not really.


> > Yes, it does all its flash access, even waiting for erases to finish,
> > with interrupts disabled.

> Do you know if this is true for M-Systems' driver as well? 

I think it is.

> Are the interrupts disabled during read operations as well?  Could it
> be that the driver disables the interrupts even if the flash is not
> mounted?

During read, yes. When the flash isn't mounted, no.

> How long does it take it to finish? 

A week or so of working time, which I'm not going to get for a month or two. 
Are you volunteering?



--
dwmw2




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

i hope to write open source's firmware

[jyllyj]

hi,all
hi,David Woodhouse
yes ,I want to do it ,need to all of M_sys doc2000 document of spec and
specific.
can you email me?




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