All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Joel Stanley <joel@jms.id.au>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>, Andrew Jeffery <andrew@aj.id.au>,
	Jim Mussared <jim.mussared@gmail.com>,
	Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] arm: Add Nordic Semiconductor nRF51 SoC
Date: Thu, 3 May 2018 10:17:51 +0100	[thread overview]
Message-ID: <CAFEAcA_4EiWXdSNdbiEWO_Q2Sac7qzNduhyWVNwW-crc5=w_nA@mail.gmail.com> (raw)
In-Reply-To: <20180503090532.3113-2-joel@jms.id.au>

On 3 May 2018 at 10:05, Joel Stanley <joel@jms.id.au> wrote:
> The nRF51 is a Cortex-M0 microcontroller with an on-board radio module,
> plus other common ARM SoC peripherals.
>
>  http://infocenter.nordicsemi.com/pdf/nRF51_RM_v3.0.pdf
>
> This defines a basic model of the CPU and memory, with no peripherals
> implemented at this stage.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>

> +static void nrf51_soc_realize(DeviceState *dev_soc, Error **errp)
> +{
> +    NRF51State *s = NRF51_SOC(dev_soc);
> +    DeviceState *nvic;
> +    Error *err = NULL;
> +
> +    /* IO space */
> +    create_unimplemented_device("nrf51_soc.io", IOMEM_BASE, IOMEM_SIZE);
> +
> +    /* FICR */
> +    create_unimplemented_device("nrf51_soc.ficr", FICR_BASE, FICR_SIZE);
> +
> +    MemoryRegion *system_memory = get_system_memory();
> +    MemoryRegion *sram = g_new(MemoryRegion, 1);
> +    MemoryRegion *flash = g_new(MemoryRegion, 1);

An SoC object doesn't need to allocate memory for things like this:
it can just put them as struct fields in its state structure.

> +
> +    memory_region_init_ram_nomigrate(flash, NULL, "nrf51.flash", FLASH_SIZE,

You should pass in OBJECT(s) as your owner argument, not NULL.

> +            &err);
> +    if (err) {
> +        error_propagate(errp, err);
> +        return;
> +    }
> +
> +    vmstate_register_ram_global(flash);

Rather than using the _nomigrate init function and then registering
the ram by hand, if you use memory_region_init_ram() it will automatically
register the memory for migration for you.

> +    memory_region_set_readonly(flash, true);
> +
> +    memory_region_add_subregion(system_memory, FLASH_BASE, flash);

SoC objects should avoid directly adding things to system memory.
If you look at hw/arm/iotkit.c it's an example of an SoC that
takes a MemoryRegion property from the board, creates a 'container'
region, adds the board memory and its devices to the container,
and then passes it to the CPU.

> +    memory_region_init_ram_nomigrate(sram, NULL, "nrf51.sram", SRAM_SIZE,
> +            &err);
> +    if (err) {
> +        error_propagate(errp, err);
> +        return;
> +    }
> +    vmstate_register_ram_global(sram);
> +    memory_region_add_subregion(system_memory, SRAM_BASE, sram);
> +
> +    /* TODO: implement a cortex m0 and update this */
> +    nvic = armv7m_init(get_system_memory(), FLASH_SIZE, 96,
> +            s->kernel_filename, ARM_CPU_TYPE_NAME("cortex-m3"));

We recently refactored the armv7m init code so you don't have
to use this function. Instead you can:
 * in this SoC object, initialize and realize an armv7m object
 * in the board code, use armv7m_load_kernel() to do the initial
   image load

That way you don't need to pass in the kernel filename as a
property to this object.


I'm a bit reluctant to take these patches until we have an
actual cortex-m0 model, because anything we take into QEMU
master is then something we have to support. My rule of thumb
is that it's ok to have board models that are missing
functionality, but we should avoid models that have wrong
functionality (like the wrong CPU) where we can.

thanks
-- PMM

  reply	other threads:[~2018-05-03  9:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03  9:05 [Qemu-devel] [PATCH 0/2] arm: Add nRF51 SoC and micro:bit machine Joel Stanley
2018-05-03  9:05 ` [Qemu-devel] [PATCH 1/2] arm: Add Nordic Semiconductor nRF51 SoC Joel Stanley
2018-05-03  9:17   ` Peter Maydell [this message]
2018-05-08 12:01     ` Stefan Hajnoczi
2018-05-08 12:05   ` Stefan Hajnoczi
2018-05-03  9:05 ` [Qemu-devel] [PATCH 2/2] arm: Add BBC micro:bit machine Joel Stanley
2018-05-03  9:21   ` Peter Maydell
2018-05-03  9:14 ` [Qemu-devel] [PATCH 0/2] arm: Add nRF51 SoC and " no-reply
2018-05-03  9:14 ` no-reply
2018-05-03  9:16 ` no-reply
2018-05-03  9:24 ` Peter Maydell
2018-06-27 14:35   ` Joel Stanley
2018-05-08 12:08 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFEAcA_4EiWXdSNdbiEWO_Q2Sac7qzNduhyWVNwW-crc5=w_nA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=andrew@aj.id.au \
    --cc=jim.mussared@gmail.com \
    --cc=joel@jms.id.au \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.