From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA294-0002cW-Ne for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:43:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SA292-0001EY-3b for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:42:50 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:54220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA291-0001EM-Qg for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:42:48 -0400 Received: by pbcuo5 with SMTP id uo5so220755pbc.4 for ; Tue, 20 Mar 2012 09:42:45 -0700 (PDT) Date: Wed, 21 Mar 2012 00:41:34 +0800 From: walimis Message-ID: <20120320164134.GB5223@walimis-desktop> References: <1332255423-21090-1-git-send-email-walimisdev@gmail.com> <20120320160005.GA5223@walimis-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] hw/vexpress.c: Add NOR flash model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org On Tue, Mar 20, 2012 at 04:13:43PM +0000, Peter Maydell wrote: >On 20 March 2012 16:00, walimis wrote: >> On Tue, Mar 20, 2012 at 03:13:33PM +0000, Peter Maydell wrote: >>>On 20 March 2012 14:57, Liming Wang wrote: >>>> Vexpress motherboard has two 2x16 NOR flash, but pflash_cfi01 >>>> doesn't support interleaving, so here only models two 1x32 flash. >>>> Although it's not exactly modeled, it works fine for running linux. >>>> >>>> Signed-off-by: Liming Wang >>>> --- >>>>  hw/vexpress.c |   19 +++++++++++++++++-- >>>>  1 files changed, 17 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/hw/vexpress.c b/hw/vexpress.c >>>> index b9aafec..921b01b 100644 >>>> --- a/hw/vexpress.c >>>> +++ b/hw/vexpress.c >>>> @@ -29,9 +29,13 @@ >>>>  #include "sysemu.h" >>>>  #include "boards.h" >>>>  #include "exec-memory.h" >>>> +#include "flash.h" >>>> +#include "blockdev.h" >>>> >>>>  #define VEXPRESS_BOARD_ID 0x8e0 >>>> >>>> +#define VEXPRESS_FLASH_SIZE 0x04000000 >>>> + >>>>  static struct arm_boot_info vexpress_binfo; >>>> >>>>  /* Address maps for peripherals: >>>> @@ -355,6 +359,9 @@ 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 = NULL; >>>> +    uint32_t sector_len = 256 * 1024; >>>> +    int i = 0; >>>> >>>>     daughterboard->init(daughterboard, ram_size, cpu_model, pic, &proc_id); >>>> >>>> @@ -405,9 +412,17 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, >>>> >>>>     sysbus_create_simple("pl111", map[VE_CLCD], pic[14]); >>>> >>>> -    /* VE_NORFLASH0: not modelled */ >>>> +    for(i = 0; i < 2; i++) { >>>> +       dinfo = drive_get(IF_PFLASH, 0, i); >>>> +        if (dinfo) { >>>> +           pflash_cfi01_register(((i == 0) ? map[VE_NORFLASH0] : map[VE_NORFLASH1]), NULL, >>>> +                           ((i == 0) ? "vexpress.flash0" : "vexpress:flash1"), >>>> +                           VEXPRESS_FLASH_SIZE, dinfo->bdrv, sector_len, >>>> +                           VEXPRESS_FLASH_SIZE / sector_len, 4, >>>> +                           0, 0x89, 0x89, 0x19, 0); >>>> +       } >>>> +    } >>> >>>As it stands this will stick flash0 over the top of RAM at address >>>zero on the vexpress-a15, since there VE_NORFLASH0 is 0. I think >>>that was a mistake, and we should have it in line with the legacy >> Sorry, I don't notice the situation for vexpress-a15. It seems to be >> fixed to fit both vexpress-a9 and vexpress-a15. Unfortunately, I have >> no infomation about memory map for vexpress-a15. > >The docs are publicly available: >http://infocenter.arm.com/help/topic/com.arm.doc.dui0604a/ch03s02s01.html Great, thanks. > >As I say basically you just want to change the a15's value of >NORFLASH0 to 0x0800000 and delete all references to NORFLASH0ALIAS. OK, I agree that it's a good way to delete NORFLASH0ALIAS. > >>>memory map, ie NORFLASH0 at 0x0800000 (and drop NORFLASH0ALIAS). >>> >>>What's your use case for this? Do we need to/want to implement >>>the memory remapping so you can have flash at address 0 and >>>boot out of it? >> I don't want to boot from flash, but only to model flash to erase/mount >> on linux guest os. We know that on vexpress-a9 board, u-boot is loaded >> by the board's monitor, not by itself. > >Mmm, you'd need a boot monitor in the flash too. I have vague >plans to have a go at trying the UEFI for vexpress-a9 here... It's a good idea. I'm now also interested in using UEFI to boot vexpress-a9. BTW, do you know why I cant' see my post on the mailing list? Liming Wang > >-- PMM