[coreboot] [PATCH] Major cleanups of hard_reset() related code/config

[Uwe Hermann]

See patch.

I'm happy for any comments. Also, I'm not sure how all this
hard_reset() stuff is meant to work. Many southbridges have _two_
implementations of hard_reset(). Why? Some only have one.
Some have none, but I guess that's OK, as their RAM init or other
coreboot code doesn't need to reset the machine (?)

And then there are various reset.c files in the mainboard directories
which don't look board-specific at all. I propose to drop them all and
provide one global hard_reset() function somewhere. Feasible?

This is the list of reset.c files we have:

$ find . -name reset.c
./src/mainboard/tyan/s2735/reset.c
./src/mainboard/kontron/986lcd-m/reset.c
./src/mainboard/intel/eagleheights/reset.c
./src/mainboard/intel/xe7501devkit/reset.c
./src/mainboard/intel/jarrell/reset.c
./src/mainboard/dell/s1850/reset.c
./src/mainboard/supermicro/x6dhr_ig2/reset.c
./src/mainboard/supermicro/x6dhr_ig/reset.c
./src/mainboard/supermicro/x6dai_g/reset.c
./src/mainboard/supermicro/x6dhe_g/reset.c
./src/mainboard/supermicro/x6dhe_g2/reset.c

If you look at them you'll notice they're all pretty much the same,
at least the hard_reset() function in the files.

Can someone explain what the rationale is for having the board reset.c
files (and some hard_reset() implementations in auto.c instead of in
reset.c files, which is also not so nice)?


Not yet abuild-tested.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.randomprojects.org
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_reset_fixes.patch
Type: text/x-diff
Size: 43813 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20091020/f7646801/attachment.bin>