Patchwork [2/2] vexpress: Add NOR1 Flash support

login
register
mail settings
Submitter 402jagan@gmail.com
Date July 18, 2012, 7:03 p.m.
Message ID <1342638220-3600-3-git-send-email-402jagan@gmail.com>
Download mbox | patch
Permalink /patch/171814/
State New
Headers show

Comments

402jagan@gmail.com - July 18, 2012, 7:03 p.m.
From: Jagan <402jagan@gmail.com>

This patch adds support for NOR1 flash (Bank #2) on
vexpress-a9 platform. It is 64MB CFI01 compliant flash.

Tested on stable u-boot version through Linux.

Signed-off-by: Jagan <402jagan@gmail.com>
---
 hw/vexpress.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)
Peter A. G. Crosthwaite - July 18, 2012, 11:57 p.m.
On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com> wrote:
> From: Jagan <402jagan@gmail.com>
>
> This patch adds support for NOR1 flash (Bank #2) on
> vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>
> Tested on stable u-boot version through Linux.
>
> Signed-off-by: Jagan <402jagan@gmail.com>
> ---
>  hw/vexpress.c |   10 +++++++++-
>  1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/hw/vexpress.c b/hw/vexpress.c
> index 2e889a8..b4262ed 100644
> --- a/hw/vexpress.c
> +++ b/hw/vexpress.c
> @@ -422,7 +422,15 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
>      }
>
>      /* VE_NORFLASH0ALIAS: not modelled */
> -    /* VE_NORFLASH1: not modelled */
> +    /* VE_NORFLASH1: */
> +    dinfo = drive_get(IF_PFLASH, 0, 0);

Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
are both going to back to the same file (one -pflash argument) and
share storage? Should this use drive_get_next() and you specify two
-pflash args, one for each device?

Regards
Peter

> +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL, "vexpress.flash1",
> +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
> +        VEXPRESS_FLASH_SECT_SIZE,
> +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
> +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
> +        fprintf(stderr, "qemu: Error registering flash1 memory.\n");
> +    }
>
>      sram_size = 0x2000000;
>      memory_region_init_ram(sram, "vexpress.sram", sram_size);
> --
> 1.7.0.4
>
>
402jagan@gmail.com - July 19, 2012, 9:16 a.m.
Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
As these flashes are two different banks with individual bases address, I
used the same.

Was there any block allocation problem with this..will you please elaborate.
I couldn't understand about drive_get_next(), I think function can
be useful single drive devices SD/MTD.

Please suggest your comments.

Regards,
Jagan.

On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite <
peter.crosthwaite@petalogix.com> wrote:

> On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com> wrote:
> > From: Jagan <402jagan@gmail.com>
> >
> > This patch adds support for NOR1 flash (Bank #2) on
> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
> >
> > Tested on stable u-boot version through Linux.
> >
> > Signed-off-by: Jagan <402jagan@gmail.com>
> > ---
> >  hw/vexpress.c |   10 +++++++++-
> >  1 files changed, 9 insertions(+), 1 deletions(-)
> >
> > diff --git a/hw/vexpress.c b/hw/vexpress.c
> > index 2e889a8..b4262ed 100644
> > --- a/hw/vexpress.c
> > +++ b/hw/vexpress.c
> > @@ -422,7 +422,15 @@ static void vexpress_common_init(const VEDBoardInfo
> *daughterboard,
> >      }
> >
> >      /* VE_NORFLASH0ALIAS: not modelled */
> > -    /* VE_NORFLASH1: not modelled */
> > +    /* VE_NORFLASH1: */
> > +    dinfo = drive_get(IF_PFLASH, 0, 0);
>
> Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
> are both going to back to the same file (one -pflash argument) and
> share storage? Should this use drive_get_next() and you specify two
> -pflash args, one for each device?
>
> Regards
> Peter
>
> > +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL,
> "vexpress.flash1",
> > +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
> > +        VEXPRESS_FLASH_SECT_SIZE,
> > +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
> > +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
> > +        fprintf(stderr, "qemu: Error registering flash1 memory.\n");
> > +    }
> >
> >      sram_size = 0x2000000;
> >      memory_region_init_ram(sram, "vexpress.sram", sram_size);
> > --
> > 1.7.0.4
> >
> >
>
Mitsyanko Igor - July 19, 2012, 6:49 p.m.
On 07/19/2012 01:16 PM, jagan wrote:
> Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
> As these flashes are two different banks with individual bases address,
> I used the same.
>
> Was there any block allocation problem with this..will you please elaborate.
> I couldn't understand about drive_get_next(), I think function can
> be useful single drive devices SD/MTD.
>
> Please suggest your comments.
>
> Regards,
> Jagan.
>

I'm not sure how it was possible for you to successfully test this 
patch, pflash_cfi01_register() calls bdrv_attach_dev_nofail() which 
abort()s when you pass an already attached drive to it.

> On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite
> <peter.crosthwaite@petalogix.com
> <mailto:peter.crosthwaite@petalogix.com>> wrote:
>
>     On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com
>     <mailto:402jagan@gmail.com>> wrote:
>      > From: Jagan <402jagan@gmail.com <mailto:402jagan@gmail.com>>
>      >
>      > This patch adds support for NOR1 flash (Bank #2) on
>      > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>      >
>      > Tested on stable u-boot version through Linux.
>      >
>      > Signed-off-by: Jagan <402jagan@gmail.com <mailto:402jagan@gmail.com>>
>      > ---
>      >  hw/vexpress.c |   10 +++++++++-
>      >  1 files changed, 9 insertions(+), 1 deletions(-)
>      >
>      > diff --git a/hw/vexpress.c b/hw/vexpress.c
>      > index 2e889a8..b4262ed 100644
>      > --- a/hw/vexpress.c
>      > +++ b/hw/vexpress.c
>      > @@ -422,7 +422,15 @@ static void vexpress_common_init(const
>     VEDBoardInfo *daughterboard,
>      >      }
>      >
>      >      /* VE_NORFLASH0ALIAS: not modelled */
>      > -    /* VE_NORFLASH1: not modelled */
>      > +    /* VE_NORFLASH1: */
>      > +    dinfo = drive_get(IF_PFLASH, 0, 0);
>
>     Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
>     are both going to back to the same file (one -pflash argument) and
>     share storage? Should this use drive_get_next() and you specify two
>     -pflash args, one for each device?
>
>     Regards
>     Peter
>
>      > +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL,
>     "vexpress.flash1",
>      > +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
>      > +        VEXPRESS_FLASH_SECT_SIZE,
>      > +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
>      > +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
>      > +        fprintf(stderr, "qemu: Error registering flash1 memory.\n");
>      > +    }
>      >
>      >      sram_size = 0x2000000;
>      >      memory_region_init_ram(sram, "vexpress.sram", sram_size);
>      > --
>      > 1.7.0.4
>      >
>      >
>
>
Peter A. G. Crosthwaite - July 20, 2012, 1:28 a.m.
On Thu, Jul 19, 2012 at 7:16 PM, jagan <402jagan@gmail.com> wrote:
> Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
> As these flashes are two different banks with individual bases address, I
> used the same.
>
> Was there any block allocation problem with this..will you please elaborate.
> I couldn't understand about drive_get_next(),

s/drive_get(IF_PFLASH, 0, 0) /drive_get_next(IF_PFLASH)/

This will mean you have two -fplash arguments on qemu cmd line your two flashes.

qemu-system-arm ... -pflash nor0.bin -pflash nor1.bin

Currently you back (or attempt to back) both flashes to the same bdrv
which means they share storage. The two flashes will corrupt each
others data.

Regards,
Peter

 I think function can be useful
> single drive devices SD/MTD.
>
> Please suggest your comments.
>
> Regards,
> Jagan.
>
> On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite
> <peter.crosthwaite@petalogix.com> wrote:
>>
>> On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com> wrote:
>> > From: Jagan <402jagan@gmail.com>
>> >
>> > This patch adds support for NOR1 flash (Bank #2) on
>> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>> >
>> > Tested on stable u-boot version through Linux.
>> >
>> > Signed-off-by: Jagan <402jagan@gmail.com>
>> > ---
>> >  hw/vexpress.c |   10 +++++++++-
>> >  1 files changed, 9 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/hw/vexpress.c b/hw/vexpress.c
>> > index 2e889a8..b4262ed 100644
>> > --- a/hw/vexpress.c
>> > +++ b/hw/vexpress.c
>> > @@ -422,7 +422,15 @@ static void vexpress_common_init(const VEDBoardInfo
>> > *daughterboard,
>> >      }
>> >
>> >      /* VE_NORFLASH0ALIAS: not modelled */
>> > -    /* VE_NORFLASH1: not modelled */
>> > +    /* VE_NORFLASH1: */
>> > +    dinfo = drive_get(IF_PFLASH, 0, 0);
>>
>> Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
>> are both going to back to the same file (one -pflash argument) and
>> share storage? Should this use drive_get_next() and you specify two
>> -pflash args, one for each device?
>>
>> Regards
>> Peter
>>
>> > +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL,
>> > "vexpress.flash1",
>> > +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
>> > +        VEXPRESS_FLASH_SECT_SIZE,
>> > +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
>> > +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
>> > +        fprintf(stderr, "qemu: Error registering flash1 memory.\n");
>> > +    }
>> >
>> >      sram_size = 0x2000000;
>> >      memory_region_init_ram(sram, "vexpress.sram", sram_size);
>> > --
>> > 1.7.0.4
>> >
>> >
>
>
402jagan@gmail.com - July 20, 2012, 1:30 p.m.
I think I understand the situation, like when I called
pflash_cfi01_register, it verifies BlockDriverState is < 0.
Was my understanding correct?

If ie so. I think I need to change  drive_get(IF_PFLASH, 0, 0)  to
drive_get_next(IF_PFLASH) on second flash access by
keeping  drive_get(IF_PFLASH, 0, 0
on first flash, correct?

But I am wondering why it's still detecting 2 Flashes with 128MB when I
tested through u-boot.
Even I was written Linux and Ramdisk on to flashes again read back and able
to boot it, Fine.

Please find the attachment for u-boot log.

I haven't tested -pflash argument through ./qemu-system-arm
because it again asking about kernel argument, do I need to test this also?

Regards,
Jagan.

On Fri, Jul 20, 2012 at 6:58 AM, Peter Crosthwaite <
peter.crosthwaite@petalogix.com> wrote:

> On Thu, Jul 19, 2012 at 7:16 PM, jagan <402jagan@gmail.com> wrote:
> > Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
> > As these flashes are two different banks with individual bases address, I
> > used the same.
> >
> > Was there any block allocation problem with this..will you please
> elaborate.
> > I couldn't understand about drive_get_next(),
>
> s/drive_get(IF_PFLASH, 0, 0) /drive_get_next(IF_PFLASH)/
>
> This will mean you have two -fplash arguments on qemu cmd line your two
> flashes.
>
> qemu-system-arm ... -pflash nor0.bin -pflash nor1.bin
>
> Currently you back (or attempt to back) both flashes to the same bdrv
> which means they share storage. The two flashes will corrupt each
> others data.
>
> Regards,
> Peter
>
>  I think function can be useful
> > single drive devices SD/MTD.
> >
> > Please suggest your comments.
> >
> > Regards,
> > Jagan.
> >
> > On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite
> > <peter.crosthwaite@petalogix.com> wrote:
> >>
> >> On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com> wrote:
> >> > From: Jagan <402jagan@gmail.com>
> >> >
> >> > This patch adds support for NOR1 flash (Bank #2) on
> >> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
> >> >
> >> > Tested on stable u-boot version through Linux.
> >> >
> >> > Signed-off-by: Jagan <402jagan@gmail.com>
> >> > ---
> >> >  hw/vexpress.c |   10 +++++++++-
> >> >  1 files changed, 9 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/hw/vexpress.c b/hw/vexpress.c
> >> > index 2e889a8..b4262ed 100644
> >> > --- a/hw/vexpress.c
> >> > +++ b/hw/vexpress.c
> >> > @@ -422,7 +422,15 @@ static void vexpress_common_init(const
> VEDBoardInfo
> >> > *daughterboard,
> >> >      }
> >> >
> >> >      /* VE_NORFLASH0ALIAS: not modelled */
> >> > -    /* VE_NORFLASH1: not modelled */
> >> > +    /* VE_NORFLASH1: */
> >> > +    dinfo = drive_get(IF_PFLASH, 0, 0);
> >>
> >> Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
> >> are both going to back to the same file (one -pflash argument) and
> >> share storage? Should this use drive_get_next() and you specify two
> >> -pflash args, one for each device?
> >>
> >> Regards
> >> Peter
> >>
> >> > +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL,
> >> > "vexpress.flash1",
> >> > +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
> >> > +        VEXPRESS_FLASH_SECT_SIZE,
> >> > +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
> >> > +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
> >> > +        fprintf(stderr, "qemu: Error registering flash1 memory.\n");
> >> > +    }
> >> >
> >> >      sram_size = 0x2000000;
> >> >      memory_region_init_ram(sram, "vexpress.sram", sram_size);
> >> > --
> >> > 1.7.0.4
> >> >
> >> >
> >
> >
>
402jagan@gmail.com - July 20, 2012, 2:12 p.m.
And one more point is when I tried  drive_get(IF_PFLASH, 0, 0)  and then
drive_get_next(IF_PFLASH) individually on second flash.
I didn't observe any issue on bdrv_attach_dev_nofail, as it seems to be
failed on second case if we re-access the flash.

Code snippet:
------------------
+ bdrv_attach_dev_nofail(pfl->bs, pfl);

/* TODO qdevified devices don't use this, remove when devices are qdevified
*/
void bdrv_attach_dev_nofail(BlockDriverState *bs, void *dev)
{
        printf ("%s\n", __func__);
    if (bdrv_attach_dev(bs, dev) < 0) {
        printf ("%s: ERROR\n", __func__);
        abort();
    }
}

In both the cases I couldn't get the ERROR print.

Correct me If I did any wrong debugging.

Regards,
Jagan.

On Fri, Jul 20, 2012 at 7:00 PM, jagan <402jagan@gmail.com> wrote:

> I think I understand the situation, like when I called
> pflash_cfi01_register, it verifies BlockDriverState is < 0.
> Was my understanding correct?
>
> If ie so. I think I need to change  drive_get(IF_PFLASH, 0, 0)  to
> drive_get_next(IF_PFLASH) on second flash access by
> keeping  drive_get(IF_PFLASH, 0, 0
> on first flash, correct?
>
> But I am wondering why it's still detecting 2 Flashes with 128MB when I
> tested through u-boot.
> Even I was written Linux and Ramdisk on to flashes again read back and
> able to boot it, Fine.
>
> Please find the attachment for u-boot log.
>
> I haven't tested -pflash argument through ./qemu-system-arm
> because it again asking about kernel argument, do I need to test this also?
>
> Regards,
> Jagan.
>
>
> On Fri, Jul 20, 2012 at 6:58 AM, Peter Crosthwaite <
> peter.crosthwaite@petalogix.com> wrote:
>
>> On Thu, Jul 19, 2012 at 7:16 PM, jagan <402jagan@gmail.com> wrote:
>> > Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
>> > As these flashes are two different banks with individual bases address,
>> I
>> > used the same.
>> >
>> > Was there any block allocation problem with this..will you please
>> elaborate.
>> > I couldn't understand about drive_get_next(),
>>
>> s/drive_get(IF_PFLASH, 0, 0) /drive_get_next(IF_PFLASH)/
>>
>> This will mean you have two -fplash arguments on qemu cmd line your two
>> flashes.
>>
>> qemu-system-arm ... -pflash nor0.bin -pflash nor1.bin
>>
>> Currently you back (or attempt to back) both flashes to the same bdrv
>> which means they share storage. The two flashes will corrupt each
>> others data.
>>
>> Regards,
>> Peter
>>
>>  I think function can be useful
>> > single drive devices SD/MTD.
>> >
>> > Please suggest your comments.
>> >
>> > Regards,
>> > Jagan.
>> >
>> > On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite
>> > <peter.crosthwaite@petalogix.com> wrote:
>> >>
>> >> On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com> wrote:
>> >> > From: Jagan <402jagan@gmail.com>
>> >> >
>> >> > This patch adds support for NOR1 flash (Bank #2) on
>> >> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>> >> >
>> >> > Tested on stable u-boot version through Linux.
>> >> >
>> >> > Signed-off-by: Jagan <402jagan@gmail.com>
>> >> > ---
>> >> >  hw/vexpress.c |   10 +++++++++-
>> >> >  1 files changed, 9 insertions(+), 1 deletions(-)
>> >> >
>> >> > diff --git a/hw/vexpress.c b/hw/vexpress.c
>> >> > index 2e889a8..b4262ed 100644
>> >> > --- a/hw/vexpress.c
>> >> > +++ b/hw/vexpress.c
>> >> > @@ -422,7 +422,15 @@ static void vexpress_common_init(const
>> VEDBoardInfo
>> >> > *daughterboard,
>> >> >      }
>> >> >
>> >> >      /* VE_NORFLASH0ALIAS: not modelled */
>> >> > -    /* VE_NORFLASH1: not modelled */
>> >> > +    /* VE_NORFLASH1: */
>> >> > +    dinfo = drive_get(IF_PFLASH, 0, 0);
>> >>
>> >> Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
>> >> are both going to back to the same file (one -pflash argument) and
>> >> share storage? Should this use drive_get_next() and you specify two
>> >> -pflash args, one for each device?
>> >>
>> >> Regards
>> >> Peter
>> >>
>> >> > +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL,
>> >> > "vexpress.flash1",
>> >> > +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
>> >> > +        VEXPRESS_FLASH_SECT_SIZE,
>> >> > +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
>> >> > +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
>> >> > +        fprintf(stderr, "qemu: Error registering flash1 memory.\n");
>> >> > +    }
>> >> >
>> >> >      sram_size = 0x2000000;
>> >> >      memory_region_init_ram(sram, "vexpress.sram", sram_size);
>> >> > --
>> >> > 1.7.0.4
>> >> >
>> >> >
>> >
>> >
>>
>
>
Mitsyanko Igor - July 20, 2012, 2:19 p.m.
On 07/20/2012 05:30 PM, jagan wrote:
> I think I understand the situation, like when I called 
> pflash_cfi01_register, it verifies BlockDriverState is < 0.
> Was my understanding correct?
>
> If ie so. I think I need to change drive_get(IF_PFLASH, 0, 0)  to 
> drive_get_next(IF_PFLASH) on second flash access by 
> keeping  drive_get(IF_PFLASH, 0, 0
> on first flash, correct?
>
> But I am wondering why it's still detecting 2 Flashes with 128MB when 
> I tested through u-boot.
> Even I was written Linux and Ramdisk on to flashes again read back and 
> able to boot it, Fine.
>
> Please find the attachment for u-boot log.
>
> I haven't tested -pflash argument through ./qemu-system-arm 
> because it again asking about kernel argument, do I need to test this 
> also?

Now I understand why QEMU didn't abort during your test, If you do not 
specify a -pflash argument then there is no backing drive for any of 
flash banks and they just behave as read-only RAM regions, and in that 
case it doesn't matter whether you used drive_get(IF_PFLASH, 0, 0) or 
drive_get_next(IF_PFLASH) or nothing at all. U-boot should detect both 
banks without any problem, but he wouldn't be able to write anything to 
them.
As Peter already said, you need to use drive_get_next(IF_PFLASH) for 
both flash banks initialization, or use drive_get(IF_PFLASH, 0, 0) for 
first and drive_get(IF_PFLASH, 0, 1) for second bank.

>
> Regards,
> Jagan.
>
> On Fri, Jul 20, 2012 at 6:58 AM, Peter Crosthwaite 
> <peter.crosthwaite@petalogix.com 
> <mailto:peter.crosthwaite@petalogix.com>> wrote:
>
>     On Thu, Jul 19, 2012 at 7:16 PM, jagan <402jagan@gmail.com
>     <mailto:402jagan@gmail.com>> wrote:
>     > Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
>     > As these flashes are two different banks with individual bases
>     address, I
>     > used the same.
>     >
>     > Was there any block allocation problem with this..will you
>     please elaborate.
>     > I couldn't understand about drive_get_next(),
>
>     s/drive_get(IF_PFLASH, 0, 0) /drive_get_next(IF_PFLASH)/
>
>     This will mean you have two -fplash arguments on qemu cmd line
>     your two flashes.
>
>     qemu-system-arm ... -pflash nor0.bin -pflash nor1.bin
>
>     Currently you back (or attempt to back) both flashes to the same bdrv
>     which means they share storage. The two flashes will corrupt each
>     others data.
>
>     Regards,
>     Peter
>
>      I think function can be useful
>     > single drive devices SD/MTD.
>     >
>     > Please suggest your comments.
>     >
>     > Regards,
>     > Jagan.
>     >
>     > On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite
>     > <peter.crosthwaite@petalogix.com
>     <mailto:peter.crosthwaite@petalogix.com>> wrote:
>     >>
>     >> On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com
>     <mailto:402jagan@gmail.com>> wrote:
>     >> > From: Jagan <402jagan@gmail.com <mailto:402jagan@gmail.com>>
>     >> >
>     >> > This patch adds support for NOR1 flash (Bank #2) on
>     >> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>     >> >
>     >> > Tested on stable u-boot version through Linux.
>     >> >
>     >> > Signed-off-by: Jagan <402jagan@gmail.com
>     <mailto:402jagan@gmail.com>>
>     >> > ---
>     >> >  hw/vexpress.c |   10 +++++++++-
>     >> >  1 files changed, 9 insertions(+), 1 deletions(-)
>     >> >
>     >> > diff --git a/hw/vexpress.c b/hw/vexpress.c
>     >> > index 2e889a8..b4262ed 100644
>     >> > --- a/hw/vexpress.c
>     >> > +++ b/hw/vexpress.c
>     >> > @@ -422,7 +422,15 @@ static void vexpress_common_init(const
>     VEDBoardInfo
>     >> > *daughterboard,
>     >> >      }
>     >> >
>     >> >      /* VE_NORFLASH0ALIAS: not modelled */
>     >> > -    /* VE_NORFLASH1: not modelled */
>     >> > +    /* VE_NORFLASH1: */
>     >> > +    dinfo = drive_get(IF_PFLASH, 0, 0);
>     >>
>     >> Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
>     >> are both going to back to the same file (one -pflash argument) and
>     >> share storage? Should this use drive_get_next() and you specify two
>     >> -pflash args, one for each device?
>     >>
>     >> Regards
>     >> Peter
>     >>
>     >> > +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL,
>     >> > "vexpress.flash1",
>     >> > +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
>     >> > +        VEXPRESS_FLASH_SECT_SIZE,
>     >> > +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
>     >> > +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
>     >> > +        fprintf(stderr, "qemu: Error registering flash1
>     memory.\n");
>     >> > +    }
>     >> >
>     >> >      sram_size = 0x2000000;
>     >> >      memory_region_init_ram(sram, "vexpress.sram", sram_size);
>     >> > --
>     >> > 1.7.0.4
>     >> >
>     >> >
>     >
>     >
>
>
402jagan@gmail.com - July 20, 2012, 2:56 p.m.
Thanks for your info, In fact I was thinking about to use
drive_get(IF_PFLASH, 0, 0) for first and drive_get(IF_PFLASH, 0, 1)  also.

But the point I was still uncover is even I was using  drive_get(IF_PFLASH,
0, 0)   on both the flashes, If I tested through u-boot
I was able to detect two flashes and able to write, read and erase....

here are my test procedure:
---------------------------------------
$ qemu-system-arm -M vexpress-a9 -net nic -net tap,ifname=tap0 -kernel
u-boot -nographic

/* writing kernel on to flash0, with 0x40040000 offset */
VExpress# tftp 0x60008000 uImage-vexp
VExpress# erase all
VExpress# cp.b 0x60008000 0x40040000 ${filesize}

/* writing ramdisk on to flash1, with 0x45440000 offset */
VExpress# tftp 0x60100000 ramdisk16M.img.gz
VExpress# cp.b 0x60100000 0x45440000 ${filesize}

/* Reading from flash0, flash1 and boot */
VExpress# cp 0x40040000 0x61000000 ${filesize}
VExpress# cp 0x45440000 0x60800000 ${filesize}
VExpress# bootm 0x61000000

Please let me know for any issue on my testing.let me know you want the
boot logs.

Regards,
Jagan.


On Fri, Jul 20, 2012 at 7:49 PM, Igor Mitsyanko <i.mitsyanko@samsung.com>wrote:

>  On 07/20/2012 05:30 PM, jagan wrote:
>
> I think I understand the situation, like when I called
> pflash_cfi01_register, it verifies BlockDriverState is < 0.
> Was my understanding correct?
>
>  If ie so. I think I need to change  drive_get(IF_PFLASH, 0, 0)  to
> drive_get_next(IF_PFLASH) on second flash access by
> keeping  drive_get(IF_PFLASH, 0, 0
> on first flash, correct?
>
>  But I am wondering why it's still detecting 2 Flashes with 128MB when I
> tested through u-boot.
> Even I was written Linux and Ramdisk on to flashes again read back and
> able to boot it, Fine.
>
>  Please find the attachment for u-boot log.
>
>  I haven't tested -pflash argument through ./qemu-system-arm
> because it again asking about kernel argument, do I need to test this also?
>
>
> Now I understand why QEMU didn't abort during your test, If you do not
> specify a -pflash argument then there is no backing drive for any of flash
> banks and they just behave as read-only RAM regions, and in that case it
> doesn't matter whether you used drive_get(IF_PFLASH, 0, 0) or
> drive_get_next(IF_PFLASH) or nothing at all. U-boot should detect both
> banks without any problem, but he wouldn't be able to write anything to
> them.
> As Peter already said, you need to use drive_get_next(IF_PFLASH) for both
> flash banks initialization, or use drive_get(IF_PFLASH, 0, 0) for first and
> drive_get(IF_PFLASH, 0, 1) for second bank.
>
>
>
>  Regards,
> Jagan.
>
> On Fri, Jul 20, 2012 at 6:58 AM, Peter Crosthwaite <
> peter.crosthwaite@petalogix.com> wrote:
>
>> On Thu, Jul 19, 2012 at 7:16 PM, jagan <402jagan@gmail.com> wrote:
>> > Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
>> > As these flashes are two different banks with individual bases address,
>> I
>> > used the same.
>> >
>> > Was there any block allocation problem with this..will you please
>> elaborate.
>> > I couldn't understand about drive_get_next(),
>>
>>  s/drive_get(IF_PFLASH, 0, 0) /drive_get_next(IF_PFLASH)/
>>
>> This will mean you have two -fplash arguments on qemu cmd line your two
>> flashes.
>>
>> qemu-system-arm ... -pflash nor0.bin -pflash nor1.bin
>>
>> Currently you back (or attempt to back) both flashes to the same bdrv
>> which means they share storage. The two flashes will corrupt each
>> others data.
>>
>> Regards,
>> Peter
>>
>>  I think function can be useful
>> > single drive devices SD/MTD.
>> >
>> > Please suggest your comments.
>> >
>> > Regards,
>> > Jagan.
>> >
>> > On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite
>> > <peter.crosthwaite@petalogix.com> wrote:
>> >>
>> >> On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com> wrote:
>> >> > From: Jagan <402jagan@gmail.com>
>> >> >
>> >> > This patch adds support for NOR1 flash (Bank #2) on
>> >> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>> >> >
>> >> > Tested on stable u-boot version through Linux.
>> >> >
>> >> > Signed-off-by: Jagan <402jagan@gmail.com>
>> >> > ---
>> >> >  hw/vexpress.c |   10 +++++++++-
>> >> >  1 files changed, 9 insertions(+), 1 deletions(-)
>> >> >
>> >> > diff --git a/hw/vexpress.c b/hw/vexpress.c
>> >> > index 2e889a8..b4262ed 100644
>> >> > --- a/hw/vexpress.c
>> >> > +++ b/hw/vexpress.c
>> >> > @@ -422,7 +422,15 @@ static void vexpress_common_init(const
>> VEDBoardInfo
>> >> > *daughterboard,
>> >> >      }
>> >> >
>> >> >      /* VE_NORFLASH0ALIAS: not modelled */
>> >> > -    /* VE_NORFLASH1: not modelled */
>> >> > +    /* VE_NORFLASH1: */
>> >> > +    dinfo = drive_get(IF_PFLASH, 0, 0);
>> >>
>> >> Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
>> >> are both going to back to the same file (one -pflash argument) and
>> >> share storage? Should this use drive_get_next() and you specify two
>> >> -pflash args, one for each device?
>> >>
>> >> Regards
>> >> Peter
>> >>
>> >> > +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL,
>> >> > "vexpress.flash1",
>> >> > +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
>> >> > +        VEXPRESS_FLASH_SECT_SIZE,
>> >> > +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
>> >> > +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
>> >> > +        fprintf(stderr, "qemu: Error registering flash1 memory.\n");
>> >> > +    }
>> >> >
>> >> >      sram_size = 0x2000000;
>> >> >      memory_region_init_ram(sram, "vexpress.sram", sram_size);
>> >> > --
>> >> > 1.7.0.4
>> >> >
>> >> >
>> >
>> >
>>
>
>
>
Peter A. G. Crosthwaite - July 23, 2012, 12:51 a.m.
On Sat, Jul 21, 2012 at 12:56 AM, jagan <402jagan@gmail.com> wrote:
> Thanks for your info, In fact I was thinking about to use
> drive_get(IF_PFLASH, 0, 0) for first and drive_get(IF_PFLASH, 0, 1)  also.
>
> But the point I was still uncover is even I was using  drive_get(IF_PFLASH,
> 0, 0)   on both the flashes, If I tested through u-boot
> I was able to detect two flashes and able to write, read and erase....
>

Yes that right. It will work, but not across boots.

> here are my test procedure:
> ---------------------------------------
> $ qemu-system-arm -M vexpress-a9 -net nic -net tap,ifname=tap0 -kernel

Here, you have no -pflash argument, so there in no bdrv storage file
for your pflash. It will work but any data you write will be lost when
you close QEMU.

> u-boot -nographic
>
> /* writing kernel on to flash0, with 0x40040000 offset */
> VExpress# tftp 0x60008000 uImage-vexp
> VExpress# erase all
> VExpress# cp.b 0x60008000 0x40040000 ${filesize}
>
> /* writing ramdisk on to flash1, with 0x45440000 offset */
> VExpress# tftp 0x60100000 ramdisk16M.img.gz
> VExpress# cp.b 0x60100000 0x45440000 ${filesize}
>
> /* Reading from flash0, flash1 and boot */
> VExpress# cp 0x40040000 0x61000000 ${filesize}
> VExpress# cp 0x45440000 0x60800000 ${filesize}
> VExpress# bootm 0x61000000
>
> Please let me know for any issue on my testing.let me know you want the boot
> logs.

This is fine, just make the suggested drive_get_next() change, as that
will allow you to keep your flash data from one qemu run to the next.

Heres a test sequence to illustrate what we are getting at:

1. make some binary files, nor1.bin, nor2.bin, with random/zero/one data
2. qemu-system-arm -M vexpress-a9 -net nic -net tap,ifname=tap0
-kernel -pflash ./nor0.bin -pflash ./nor1.bin ...
3. Get u-boot to write two different things to the two different flashes.
4. Close QEMU.
5. run QEMU again, same cmd line as step 2
6. get u-boot (or whatever) to read back contents both flashes.
7. verify data is the same as written in step 3.

Regards,
Peter

>
> Regards,
> Jagan.
>
>
> On Fri, Jul 20, 2012 at 7:49 PM, Igor Mitsyanko <i.mitsyanko@samsung.com>
> wrote:
>>
>> On 07/20/2012 05:30 PM, jagan wrote:
>>
>> I think I understand the situation, like when I called
>> pflash_cfi01_register, it verifies BlockDriverState is < 0.
>> Was my understanding correct?
>>
>> If ie so. I think I need to change  drive_get(IF_PFLASH, 0, 0)  to
>> drive_get_next(IF_PFLASH) on second flash access by keeping
>> drive_get(IF_PFLASH, 0, 0
>> on first flash, correct?
>>
>> But I am wondering why it's still detecting 2 Flashes with 128MB when I
>> tested through u-boot.
>> Even I was written Linux and Ramdisk on to flashes again read back and
>> able to boot it, Fine.
>>
>> Please find the attachment for u-boot log.
>>
>> I haven't tested -pflash argument through ./qemu-system-arm because it
>> again asking about kernel argument, do I need to test this also?
>>
>>
>> Now I understand why QEMU didn't abort during your test, If you do not
>> specify a -pflash argument then there is no backing drive for any of flash
>> banks and they just behave as read-only RAM regions, and in that case it
>> doesn't matter whether you used drive_get(IF_PFLASH, 0, 0) or
>> drive_get_next(IF_PFLASH) or nothing at all. U-boot should detect both banks
>> without any problem, but he wouldn't be able to write anything to them.
>> As Peter already said, you need to use drive_get_next(IF_PFLASH) for both
>> flash banks initialization, or use drive_get(IF_PFLASH, 0, 0) for first and
>> drive_get(IF_PFLASH, 0, 1) for second bank.
>>
>>
>>
>> Regards,
>> Jagan.
>>
>> On Fri, Jul 20, 2012 at 6:58 AM, Peter Crosthwaite
>> <peter.crosthwaite@petalogix.com> wrote:
>>>
>>> On Thu, Jul 19, 2012 at 7:16 PM, jagan <402jagan@gmail.com> wrote:
>>> > Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
>>> > As these flashes are two different banks with individual bases address,
>>> > I
>>> > used the same.
>>> >
>>> > Was there any block allocation problem with this..will you please
>>> > elaborate.
>>> > I couldn't understand about drive_get_next(),
>>>
>>> s/drive_get(IF_PFLASH, 0, 0) /drive_get_next(IF_PFLASH)/
>>>
>>> This will mean you have two -fplash arguments on qemu cmd line your two
>>> flashes.
>>>
>>> qemu-system-arm ... -pflash nor0.bin -pflash nor1.bin
>>>
>>> Currently you back (or attempt to back) both flashes to the same bdrv
>>> which means they share storage. The two flashes will corrupt each
>>> others data.
>>>
>>> Regards,
>>> Peter
>>>
>>>  I think function can be useful
>>> > single drive devices SD/MTD.
>>> >
>>> > Please suggest your comments.
>>> >
>>> > Regards,
>>> > Jagan.
>>> >
>>> > On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite
>>> > <peter.crosthwaite@petalogix.com> wrote:
>>> >>
>>> >> On Thu, Jul 19, 2012 at 5:03 AM,  <402jagan@gmail.com> wrote:
>>> >> > From: Jagan <402jagan@gmail.com>
>>> >> >
>>> >> > This patch adds support for NOR1 flash (Bank #2) on
>>> >> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>>> >> >
>>> >> > Tested on stable u-boot version through Linux.
>>> >> >
>>> >> > Signed-off-by: Jagan <402jagan@gmail.com>
>>> >> > ---
>>> >> >  hw/vexpress.c |   10 +++++++++-
>>> >> >  1 files changed, 9 insertions(+), 1 deletions(-)
>>> >> >
>>> >> > diff --git a/hw/vexpress.c b/hw/vexpress.c
>>> >> > index 2e889a8..b4262ed 100644
>>> >> > --- a/hw/vexpress.c
>>> >> > +++ b/hw/vexpress.c
>>> >> > @@ -422,7 +422,15 @@ static void vexpress_common_init(const
>>> >> > VEDBoardInfo
>>> >> > *daughterboard,
>>> >> >      }
>>> >> >
>>> >> >      /* VE_NORFLASH0ALIAS: not modelled */
>>> >> > -    /* VE_NORFLASH1: not modelled */
>>> >> > +    /* VE_NORFLASH1: */
>>> >> > +    dinfo = drive_get(IF_PFLASH, 0, 0);
>>> >>
>>> >> Both flashes use drive_get(IF_PFLASH, 0, 0). Doesnt this means they
>>> >> are both going to back to the same file (one -pflash argument) and
>>> >> share storage? Should this use drive_get_next() and you specify two
>>> >> -pflash args, one for each device?
>>> >>
>>> >> Regards
>>> >> Peter
>>> >>
>>> >> > +    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL,
>>> >> > "vexpress.flash1",
>>> >> > +        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
>>> >> > +        VEXPRESS_FLASH_SECT_SIZE,
>>> >> > +        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
>>> >> > +        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
>>> >> > +        fprintf(stderr, "qemu: Error registering flash1
>>> >> > memory.\n");
>>> >> > +    }
>>> >> >
>>> >> >      sram_size = 0x2000000;
>>> >> >      memory_region_init_ram(sram, "vexpress.sram", sram_size);
>>> >> > --
>>> >> > 1.7.0.4
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>>
>

Patch

diff --git a/hw/vexpress.c b/hw/vexpress.c
index 2e889a8..b4262ed 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@ -422,7 +422,15 @@  static void vexpress_common_init(const VEDBoardInfo *daughterboard,
     }
 
     /* VE_NORFLASH0ALIAS: not modelled */
-    /* VE_NORFLASH1: not modelled */
+    /* VE_NORFLASH1: */
+    dinfo = drive_get(IF_PFLASH, 0, 0);
+    if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL, "vexpress.flash1",
+        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
+        VEXPRESS_FLASH_SECT_SIZE,
+        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
+        4, 0x0089, 0x0018, 0x0000, 0x1, 0)) {
+        fprintf(stderr, "qemu: Error registering flash1 memory.\n");
+    }
 
     sram_size = 0x2000000;
     memory_region_init_ram(sram, "vexpress.sram", sram_size);