From owner-freebsd-arm@FreeBSD.ORG Tue Mar 24 12:16:09 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 36B6C106564A for ; Tue, 24 Mar 2009 12:16:09 +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 BD9D28FC1A for ; Tue, 24 Mar 2009 12:16:08 +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 n2OCG7xq044427; Tue, 24 Mar 2009 13:16:07 +0100 (CET) (envelope-from antab@freebsd.org) Message-Id: <00675D70-A3F9-412F-BDB9-F9CF8C91D75A@freebsd.org> From: Arnar Mar Sig To: Sylvestre Gallon In-Reply-To: <164b4c9c0903240210v4d05770du1f02de26f42f6454@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 13:16:07 +0100 References: <164b4c9c0903231301p754eebb7k84ea2b22d7b60dc1@mail.gmail.com> <8BC7AFF2-E0E1-4498-82E8-29C3F64C5E2E@FreeBSD.org> <164b4c9c0903240210v4d05770du1f02de26f42f6454@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-arm@freebsd.org 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 12:16:09 -0000 On Mar 24, 2009, at 10:10 AM, Sylvestre Gallon wrote: > On Tue, Mar 24, 2009 at 3:45 AM, Arnar Mar Sig > wrote: >> >> 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 > > Thanks :) > >> >>> >>> 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). > > I don't found it in the source tree. Where it is located ? If you > wan't the > smc register description you can take a look at this datasheet in > chapter 22: > > http://www.atmel.org/dyn/resources/prod_documents/doc6242.pdf > > The smc is not used in the patch yet but I will need to use it for the > implement the dm9000 driver (because this chip is attach on the 2nd > channel of the smc) Code is in p4: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/avr32/src/sys/avr32/avr32&HIDEDEL=NO Note the driver dose not use KVA, instead it uses unmapped memory segment in avr32, but that only works for 5 of the 6 chips select so it will be needed later on. > >> >>> - 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? >> > > Yes here we can use hints to factorise a lot of code like > a big part of the code where the #ifdef AT91SAM9261 are. > But like M. Warner Losh said I think that one needs a .c > by SoC to put the cpu_devs structure, the pmap_devmap > structure and the errata code. We need to put this in a specific > files because these code are dependant of the SoC. cpu_devs can be in hints, but i dont know about pmap_devmap. on avr32 all devices registers can be addressed without mmu lookups. > > Cheers, > > -- > Sylvestre Gallon (http://devsyl.blogspot.com) > Fifth Grade Student @ Epitech & Researcher @ LSE > R&D @ Rathaxes (http://www.rathaxes.org) > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"