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.mitsya...@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.crosthwa...@petalogix.com> wrote:
>
>> On Thu, Jul 19, 2012 at 7:16 PM, jagan <402ja...@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.crosthwa...@petalogix.com> wrote:
>> >>
>> >> On Thu, Jul 19, 2012 at 5:03 AM, <402ja...@gmail.com> wrote:
>> >> > From: Jagan <402ja...@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 <402ja...@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
>> >> >
>> >> >
>> >
>> >
>>
>
>
>
