In arch/arm/mach-realview/realview_*.c pl061_platform_data irq_base
members are statically (default) initialised to 0 (whereas for versatile
they are explicitly set via defines in the platform headers).
In pl061_probe, -ENODEV is returned for irq_base <= 0.
Changing this to < 0, results in irq_do
confirmed - not a bug, patching the kernel fixes the problem.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1409246
Title:
ARM GIC / PL061 error o
now I look further I notice that the pl061_platform_data structures are
not fully initialised in the kernel
linux-3.18.1/arch/arm/mach-realview/realview_pba8.c
so this probably isn't a qemu bug
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
** Attachment added: "QEmu command line / boot log"
https://bugs.launchpad.net/qemu/+bug/1409246/+attachment/4295187/+files/qemu-console-boot.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1409
Public bug reported:
chorler@linux-foxtrot:~/projects/src/qemu> git describe
v2.2.0-369-gab0302e
When booting Linux 3.19.1 (default buildroot), configured for realview-
pb-a8 on qemu from git (as above).
The following message appears (line 253/ 254 of attached log):
"GIC CPU mask not found - ker
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1316115
Title:
linux-user qemu-arm NEON support
Status in QEMU:
Invalid
Bug description:
I was
I didn't test it on real hardware yet - but I resolved the issue and
found the root cause last night:
This perhaps should have been more obvious to me in the beginning, but "readelf
-l" shows a program header similar to this:
INTERP 0x00394600 0x00394600 0x003946
I built Qt5 myself, and tested and it crashed again.
I think the entry point getting set in the ELF header is probably
invalid and leading to the crash - I'm going to try and fix that - but
it's almost certainly not a qemu bug.
I suggest closing the bug report.
--
You received this bug notifica
Now I look at the two sets of architecture specific information for the
two versions of the library it's almost certain this has nothing to do
with NEON.
I'll build a version of Qt5 of my own to test, if that works then from
my perspective it's not a qemu bug.
--
You received this bug notificati
> Are you trying to execute a DLL on purpose?
Yes - it's executable and should print out something like this (this
from my host system):
chorler@linux-foxtrot:~> /usr/lib64/libQt5Core.so.5
This is the QtCore library version 5.1.1
Copyright (C) 2013 Digia Plc and/or its subsidiary(-ies).
Contact:
Public bug reported:
I was reading the mailing list and saw NEON support in QEmu was making
progress.
Is it not supported in user mode? or am I running into something else
here? (I've tried to include some what may be useful information)
using qemu from git (last commits as below):
fdaad47 Mer
11 matches
Mail list logo
