Public bug reported:
When working with QEMU's PCI network card E1000 emulator, I accidentally
put virtual addresses into the memory mapped registers when I should
have put physical addresses. Short story is, the address was too large
for the physical address space so when the network card tried to
Yeah it was. Sorry, should have specified. Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/984476
Title:
"segmentaion" error when DMAing
Status in QEMU:
Confirmed
Bug description:
When
** Changed in: qemu-kvm (Ubuntu Lucid)
Status: New => Confirmed
--
qemu fails to set hdd serial number
https://bugs.launchpad.net/bugs/584143
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: In Progress
Status in “
On 08/20/2012 05:33 PM, Alexander Graf wrote:
> This updates the OpenBIOS binaries for PPC to svn revision 1063,
> fixing -M g3beige with large PCI memory users.
>
> Signed-off-by: Alexander Graf
Tested-by: Rob Landley
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they
uld
synchronously set the VIRTIO_USED_F_NOTIFY bit - the guest could do
this itself, but that'd require giving the guest write access to the
used side of the virtio queue, and I kind of like the idea that it
doesn't need write access there. Then again, I don't have any perf
data to back up the need for this.
The rest of it sounds great.
)Rob
could do this
itself, but that'd require giving the guest write access to the used side
of the virtio queue, and I kind of like the idea that it doesn't need write
access there. Then again, I don't have any perf data to back up the need
for this.
The rest of it sounds great.
)Rob
On Sun, Feb 5, 2012 at 5:14 AM, Avi Kivity wrote:
> On 02/03/2012 12:13 AM, Rob Earhart wrote:
>> On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivity > <mailto:a...@redhat.com>> wrote:
>>
>> The kvm api has been accumulating cruft for several years now.
>>
would go along with those files...
Any hints?
Rob
stood why _using_ virtio serial ports was so different,
but it's been about a year since I looked at them (because they were so
different).
Rob
Reasonably vanilla versions of both just did this. No idea why. Just
did it the once, haven't gotten it to reproduce...
Rob
Restarting system.
reboot: machine restart
general protection fault: fff2 [#1]
CPU 0
Pid: 8542, comm: oneit Not tainted 3.7.0 #1 Bochs Bochs
RIP:
tform is it's hardwired to 64 megs.)
(Sparc32 can handle 256 megs ram but crashes if you feed it too long a
kernel command line.)
Rob
On 03/06/2013 12:34:53 PM, Peter Maydell wrote:
On 6 March 2013 11:59, Rob Landley wrote:
> On 03/05/2013 12:09:27 AM, Peter Maydell wrote:
>> On 5 March 2013 14:07, 陳韋任 (Wei-Ren Chen)
>> wrote:
>> > On Tue, Mar 05, 2013 at 01:40:38PM +0800, Peter Maydell wrote:
>
It's all described at
http://landley.net/aboriginal/about.html
Try this:
wget http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2
tar xvjf system-image-armv5l.tar.bz2
cd system-image.armv5l
./run-emulator.sh
gcc /usr/src/thread-hello2.c -lpthread
./a.out
exit
Thanks,
Rob
ve to get the
discontiguous memory stuff to work, haven't done that yet.)
That's the one I used in Aboriginal Linux arm images.
Rob
nth alone, and August was
feature freeze for the 1.6.0 release. (If it _wasn't_ actively
developed I wouldn't have had to work around a darn IRQ routing issue
on the arm target in the last Aboriginal release...)
Rob
nything to work in 4 megs requires diabling all the
printk strings at compile time. (The last time I saw somebody do a 4
meg system was CELF in 2006. 32 bit x86.)
Look at the uClinux project. Or try to bolt your app onto uboot and run
it on the bare metal.
Rob
tically linked one, due to the extra
translations caused by the relocation fixups.
Rob
On 03/26/2013 02:34:50 AM, Artyom Tarasenko wrote:
On Tue, Mar 26, 2013 at 1:52 AM, Rob Landley wrote:
> Can the virtio things (serial, network, block, virtfs) be used on
arbitrary
> targets yet? I.E. Can I use a virtio network device on arm, mips,
powerpc,
> sparc...
Yes. More
working out more. (I push them upstream when I can, but the maintainers
aren't always interested.)
(Currently the project is migrating from uClibc to musl libc, in part
because I can fish target support out of klibc and apply it to musl in
a way I can't for uClibc, so I can _finally_ get s390 and such to
work... But day job and my other projects eat lots of time so it goes
slowly...)
Rob
On 04/14/2013 04:38:23 AM, Artyom Tarasenko wrote:
On Sat, Apr 13, 2013 at 7:03 PM, Rob Landley wrote:
> On 03/26/2013 02:34:50 AM, Artyom Tarasenko wrote:
>>
>> On Tue, Mar 26, 2013 at 1:52 AM, Rob Landley
wrote:
>> > Can the virtio things (serial, network, b
ort to musl and convince the toolchain
it's just going to have to cope with the idea of a 64 bit sparc
userspace.
Rob
On 04/19/2013 05:27:55 AM, Mark Cave-Ayland wrote:
On 22/03/13 05:19, Rob Landley wrote:
If I do this:
qemu-system-sparc -nographic -no-reboot -kernel image -hda hda.sqf
-append 'root=/dev/sda rw init=/sbin/init.sh panic=1
PATH=/usr/distcc:/bin:/sbin console=ttyS0 HOST=sparc C
From: Rob Herring
Enable the generic PCI host on ARM virt platform.
TODO:
The memory regions aliases are hard coded in the host ATM. These probably
need to become QOM properties.
Signed-off-by: Rob Herring
---
hw/arm/virt.c | 57 +
1
From: Rob Herring
Add a generic PCI host controller for virtual platforms. This is for ARM
virtual platforms at the moment, but has nothing ARM specific. This
matches the generic PCI host driver added in the 3.16 kernel.
Functioning with OHCI (usb disk), but not LSI SCSI which doesn't f
n is just source versions or
requires the license text to be in the binary; Android does it to be
safe, most others don't bother.)
Rob
(Personally I look back at the days when my Commodore 64 came bundled
with a "Disk Bonus Pack" of public domain software mostly written by
Jim
no point what so ever changing the kernel.
Because working with old and new qemu, like it used to before everybody
fiddled with it to not actually match hardware nobody _has_, is
definitely not an interesting goal. If it was, I'd point you to:
http://landley.net/hg/aboriginal/rev/c756b708583f
Rob
On Wed, May 14, 2014 at 12:51 PM, Peter Maydell
wrote:
> On 5 May 2014 17:00, Rob Herring wrote:
>> From: Rob Herring
>>
>> Now that we have PSCI emulation, enable it for the virt platform.
>> This simplifies the virt machine a bit now that PSCI and SMP no longer
>
From: Rob Herring
The AArch64 kermel Image format defines the load offset in its header.
Retrieve the offset from the file instead of hardcoding it to 0x8.
Use of the hardcoded value will break when text_offset randomization is
added to the kernel.
Signed-off-by: Rob Herring
---
hw/arm
On Wed, May 14, 2014 at 12:44 PM, Peter Maydell
wrote:
> On 5 May 2014 17:00, Rob Herring wrote:
>> From: Rob Herring
>>
>> Add the infrastructure to handle and emulate hvc and smc exceptions.
>> This will enable emulation of things such as PSCI calls. This co
On Wed, May 14, 2014 at 4:25 PM, Peter Maydell wrote:
> On 14 May 2014 20:15, Rob Herring wrote:
>> On Wed, May 14, 2014 at 12:51 PM, Peter Maydell
>> wrote:
>>> My suggestion to Pranav was that we abstract away the "which PSCI
>>> version?" decision i
On Wed, May 14, 2014 at 1:12 PM, Peter Maydell wrote:
> On 5 May 2014 17:00, Rob Herring wrote:
>> From: Rob Herring
>>
>> Add support for handling PSCI calls in system emulation. Both version
>> 0.1 and 0.2 of the PSCI spec are supported. Platforms can enable support
From: Rob Herring
Signed-off-by: Rob Herring
---
Mark, I guessing you don't want to stay as maintainer?
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 97c9fa1..5ad7dcc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -
On Thu, May 22, 2014 at 6:18 AM, Pranavkumar Sawargaonkar
wrote:
> If we have PSCI v0.2 emulation available for KVM ARM/ARM64 or TCG then
> we need to provide PSCI v0.2 compatible string via generated DTB.
>
> Signed-off-by: Pranavkumar Sawargaonkar
> Signed-off-by: Anup Patel
R
From: Rob Herring
This series adds support for emulating ARM PSCI calls. PSCI or Power
State Coordination Interface is an ARM standard for controlling cpu
power states. This series supports both AArch32 and AArch64 using HVC or
SMC calls.
This is based on version 6 of Pranavkumar Sawargaonkar&#
From: Rob Herring
In preparation to add system mode only calls to
aarch64_cpu_do_interrupt, compile it for system mode only and don't set
the do_interrupt callback for user mode emulation. User mode emulation
should never get interrupts and thus should not have a exception handler
functio
From: Rob Herring
Now that we have PSCI emulation, enable it for the virt platform.
This simplifies the virt machine a bit now that PSCI and SMP no longer
need to be KVM only features.
Signed-off-by: Rob Herring
---
v2:
- Rebased. Mostly a whitespace change removing the kvm_enabled() check
From: Rob Herring
Enable PSCI emulation on highbank and midway platforms.
Note that this requires fixing the PSCI function IDs in the DTB to match
what QEMU is using. This should get fixed.
Signed-off-by: Rob Herring
---
v2:
- Add error_abort on setting of start-powered-off.
hw/arm
From: Rob Herring
Add support for handling PSCI calls in system emulation. Both version
0.1 and 0.2 of the PSCI spec are supported. Platforms can enable support
by setting "psci-method" QOM property on the cpus to SMC or HVC
emulation and having PSCI binding in their dtb.
Signed-o
From: Rob Herring
Add the infrastructure to handle and emulate hvc and smc exceptions.
This will enable emulation of things such as PSCI calls. This commit
does not change the behavior and will exit with unknown exception.
Signed-off-by: Rob Herring
---
v2:
- add syn_aa32_smc
- add missing
From: Rob Herring
Add tracking of cpu power state in order to support powering off of
cores in system emulation. The initial state is determined by the
start-powered-off QOM property.
Signed-off-by: Rob Herring
---
v2:
- Add vmstate for powered_off
target-arm/cpu-qom.h | 2 ++
target-arm
I had the exact same issue with a VM after upgrading the host from 12.04
to 14.04.
Thank you Todd for the workaround. It would have been more work than I
cared for to reassemble that machine (even if it was just a test
machine).
I'm not sure what the status of this bug is? Is this something that
on=pl011,0x... command line arguments.
>
> Signed-off-by: Ard Biesheuvel
I have this same patch in my tree. BTW, you do still need just
"earlycon" on the command-line to get an early console.
Reviewed-by: Rob Herring
Rob
> ---
> hw/arm/virt.c | 2 ++
> 1 file changed, 2
that the reverted commit fixes it.
Rob
On 09/01/14 00:05, Rob Landley wrote:
> If you grab http://landley.net/aboriginal/bin/qemu-system-sh4.tar.bz2
> extract it and ./run-emulator.sh (which is a fairly straightforward
> qemu-system-sh4 invocation on the included kernel image and squashfs
> root filesystem), older qemu ve
On 09/01/14 03:07, Paolo Bonzini wrote:
> Il 01/09/2014 07:05, Rob Landley ha scritto:
>> If you grab http://landley.net/aboriginal/bin/qemu-system-sh4.tar.bz2
>> extract it and ./run-emulator.sh (which is a fairly straightforward
>> qemu-system-sh4 invocation on the incl
gt;> after not :).
>>
>> Hi Alex,
>>
>> Unfortunately I think the last one was this week. If you are available
>> next week I would propose to setup a short call next week.
>
>
> Sure!
>
>
>> Who are the
>> required people in the call aside us and Peter?
>
>
> It would be good if we could have one person on the call who has a very good
> understanding of cross-platform device trees. Scott Wood or Rob Herring come
> to my mind here.
>
> Scott, Rob, would either of you be available for a quick call on device tree
> abstraction levels in QEMU Tuesday next week?
Yes, I can.
Rob
Mark,
On 12/22/2011 12:20 PM, Mark Langsdorf wrote:
> From: Rob Herring
>
> Signed-off-by: Rob Herring
> Signed-off-by: Mark Langsdorf
> ---
> hw/a9mpcore.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/a9mpcore.c b/hw/a9mpcore
On 01/05/2012 08:35 AM, Mark Langsdorf wrote:
> On 01/05/2012 08:26 AM, Alexander Graf wrote:
>>
>> On 05.01.2012, at 15:16, Andreas Färber wrote:
>>
>>> Am 05.01.2012 14:52, schrieb Mark Langsdorf:
>>>> From: Rob Herring
>>>>
>>>
On 01/05/2012 09:32 AM, Peter Maydell wrote:
> On 5 January 2012 15:11, Rob Herring wrote:
>> Mark, there is not a qemu code dependency on Trustzone support, so we
>> don't need to wait for that to add highbank support.
>
> That's good, because Trustzone support
t have much luck getting it working and
haven't debugged it further.
SD3.0 vs 2.0 is probably not going to make a difference from a QEMU
point of view.
Rob
>> +if (!cpu_model) {
>> +cpu_model = "cortex-a9";
>> +}
>
> Google said there is only c
this number is
irrelevant. This is the legacy boot interface and qemu really needs to
learn to boot with a separate dtb.
Rob
On 01/20/2012 02:47 AM, Peter Maydell wrote:
> On 19 January 2012 23:17, Rob Herring wrote:
>> On 01/19/2012 03:44 PM, Peter Maydell wrote:
>>> On 19 January 2012 21:31, Mark Langsdorf wrote:
>>>> +highbank_binfo.board_id = 0xEC10100f; /* provided by deviceT
stem-image-mips
./run-emulator.sh
[ wait for shell prompt ]
wget http://google.com
Under 0.15.1 it works, under 1.0 it doesn't. Identical binary. I
bisected it to the commit in question, it's still broken in -master.
Rob
On 01/22/2012 01:06 AM, Stefan Weil wrote:
> Am 21.01.2012 20:04, schrieb Rob Landley:
>> commit 5632ae46: "mips_malta: move i8259 initialization after piix4
>> initialization" broke the network on mips. It still comes up, but
>> doesn't pass packets
On 01/22/2012 07:44 PM, Anthony Liguori wrote:
> On 01/22/2012 05:42 PM, Rob Landley wrote:
>> On 01/22/2012 01:06 AM, Stefan Weil wrote:
>>> This was fixed with commits e9b40fd34ceb23461083d505a444a389c094455b
>>> and 0b23c5d40ea933cfece3b4f69427f79c8a23256d in maste
On 01/23/2012 12:34 AM, Stefan Weil wrote:
> Hi Rob,
>
> the patch was applied after v1.0, and there are two commits for
> the stable-1.0 branch and the main development branch.
> So I think that your git repository and your analysis is correct.
>
> Where did you get y
pu arm1136-r2 (0x4107b363), but it
seems like the correct fix would be to add "hardware" TLS support to arm
kernels. Is this currently on anybody's todo list? (Is there a data
sheet somewhere...?)
Rob
back? :-)
>
> -- PMM
I suspect most people emulating boards only feed one interface to the
thing, so it probably doesn't come up much.
Either way, I have a workaround now, but consistency would be nice.
Rob
ox binaries for each target (which were cross compiled).
For more information, see http;//landley.net/aboriginal
Aboriginal Linux: "We cross compile so you don't have to."
Rob
On 06/16/2011 12:45 PM, Mulyadi Santosa wrote:
> On Thu, Jun 16, 2011 at 19:34, Rob Landley wrote:
>> Aboriginal Linux's motto is "we cross compile so you don't have to".
>
> Hi Rob
>
> Thanks for your kind work I began to learn about building cro
econd TB may disappear when the memory mapping changes and the
> subsequent direct jump from the first TB will crash qemu.
>
> I guess that this usually does not happen in usermode, because the
> guest would not modify executable code memory mapping. However I
> suppose that this is also possible.
Dynamic linking modifies guest code, requiring the page to be
retranslated. With lazy binding this can happen at any time, and
without PIE executables this can happen to just about any executable page.
Rob
. I'm interested in Linux system
emulation of non-coldfire m68k. So far that means "use aranym".)
Thanks,
Rob
ror --target-list=m68k-softmmu", and then ran make, which
generated 4 header files and considered itself done.
I.E. m68k system emulation doesn't seem to be building in that tree.
Rob
On 08/18/2011 10:00 AM, bala suru wrote:
> Hi,
>
> I'm running VM on kvm-qemu hyper visor . I need to access the serail
> port on the VM ,
> I tried the sample code to read/write com port but I get port error when
> ever I tried write something to the port(dev/ttyS0) .
>
> the same code work fine
m
images forever (the kernel's some atari variant donated to the project
by a user), but have only been able to test them a couple times under
aranym, not under qemu.
Web page:
http://landley.net/aboriginal
Prebuilt binary system images for use with qemu:
http://landley.net/aboriginal/downloads/binaries
>> Currently, I'm trying to port some parts of BasiliskII into Qemu to be
>> able to boot MacOS 7.6.
>
> Why are you planning to port a hack instead of making a full machine
> emulation?
Yay machine emulation. If qemu comes up with an m68k system emulation
that has a chance of running Linux, please let me know...
Rob
putting together a 1.0.3 release with Linux 3.0, busybox 1.19.0, and
uClibc 0.9.32 this weekend. If you don't want to wait for the release,
go to http;//landley.net/hg/aboriginal and click on one of the download
links near the top to get a tarball of the current build scripts from
source control.
Rob
se
these page tables have no mapping for it, you don't have to load it back
in when you switch back to the other context that CAN access it.)
Rob
are stock
>> chips (probably almost all are NE2000, 3COM and PCNET), and Apple
>> integrated ones are also stock, easy to do :p
>
> NIC isn't really necessary at first, those things don't netboot anyway,
> do they ?
The hardware I'm interested in is:
A) CPU with MMU (FPU is nice but optional)
B) At least 256k ram,
C) Serial port
D) Three hard drives (IDE, SCSI, etc.)
E) Hardware clock
F) Network card (for distcc)
One of the goals of mmy project is to replace cross comiling with native
compiling, and that's the set of hardware I need to get a reasonably
convenient native development environment running under the emulator.
Rob
tomorrow-ish, if that would be a
better testing base. I'm probably basing it on the atari_defconfig in
the 3.0 kernel unless somebody has a better idea. (In case I need to
fish out aranym again.)
Rob
7;paste.
>>
>> Yeah, you said it!
>> The work is already done, we have all the hardware emulation that Basilisk
>> substitutes for hacks.
>
> I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no
> video card, no SWIM, no SCSI, ... useless with a patched ROM.
>
> You know, nights are not long enough...
>
>> We only lack the 68k cpu (oh! your patches!!!) and the glue :p
>
> this part is not working well as well ... gcc cannot compile linux
> kernel, some demos fail in gtk-demo, ...
I got gcc 4.2.1 with binutils 2.17 to compile the m68k Linux kernel
(including 3.0).
This kind of regression testing of each new release on various platforms
is what I've been doing for the ones I've got working for years now.
I'd love to add m68k to it (heck, I've got infrastructure to do nightly
builds from upstream -git of the kernel and uClibc and auto-bisect
breakage that prevented dropbear and strace from building natively under
the result; I admit I haven't put in the effort to follow up on the
result yet).
But all i've been able to say so far is 'I got it to compile", I can't
_run_ it on qemu. (And my aranym setup keeps bit rotting, and hasn't
got the right kind of console anyway...)
Rob
On 08/20/2011 04:16 PM, Laurent Vivier wrote:
> Le samedi 20 août 2011 à 15:57 -0500, Rob Landley a écrit :
>> On 08/18/2011 06:12 AM, François Revol wrote:
>>> Le -10/01/-28163 20:59, Laurent Vivier a écrit :
>>>> Le mercredi 17 août 2011 à 17:35 -0500, Anthony Li
configure --disable-werror --target-list=m68k-softmmu
> make
>
> and let me know what happens...
Ahem, helps to do that in the right tree. (That test was in current
vanilla -git.)
It built fine. No new board targets, but I'll see if I can find time to
fiddle with it.
Thanks,
Rob
On 08/20/2011 04:16 PM, Laurent Vivier wrote:
> Le samedi 20 août 2011 à 15:57 -0500, Rob Landley a écrit :
>> On 08/18/2011 06:12 AM, François Revol wrote:
>>> Le -10/01/-28163 20:59, Laurent Vivier a écrit :
>>>> Le mercredi 17 août 2011 à 17:35 -0500, Anthony Li
OS (that's why Linux and A/UX
> will never work on it)
I believe toolbox is the ancient mac bios, correct? Does Linux need/use
it at all?
Rob
filesystem drivers.
> Btw, vMac is more loyal to real hardware emulation.
>
> And the hardware, and the whole Toolbox and System are heavily
> documented up to II machines in the Inside Macintosh Volumes.
Again, this is about running an ancient macos version I haven't got a
license for. Half the OS was in ROM the other half was on disk. As far
as QEMU is concerned both are files you load. (One as -rom one as -hda
or similar... not my problem?)
Rob
On 08/20/2011 09:02 PM, Natalia Portillo wrote:
> El 21/08/2011, a las 01:50, Rob Landley escribió:
>
>> On 08/20/2011 07:23 PM, Natalia Portillo wrote:
>>>>> Linux requires the MMU and an almost complete hardware
>>>>> emulation. Standard m68k e
On 08/21/2011 05:04 AM, Laurent Vivier wrote:
> Le samedi 20 août 2011 à 18:42 -0500, Rob Landley a écrit :
>> On 08/20/2011 06:17 PM, Natalia Portillo wrote:
>>>> or ancient macintosh support
>>>
>>> Most of the hardware (but a few required ones like SWIM) i
fff
D7 = 0022db50 A7 = 0ff0 F7 = 7fff
PC = SR = 2700 - Aborted
Which is a bit of a dead end. I'd guess that "vmlinux" isn't the right
binary, except there isn't an arch/m68k/boot directory...
Laurent: do you have any hint
On 04/19/2012 05:47 AM, Laurent Vivier wrote:
> Hi Rob,
>
> you need to do a fresh clone because I rebase the branch frequently on
> the qemu/master instead of merging it. It is easier to manage for me.
Ok. (Did that.)
> BTW, qemu-system-m68k is not working currently.
Did it
you encounter a compiler error here, see the explanation
* near the end of INSTALL.
*/
__pngconf.h__ in libpng already includes setjmp.h;
__dont__ include it again.;
# endif
#endif /* __linux__ */
# endif /* PNG_SKIP_SETJMP_CHECK */
Rob
Those of us who have vmdk images bestowed upon us and would prefer to
run them under qemu would very like to have a way to convert the images
in both directions.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.n
Linux has a mac_defconfig under the m68k
directory specifying numerous drivers for actual hardware.
It seems unlikely that the powerpc mac99 and g3beige worked just fine
for me, but before they swapped the CPU out it all ran by magic.
Rob
P.S. For context as to what counts as "intimidating" and "magic", Jeri
Ellsworth reverse engineered the Amiga chips in an FPGA:
http://www.youtube.com/watch?v=5uaDzF99a80
From: Rob Herring
ARMv8 has both AArch32 and AArch64 versions of ID registers. Both sets
of registers are accessible in AArch64 state, but only . Update the
definitions to allow AArch64 access.
This fixes booting on recent (linux-next for 3.15) linux kernels which
add access to ID_ISAR5
->id_dfr0 = 0x03010066;
> +cpu->id_afr0 = 0x;
> +cpu->id_mmfr0 = 0x10101105;
> +cpu->id_mmfr1 = 0x4000;
> +cpu->id_mmfr2 = 0x0126;
> +cpu->id_mmfr3 = 0x02102211;
> +cpu->id_isar0 = 0x02101110;
> +cpu->id_isar1 = 0x13112111;
> +cpu->id_isar2 = 0x21232042;
> +cpu->id_isar3 = 0x01112131;
> +cpu->id_isar4 = 0x00011142;
Need to add id_isar5 here. 0x00010001 is the correct value with no
crypto extensions.
Rob
en we could just say "-cpu host only makes sense for
> the virt machine", but we're not there right now.)
>
> Peter Maydell (2):
> hw/arm/highbank: Don't segfault on unknown CPU names
> hw/arm/vexpress, hw/arm/highbank: Don't insist that CPU has reset-cbar
> property
For both:
Reviewed-by: Rob Herring
SBSA compliant GICv2(M)
A57 + GICv3
The SBSA change is making each register bank within the GIC 64K spaced
instead of 4K spaced to support 64KB pages in OSs and hypervisors.
This is a simple address swizzling trick defined in the SBSA doc.
(Since it's documented it must not be a cute embedded nonsense hack.
:)) Then the M portion is for PCI MSI support which is optional.
Rob
#x27;s
a 32-bit binary output from the Aboriginal Linux build. (I try to
upload new ones each time Denys has a release, but I'm buried in todo
items and don't always get to it. Right now I need to clean up and
repost the inittmpfs patches for 3.9...)
Rob
different problem in the 3.9 kernel for sh4...
Rob
interested in this last one for the 1.5
release.
Sparc's OpenBios also needs a refresh to handle longer command lines:
http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg03880.html
Rob
On 04/30/2013 04:31:29 PM, Artyom Tarasenko wrote:
On Mon, Apr 29, 2013 at 7:43 AM, Rob Landley wrote:
> On 04/27/2013 03:00:06 PM, Artyom Tarasenko wrote:
>>
>> > For a lot of the 64-bit targets, actual 64 bit userspace support
is
>> > strangely lacking. For ppc64
m to add a command line thing to qemu to plug a physical memory
address range into an aribtrary address and then tell linux
discontigmem "add memory range HERE" on the command line. That way I
wouldn't have to hack up each board emulation to get more memory...)
Rob
equivalent to solving the halting problem. The best you
can do is log and replay.
Rob
pts again, doesn't mean it's a normal
departure point, could be a signal). And the problem is do you record
the target's idea of "from" or the translated host idea of "from"...
Rob
On Tue, Feb 11, 2014 at 5:29 PM, Peter Maydell wrote:
> On 11 February 2014 23:19, Rob Herring wrote:
>> From: Rob Herring
>>
>> Several platforms make smc calls for things such as PL310 cache setup.
>> In these cases, making smc a nop rather than an illegal instr
we split out the CPU and
> private memory region init to its own function.
>
> Signed-off-by: Peter Maydell
> Reported-by: Rob Herring
> ---
> Thanks to Rob for tracking down this SMP boot issue and identifying
> the offending kernel change (which personally I think is a terrible
From: Rob Herring
MPIDR register is a machine configurable option and current kernels require
the value to match with DT cpu reg properties. So add a property for MPIDR
value and allow platforms to override.
ARM_FEATURE_MPIDR is not used here because it is set too late.
Signed-off-by: Rob
From: Rob Herring
Calxeda highbank platform uses a cluster id of 9 which makes MPIDR
register be 0x890n where n is the core number. This causes problems
on current kernels expecting the MPIDR to match DT cpu reg property.
Midway is "normal" and has a cluster id of 0, so it doe
On Mon, Feb 24, 2014 at 4:28 PM, Peter Maydell wrote:
> On 24 February 2014 22:14, Rob Herring wrote:
>> From: Rob Herring
>> MPIDR register is a machine configurable option and current kernels require
>> the value to match with DT cpu reg properties. So add a property f
erent CPUs and timer event streams), so making
> it do a yield seems like a useful intermediate fix.
>
> This seems to be hugely beneficial on my test case (whereas
> the recent GIC fix to not accidentally deassert PPIs doesn't
> have any effect at all). Rob, do you still see
On Wed, Feb 26, 2014 at 4:31 AM, Peter Maydell wrote:
> On 26 February 2014 03:32, Hu Tao wrote:
>> On Wed, Feb 26, 2014 at 10:49:59AM +0800, Hu Tao wrote:
>>> On Sat, Feb 15, 2014 at 04:07:24PM +, Peter Maydell wrote:
>>> > From: Rob Herring
>
>>>
1 - 100 of 587 matches
Mail list logo
