From owner-freebsd-arm@FreeBSD.ORG Tue Mar 24 11:59:13 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC76A106566C for ; Tue, 24 Mar 2009 11:59:13 +0000 (UTC) (envelope-from antab@freebsd.org) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id 4EBBB8FC0A for ; Tue, 24 Mar 2009 11:59:12 +0000 (UTC) (envelope-from antab@freebsd.org) Received: from dumb.farm.antab.is (farm.antab.is [80.101.60.195]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id n2OBxBvG036004 for ; Tue, 24 Mar 2009 12:59:11 +0100 (CET) (envelope-from antab@freebsd.org) Resent-Message-Id: <200903241159.n2OBxBvG036004@smtp-vbr19.xs4all.nl> Resent-To: freebsd-arm@freebsd.org From: Arnar Mar Sig To: "M. Warner Losh" In-Reply-To: <20090323.213840.1631944207.imp@bsdimp.com> Resent-From: Arnar Mar Sig References: <164b4c9c0903231301p754eebb7k84ea2b22d7b60dc1@mail.gmail.com> <8BC7AFF2-E0E1-4498-82E8-29C3F64C5E2E@FreeBSD.org> <20090323.213840.1631944207.imp@bsdimp.com> Message-Id: <43AF275A-D9D1-4A50-B28E-8DFD43679434@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Resent-Date: Tue, 24 Mar 2009 12:59:11 +0100 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 12:39:08 +0100 X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Subject: Re: Atmel at91sam9261-ek support. 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: Tue, 24 Mar 2009 11:59:14 -0000 On Mar 24, 2009, at 4:38 AM, M. Warner Losh wrote: > In message: <8BC7AFF2-E0E1-4498-82E8-29C3F64C5E2E@FreeBSD.org> > Arnar Mar Sig writes: > : > : On Mar 23, 2009, at 9:01 PM, Sylvestre Gallon wrote: > : > Hi freebsd-arm@ > : > > : > I've got an access to an at91sam9261-ek. This board have a > : > at91sam9261 soc that is near the at91rm9200, so I start a > : > little port of it into FreeBSD. So I work 3 days on it and that > : > results in a Big patch that allow the board to boot. > : Nice work > : > : > > : > As you can see in the dmesg, for the moment the system > : > hangs, but it is normal (I haven't yet finish the implementation > : > of the dm9000 ethernet driver so NFS don't find any ethernet > : > interface and panic). > : > > : > > : > This big diff contains : > : > - an AT91SAM9261EK conf file. > : > - an std.at91sam9261ek file. > : > - a begin of dme driver (dm9000 ethernet chip driver). I > : > will work this week on it to send you another diff that > : > complete this driver :) > : > - a board_at91sam9261ek.c file. > : > - an include for at91sam9261 registers. > : > - a new watchdog driver (at91_wdt) > : > - a new smc driver (static memory controller) > : Looks like the at91sam9261 uses the same SMC core as at32ap700x, we > : should look into using the same driver for both archs. I already > have > : at32_smc in p4 to do bus managment and attach childs but no setup > code > : (already done in uboot for what i need). > : > : > - a new pit driver (periodic interval timer) > : > > : > There is a lot of little modification on the at91 existing > : > sources. > : > > : > As you can see in the diff I work for the moment on a > : > define way to separate the two soc code that differ. But I > : > think that in the future a .c for each soc should appear. > : What about using hints more for device wiring instead of .c code > like > : i did for avr32? > > The trouble is that we'd need varadic hints. That is, hints that vary > based on which SoC you're running on. We don't have those yet. > Wouldn't be terribly hard to implement though... Well, building kernel for different SoC dosen't look to be supported at the moment anyway. On i386/amd64 dosen't the loader load /boot/devices.hints for additional hints not found in the kernel? Would it not make more sense to have loader on arm/avr32 (or patch uboot) to store and load SoC hints for that given chip+board instead of storing everything in the kernel? The code for cpu_devs in atmelarm does the same with the same info as i do with hints for at32bus. I got conf/cpu/.hints for a given SoC thats included in the kernel config, plus board level hints file for onboard flash and geom slicing of the flash thru hints. > > Also, we need a generic base-class for all busses in the system that > dole out resources so that each new system is more like 20-30 lines of > code rather than the few hundred of cut and paste they are today. Ohh yeah. copying the same code over and over is not that nice:) Arnar Mar Sig