[1/2] arm: Add Nordic Semiconductor nRF51 SoC

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>
---
 default-configs/arm-softmmu.mak |   1 +
 hw/arm/Makefile.objs            |   1 +
 hw/arm/nrf51_soc.c              | 101 ++++++++++++++++++++++++++++++++
 include/hw/arm/nrf51_soc.h      |  31 ++++++++++
 4 files changed, 134 insertions(+)
 create mode 100644 hw/arm/nrf51_soc.c
 create mode 100644 include/hw/arm/nrf51_soc.h

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

On Thu, May 03, 2018 at 10:17:51AM +0100, Peter Maydell wrote:
> On 3 May 2018 at 10:05, Joel Stanley <joel@jms.id.au> wrote:
> 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.

For the purposes of the micro:bit emulation project we're not sure yet
how far the M3 model will take us.  The M0 is a subset of the M3 and we
intend to use it during bring-up...and even afterwards if software runs
okay with it.

If you don't want to merge this into qemu.git/master we'll have to
maintain a "microbit" project branch on which Julia and Steffen (and
others) can work during the Google Summer of Code and Outreachy period.

My concern about keeping it out-of-tree is that we want Julia and
Steffen to participate in the upstream community and get their patches
merged.  Anything out-of-tree could still be rejected at a later date
:(.

Can we mark the machine type "experimental" and merge it in
qemu.git/master with the understanding that it may be removed if there
is no active development?

Stefan

On Thu, May 03, 2018 at 06:35:31PM +0930, Joel Stanley wrote:
> diff --git a/hw/arm/nrf51_soc.c b/hw/arm/nrf51_soc.c
> new file mode 100644
> index 000000000000..a2e3d6f013f0
> --- /dev/null
> +++ b/hw/arm/nrf51_soc.c
> @@ -0,0 +1,101 @@
> +/*
> + * Nordic Semiconductor nRF51 SoC
> + *
> + * Copyright 2018 Joel Stanley <joel@jms.id.au>
> + *
> + * This code is licensed under the GPL version 2 or later.  See
> + * the COPYING file in the top-level directory.

Please include the link in the comment:

  The reference manual is available here:
  http://infocenter.nordicsemi.com/pdf/nRF51_RM_v3.0.pdf

> +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);
> +
> +    memory_region_init_ram_nomigrate(flash, NULL, "nrf51.flash", FLASH_SIZE,
> +            &err);
> +    if (err) {
> +        error_propagate(errp, err);
> +        return;

Please free resources (e.g. sram and flash) in error code paths.