From owner-freebsd-arm@FreeBSD.ORG Sat Mar 10 16:43:28 2007 Return-Path: X-Original-To: freebsd-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 58E6016A405; Sat, 10 Mar 2007 16:43:28 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 177F413C4A8; Sat, 10 Mar 2007 16:43:28 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2AGhKV8029518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Mar 2007 08:43:23 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <45F2E028.4080907@errno.com> Date: Sat, 10 Mar 2007 08:43:20 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: John Hay References: <20070228102459.GB28669@zibbi.meraka.csir.co.za> <45E5A73E.20503@errno.com> <20070228.094155.660269855.imp@bsdimp.com> <20070305194018.GA73100@zibbi.meraka.csir.co.za> <45ECBA38.7030607@errno.com> <20070306064715.GA3932@zibbi.meraka.csir.co.za> <45F084C5.8020601@errno.com> <20070309064843.GA3384@zibbi.meraka.csir.co.za> <45F19438.5030109@errno.com> <20070310123835.GA83779@zibbi.meraka.csir.co.za> In-Reply-To: <20070310123835.GA83779@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Olivier Houchard Subject: Re: redboot based boot loader for kernels? 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: Sat, 10 Mar 2007 16:43:28 -0000 John Hay wrote: >>> Well in effect I only get half of the bytes, but not the first or second >>> half. With every 16 bit read I get 2 bytes. But some are missing. So if >>> the start of the sector on the disk looks like this: >>> >>> 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 >>> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>> >>> What I read is this: >>> >>> 01 02 >>> 05 06 >>> 09 10 >>> 13 14 >>> 17 18 >>> 21 22 >>> 25 26 >>> 29 30 >>> >>> So after 128 reads you start to read zeros because all the data has been >>> read. >> So you're reading 4 bytes at a time, swab'ing 'em, then taking only 2. > > Yip, and now after finishing most of the other stuff in my boot2 program, > I decided to look at the 16 bit mode again... And it was working without > me doing anything. Hmmm I know I have twiddled some of the compile > options in my makefile... Maybe it was that. Ha, time heals all code :) > >>> In another email you asked: >>> >>>> I'm probably wrong and it would explain some issues we had with reset. >>>> Feel free to send us a patch. I know I used both the appnote and the >>>> linux driver as a basis for avila_ata.c ... >>> I'll have a look at it as soon as I am happy with my boot2 loader. I'll >>> just have to figure out how to map CS2. At the moment only CS1 is mapped, >>> but for ALT_STATUS and DRV_CNTRL you need CS2. >> Look in ixp425.c for the CS1 entry. Add CS2 and map it in the driver. >> But I'm not sure how to deal with gluing this into the ata driver unless >> you can just special case those registers and fetch from the alternate >> map'd area. All this is kinda surprising as I did a bunch of tests on >> my cf w/o seeing any issues--but I'm certainly no ata expert. > > Everywhere in the Intel appnote (302456-003) where they describe "True > IDE Mode", they say that they implemented it with CS1 and CS2. The > register set wrap around on an 8 byte boundary and I think we have just > been lucky that a write to 0x1e actually went to the ATA_DRIVE register > and didn't cause any problems. But the CF is then not really reset. This > probably didn't matter too much because the CF is in a pretty sane state. Olivier and I saw occasional complaints about not being able to reset the part but otherwise it seemed the driver worked fine (and when the complaints stopped we stopped looking). I thought I also verified the register writes against the operation of the linux driver but patches to fix this would be welcome. > > Something else, appart from the Avila boards, I also have a Pronghorn > Metro from Adi Engineering. It is very similar to the Avila software > wise. The 2 main differences that I have found is, they use the other > serial port for the console and they used CS3 and CS4 for the IDE/CF > card. It seems silly to make a whole new kernel config for it. Would > it be acceptable if one could detect the board type somehow on startup > and use that to select the correct serial port and chip selects for > the CF? The console seems like something to specify with hints unless you can auto-detect. Regarding ata maybe you can map CS3 and CS4 too and try probing both places. > > One last thing, I see that npe0 and npe1 use the same mac address. The > uClinux that came installed use 2 different addresses: > ixp400_eth: Using MAC address 00:d0:12:02:87:10 for port 0 > ixp400_eth: Using MAC address 00:d0:12:12:87:10 for port 1 > > Not sure where they get it though. The mac is read from the h/w. If they are the same then it's likely confusion mapping the npe's. That part of the driver needs to use hints and/or better auto-config (though I'm not sure if it's possible to identify different xscale boards/configs). Sam