Hello Keith, Patrick nailed most of your questions on the head. Few of my comments below.
On Thu, 17 Feb 2011 08:18:25 +0100, "Georgi, Patrick" Patrick.Georgi@secunet.com wrote:
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.
Yes if it has seperate logical devices for northbrige and southbridge I would split it.
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).
Alot of the intel chips (i810, i830, etc) with onboard vga also have shared memory, look at those for examples. It is mainly needs to be declared in northbridge.c as a reserved memory area so the resource allocator does not touch that area. As far as init one of the rom emulators will handle that.
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).
Usually we declare that stuff in devicetree.cb.... Not really sure how to do that in cmos but it would be nice :-)
As far as chip.h you can also use it to share functions / values between chips (mainboard/northbridge/southbridge). A classic one you see alot is ide0_enable / ide1_enable which is usually delared in devicetree.cb.
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.
If you need to set board specific superIO registers it is usually done in romstage.c, on my boards I have it setup to set the superIO gpios.
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.
Hmm you could always set the device ID staticly?
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).
I think the best approach would be to setup a simple mainboard / northbridge / southbridge dir with just the bare minimum and get raminit working. After that you can worry about things like cmos, vga, etc. No need to make things to complicated right off the bat, your just end up with a headache :-)
Well I hope this helps.