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

Joseph Smith joe at settoplinux.org
Thu Feb 17 10:18:29 CET 2011


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 at 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.
  
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org





More information about the coreboot mailing list