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

[Moffett, Kyle D]

On Mar 07, 2011, at 16:40, Mike Frysinger wrote:
> On Monday, March 07, 2011 12:37:22 Kyle Moffett wrote:
>> +__attribute__((__noreturn__))
>> +void emergency_restart(void)
>> +{
>> +	__board_emergency_restart();
>> +	__arch_emergency_restart();
>> +
>> +	/* Fallback to the old do_reset() until everything is converted. */
>> +	do_reset(NULL, 0, 0, NULL);
>> +
>> +	printf("EMERGENCY RESTART: All attempts to reboot failed!");
> 
> missing a trailing newline, and i'd just call puts() to bypass useless format 
> string parsing

Ok, I'll go check for this in all the patches, thanks.


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

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

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

The "emergency_restart()" best-effort reboot is obviously a special case, as the system is already wedged and there's nowhere useful to return *to*.

Cheers,
Kyle Moffett