[U-Boot] [PATCH 01/21] Define new system_restart() and emergency_restart()

[Mike Frysinger]

On Monday, March 07, 2011 16:56:31 Moffett, Kyle D wrote:
> On Mar 07, 2011, at 16:40, Mike Frysinger wrote:
> > On Monday, March 07, 2011 12:37:22 Kyle Moffett wrote:
> >> +	udelay(50000);
> > 
> > this doesnt sit well with me.  i dont see why this matters ... we dont
> > have any delays today, and i dont think we should introduce any.
> 
> Actually, several architectures had a printf()+udelay() already.  (i386 and
> ARM, IIRC).  Since I was moving the printf() to common code I figured I'd
> better move the udelay() as well.
> 
> I believe they had comments to the effect of "This udelay() prevents
> garbage on the serial console while rebooting", I would guess because it
> gives the FIFO time to finish flushing.

Blackfin specifically does not do this.  personally, a half baked uart char is 
preferable to a (imo) useless hardcoded delay.  i wonder if they picked a 
number that seems to work, or actually calculated it based on the slowest baud 
times the deepest fifo times the extra bits (parity/stop/etc...).  i'd suspect 
the former which means this is even dumber.

> I can move it back to the individual architectures if you'd like.

if we cant agree to simply punt it, then yes, please do.  or make it a config 
option so board porters can opt out, and default it to on for only the 
existing arches.

> >> +__attribute__((__weak__))
> >> +int __board_restart(void)
> >> +{
> >> +	/* Fallthrough to architecture-specific code */
> >> +	return 0;
> >> +}
> >> +
> >> +__attribute__((__weak__))
> >> +int __arch_restart(void)
> >> +{
> >> +	/* Fallthrough to legacy do_reset() code */
> >> +	return 0;
> >> +}
> > 
> > what use is there in having a return value ?  the do_reset() funcs today
> > dont return, which means they have no meaningful reset value.
> 
> Well, actually, a surprising number of them *do* return (at least on some
> board ports).
> 
> In particular I'm doing this for a custom board of ours (HWW-1U-1A) which
> *must* synchronize with Linux firmware running on another physical
> processor prior to asserting the reset line, otherwise it probably won't
> boot up correctly.  Since the synchronization may take an arbitrary amount
> of time (IE: Waiting for the other Linux to finish initializing), my
> board's __board_restart() function checks for Ctrl-C on the serial
> console.  If I actually *do* get a Ctrl-C I need to prevent the
> __arch_restart() hook from being run, by returning an error code.

hrm, sounds dumb to me.  i guess we cant localize this though, and it isnt 
that much overhead, so i wont complain too much about the board part.

what about the arch hook ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110307/7b54667e/attachment.pgp