* Keith Hui buurin@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