Hi Joseph,
Okay, now I probably can use some help, at least in how to organize the code. Below is what I understand up to this point, but feel free to stop and correct me.
SIS630 is just one chip. All the chipsets we have so far seems to always have a "northbridge" plus a "southbridge", at least that's how the coreboot source tree is organized. Northbridge has raminit.c for initializing (S)DRAM, a chip.h where some stuff got declared - but not 100% sure what, northbridge.c as a "driver" for ramstage for detecting and enabling PCI resources, as well as building a memory table, and debug.c with functions needed for CONFIG_DEBUG_RAM_SETUP.
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) one ramstage "driver" for each PCI device the bridge supports eg. IDE, USB, LAN romstage smbus access code for reading SPD
Mainboard has... devicetree.cb for describing the board's devices
Here are my questions. If the answer can be found in a certain file in the tree, tell me - I'll read it.
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?
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?
What is the relationship between devicetree.cb, sconfig, parameters available to be included in cmos.layout, northbridge and southbridge drivers? 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? 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? 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?
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?
In the ramstage driver model, what is the relationships between chip.h,
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.
I had a long chat the other night with Idwer helping him port coreboot to intel 865. Figures it's about time I get some help for myself.
Thanks. Keith
On Wed, Jan 5, 2011 at 5:55 AM, Joseph Smith joe@settoplinux.org wrote:
On Wed, 5 Jan 2011 00:06:29 -0500, Keith Hui buurin@gmail.com wrote:
This is the next board I want to port coreboot to. And the three logs are attached. "Sissy" is what I name the machine the board is in, after SiS. :D
The flash chip i know for sure is SST 39SF020A. It needs a board enable, for which I have figured out 3 of the 5 operations involved, thanks to Luc's slides up at Phoronix.
It used a soldered PLCC32 flash chip. I soldered a socket on myself, and the chip miraclously survived. But I have not been able to get another of the same chip for backup. All my 3 spares are DIP32.
Super I/O is IT8705F, already supported. So it looks like all that's needed is porting SiS630 from coreboot v1. I think I would also be the first to port a single chip chipset to v4.
Thanks to a previous thread on this list, I got the '630 datasheet, but I don't know for sure what is different between it (the 630) and my chip (630ET).
Appreciate all the help I can get for this one.
Sweet! I have a bunch of SIS 630 boards laying around, anything I can do to help just let me know :-)
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
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
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.
* 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
-
Georgi, Patrick -
Joseph Smith -
Keith Hui -
Stefan Reinauer