[ECOS] Flash V2 with 2 flash chips on board !
Manfred Gruber
m.gruber@tirol.com
Tue Nov 22 08:14:00 GMT 2005
Hi !
thanks a lot for your answer.
Am Sonntag, 20. November 2005 23:14 schrieben Sie:
> Setting up the MMU tables is the responsibility of the platform HAL.
> No other package will know exactly what chips are present on the
> target hardware. The first flash chip can always be mapped to an
> appropriate virtual address. For the second one, you could map it into
> the virtual address space irrespective of whether or not it is
> present. Alternatively you can do run-time detection and only map it
> if present. If the first flash chip is variable size and the second
> must appear contiguous then run-time mapping is unavoidable.
So, as I understand correct,for example I have two flash chips on my device
2x32MB. The first one is physical on 0xf0000000 and the second one is on
0x10000000. I have to map them to a virtual address like that:
first chip virtual 0xf0000000
0xf2000000 -- first 32mb
second chip 0xf2000000
0xf4000000 -- second 32mb
would this be correct ?
the second chip only would be maped if it is present, and my second
CYG_FLASH_DRIVER() function would so a custom init function to detect if a
chip is on 0xf2000000?
will this chips then appear as one flash device in redboot? so that later
linux will detect the redboot partitions, because of concate them in linux ?
> Once the flash chip(s) have been mapped into the address space you
> need to instantiate device structures for each one. The details of
> this will depend on the family of flash chips you are using. For the
> the AM29xxxxx V2 driver you need two CYG_FLASH_DRIVER() invocations,
> one for each chip. For the first chip you would probably want to use
> the CFI init function, to allow for variable-sized devices.
> Alternatively if the platform HAL has already detected the block
> layout it can fill in the appropriate fields. For the second chip you
> would want a custom init function which checks whether or not the
> platform HAL detected the chip, and then possibly chain to the CFI
> init function to fill in the block details.
OK, thanks now I know my error, I had 2 CYG_FLASH_DRIVER() invocations, which
both used CFI init functions and the second chip was not there, so redboot
does not boot. I will change the second CYG_FLASH_DRIVER() to a custom init
function and when the chip is is there i will use CFI init.
> One caution: I have had reports that RedBoot still has trouble coping
> with multiple flash chips. I have not investigated further.
i will investigate when i have my hardware with 2 flash chips.
thanks regards manfred
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list