[Aboriginal] [Qemu-devel] [PATCH] Fixing sh4 serial abort

[Rob Landley]

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,
actually.)

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

  http://www.mail-archive.com/qemu-devel@nongnu.org/msg19370.html

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.

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.