[Qemu-devel] [PATCH 0/2] vexpress-a9: NOR flash support

[Qemu-devel] [PATCH 0/2] vexpress-a9: NOR flash support

[402jagan]

From: Jagan <402jagan@gmail.com>

These patches are added a support for NOR flash on vexpress-a9
both in Bank #1 and Bank #2.
Well tested on u-boot stable tree with Linux.

Jagan (2):
  vexpress: Add NOR0 Flash support
  vexpress: Add NOR1 Flash support

 hw/vexpress.c |   27 +++++++++++++++++++++++++--
 1 files changed, 25 insertions(+), 2 deletions(-)

[Qemu-devel] [PATCH 1/2] vexpress: Add NOR0 Flash support

[402jagan]

From: Jagan <402jagan@gmail.com>

This patch adds support for NOR0 flash (Bank #1) 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 |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/hw/vexpress.c b/hw/vexpress.c
index 8072c5a..2e889a8 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@ -29,6 +29,11 @@
 #include "sysemu.h"
 #include "boards.h"
 #include "exec-memory.h"
+#include "blockdev.h"
+#include "flash.h"
+
+#define VEXPRESS_FLASH_SIZE (64 * 1024 * 1024)
+#define VEXPRESS_FLASH_SECT_SIZE (256 * 1024)
 
 #define VEXPRESS_BOARD_ID 0x8e0
 
@@ -355,6 +360,7 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
     MemoryRegion *vram = g_new(MemoryRegion, 1);
     MemoryRegion *sram = g_new(MemoryRegion, 1);
     const target_phys_addr_t *map = daughterboard->motherboard_map;
+    DriveInfo *dinfo;
 
     daughterboard->init(daughterboard, ram_size, cpu_model, pic, &proc_id);
 
@@ -405,7 +411,16 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
 
     sysbus_create_simple("pl111", map[VE_CLCD], pic[14]);
 
-    /* VE_NORFLASH0: not modelled */
+    /* VE_NORFLASH0: */
+    dinfo = drive_get(IF_PFLASH, 0, 0);
+    if (!pflash_cfi01_register(map[VE_NORFLASH0], NULL, "vexpress.flash0",
+        VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
+        VEXPRESS_FLASH_SECT_SIZE,
+        VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE,
+        4, 0x0089, 0x0018, 0x0000, 0x0, 0)) {
+        fprintf(stderr, "qemu: Error registering flash0 memory.\n");
+    }
+
     /* VE_NORFLASH0ALIAS: not modelled */
     /* VE_NORFLASH1: not modelled */
 
-- 
1.7.0.4

[Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[402jagan]

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);
+    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

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[Peter Crosthwaite]

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

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[jagan]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3011 bytes --]

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[Igor Mitsyanko]

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

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[Peter Crosthwaite]

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

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[jagan]

[-- Attachment #1.1: Type: text/plain, Size: 3585 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 5088 bytes --]

[-- Attachment #2: vexpress-a9_flash.log --]
[-- Type: application/octet-stream, Size: 9428 bytes --]

Mr.J> /home/jagan/bin/qemu-system-arm -M vexpress-a9 -kernel u-boot -nographic


U-Boot 2012.04.01-00016-g8ae8bd9-dirty (Jul 20 2012 - 18:37:09)

DRAM:  128 MiB
WARNING: Caches not enabled
Flash: pflash_write: Unimplemented flash cmd sequence (offset 0000000000000000, wcycle 0x0 cmd 0x0 value 0xf0)
pflash_write: Unimplemented flash cmd sequence (offset 0000000000000000, wcycle 0x0 cmd 0x0 value 0xf0)
128 MiB
MMC:   MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   smc911x-0
Hit any key to stop autoboot:  0 
VExpress# flinfo

Bank # 1: CFI conformant flash (32 x 32)  Size: 64 MB in 256 Sectors
  Intel Extended command set, Manufacturer ID: 0x18, Device ID: 0x00
  Erase timeout: 16384 ms, write timeout: 3 ms
  Buffer write timeout: 3 ms, buffer size: 2048 bytes

  Sector Start Addresses:
  40000000   RO   40040000        40080000        400C0000        40100000      
  40140000        40180000        401C0000        40200000        40240000      
  40280000        402C0000        40300000        40340000        40380000      
  403C0000        40400000        40440000        40480000        404C0000      
  40500000        40540000        40580000        405C0000        40600000      
  40640000        40680000        406C0000        40700000        40740000      
  40780000        407C0000        40800000        40840000        40880000      
  408C0000        40900000        40940000        40980000        409C0000      
  40A00000        40A40000        40A80000        40AC0000        40B00000      
  40B40000        40B80000        40BC0000        40C00000        40C40000      
  40C80000        40CC0000        40D00000        40D40000        40D80000      
  40DC0000        40E00000        40E40000        40E80000        40EC0000      
  40F00000        40F40000        40F80000        40FC0000        41000000      
  41040000        41080000        410C0000        41100000        41140000      
  41180000        411C0000        41200000        41240000        41280000      
  412C0000        41300000        41340000        41380000        413C0000      
  41400000        41440000        41480000        414C0000        41500000      
  41540000        41580000        415C0000        41600000        41640000      
  41680000        416C0000        41700000        41740000        41780000      
  417C0000        41800000        41840000        41880000        418C0000      
  41900000        41940000        41980000        419C0000        41A00000      
  41A40000        41A80000        41AC0000        41B00000        41B40000      
  41B80000        41BC0000        41C00000        41C40000        41C80000      
  41CC0000        41D00000        41D40000        41D80000        41DC0000      
  41E00000        41E40000        41E80000        41EC0000        41F00000      
  41F40000        41F80000        41FC0000        42000000        42040000      
  42080000        420C0000        42100000        42140000        42180000      
  421C0000        42200000        42240000        42280000        422C0000      
  42300000        42340000        42380000        423C0000        42400000      
  42440000        42480000        424C0000        42500000        42540000      
  42580000        425C0000        42600000        42640000        42680000      
  426C0000        42700000        42740000        42780000        427C0000      
  42800000        42840000        42880000        428C0000        42900000      
  42940000        42980000        429C0000        42A00000        42A40000      
  42A80000        42AC0000        42B00000        42B40000        42B80000      
  42BC0000        42C00000        42C40000        42C80000        42CC0000      
  42D00000        42D40000        42D80000        42DC0000        42E00000      
  42E40000        42E80000        42EC0000        42F00000        42F40000      
  42F80000        42FC0000        43000000        43040000        43080000      
  430C0000        43100000        43140000        43180000        431C0000      
  43200000        43240000        43280000        432C0000        43300000      
  43340000        43380000        433C0000        43400000        43440000      
  43480000        434C0000        43500000        43540000        43580000      
  435C0000        43600000        43640000        43680000        436C0000      
  43700000        43740000        43780000        437C0000        43800000      
  43840000        43880000        438C0000        43900000        43940000      
  43980000        439C0000        43A00000        43A40000        43A80000      
  43AC0000        43B00000        43B40000        43B80000        43BC0000      
  43C00000        43C40000        43C80000        43CC0000        43D00000      
  43D40000        43D80000        43DC0000        43E00000        43E40000      
  43E80000        43EC0000        43F00000        43F40000        43F80000      
  43FC0000      

Bank # 2: CFI conformant flash (32 x 32)  Size: 64 MB in 256 Sectors
  Intel Extended command set, Manufacturer ID: 0x18, Device ID: 0x01
  Erase timeout: 16384 ms, write timeout: 3 ms
  Buffer write timeout: 3 ms, buffer size: 2048 bytes

  Sector Start Addresses:
  44000000        44040000        44080000        440C0000        44100000      
  44140000        44180000        441C0000        44200000        44240000      
  44280000        442C0000        44300000        44340000        44380000      
  443C0000        44400000        44440000        44480000        444C0000      
  44500000        44540000        44580000        445C0000        44600000      
  44640000        44680000        446C0000        44700000        44740000      
  44780000        447C0000        44800000        44840000        44880000      
  448C0000        44900000        44940000        44980000        449C0000      
  44A00000        44A40000        44A80000        44AC0000        44B00000      
  44B40000        44B80000        44BC0000        44C00000        44C40000      
  44C80000        44CC0000        44D00000        44D40000        44D80000      
  44DC0000        44E00000        44E40000        44E80000        44EC0000      
  44F00000        44F40000        44F80000        44FC0000        45000000      
  45040000        45080000        450C0000        45100000        45140000      
  45180000        451C0000        45200000        45240000        45280000      
  452C0000        45300000        45340000        45380000        453C0000      
  45400000        45440000        45480000        454C0000        45500000      
  45540000        45580000        455C0000        45600000        45640000      
  45680000        456C0000        45700000        45740000        45780000      
  457C0000        45800000        45840000        45880000        458C0000      
  45900000        45940000        45980000        459C0000        45A00000      
  45A40000        45A80000        45AC0000        45B00000        45B40000      
  45B80000        45BC0000        45C00000        45C40000        45C80000      
  45CC0000        45D00000        45D40000        45D80000        45DC0000      
  45E00000        45E40000        45E80000        45EC0000        45F00000      
  45F40000        45F80000        45FC0000        46000000        46040000      
  46080000        460C0000        46100000        46140000        46180000      
  461C0000        46200000        46240000        46280000        462C0000      
  46300000        46340000        46380000        463C0000        46400000      
  46440000        46480000        464C0000        46500000        46540000      
  46580000        465C0000        46600000        46640000        46680000      
  466C0000        46700000        46740000        46780000        467C0000      
  46800000        46840000        46880000        468C0000        46900000      
  46940000        46980000        469C0000        46A00000        46A40000      
  46A80000        46AC0000        46B00000        46B40000        46B80000      
  46BC0000        46C00000        46C40000        46C80000        46CC0000      
  46D00000        46D40000        46D80000        46DC0000        46E00000      
  46E40000        46E80000        46EC0000        46F00000        46F40000      
  46F80000        46FC0000        47000000        47040000        47080000      
  470C0000        47100000        47140000        47180000        471C0000      
  47200000        47240000        47280000        472C0000        47300000      
  47340000        47380000        473C0000        47400000        47440000      
  47480000        474C0000        47500000        47540000        47580000      
  475C0000        47600000        47640000        47680000        476C0000      
  47700000        47740000        47780000        477C0000        47800000      
  47840000        47880000        478C0000        47900000        47940000      
  47980000        479C0000        47A00000        47A40000        47A80000      
  47AC0000        47B00000        47B40000        47B80000        47BC0000      
  47C00000        47C40000        47C80000        47CC0000        47D00000      
  47D40000        47D80000        47DC0000        47E00000        47E40000      
  47E80000        47EC0000        47F00000        47F40000        47F80000   RO 
  47FC0000      
VExpress# 

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[jagan]

[-- Attachment #1: Type: text/plain, Size: 4512 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6524 bytes --]

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[Igor Mitsyanko]

[-- Attachment #1: Type: text/plain, Size: 4863 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 8713 bytes --]

Re: [Qemu-devel] [PATCH 1/2] vexpress: Add NOR0 Flash support

[Peter Maydell]

On 18 July 2012 20:03,  <402jagan@gmail.com> wrote:
> From: Jagan <402jagan@gmail.com>
>
> This patch adds support for NOR0 flash (Bank #1) on
> vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>
> Tested on stable u-boot version through Linux.

You might want to look at a previous attempt at this by
Liming Wang: http://patchwork.ozlabs.org/patch/147905/
and at the review comments I made on that patch.

> Signed-off-by: Jagan <402jagan@gmail.com>

The name in your Signed-off-by: line has to be your full
real name, not a pseudonym or abbreviation. (I appreciate
that some people's full real name really is only a single
name, but since that's the less common case I thought I
should mention this requirement.)

-- PMM

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[jagan]

[-- Attachment #1: Type: text/plain, Size: 5587 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 10592 bytes --]

Re: [Qemu-devel] [PATCH 1/2] vexpress: Add NOR0 Flash support

[jagan]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Was flash support on express is already there, I haven't seen this
on mainline (master)
that is the reason I worked this.

Should I send the patches again with changing full name at  Signed-off-by

Regards,
Jagan.

On Fri, Jul 20, 2012 at 8:11 PM, Peter Maydell <peter.maydell@linaro.org>wrote:

> On 18 July 2012 20:03,  <402jagan@gmail.com> wrote:
> > From: Jagan <402jagan@gmail.com>
> >
> > This patch adds support for NOR0 flash (Bank #1) on
> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
> >
> > Tested on stable u-boot version through Linux.
>
> You might want to look at a previous attempt at this by
> Liming Wang: http://patchwork.ozlabs.org/patch/147905/
> and at the review comments I made on that patch.
>
> > Signed-off-by: Jagan <402jagan@gmail.com>
>
> The name in your Signed-off-by: line has to be your full
> real name, not a pseudonym or abbreviation. (I appreciate
> that some people's full real name really is only a single
> name, but since that's the less common case I thought I
> should mention this requirement.)
>
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 1720 bytes --]

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[Peter Crosthwaite]

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