| Message ID | 1342638220-3600-3-git-send-email-402jagan@gmail.com |
|---|---|
| State | New |
| Headers | show |
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 > >
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 > > > > >
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 > > > > > >
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 >> > >> > > >
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 > >> > > >> > > > > > >
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
>> >> >
>> >> >
>> >
>> >
>>
>
>
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 > >> > > >> > > > > > > >
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
>> >> >
>> >> >
>> >
>> >
>>
>
>
>
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 >>> >> > >>> >> > >>> > >>> > >> >> >> >
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);