понедељак, 22. јун 2020., Philippe Mathieu-Daudé <f4...@amsat.org> је написао/ла:
> Hi Aleksandar, > > On 6/22/20 7:30 PM, Aleksandar Markovic wrote: > > понедељак, 22. јун 2020., Aleksandar Markovic > > <aleksandar.qemu.de...@gmail.com > > <mailto:aleksandar.qemu.de...@gmail.com>> је написао/ла: > > > > > > > > понедељак, 22. јун 2020., Philippe Mathieu-Daudé <f4...@amsat.org > > <mailto:f4...@amsat.org>> је написао/ла: > > > > +Thomas > > > > On 6/22/20 6:19 PM, Peter Maydell wrote: > > > On Mon, 22 Jun 2020 at 17:01, Peter Maydell > > <peter.mayd...@linaro.org <mailto:peter.mayd...@linaro.org>> > wrote: > > >> > > >> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé > > <f4...@amsat.org <mailto:f4...@amsat.org>> wrote: > > >>> Renesas hardware patches > > >>> > > >>> - Add a common entry for Renesas hardware in MAINTAINERS > > >>> - Trivial SH4 cleanups > > >>> - Add RX GDB simulator from Yoshinori Sato > > >>> > > > > > > > > Can this rx patch be included in this pull request: (it was r-b-ed a > > couple of weeks ago already): > > > > https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg08581.html > > <https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg08581.html > > > > This pull request only contains hardware emulation patches (files under > hw/, not the TCG code from target/). > > The patch in question affects system mode, therefore hardware emulation too. Not a big deal, but, to me, it seems as a natural part of this pull request. It is quite common that pull requests are not limited by directories - optimally, they should deal with certain set of related functionalities, not limited by directories. Why would be that patch be left lonesome? Could you please, Philippe, reconsider exclusion/inclusion of this patch, if possible? Thanks, Aleksandar > R-b by Richard is here: > > > > https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00229.html > > > > The two messages are not directly connected on the list, since r-b was > > in June, and the patch was in May. > > > > > > > > Thanks in advance! > > > > Aleksandar > > > > > > > > > > >>> The Renesas RX target emulation was added in commit > c8c35e5f51, > > >>> these patches complete the target by adding the hardware > > emulation. > > >>> > > >>> Thank you Yoshinori for adding this code to QEMU, and your > > patience > > >>> during the review process. Now your port is fully integrated. > > >>> > > >>> Travis-CI: > > >>> https://travis-ci.org/github/philmd/qemu/builds/700461815 > > <https://travis-ci.org/github/philmd/qemu/builds/700461815> > > >> > > >> Hi; I'm afraid there's a format-string issue here (manifests > > >> on OSX, openbsd, and 32-bit platforms): > > >> > > >> /home/peter.maydell/qemu/hw/rx/rx-gdbsim.c: In function > > 'rx_gdbsim_init': > > >> /home/peter.maydell/qemu/hw/rx/rx-gdbsim.c:93:22: error: > > format '%lli' > > >> expects argument of type 'long long int', but argument 2 has > type > > >> 'ram_addr_t {aka unsigned int}' [-Werror=format=] > > >> error_report("Invalid RAM size, should be more than > > %" PRIi64 " Bytes", > > >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~ > > >> mc->default_ram_size); > > >> ~~~~~~~~~~~~~~~~~~~~ > > > > > > Also there appears to be a makefile/dependency bug somewhere, > > > because when I drop this merge attempt and retry building > > > with current master I get this error: > > > > > > make[1]: Entering directory '/home/petmay01/qemu-for- > merges/slirp' > > > make[1]: Nothing to be done for 'all'. > > > make[1]: Leaving directory '/home/petmay01/qemu-for- > merges/slirp' > > > CC qga/main.o > > > CC qemu-io.o > > > CC monitor/qmp-cmds-control.o > > > make: *** No rule to make target > > > '/home/petmay01/qemu-for-merges/hw/rx/Kconfig', needed by > > > 'aarch64-softmmu/config-devices.mak'. Stop. > > > make: *** Waiting for unfinished jobs.... > > > make: Leaving directory '/home/petmay01/qemu-for- > merges/build/w64' > > > > > > This seems to be because aarch64-softmmu/config-devices.mak.d > > > in the build tree says that aarch64-softmmu/config-devices.mak > > > depends on all the Kconfig files; this means that if a Kconfig > > > file gets deleted then incremental build stops working? > > > > This seems the same problem previously discussed here: > > https://www.mail-archive.com/qemu-devel@nongnu.org/ > msg676319.html <https://www.mail-archive.com/qemu-devel@nongnu.org/ > msg676319.html> > > >
