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.