From patchwork Sat Feb 13 08:02:00 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rob Landley X-Patchwork-Id: 45231 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 1DB63B7BEE for ; Sat, 13 Feb 2010 19:14:02 +1100 (EST) Received: from localhost ([127.0.0.1]:39872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NgD8Z-0006an-5T for incoming@patchwork.ozlabs.org; Sat, 13 Feb 2010 03:13:59 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NgCyb-0004pQ-Fs for qemu-devel@nongnu.org; Sat, 13 Feb 2010 03:03:41 -0500 Received: from [199.232.76.173] (port=35388 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NgCya-0004p4-AW for qemu-devel@nongnu.org; Sat, 13 Feb 2010 03:03:40 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NgCyY-0004wx-9s for qemu-devel@nongnu.org; Sat, 13 Feb 2010 03:03:39 -0500 Received: from [71.162.243.5] (port=56249 helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NgCyY-0004tK-09 for qemu-devel@nongnu.org; Sat, 13 Feb 2010 03:03:38 -0500 Received: from landley.net (localhost [127.0.0.1]) by grelber.thyrsus.com (Postfix) with ESMTP id 50C199F0140 for ; Sat, 13 Feb 2010 03:01:34 -0500 (EST) From: Rob Landley Organization: Boundaries Unlimited To: qemu-devel@nongnu.org Date: Sat, 13 Feb 2010 02:02:00 -0600 User-Agent: KMail/1.11.2 (Linux/2.6.28-17-generic; KDE/4.2.2; x86_64; ; ) MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201002130202.01901.rob@landley.net> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: [Qemu-devel] qemu-system-ppc -m g3beige -hda is setting /dev/hdc on Linux. X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org The -hda, -hdb, -hdc, and -hdd command line options for g3beige don't match the order the kernel assigns the drives. The reason is that the Linux kernel always initializes the cmd646 driver before the pmac driver, thus if there's a cmd646 it gets /dev/hda and /dev/hdb, and the pmac gets /dev/hdc and /dev/hdb. If you only supply an -hda (and/or -hdb) with no -hdc or -hdd, then the cmd646 driver never attaches to anything and only the pmac controller shows up, thus -hda and -hdb set /dev/hda and /dev/hdb. But if you specify a -hdc it shows up as /dev/hda every time, and kicks the -hda entry to /dev/hdc. Note that neither the kernel's CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST nor CONFIG_IDEPCI_PCIBUS_ORDER made any difference, because those affect multiple devices handled by the same driver, and this is a static driver initialization order issue. When you statically link in both drivers, cmd64x always probes before pmac due to the above hardwired device order in the kernel, 100% reliable and deterministic. It's hardwired, and you have to patch the kernel to change it. Here's a patch to the Linux kernel that changes the device probe order so the kernel behaves like g3beige is expecting it to: Rob --- a/drivers/ide/Makefile +++ b/drivers/ide/Makefile @@ -39,6 +39,7 @@ obj-$(CONFIG_BLK_DEV_AMD74XX) += amd74xx.o obj-$(CONFIG_BLK_DEV_ATIIXP) += atiixp.o obj-$(CONFIG_BLK_DEV_CELLEB) += scc_pata.o +obj-$(CONFIG_BLK_DEV_IDE_PMAC) += pmac.o obj-$(CONFIG_BLK_DEV_CMD64X) += cmd64x.o obj-$(CONFIG_BLK_DEV_CS5520) += cs5520.o obj-$(CONFIG_BLK_DEV_CS5530) += cs5530.o @@ -76,8 +77,6 @@ obj-$(CONFIG_BLK_DEV_CMD640) += cmd640.o -obj-$(CONFIG_BLK_DEV_IDE_PMAC) += pmac.o - obj-$(CONFIG_IDE_H8300) += ide-h8300.o obj-$(CONFIG_IDE_GENERIC) += ide-generic.o The problem is, the kernel guys will never take that patch upstream because what they're currently doing isn't actually wrong. Their behavior is consistent, the kernel's been probing the same devices in the same order since the 90's, and they don't really care what order things go in. The problem is that the association between qemu's command line arguments and the devices they refer to is somewhat arbitrary. On the other targets I've used (arm, mips, x86, and so on), the device QEMU initializes in response to "-hda" is the one the Linux kernel makes /dev/hda (or /dev/sda), and the one it intializes in response to "-hdc" is the one Linux makes /dev/hdc. But in this case, they don't match up, and that's screwing up my same init/build script that works fine on all the other tarets. Here's a patch to QEMU that makes those arguments intialize the devices the kernel expects them to. This doesn't change where any of the hardware is on the board, just which command line arguments associate with which drives: --- a/hw/ppc_oldworld.c +++ b/hw/ppc_oldworld.c @@ -346,16 +346,16 @@ static void ppc_heathrow_init (ram_addr_t ram_size, exit(1); } - /* First IDE channel is a MAC IDE on the MacIO bus */ - hd[0] = drive_get(IF_IDE, 0, 0); - hd[1] = drive_get(IF_IDE, 0, 1); + /* Second IDE channel is a MAC IDE on the MacIO bus */ + hd[0] = drive_get(IF_IDE, 1, 0); + hd[1] = drive_get(IF_IDE, 1, 1); dbdma = DBDMA_init(&dbdma_mem_index); ide_mem_index[0] = -1; ide_mem_index[1] = pmac_ide_init(hd, pic[0x0D], dbdma, 0x16, pic[0x02]); - /* Second IDE channel is a CMD646 on the PCI bus */ - hd[0] = drive_get(IF_IDE, 1, 0); - hd[1] = drive_get(IF_IDE, 1, 1); + /* First IDE channel is a CMD646 on the PCI bus */ + hd[0] = drive_get(IF_IDE, 0, 0); + hd[1] = drive_get(IF_IDE, 0, 1); hd[3] = hd[2] = NULL; pci_cmd646_ide_init(pci_bus, hd, 0);