[Aboriginal] [Qemu-devel] [PATCH] Fixing sh4 serial abort
rob at landley.net
Wed Aug 1 04:50:14 PDT 2012
On 07/27/2012 12:28 PM, Peter Maydell wrote:
> On 27 July 2012 18:16, Rob Landley <rob at landley.net> wrote:
>> On 07/27/2012 09:32 AM, Peter Maydell wrote:
>>> The thing this analysis is missing is any examination of the question
>>> "what is the hardware we are modelling documented to do?".
>> Given that 3.3, 3.4, and 3.5 kernels have already shipped with this, I'm
>> guessing "not immediately crash"?
> I said "documented", not "what it happens to do in practice".
I'm trying to make it work in practice.
>> So the arm maintainer noticed a place where the code didn't match the
>> documentation, changed the code to match the docs, and result doesn't
>> work under qemu's versatile board emulation. But at least 3.5 doesn't
>> work for a _different_ reason than 3.4 didn't work, so there's that.
> PCI on versatilepb is hopelessly broken -- the only thing the kernel
> code does (or did) is work on QEMU.
Which is all I used it for.
>> I hadn't reported this one yet because I still haven't root caused it,
>> just bisected to find the break. I know reverting the IRQ assignment
>> line in 3.5 doesn't fix it, which implies the "swizzle" bit is to blame
>> (which seems ot have something to do with PCI bridges), and thus calling
>> the default function instead of calling no function breaks qemu's
>> versatile board emulation.
> 1. Find Arnd's kernel patches and see what of them still need to
> be applied (http://comments.gmane.org/gmane.linux.ports.arm.kernel/93393)
> 2. Get kernel working on real hardware
You seem to be under the impression I have real arm hardware. (Or real
sh4 hardware, or real powerpc hardware, or real mips hardware...)
I've got an armv4t board in a box (a patch to support that was submited
to the list by the vendor, and never merged), and a phone that's
presumably armv7l but it's in use as a phone with the vendor software on
it, and at work I use an cluster of unreleased armv7 SOCs in an "I can't
believe it's not NUMA" configuration. The userspaces I worked out under
qemu run in a chroot under there.
I've got two diferent mips routers in a box somewhere with a dongle that
lets me do a serial console but both require kernel patches to add board
support (neither vendor ever submitted it upstream). I've run the root
filesystems I worked out under qemu in a chroot under them but haven't
gotten them out of the box in over a year. (I think it's in storage,
A couple of the game consoles might be powerpc, but I've never run linux
on them. I don't own sh4 or sparc hardware.
> 3. Submit qemu patches to fix our versatilepb PCI emulation to
> match hardware
4) locally patch the kernel back to work with existing qemu releases
since all I want to do is boot an arm userspace to a shell prompt and
run arm code on it, and don't really care about the board emulation
except for the laundry list of features I need out of it such as "a
working persistent clock so make doesn't lose its marbles", "enough
physical memory", "serial console", "working network device", and "three
working block device I can plug filesystem images into".
My goal is to run an emulated linux userspace, and application emulation
is _way_ more complicated and fiddly than system emulation. If real
hardware was as easily accessible for me as qemu, qemu would be
significantly less useful.
> If you like you can do 3 first and I'll happily apply those patches
> regardless of whether anybody cares to fix the kernel.
I just want it to work. Working the same way real hardware does is a
bonus, but if the change isn't visible to userspace (virtio? emulated
scsi? emulated ide?) it's not actually relevant to my use case.
> I'm afraid I don't have a great deal of time for versatilepb
> emulation fixes because it's an incredibly ancient devboard.
I can switch to a newer board, but I want to plug armv4tl, armv5l,
armv6l, and armv7l processors into it. (And eventually armv8 but nothing
supports that yet.) If it's always running armv7 then I can't _prove_
that this userspace would actually run on armv5 and didn't leak armv7
instructions in there.
Last time I looked at newer boards the idea of plugging older processors
into them confused both qemu and the kernel's config stuff.
Looking at current qemu-git, there's no "-M vexpress", there is instead
vexpress-a9 ARM Versatile Express for Cortex-A9
vexpress-a15 ARM Versatile Express for Cortex-A15
I.E. the assumption about what processor you're plugging into this board
is baked into the board _name_, and both of those are armv7 only.
Hmmm, then again it looks like
Never got merged so the -cpu restrictions for armv4t and armv5l are
currently commented out anyway. (I tested with it at one point, but I
ship system images that people use with their existing qemu versions, so
I can't patch qemu for them....)
> vexpress breakage will get more attention from me (though I
> don't habitually test new kernels on qemu so I won't necessarily
> notice bugs unless my attention is drawn to them.)
I do habitually test newer kernels on qemu. I can draw attention to
them, but not necessarily interest.
> -- PMM
I'll poke at vexpress and see what I can get it to do.
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
More information about the Aboriginal