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

[Peter Crosthwaite]

On Sat, Jul 21, 2012 at 12:56 AM, jagan <address@hidden> 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 <address@hidden>
> 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
>> <address@hidden> wrote:
>>>
>>> On Thu, Jul 19, 2012 at 7:16 PM, jagan <address@hidden> 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
>>> > <address@hidden> wrote:
>>> >>
>>> >> On Thu, Jul 19, 2012 at 5:03 AM,  <address@hidden> wrote:
>>> >> > From: Jagan <address@hidden>
>>> >> >
>>> >> > 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 <address@hidden>
>>> >> > ---
>>> >> >  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
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>>
>