On 8/16/10 7:11 PM, Peter Stuge wrote:
Stefan Reinauer wrote:
mainboard specific setup code is critical for many boards.
What does it do?
On some boards it sets up the fans. On others it makes sure the display brightness is initialized correctly.
What determines the correct way to do those tasks? Is it really mainboard specific; ie. circuit design?
Yes. Hence they're done in mainboard.c
Some of them _might_ live in mainboard.c because creating a new framework like a "display brightness framework" into coreboot and writing a driver for whatever actual hardware controls brightness just for getting one value written into one register didn't seem appropriate at the time. So in the end it makes life easier for porters and readers than having to cope with yet another framework.
Even if there is a unique supporting circuit on the boards, the chips that we talk to from software will only have a finite ways they can work, so we should always be able to use parameters..
Yes. But you have to weigh things up. While there might be a "formula for everything" it might not be the most effective way to solve one given problem, even if the model sounds nicer in theory.
Sometimes it installs board specific interrupt handlers for oprom init.
Thanks, I "forgot" about that one. :) What makes those interrupt handlers board specific though? What they return might also be easy to control by simple parameters.
That might be very different things, like how wide the graphics bus is or how fast it can be clocked based on how the mainboard designed layed out the wires. Or whether the board has a TV-Out that should be selected.
I agree a lot of this _could_ go into the config / device tree, but right now there are bigger drawbacks one could fight if going for a sconfig overhaul. Such as putting interrupt routing information in there. Maybe even dropping the idea of "register" in sconfig completely and coming up with something better.
Stefan