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/). > 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> >