Date: Mon, 23 Mar 2009 21:38:40 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: antab@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: Atmel at91sam9261-ek support. Message-ID: <20090323.213840.1631944207.imp@bsdimp.com> In-Reply-To: <8BC7AFF2-E0E1-4498-82E8-29C3F64C5E2E@FreeBSD.org> References: <164b4c9c0903231301p754eebb7k84ea2b22d7b60dc1@mail.gmail.com> <8BC7AFF2-E0E1-4498-82E8-29C3F64C5E2E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <8BC7AFF2-E0E1-4498-82E8-29C3F64C5E2E@FreeBSD.org>
Arnar Mar Sig <antab@freebsd.org> 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...
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.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090323.213840.1631944207.imp>