On 08/08/2012 04:16 PM, Alexander Graf wrote:
>
> On 24.06.2012, at 01:07, Alexander Graf wrote:
>
>> Due to popular demand, we're updating the way we generate the MPIC
>> node and interrupt lines based on what the current state of art is.
>>
>> Requ
On 08/09/2012 03:48 PM, Alexander Graf wrote:
>
> On 09.08.2012, at 00:40, Scott Wood wrote:
>
>> On 08/08/2012 04:16 PM, Alexander Graf wrote:
>>>
>>> On 24.06.2012, at 01:07, Alexander Graf wrote:
>>>
>>>> Due to popular demand, we&
On 08/09/2012 03:52 PM, Alexander Graf wrote:
>
> On 09.08.2012, at 22:50, Scott Wood wrote:
>
>> On 08/09/2012 03:48 PM, Alexander Graf wrote:
>>>
>>> On 09.08.2012, at 00:40, Scott Wood wrote:
>>>
>>>> On 08/08/2012 04:16 PM, Alexander Graf
On 08/09/2012 04:01 PM, Alexander Graf wrote:
>
> On 09.08.2012, at 22:58, Scott Wood wrote:
>
>> On 08/09/2012 03:52 PM, Alexander Graf wrote:
>>>
>>> On 09.08.2012, at 22:50, Scott Wood wrote:
>>>
>>>> On 08/09/2012 03:48 PM, Alexander
On 08/09/2012 04:19 PM, Alexander Graf wrote:
>
> On 09.08.2012, at 23:11, Scott Wood wrote:
>
>> On 08/09/2012 04:01 PM, Alexander Graf wrote:
>>>
>>> On 09.08.2012, at 22:58, Scott Wood wrote:
>>>> Additionally, we should consider adding extra co
On 08/09/2012 04:36 PM, Alexander Graf wrote:
>
> On 09.08.2012, at 23:28, Scott Wood wrote:
>
>> On 08/09/2012 04:19 PM, Alexander Graf wrote:
>>>
>>> On 09.08.2012, at 23:11, Scott Wood wrote:
>>>> ...so that we can run new kernels on old QEMUs, no
On 08/14/2012 07:50 AM, Bharat Bhushan wrote:
> PCI Root complex have TYPE-1 configuration header while PCI endpoint
> have type-0 configuration header. The type-1 configuration header have
> a BAR (BAR0). In Freescale PCI controller BAR0 is used for mapping pci
> address space to CCSR address spac
e the
actual BSS size. Increase the allowance to 18 MiB to give us plenty of
room. Eventually this should be more intelligent, possibly packing
initrd+dtb at the end of guest RAM.
Signed-off-by: Scott Wood
---
hw/ppc/e500.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/h
While investigating dtb pad issues, I noticed that initrd_base wasn't taking
loadaddr into account the way dt_base was. This seems wrong.
Signed-off-by: Scott Wood
---
hw/ppc/e500.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
On 01/20/2012 08:43 PM, Alexander Graf wrote:
>
>
> Am 20.01.2012 um 21:01 schrieb Scott Wood :
>> I'm not sure what happens when you write
>> an entry to TLB1 with an invalid TSIZE.
>
> What it says, the ISA means it's implementation dependent. Wha
On 01/20/2012 10:15 PM, Alexander Graf wrote:
> +/* returns bitmap of supported page sizes for a given TLB */
> +static inline uint32_t booke206_tlbnps(CPUState *env, const int tlbn)
> +{
> +bool mav2 = false;
> +uint32_t ret = 0;
> +
> +if (mav2) {
> +ret = env->spr[SPR_BOOKE_T
On 01/20/2012 10:15 PM, Alexander Graf wrote:
> @@ -4273,6 +4274,16 @@ void helper_booke206_tlbwe(void)
> tlb->mas1 &= ~MAS1_IPROT;
> }
>
> +/* check that we support the targeted size */
> +size_tlb = (tlb->mas1 & MAS1_TSIZE_MASK) >> MAS1_TSIZE_SHIFT;
> +size_ps = booke2
On 01/23/2012 11:33 AM, Alexander Graf wrote:
> On 01/23/2012 06:32 PM, Scott Wood wrote:
>> On 01/20/2012 10:15 PM, Alexander Graf wrote:
>>> @@ -4273,6 +4274,16 @@ void helper_booke206_tlbwe(void)
>>> tlb->mas1&= ~MAS1_IPROT;
>>>
On 01/23/2012 12:41 PM, Alexander Graf wrote:
>>> For tlb0 on e500 and derivatives, tsize is explicitly documented as
>>> ignored. Software may rely on this.
>> Yup, that's why there's the check for TLBnCG_AVAIL, which indicates that
>> a TLB has dynamic page size capabilities, which TLB0 does not
On 01/23/2012 02:03 PM, Alexander Graf wrote:
>
>
> On 23.01.2012, at 19:49, Scott Wood wrote:
>
>> On 01/23/2012 12:41 PM, Alexander Graf wrote:
>>>>> For tlb0 on e500 and derivatives, tsize is explicitly documented as
>>>>> ignored. Softwar
On 01/23/2012 03:29 PM, Alexander Graf wrote:
>
>
> On 23.01.2012, at 21:10, Scott Wood wrote:
>
>> If TLB0 has TLBnCFG[AVAIL] set, then with this patch you'll be raising
>> an exception rather than setting the size to the minimum.
>>
>> If TLB0 do
On 01/24/2012 12:23 PM, Stefan Weil wrote:
> I'd prefer a different solution. As far as I have understood,
> the dtb is only useful with a kernel, so it could be handled
> as an optional attribute to the -kernel parameter:
>
> -kernel IMAGE[,dtb=DTB]
>
> Of course the same applies to -append,
On 02/03/2012 04:52 PM, Anthony Liguori wrote:
> On 02/03/2012 12:07 PM, Eric Northup wrote:
>> On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivity wrote:
>> [...]
>>>
>>> Moving to syscalls avoids these problems, but introduces new ones:
>>>
>>> - adding new syscalls is generally frowned upon, and kvm wil
On 02/07/2012 06:28 AM, Anthony Liguori wrote:
> On 02/06/2012 01:46 PM, Scott Wood wrote:
>> On 02/03/2012 04:52 PM, Anthony Liguori wrote:
>>> On 02/03/2012 12:07 PM, Eric Northup wrote:
>>>> How would the ability to use sys_kvm_* be regulated?
>>>
>&
On 02/07/2012 04:57 PM, Alexander Graf wrote:
>
> On 07.02.2012, at 23:29, Brad Smith wrote:
>
>> On 07/02/12 5:12 PM, malc wrote:
>>> On Tue, 7 Feb 2012, Alexander Graf wrote:
>>>
On 07.02.2012, at 22:12, malc wrote:
> On Tue, 7 Feb 2012, Alexander Graf wrote:
>
>>
>>>
On 02/08/2012 05:42 PM, Alexander Graf wrote:
>
> On 09.02.2012, at 00:29, Scott Wood wrote:
>
>> On 02/07/2012 04:57 PM, Alexander Graf wrote:
>>> Eh, this patch:
>>>
>>> diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
>>> index f5d
On 02/15/2012 05:57 AM, Alexander Graf wrote:
>
> On 15.02.2012, at 12:18, Avi Kivity wrote:
>
>> Well the real reason is we have an extra bit reported by page faults
>> that we can control. Can't you set up a hashed pte that is configured
>> in a way that it will fault, no matter what type of a
On 02/16/2012 01:38 PM, Avi Kivity wrote:
> On 02/16/2012 09:34 PM, Alexander Graf wrote:
>> On 16.02.2012, at 20:24, Avi Kivity wrote:
>>
>>> On 02/15/2012 04:08 PM, Alexander Graf wrote:
>
> Well, the scatter/gather registers I proposed will give you just one
> register or all of them
On 02/16/2012 06:23 PM, Alexander Graf wrote:
> On 16.02.2012, at 21:41, Scott Wood wrote:
>> And yes, we do have fancier hardware coming fairly soon for which this
>> breaks (TLB0 entries can be loaded without host involvement, as long as
>> there's a translation from
area seems to be in line with what
other backends do from the couple I looked at (x86, ppc).
Signed-off-by: Scott Wood
---
tcg/tci/tcg-target.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tcg/tci/tcg-target.c b/tcg/tci/tcg-target.c
index 453f187..3c6b0f5 100644
--- a
On 06/19/2012 12:53 AM, Stefan Weil wrote:
> Am 19.06.2012 04:31, schrieb Scott Wood:
>> If tci_out_label is called in the context of tcg_gen_code_search_pc, we
>> could be overwriting an already patched relocation with zero -- and not
>> repatch it because the set_label is pa
On 06/20/2012 03:11 PM, Alexander Graf wrote:
> +/* XXX better abstract into Emb.xxx features */
> +if (version == fsl_e5500) {
> +spr_register(env, SPR_BOOKE_EPCR, "EPCR",
> + SPR_NOACCESS, SPR_NOACCESS,
> + &spr_read_generic, &spr_write_gene
On 06/20/2012 05:59 PM, Alexander Graf wrote:
>
> On 21.06.2012, at 00:26, Scott Wood wrote:
>
>> On 06/20/2012 03:11 PM, Alexander Graf wrote:
>>> +/* XXX better abstract into Emb.xxx features */
>>> +if (version == fsl_e5500) {
>>> +
On 06/20/2012 06:10 PM, Alexander Graf wrote:
>
> On 21.06.2012, at 01:07, Scott Wood wrote:
>
>> On 06/20/2012 05:59 PM, Alexander Graf wrote:
>>>
>>> On 21.06.2012, at 00:26, Scott Wood wrote:
>>>
>>>> On 06/20/2012 03:11 PM, Alexander Graf
On 06/21/2012 08:33 AM, Alexander Graf wrote:
> The MAS registers on BookE are all 32 bit wide, except for MAS2, which
> can hold up to 64 bit on 64 bit capable CPUs. Reflect this in the SPR
> setting code, so that the guest can never write invalid values in them.
>
> Signed-off-by: Alexander Graf
No functional changes -- machine is still outwardly mpc8544ds.
The references that are not changed contain mpc8544 hardware details that
need to be parameterized if/when a different e500 platform wants to
change them.
Signed-off-by: Scott Wood
---
hw/ppc/e500.c | 27
Rename the file (with no changes other than fixing up the header paths)
in preparation for refactoring into a generic e500 platform. Also move
it into the newly created ppc/ directory.
Signed-off-by: Scott Wood
---
hw/ppc/Makefile.objs |2 +-
hw/{ppce500_mpc8544ds.c
: Scott Wood
---
hw/ppc/Makefile.objs |3 +-
hw/ppc/e500plat.c| 60 ++
2 files changed, 62 insertions(+), 1 deletions(-)
create mode 100644 hw/ppc/e500plat.c
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 23eb8ca..58d82c9
generic e500 backend isn't
very generic yet), but additional refactoring should happen in the
future.
Scott Wood (4):
PPC: e500: rename mpc8544ds into generic file
PPC: e500: change internal references away from mpc8544ds
PPC: e500: split mpc8544ds machine from generic e500 code
PPC:
From: Scott Wood
Currently the only mpc8544ds-ism that is factored out is
toplevel compatible and model. In the future the generic e500
code is expected to become more generic.
Signed-off-by: Scott Wood
---
Patch 3/4 of the series didn't make it to the list archives or patchwork
de
On 07/02/2012 11:33 AM, Stuart Yoder wrote:
> On Wed, Jun 27, 2012 at 6:51 PM, Scott Wood wrote:
>> +static QEMUMachine e500plat_machine = {
>> +.name = "e500plat",
>> +.desc = "e500plat",
>> +.init = e500plat_init,
>> +.ma
On 07/02/2012 11:50 AM, Andreas Färber wrote:
> Hi Scott,
>
> Am 28.06.2012 01:50, schrieb Scott Wood:
>> Rename the file (with no changes other than fixing up the header paths)
>> in preparation for refactoring into a generic e500 platform. Also move
>> it into the n
On 07/02/2012 12:06 PM, Scott Wood wrote:
> On 07/02/2012 11:50 AM, Andreas Färber wrote:
>> Hi Scott,
>>
>> Am 28.06.2012 01:50, schrieb Scott Wood:
>>> Rename the file (with no changes other than fixing up the header paths)
>>> in preparation for refactor
On 07/02/2012 03:58 PM, Andreas Färber wrote:
> Am 02.07.2012 22:32, schrieb Scott Wood:
>> On 07/02/2012 12:06 PM, Scott Wood wrote:
>>> On 07/02/2012 11:50 AM, Andreas Färber wrote:
>>>> Am 28.06.2012 01:50, schrieb Scott Wood:
>>>>> hw/ppc/Makefi
On 07/02/2012 04:08 PM, Alexander Graf wrote:
>
> On 02.07.2012, at 23:07, Scott Wood wrote:
>
>> On 07/02/2012 03:58 PM, Andreas Färber wrote:
>>> Am 02.07.2012 22:32, schrieb Scott Wood:
>>>> On 07/02/2012 12:06 PM, Scott Wood wrote:
>>>&g
On 07/02/2012 04:17 PM, Alexander Graf wrote:
>
> On 02.07.2012, at 23:16, Scott Wood wrote:
>
>> On 07/02/2012 04:08 PM, Alexander Graf wrote:
>>>
>>> On 02.07.2012, at 23:07, Scott Wood wrote:
>>>
>>>> How is hw/ppc/e500.o better t
subplatforms is toplevel
compatible and model in the device tree (the generic e500 backend isn't
very generic yet), but additional refactoring should happen in the
future.
Scott Wood (4):
PPC: e500: rename mpc8544ds into generic file
PPC: e500: change internal references away from mpc8544ds
PPC:
Rename the file (with no changes other than fixing up the header paths)
in preparation for refactoring into a generic e500 platform. Also move
it into the newly created ppc/ directory.
Signed-off-by: Scott Wood
---
v2: Use the right part of the makefile for hw/ppc files
hw/ppc/Makefile.objs
: Scott Wood
---
v2:
- Use the right part of the makefile for hw/ppc files
- Update platform name to ppce500
- Provide a proper platform description
hw/ppc/Makefile.objs |3 +-
hw/ppc/e500plat.c| 60 ++
2 files changed, 61 insertions
Currently the only mpc8544ds-ism that is factored out is
toplevel compatible and model. In the future the generic e500
code is expected to become more generic.
Signed-off-by: Scott Wood
---
v2: Use the right part of the makefile for hw/ppc files
hw/ppc/Makefile.objs |3 +-
hw/ppc/e500.c
No functional changes -- machine is still outwardly mpc8544ds.
The references that are not changed contain mpc8544 hardware details that
need to be parameterized if/when a different e500 platform wants to
change them.
Signed-off-by: Scott Wood
---
v2: no changes
hw/ppc/e500.c | 27
On 07/03/2012 02:45 PM, Alexander Graf wrote:
>
> On 03.07.2012, at 07:07, Eli Lewis wrote:
>
>>>
>>
Maybe
we can change the BSP of POK in order to support the MPC8544DS board.
>>>
>>> It's not only the board. Kernel mode is vastly different from the 601
>>> you're probably targeting t
ut the dependency on
CONFIG_FDT was accidentally dropped. This broke the build when FDT
support is not enabled.
Signed-off-by: Scott Wood
---
hw/ppc/Makefile.objs |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 8
On 07/09/2012 09:07 AM, Andreas Färber wrote:
> Am 09.07.2012 16:04, schrieb Scott Wood:
>> Recent patches "PPC: e500: rename mpc8544ds into generic file", "PPC:
>> e500: split mpc8544ds machine from generic e500 code", and "PPC: e500:
>> add generic e
On 07/10/2012 12:51 AM, Alexey Kardashevskiy wrote:
> The patch enables VFIO on POWER.
>
> It literally does the following:
>
> 1. POWERPC IOMMU support (the kernel counterpart is required)
[snip]
> +/* API for POWERPC IOMMU */
> +
> +#define POWERPC_IOMMU 2
> +
> +str
On 12/10/2012 05:34:19 PM, Scott Wood wrote:
On 12/08/2012 07:44:25 AM, Alexander Graf wrote:
/* Interrupt definitions */
-#define MPIC_EXT_IRQ 0
-#define MPIC_INT_IRQ (MPIC_EXT_IRQ + MPIC_MAX_EXT)
-#define MPIC_TMR_IRQ (MPIC_INT_IRQ + MPIC_MAX_INT)
-#define MPIC_MSG_IRQ
On 12/08/2012 07:44:33 AM, Alexander Graf wrote:
The openpic source irqs are carrying around a type indicator that
is never accessed by anything. Remove it.
Signed-off-by: Alexander Graf
---
hw/openpic.c | 27 ++-
1 files changed, 2 insertions(+), 25 deletions(-)
dif
On 12/08/2012 07:44:25 AM, Alexander Graf wrote:
MPIC interrupt numbers in Linux (device tree) and in QEMU are
different,
because QEMU takes the sparseness of the IRQ number space into
account.
Remove that cleverness and instead assume a flat number space. This
makes
the code easier to und
On 12/08/2012 07:44:37 AM, Alexander Graf wrote:
This patch converts the OpenPIC device to qdev. Along the way it
renames the "openpic" target to "raven" and the "mpic" target to
"mpc8544", to better reflect the actual models they implement.
This way we have a generic OpenPIC device now that can
On 12/08/2012 07:44:39 AM, Alexander Graf wrote:
The OpenPIC allows MSI access through shared MSI registers. Implement
them for the MPC8544 MPIC, so we can support MSIs.
Signed-off-by: Alexander Graf
---
hw/openpic.c | 150
++
1 files
On 12/11/2012 02:10:14 AM, Alexander Graf wrote:
On 11.12.2012, at 01:36, Scott Wood wrote:
> On 12/08/2012 07:44:39 AM, Alexander Graf wrote:
>> The OpenPIC allows MSI access through shared MSI registers.
Implement
>> them for the MPC8544 MPIC, so we can support MSIs.
&
On 12/11/2012 02:14:42 AM, Alexander Graf wrote:
On 11.12.2012, at 00:34, Scott Wood wrote:
> On 12/08/2012 07:44:25 AM, Alexander Graf wrote:
>> +/* These are available through separate regions, but
>> + for simplicity's sake mapped into the same number space */
>
On 12/11/2012 02:25:31 AM, Alexander Graf wrote:
On 11.12.2012, at 00:47, Scott Wood wrote:
> On 12/08/2012 07:44:37 AM, Alexander Graf wrote:
>> This patch converts the OpenPIC device to qdev. Along the way it
>> renames the "openpic" target to "raven" a
On 12/11/2012 06:56:56 PM, Alexander Graf wrote:
On 11.12.2012, at 18:47, Scott Wood wrote:
> On 12/11/2012 02:25:31 AM, Alexander Graf wrote:
>> If we want a pv style generic mpic (for -M e500), let's add such
an mpic to the model list and make that one be really generic. But
On 12/11/2012 06:53:44 PM, Alexander Graf wrote:
On 11.12.2012, at 18:35, Scott Wood wrote:
> On 12/11/2012 02:10:14 AM, Alexander Graf wrote:
>> On 11.12.2012, at 01:36, Scott Wood
wrote:
>> > On 12/08/2012 07:44:39 AM, Alexander Graf wrote:
>> >> The Ope
QEMU is sometimes used in embedded contexts, where graphical support
is unnecessary. The ability to turn off graphics support not only
saves some space, but it eliminates the dependency on pixman.
Signed-off-by: Scott Wood
---
There are undoubtedly some rough edges that need to be cleaned up
On 12/12/2012 08:09:56 AM, Alexander Graf wrote:
Today we're hardcoding the PCI interrupt map in the e500 machine file.
Instead, let's write it dynamically so that different machine types
can have different slot properties.
Signed-off-by: Alexander Graf
---
hw/ppc/e500.c | 51
+
On 12/12/2012 05:38:32 PM, Alexander Graf wrote:
On 12.12.2012, at 19:40, Scott Wood wrote:
> On 12/12/2012 08:09:56 AM, Alexander Graf wrote:
>> +for (slot = first_slot; slot < last_slot; slot++) {
>> +for (pci_irq = 0; pci_irq < 4; pci_irq++) {
>
On 12/12/2012 06:04:11 PM, Alexander Graf wrote:
On 13.12.2012, at 00:43, Scott Wood wrote:
> On 12/12/2012 05:38:32 PM, Alexander Graf wrote:
>> On 12.12.2012, at 19:40, Scott Wood wrote:
>> > On 12/12/2012 08:09:56 AM, Alexander Graf wrote:
>> >> +for (slot
On 12/12/2012 06:28:02 PM, Alexander Graf wrote:
On 13.12.2012, at 01:20, Scott Wood wrote:
> On 12/12/2012 06:04:11 PM, Alexander Graf wrote:
>> We could call bus->map_irq(...) with an artificially created
PCIDevice struct ;). But that's pretty hacky.
>
> If we do
On 12/12/2012 12:46:44 AM, Stefan Weil wrote:
Am 12.12.2012 04:18, schrieb Scott Wood:
QEMU is sometimes used in embedded contexts, where graphical support
is unnecessary. The ability to turn off graphics support not only
saves some space, but it eliminates the dependency on pixman.
Signed
On 12/12/2012 10:47:04 AM, Peter Maydell wrote:
On 12 December 2012 03:18, Scott Wood wrote:
> QEMU is sometimes used in embedded contexts, where graphical support
> is unnecessary. The ability to turn off graphics support not only
> saves some space, but it eliminates the dependency
On 12/12/2012 10:54:04 AM, Andreas Färber wrote:
Am 12.12.2012 17:28, schrieb John Spencer:
> On 12/12/2012 04:18 AM, Scott Wood wrote:
>> QEMU is sometimes used in embedded contexts, where graphical
support
>> is unnecessary. The ability to turn off graphics support not onl
On 12/12/2012 01:52:29 AM, Gerd Hoffmann wrote:
On 12/12/12 04:18, Scott Wood wrote:
> QEMU is sometimes used in embedded contexts, where graphical support
> is unnecessary. The ability to turn off graphics support not only
> saves some space, but it eliminates the dependency on pi
On 12/13/2012 12:31:14 AM, Stefan Weil wrote:
Am 13.12.2012 01:48, schrieb Scott Wood:
It doesn't seem to like my --cross-prefix being a full path rather
than being a recognized target pattern:
checking host system type... Invalid configuration
`/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.
On 12/13/2012 09:16:58 AM, Gerd Hoffmann wrote:
Hi,
>> A pretty central data structure in qemu (DisplayState /
>> DisplaySurface) carries a pixman image, not some module which can
>> easily be made optional. Just look at the tons of #ifdef'ery you
>> have to do to get this going.
>
> His poin
On 12/13/2012 12:58:19 PM, Stefan Weil wrote:
Am 13.12.2012 16:53, schrieb Scott Wood:
On 12/13/2012 12:31:14 AM, Stefan Weil wrote:
Indeed, --cross-prefixdoes not support absolute path names.
I assume that the executables in
/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu
On 12/13/2012 01:16:48 PM, Scott Wood wrote:
On 12/13/2012 12:58:19 PM, Stefan Weil wrote:
A cross prefix which starts with an absolute path (like in your
scenario) justs
requires adding `dirname "${cross_prefix}"` to PATH and passing
`basename "${cross_prefix%-}" to
"opp->nb_irqs-1" would have been a minor coding style error,
but putting in one space but not the other makes it look
confusingly like a numeric literal "-1".
Signed-off-by: Scott Wood
---
hw/openpic.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
the symbolic name. I looked at
Freescale and IBM MPIC docs and at the base OpenPIC spec, and all three
had priority as 4 bits rather than 5. Plus, the magic nubmer that is
being replaced with symbolic values treated the field as 4 bits wide.
Signed-off-by: Scott Wood
---
hw/open
Previously only the spurious vector was sized appropriately
to the openpic model.
Also, instances of "IPVP_VECTOR(opp->spve)" were replace with
just "opp->spve", as opp->spve is already just a vector and not
an IVPR.
Signed-off-by: Scott Wood
---
hw/openpic.c |
There'll be more to come, but here's an initial set of cleanups
and fixes for openpic.
This is based on the ppc-mpic-cleanup branch in
git://repo.or.cz/qemu/agraf.git
Scott Wood (6):
openpic: symbolicize some magic numbers
openpic: remove pcsr (CPU sensitivity register)
openpi
o read the register on the QEMU command line with "xp".
Signed-off-by: Scott Wood
---
hw/openpic.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index c57a168..c0c4307 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -580,6 +580,
I could not find this register in any spec (FSL, IBM, or OpenPIC)
and the code doesn't do anything with it but initialize, save,
or restore it.
Signed-off-by: Scott Wood
---
hw/openpic.c |4
1 file changed, 4 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index 7e72c29..57
If we access a register via the QEMU memory inspection commands (e.g.
"xp") rather than from guest code, we won't have a CPU context.
Gracefully fail to access the register in that case, rather than
crashing.
Signed-off-by: Scott Wood
---
hw/openpic.c | 16 +++-
1 f
On 12/14/2012 06:35:12 AM, Alexander Graf wrote:
On 14.12.2012, at 03:12, Scott Wood wrote:
> If we access a register via the QEMU memory inspection commands
(e.g.
> "xp") rather than from guest code, we won't have a CPU context.
> Gracefully fail to access the regis
On 12/14/2012 02:07:23 AM, Gerd Hoffmann wrote:
Hi,
> No, they are with prefix, just not in $PATH. I have more than one
> "powerpc-linux-gnu" toolchain and I don't want to mess with my $PATH
> constantly to choose between them.
# ls -l /usr/bin/*-gcc
-rwxr-xr-x. 2 root root 264112 Aug 23 201
On 12/14/2012 02:13:53 AM, Gerd Hoffmann wrote:
Hi,
> Yes, I could manually install it, though then I get to deal with
telling
> the pixman build exactly where to install itself, and repeating the
> process for each toolchain and multilib-variant thereof.
That part is easy too. You just n
On 12/14/2012 06:35:12 AM, Alexander Graf wrote:
On 14.12.2012, at 03:12, Scott Wood wrote:
> If we access a register via the QEMU memory inspection commands
(e.g.
> "xp") rather than from guest code, we won't have a CPU context.
> Gracefully fail to access the regis
On 12/19/2012 03:02:13 AM, Gerd Hoffmann wrote:
On 12/14/12 19:51, Scott Wood wrote:
> On 12/14/2012 02:13:53 AM, Gerd Hoffmann wrote:
>> Hi,
>>
>> > Yes, I could manually install it, though then I get to deal with
>> telling
>> > the pixman build exactly
On 12/19/2012 03:13:34 AM, Gerd Hoffmann wrote:
>> ./configure
>>
--cross-prefix=/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-
>>
>> && make ?
>
> A few more options than that, but basically yes.
>
> I can get past this particular obstacle by doing somet
On 12/20/2012 12:59:05 AM, Gerd Hoffmann wrote:
Hi,
>> Why do you need this? Any tools not picked up correctly if you
don't
>> set the PATH? Which ones?
>
> If I don't set the PATH for configure then I get this:
> ERROR: "powerpc-linux-gnu-gcc" either does not exist or does not
work
A
On 12/21/2012 04:56:05 AM, Robert Schiele wrote:
On Fri, Dec 21, 2012 at 9:56 AM, Gerd Hoffmann
wrote:
> I mean with --cross-prefix specifying the absolute location (so you
> don't have to mess with PATH), why does that not work?
He actually wrote already previously: The name is thrown into
c
This will stop things from breaking once it's properly treated as a
level-triggered interrupt. Note that it's the MPIC's MSI cascade
interrupts that are level-triggered; the individual MSIs are
edge-triggered.
Signed-off-by: Scott Wood
---
hw/openpic.c |1 +
1 file chang
Other priorities are signed, so avoid comparisons between
signed and unsigned.
Signed-off-by: Scott Wood
---
hw/openpic.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index 94a7807..9d22e9c 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
Signed-off-by: Scott Wood
---
hw/openpic.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index 9d22e9c..268f312 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -194,6 +194,7 @@ typedef struct IRQ_src_t {
bool level; /* level
e the Freescale abbreviations.
Signed-off-by: Scott Wood
---
BTW, I'm still not sure where the first "P" in QEMU's "IPVP" came from.
---
hw/openpic.c | 362 +-
1 file changed, 181 insertions(+), 181 deletions
he current serialization format was not built for extensibility.
Signed-off-by: Scott Wood
---
hw/openpic.c | 110 --
1 file changed, 76 insertions(+), 34 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index 7647368..94a7807 10064
that's another matter.
Signed-off-by: Scott Wood
---
hw/openpic.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index f2ac286..5accff5 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -270,21 +270,35 @@ static inlin
Previously the code relied on the queue's "next" field getting
set to -1 sometime between an update to the bitmap, and the next
call to IRQ_get_next. Sometimes this happened after the update.
Sometimes it happened before the check. Sometimes it didn't happen
at all.
Signe
Here's another patch of cleanups and fixes, dealing with critical
interrupts, interrupt deassertion, task priority, and other issues.
Scott Wood (15):
openpic: fix debug prints
openpic: lower interrupt when reading the MSI register
openpic: fix sense and priority bits
ppc/booke: fix
evel. FSL timers and IPIs do not have
sense or polarity bits (read as zero), and are edge-triggered. To
accommodate FSL internal interrupts, QEMU's internal notion of whether an
interrupt is level-triggered is separated from the IVPR bit.
Signed-off-by: Scott Wood
---
hw/o
Besides making the code cleaner, we will need a separate way to access
IACK in order to implement EPR (external proxy) interrupt delivery.
Signed-off-by: Scott Wood
---
hw/openpic.c | 95 --
1 file changed, 53 insertions(+), 42 deletions
e we will get faster queue lookups on 64-bit hosts once
we search a word at a time.
Signed-off-by: Scott Wood
---
hw/openpic.c | 55 +--
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index cc3e514..
erformance concerns.
Signed-off-by: Scott Wood
---
hw/openpic.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/hw/openpic.c b/hw/openpic.c
index e2e7079..cc3e514 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -181,7 +181,6 @@ typedef struct IRQ_queue_t {
uint32_t queu
1 - 100 of 456 matches
Mail list logo
