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

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

[Haavard Skinnemoen]

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 ;)

We do intend to do so, though, so the other claim that we're "ignoring
the main U-boot tree" is not correct either. It's just that we've stuck
to point releases so far.

Now that blackfin has "stolen" our architecture number, I guess it's
time to get moving. Changing the architecture ID will probably break a
lot of setups, but I guess it's better to do a clean break now, handle
the additional support requests, and be done with it.

I'll start folding and rebasing the patches against the master branch
next week, so I'll probably have some patches ready for you in a few
days. What's the best way to split them up? Separate patches for
everything? Maybe I should combine the arch patch with support for one
CPU and one board so that it's possible to actually build the result?
I'll submit the drivers separately anyway.

Ulf, I appreciate your efforts getting AVR32 support into u-boot. The
"drivers/atmel" thing looks interesting -- have you consolidated any of
the drivers yet?

Haavard

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

[Ulf Samuelsson]

> 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).

> We do intend to do so, though, so the other claim that we're "ignoring
> the main U-boot tree" is not correct either. It's just that we've stuck
> to point releases so far.

More the AT91 group than you...
 
> Now that blackfin has "stolen" our architecture number, I guess it's
> time to get moving. Changing the architecture ID will probably break a
> lot of setups, but I guess it's better to do a clean break now, handle
> the additional support requests, and be done with it.
> 
> I'll start folding and rebasing the patches against the master branch
> next week, so I'll probably have some patches ready for you in a few
> days. What's the best way to split them up? Separate patches for
> everything? Maybe I should combine the arch patch with support for one
> CPU and one board so that it's possible to actually build the result?
> I'll submit the drivers separately anyway.
> 
> Ulf, I appreciate your efforts getting AVR32 support into u-boot. The
> "drivers/atmel" thing looks interesting -- have you consolidated any of
> the drivers yet?

I have put the AT91 memory drivers
* at45.c->at45dbxxx.c
* flash.c->at49bvxxx.c
* nand.c
and the dm9161a.c 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.
You may want to update the files, because today they configure based on different AT91 chips.
Maybe a CONFIGURE_ATMEL ??

Probably, it is a good idea to put most of the Atmel Rousset peripheral drivers in 
an "board/atmel/common" directory as well.

> 
> Haavard


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR  link: www.avrfreaks.net

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

[Haavard Skinnemoen]

On Fri, 25 Aug 2006 12:42:46 +0200
"Ulf Samuelsson" <ulf@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?

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? ;)

Haavard

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

[Ulf Samuelsson]

> On Fri, 25 Aug 2006 12:42:46 +0200
> "Ulf Samuelsson" <ulf@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

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

[Haavard Skinnemoen]

On Fri, 25 Aug 2006 19:45:11 +0200
"Ulf Samuelsson" <ulf@atmel.com> wrote:

> > On Fri, 25 Aug 2006 12:42:46 +0200
> > "Ulf Samuelsson" <ulf@atmel.com> wrote:
> >> 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

Ok, I see. Now that I look closer, dataflash.c looks awfully
board-specific. I think it would actually make more sense to put the
low-level stuff into drivers (which, if I understand correctly, is what
you want to do) and move some of the code in dataflash.c into boards/foo

For example, it looks to me lilke the area_list[] and cs[] stuff makes
the dataflash.c code unusable for AT32STK1000 and probably other AT91
boards as well.

Maybe it would make sense to move the detection logic into the low-level
driver as well.

> >> 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.

That seems to be how it's done in practice, yes. But I don't understand
what the rules are for which drivers go into boards/foo and which go
into drivers. Can someone fill me in?

IMO drivers that are used by more than one board and/or CPU should go
into drivers, but please correct me if I'm wrong.

Haavard

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

[Ulf Samuelsson]

Haavard,
Your  "-gstabs" -> "-g"
patch breaks the build
of the ARM version of U-boot.

You should check if the
build is for an AVR32
and then use "-g"
otherwise use "-gstabs".

Please update your patch.

Best Regards
Ulf Samuelsson

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

[Haavard Skinnemoen]

On 8/31/06, Ulf Samuelsson <ulfs@dof.se> wrote:
>
> Haavard,
> Your  "-gstabs" -> "-g"
> patch breaks the build
> of the ARM version of U-boot.

That's interesting...I did actually run the MAKEALL script on ARM
before I submitted the patch. Out of curiosity, in what way does it
break?

> You should check if the
> build is for an AVR32
> and then use "-g"
> otherwise use "-gstabs".

Ok, I'll do that. I just thought it looked strange to force "stabs"
debugging format on all arches, but if it breaks stuff not doing it, I
guess we should keep it the way it is on all arches but AVR32.

> Please update your patch.

I'll submit a new patch tomorrow. Thanks for testing.

Btw, why are you replying to this thread instead of the actual patch submission?

Haavard