qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v13 13/19] i.MX: KZM now uses the standalone i.M


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v13 13/19] i.MX: KZM now uses the standalone i.MX31 SOC support
Date: Mon, 10 Aug 2015 17:23:12 +0100

On 10 August 2015 at 17:15, Jean-Christophe DUBOIS <address@hidden> wrote:
> Le 07/08/2015 15:45, Peter Maydell a écrit :
>
> On 16 July 2015 at 22:21, Jean-Christophe Dubois <address@hidden>
> wrote:

>
> memory_region_allocate_system_memory() needs to be called once and
> only once by a board init. You're going to end up calling it twice here.
>
>
> Actually, I may be calling it up 3 time because there is also an internal
> (16KB) memory range that is allocated during the SOC init (fsl-imx31.c
> file).

Small blocks of stuff like 16KB are not the "main lump of RAM", so
should not be initialized with memory_region_allocate_system_memory().
Use memory_region_init_ram() followed by vmstate_register_ram_global()
for that sort of small RAM region.

> Now as my memory (the 3 memory banks) is  (partially) discontiguous how am I
> suppose to init all of it in one call?

Your main RAM will be all contiguous, the only reason it would be
discontiguous is if you were trying to model 128MB + 128MB,
which you can't specify anyway with a single 'this much memory' ram_size
argument.

> And if memory_region_allocate_system_memory() should really be called only
> once, why is it not enforced in this function? After all,
> memory_region_allocate_system_memory() only calls memory_region_init_ram()
> and vmstate_register_ram_global() in one step ...

It does a lot more complicated things than that, potentially.
I agree that it ought to assert the once-and-only-once property;
in fact I suggested on IRC last week that that would be a good
plan, since it's an easy mistake to make.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]