Hi Alistair,
On Tue, Jun 27, 2017 at 4:19 AM, Alistair Francis <alistai...@gmail.com>
wrote:
> On Mon, Jun 26, 2017 at 9:01 AM, sundeep subbaraya
> <sundeep.l...@gmail.com> wrote:
> > Hi Alistair,
> >
> > On Wed, May 31, 2017 at 4:02 AM, Alistair Francis <alistai...@gmail.com>
> > wrote:
> >>
> >> On Sun, May 28, 2017 at 10:26 PM, sundeep subbaraya
> >> <sundeep.l...@gmail.com> wrote:
> >> > Hi Alistair,
> >> >
> >> > On Sat, May 27, 2017 at 5:30 AM, Alistair Francis <
> alistai...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, May 16, 2017 at 8:38 AM, Subbaraya Sundeep
> >> >> <sundeep.l...@gmail.com> wrote:
> >> >> > Emulated Emcraft's Smartfusion2 System On Module starter
> >> >> > kit.
> >> >> >
> >> >> > Signed-off-by: Subbaraya Sundeep <sundeep.l...@gmail.com>
> >> >> > ---
> >> >> > hw/arm/Makefile.objs | 1 +
> >> >> > hw/arm/msf2-som.c | 89
> >> >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> > 2 files changed, 90 insertions(+)
> >> >> > create mode 100644 hw/arm/msf2-som.c
> >> >> >
> >> >> > diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> >> >> > index c828061..4b02093 100644
> >> >> > --- a/hw/arm/Makefile.objs
> >> >> > +++ b/hw/arm/Makefile.objs
> >> >> > @@ -5,6 +5,7 @@ obj-y += omap_sx1.o palm.o realview.o spitz.o
> >> >> > stellaris.o
> >> >> > obj-y += tosa.o versatilepb.o vexpress.o virt.o xilinx_zynq.o z2.o
> >> >> > obj-$(CONFIG_ACPI) += virt-acpi-build.o
> >> >> > obj-y += netduino2.o
> >> >> > +obj-y += msf2-som.o
> >> >>
> >> >> This should be obj-$(CONFIG_MSF2).
> >> >
> >> >
> >> > Ok will change it.
> >> >>
> >> >>
> >> >> > obj-y += sysbus-fdt.o
> >> >> >
> >> >> > obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
> >> >> > diff --git a/hw/arm/msf2-som.c b/hw/arm/msf2-som.c
> >> >> > new file mode 100644
> >> >> > index 0000000..cd2b759
> >> >> > --- /dev/null
> >> >> > +++ b/hw/arm/msf2-som.c
> >> >> > @@ -0,0 +1,89 @@
> >> >> > +/*
> >> >> > + * SmartFusion2 SOM starter kit(from Emcraft) emulation.
> >> >> > + *
> >> >> > + * Copyright (c) 2017 Subbaraya Sundeep <sundeep.l...@gmail.com>
> >> >> > + *
> >> >> > + * Permission is hereby granted, free of charge, to any person
> >> >> > obtaining a copy
> >> >> > + * of this software and associated documentation files (the
> >> >> > "Software"), to deal
> >> >> > + * in the Software without restriction, including without
> limitation
> >> >> > the rights
> >> >> > + * to use, copy, modify, merge, publish, distribute, sublicense,
> >> >> > and/or
> >> >> > sell
> >> >> > + * copies of the Software, and to permit persons to whom the
> >> >> > Software
> >> >> > is
> >> >> > + * furnished to do so, subject to the following conditions:
> >> >> > + *
> >> >> > + * The above copyright notice and this permission notice shall be
> >> >> > included in
> >> >> > + * all copies or substantial portions of the Software.
> >> >> > + *
> >> >> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >> >> > EXPRESS OR
> >> >> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> >> >> > MERCHANTABILITY,
> >> >> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT
> >> >> > SHALL
> >> >> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES
> >> >> > OR
> >> >> > OTHER
> >> >> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> >> >> > ARISING FROM,
> >> >> > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> >> >> > DEALINGS IN
> >> >> > + * THE SOFTWARE.
> >> >> > + */
> >> >> > +
> >> >> > +#include "qemu/osdep.h"
> >> >> > +#include "qapi/error.h"
> >> >> > +#include "hw/boards.h"
> >> >> > +#include "hw/arm/msf2-soc.h"
> >> >> > +#include "hw/arm/arm.h"
> >> >> > +#include "exec/address-spaces.h"
> >> >> > +
> >> >> > +#define DDR_BASE_ADDRESS 0xA0000000
> >> >> > +#define DDR_SIZE (64 * M_BYTE)
> >> >> > +
> >> >> > +static void emcraft_sf2_init(MachineState *machine)
> >> >> > +{
> >> >> > + DeviceState *dev;
> >> >> > + DeviceState *spi_flash;
> >> >> > + MSF2State *soc;
> >> >> > + DriveInfo *dinfo = drive_get_next(IF_MTD);
> >> >> > + qemu_irq cs_line;
> >> >> > + SSIBus *spi_bus;
> >> >> > + MemoryRegion *sysmem = get_system_memory();
> >> >> > + MemoryRegion *ddr = g_new(MemoryRegion, 1);
> >> >> > +
> >> >> > + memory_region_init_ram(ddr, NULL, "ddr-ram", DDR_SIZE,
> >> >> > + &error_fatal);
> >> >> > + vmstate_register_ram_global(ddr);
> >> >> > + memory_region_add_subregion(sysmem, DDR_BASE_ADDRESS, ddr);
> >> >>
> >> >> The user can use -m to specify the amount of RAM to create in the
> >> >> machine. Unless this board only ever includes 64MB of RAM you should
> >> >> use that option (you will need to sanity check it though). If the
> >> >> board only ever has 64MB it might be worth printing a warning to the
> >> >> user if they specify an something. Although there might be a default
> >> >> if they don't use -m, which makes it hard to print out a warning
> >> >> message.
> >> >
> >> >
> >> > This -m confuses me. Why is it necessary for an embedded board? RAM
> chip
> >> > is fixed and not extendable. Whereas normal PC may have extra RAM
> slots.
> >> > If another board has more RAM then we would instantiate another
> machine
> >> > for
> >> > it
> >> > with that RAM size. Please explain. Maybe I am thinking in wrong
> >> > direction.
> >>
> >> I agree with you, it doesn't make sense for every board. For some
> >> embedded boards it does make sense (ZynqMP can have a customisable
> >> amount of memory) but for most it doesn't make too much sense.
> >>
> >> In saying that it is a commonly used QEMU option, if you can find a
> >> way to report a warning if the user tries to specify a custom amount
> >> of memory I think that would be beneficial as QEMU will just ignore
> >> their input. I have a feeling that the ram_size variable will be set
> >> even if the user doesn't specify anything, which we don't want to
> >> report a warning on.
> >
> >
> > Do we need to report and exit if user specifies custom amount of memory?
>
> I had a quick look at other ARM machines and it looks like a lot of
> them use the ram_size variable from the machine to set the size of the
> memory, but some have just hard coded values.
>
> I'm not sure if there is an accepted "right" way to do this. If the
> board only ever has 64MB of memory then it's probably ok to just hard
> code it. Like you said, I don't think user have a high expectation of
> adjusting the memory in embedded boards.
>
Thank you, I will drop the -m option.
Regards,
Sundeep
>
> Thanks,
> Alistair
>
