Hi,
I followed the on-going discussion. Everyone seems to have lots of experiences and/or ideas for a cleaned up and shiny new U-Boot 2.0 release :-)
So the question is how we want to proceed.
I had a look on Saschas u-boot 2.0 draft - the new make and config system perfectly solves a lot of problems. I really like this frame work, and would support adoption of this framework as a basement for the 2.x tree. The custodian repository u-boot-v2 is still empty/unaccessible.
Maybe it could help to commit a stripped down version of your tree to this repository, so that we start to talk about the same thing?
Just a proper directory and konfig option tree - and everything stripped down to resetcode, relocator and C runtime setup. The relocated code should just print "Hallo world!" and loop forever. The only 'board' available would be the sandbox target, and (maybe) a generic target for each arch/cpu (Are there _simple_ boards suitable for such a reference in the 1.x tree?)
This gives a good starting point to * port (not just copy) arch/cpu reset and early init code from 1.x tree. * find out, what parts are common, and what needs to be configurable * compile and link code, and examine results. * write a working relocator for all targets and adapt GCC/bintuils to store relocation info or similiar in the binary. * start with a minimum set of kconfig options, which should whenever possible be shared between all architectures (where possible).
This helps to get rid of old code and other unwanted inheritages from 1.x tree. As the tree is empty we can talk about and decide on any issue (early debug output, complicated DRAM setups, ...) and fill in the code after such an common agreement.
The CONFIG defines for 2.x should follow a cannonical naming scheme. The corresponding CONFIG/CFG define in the 1.x tree should be renamed to match the new name.
This approach splits 'stage 1' of the bootloader apart from the common code available for all targets. It also gives us more time to develope a proper configuration tree for and to improve the internal APIs of the common code (e.g. improved _initcode scheme, common entry points, ...)
Most important: We should use the wiki to write down all these design considerations and requirements. So we can check the results of work above against a requirements list on the wiki.
In parallel people might start working with the sandbox target on a separate branch and just think about the common part (stage 2). These people won't care about stage 1 and just assume a working C environment and some configuration parameters provided by stage 1 (e.g. Address/Size of system memory an the relocated code & data segment. Or funktions provided by the board specific code).
Ok, just an proposal. But however we might continue - we are talking about a lot of work to get things clean and proper again. So it might be worth the effort to start from 'scratch' and focus all efforts on the 2.x branch.
I really like to contribute some work for this 2.x project. But I need a main-stream version as a reference for my patches first :-)
Regards Carsten
____________ Virus checked by G DATA AntiVirusKit Version: AVKA 17.260 from 03.07.2007