[U-Boot-Users] Status of the AVR32 u-boot patches

[Ulf Samuelsson]

> On Fri, 25 Aug 2006 12:42:46 +0200
> "Ulf Samuelsson" <ulf at atmel.com> wrote:
> 
>> > Hi Wolfgang,
>> > 
>> > I just noticed Ulf claiming that we (Atmel Norway) have submitted
>> > patches for AVR32 support. That is not correct as far as I know, and
>> > I'm the one sitting on the patches. So you can probably stop
>> > looking ;)
>> > 
>> No, I have been told by someone else in Norway it happend, and this
>> guys was obviously misinformed I wanted to check if it was true
>> (Notice the "is this correct" question).
> 
> Ok, I guess someone must have misunderstood something.
> 
>> I have put the AT91 memory drivers
>> * at45.c->at45dbxxx.c
> 
> Hmmm...what's wrong with drivers/dataflash.c?

You might as well ask why use IP; then you have TCP :-)
Dataflash.c is on top of at45dbxxx.c

> 
> Note that I haven't tried the dataflash driver myself, as the STK1000
> doesn't have a dataflash chip.
> 
>> * flash.c->at49bvxxx.c
> 
> Ideally, that should be supported by drivers/cfi_flash.c. But I didn't
> have much success with it either, and I noticed that several boards use
> their own flash driver.
> 
>> * nand.c
> 
> Ok, maybe we'll get one of those in the future.
> 
>> and the dm9161a.c
> 
> Hmmm...looks like a pretty basic MII-compatible PHY to me. Maybe it's
> time to introduce a generic MII framework into u-boot?
> 
> There are probably other drivers that can be consolidated as well. The
> mmc, hsdramc, hsmc and pio drivers come to mind.
> 
>> but since Wolfgang does not like
>> the idea of distributing things, I'm in between chairs at the moment.
>> I can send you the source files and then you can include them in your
>> patch. I guess it does not hurt having source available before use.
> 
> Yeah, I'd like to have a look at those drivers. I won't include them in
> any other patches though, as I think drivers should be posted as
> separate patches.
> 
>> You may want to update the files, because today they configure based
>> on different AT91 chips. Maybe a CONFIGURE_ATMEL ??
> 
> Ok, we'll have to think of something. I'll have a look and see if we
> can abstract the configuration options somehow.
> 
>> Probably, it is a good idea to put most of the Atmel Rousset
>> peripheral drivers in an "board/atmel/common" directory as well.
> 
> I thought drivers were supposed to go in the "drivers" subdirectory? ;)

Some are in the board directory, some are in the cpu directory and some are in the drivers directory today.
The lowest level seems to be in the CPU directory, but if generic, 
it makes more sense in atmel/common.

> 
> Haavard