[coreboot] mainboard.c: init() still being called?

[Jens Rottmann]

Hi,

sorry for the delay, I'm continually jumping between projects and especially if
a customer wants something I have to immediately drop everything else.

I wrote:
>> [...] separate the configuration _data_ from the _code_ that writes it into
>> the chip.  [...]  I had guessed that this is the purpose why there
>> is a struct mainboard_config in the mainboard's chip.h, just as there is a
>> struct superio_..._config in all superio's chip.h.

Myles wrote:
> The device tree isn't for options. It's for immutable properties of the
> mainboard.

I'm not sure why things like 'register "com1_address" = "0x3E8"', which is in
devicetree.cb, and which is changable in most standard BIOSes' Setup, are
considered more immutable than an option switching RS232 to RS485 (via some
mainboard logic).

In this sense I experimented doing this:

chip mainboard/CONFIG_MAINBOARD_DIR
    # Bit0 turns off Live LED, bit1 switches Com1 to RS485, bit2 same for Com2
    register "sio_gp1x_config" = "0x01"
    chip northbridge/amd/lx
        device pci_domain 0 on
        ...

i.e. make the mainboard the root device of the device tree - seemed plausible to
me, somehow. This compiles and boots fine, but the 'register' statement still
doesn't have any effect, sio_gp1x_config in the mainboard's chip.h still isn't
set - hmm, tough luck ... Why have a struct mainboard_config if it can't be
used? Maybe it should be removed completely??

> I think you need Kconfig variables for both of those things.

Ok, then I'll take this approach instead - and tripped over something else:

The vendor's Kconfig looks like this:
choice
	prompt "Mainboard model"
	source board/1
	...
endchoice

This means you can't put any (visible) options in the board's Kconfig, because
they'd all end up _inside_ the choice instead of as seperate options. So you'd
have to put them all in the vendor Kconfig - but this would soon become very
ugly with all the "depends on"s once the list of boards and options grows. And
board specific options just belong in the board specific Kconfig, not in the
vendor's.

So I did this:
choice
	prompt "Mainboard model"
	config BOARD_1
		bool "Board 1"
endchoice
source board/1

This made the board Kconfig:
config BOARD_1
	bool "Board 1"
	select FOO

lose the BOARD_1 option. But I needed something to attach the selects to:
config BOARD_SPECIFIC_OPTIONS # dummy
	def_bool y
	select FOO

(Dependencies skipped for simplicity, see attached full patch.) This works fine,
but I don't like the dummy config option BOARD_SPECIFIC_OPTIONS, which is always
y and doesn't actually configure anything.

- Does anyone have a better idea, avoiding the dummy option?
- I'm going to use the same scheme for the RoadRunner-LX and also for the 2
additional boards I'm planning to base on this. Maybe this restructuring should
be applied to all boards/vendors?? I've seen there is one other board with a
private config option, which is so far kept in the vendor's Kconfig.

Any comments are most welcome.

Thanks and cheers,
Jens
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kconfig_options.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100825/eea73491/attachment.ksh>