Re: [U-Boot-Users] [PATCH] AT91SAM9263 Board files
I'm not sure if you want to demonstrate something, and what, by dumping to the mailing list such a list of "patches" that are no patches at all because they violate all formal requirements as layed down in the README. The rules are not there just for fun, but to allow reviewing of the submitted code, and to make integration as easy as possible. You leave me no choice but to reject your submissions, or anybody could quote a precedent from this.
And I think you knew this before.
So why?
No, I don't want to demonstrate anything. I would like U-Boot to include board support for the current AT91 boards. The AT91 product line says that they have no time to spend.
The Atmel patches are based on U-Boot-1.1.5 and if I do "diff -purN" between 12.1.5 and the Atmel version I get around 1 MB of uncompressed patches.
There are even files there which are larger than the mailing list limit. The CPU header files are ~ 100-200 kB. The USB host support is > 40 kB. This means that I cannot supply everything as a patch. I *must* due to the size of the patch supply as several patches, each below 40 kB. I wrote an application which splits a large file into one patch per file in the target system, so all patches can be applied in any order. The Atmel U-Boot contains 4 new boards, and the patch for Makefile and MAKEALL contains all four boards. If that needs to be split up into 4 patches, then there have to be a patch order for those two files.
The main part of the patches are support for:
* Atmel ARM926 based CPUs "cpu/arm926ejs/at91sam926x" directory. * Moving at45.c dataflash driver from the board directories to the "driver" directory. * Board support for 4 new boards. - at91rm9200ek - at91sam9260ek - at91sam9261ek - at91sam9263ek
On top of the official patches, I would like to add some of my own including
* Different partitioning of the dataflash, so that it is compatible with linux-2.6 and not linux-2.4. * "cmp" support for dataflash * "crc" support for dataflash * New board "at91rm9200df" * block erase of dataflash (faster erase of large blocks)
Moving the dataflash to the "driver" directory will break all boards which has the dataflash driver in the board directory. When I checked, I think there are 3-4 boards in the current distribution which will be affected.
In the end I would like to move all boards down to the "board/atmel" directory at the end of the
I think it would be easier if we broke down things into smaller parts. First I would like to move of the dataflash support to the driver directory.
Then adding patches for the ARM926 based cpu/board directories, but without any references to these patches in Makefiles/MAKEALL. At the end a patch which would make them buildable.
This would during a short period give some "dangling" or unused code I know you don't like that, so how proceed with such a large patchset, where things depend on each other?
I dont have any git server which I can use for this. Will try to get access to www.atmel.no like Haavard but I do not know know if it is possible and if it is, when it is possible.
Best regards,
Wolfgang Denk
Best Regards, Ulf Samuelsson ulf@atmel.com GSM: +46 (706) 22 44 57 Tel: +46 (8) 441 54 22 Fax: +46 (8) 441 54 29 Mail: Box 2033 174 02 Sundbyberg Visit: Kavallerivägen 24 174 58 Sundbyberg' Sweden
In message 022e01c74631$4177caa0$01c4af0a@atmel.com you wrote:
There are even files there which are larger than the mailing list limit. The CPU header files are ~ 100-200 kB. The USB host support is > 40 kB.
...uncompressed, I guess.
This means that I cannot supply everything as a patch. I *must* due to the size of the patch supply as several patches, each below 40 kB.
right. so (1) compress it, and (2) create a series of numbered patches as everybody else is doing this.
I wrote an application which splits a large file into one patch per file in the target system, so all patches can be applied in any order. The Atmel U-Boot contains 4 new boards, and the patch for Makefile and MAKEALL contains all four boards.
No. The support for each board should be separated and sumbitrted independently, i. e. each patch will add just one target to Makefile and MAKEALL. Please see the patch requirements in the README.
If that needs to be split up into 4 patches, then there have to be a patch order for those two files.
Yes, of course.
- "cmp" support for dataflash
- "crc" support for dataflash
Don't bother about this. It will not be accepted.
In the end I would like to move all boards down to the "board/atmel" directory at the end of the
That would be good [and needs no significant patch size, as git is clever enough to recognize file renames and just includes meta information in the patches it creates].
I think it would be easier if we broke down things into smaller parts.
Yes, it is. But a patch is a patch, not a tarball, and it has a description, a changelog, and eventually a sequence number. Please see the README.
First I would like to move of the dataflash support to the driver directory.
I'm not sure this makes sense, given the fact that this will be soon (?) reworked.
Then adding patches for the ARM926 based cpu/board directories, but without any references to these patches in Makefiles/MAKEALL. At the end a patch which would make them buildable.
No. Each patch is supposed to be independent of the others. It should be possible to apply only the first N patches of your sequenbce and get a useful, buildable code version - otherwise you will always have to rework the whole sequence if patch N+1 gets rejected for a reason or another.
But all this is documented in the README.
This would during a short period give some "dangling" or unused code I know you don't like that, so how proceed with such a large patchset, where things depend on each other?
Split it in orthogonal chunks. That's what they do with Linux, and what we have been doing with U-Boot for a long, long time.
I dont have any git server which I can use for this.
You don't need a git server. Use a local repositoy, and git to create the patches.
Will try to get access to www.atmel.no like Haavard but I do not know know if it is possible and if it is, when it is possible.
It's not needed.
Best regards,
Wolfgang Denk
I think it would be easier if we broke down things into smaller parts.
Yes, it is. But a patch is a patch, not a tarball, and it has a description, a changelog, and eventually a sequence number. Please see the README.
First I would like to move of the dataflash support to the driver directory.
I'm not sure this makes sense, given the fact that this will be soon (?) reworked.
It is the driver for dataflash, and the planned changes are things put on top of the driver. I am not talking about the memory commands. The stuff is already there in the AT91SAM926 patches and this means that if there are any changes, they will be in a single place instead of one patch per board.
Then adding patches for the ARM926 based cpu/board directories, but without any references to these patches in Makefiles/MAKEALL. At the end a patch which would make them buildable.
No. Each patch is supposed to be independent of the others. It should be possible to apply only the first N patches of your sequenbce and get a useful, buildable code version - otherwise you will always have to rework the whole sequence if patch N+1 gets rejected for a reason or another.
What I mean is that I want to start with creating the cpu/arm926ejs/at91sam926x directory and associated includes. All the AT91SAM926x boards use this. Before the boardpatches are submitted, this will be a dangling patch since no board depends on it.
It will be a little easier to do the board patches if the cpu support is there.
But all this is documented in the README.
This would during a short period give some "dangling" or unused code I know you don't like that, so how proceed with such a large patchset, where things depend on each other?
Split it in orthogonal chunks. That's what they do with Linux, and what we have been doing with U-Boot for a long, long time.
I dont have any git server which I can use for this.
You don't need a git server. Use a local repositoy, and git to create the patches.
I was thinking of the problem of size. The AT91SAM9263 header > 40 kB bzip2 compressed.
I assumed that if I use a git from where people can pull I can have larger patches, but that might be a mistake.
Will try to get access to www.atmel.no like Haavard but I do not know know if it is possible and if it is, when it is possible.
It's not needed.
Best regards,
Wolfgang Denk
Best Regards, Ulf Samuelsson ulf@atmel.com GSM: +46 (706) 22 44 57 Tel: +46 (8) 441 54 22 Fax: +46 (8) 441 54 29 Mail: Box 2033 174 02 Sundbyberg Visit: Kavallerivägen 24 174 58 Sundbyberg' Sweden
On 2/2/07, Ulf Samuelsson ulf@atmel.com wrote:
Then adding patches for the ARM926 based cpu/board directories, but without any references to these patches in Makefiles/MAKEALL. At the end a patch which would make them buildable.
No. Each patch is supposed to be independent of the others. It should be possible to apply only the first N patches of your sequenbce and get a useful, buildable code version - otherwise you will always have to rework the whole sequence if patch N+1 gets rejected for a reason or another.
What I mean is that I want to start with creating the cpu/arm926ejs/at91sam926x directory and associated includes. All the AT91SAM926x boards use this. Before the boardpatches are submitted, this will be a dangling patch since no board depends on it.
I think this makes sense. Adding support for a CPU is one logical change. If it gets used by a board patch later in the series, what's the problem?
Combining it with a board patch means that the series will have to be reworked if either of them changes. And it becomes very difficult to obey the size restrictions.
It will be a little easier to do the board patches if the cpu support is there.
Exactly.
But all this is documented in the README.
A bit OT: Would it make sense to split up the README a bit? For example, pull the patch submission rules out and put it into doc/SubmittingPatches or something? Similarly with the coding style rules and the CONFIG/CFG macro documentation. I think this would make it easier for everyone to get an overview of what documentation is really available and maybe more people would actually read the rules?
This would during a short period give some "dangling" or unused code I know you don't like that, so how proceed with such a large patchset, where things depend on each other?
Split it in orthogonal chunks. That's what they do with Linux, and what we have been doing with U-Boot for a long, long time.
I think board and cpu support _are_ two orthogonal chunks.
I dont have any git server which I can use for this.
You don't need a git server. Use a local repositoy, and git to create the patches.
I was thinking of the problem of size. The AT91SAM9263 header > 40 kB bzip2 compressed.
A header file (or really any single files) which weighs in at more than 40k compressed is just wrong. The at91 u-boot people need to talk more with the Linux people -- the at91 Linux headers are a lot more sane.
Register definitions for specific hardware modules should be split out into separate files IMO. For example, the USART definitions are redundant with drivers/atmel_usart.h anyway.
I think we should become better at collaborating on u-boot drivers between the avr32 and arm departments in Atmel. We're already doing this with Linux -- several drivers are already shared between avr32 and at91, e.g. atmel_serial and atmel_spi (which I'm hoping will go in during the 2.6.21 merge window.) I'll try to contact whoever is in charge of u-boot in the at91 departement and see if I can get the ball rolling on a joint effort to consolidate some of the at91 and avr32 stuff.
I assumed that if I use a git from where people can pull I can have larger patches, but that might be a mistake.
I think the size of the patches is more of an indicator that something is wrong. But I also think that if an oversize patch is otherwise ok we shouldn't let the size rule block it iff the coding style rules and the rule about single logical changes are being followed.
In Linux, oversize patches are usually posted at a public webserver with a link to it in the e-mail unless they have been fully reviewed and are sent to Linus for inclusion (without Cc to lkml.)
Btw, I don't really have anything to do with arm or at91, so feel free to ignore my advise.
Haavard
participants (3)
-
Haavard Skinnemoen -
Ulf Samuelsson -
Wolfgang Denk