On 07/27/2012 12:28 PM, Peter Maydell wrote: > On 27 July 2012 18:16, Rob Landley <r...@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.