Porting LinuxBIOS to the AMD SC520

Now we set up the mainboard. We first cd to mainboard/digitallogic and issue:

mkdir msm586seg

We then populate it from the adjacent adl855pc directory.

There are a lot of files here. We do not have enough space here to go into the changes for each file, but we can summarize what we do to each one.

This file is compiled by romcc, and in a proprietary BIOS it would be a large blob of assembly code. To start, we completely empty this file—all it should have is a print function. This is the easiest way to get a new port going—make sure you have the ability to get some output. There is not room to show the whole file, but you can see it in the repository or use viewarch. There are two key things to get right, however. First is picking include files. For romcc, additional C code is not linked in; it is included. The include files look like this:

#define ASSEMBLY 1

#define ASM_CONSOLE_LOGLEVEL 8

#include <stdint.h>
#include <device/pci_def.h>
#include <arch/io.h>
#include <device/pnp_def.h>
#include <arch/romcc_io.h>
#include <arch/hlt.h>
#include "pc80/mc146818rtc_early.c"
#include "pc80/serial.c"
#include "arch/i386/lib/console.c"
#include "ram/ramtest.c"
#include "cpu/x86/mtrr/earlymtrr.c"
#include "cpu/x86/bist.h"
#include "cpu/amd/sc520/raminit.c"

For romcc, we define the ASSEMBLY value to 1. We also set the console log level for assembly to a very high level—8 in this case. LinuxBIOS uses macros for printing so that when a production BIOS is built, the debug print macros can be compiled out to save space. A console log level of 8 ensures that every print call is compiled.

Here's the main function, which does nothing at all:

static void main(unsigned long bist)

{
    print_err("Hello\n");
}

With this simple main we can test a lot. We can build the BIOS, load it and see if we get a printout. Simply getting print to work is a huge step in getting your BIOS going.

We saw chip.h for a CPU; is it different for the mainboard? In fact, it's not really different at all:

extern struct chip_operations
    mainboard_digitallogic_msm586seg_ops;

struct mainboard_digitallogic_msm586seg_config {
};

As before, there is a generic chip_operations structure and a specialized structure for the chip, which in this case is a mainboard. Every single device in LinuxBIOS is treated the same way. This uniform structure has proven to be powerful.

cmos.layout defines the structure of the CMOS memory, which is a battery-backed memory on the motherboard. We leave this unchanged for now.

Config.lb is pretty standard across platforms, so for reasons of space we show only a subset here, the part that is mainboard-specific. We are going to touch on a few highlights, but for more detail you need to study the full file in the archive.

This statement declares a driver file, mainboard.o, which is included in the set of binaries linked in to the final image:

##
## Build our 16 bit and 32 bit linuxBIOS entry code
##

mainboardinit cpu/x86/16bit/entry16.inc
mainboardinit cpu/x86/32bit/entry32.inc
ldscript /cpu/x86/16bit/entry16.lds
ldscript /cpu/x86/32bit/entry32.lds

These commands relate to early initialization. The config tool builds a loader script for the BIOS, an assembly code file as well as a C file and Makefiles. The mainboardinit command tells the config tool to add the entry16.inc and entry32.inc assembly code files to the assembly code file for the mainboard. The .lds files are used in the ld script to determine how the assembly code is linked.

A number of mainboardinit and ldscript directives are in this file. These are architecture-related, for example, for the x86 architecture; CPU-related, for example, specific to the SC520 CPU; and, in some cases, mainboard-related.

Now we come to the complicated part of the file, which we are going to simplify for reasons of space:

chip cpu/amd/sc520
     device pci_domain 0 on
          device pci 0.0 on end
          device pci 1.0 on end
   end
end

We are declaring the CPU and the nested devices under that CPU. The first device is the PCI domain, domain 0, which is the only domain this CPU has. We declare device 0:0.0 and 0:0.1. That's it for now—this does get more complex later, however.

Some of these files are complex, in some cases running to 100 or more lines, as some boards are complicated.