Flash V2 with 2 flash chips on board !

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Flash V2 with 2 flash chips on board !

Manfred Gruber
Hi !

I have a problem on a custom board how to solve following issue on flash_v2
ecos branche.

we use ecos flash_v2 branche now for a while. works very good.

now i have an new board with 8MB/16MB Flash on it, the base address for the
flash is 0xf0000000.

now i want to add a second 16mb flash chip on 0x10000000. is there a solution
like in mtd to concate them or bring the chips dynamically in series ?

i have already the asm code for detecting the size to build my mmu-tables but
i think it would be not enough to bring the two chips in the address space in
series. Doese anyone have a solution for me how this should work. I want to
have the same configuration like in linux also to have in redboot.

in linux the chips are concated to one chip, in series. how do i do this in
redboot dynamically ?

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

Reply | Threaded
Open this post in threaded view
|

Re: Flash V2 with 2 flash chips on board !

Bart Veer
>>>>> "Manfred" == Manfred Gruber <[hidden email]> writes:

    Manfred> I have a problem on a custom board how to solve following
    Manfred> issue on flash_v2 ecos branche.

    Manfred> we use ecos flash_v2 branche now for a while. works very
    Manfred> good.

    Manfred> now i have an new board with 8MB/16MB Flash on it, the
    Manfred> base address for the flash is 0xf0000000.

    Manfred> now i want to add a second 16mb flash chip on 0x10000000.
    Manfred> is there a solution like in mtd to concate them or bring
    Manfred> the chips dynamically in series ?

    Manfred> i have already the asm code for detecting the size to
    Manfred> build my mmu-tables but i think it would be not enough to
    Manfred> bring the two chips in the address space in series. Doese
    Manfred> anyone have a solution for me how this should work. I
    Manfred> want to have the same configuration like in linux also to
    Manfred> have in redboot.

    Manfred> in linux the chips are concated to one chip, in series.
    Manfred> how do i do this in redboot dynamically ?

I am not sure I understand entirely what you are trying to achieve.

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.

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.

One caution: I have had reports that RedBoot still has trouble coping
with multiple flash chips. I have not investigated further.

Bart

--
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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

Reply | Threaded
Open this post in threaded view
|

Re: Flash V2 with 2 flash chips on board !

Manfred Gruber
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

Reply | Threaded
Open this post in threaded view
|

Re: Flash V2 with 2 flash chips on board !

Andrew Lunn-2
On Tue, Nov 22, 2005 at 09:18:28AM +0100, Manfred Gruber wrote:

> 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 ?

To Redboot they will still be two flash devices. But redboot will be
happy to store images in both and it should also be happy to have an
image which spans from one device to the second device. However i
don't think i tested this.

Are you using a jffs2 filesystem? I don't know how jffs2 will handle
spanning two devices, especially if the block sizes are different
between the two devices. This is something you will have to test.

        Andrew

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

Reply | Threaded
Open this post in threaded view
|

Re: Flash V2 with 2 flash chips on board !

Manfred Gruber
Hi !

Am Dienstag, 22. November 2005 09:47 schrieb Andrew Lunn:
> To Redboot they will still be two flash devices. But redboot will be
> happy to store images in both and it should also be happy to have an
> image which spans from one device to the second device. However i
> don't think i tested this.
> Are you using a jffs2 filesystem? I don't know how jffs2 will handle
> spanning two devices, especially if the block sizes are different
> between the two devices. This is something you will have to test.

Yes I want to use jffs2, but the two flash chips have the same block size, i
will contact mtd-guys if it will work. But concate support is in mtd, when
things run good jffs2 works with 2 concated flashs chips :-) hopefully

Redboot: I see that I have to test and to look if things could work as I want,
at the moment I only have a hardware with on flash chip. When I get the
hardware with two flash devices I come back and tell my experiences, thanks
for your explanations and help.

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

Reply | Threaded
Open this post in threaded view
|

Re: Flash V2 with 2 flash chips on board !

Bart Veer
In reply to this post by Manfred Gruber
>>>>> "Manfred" == Manfred Gruber <[hidden email]> writes:

    Manfred> Hi !
    Manfred> thanks a lot for your answer.

    Manfred> 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.

    Manfred> So, as I understand correct,for example I have two flash
    Manfred> chips on my device 2x32MB. The first one is physical on
    Manfred> 0xf0000000 and the second one is on 0x10000000. I have to
    Manfred> map them to a virtual address like that:

    Manfred> first chip virtual 0xf0000000
    Manfred> 0xf2000000 -- first 32mb
    Manfred> second chip 0xf2000000
    Manfred> 0xf4000000 -- second 32mb

    Manfred> would this be correct ?

That looks right. If the first chip is variable-sized, e.g. it may
only be 16MB, then things get a bit more complicated because you will
want to map the second chip (if present) to 0xf1000000 instead of
0xf2000000. That will affect both the MMU settings and the base
address in the CYG_FLASH_DRIVER() instantiation.

    Manfred> the second chip only would be maped if it is present, and
    Manfred> my second CYG_FLASH_DRIVER() function would so a custom
    Manfred> init function to detect if a chip is on 0xf2000000?

What should probably happen is that the platform HAL sets a global
variable to 0 if the second chip is missing, or to 0xf1000000 or
0xf2000000 if the second chip is present. The custom init function can
then just check that variable and update the device instance structure
as appropriate.

    Manfred> will this chips then appear as one flash device in
    Manfred> redboot? so that later linux will detect the redboot
    Manfred> partitions, because of concate them in linux ?

It will appear as two flash chips, but in theory RedBoot should cope.

    >> 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.

    Manfred> OK, thanks now I know my error, I had 2
    Manfred> CYG_FLASH_DRIVER() invocations, which both used CFI init
    Manfred> functions and the second chip was not there, so redboot
    Manfred> does not boot. I will change the second
    Manfred> CYG_FLASH_DRIVER() to a custom init function and when the
    Manfred> chip is is there i will use CFI init.

The CFI init for the second chip will have tried to poke and peek a
chip that did not exist. Exactly what happens then depends very much
on the hardware. If it fails silently then the CFI init function would
detect the absence of CFI information and mark the chip as absent. If
the hardware starts throwing exceptions then you'll end up with poorly
defined behaviour, especially early on in the init sequence, and
portable code like the AM29xxxxxV2 driver cannot really cope with
that. Instead the driver allows for a platform-specific init function
which can do the right thing.

    >> One caution: I have had reports that RedBoot still has trouble
    >> coping with multiple flash chips. I have not investigated
    >> further.

    Manfred> i will investigate when i have my hardware with 2 flash
    Manfred> chips.

There may be a simple workaround, but I'll let you investigate current
RedBoot behaviour first.

Bart

--
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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