[U-Boot-Users] das u-boot and disc on chip
listmember at orkun.us
Wed Mar 2 23:44:00 CET 2005
Wolfgang Denk wrote:
>>developers/users) should make some enhancements to deal with this
>>situation in a formal supported way before too many forks occur.
>Actually NO enhancements are needed. All is ready and in place, it's
>just that you don't get any support here for creating the primary
>bootstrap loader. This is a different issue, which is unrelated to
Perhaps, there could be a U-Boot project sanctioned primary boot loader
framework. Much of the code to do that is already in U-Boot anyway (like
common CPU initialization code). Some of the board level initialization
code and any board specific code for retrieving U-Boot image would need
to be there as well.
Alternatively if you do not like that idea, U-Boot project would
formally define the guidelines of operation in a system where primary
boot loader is required and state the requirements (state of DRAM,
relocation etc) expected from such primary bootloader.
>U-Boot. U-Boot can live with suh a situation fine - of course you
>have to know _exactly_ what you are doing. See for examplethe Atmel
>AT91RM9200 configuration where all you need to change is the
>CONFIG_BOOTBINFUNC definition to either use an external bootstrap
>loader or to have a real self-contained U-Boot image.
Yes, the developer is expected to know _exactly_ what they are doing in
any case with or without a primary boot loader. Porting requires
complete understanding of the hardware and software architecture. Much
of the same concerns of developing such primary bootloader applies to
the board level startup code anyway. There is no substitute...
Defining the guidelines, requirements and the interface would
significantly help steer the development in the right direction. It is
better than saying not supported but developer has to do it anyway. At
least, such formalism would help the process.
More information about the U-Boot