[U-Boot-Users] autostart

[U-Boot-Users] autostart

[Der Herr Hofrat]

HI !

 I have a problem with device initialisation in the kernel (all up and running
 in u-boot) , so I wanted to have u-boot load the kernel, decompress it but 
 then not actually start it -  reading the u-boot manual I found that one 
 should use autostart no. The sequence I used was:

   setenv ipaddr 192.168.1.250
   setenv serverip 192.168.1.34
   tftpboot 0x350000 vmlinux.PPCBoot
   setenv autostart no 
   bootm 0x350000 

 but that simply kicks up the kernel and ends up in a panic becaues the 
 network and serial port initialization don't work in the kernel which I'm 
 trying to debug that - but I can't seem to stop the kernel with a breakpoint
 as the xilinx tools (XMD) simply does not set it, so I wanted u-boot to stop
 at the kernel entry and step it from there - no luck though.

 So how can I get u-boot to just do the decompression but not pass control to 
 the kernel ?

thx !
hofrat

[U-Boot-Users] autostart

[Wolfgang Denk]

In message <200503121044.j2CAiwQ28057@hofr.at> you wrote:
> 
>  So how can I get u-boot to just do the decompression but not pass control to 
>  the kernel ?

For compressed images of type "standalone" you  can  use  the  method
described in the FAQ:
http://www.denx.de/twiki/bin/view/DULG/HowCanILoadAndUncompressACompressedImage


For Linux kernel images this will not work: the Linux kernel  expects
to  be laoded at address 0x0000; when you load it, you will overwrite
U-Boot's exception vectors - the next timer interrupt would crash the
system. This is why there is a point of  no  return  when  loading  a
Linux kernel image -- U-Boot will then disable all interrupts, and in
case of errors the only way out is to reset the board.

Can't you use a real debugger like the BDI2000?

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
A girl with a future avoids the man with a past.
                                   -- Evan Esar, "The Humor of Humor"

[U-Boot-Users] autostart

[Der Herr Hofrat]

> In message <200503121044.j2CAiwQ28057@hofr.at> you wrote:
> > 
> >  So how can I get u-boot to just do the decompression but not pass control to 
> >  the kernel ?
> 
> For compressed images of type "standalone" you  can  use  the  method
> described in the FAQ:
> http://www.denx.de/twiki/bin/view/DULG/HowCanILoadAndUncompressACompressedImage

I did read that but did not catch the exclusion of the Linux kernel - thanks.

> 
> 
> For Linux kernel images this will not work: the Linux kernel  expects
> to  be laoded at address 0x0000; when you load it, you will overwrite
> U-Boot's exception vectors - the next timer interrupt would crash the
> system. This is why there is a point of  no  return  when  loading  a
> Linux kernel image -- U-Boot will then disable all interrupts, and in
> case of errors the only way out is to reset the board.

well it does not crash - the kernel actually boots - but I can no longer talk
to the peripherals on the opb.

> 
> Can't you use a real debugger like the BDI2000?

If it were for me to descide yes, do you know if the Xilinx Virtex II Pro is
properly supported (assuming a 405 soft core)?

hofrat

[U-Boot-Users] autostart

[Grant Likely]

On Sat, 12 Mar 2005 12:23:59 +0100 (CET), Der Herr Hofrat
<der.herr@hofr.at> wrote:
> > In message <200503121044.j2CAiwQ28057@hofr.at> you wrote:
> >
> > Can't you use a real debugger like the BDI2000?
> 
> If it were for me to descide yes, do you know if the Xilinx Virtex II Pro is
> properly supported (assuming a 405 soft core)?
> 
> hofrat

Yes, at work we're using the BDI2000 with a dual core Vertex II Pro. 
No problems that I know of.

g.

[U-Boot-Users] autostart

[Wolfgang Denk]

In message <200503121124.j2CBO0Y28470@hofr.at> you wrote:
>
> > For Linux kernel images this will not work: the Linux kernel  expects
> > to  be laoded at address 0x0000; when you load it, you will overwrite
> > U-Boot's exception vectors - the next timer interrupt would crash the
> > system. This is why there is a point of  no  return  when  loading  a
...
> well it does not crash - the kernel actually boots - but I can no longer talk
> to the peripherals on the opb.

Sorry for not being clear enough. I meant: if you tried to just  load
the  Linux  kernel  image into RAM, and then contied executing U-Boot
code (for example trying to use U-Boot's embedded  debugger  [bedbug]
to debug the Linux initialization) then U-Boot would crash as soon as
any reference to it's (now overwritten) exception vectors occurs.

> > Can't you use a real debugger like the BDI2000?
> 
> If it were for me to descide yes, do you know if the Xilinx Virtex II Pro is
> properly supported (assuming a 405 soft core)?

Yes, it is.

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
Thought for the day: What if there were no hypothetical situations?