Hi, Peter Maydel,
If I have to make a qemu machine for our future real system, can't I really just use virt (or copied version of virt for modification) and add our peripheral model? The purpose is to provide environment for software developers (using our peripheral which will take some time until functioning stage) and it doesn't need to be cycle accurate(of course qemu isn't for that), or even the processor doesn't need to be the same one for our development. I think we can just use cortex-a72 model for some time and change the model for more accurate emulation. Is it a possibility? Or as you said I have to choose an emulator model for a real system? Also I'm curious if for other machines, the DTB(device tree blob) is automatically generated like in 'virt' machine. p.s. - By the way, the 'machine not supported' error was because I haven't fully replaced the code for 'ababa' and it runs processing at least, though I saw seg fault. Thanks for the help, best regards, Chan Kim > -----Original Message----- > From: c...@etri.re.kr <c...@etri.re.kr> > Sent: Wednesday, February 17, 2021 8:33 PM > To: 'Peter Maydell' <peter.mayd...@linaro.org> > Cc: 'qemu-discuss' <qemu-discuss@nongnu.org> > Subject: RE: how to add a new machine? > > > Hi, Peter Maydell > Thank you very much for the information. > Those are all very helpful information for me. > Thank you! > Chan Kim > > > -----Original Message----- > > From: Peter Maydell <peter.mayd...@linaro.org> > > Sent: Wednesday, February 17, 2021 8:12 PM > > To: Chan Kim <c...@etri.re.kr> > > Cc: qemu-discuss <qemu-discuss@nongnu.org> > > Subject: Re: how to add a new machine? > > > > On Wed, 17 Feb 2021 at 09:39, <c...@etri.re.kr> wrote: > > > > > > Hello, very clever qemu developers, > > > > > > > > > > > > For our SoC development, I decided to make our new machine to play > > > with. (It’ll be a long term job) > > > > > > Let’s call the new machine ababa here. > > > > > > I thought just copying a machine will be easy, so I added these > > > files > > below. > > > > > > l hw/arm/ababa.c > > > > > > l include/hw/arm/ababa.h > > > > > > l hw/arm/ababa-acpi-build.c > > > > This suggests that you're modifying the 'virt' board. That is not a > > good template to use for a model of an SoC, because the virt board is > > purely virtual, and has no SoC at all, and also has a lot of > > complicated stuff related to ACPI, to dtb generation, and to versioned > > machine types, which a simple "model of real hardware" > > does not require. The aspeed boards are probably a good example of a > > recently-implemented well-maintained SoC based set of boards. > > > > > and modified these files to add that machine ababa during the build. > > > > > > l default-configs/arm-softmmu.mak, > > > > > l hw/arm/Kconfig > > > > > l hw/arm/Makefile.objs > > > > This suggests that you're modifying an old version of QEMU. > > If you're trying to do development like adding a new board model, you > > should usually be working with the head-of-QEMU-git. > > > > > So at least it compiles ok. But when I tried running an example > > > kernel (which boots ok on ‘virt’) on the ‘ababa’ machine, > > > > > > “Qemu gave me this error message. “qemu-system-aarch64 -M ababa : > > unsupported machine type.” > > > > This means that either (a) you failed to correctly modify the build > > system to actually build your ababa.c file, or > > (b) your ababa.c file didn't actually register a machine type with the > > right name. The -M option simply looks for every registered subclass > > of TYPE_MACHINE, so you don't need to explicitly add your new machine > > to any list. > > > > thanks > > -- PMM