[U-Boot-Users] intended behavior of bootm

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Matthias Fuchs wrote:
> Hi,
> 
> after going through the boom code I found out, that
> setting the 'autostart' variable to 'no' brings me a little closer
> to what I want. But finally I end up
> in the enable_interrupts() at the very end of do_bootm(). This freezes
> my system. The reason for this is the Linux kernel image that is loaded to address 0
> and that overwrites the vector table. So reenabling the interrupts in U-Boot with
> Linux interrupt table is a bad idea.

No, having your (u-boot) interrupt go off while booting linux is a bad idea.

Which interrupt is going off?  Why is it going off (why isn't the 
hardware put into a quiescent state)?

> So what's the best idea to fix this? I could copy the vector table onto the stack
> in do_bootm() and copy it back just before reenabling the interrupts.

NO NO NO.

> Any better idea?
> 
> Matthias

That a u-boot initialized interrupt is occurring is wrong and needs to 
be fixed.
* Traditionally, u-boot does not use interrupts for anything, thus this 
isn't a problem.

* Proper hardware and device driver convention is that the hardware must 
be quiescent when linux is started and the linux device driver must 
(re)configure that hardware the way it wants/needs.  Obviously, this is 
probably a 95% rule (console I/O, memory initialization, some others may 
violate this rule for practical reasons).

* If your u-boot enables interrupt(s), you MUST disable the interrupt 
source before starting linux.  There is NO graceful way of getting linux 
to handle an interrupt that was a result of u-boot's running.  Starting 
linux with interrupts disabled is not a good solution - you may get 
lucky but leaving an active interrupt source is a dangerous game.  At 
best, it is a race condition that you may happen to win today.

Best regards,
gvb