[U-Boot] [ANNOUNCE] Public x-loader git tree
Hi all,
As all OMAP folks know, x-loader is a first-stage bootloader for OMAPs, derived from the u-boot base code. There have been several forks of the x-loader code within and outside of TI. X-loader has no upstream path as it is currently used only for TI-products.
To avoid duplication of efforts, it's high time the code from these different trees was consolidated. Several contributors to x-loader have expressed a desire to have the code developed collaboratively in public.
To this end, we have set up an x-loader git tree on gitorious, and seeded it with Steve Sakoman's x-loader tree [1] as of 15 December 2010. (Thanks Steve for unifying so much of the forked code, and getting rid of the dependency on u-boot, and more!).
The tree is available at: http://gitorious.org/x-loader/x-loader
And a wiki page at: http://gitorious.org/x-loader/pages/Home
In addition, a mailing list has been set up at: http://groups.google.com/group/x-loader
(Thanks Nishanth Menon for setting these up).
Deva and I have volunteered to maintain the x-loader code - everyone is welcome to contribute and help make it better. (This is our first attempt at maintaining a software project - so any help is appreciated).
Currently, thanks mainly to Steve's efforts, the tree builds for and works on the following platforms: the OMAP3 EVM, the Overo and Beagle (both 35xx and 37xx), and the Pandaboard.
There are also configs for the 1710 h3, 2420 h4, 2430 SDP, 3430 SDP and 3430 Labrador boards - however these don't currently compile. They will be removed soon unless someone steps in to help bring them into shape and maintain them. (We can discuss this on the x-loader mailing list above ;) ).
Patches are welcome for any new platforms that would like to be supported in this repository. If there are forked versions out there, let us know and we'll try and integrate them here.
Feel free to use this tree, test it, report issues, and help keep the code in shape.
- Anand and Deva
[1] Steve Sakoman's x-loader tree: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=x-loader.git;a=summary
Dear Anand,
In message AANLkTinHGBBJ_MO=bk2wcHjwMNuti62UACJYNaBenf3j@mail.gmail.com you wrote:
To this end, we have set up an x-loader git tree on gitorious, and seeded it with Steve Sakoman's x-loader tree [1] as of 15 December 2010. (Thanks Steve for unifying so much of the forked code, and getting rid of the dependency on u-boot, and more!).
...
Deva and I have volunteered to maintain the x-loader code - everyone is welcome to contribute and help make it better. (This is our first attempt at maintaining a software project - so any help is appreciated).
May I ask what your goal is for such a project?
You mentioned that x-loader was derived from U-Boot, and shares some code. What is the benefit from maintaining it as a separate project?
You write "getting rid of the dependency on u-boot", and try to make this sound as an advantage. Is this really the case? Or did you just cut off your feed from upstream?
Would it not make more sense to merge it into the U-Boot tree, so it gets maintained as one project, and code is automatically kept in sync?
Best regards,
Wolfgang Denk
Wolfgang Denk had written, on 12/16/2010 02:38 PM, the following:
Dear Anand,
In message AANLkTinHGBBJ_MO=bk2wcHjwMNuti62UACJYNaBenf3j@mail.gmail.com you wrote:
To this end, we have set up an x-loader git tree on gitorious, and seeded it with Steve Sakoman's x-loader tree [1] as of 15 December 2010. (Thanks Steve for unifying so much of the forked code, and getting rid of the dependency on u-boot, and more!).
...
Deva and I have volunteered to maintain the x-loader code - everyone is welcome to contribute and help make it better. (This is our first attempt at maintaining a software project - so any help is appreciated).
May I ask what your goal is for such a project?
You mentioned that x-loader was derived from U-Boot, and shares some code. What is the benefit from maintaining it as a separate project?
You write "getting rid of the dependency on u-boot", and try to make this sound as an advantage. Is this really the case? Or did you just cut off your feed from upstream?
The statement was more in-terms of some ghastly ln -s ../../../u-boot/include/asm/mux.h kind of stuff which existed in x-loader previously, practically making build of x-loader requiring that u-boot source be in the same location as the x-loader. yeah, it was atrocious, and is one of the steps of breaking that dependency that took place.
Would it not make more sense to merge it into the U-Boot tree, so it gets maintained as one project, and code is automatically kept in sync?
My 2 cents: The eventual long term goal is to make u-boot/other alternatives (such as OMAP configuration header[1][2]) capable of replacing x-loader. We have much to do to reach that stage(while we work on it in parallel). in the meanwhile, current xfurcation (since there are more than 5 or 6 different known forks at least) make it impossible to do where we stand and what needs to be done.
In a way, considering a single x-loader as a standin solution while a final alternative evolves and becomes practical is important and is an evolutionary step IMHO.
Ref: [1] https://gforge.ti.com/gf/download/docmanfileversion/229/3870/linux-without-a... [2] http://nishanthmenon.blogspot.com/2009/05/configuration-header-no-more-x-loa...
participants (3)
-
Gadiyar, Anand -
Nishanth Menon -
Wolfgang Denk