[U-Boot-Users] das u-boot and disc on chip

[Tolunay Orkun]

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.

Best regards,
Tolunay