Re: Flashdriver for TC1796

Re: Flashdriver for TC1796

[Rudi Pfister]

Hello,

> So you want to do something like:
>
> fis write -b 0x00100000 -f 0x0020000 -l 0x1000
>
> ie write the contents of RAM 0x0010000, length 0x1000 to flash address
> 0x00200000. This does not need a buffer.

No, I want to do something like this:

load -r -f 0xa0000000 -m ymodem

I want to load a program directly into the flash memory via
a serial line.
For this operation Redboot uses the flash_load_write()-function,
which saves the block to a buffer in RAM.

Using the "fis write"-command doesn't solve my problem.
On the one hand I have to load the application into RAM
first, but I can't be sure that I have enough RAM for this.
And on the other hand I can only write data to the beginning 
of a block and the whole block will be erased. So even if I want
to write only a part of the block the whole old data in the block
will be deleted.

Thanks

	Rudi

Re: Flashdriver for TC1796

[Andrew Lunn]

On Tue, Nov 21, 2006 at 12:03:51PM +0100, Rudi Pfister wrote:
> Hello,
> 
> I don't want to use the Flash Image System ...
> 
> I want to write programcode to the flash memory of the TC1796.
> It should be possible to place the code anywhere in the flash,
> e.g. to the program counter start address so the board will start
> my application after a reset.

So you want to do something like:

fis write -b 0x00100000 -f 0x0020000 -l 0x1000

ie write the contents of RAM 0x0010000, length 0x1000 to flash address
0x00200000. This does not need a buffer.

> > The eCos design philosophy would be to use CDL.
> 
> Do you mean I should use an option to configure the size of the
> buffer and only use the blocks smaller or equal to the buffer
> size ?

Yes, and also an option to specify where in memory the block should be
placed, so you can put it into the external RAM if you want to.

        Andrew

P.S.

You mail server is broken somehow. The Reply-to: field is
Reply-To: 20061118203849.GC31982@lunn.ch
which is not going to work.

Re: Flashdriver for TC1796

[Rudi Pfister]

Hello,

I don't want to use the Flash Image System ...

I want to write programcode to the flash memory of the TC1796.
It should be possible to place the code anywhere in the flash,
e.g. to the program counter start address so the board will start
my application after a reset.

The only way to achieve this is to use the load-command with the
option -f <address> and for this operation Redboot uses the
buffer, or am I wrong ?

> The eCos design philosophy would be to use CDL.

Do you mean I should use an option to configure the size of the
buffer and only use the blocks smaller or equal to the buffer
size ?

Thanks !

	Rudi



> On Sat, Nov 18, 2006 at 04:06:45PM +0100, Rudi Pfister wrote:
> > Hello,
> >
> > I'm porting Redboot to the Tricore-architecture. In special to the
> > TC1796-variant on a Infineon-Triboard.
> >
> > The TC1796 has onchip 2 MByte of Flashmemory devided into several
> > blocks with sizes from 16 KByte up to 512 KByte.
> > The TC1796 has about 192 KByte RAM in total.
> > The Triboard has 1 MByte SRAM used by the TC1796 as external
> > Memory.
> >
> > I want to write a driver for the flash memory of the TC1796.
> >
> > If the Redboot wants to change data in the flash memory it stores
> > the block to which the data should be written to a buffer in RAM.
> > Then it changes the data in the buffer and writes it back to flash
> > memory. The size of the buffer has to be the same size as the
> > largest block in the flash memory.
> >
> > Here is my problem. The size of the buffer has to be 512 KByte, but
> > the TC1796 has less than 512 KByte in total, so there is no space to
> > create the Buffer an a TC1796.
> >
> > In my case I could use the RAM of the Triboard, which is large enough.
> > But then the the driver for the flash memory of the TC1796-variant would
> > depend on the properites of the Triboard-platform.
> > I could also use only a part of the flash of the TC1796. In special the
>
> blocks
>
> > with the size of 16 KBytes. In total I would then be able to use 128
> > Kbytes of Flashmemory, which would be enough for me.
> > But in my opinion both ways are very unsatisfying.
> >
> > Is there a better way to deal with this problem ?
> > And what is the best resolution in respect to the
> > eCos-design-philosophy ?
>
> The eCos design philosophy would be to use CDL.
>
> First off we should talk about the different uses Redboot makes of
> flash.
>
> There two configuration areas, FIS and CFG. These can be in separate
> blocks, or combined into one. Redboot keeps a working copy of these in
> RAM.
>
> The second usage of flash is to allow you to store application images
> in flash. This is the fis create command and fis load. They don't
> require a RAM copy of a flash block, you just need sufficient RAM to
> hold what ever you want move to/from flash.
>
> For FIS/CFG you want to use the smaller blocks. 16KBytes is big enough
> to hold the combined FIS/CFG.
>
> Once option is to let the flash driver report that the block size if
> 16KBytes. This will allow FIS/CFG to work optimally. However, if you
> ask FIS to find free space in the flash to place an image, it is going
> to give the wrong answer, because the block boundaries are not where
> it thinks they are. There is a danger you then put an image into the
> middle of a block, which results in the image before/after being
> corrupted when the block is erased. So long as you manually control
> the memory map, this can work.
>
> A second option is to add new code which allows you to control where
> the fis_work_block is stored. You HAL can then set this variable to
> somewhere in your external RAM.
>
>           Andrew

Re: Flashdriver for TC1796

[Andrew Lunn]

On Sat, Nov 18, 2006 at 04:06:45PM +0100, Rudi Pfister wrote:
> Hello,
> 
> I'm porting Redboot to the Tricore-architecture. In special to the
> TC1796-variant on a Infineon-Triboard.
> 
> The TC1796 has onchip 2 MByte of Flashmemory devided into several
> blocks with sizes from 16 KByte up to 512 KByte.
> The TC1796 has about 192 KByte RAM in total.
> The Triboard has 1 MByte SRAM used by the TC1796 as external
> Memory.
> 
> I want to write a driver for the flash memory of the TC1796.
> 
> If the Redboot wants to change data in the flash memory it stores
> the block to which the data should be written to a buffer in RAM.
> Then it changes the data in the buffer and writes it back to flash
> memory. The size of the buffer has to be the same size as the
> largest block in the flash memory.
> 
> Here is my problem. The size of the buffer has to be 512 KByte, but
> the TC1796 has less than 512 KByte in total, so there is no space to
> create the Buffer an a TC1796.
> 
> In my case I could use the RAM of the Triboard, which is large enough.
> But then the the driver for the flash memory of the TC1796-variant would
> depend on the properites of the Triboard-platform.
> I could also use only a part of the flash of the TC1796. In special the blocks
> with the size of 16 KBytes. In total I would then be able to use 128 Kbytes
> of Flashmemory, which would be enough for me.
> But in my opinion both ways are very unsatisfying.
> 
> Is there a better way to deal with this problem ?
> And what is the best resolution in respect to the
> eCos-design-philosophy ?

The eCos design philosophy would be to use CDL.

First off we should talk about the different uses Redboot makes of
flash.

There two configuration areas, FIS and CFG. These can be in separate
blocks, or combined into one. Redboot keeps a working copy of these in
RAM.

The second usage of flash is to allow you to store application images
in flash. This is the fis create command and fis load. They don't
require a RAM copy of a flash block, you just need sufficient RAM to
hold what ever you want move to/from flash.

For FIS/CFG you want to use the smaller blocks. 16KBytes is big enough
to hold the combined FIS/CFG.

Once option is to let the flash driver report that the block size if
16KBytes. This will allow FIS/CFG to work optimally. However, if you
ask FIS to find free space in the flash to place an image, it is going
to give the wrong answer, because the block boundaries are not where
it thinks they are. There is a danger you then put an image into the
middle of a block, which results in the image before/after being
corrupted when the block is erased. So long as you manually control
the memory map, this can work.

A second option is to add new code which allows you to control where
the fis_work_block is stored. You HAL can then set this variable to
somewhere in your external RAM. 

          Andrew

Flashdriver for TC1796

[Rudi Pfister]

Hello,

I'm porting Redboot to the Tricore-architecture. In special to the
TC1796-variant on a Infineon-Triboard.

The TC1796 has onchip 2 MByte of Flashmemory devided into several
blocks with sizes from 16 KByte up to 512 KByte.
The TC1796 has about 192 KByte RAM in total.
The Triboard has 1 MByte SRAM used by the TC1796 as external
Memory.

I want to write a driver for the flash memory of the TC1796.

If the Redboot wants to change data in the flash memory it stores
the block to which the data should be written to a buffer in RAM.
Then it changes the data in the buffer and writes it back to flash
memory. The size of the buffer has to be the same size as the
largest block in the flash memory.

Here is my problem. The size of the buffer has to be 512 KByte, but
the TC1796 has less than 512 KByte in total, so there is no space to
create the Buffer an a TC1796.

In my case I could use the RAM of the Triboard, which is large enough.
But then the the driver for the flash memory of the TC1796-variant would
depend on the properites of the Triboard-platform.
I could also use only a part of the flash of the TC1796. In special the blocks
with the size of 16 KBytes. In total I would then be able to use 128 Kbytes
of Flashmemory, which would be enough for me.
But in my opinion both ways are very unsatisfying.

Is there a better way to deal with this problem ?
And what is the best resolution in respect to the
eCos-design-philosophy ?

Thanks !


Rudi