Re: Flashdriver for TC1796

[Andrew Lunn <andrew at lunn dot ch>]

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