[ECOS] Re: Flash device interface

[ECOS] Re: Flash device interface

[Savin Zlobec]

Roland Caßebohm wrote:

>On Dienstag, 4. November 2003 16:57, Roland Caßebohm wrote:
>> Hi again,
>>
>> I'm just trying to use the flash device interface (/dev/flash1)
>> for accessing flash, but if I write to flash with write() I get
>> an "I/O error".
>>
>> The problem seems to be, that flashiodev_bwrite() does not erase
>> the region before programming it. I also think about a possibility
>> to write regions, which are not block aligned.
>>
>> Maybe the function calls flash_erase() and flash_program() block
>> by block and for the first and the last block which are not block
>> aligned, it first makes a copy of the current flash content,
>> replaces the to be written data in this copy and programs the copy
>> back.
>>
>> I also want to use flash_read() instead of directly read the flash.
>> Then it should work with flashes with indirect access too.
>>
>> Any suggestions?
>
>In the attached patch I have made such a change, but as I have written
>in an other mail the devfs which is used by this layer doesn't support
>lseek() and fstat(). That's why it is even with this changes not
>possible to use a flash image like a file.
>
>But at least erasing the flash before writing it should be done,
>else the flash content would be corrupted.
>
[ ... ]

I don't think this is a way to go if you want to have byte access to 
your flash.
You have a read/modify/erase/write cycle if your data is not block 
alligned for every write -
a lot of work if you want to change just a byte of two, not to mention 
the limited amount of
times you can do that with one flash chip.

Using my block library should give you much better results.
It caches the blocks for you and writes only when block gets thrown out 
of cache or you
request it. Beside that you have byte access and block access functions 
and the cache size and
block size are configurable. You can write a simple filesystem on top of 
that wich suits your needs,
and this is really simple if all what you need is file like access to 
your flash region.

savin




-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: Flash device interface

[Roland Caßebohm]

On Donnerstag, 6. November 2003 16:10, Savin Zlobec wrote:
> Roland Caßebohm wrote:
> >On Dienstag, 4. November 2003 16:57, Roland Caßebohm wrote:
> >> Hi again,
> >>
> >> I'm just trying to use the flash device interface (/dev/flash1)
> >> for accessing flash, but if I write to flash with write() I get
> >> an "I/O error".
> >>
> >> The problem seems to be, that flashiodev_bwrite() does not erase
> >> the region before programming it. I also think about a possibility
> >> to write regions, which are not block aligned.
> >>
> >> Maybe the function calls flash_erase() and flash_program() block
> >> by block and for the first and the last block which are not block
> >> aligned, it first makes a copy of the current flash content,
> >> replaces the to be written data in this copy and programs the copy
> >> back.
> >>
> >> I also want to use flash_read() instead of directly read the flash.
> >> Then it should work with flashes with indirect access too.
> >>
> >> Any suggestions?
> >
> >In the attached patch I have made such a change, but as I have written
> >in an other mail the devfs which is used by this layer doesn't support
> >lseek() and fstat(). That's why it is even with this changes not
> >possible to use a flash image like a file.
> >
> >But at least erasing the flash before writing it should be done,
> >else the flash content would be corrupted.
>
> [ ... ]
>
> I don't think this is a way to go if you want to have byte access to
> your flash.
> You have a read/modify/erase/write cycle if your data is not block
> alligned for every write -
> a lot of work if you want to change just a byte of two, not to mention
> the limited amount of
> times you can do that with one flash chip.
>
> Using my block library should give you much better results.
> It caches the blocks for you and writes only when block gets thrown out
> of cache or you
> request it. Beside that you have byte access and block access functions
> and the cache size and
> block size are configurable. You can write a simple filesystem on top of
> that wich suits your needs,
> and this is really simple if all what you need is file like access to
> your flash region.
>

This sounds very good, but I'm afraid I have no time anymore for this.
Maybe in the future I will go on.

But one thing still interests me, does anybody ever used the flash device
interface (flashiodev.c) with real flash? I think it just can't work, 
because in the write function the flash would not be erased before
programming.

Thanks for your suggestion,
Roland
-- 

___________________________________________________

VS Vision Systems GmbH, Industrial Image Processing
Dipl.-Ing. Roland Caßebohm
Aspelohe 27A, D-22848 Norderstedt, Germany
http://www.visionsystems.de
___________________________________________________


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Re: Flash device interface

[Roland Caßebohm]

On Mittwoch, 5. November 2003 12:16, Savin Zlobec wrote:
> Roland Caßebohm wrote:
> >Hi again,
> >
> >I'm just trying to use the flash device interface (/dev/flash1)
> >for accessing flash, but if I write to flash with write() I get
> >an "I/O error".
> >
> >The problem seems to be, that flashiodev_bwrite() does not erase
> >the region before programming it. I also think about a possibility
> >to write regions, which are not block aligned.
> >
> >Maybe the function calls flash_erase() and flash_program() block
> >by block and for the first and the last block which are not block
> >aligned, it first makes a copy of the current flash content,
> >replaces the to be written data in this copy and programs the copy
> >back.
> >
> >I also want to use flash_read() instead of directly read the flash.
> >Then it should work with flashes with indirect access too.
> >
> > Any suggestions?
>
> Hi,
>
> you can take a look at the work I've done on FAT fs. It includes
> a block cache and access library and a simple disk drivers framework.
> It was written to support CF cards, but the block access is pretty generic.
>

Hi,

I have made a quick look at your code and it looks realy good, but I
don't know how to use it for my case.

What I wanted is that RedBoot manages the flash fis the fis commands.
But then I need a possibility to access the flash from an application
without corrupt the fis images.

With the "Flash device interface" I thought could at least have access
to one fis image. But now I have noticed, that the dev filesystem
don't support things like lseek() and fstat(), which I need to use
a fis image like a file.

Maybe it would be good to implement a "fis filesystem", which then
gives access to all fis images. If this includes the RedBoot image
itself, it should be possible to write application which could
update it self and RedBoot.

Roland



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] Re: Flash device interface

[Savin Zlobec]

Roland Caßebohm wrote:

>Hi again,
>
>I'm just trying to use the flash device interface (/dev/flash1) 
>for accessing flash, but if I write to flash with write() I get
>an "I/O error".
>
>The problem seems to be, that flashiodev_bwrite() does not erase
>the region before programming it. I also think about a possibility
>to write regions, which are not block aligned.
>
>Maybe the function calls flash_erase() and flash_program() block
>by block and for the first and the last block which are not block
>aligned, it first makes a copy of the current flash content,
>replaces the to be written data in this copy and programs the copy
>back.
>
>I also want to use flash_read() instead of directly read the flash.
>Then it should work with flashes with indirect access too.
>
> Any suggestions?

Hi,

you can take a look at the work I've done on FAT fs. It includes
a block cache and access library and a simple disk drivers framework.
It was written to support CF cards, but the block access is pretty generic.

savin


____________________
http://www.email.si/

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss