[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] extensions to the -m memory option
From: |
Peter Crosthwaite |
Subject: |
Re: [Qemu-devel] [RFC] extensions to the -m memory option |
Date: |
Sat, 30 May 2015 02:55:56 -0700 |
On Fri, May 29, 2015 at 4:08 AM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 29/05/2015 00:11, Liviu Ionescu wrote:
>> for more flexibility, in the new Cortex-M implementation I'm working on, I
>> can overwrite the vendor defined MCU internal SRAM size by using:
>>
>> -m sizeK
>>
>> I'm trying to find a way to also overwrite the internal flash size and the
>> first idea I had was to extend the "-m" command like:
>>
>> -m sizeK,flash=sizeK
>>
>> would this be ok?
>>
>> for more readability I would prefer something like:
>>
>> --memory ram=sizeK,flash=sizeK
>>
>> any other suggestions?
>
> If the flash is persistent, it should be tied to either "-pflash" (NOR)
> or "-mtd" (NAND). Just using a different image then results in resizing
> the flash.
>
Does it? From what I can see the NAND model inits a specific part as
instructed by the board with a fixed size. As the part is self
identifying to the system via jedec code the guest is going to assume
this is a very specifically sized part regardless of what size block
image is really behind it. I think the same is true of NOR. I know
that SD cards do however change size to the guest the way you
describe.
Using -pflash or -mtd for persistance support is a good idea but I
dont think it works for this resizing problem in general. I think this
a property on the SoC layer. This flash seems to be heavily integrated
into the SoC and transparently has a memory mapped interface.
Regards,
Peter
> Paolo
>
- Re: [Qemu-devel] [RFC] extensions to the -m memory option, (continued)
Re: [Qemu-devel] [RFC] extensions to the -m memory option, Paolo Bonzini, 2015/05/29
Re: [Qemu-devel] [RFC] extensions to the -m memory option,
Peter Crosthwaite <=