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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
