| Message ID | 307d86106f46f5781854708cc52cc2f83e63f119.1337944756.git.gxt@mprc.pku.edu.cn |
|---|---|
| State | New |
| Headers | show |
Am 25.05.2012 13:29, schrieb Guan Xuetao: > This patch adds configure and makefile support for unicore32-softmmu. > All puv3-soc devices are put into hw/pkunity directory, so this dir > will be added when unicore32-softmmu is selected. > > Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> > --- > Makefile.target | 5 +++++ > arch_init.c | 2 ++ > arch_init.h | 1 + > configure | 4 ++++ > default-configs/unicore32-softmmu.mak | 4 ++++ > 5 files changed, 16 insertions(+), 0 deletions(-) > create mode 100644 default-configs/unicore32-softmmu.mak > > diff --git a/Makefile.target b/Makefile.target > index 1582904..2f850d3 100644 > --- a/Makefile.target > +++ b/Makefile.target > @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o > obj-xtensa-y += core-dc233c.o > obj-xtensa-y += core-fsf.o > > +obj-unicore32-y += uc32_softmmu.o > +obj-unicore32-y += pkunity/puv3.o > +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o pkunity/puv3_gpio.o > +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o [snip] You need to put the Makefile/configure changes into the patches that introduce the files please, otherwise they cannot be checked for compiler warnings/errors. Andreas
> Am 25.05.2012 13:29, schrieb Guan Xuetao: >> This patch adds configure and makefile support for unicore32-softmmu. >> All puv3-soc devices are put into hw/pkunity directory, so this dir >> will be added when unicore32-softmmu is selected. >> >> Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> >> --- >> Makefile.target | 5 +++++ >> arch_init.c | 2 ++ >> arch_init.h | 1 + >> configure | 4 ++++ >> default-configs/unicore32-softmmu.mak | 4 ++++ >> 5 files changed, 16 insertions(+), 0 deletions(-) >> create mode 100644 default-configs/unicore32-softmmu.mak >> >> diff --git a/Makefile.target b/Makefile.target >> index 1582904..2f850d3 100644 >> --- a/Makefile.target >> +++ b/Makefile.target >> @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o >> obj-xtensa-y += core-dc233c.o >> obj-xtensa-y += core-fsf.o >> >> +obj-unicore32-y += uc32_softmmu.o >> +obj-unicore32-y += pkunity/puv3.o >> +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o >> pkunity/puv3_gpio.o >> +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o > [snip] > > You need to put the Makefile/configure changes into the patches that > introduce the files please, otherwise they cannot be checked for > compiler warnings/errors. > > Andreas I think the patch series is considered as a whole, and only compiling/building one device sim-code doesn't make sense. In fact, when unicore32-softmmu not enabled, the device sim-code isn't going to be compiled at all. Guan Xuetao
Am 28.05.2012 12:08, schrieb guanxuetao@mprc.pku.edu.cn: >> Am 25.05.2012 13:29, schrieb Guan Xuetao: >>> This patch adds configure and makefile support for unicore32-softmmu. >>> All puv3-soc devices are put into hw/pkunity directory, so this dir >>> will be added when unicore32-softmmu is selected. >>> >>> Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> >>> --- >>> Makefile.target | 5 +++++ >>> arch_init.c | 2 ++ >>> arch_init.h | 1 + >>> configure | 4 ++++ >>> default-configs/unicore32-softmmu.mak | 4 ++++ >>> 5 files changed, 16 insertions(+), 0 deletions(-) >>> create mode 100644 default-configs/unicore32-softmmu.mak >>> >>> diff --git a/Makefile.target b/Makefile.target >>> index 1582904..2f850d3 100644 >>> --- a/Makefile.target >>> +++ b/Makefile.target >>> @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o >>> obj-xtensa-y += core-dc233c.o >>> obj-xtensa-y += core-fsf.o >>> >>> +obj-unicore32-y += uc32_softmmu.o >>> +obj-unicore32-y += pkunity/puv3.o >>> +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o >>> pkunity/puv3_gpio.o >>> +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o >> [snip] >> >> You need to put the Makefile/configure changes into the patches that >> introduce the files please, otherwise they cannot be checked for >> compiler warnings/errors. >> > I think the patch series is considered as a whole, and only > compiling/building one device sim-code doesn't make sense. In fact, when > unicore32-softmmu not enabled, the device sim-code isn't going to be > compiled at all. Well, we expect each patch in a series to build warning-free for bisectability (even if applied in one PULL), and only compiling things in the final patch does not help. The series should be ordered so that we can either manually enable it with --target-list=unicore32-softmmu until it finally gets enabled by default, or like the openrisc target enables itself by default with some stubs and refines itself over the next patches. The other aspect is to make it easy for humans to review your patches before they can get applied, and personally I find it easier to review small patches. But opinions are divided on that. The criteria for acceptance is not just whether your kernel works in the end [*], my concern is more about how its design aligns with upstream trends like QOM awareness. Another thing: It is advisable to place SoC devices (as opposed to the machine) into Makefile.objs (hw-unicore32-y) so that they get compiled into libhw32 rather than into the target's directory. That avoids duplicates when a second endianness or a 64-bit version is introduced. (Yes, some existing targets violate that principle. I am working towards fixing it.) Andreas [*] It would be helpful if you could share linux-user and softmmu binaries on the Wiki for us to avoid regressions. http://wiki.qemu.org/Testing
> Am 28.05.2012 12:08, schrieb guanxuetao@mprc.pku.edu.cn: >>> Am 25.05.2012 13:29, schrieb Guan Xuetao: >>>> This patch adds configure and makefile support for unicore32-softmmu. >>>> All puv3-soc devices are put into hw/pkunity directory, so this dir >>>> will be added when unicore32-softmmu is selected. >>>> >>>> Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> >>>> --- >>>> Makefile.target | 5 +++++ >>>> arch_init.c | 2 ++ >>>> arch_init.h | 1 + >>>> configure | 4 ++++ >>>> default-configs/unicore32-softmmu.mak | 4 ++++ >>>> 5 files changed, 16 insertions(+), 0 deletions(-) >>>> create mode 100644 default-configs/unicore32-softmmu.mak >>>> >>>> diff --git a/Makefile.target b/Makefile.target >>>> index 1582904..2f850d3 100644 >>>> --- a/Makefile.target >>>> +++ b/Makefile.target >>>> @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o >>>> obj-xtensa-y += core-dc233c.o >>>> obj-xtensa-y += core-fsf.o >>>> >>>> +obj-unicore32-y += uc32_softmmu.o >>>> +obj-unicore32-y += pkunity/puv3.o >>>> +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o >>>> pkunity/puv3_gpio.o >>>> +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o >>> [snip] >>> >>> You need to put the Makefile/configure changes into the patches that >>> introduce the files please, otherwise they cannot be checked for >>> compiler warnings/errors. >>> >> I think the patch series is considered as a whole, and only >> compiling/building one device sim-code doesn't make sense. In fact, when >> unicore32-softmmu not enabled, the device sim-code isn't going to be >> compiled at all. > > Well, we expect each patch in a series to build warning-free for > bisectability (even if applied in one PULL), and only compiling things > in the final patch does not help. The series should be ordered so that > we can either manually enable it with --target-list=unicore32-softmmu > until it finally gets enabled by default, or like the openrisc target > enables itself by default with some stubs and refines itself over the > next patches. > > The other aspect is to make it easy for humans to review your patches > before they can get applied, and personally I find it easier to review > small patches. But opinions are divided on that. The criteria for > acceptance is not just whether your kernel works in the end [*], my > concern is more about how its design aligns with upstream trends like > QOM awareness. I see. Thanks. > > Another thing: It is advisable to place SoC devices (as opposed to the > machine) into Makefile.objs (hw-unicore32-y) so that they get compiled > into libhw32 rather than into the target's directory. That avoids > duplicates when a second endianness or a 64-bit version is introduced. > (Yes, some existing targets violate that principle. I am working towards > fixing it.) Thanks. That's exactly what I want to know. > > Andreas > > [*] It would be helpful if you could share linux-user and softmmu > binaries on the Wiki for us to avoid regressions. > http://wiki.qemu.org/Testing > I'm wandering who maintains Testing, then I could handin unicore32 testcase. Thanks & Regards, Guan Xuetao
diff --git a/Makefile.target b/Makefile.target index 1582904..2f850d3 100644 --- a/Makefile.target +++ b/Makefile.target @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o obj-xtensa-y += core-dc233c.o obj-xtensa-y += core-fsf.o +obj-unicore32-y += uc32_softmmu.o +obj-unicore32-y += pkunity/puv3.o +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o pkunity/puv3_gpio.o +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o + main.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) monitor.o: hmp-commands.h qmp-commands-old.h diff --git a/arch_init.c b/arch_init.c index 988adca..9314025 100644 --- a/arch_init.c +++ b/arch_init.c @@ -81,6 +81,8 @@ int graphic_depth = 15; #define QEMU_ARCH QEMU_ARCH_SPARC #elif defined(TARGET_XTENSA) #define QEMU_ARCH QEMU_ARCH_XTENSA +#elif defined(TARGET_UNICORE32) +#define QEMU_ARCH QEMU_ARCH_UNICORE32 #endif const uint32_t arch_type = QEMU_ARCH; diff --git a/arch_init.h b/arch_init.h index c7cb94a..5298139 100644 --- a/arch_init.h +++ b/arch_init.h @@ -16,6 +16,7 @@ enum { QEMU_ARCH_SH4 = 1024, QEMU_ARCH_SPARC = 2048, QEMU_ARCH_XTENSA = 4096, + QEMU_ARCH_UNICORE32 = 8192, }; extern const uint32_t arch_type; diff --git a/configure b/configure index b55a792..e4a7c3a 100755 --- a/configure +++ b/configure @@ -934,6 +934,7 @@ sparc64-softmmu \ s390x-softmmu \ xtensa-softmmu \ xtensaeb-softmmu \ +unicore32-softmmu \ " fi # the following are Linux specific @@ -3504,6 +3505,9 @@ mkdir -p $target_dir/kvm if test "$target" = "arm-linux-user" -o "$target" = "armeb-linux-user" -o "$target" = "arm-bsd-user" -o "$target" = "armeb-bsd-user" ; then mkdir -p $target_dir/nwfpe fi +if test "$target" = "unicore32-softmmu" ; then + mkdir -p $target_dir/pkunity +fi symlink "$source_path/Makefile.target" "$target_dir/Makefile" diff --git a/default-configs/unicore32-softmmu.mak b/default-configs/unicore32-softmmu.mak new file mode 100644 index 0000000..7508f75 --- /dev/null +++ b/default-configs/unicore32-softmmu.mak @@ -0,0 +1,4 @@ +# Default configuration for unicore32-softmmu + +CONFIG_PTIMER=y +CONFIG_PCKBD=y
This patch adds configure and makefile support for unicore32-softmmu. All puv3-soc devices are put into hw/pkunity directory, so this dir will be added when unicore32-softmmu is selected. Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> --- Makefile.target | 5 +++++ arch_init.c | 2 ++ arch_init.h | 1 + configure | 4 ++++ default-configs/unicore32-softmmu.mak | 4 ++++ 5 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 default-configs/unicore32-softmmu.mak