headers
Wolfgang Denk | 1 Mar 2005 17:15
Picon
Picon
Favicon

Re: das u-boot and disc on chip

In message <42248E52.8070109 <at> esem.com> you wrote:
> 
> If I understood you right, U-Boot is maybe not the best choice for me, 
> because there are only 2KB XIP Flash available at address 0x00000000 on 
> startup.

I wouldn't put it like that. IMO your hardware is not the best choice
for you because it is missing a proper boot ROM (256 kB  flash  would
be  just  perfect)  to  allow  you using a decent boot loader without
jumping in loops.

> Because of the several boot-modes, the lh7a404 offers, I'm thinking in 
> the meantime about to ommit the loader completely and copy the kernel 
> image directly from DoC to ram and jump there.

And who will initialize the hardware for Linux?  Who  will  tell  the
Linux  kernel  how  much  memory you have, and pass all the other bot
arguments to it? And how will you get LInux into the DoC in the first
place?

It's software, so all things are possible. But  not  all  things  are
reasonable.

Best regards,

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd <at> denx.de
(Continue reading)

Permalink | Reply |
headers
Tolunay Orkun | 2 Mar 2005 22:26
Picon

Re: das u-boot and disc on chip

Dear Wolfgang,

Wolfgang Denk wrote:
> In message <42248E52.8070109 <at> esem.com> you wrote:
> 
>>If I understood you right, U-Boot is maybe not the best choice for me, 
>>because there are only 2KB XIP Flash available at address 0x00000000 on 
>>startup.
> 
> I wouldn't put it like that. IMO your hardware is not the best choice
> for you because it is missing a proper boot ROM (256 kB  flash  would
> be  just  perfect)  to  allow  you using a decent boot loader without
> jumping in loops.

I 100% agree that dealing with a separate NOR boot ROM is so much more 
easier. However, I also see booting from NAND data flash with a small 
boot readable sector is quickly becoming popular in lower cost/smaller 
footprint/less power consumption equipment.

IMHO instead of denying this reality, perhaps we (as U-Boot 
developers/users) should make some enhancements to deal with this 
situation in a formal supported way before too many forks occur.

After all it is supposed to be **Universal** boot loader. ;)

Best regards,
Tolunay

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
(Continue reading)

Permalink | Reply |
headers
Wolfgang Denk | 2 Mar 2005 23:00
Picon
Picon
Favicon

Re: das u-boot and disc on chip

Dear Tolunay,

in message <42262F9B.7030509 <at> orkun.us> you wrote:
> 
> I 100% agree that dealing with a separate NOR boot ROM is so much more 
> easier. However, I also see booting from NAND data flash with a small 
> boot readable sector is quickly becoming popular in lower cost/smaller 
> footprint/less power consumption equipment.

Yes - and you shift 90% of the problems that U-Boot  is  supposed  to
solve  (like easy debugging of the low level initialization sequence)
into this "small primary bootstrap loader".

> IMHO instead of denying this reality, perhaps we (as U-Boot 

I don't deny it. I just tend to ignore it -  like  I  ignore  systems
running (or crashing) those Windoze "software" ;-)

> 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
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.
(Continue reading)

Permalink | Reply |
headers
Tolunay Orkun | 2 Mar 2005 23:44
Picon

Re: das u-boot and disc on chip

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
(Continue reading)

Permalink | Reply |
headers
Wolfgang Denk | 3 Mar 2005 00:48
Picon
Picon
Favicon

Re: das u-boot and disc on chip

In message <422641B0.50602 <at> orkun.us> you wrote:
> 
> 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.

I seriously doubt that the existing code could be  used.  It's  build
around  the central assumption that ease debugging is most important,
so for example  a  serial  console  port  is  provided  as  early  as
possible, long before even attempting to initialize any system memory
(RAM or flash). This pulls in a serial driver, and printf, and ...

> 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.
...
> 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.

Please feel free to submit such a definition of guidelines,  require-
ments and interfaces.

Best regards,

Wolfgang Denk
(Continue reading)

Permalink | Reply |

Gmane