[U-Boot-Users] Re: [PATCH] Cleanup cpu/arm920t using SoC
In message 4120DD8B.8040709@imc-berlin.de you wrote:
- Patch by Steven Scholz, 16 Aug 2004:
- Introducing the concept of SoCs "./cpu/$(CPU)/$(SOC)"
- creating subdirs for SoCs ./cpu/arm920t/imx and ./cpu/arm920t/s3c24x0
- moving SoC specific code out of cpu/arm920t/ into cpu/arm920t/$(SOC)/
- moving drivers/s3c24x0_i2c.c and drivers/serial_imx.c out of drivers/ into cpu/arm920t/$(SOC)/
Added, thanks.
Please feel free to go on now with the next step of cleanup. And sorry it took so long.
Viele Grüße,
Wolfgang Denk
Hi,
here http://www.dave-tech.it/download/misc/sw/edb93xx/u-boot-edb93xx-3 is available for download a patch for Cirrus Logic EDB93xx. It has been tested on EDB9312. This patch is based on current CVS repository so it exploits Steven Scholz's SoC patch. See the attachment for the CHANGELOG.
Best regards,
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
In message 6.0.1.1.0.20041012151214.01e803d0@192.168.2.1 you wrote:
here http://www.dave-tech.it/download/misc/sw/edb93xx/u-boot-edb93xx-3 is available for download a patch for Cirrus Logic EDB93xx. It has been tested on EDB9312. This patch is based on current CVS repository so it exploits Steven Scholz's SoC patch. See the attachment for the CHANGELOG.
Sorry, but I reject this patch. It violates too many of the Coding Style requirements (C++ comments, trailing white space, no TABs for indentation, actually TERRIBLE indentation, etc.)
Please cleanup, reformat (using indent etc.) and resubmit.
Best regards,
Wolfgang Denk
here http://www.dave-tech.it/download/misc/sw/edb93xx/u-boot-edb93xx-3 is available for download a patch for Cirrus Logic EDB93xx. It has been tested on EDB9312. This patch is based on current CVS repository so it exploits Steven
Scholz's
SoC patch. See the attachment for the CHANGELOG.
Sorry, but I reject this patch. It violates too many of the Coding Style requirements (C++ comments, trailing white space, no TABs for indentation, actually TERRIBLE indentation, etc.)
Please cleanup, reformat (using indent etc.) and resubmit.
Hi Wolfgang,
to support this board I used several existing files that were not written following U-Boot coding rules :( Also I don't have the board anymore. I had a look at our web site usage statistics and a lot of people downloaded the patch I released. Anybody can help about cleaning it up?
Generally speaking about patch management, have you ever thought about using BitKeeper to manage U-Boot repository? Thanks to your great effort and to the U-Boot developers, its popularity is growing very fast and I think that patch management task is become really huge. I started working with BitKeeper because Linux 2.6 and I think it could ease this task a lot.
Best regards,
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
In message 6.0.1.1.0.20050118091601.01ba8630@192.168.2.1 you wrote:
Generally speaking about patch management, have you ever thought about using BitKeeper to manage U-Boot repository? Thanks to your great effort and
No. U-Boot is a Free Software project, and we will never make it dependent on a proprietary product withj nsty licensing terms.
to the U-Boot developers, its popularity is growing very fast and I think that patch management task is become really huge. I started working with BitKeeper because Linux 2.6 and I think it could ease this task a lot.
It could if it was usable. But it ain't. It restricts your freedom in an unacceptable way. Did you read the BKL license? [It's difficult to do because it's only readable AFTER installing the product.] Did you read for example section "3. LICENSEE OBLIGATIONS": "(d) No free use for competitors". What if I happen to hack CVS, subversion or arch or any other free frevision control system?
But I am perfectly aware that a system with support for distributed repositories would be beneficial. We will probably try switching to arch.
And while we are at it: another thing that would be useful is a patch database. Any suggestions?
Best regards,
Wolfgang Denk
to the U-Boot developers, its popularity is growing very fast and I
think that
patch management task is become really huge. I started working with
BitKeeper
because Linux 2.6 and I think it could ease this task a lot.
It could if it was usable. But it ain't. It restricts your freedom in an unacceptable way. Did you read the BKL license? [It's difficult to do because it's only readable AFTER installing the product.] Did you read for example section "3. LICENSEE OBLIGATIONS": "(d) No free use for competitors".
I see. I agree this is a very good reason to avoid adopting it.
But I am perfectly aware that a system with support for distributed repositories would be beneficial. We will probably try switching to arch.
Great.
And while we are at it: another thing that would be useful is a patch database. Any suggestions?
The system used by www.arm.linux.org.uk seems very powerful. We could ask Russell about it.
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
Wolfgang Denk wrote:
In message 6.0.1.1.0.20050118091601.01ba8630@192.168.2.1 you wrote:
Generally speaking about patch management, have you ever thought about using BitKeeper to manage U-Boot repository? Thanks to your great effort and
No. U-Boot is a Free Software project, and we will never make it dependent on a proprietary product withj nsty licensing terms.
to the U-Boot developers, its popularity is growing very fast and I think that patch management task is become really huge. I started working with BitKeeper because Linux 2.6 and I think it could ease this task a lot.
It could if it was usable. But it ain't. It restricts your freedom in an unacceptable way. Did you read the BKL license? [It's difficult to do because it's only readable AFTER installing the product.] Did you read for example section "3. LICENSEE OBLIGATIONS": "(d) No free use for competitors". What if I happen to hack CVS, subversion or arch or any other free frevision control system?
But I am perfectly aware that a system with support for distributed repositories would be beneficial. We will probably try switching to arch.
And while we are at it: another thing that would be useful is a patch database. Any suggestions?
Best regards,
Wolfgang Denk
The obvious answer (but not necessarily the correct answer :-) is gforge http://gforge.org/ It says it can use subversion for version control as well as cvs. That doesn't get you your distributed repository, however it does make it an easier switch.
gvb
In message 41ED32F0.3020109@smiths-aerospace.com you wrote:
The obvious answer (but not necessarily the correct answer :-) is gforge http://gforge.org/ It says it can use subversion for version control as well as cvs. That doesn't get you your distributed repository, however it does make it an easier switch.
Subversion is nice, but distributed repositories are essential to me.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 41ED32F0.3020109@smiths-aerospace.com you wrote:
The obvious answer (but not necessarily the correct answer :-) is gforge http://gforge.org/ It says it can use subversion for version control as well as cvs. That doesn't get you your distributed repository, however it does make it an easier switch.
Subversion is nice, but distributed repositories are essential to me.
Best regards,
Wolfgang Denk
Another possibility is Aegis by Peter Miller http://gd.tuwien.ac.at/softeng/Aegis/README.html http://aegis.sourceforge.net/ I have not used it, but have looked it over several times. It looks intriguing. It also looks rather more heavyweight than arch.
I was looking at arch a bit, thinking it should be usable with gforge. A quick google search showed others thought the same thing, including a big thread pointed to in the article "Arch and XMLRPC and BugZilla, posted 8 Aug 2003" (getting pretty old): http://www.advogato.org/article/694.html but the links to the discussions are dead. It also isn't clear what the discussion was (since it is MIA), whether it was gforge or gsoap or bugzilla or ???
gvb
The obvious answer (but not necessarily the correct answer :-) is gforge http://gforge.org/ It says it can use subversion for version control as well as cvs. That doesn't get you your distributed repository, however it does make it an easier switch.
Subversion is nice, but distributed repositories are essential to me. Best regards, Wolfgang Denk
Another possibility is Aegis by Peter Miller http://gd.tuwien.ac.at/softeng/Aegis/README.html http://aegis.sourceforge.net/ I have not used it, but have looked it over several times. It looks intriguing. It also looks rather more heavyweight than arch.
I was looking at arch a bit, thinking it should be usable with gforge. A quick google search showed others thought the same thing, including a big thread pointed to in the article "Arch and XMLRPC and BugZilla, posted 8 Aug 2003" (getting pretty old): http://www.advogato.org/article/694.html but the links to the discussions are dead. It also isn't clear what the discussion was (since it is MIA), whether it was gforge or gsoap or bugzilla or ???
I found this interesting comparison: http://better-scm.berlios.de/comparison/comparison.html
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
Wolfgang Denk wd@denx.de writes:
Subversion is nice, but distributed repositories are essential to me.
http://www.gna.org/ might be a good choice. It supports GNU Arch (it's not hard since it doesn't require a specific server), it has a patch manager, bug tracker etc. (their web interface is Savane, a continuation of Savannah).
Using a distributed versions control software would be a real benefit for the contributors and the best available free tool seems to be GNU Arch.
Catalin
Catalin Marinas wrote:
Wolfgang Denk wd@denx.de writes:
Subversion is nice, but distributed repositories are essential to me.
http://www.gna.org/ might be a good choice. It supports GNU Arch (it's not hard since it doesn't require a specific server), it has a patch manager, bug tracker etc. (their web interface is Savane, a continuation of Savannah).
Using a distributed versions control software would be a real benefit for the contributors and the best available free tool seems to be GNU Arch.
Catalin
The Arch, Savane (which has its roots as a fork of SourceForge when they went closed source), and http://www.gna.org are good tips. I've been perusing the pages and they look really good.
On the Savane/SourceForge front, currently u-boot is only using SourceForge as a public CVS repository. The SourceForge software is MUCH more capable than that. I would strongly recommend looking at the Rockbox project as an example of a very good use of SourceForge's capabilities.
Rockbox has a home page at http://www.rockbox.org/
An interesting technique is that they take the SourceForge information and reformat it for their web pages. In particular, see their patch page which separates the patches by category (catagories are supported by SourceForge). This is very nicely done. http://www.rockbox.org/patches.shtml
The underlying Rockbox SourceForge page is: http://sourceforge.net/projects/rockbox/ If you click on the "bugs" and "patches" and "feature request" links, you will see lots of good stuff (especially patches). I'm a little skeptical about bug reports and feature requests since (in my experience) they tend to be filled in and ignored thereafter.
Patch sets, however, are very useful for distributed development. You can upload a new patch (very useful) and have a discussion on the patch online (list-based discussion is arguably a better forum). The patch author can retract, update, etc. the patch. Others can watch the patch and apply it to their system if necessary. Eventually, Wolfgang & Co. would apply the patch to the mainline, at which time the patch gets closed. All good stuff.
I don't see any major use of the patch support on the gna.org web site. The only sort of useful example I found is the "eagle usb" project. https://gna.org/patch/?group=eagleusb
gvb
Hi Wolfgang et al.:
I played quite a bit with arch over the weekend. So far, I'm very impressed with its capabilities and apparent ease of supporting distributed version control. Obviously, I have not used it extensively, but I did a fair amount of concept proofing and kept notes. Attached is a HTML web page with my notes. I don't claim 100% accuracy or coverage, but it is a starting place if you or others want to experiment with arch. If you chose to switch to arch, I would be happy to contribute this and any more information I learn to your wiki.
Cliff Brake in his email of 2005-01-18 mentions his arch archive as well. His web page pointer is: http://bec-systems.com/phpwiki/index.php/UbootNotes He obviously has more experience with arch than me.
gvb
I've been using GNU Arch extensively with the Linux kernel and I am happy with what it can do. I have a minor suggestion below:
Jerry Van Baren gerald.vanbaren@smiths-aerospace.com writes:
Due to violation of ARCH naming conventions, ARCH has problems importing the following U-Boot files
directories:
board/MAI/bios_emulator/scitech/lib/debug/linux/gcc/glibc.soboard/MAI/bios_emulator/scitech/lib/debug/linux/gcc/libc.so board/MAI/bios_emulator/scitech/lib/release/linux/gcc/glibc.so board/MAI/bios_emulator/scitech/lib/release/linux/gcc/libc.so
You should usually import a clean source to avoid adding compiler-generated files to the repository. Arch tries to ensure some discipline on what files are kept in the working directory (but this can be modified to be a simple warning, not an error).
You can ignore them by changing the "unrecognized" regexp in the {arch}/=tagged-method file and it or by adding .arch-inventory files in those directories.
Catalin
Catalin Marinas wrote:
I've been using GNU Arch extensively with the Linux kernel and I am happy with what it can do. I have a minor suggestion below:
Jerry Van Baren gerald.vanbaren@smiths-aerospace.com writes:
Due to violation of ARCH naming conventions, ARCH has problems importing the following U-Boot files
directories:
board/MAI/bios_emulator/scitech/lib/debug/linux/gcc/glibc.soboard/MAI/bios_emulator/scitech/lib/debug/linux/gcc/libc.so board/MAI/bios_emulator/scitech/lib/release/linux/gcc/glibc.so board/MAI/bios_emulator/scitech/lib/release/linux/gcc/libc.so
You should usually import a clean source to avoid adding compiler-generated files to the repository. Arch tries to ensure some discipline on what files are kept in the working directory (but this can be modified to be a simple warning, not an error).
You can ignore them by changing the "unrecognized" regexp in the {arch}/=tagged-method file and it or by adding .arch-inventory files in those directories.
Catalin
FWIIW, I did start with clean source. Those directories are in the u-boot tree and contain a readme.txt file that states "This file is just to ensure that the directory is created."
I'll have to use your .arch-inventory tip to avoid the problem for my purposes, but this isn't going to work for someone that cares about MAI bios emulators :-/.
Thanks, gvb
On Tue, 18 Jan 2005 09:32:56 +0100, llandre r&d2@dave-tech.it wrote:
Generally speaking about patch management, have you ever thought about using BitKeeper to manage U-Boot repository? Thanks to your great effort and to the U-Boot developers, its popularity is growing very fast and I think that patch management task is become really huge. I started working with BitKeeper because Linux 2.6 and I think it could ease this task a lot.
I have been using arch w/ U-boot -- seems to work pretty well. There is a tla-cvs-sync script that can be used to sync an arch repository w/ a CVS repository, so this allows me to have my own version control system (arch) for my projects, but yet easily keep in sync with the U-boot CVS. My arch mirror of U-boot is available if anyone is interested:
http://bec-systems.com/phpwiki/index.php/UbootNotes
Cliff
Generally speaking about patch management, have you ever thought about using BitKeeper to manage U-Boot repository? Thanks to your great
effort and
to the U-Boot developers, its popularity is growing very fast and I
think that
patch management task is become really huge. I started working with
BitKeeper
because Linux 2.6 and I think it could ease this task a lot.
I have been using arch w/ U-boot -- seems to work pretty well. There is a tla-cvs-sync script that can be used to sync an arch repository w/ a CVS repository, so this allows me to have my own version control system (arch) for my projects, but yet easily keep in sync with the U-boot CVS.
It sounds very very interesting. Thanks for pointing it out!
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
llandre wrote:
here
http://www.dave-tech.it/download/misc/sw/edb93xx/u-boot-edb93xx-3 is
available for download a patch for Cirrus Logic EDB93xx. It has been tested on EDB9312. This patch is based on current CVS repository so it exploits Steven
Scholz's
SoC patch. See the attachment for the CHANGELOG.
Sorry, but I reject this patch. It violates too many of the Coding Style requirements (C++ comments, trailing white space, no TABs for indentation, actually TERRIBLE indentation, etc.)
Please cleanup, reformat (using indent etc.) and resubmit.
Hi Wolfgang,
to support this board I used several existing files that were not written following U-Boot coding rules :( Also I don't have the board anymore. I had a look at our web site usage statistics and a lot of people downloaded the patch I released. Anybody can help about cleaning it up?
I'm in the process of cleaning this up, and verifying functionality on all EDB93xx variants, as I've got easy access to all of the boards. There were several issues I resolved in bringing U-Boot up on EDB9301 hardware (notably broken ethernet drivers), along with a mess of cruft begging to be cleaned out. Unfortunately this is a side-project of a current development effort, and so not something I can commit terribly many hours to.
-Cory
I had a look at our web site usage statistics and a lot of people downloaded the patch I released. Anybody can help about cleaning it up?
I'm in the process of cleaning this up, and verifying functionality on all EDB93xx variants, as I've got easy access to all of the boards. There were several issues I resolved in bringing U-Boot up on EDB9301 hardware (notably broken ethernet drivers), along with a mess of cruft begging to be cleaned out.
Great.
Unfortunately this is a side-project of a current development effort, and so not something I can commit terribly many hours to.
I see. Thanks for your help,
llandre
DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2@dave-tech.it
participants (6)
-
Catalin Marinas -
Cliff Brake -
Cory Tusar -
Jerry Van Baren -
llandre -
Wolfgang Denk