From owner-freebsd-arm@FreeBSD.ORG Fri Jun 8 06:14:22 2007 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C66016A421 for ; Fri, 8 Jun 2007 06:14:22 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id 2B36D13C46C for ; Fri, 8 Jun 2007 06:14:22 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de ([195.225.132.203]) by localhost (liberty-mail [195.225.132.203]) (amavisd-new, port 10024) with ESMTP id 52954-08; Fri, 8 Jun 2007 08:14:17 +0200 (CEST) Received: from home.alpha-tierchen.de (port-212-202-170-5.dynamic.qsc.de [212.202.170.5]) by mail.liberty-hosting.de (Postfix) with ESMTP id 7DBB2180FE8; Fri, 8 Jun 2007 08:14:17 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id 8EF4945046; Fri, 8 Jun 2007 08:14:16 +0200 (CEST) Received: from 2001:6f8:101e:0:20e:cff:fe6d:6adb (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Fri, 8 Jun 2007 08:14:16 +0200 (CEST) Message-ID: <60893.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181283256.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20070607.140054.74667648.imp@bsdimp.com> References: <49754.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181244172.squirrel@webmail.alpha-tierchen.de> <20070607.133456.74668036.imp@bsdimp.com> <20070607123930.E75948@synthcom.com> <20070607.140054.74667648.imp@bsdimp.com> Date: Fri, 8 Jun 2007 08:14:16 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: arm@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at mail.smartterra.de Cc: ticso@cicely12.cicely.de Subject: Re: 4-bit SD Card mode X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2007 06:14:22 -0000 Warner Losh skrev: > My hardware guys are somewhat agressive in their elimination of > "unused" lines. We multiplex TX/RX from one of the serial ports to be > GPIO lines dynamically at run time depending on what add-in hardware > is connected to the box. I want to keep things as flexible as > possible because I know that other designs are doing similar "icky" > things. Ok, I thought about the topic a bit over night. On the one hand I understand your concern that we can't probe for pins whether they are connected or not; this characterises a significant difference between embedded hardware and PC hardware. On the other hand the problem remains if we make the loader responsible for configuring the PIO controller, because board-specific configuration is necessary in any case. Shifting a task is not a solution, especially if we want to stay independend of the loader. I understand the loader as a very small piece of software for bootstraping. Usually it is lean and mean as much as possible and does only things that are really necessary to go on with loading the operating system, not to be able using specific hardware. Actually neither the loader nor the kernel is responsible for making those kind of decisions, but rather the user has to attend this duty. Since the FreeBSD kernel is more flexible and highly configurable in contrast to any loader I still hold the view that the kernel should give the ability to configure the PIO controller. I agree with you that it is impossible and unjustifiable to make unprovable assumptions about the hardware that may cause damage or unexpected behaviour (I like to apologise for suggesting such code ;-). The best solution that I see is to provide a way to specify the hardware without patching the kernel and without requiring special bits from the loader. This should happen directly or indirectly in the kernel configuration file. I'm still concerned about this, so I'll provide some code that takes your objection into account. Regards Björn