[U-Boot-Users] U-Boot 2.0 - How to proceed...? (was RE: U-Boot-NG ?)

[Carsten Schlote]

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