[coreboot] Code organization question Re: Next target: ASUS TUSI-M

Stefan Reinauer stefan.reinauer at coreboot.org
Thu Feb 17 19:54:33 CET 2011


* Keith Hui <buurin at gmail.com> [110217 05:52]:
> Southbridge has...
> bootblock.c for code required to make the whole ROM chip accessible
> all ACPI stuff (will be a while before I can get to that)

There is some ACPI stuff in the northbridge, too. See Intel i945 and
sb i82801gx for an example.

> one ramstage "driver" for each PCI device the bridge supports eg. IDE, USB, LAN
> romstage smbus access code for reading SPD

you only need a driver if there is a __pci_driver struct in the code,
and if you actually have to do init on that device.

> For this single chip chipset, should I put everything into
> northbridge, or keep only RAM init and bus scan stuff in
> src/northbridge, and put IDE/USB/LAN/SMBus/LPC/ISA etc. in
> src/southrbidge? In this scheme where would VGA fit?

I think you can decide which way to go. The Intel SCH chipset for
example exists in both northbridge/ and southbridge despite it being one
chip. On the other hand the VIA CX700 lives completely in northbridge/
VGA probably lives in the northbridge part of the chip.

> SIS630 and my board has onboard VGA that shares memory with main. I
> have the VGA BIOS extracted. Do I still need to write code to
> initialize it? If so, where in the coreboot tree?
 
I would start without writing extra code and then go from there. You
might need VGA int15 5fXX hooks, or additional init, but you can figure
that out when it becomes a problem.

> What is the relationship between devicetree.cb, sconfig, parameters
> available to be included in cmos.layout, northbridge and southbridge
> drivers? 

sconfig is a C program that parses devicetree.cb and creates the "static
portion" of the coreboot device tree. The parameters you specify in
devicetree.cb end up in static.c which is produced by sconfig.

cmos.layout is completely distinct from the device tree stuff.

> Say I need to have add a setting in cmos.layout to
> enable/disable the built in LAN, in how many places do I have to
> declare this setting?

Look at src/mainboard/kontron/986lcd-m/{cmos.layout,romstage.c} for an
example of how I did this. There might be better ways to do it, but
basically you want to make sure you disable your device early on so it
does not interact with the resource allocator. .enable function in
stage2 is good enough, too.

> My factory bios writes some known values into
> various superio LDNs during early initialization. Can I declare them
> in devicetree.cb or I have to write them in C into some early init
> code?

That's a matter of taste. I think if it's not going to be changed
putting it in code is fine. Sometimes it needs to go in romstage.c, for
example the serial port setup in romstage.c. Beyond that most things
should be fine to go to devicetree.cb

> Also, should I declare devices that can be enabled/disabled
> either in software or by jumper?
> 
> In declaring devices in devicetree.cb, does "device pci_domain 1..."
> means PCI bus 1, like the AGP slot on a 440BX?

No, on PC systems you almost always only have one PCI domain. AGP is
just another bus. In general you should not need to add that explicitly
to your devicetree.cb as coreboot can do the enumeration by itself.

Roughly you only need to add devices to the device tree if
- they can not be automatically detected
- they need some specific configuration, like whether to run the IDE
  controller in AHCI or IDE mode.
- they require some knowledge of the layout, like which HT link is used
  on a K8 system to connect the southbridge.
- they shall be explicitly disabled even though they're on per default
  (and you don't want to do that in romstage)

> The IDE, USB and LAN devices on SIS chipsets so often share the same
> PCI IDs and probably the same initialization sequence. There is
> currently only one other SIS southbridge in the tree (the 966) but its
> IDE has the same 1039:5513 ID as that on the 630. Any way I can share
> this code, or I still have to duplicate it?

It might be worth duplicating the code, since the components might still
need specific errata work arounds despite their same PCI ID. I've seen
this happen more than once.

> Any chance I can factor it out like Sil3114?

I suggest not to do that for chipset components.

> In the ramstage driver model, what is the relationships between chip.h,

chip.h contains the config structures for the parameters used in
devicetree.cb.

> Looking at my factory BIOS disassembly and what coreboot v1 had done,
> I am going to have to write some known values into known registers,
> both in the northbridge device, "southbridge device", and superio.
> Where usually is this done?

Since this is basically what firmware does all the time, this totally
depends on the values and the devices and the purpose of the writes.

If it's for configuring the RAM controller, it should probably happen in
raminit.c. for some generic chipset setup I used early_init.c in i945
but if possible it is a good manner to put the code changing a device's
config space to the ramstage driver of that device.

> bootblock_northbridge_init() for tinybootblock, in the mainboard
> romstage main(), in raminit.c before actually doing RAM init? I figure
> the first option is the earliest and best opportunity, following
> factory bios' lead.

The bootblock code should only contain stuff that is needed to make the
whole rom visible. Or enable some things like SPI prefetch to make
accesses faster. If you need the setup to happen before ram init, I
suggest to put it into romstage.c (or a function called from there).
i945 has some examples.

HTH.

Stefan





More information about the coreboot mailing list