subject:"Re\: \[PULL 00\/15\] Renesas hardware patches for 2020\-06\-21"

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

2020-06-22 Thread Aleksandar Markovic

понедељак, 22. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> Hi Aleksandar,
>
> On 6/22/20 7:30 PM, Aleksandar Markovic wrote:
> > понедељак, 22. јун 2020., Aleksandar Markovic
> >  > > је написао/ла:
> >
> >
> >
> > понедељак, 22. јун 2020., Philippe Mathieu-Daudé  > > је написао/ла:
> >
> > +Thomas
> >
> > On 6/22/20 6:19 PM, Peter Maydell wrote:
> > > On Mon, 22 Jun 2020 at 17:01, Peter Maydell
> > mailto:peter.mayd...@linaro.org>>
> wrote:
> > >>
> > >> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé
> > 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
> >  >
>
> 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
> > 
> > >>
> > >> 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  msg676319.html>
> >
>

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

2020-06-22 Thread Philippe Mathieu-Daudé

Hi Aleksandar,

On 6/22/20 7:30 PM, Aleksandar Markovic wrote:
> понедељак, 22. јун 2020., Aleksandar Markovic
>  > је написао/ла:
> 
> 
> 
> понедељак, 22. јун 2020., Philippe Mathieu-Daudé  > је написао/ла:
> 
> +Thomas
> 
> On 6/22/20 6:19 PM, Peter Maydell wrote:
> > On Mon, 22 Jun 2020 at 17:01, Peter Maydell
> mailto:peter.mayd...@linaro.org>> wrote:
> >>
> >> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé
> 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
> 

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
> 
> >>
> >> 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 
> 
>

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

2020-06-22 Thread Aleksandar Markovic

понедељак, 22. јун 2020., Aleksandar Markovic <
aleksandar.qemu.de...@gmail.com> је написао/ла:

>
>
> понедељак, 22. јун 2020., Philippe Mathieu-Daudé  је
> написао/ла:
>
>> +Thomas
>>
>> On 6/22/20 6:19 PM, Peter Maydell wrote:
>> > On Mon, 22 Jun 2020 at 17:01, Peter Maydell 
>> wrote:
>> >>
>> >> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé 
>> 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
>
>
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
>> >>
>> >> 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
>>
>>

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

2020-06-22 Thread Aleksandar Markovic

понедељак, 22. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> +Thomas
>
> On 6/22/20 6:19 PM, Peter Maydell wrote:
> > On Mon, 22 Jun 2020 at 17:01, Peter Maydell 
> wrote:
> >>
> >> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé 
> 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

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
> >>
> >> 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
>
>

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

2020-06-22 Thread Philippe Mathieu-Daudé

+Thomas

On 6/22/20 6:19 PM, Peter Maydell wrote:
> On Mon, 22 Jun 2020 at 17:01, Peter Maydell  wrote:
>>
>> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé  wrote:
>>> Renesas hardware patches
>>>
>>> - Add a common entry for Renesas hardware in MAINTAINERS
>>> - Trivial SH4 cleanups
>>> - Add RX GDB simulator from Yoshinori Sato
>>>
>>> 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
>>
>> 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

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

2020-06-22 Thread Philippe Mathieu-Daudé

On 6/22/20 6:01 PM, Peter Maydell wrote:
> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé  wrote:
>>
>> The following changes since commit 06c4cc3660b366278bdc7bc8b6677032d7b1118c:
>>
>>   qht: Fix threshold rate calculation (2020-06-19 18:29:11 +0100)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.com/philmd/qemu.git tags/renesas-hw-20200621
>>
>> for you to fetch changes up to 730101266e4026fc19808c740ee4b8118eeaaafe:
>>
>>   docs: Document the RX target (2020-06-21 01:21:47 +0200)
>>
>> 
>> Renesas hardware patches
>>
>> - Add a common entry for Renesas hardware in MAINTAINERS
>> - Trivial SH4 cleanups
>> - Add RX GDB simulator from Yoshinori Sato
>>
>> 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
> 
> 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);
>   

I apologize, I missed that while rebasing on Igor's memdev work.
I disabled my obsd and win32 builds after they started to fail
few months ago and forgot to re-enable them after they were fixed.

We recently dropped the Travis-CI OSX builds (commit 22a231950)
in favor of Cirrus-CI. There the build succeeded (Mojave):
https://cirrus-ci.com/build/6678899172048896
What is different in your OSX setup?

I'll respin with:

-- >8 --
diff --git a/hw/rx/rx-gdbsim.c b/hw/rx/rx-gdbsim.c
index 8cd7a438f2..b8a56fa7af 100644
--- a/hw/rx/rx-gdbsim.c
+++ b/hw/rx/rx-gdbsim.c
@@ -17,6 +17,7 @@
  */

 #include "qemu/osdep.h"
+#include "qemu/cutils.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "qemu-common.h"
@@ -90,8 +91,9 @@ static void rx_gdbsim_init(MachineState *machine)
 const char *dtb_filename = machine->dtb;

 if (machine->ram_size < mc->default_ram_size) {
-error_report("Invalid RAM size, should be more than %" PRIi64 "
Bytes",
- mc->default_ram_size);
+char *sz = size_to_str(mc->default_ram_size);
+error_report("Invalid RAM size, should be more than %s", sz);
+g_free(sz);
 }

 /* Allocate memory space */
---

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

2020-06-22 Thread Peter Maydell

On Mon, 22 Jun 2020 at 17:01, Peter Maydell  wrote:
>
> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé  wrote:
> > Renesas hardware patches
> >
> > - Add a common entry for Renesas hardware in MAINTAINERS
> > - Trivial SH4 cleanups
> > - Add RX GDB simulator from Yoshinori Sato
> >
> > 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
>
> 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?

thanks
-- PMM

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

2020-06-22 Thread Peter Maydell

On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé  wrote:
>
> The following changes since commit 06c4cc3660b366278bdc7bc8b6677032d7b1118c:
>
>   qht: Fix threshold rate calculation (2020-06-19 18:29:11 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/philmd/qemu.git tags/renesas-hw-20200621
>
> for you to fetch changes up to 730101266e4026fc19808c740ee4b8118eeaaafe:
>
>   docs: Document the RX target (2020-06-21 01:21:47 +0200)
>
> 
> Renesas hardware patches
>
> - Add a common entry for Renesas hardware in MAINTAINERS
> - Trivial SH4 cleanups
> - Add RX GDB simulator from Yoshinori Sato
>
> 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

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);
  

thanks
-- PMM

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

8 matches

Site Navigation

Mail list logo

Footer information