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

[Georgi, Patrick]

Am Mittwoch, den 16.02.2011, 23:52 -0500 schrieb Keith Hui:
> 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?
Look at intel/sch - we split that into north/southbridge as you
described.
Unless the chip actually provides just a single PCI device interface,
you should split the SiS630 code, too. Just forget about how many chips
it's provided in, think in logical devices.

> 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?
We have a couple of methods to initialize VGA with option ROMs (x86emu,
YABEL). One of them should work, but you might have to add support code
if the VGABIOS requires callbacks for various hardware information (look
for "int15" in our tree for examples).

> What is the relationship between devicetree.cb, sconfig, parameters
> available to be included in cmos.layout, northbridge and southbridge
> drivers? 
sconfig compiled the devicetree.cb into code to be included by coreboot.
The devicetree.cb should contain all devices that either require
configuration (beyond the autoconfiguration we do - rule of thumb: if it
requires a special driver, add it) or that can't be autodetected (eg.
legacy-pnp devices, core chipset functions).

> 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?
In cmos.layout and in the code that uses the CMOS flag (which is
entirely unrelated to the devicetree/sconfig).

> 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? 
We usually do that in code (often in romstage.c, even though it doesn't
really belong there imho), as far as I can see.

> 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? Any chance I can factor it
> out like Sil3114?
It might be possible to factor it out - but be careful to check that
they're actually the same. Once you start changing it, consider
duplicating these parts into the chipset specific code, unless you have
a 966 based board around with which you can test that you don't break
it.

> 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? 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.
Depends on what they are for. The tinybootblock code usually only maps
ROM to be fully available (and does whatever is necessary to get there,
of course). This is for two reasons: First, romcc works better on
smaller pieces of code (and bootblock code is compiled with romcc),
second ROM mapping is necessary at that point, otherwise the CBFS code
might not find the necessary data (because it's not mapped properly).


Regards,
Patrick
-- 
Patrick Georgi
SINA-Development - High Security
secunet Security Networks AG - Mergenthalerallee 77 - 65760 Eschborn, Germany
Phone +49 201 54 54-3610 - Fax +49 201 54 54-1325 - www.secunet.com 

Sitz: Kronprinzenstraße 30, 45128 Essen / Amtsgericht Essen HRB 13615
Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Koelzer, Thomas Pleines
Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20110217/8ccaa53a/attachment.sig>