Atmel at91sam9261-ek support.

[Arnar Mar Sig]

On Mar 24, 2009, at 4:38 AM, M. Warner Losh wrote:

> In message: <8BC7AFF2-E0E1-4498-82E8-29C3F64C5E2E at FreeBSD.org>
>           Arnar Mar Sig <antab at 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...
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/<chip>.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