Dear Graeme Russ,
In message <4d88909a.80...@gmail.com> you wrote:
>
> > That would be a layer higher than do_reset() (for example, in
> > panic()).
>
> Hmmm, but panic() is defined in lib/vsprintf.c with no possibility for it
> to be overridden in any arch or board specific way
I guess that could be helped.
> > panic() is a higher software layer. It probably results in calling
> > reset() in the end.
>
> Unless CONFIG_PANIC_HANG is defined...
> reset():
> - does not exist (as far as I can tell)
reset() is used as symbol in many arm, mips and sparc start.S files
> I still like the idea of passing a 'reason' to reset() / panic() - Could we
> change panic() to:
...
> Anywhere in the code that needed to hang has a choice - hang(reason) or
> panic(reason | PANIC_FLAG_HANG)
I don't think you resonably decide which to use in common code.
Most calls to panic() appear to come from proprietary flash drivers
anyway - most of which should be dropped as they could use the CFI
driver instead. [And if you look at the actual code, the tests for
these panic()s can easily be computed at compile time, so these are
stupid aniway.]
Others
Now, assume for things like this:
panic("No working SDRAM available\n");
or like handling undefined instructions or that - what would be more
useful - to hang() to to reset()? ;-)
Can you please show me a specific case where you would use such
different arguments to panic() in the existing code?
> Default implementations of hang() and reset() would just ignore reason.
> Board specific code can use reason to do one last boot_progress(), set LED
> states etc.
That should be done at a higher software layer.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
CAUTION: The Mass of This Product Contains the Energy Equivalent of
85 Million Tons of TNT per Net Ounce of Weight.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
