On 2/15/21 6:31 AM, Thomas Huth wrote:
> On 14/02/2021 18.59, Philippe Mathieu-Daudé wrote:
>> Add a job to build the MIPS r5900o32el (linux-user) target
>> and run the TCG tests.
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> .gitlab-ci.yml | 12
>> 1 file changed, 12 inser
On 2/15/21 9:07 AM, Philippe Mathieu-Daudé wrote:
> On 2/15/21 6:31 AM, Thomas Huth wrote:
>> On 14/02/2021 18.59, Philippe Mathieu-Daudé wrote:
>>> Add a job to build the MIPS r5900o32el (linux-user) target
>>> and run the TCG tests.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé
>>> ---
>>> .gi
Igor Mammedov writes:
>> >
>> > Please try reusing scratch CPU approach, see
>> > kvm_arm_get_host_cpu_features()
>> > for an example. You will very likely end up with simpler series,
>> > compared to reinventing wheel.
>>
>> Even if I do that (and I serioulsy doubt it's going to be easier t
Igor Mammedov writes:
> On Fri, 12 Feb 2021 16:26:03 +0100
> Vitaly Kuznetsov wrote:
>
>> Vitaly Kuznetsov writes:
>>
>> > Igor Mammedov writes:
>> >
>> >>
>> >> Please try reusing scratch CPU approach, see
>> >> kvm_arm_get_host_cpu_features()
>> >> for an example. You will very likely e
On Fri, Feb 12, 2021 at 06:38:16PM +, Peter Maydell wrote:
> On Thu, 11 Feb 2021 at 10:12, Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > I notice that as well as handling surface_bits_per_pixel()
> > > possibly returning 8, 15, 16, 24, these devices also seem to
> > > check for the possibility
We already got a global function called id_generate() to create unique
IDs within QEMU. Let's use it in the network subsytem, too, instead of
inventing our own ID scheme here.
Signed-off-by: Thomas Huth
---
include/qemu/id.h | 1 +
net/net.c | 6 +++---
util/id.c | 1 +
3 files c
Am 13.02.2021 um 00:13 hat Eric Blake geschrieben:
> On 2/2/21 6:49 AM, Vladimir Sementsov-Ogievskiy wrote:
> > This patch is generated by cocci script:
> >
> > @@
> > symbol bdrv_open_child, errp, local_err;
> > expression file;
> > @@
> >
> > file = bdrv_open_child(...,
> > -
On 2/14/21 6:58 PM, Philippe Mathieu-Daudé wrote:
> The R5900 CPU was removed some time ago (frankly I don't remember
> why). This series add it back, but to prove it works, we also add
> testing at the end.
>
> The main motivation is to have MIPS R5900 coverage, but to be able
> to run real world
From: Thomas Huth
Simply add the flag to an existing job, no need for yet another
job here.
Signed-off-by: Thomas Huth
Signed-off-by: Alex Bennée
Reviewed-by: Wainer dos Santos Moschetta
Reviewed-by: Alex Bennée
Message-Id: <20210211045455.456371-4-th...@redhat.com>
Message-Id: <202102111227
The following changes since commit 392b9a74b9b621c52d05e37bc6f41f1bbab5c6f8:
Merge remote-tracking branch 'remotes/ericb/tags/pull-bitmaps-2021-02-12'
into staging (2021-02-13 21:26:00 +)
are available in the Git repository at:
https://github.com/stsquad/qemu.git tags/pull-testing-gdbst
From: Thomas Huth
Add it to the existing Clang job and also add a job that covers the
linux-user code with this compiler flag. To make sure that the detected
problems are not simply ignored, let's also use "-fno-sanitize-recover=..."
now instead.
Signed-off-by: Thomas Huth
Signed-off-by: Alex B
Shippable is about to sunset in May 2021 [1] and we had already moved
a chunk of the crossbuilds to GitLab. We already cross build
mips-softmmu targets since:
6bcb5fc0f7 ("gitlab-ci: Add cross-compiling build tests")
and x86 is very well covered.
[1]:
https://blog.shippable.com/the-next-step-
From: Philippe Mathieu-Daudé
Similarly to commit 8cdb2cef3f1, move the gprof/gcov test to GitLab.
The coverage-summary.sh script is not Travis-CI specific, make it
generic.
[thuth: Add gcovr and bsdmainutils which are required for the
coverage-summary.sh script to the ubuntu docker file
From: Thomas Huth
Use clang-10, so we can also use the --enable-tsan configure
option instead of only passing the flag via --extra-cflags.
Signed-off-by: Thomas Huth
Signed-off-by: Alex Bennée
Reviewed-by: Alex Bennée
Message-Id: <20210211045455.456371-6-th...@redhat.com>
Message-Id: <2021021
From: Philippe Mathieu-Daudé
Travis-CI seems to have enforced memory limit on containers,
and the 'GCC check-tcg' job started to fail on AArch64 [*]:
[2041/3679] Compiling C++ object libcommon.fa.p/disas_nanomips.cpp.o
FAILED: libcommon.fa.p/disas_nanomips.cpp.o
{standard input}: Assembler
From: Peter Maydell
We used to make a distinction between 'float64'/'float32' types and
the 'uint64_t'/'uint32_t' types, requiring special conversion
operations to go between them. We've now dropped this distinction as
unnecessary, and the 'float*' types remain primarily for
documentation purpos
From: Thomas Huth
We already have similar jobs in the gitlab-CI ("build-some-softmmu" and
"build-user-plugins"), so let's switch one of them to use --enable-debug
instead of --enable-debug-tcg, then we can simply drop these jobs from
the Travis-CI.
Signed-off-by: Thomas Huth
Signed-off-by: Alex
From: Peter Maydell
The F: patterns in the "GDB stub" section forgot gdbstub.h; add it.
Signed-off-by: Peter Maydell
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Alex Bennée
Message-Id: <20210208113729.25170-1-peter.mayd...@linaro.org>
Message-Id: <20210211122750.
From: Daniel P. Berrangé
The travis container that we have no longer matches what travis
currently uses. As all x86 jobs are being moved to GitLab CI too,
there is no compelling reason to update the travis container. It
is simpler to just remove it.
Signed-off-by: Daniel P. Berrangé
Signed-off-
Signed-off-by: Alex Bennée
Message-Id: <20210211122750.22645-16-alex.ben...@linaro.org>
diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target
b/tests/tcg/multiarch/system/Makefile.softmmu-target
index 4657f6e4cf..625ed792c6 100644
--- a/tests/tcg/multiarch/system/Makefile.softmmu-targe
From: Peter Maydell
The functions gdb_get_float32() and gdb_get_float64() are now unused;
remove them.
Signed-off-by: Peter Maydell
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20210208113428.7181-5-peter.mayd...@linaro.org>
Message-Id: <20210211122750.22645-14-
From: Peter Maydell
We used to make a distinction between 'float64'/'float32' types and
the 'uint64_t'/'uint32_t' types, requiring special conversion
operations to go between them. We've now dropped this distinction as
unnecessary, and the 'float*' types remain primarily for
documentation purpos
From: Peter Maydell
We used to make a distinction between 'float64'/'float32' types and
the 'uint64_t'/'uint32_t' types, requiring special conversion
operations to go between them. We've now dropped this distinction as
unnecessary, and the 'float*' types remain primarily for
documentation purpos
From: Peter Maydell
The float-access functions stfl_*, stfq*, ldfl* and ldfq* are now
unused; remove them. (Accesses to float64 and float32 types can be
made with the ldl/stl/ldq/stq functions, as float64 and float32 are
guaranteed to be typedefs for normal integer types.)
Signed-off-by: Peter
Vincent Fazio writes:
> On Sun, Feb 14, 2021 at 6:50 AM Laurent Vivier wrote:
>>
>> Le 14/02/2021 à 12:24, Alex Bennée a écrit :
>> >
>> > Vincent Fazio writes:
>> >
>> >> From: Vincent Fazio
>> >>
>> >> Previously, pgd_find_hole_fallback assumed that if the build host's libc
>> >> had MAP_F
Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:
> even luminous (version 12.2) is unmaintained for over 3 years now.
> Bump the requirement to get rid of the ifdef'ry in the code.
>
> Signed-off-by: Peter Lieven
> diff --git a/meson.build b/meson.build
> index 5943aa8a51..02d263ad33 100644
On Mon, Feb 15, 2021 at 11:11:23AM +0100, Kevin Wolf wrote:
> Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:
> > even luminous (version 12.2) is unmaintained for over 3 years now.
> > Bump the requirement to get rid of the ifdef'ry in the code.
> >
> > Signed-off-by: Peter Lieven
>
> > dif
Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:
> Signed-off-by: Peter Lieven
> ---
> block/rbd.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/block/rbd.c b/block/rbd.c
> index f68ebcf240..7abd0252c9 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel, RGB. The TCX code already
assumes 32bpp, but it still has some checks of is_surface_bgr()
in an attempt to support 32bpp BGR. is_surface_bgr() will always
return false for the qemu_console_surface(
On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
> even luminous (version 12.2) is unmaintained for over 3 years now.
> Bump the requirement to get rid of the ifdef'ry in the code.
We have clear rules on when we bump minimum versions, determined by
the OS platforms we target:
https
Claudio Fontana writes:
> Signed-off-by: Claudio Fontana
Reviewed-by: Alex Bennée
--
Alex Bennée
Now the template header is included only for BITS==32, expand
out all the macros that depended on the BITS setting.
Signed-off-by: Peter Maydell
---
hw/display/tc6393xb_template.h | 35 --
1 file changed, 4 insertions(+), 31 deletions(-)
diff --git a/hw/display/t
The function tc6393xb_draw_graphic32() is called in exactly one place,
so just inline the function body at its callsite. This allows us to
drop the template header entirely.
The code move includes a single added space after 'for' to fix
the coding style.
Signed-off-by: Peter Maydell
---
hw/disp
We only include the template header once, so just inline it into the
source file for the device.
Signed-off-by: Peter Maydell
---
hw/display/omap_lcd_template.h | 154 -
hw/display/omap_lcdc.c | 127 ++-
2 files changed, 125 inserti
This patchset removes dead code (including a couple of 'template'
headers) for handling UI surfaces that are formats other than
32-bit RGB for the musicpal, tc6393xb and omap_lcdc display devices.
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel
The draw_line16_32() function in the omap_lcdc template header
includes an ifdef for the case where HOST_WORDS_BIGENDIAN matches
TARGET_WORDS_BIGENDIAN. This is trying to optimise for "source
bitmap and destination bitmap format match", but it is broken,
because in this function the formats don't
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel RGB. Remove the legacy dead
code from the tc6393xb display device which was handling the
possibility that the console surface was some other format.
Signed-off-by: Peter Maydell
---
include/ui/co
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel RGB. Remove the legacy dead
code from the milkymist display device which was handling the
possibility that the console surface was some other format.
Signed-off-by: Peter Maydell
---
hw/arm/music
Tests in the "auto" group should support qcow2 so that they can
be run during "make check-block". Test 259 only supports "raw", so
it currently always gets skipped when running "make check-block".
Let's skip this unnecessary step and remove it from the auto group.
Signed-off-by: Thomas Huth
---
The omap_lcdc template header is already only included once, for
DEPTH==32, but it still has all the macro-driven parameterization
for other depths. Expand out all the macros in the header.
Signed-off-by: Peter Maydell
---
hw/display/omap_lcd_template.h | 67 ++
1
Fix some minor coding style issues in the template header,
so checkpatch doesn't complain when we move the code.
Signed-off-by: Peter Maydell
---
hw/display/omap_lcd_template.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/display/omap_lcd_template.h b/hw/display/o
On Wed, Feb 10, 2021 at 4:04 AM Dr. David Alan Gilbert (git)
wrote:
>
> From: "Dr. David Alan Gilbert"
> +
> +typedef struct {
> +/* Offsets within the file being mapped */
> +uint64_t fd_offset[VHOST_USER_FS_SLAVE_ENTRIES];
> +/* Offsets within the cache */
> +uint64_t c_offset[V
The macro draw_line_func is used only once; just expand it.
Signed-off-by: Peter Maydell
---
hw/display/omap_lcdc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/display/omap_lcdc.c b/hw/display/omap_lcdc.c
index 2db04fad2fc..0ba42ef637c 100644
--- a/hw/display/omap_l
Am 07.12.2020 um 18:20 hat Stefan Hajnoczi geschrieben:
> v2:
> * Add abrt handler that terminates qemu-storage-daemon to
>vhost-user-blk-test. No more orphaned processes on test failure. [Peter]
> * Fix sector number calculation in vhost-user-blk-server.c
> * Introduce VIRTIO_BLK_SECTOR_BIT
On Thu, 11 Feb 2021 19:52:40 -0300
Daniel Henrique Barboza wrote:
> drc_isolate_logical() is used to move the DRC from the "Configured" to the
> "Available" state, erroring out if the DRC is in the unexpected "Unisolate"
> state and doing nothing (with RTAS_OUT_SUCCESS) if the DRC is already in
>
On 1/18/21 10:36 AM, Philippe Mathieu-Daudé wrote:
> On 1/18/21 10:10 AM, Claudio Fontana wrote:
>> On 1/17/21 5:48 PM, Philippe Mathieu-Daudé wrote:
>>> Watchpoint funtions use cpu_restore_state() which is only
>>> available when TCG accelerator is built. Restrict them
>>> to TCG.
>>>
>>> Signed-o
On Mon, Feb 15, 2021 at 09:53:50AM +0100, Vitaly Kuznetsov wrote:
> I have no clue why scratch vCPUs were implemented on ARM, however, I'd
We don't have an ioctl like KVM_GET_SUPPORTED_CPUID, which operates on
the KVM fd. Perhaps we should.
Thanks,
drew
Am 19.01.2021 um 17:40 hat Alexander Bulekov geschrieben:
> cmd_fis is mapped as DMA_DIRECTION_FROM_DEVICE, however, it is read
> from, and not written to anywhere. Fix the DMA_DIRECTION and mark
> cmd_fis as read-only in the code.
>
> Signed-off-by: Alexander Bulekov
Thanks, applied to the bloc
Am 18.01.2021 um 16:49 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 18 January 2021 15:34
> > To: qemu-devel@nongnu.org
> > Cc: Roger Pau Monne ; Arthur Borsboom
> > ; Stefano
> > Stabellini ; Anthony Perard
> > ; Paul Durrant
> > ; Kevin Wolf
On Fri, Feb 12, 2021 at 12:08:11PM +, Jag Raman wrote:
> If we have to use libvfio-user library in QEMU, could we link the library
> with the QEMU binary based on some config options?
Yes, meson_options.txt can be used.
> Secondly, the remote process in multi-process QEMU uses the same QEMU
On 2/15/21 11:32 AM, Peter Maydell wrote:
> The function tc6393xb_draw_graphic32() is called in exactly one place,
> so just inline the function body at its callsite. This allows us to
> drop the template header entirely.
>
> The code move includes a single added space after 'for' to fix
> the cod
On 2/15/21 11:32 AM, Peter Maydell wrote:
> The draw_line16_32() function in the omap_lcdc template header
> includes an ifdef for the case where HOST_WORDS_BIGENDIAN matches
> TARGET_WORDS_BIGENDIAN. This is trying to optimise for "source
> bitmap and destination bitmap format match", but it is b
On 2/15/21 11:32 AM, Peter Maydell wrote:
> We only include the template header once, so just inline it into the
> source file for the device.
>
> Signed-off-by: Peter Maydell
> ---
> hw/display/omap_lcd_template.h | 154 -
> hw/display/omap_lcdc.c | 127 +
On 2/15/21 11:32 AM, Peter Maydell wrote:
> The macro draw_line_func is used only once; just expand it.
>
> Signed-off-by: Peter Maydell
> ---
> hw/display/omap_lcdc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
On 2/15/21 11:32 AM, Peter Maydell wrote:
> Fix some minor coding style issues in the template header,
> so checkpatch doesn't complain when we move the code.
>
> Signed-off-by: Peter Maydell
> ---
> hw/display/omap_lcd_template.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Re
On 14/01/21 17:36, John Snow wrote:
The sane way to evade the language design problem is to use the existing
QMP language.
I wouldn't mind implementing this for version 0.1 -- just allow
copy-pasting JSON into the input bar -- it's a feature I wanted anyway.
I think the only way out of lan
Do you have a test case (QEMU command line and all necessary image
files) that demonstrates this, please ?
** Tags added: arm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1914535
Title:
PL110 8-
On 2/13/21 4:23 AM, Bruce Rogers wrote:
> When qemu is built with modules, but a given module doesn't load
> qemu should handle that gracefully. When ui-spice-core.so isn't
> able to be loaded and qemu is invoked with -display spice-app or
> -spice, qemu will dereference a null pointer. With this c
Claudio Fontana writes:
> i386 is the first user of AccelCPUClass, allowing to split
> cpu.c into:
>
> cpu.ccpuid and common x86 cpu functionality
> host-cpu.c host x86 cpu functions and "host" cpu type
> kvm/kvm-cpu.cKVM x86 AccelCPUClass
> hvf/hvf-cpu.cHVF x86 AccelC
Am 15.02.2021 um 11:38 hat Thomas Huth geschrieben:
> Tests in the "auto" group should support qcow2 so that they can
> be run during "make check-block". Test 259 only supports "raw", so
> it currently always gets skipped when running "make check-block".
> Let's skip this unnecessary step and remov
Claudio Fontana writes:
> move the call to accel_cpu->cpu_realizefn to the general
> cpu_exec_realizefn from target/i386, so it does not need to be
> called for every target explicitly as we enable more targets.
>
> Signed-off-by: Claudio Fontana
Reviewed-by: Alex Bennée
--
Alex Bennée
Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:
On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
even luminous (version 12.2) is unmaintained for over 3 years now.
Bump the requirement to get rid of the ifdef'ry in the code.
We have clear rules on when we bump minimum versions, de
Am 15.02.21 um 11:19 schrieb Daniel P. Berrangé:
On Mon, Feb 15, 2021 at 11:11:23AM +0100, Kevin Wolf wrote:
Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:
even luminous (version 12.2) is unmaintained for over 3 years now.
Bump the requirement to get rid of the ifdef'ry in the code.
Sign
Claudio Fontana writes:
> avoid open coding the accesses to cpu->accel_cpu interfaces,
> and instead introduce:
>
> accel_cpu_instance_init,
> accel_cpu_realizefn
>
> to be used by the targets/ initfn code,
> and by cpu_exec_realizefn respectively.
>
> Signed-off-by: Claudio Fontana
Reviewed-
Claudio Fontana writes:
> the lack of target_user_arch makes it hard to fully leverage the
> build system in order to separate user code from softmmu code.
>
> Provide it, so that we can avoid the proliferation of #ifdef
> in target code.
>
> Signed-off-by: Claudio Fontana
Reviewed-by: Alex B
Claudio Fontana writes:
> Looking forward to your comments on this proposal,
>
So I've reviewed as much as I'm comfortable with - I'm going to defer to
the x86 experts on the split of stuff for x86. However from my point of
view I think it's a nice step in improving modularity and reducing t
Am 13.01.2021 um 15:15 hat Stefan Hajnoczi geschrieben:
> On Wed, Jan 13, 2021 at 01:51:17PM +0100, BALATON Zoltan wrote:
> > On Wed, 13 Jan 2021, Stefan Hajnoczi wrote:
> > > On Tue, Jan 12, 2021 at 09:44:03PM +0100, BALATON Zoltan wrote:
> > > > On Tue, 12 Jan 2021, Stefan Hajnoczi wrote:
> > > >
On Mon, Feb 15, 2021 at 12:32:24PM +0100, Peter Lieven wrote:
> Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:
> > On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
> > > even luminous (version 12.2) is unmaintained for over 3 years now.
> > > Bump the requirement to get rid of the if
On 2/14/21 6:59 PM, Philippe Mathieu-Daudé wrote:
> Add a job to build the Gentoo based MIPS R5900 cross-toolchain image.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> .gitlab-ci.d/containers.yml | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/.gitlab-ci.d/containers.yml b/.
Am 15.02.21 um 12:41 schrieb Daniel P. Berrangé:
On Mon, Feb 15, 2021 at 12:32:24PM +0100, Peter Lieven wrote:
Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:
On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
even luminous (version 12.2) is unmaintained for over 3 years now.
Bump
Am 15.02.21 um 11:20 schrieb Kevin Wolf:
Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:
Signed-off-by: Peter Lieven
---
block/rbd.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/block/rbd.c b/block/rbd.c
index f68ebcf240..7abd0252c9 100644
--- a/b
On 2/15/21 12:37 PM, Alex Bennée wrote:
>
> Claudio Fontana writes:
>
>
>> Looking forward to your comments on this proposal,
>>
>
>
> So I've reviewed as much as I'm comfortable with - I'm going to defer to
> the x86 experts on the split of stuff for x86. However from my point of
> view I th
On Mon, Feb 15, 2021 at 12:45:01PM +0100, Peter Lieven wrote:
> Am 15.02.21 um 12:41 schrieb Daniel P. Berrangé:
> > On Mon, Feb 15, 2021 at 12:32:24PM +0100, Peter Lieven wrote:
> > > Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:
> > > > On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wr
On 2/12/21 1:36 PM, Claudio Fontana wrote:
> smm is only really useful for softmmu, split in two modules
> around the CONFIG_USER_ONLY, in order to remove the ifdef
> and use the build system instead.
>
> Signed-off-by: Claudio Fontana
> ---
> target/i386/helper.h | 4
This patchseries implements a new board model in the mps2/mps3 family,
based on Application Note AN524:
https://developer.arm.com/documentation/dai0524/latest/
v1->v2 changes (very minor):
* renamed have-switches to has_switches
* added missing initializations of num_leds and has_switches
for
Currently the MPS2 SCC device implements a fixed number of OSCCLK
values (3). The variant of this device in the MPS3 AN524 board has 6
OSCCLK values. Switch to using a PROP_ARRAY, which allows board code
to specify how large the OSCCLK array should be as well as its
values.
With a variable-lengt
We were previously using the default OSCCLK settings, which are
correct for the older MPS2 boards (mps2-an385, mps2-an386,
mps2-an500, mps2-an511), but wrong for the mps2-an505 and mps2-511
implemented in mps2-tz.c. Now we're setting the values explicitly we
can fix them to be correct.
Signed-off
The AN524 version of the SCC interface has different behaviour for
some of the CFG registers; implement it.
Each board in this family can have minor differences in the meaning
of the CFG registers, so rather than trying to specify all the
possible semantics via individual device properties, we mak
The AN524 has a different SYSCLK frequency from the AN505 and AN521;
make the SYSCLK frequency a field in the MPS2TZMachineClass rather
than a compile-time constant so we can support the AN524.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/mps2-tz.c | 10 ++
The MPS2 board has 2 LEDs, but the MPS3 board has 10 LEDs. The
FPGAIO device is similar on both sets of boards, but the LED0
register has correspondingly more bits that have an effect. Add a
device property for number of LEDs.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
--
The AN505 and AN511 happen to share the same OSCCLK values, but the
AN524 will have a different set (and more of them), so split the
settings out to be per-board.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/mps2-tz.c | 23 ++-
1 file changed,
The AN505 and AN521 don't have any read-only memory, but the AN524
does; add a flag to ROMInfo to mark a region as ROM.
Signed-off-by: Peter Maydell
---
hw/arm/mps2-tz.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 08dd2cbaa40..cc9d70ece54 1
Set the FPGAIO num-leds and have-switches properties explicitly
per-board, rather than relying on the defaults. The AN505 and AN521
both have the same settings as the default values, but the AN524 will
be different.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/mp
The mps2-tz code uses PPCPortInfo data structures to define what
devices are present and how they are wired up. Currently we use
these to specify device types and addresses, but hard-code the
interrupt line wiring in each make_* helper function. This works for
the two boards we have at the moment
MPS3 boards have an extra SWITCH register in the FPGAIO block which
reports the value of some switches. Implement this, governed by a
property the board code can use to specify whether whether it exists.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
include/hw/misc/mps2-
Add support for the mps3-an524 board; this is an SSE-200 based FPGA
image, like the existing mps2-an521. It has a usefully larger amount
of RAM, and a PL031 RTC, as well as some more minor differences.
In real hardware this image runs on a newer generation of the FPGA
board, the MPS3 rather than
In the mps2-tz board code, we handle devices whose interrupt lines
must be wired to all CPUs by creating IRQ splitter devices for the
AN521, because it has 2 CPUs, but wiring the device IRQ directly to
the SSE/IoTKit input for the AN505, which has only 1 CPU.
We can avoid making an explicit check
We create an OR gate to wire together the overflow IRQs for all the
UARTs on the board; this has to have twice the number of inputs as
there are UARTs, since each UART feeds it a TX overflow and an RX
overflow interrupt line. Replace the hardcoded '10' with a
calculation based on the size of the u
Move the specification of the IRQ information for the uart, ethernet,
dma and spi devices to the data structures. (The other devices
handled by the PPCPortInfo structures don't have any interrupt lines
we need to wire up.)
Signed-off-by: Peter Maydell
---
hw/arm/mps2-tz.c | 52 +
The AN524 has more interrupt lines than the AN505 and AN521; make
numirq board-specific rather than a compile-time constant.
Since the difference is small (92 on the current boards and 95 on the
new one) we don't dynamically allocate the cpu_irq_splitter[] array
but leave it as a fixed length arra
Update old infocenter.arm.com URLs to the equivalent developer.arm.com
ones (the old URLs should redirect, but we might as well avoid the
redirection notice, and the new URLs are pleasantly shorter).
This commit covers the links to the MPS2 board TRM, the various
Application Notes, the IoTKit and
The AN505 and AN521 have the same device layout, but the AN524 is
somewhat different. Allow for more than one PPCInfo array, which can
be selected based on the board type.
Signed-off-by: Peter Maydell
---
We can't just put the arrays at file-scope and set up pointers
to them in the MPS2TZMachine
On the MPS2 boards, the first 32 interrupt lines are entirely
internal to the SSE; interrupt lines for devices outside the SSE
start at 32. In the application notes that document each FPGA image,
the interrupt wiring is documented from the point of view of the CPU,
so '0' is the first of the SSE's
The armv7m_load_kernel() function takes a mem_size argument which it
expects to be the size of the memory region at guest address 0. (It
uses this argument only as a limit on how large a raw image file it
can load at address zero).
Instead of hardcoding this value, find the RAMInfo corresponding
Hi,
On 11/30/20 9:36 AM, Gan Qixin wrote:
> Some Spitz-family devices have no category, put them into the correct
> category.
>
> Signed-off-by: Gan Qixin
> ---
> Cc: Peter Maydell
> ---
> hw/arm/spitz.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/arm/spitz.c b/hw/arm/spitz
The AN505 and AN521 have the same layout of RAM; the AN524 does not.
Replace the current hard-coding of where the RAM is and which parts
of it are behind which MPCs with a data-driven approach.
Signed-off-by: Peter Maydell
---
hw/arm/mps2-tz.c | 175 +-
The AN524 has a PL031 RTC, which we have a model of; provide it
rather than an unimplemented-device stub.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/mps2-tz.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/hw/arm/mps2
On 2/12/21 1:36 PM, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana
> ---
> target/i386/helper.h | 7 +
> target/i386/tcg/helper-tcg.h | 3 +
> target/i386/tcg/bpt_helper.c | 276 -
> target/i386/tcg/softmmu/bpt_helper.c | 293 ++
Instead of hardcoding the MachineClass default_ram_size and
default_ram_id fields, set them on class creation by finding the
entry in the RAMInfo array which is marked as being the QEMU system
RAM.
Signed-off-by: Peter Maydell
---
hw/arm/mps2-tz.c | 24 ++--
1 file changed, 2
On Mon, Feb 15, 2021 at 12:42:50PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/14/21 6:59 PM, Philippe Mathieu-Daudé wrote:
> > Add a job to build the Gentoo based MIPS R5900 cross-toolchain image.
> >
> > Signed-off-by: Philippe Mathieu-Daudé
> > ---
> > .gitlab-ci.d/containers.yml | 7 +++
1 - 100 of 427 matches
Mail list logo
