[U-Boot-Users] Status of the AVR32 u-boot patches
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
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@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@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
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
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
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
participants (2)
-
Haavard Skinnemoen -
Ulf Samuelsson