From owner-freebsd-alpha Sun Sep 6 14:02:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25837 for freebsd-alpha-outgoing; Sun, 6 Sep 1998 14:02:13 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from gjp.erols.com (alex-va-n008c079.moon.jic.com [206.156.18.89]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA24996; Sun, 6 Sep 1998 13:58:51 -0700 (PDT) (envelope-from gjp@gjp.erols.com) Received: from gjp.erols.com (gjp@localhost.erols.com [127.0.0.1]) by gjp.erols.com (8.8.8/8.8.7) with ESMTP id QAA22953; Sun, 6 Sep 1998 16:58:33 -0400 (EDT) (envelope-from gjp@gjp.erols.com) To: freebsd-alpha@FreeBSD.ORG cc: dfr@FreeBSD.ORG From: "Gary Palmer" Subject: alpha kernel broken? Date: Sun, 06 Sep 1998 16:58:33 -0400 Message-ID: <22949.905115513@gjp.erols.com> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been trying to compile an alpha kernel to make use of the elf dynmic loader, but keep running into a bunch of multiple definition warnings from the linker. What doesn't make any sense is that it claims the definitions are on the same line... Any ideas? Thanks, Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info -- SNIP -- root@sloth:/sys/compile/SLOTH> make loading kernel subr_bus.o: In function `devclass_find': /sys/compile/SLOTH/../../kern/subr_bus.c:165: multiple definition of `devclass_find' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:165: first defined here subr_bus.o: In function `devclass_add_driver': /sys/compile/SLOTH/../../kern/subr_bus.c:171: multiple definition of `devclass_add_driver' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:171: first defined here subr_bus.o: In function `devclass_delete_driver': /sys/compile/SLOTH/../../kern/subr_bus.c:189: multiple definition of `devclass_delete_driver' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:189: first defined here subr_bus.o: In function `device_set_driver': /sys/compile/SLOTH/../../kern/subr_bus.c:671: multiple definition of `device_set_driver' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:671: first defined here subr_bus.o: In function `devclass_find_driver': /sys/compile/SLOTH/../../kern/subr_bus.c:218: multiple definition of `devclass_find_driver' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:218: first defined here subr_bus.o: In function `devclass_get_name': /sys/compile/SLOTH/../../kern/subr_bus.c:232: multiple definition of `devclass_get_name' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:232: first defined here subr_bus.o: In function `devclass_get_device': /sys/compile/SLOTH/../../kern/subr_bus.c:238: multiple definition of `devclass_get_device' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:238: first defined here subr_bus.o: In function `devclass_get_softc': /sys/compile/SLOTH/../../kern/subr_bus.c:248: multiple definition of `devclass_get_softc' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:248: first defined here subr_bus.o: In function `devclass_get_devices': /sys/compile/SLOTH/../../kern/subr_bus.c:258: multiple definition of `devclass_get_devices' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:258: first defined here subr_bus.o: In function `devclass_get_maxunit': /sys/compile/SLOTH/../../kern/subr_bus.c:289: multiple definition of `devclass_get_maxunit' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:289: first defined here subr_bus.o: In function `device_get_name': /sys/compile/SLOTH/../../kern/subr_bus.c:562: multiple definition of `device_get_name' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:562: first defined here subr_bus.o: In function `device_get_unit': /sys/compile/SLOTH/../../kern/subr_bus.c:571: multiple definition of `device_get_unit' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:571: first defined here subr_bus.o: In function `device_is_alive': /sys/compile/SLOTH/../../kern/subr_bus.c:649: multiple definition of `device_is_alive' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:649: first defined here subr_bus.o: In function `device_get_desc': /sys/compile/SLOTH/../../kern/subr_bus.c:577: multiple definition of `device_get_desc' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:577: first defined here subr_bus.o: In function `device_add_child': /sys/compile/SLOTH/../../kern/subr_bus.c:429: multiple definition of `device_add_child' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:429: first defined here subr_bus.o: In function `device_add_child_after': /sys/compile/SLOTH/../../kern/subr_bus.c:442: multiple definition of `device_add_child_after' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:442: first defined here subr_bus.o: In function `device_delete_child': /sys/compile/SLOTH/../../kern/subr_bus.c:458: multiple definition of `device_delete_child' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:458: first defined here subr_bus.o: In function `device_find_child': /sys/compile/SLOTH/../../kern/subr_bus.c:476: multiple definition of `device_find_child' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:476: first defined here subr_bus.o: In function `device_set_devclass': /sys/compile/SLOTH/../../kern/subr_bus.c:654: multiple definition of `device_set_devclass' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:654: first defined here subr_bus.o: In function `device_get_parent': /sys/compile/SLOTH/../../kern/subr_bus.c:545: multiple definition of `device_get_parent' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:545: first defined here subr_bus.o: In function `device_get_driver': /sys/compile/SLOTH/../../kern/subr_bus.c:551: multiple definition of `device_get_driver' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:551: first defined here subr_bus.o: In function `device_get_devclass': /sys/compile/SLOTH/../../kern/subr_bus.c:557: multiple definition of `device_get_devclass' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:557: first defined here subr_bus.o: In function `device_set_desc': /sys/compile/SLOTH/../../kern/subr_bus.c:583: multiple definition of `device_set_desc' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:583: first defined here subr_bus.o: In function `device_get_softc': /sys/compile/SLOTH/../../kern/subr_bus.c:589: multiple definition of `device_get_softc' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:589: first defined here subr_bus.o: In function `device_get_ivars': /sys/compile/SLOTH/../../kern/subr_bus.c:595: multiple definition of `device_get_ivars' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:595: first defined here subr_bus.o: In function `device_get_state': /sys/compile/SLOTH/../../kern/subr_bus.c:601: multiple definition of `device_get_state' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:601: first defined here subr_bus.o: In function `device_enable': /sys/compile/SLOTH/../../kern/subr_bus.c:607: multiple definition of `device_enable' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:607: first defined here subr_bus.o: In function `device_disable': /sys/compile/SLOTH/../../kern/subr_bus.c:613: multiple definition of `device_disable' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:613: first defined here subr_bus.o: In function `device_busy': /sys/compile/SLOTH/../../kern/subr_bus.c:618: multiple definition of `device_busy' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:618: first defined here subr_bus.o: In function `device_unbusy': /sys/compile/SLOTH/../../kern/subr_bus.c:629: multiple definition of `device_unbusy' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:629: first defined here subr_bus.o: In function `device_is_enabled': /sys/compile/SLOTH/../../kern/subr_bus.c:643: multiple definition of `device_is_enabled' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:643: first defined here subr_bus.o: In function `device_probe_and_attach': /sys/compile/SLOTH/../../kern/subr_bus.c:694: multiple definition of `device_probe_and_attach' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:694: first defined here subr_bus.o: In function `device_detach': /sys/compile/SLOTH/../../kern/subr_bus.c:724: multiple definition of `device_detach' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:724: first defined here subr_bus.o: In function `device_shutdown': /sys/compile/SLOTH/../../kern/subr_bus.c:746: multiple definition of `device_shutdown' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:746: first defined here subr_bus.o: In function `resource_int_value': /sys/compile/SLOTH/../../kern/subr_bus.c:811: multiple definition of `resource_int_value' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:811: first defined here subr_bus.o: In function `resource_long_value': /sys/compile/SLOTH/../../kern/subr_bus.c:824: multiple definition of `resource_long_value' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:824: first defined here subr_bus.o: In function `resource_string_value': /sys/compile/SLOTH/../../kern/subr_bus.c:837: multiple definition of `resource_string_value' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:837: first defined here subr_bus.o: In function `resource_query_string': /sys/compile/SLOTH/../../kern/subr_bus.c:850: multiple definition of `resource_query_string' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:850: first defined here subr_bus.o: In function `resource_query_name': /sys/compile/SLOTH/../../kern/subr_bus.c:863: multiple definition of `resource_query_name' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:863: first defined here subr_bus.o: In function `resource_query_unit': /sys/compile/SLOTH/../../kern/subr_bus.c:869: multiple definition of `resource_query_unit' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:869: first defined here subr_bus.o: In function `bus_generic_attach': /sys/compile/SLOTH/../../kern/subr_bus.c:879: multiple definition of `bus_generic_attach' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:879: first defined here subr_bus.o: In function `bus_generic_detach': /sys/compile/SLOTH/../../kern/subr_bus.c:892: multiple definition of `bus_generic_detach' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:892: first defined here subr_bus.o: In function `bus_generic_shutdown': /sys/compile/SLOTH/../../kern/subr_bus.c:908: multiple definition of `bus_generic_shutdown' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:908: first defined here subr_bus.o: In function `bus_generic_print_child': /sys/compile/SLOTH/../../kern/subr_bus.c:921: multiple definition of `bus_generic_print_child' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:921: first defined here subr_bus.o: In function `bus_generic_read_ivar': /sys/compile/SLOTH/../../kern/subr_bus.c:926: multiple definition of `bus_generic_read_ivar' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:926: first defined here subr_bus.o: In function `bus_generic_write_ivar': /sys/compile/SLOTH/../../kern/subr_bus.c:932: multiple definition of `bus_generic_write_ivar' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:932: first defined here subr_bus.o: In function `bus_generic_create_intr': /sys/compile/SLOTH/../../kern/subr_bus.c:937: multiple definition of `bus_generic_create_intr' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:937: first defined here subr_bus.o: In function `bus_generic_connect_intr': /sys/compile/SLOTH/../../kern/subr_bus.c:947: multiple definition of `bus_generic_connect_intr' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:947: first defined here subr_bus.o: In function `root_bus_configure': /sys/compile/SLOTH/../../kern/subr_bus.c:1012: multiple definition of `root_bus_configure' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:1012: first defined here subr_bus.o: In function `driver_module_handler': /sys/compile/SLOTH/../../kern/subr_bus.c:1024: multiple definition of `driver_module_handler' subr_bus.o:/sys/compile/SLOTH/../../kern/subr_bus.c:1024: first defined here device_if.o: In function `DEVICE_PROBE': /sys/compile/SLOTH/device_if.c:22: multiple definition of `device_probe_desc' device_if.o:/sys/compile/SLOTH/device_if.c:22: first defined here device_if.o: In function `DEVICE_PROBE': /sys/compile/SLOTH/device_if.c:22: multiple definition of `DEVICE_PROBE' device_if.o:/sys/compile/SLOTH/device_if.c:22: first defined here device_if.o: In function `DEVICE_PROBE': /sys/compile/SLOTH/device_if.c:23: multiple definition of `device_attach_desc' device_if.o:/sys/compile/SLOTH/device_if.c:23: first defined here device_if.o: In function `DEVICE_ATTACH': /sys/compile/SLOTH/device_if.c:36: multiple definition of `DEVICE_ATTACH' device_if.o:/sys/compile/SLOTH/device_if.c:36: first defined here device_if.o: In function `DEVICE_PROBE': /sys/compile/SLOTH/device_if.c:23: multiple definition of `device_detach_desc' device_if.o:/sys/compile/SLOTH/device_if.c:23: first defined here device_if.o: In function `DEVICE_DETACH': /sys/compile/SLOTH/device_if.c:50: multiple definition of `DEVICE_DETACH' device_if.o:/sys/compile/SLOTH/device_if.c:50: first defined here device_if.o: In function `DEVICE_PROBE': /sys/compile/SLOTH/device_if.c:23: multiple definition of `device_shutdown_desc' device_if.o:/sys/compile/SLOTH/device_if.c:23: first defined here device_if.o: In function `DEVICE_SHUTDOWN': /sys/compile/SLOTH/device_if.c:64: multiple definition of `DEVICE_SHUTDOWN' device_if.o:/sys/compile/SLOTH/device_if.c:64: first defined here bus_if.o: In function `BUS_PRINT_CHILD': /sys/compile/SLOTH/bus_if.c:24: multiple definition of `bus_print_child_desc' bus_if.o:/sys/compile/SLOTH/bus_if.c:24: first defined here bus_if.o: In function `BUS_PRINT_CHILD': /sys/compile/SLOTH/bus_if.c:24: multiple definition of `BUS_PRINT_CHILD' bus_if.o:/sys/compile/SLOTH/bus_if.c:24: first defined here bus_if.o: In function `BUS_PRINT_CHILD': /sys/compile/SLOTH/bus_if.c:25: multiple definition of `bus_read_ivar_desc' bus_if.o:/sys/compile/SLOTH/bus_if.c:25: first defined here bus_if.o: In function `BUS_READ_IVAR': /sys/compile/SLOTH/bus_if.c:44: multiple definition of `BUS_READ_IVAR' bus_if.o:/sys/compile/SLOTH/bus_if.c:44: first defined here bus_if.o: In function `BUS_PRINT_CHILD': /sys/compile/SLOTH/bus_if.c:25: multiple definition of `bus_write_ivar_desc' bus_if.o:/sys/compile/SLOTH/bus_if.c:25: first defined here bus_if.o: In function `BUS_WRITE_IVAR': /sys/compile/SLOTH/bus_if.c:64: multiple definition of `BUS_WRITE_IVAR' bus_if.o:/sys/compile/SLOTH/bus_if.c:64: first defined here bus_if.o: In function `BUS_PRINT_CHILD': /sys/compile/SLOTH/bus_if.c:25: multiple definition of `bus_create_intr_desc' bus_if.o:/sys/compile/SLOTH/bus_if.c:25: first defined here bus_if.o: In function `BUS_CREATE_INTR': /sys/compile/SLOTH/bus_if.c:86: multiple definition of `BUS_CREATE_INTR' bus_if.o:/sys/compile/SLOTH/bus_if.c:86: first defined here bus_if.o: In function `BUS_PRINT_CHILD': /sys/compile/SLOTH/bus_if.c:25: multiple definition of `bus_connect_intr_desc' bus_if.o:/sys/compile/SLOTH/bus_if.c:25: first defined here bus_if.o: In function `BUS_CONNECT_INTR': /sys/compile/SLOTH/bus_if.c:102: multiple definition of `BUS_CONNECT_INTR' bus_if.o:/sys/compile/SLOTH/bus_if.c:102: first defined here *** Error code 1 Stop. -- SNIP -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Sep 6 14:17:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA28841 for freebsd-alpha-outgoing; Sun, 6 Sep 1998 14:17:47 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA28704; Sun, 6 Sep 1998 14:16:53 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id HAA26986; Mon, 7 Sep 1998 07:30:55 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199809062130.HAA26986@cimlogic.com.au> Subject: Re: alpha kernel broken? In-Reply-To: <22949.905115513@gjp.erols.com> from Gary Palmer at "Sep 6, 98 04:58:33 pm" To: gpalmer@FreeBSD.ORG (Gary Palmer) Date: Mon, 7 Sep 1998 07:30:55 +1000 (EST) Cc: freebsd-alpha@FreeBSD.ORG, dfr@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gary Palmer wrote: > > I've been trying to compile an alpha kernel to make use of the elf > dynmic loader, but keep running into a bunch of multiple definition > warnings from the linker. What doesn't make any sense is that it > claims the definitions are on the same line... Any ideas? I see all of those too. I just grabbed the kernel from Doug's home directory on freefall and used that. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Sep 6 15:03:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03802 for freebsd-alpha-outgoing; Sun, 6 Sep 1998 15:03:55 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from gjp.erols.com (alex-va-n008c079.moon.jic.com [206.156.18.89]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03793; Sun, 6 Sep 1998 15:03:49 -0700 (PDT) (envelope-from gjp@gjp.erols.com) Received: from gjp.erols.com (gjp@localhost.erols.com [127.0.0.1]) by gjp.erols.com (8.8.8/8.8.7) with ESMTP id SAA23822; Sun, 6 Sep 1998 18:03:25 -0400 (EDT) (envelope-from gjp@gjp.erols.com) To: John Birrell cc: freebsd-alpha@FreeBSD.ORG, dfr@FreeBSD.ORG From: "Gary Palmer" Subject: Re: alpha kernel broken? In-reply-to: Your message of "Mon, 07 Sep 1998 07:30:55 +1000." <199809062130.HAA26986@cimlogic.com.au> Date: Sun, 06 Sep 1998 18:03:25 -0400 Message-ID: <23818.905119405@gjp.erols.com> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Birrell wrote in message ID <199809062130.HAA26986@cimlogic.com.au>: > Gary Palmer wrote: > > > > I've been trying to compile an alpha kernel to make use of the elf > > dynmic loader, but keep running into a bunch of multiple definition > > warnings from the linker. What doesn't make any sense is that it > > claims the definitions are on the same line... Any ideas? > > I see all of those too. I just grabbed the kernel from Doug's home > directory on freefall and used that. That would assume I have my root partition on sd0a :( Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Sep 7 00:30:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA02989 for freebsd-alpha-outgoing; Mon, 7 Sep 1998 00:30:30 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA02847; Mon, 7 Sep 1998 00:29:59 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.9.1/8.8.5) with SMTP id IAA08546; Mon, 7 Sep 1998 08:30:08 +0100 (BST) Date: Mon, 7 Sep 1998 08:30:08 +0100 (BST) From: Doug Rabson To: Gary Palmer cc: freebsd-alpha@FreeBSD.ORG, dfr@FreeBSD.ORG Subject: Re: alpha kernel broken? In-Reply-To: <22949.905115513@gjp.erols.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 6 Sep 1998, Gary Palmer wrote: > > I've been trying to compile an alpha kernel to make use of the elf > dynmic loader, but keep running into a bunch of multiple definition > warnings from the linker. What doesn't make any sense is that it > claims the definitions are on the same line... Any ideas? This was caused when the device framework code was moved from files.alpha to files. I have just committed the relavent changes to files.alpha. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Sep 7 03:41:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA20915 for freebsd-alpha-outgoing; Mon, 7 Sep 1998 03:41:07 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA20910 for ; Mon, 7 Sep 1998 03:41:05 -0700 (PDT) (envelope-from roger@cs.strath.ac.uk) Received: from muir-10 (roger@muir-10.cs.strath.ac.uk [130.159.148.10]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with SMTP id LAA02169 Mon, 7 Sep 1998 11:41:00 +0100 (BST) Message-ID: <35F3B83B.167E@cs.strath.ac.uk> Date: Mon, 07 Sep 1998 11:40:59 +0100 From: Roger Hardiman Organization: University of Strathclyde X-Mailer: Mozilla 3.04Gold (X11; I; OSF1 V4.0 alpha) MIME-Version: 1.0 To: freebsd-alpha@FreeBSD.ORG Subject: Bt848 driver for Alpha Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, A question on porting the bt848 driver to Alpha hardware. Anyway, there are 2 32bit dependent sections a) memory mapped registers in the bt848 chip b) RISC code Q) The driver maps the registers (of which the bt848/878 has around 30) into the memory space and then writes to the registers as if you were writing to a normal variable (crude example bt848->register1 = some_value; bt848->register2 = some_value; Question: Can I write to just a 32 bit register with the Alpha. (in the same memory mapped way) Or, does the Alpha sneakilly do a 32 bit read of address n+1 and then do a 64 bit write. (think some old Alpha chips did this) I do not want to go writing to registers I was not intending to write to. Roger Hardiman Strathclyde Uni Telepresence Group To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Sep 8 01:39:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA25535 for freebsd-alpha-outgoing; Tue, 8 Sep 1998 01:39:21 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA25528 for ; Tue, 8 Sep 1998 01:39:18 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.9.1/8.8.5) with SMTP id JAA13408; Tue, 8 Sep 1998 09:38:51 +0100 (BST) Date: Tue, 8 Sep 1998 09:38:51 +0100 (BST) From: Doug Rabson To: Roger Hardiman cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Bt848 driver for Alpha In-Reply-To: <35F3B83B.167E@cs.strath.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Sep 1998, Roger Hardiman wrote: > Hi, > A question on porting the bt848 driver to Alpha hardware. > > Anyway, there are 2 32bit dependent sections > a) memory mapped registers in the bt848 chip > b) RISC code > > > Q) The driver maps the registers (of which the bt848/878 has > around 30) into the memory space and then writes to the registers > as if you were writing to a normal variable (crude example > bt848->register1 = some_value; > bt848->register2 = some_value; > > > Question: Can I write to just a 32 bit register with the Alpha. > (in the same memory mapped way) > Or, does the Alpha sneakilly do a 32 bit read of address n+1 and > then do a 64 bit write. (think some old Alpha chips did this) > > I do not want to go writing to registers I was not intending to write > to. You can write code like this but as you suspected, the alpha will prefetch and buffer up writes in a hardware unfriendly way. What you have to do is change all register access to use the macros read[bwl]/write[bwl]. These do the right thing to ensure that a single transaction is made on the PCI bus. I would suggest something like the ncr driver: ... vm_offset_t bt848; #define REGOFF(x) (bt848 + offsetof(struct bt848_reg, x) #define READREGB(x) readb(REGOFF(x)) #define WRITEREGB(x, v) writeb(REGOFF(x), v) -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Sep 8 12:58:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03556 for freebsd-alpha-outgoing; Tue, 8 Sep 1998 12:58:18 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03551 for ; Tue, 8 Sep 1998 12:58:17 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id NAA06723; Tue, 8 Sep 1998 13:52:03 -0600 (MDT) Date: Tue, 8 Sep 1998 13:52:03 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809081952.NAA06723@narnia.plutotech.com> To: Doug Rabson cc: alpha@FreeBSD.ORG Subject: Re: Bt848 driver for Alpha Newsgroups: pluto.freebsd.alpha In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > On Mon, 7 Sep 1998, Roger Hardiman wrote: > > I would suggest something like the ncr driver: > > ... > vm_offset_t bt848; > > #define REGOFF(x) (bt848 + offsetof(struct bt848_reg, x) > #define READREGB(x) readb(REGOFF(x)) > #define WRITEREGB(x, v) writeb(REGOFF(x), v) Ick. Ick. Ick. Almost all of the CAM code uses the bus space facility to do this. Why re-invent the wheel? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Sep 8 14:07:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13240 for freebsd-alpha-outgoing; Tue, 8 Sep 1998 14:07:56 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA13209 for ; Tue, 8 Sep 1998 14:07:48 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.9.1/8.8.5) with SMTP id WAA15373; Tue, 8 Sep 1998 22:08:06 +0100 (BST) Date: Tue, 8 Sep 1998 22:08:06 +0100 (BST) From: Doug Rabson To: "Justin T. Gibbs" cc: alpha@FreeBSD.ORG Subject: Re: Bt848 driver for Alpha In-Reply-To: <199809081952.NAA06723@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 8 Sep 1998, Justin T. Gibbs wrote: > In article you wrote: > > On Mon, 7 Sep 1998, Roger Hardiman wrote: > > > > I would suggest something like the ncr driver: > > > > ... > > vm_offset_t bt848; > > > > #define REGOFF(x) (bt848 + offsetof(struct bt848_reg, x) > > #define READREGB(x) readb(REGOFF(x)) > > #define WRITEREGB(x, v) writeb(REGOFF(x), v) > > Ick. Ick. Ick. Almost all of the CAM code uses the bus space facility > to do this. Why re-invent the wheel? I wasn't re-inventing anything. I just happened to look at a different wheel. Constructing a bus space around this is trivial (virtually the same as the i386 bus space). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Sep 8 16:21:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04590 for freebsd-alpha-outgoing; Tue, 8 Sep 1998 16:21:28 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04577 for ; Tue, 8 Sep 1998 16:21:26 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id RAA07283; Tue, 8 Sep 1998 17:15:13 -0600 (MDT) Date: Tue, 8 Sep 1998 17:15:13 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809082315.RAA07283@narnia.plutotech.com> To: Doug Rabson cc: alpha@FreeBSD.ORG Subject: Re: Bt848 driver for Alpha Newsgroups: pluto.freebsd.alpha In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Ick. Ick. Ick. Almost all of the CAM code uses the bus space facility >> to do this. Why re-invent the wheel? > > I wasn't re-inventing anything. I just happened to look at a different > wheel. Constructing a bus space around this is trivial (virtually the > same as the i386 bus space). Well, the NCR driver is an MI driver, so it should use MI interfaces to get it's work done. My (incorrect??) assumption was that you were pushing for writeb and friends to become MI interfaces. > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 951 1891 > Fax: +44 181 381 1039 -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Sep 9 01:46:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA08425 for freebsd-alpha-outgoing; Wed, 9 Sep 1998 01:46:51 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA08415 for ; Wed, 9 Sep 1998 01:46:48 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.9.1/8.8.5) with SMTP id JAA17404; Wed, 9 Sep 1998 09:46:44 +0100 (BST) Date: Wed, 9 Sep 1998 09:46:44 +0100 (BST) From: Doug Rabson To: "Justin T. Gibbs" cc: alpha@FreeBSD.ORG Subject: Re: Bt848 driver for Alpha In-Reply-To: <199809082315.RAA07283@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 8 Sep 1998, Justin T. Gibbs wrote: > >> Ick. Ick. Ick. Almost all of the CAM code uses the bus space facility > >> to do this. Why re-invent the wheel? > > > > I wasn't re-inventing anything. I just happened to look at a different > > wheel. Constructing a bus space around this is trivial (virtually the > > same as the i386 bus space). > > Well, the NCR driver is an MI driver, so it should use MI interfaces > to get it's work done. My (incorrect??) assumption was that you were > pushing for writeb and friends to become MI interfaces. I used inx/outx and readx/writex to get the port up and running quickly without having to spend huge quantities of effort changing drivers. Of course I will implement the bus_space api when CAM goes in. I will still need to support inx/outx for non-CAM drivers though unless CAM converts all of them to bus_space. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Sep 9 03:44:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA20558 for freebsd-alpha-outgoing; Wed, 9 Sep 1998 03:44:34 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA20552 for ; Wed, 9 Sep 1998 03:44:29 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.9.1/8.8.5) with SMTP id LAA17741 for ; Wed, 9 Sep 1998 11:44:52 +0100 (BST) Date: Wed, 9 Sep 1998 11:44:52 +0100 (BST) From: Doug Rabson To: freebsd-alpha@FreeBSD.ORG Subject: Shared libs on alpha Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For anyone experimenting with FreeBSD/alpha at the moment, please avoid trying to use shared libraries for the next couple of days and keep your systems static. The nice folks at Cygnus have managed to change the shared object format in such a way that shared executables and libs linked eith binutils-2.8.1 are totally incompatible with those linked with binutils-2.9.1. Since we haven't released anything yet, I will only be supporting the 2.9.1 format in rtld but I have some more testing to do before I can commit that so stay static for the next few days. For any of the NetBSD folks reading this list, be warned that you will get grief from binutils if/when you upgrade your toolchain to binutils-2.9.1. To be specific, the PLT format has changed and you will probably need two versions of _rtld_bind_start for the new and old formats :-(. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Sep 11 11:33:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11196 for freebsd-alpha-outgoing; Fri, 11 Sep 1998 11:33:49 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11191 for ; Fri, 11 Sep 1998 11:33:46 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.9.1/8.8.5) with SMTP id TAA25942 for ; Fri, 11 Sep 1998 19:34:41 +0100 (BST) Date: Fri, 11 Sep 1998 19:34:41 +0100 (BST) From: Doug Rabson To: freebsd-alpha@FreeBSD.ORG Subject: Re: Shared libs on alpha In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 9 Sep 1998, Doug Rabson wrote: > For anyone experimenting with FreeBSD/alpha at the moment, please avoid > trying to use shared libraries for the next couple of days and keep your > systems static. The nice folks at Cygnus have managed to change the > shared object format in such a way that shared executables and libs linked > eith binutils-2.8.1 are totally incompatible with those linked with > binutils-2.9.1. > > Since we haven't released anything yet, I will only be supporting the > 2.9.1 format in rtld but I have some more testing to do before I can > commit that so stay static for the next few days. > > For any of the NetBSD folks reading this list, be warned that you will get > grief from binutils if/when you upgrade your toolchain to binutils-2.9.1. > To be specific, the PLT format has changed and you will probably need two > versions of _rtld_bind_start for the new and old formats :-(. It should now be safe to build shared libs and dynamic executables on alpha. Make sure rtld-elf is up to date before trying to run any shared executables. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message