Board:via/epia-m: Difference between revisions

From coreboot
Jump to navigation Jump to search
m (Phcoder moved page VIA EPIA-M to Board:via/epia-m)
 
(3 intermediate revisions by 2 users not shown)
Line 99: Line 99:


}}
}}
== VIA EPIA-M and MII ==
== VIA EPIA-M ==




This HOWTO contains instructions for using corebootv2 on the VIA EPIA-M and MII
This HOWTO contains instructions for using corebootv2 on the VIA EPIA-M
mini-itx based motherboards.
mini-itx based motherboards.


Line 438: Line 438:
If you wish to return to the corebootv2 DSDT, then the original file dsdt.asl can be converted into a C hex file using 'iasl -tc dsdt.asl'
If you wish to return to the corebootv2 DSDT, then the original file dsdt.asl can be converted into a C hex file using 'iasl -tc dsdt.asl'


=== Boot from Onboard Compact Flash (MII only)===
== The EPIA-M Porting Guide ==


corebootv2 now supports the onboard compact flash on the MII as an IDE drive, and it is possible to boot directly from this drive using the following steps.
From nick.barker9@btinternet.com Wed Oct  6 10:56:16 2004
Date: Wed, 6 Oct 2004 06:47:08 +0100
From: Nick Barker
To: Ronald G. Minnich
Subject: EPIA-M / MII a large patch


The first step is to get Filo or whatever payload you are using to recognise and use this device.
Ron,


In order that the pcmcia subsystem of the Linux kernel can correctly configure the device later on in the boot process the CF is set up with its I/O registers in a contiguous block of 16 bytes at 0x1e0 through 0x1ef. Unfortunately this is not a standard IDE address which is why we need to 'fix' filo to use it.
As announced on the list, here is my patch for freebios2 - epia-m/mii
(Actually it is half of the address range used by IDE4, and so we need to be careful to tell the kernel not to probe that address - more on that later).


The first step is to change the filo Config file.
The patch contains both bug fixes and new features as follows:
# Comment out SUPPORT_PCI=1. This line instructs filo to search for PCI based IDE  adapters only, and the CF is not attached to a PCI based IDE controller.
# Add the following two lines somewhere in the Config file:
IDE2_CMD = 0x1e0
IDE2_CNTRL =0x1ec


* ACPI power management and interrupt routing
* Boot from onboard compact flash
* Legacy VGA Bios working
* mtrr's set up correctly for VGA
* AGP and GART set up correctly
* vt1211 h/w monitor, com ports, lpt and fdc enabled
* 1/2 speed baud rate problem resolved


The second step is to modify the file drivers/ide.c in the filo source directory.
Find the function 'find_ide_controller_compat' and change it to look like:


static int find_ide_controller_compat(struct controller *ctrl, int index)
== Caveat ==
{
 
if (index >= IDE_MAX_CONTROLLERS)
The patch uses the memory setup code ported into C from version 1 for the
return -1;
EPIA-M, but has been adjusted for 256Mb only - i.e. the size that I'm
#ifdef IDE2_CMD
currently using. This code, in northbridge/raminit.c, is an ugly hack to get
if(index == 2){
the system up and booted, and I do not particularly offer it as the 'final
ctrl->cmd_base = IDE2_CMD;
solution'. I've always assumed that one day it would be replaced with proper
ctrl->ctrl_base = IDE2_CNTRL;
autodetection - a job for someone with access to the appropriate
return 0;
documentation i.e. vt8623 datasheets.
}
 
#endif
I have tried to restrict any changes to epia-m specific files, however there
ctrl->cmd_base  = ide_base[index];
are a few generic files that I have had to make some changes in,
ctrl->ctrl_base = ide_base[index] + IDE_REG_EXTENDED_OFFSET;
particularly in the ACPI, vga bios and mtrr areas. These changes 'should' be
return 0;
benign to other platforms.
}
 
There are other areas which I consider 'hackish', in particular the setting
Filo will now recognise the CF as the first device on the third IDE controller (i.e. ide2), and can be referred to as 'hde'
up of the cardbus bridge. This device is ignored altogether by the PCI
detection code because it has a header type of PCI to cardbus bridge (type 2
I think). Having failed to understand the intricacies of the pci detection
and configuration mechanism, I have resorted to setting up the bridge
manually, and with fixed memory resources, as annotated in the code.
 
The Config.lb provided is set up for filo and legacy vga bios. In other
words it makes an image 192K big to which a captured vga bios should be
prepended.
 
The patch is relative to the web based CVS snapshot of 20041004-1100.
 
== ACPI power management and interrupt routing ==
 
I have added the code which creates three new ACPI tables, and sets up the
southbridge power management unit into ACPI mode.
 
The new tables are the:
* Fixed ACPI Description Table (FADT)
* Firmware ACPI Control Structure (FACS)
* Differentiated System Description Table (DSDT)
 
The FADT mostly describes the power management unit, and is declared in
fadt.c in the mainboard/via/epia-m directory.
 
The FACS is intended to provide non volatile memory to the ACPI system for
suspend to disk activities. However it is currently implemented as a zeroed
table. I have only included it because Linux ACPI complains if there isn't
one if a FADT has been provided.
 
The DSDT describes the interrupt routing and power management capabilities
of devices, and is what Linux uses for interrupt routing if it can. The
DSDT, defined in mainboard/via/epia-m/dsdt.c is exactly that provided with
the original Award bios. It has been created using the following approximate steps:
 
# Under Award Bios, 'cat /proc/acpi/dsdt > dsdt'
# Decompile dsdt with Intel's iasl - 'iasl -d dsdt'
# Compile to C table with Intel's iasl - 'iasl -tc dsdt.dsl'
# Copy output to mainboard/via/epia-m/dsdt.c
 
The award dsdt may carry the same IPR situation as the VGA bios, and it
could be that the file dsdt.c should not be distributed with the code.
However it is easy enough to create your own using the steps above.
 
The ACPI code seems to be fully functional - giving software off and reset,
as well as providing power button click events (the whole reason I wrote
this !!).
I assume the ACPI subsystem in Linux is also shifting the processor into S1
and S2 states, and doing other things that ACPI should do, but I haven't
confirmed that yet.
 
== Boot from onboard Compact Flash ==
 
I have added a new device to the southbridge tree -
southbridge/ricoh/rl5c476, which is the setup code for the Ricoh cardbus
bridge found on the MII. I wasn't quite sure where to put it in the source
tree, but I guessed it was more like a southbridge than anything else.
 
The code sets up a compact flash in the CF slot as an IDE drive based at
address 0x1e8, in other words the standard address for the third IDE
controller as used by Filo, Linux, and I guess Etherboot.
 
The code is a bit clunky in as much as it allocates fixed addresses for
memory windows - which ought to be allocated by the pci detection code, but
I can't figure out how to make this happen.
 
Filo detects the CF as drive 'hde' as long as filo has been compiled with
SUPPORT_PCI=1 commented out. With SUPPORT_PCI included, filo only searches
for PCI devices of the IDE controller type, whereas without it, filo will
check its standard addresses for an IDE controller.
 
You can configure Linux to support the CF in one of two ways, depending upon
your needs:
 
* Standard IDE disk support. Just let the standard IDE detection code in Linux pick up the CF as a standard device. This has the advantage of being quick and easy to get going. However if you then start up pcmcia utils to deal with the pcmcia slot, you will run into difficulties as the pcmcia-utils package resets the CF slot. There might be options you can use to instruct pcmcia-utils to ignore the CF slot entirely, but I haven't found them yet.
 
* PCMCIA-UTILS support. Firstly you have to tell the standard IDE detection code NOT to look for the third IDE controller, do so with a linux command line option of 'ide2=noprobe'. Next you need to set up an initrd. The pcmcia-utils HOWTO describes how to do this with 'pcinitrd'. In addition you have to add the program 'resetcf' from freebios2/util directory to the initrd, and make sure it is called just before the socket driver is loaded in the linuxrc file. This step is necessary because the yenta socket driver does not correctly clear down the state of the CF socket as left by freebios2 (detail - yenta socket driver never clears the io offset used by freebios2 to make the CF look like /dev/hde - I guess it normally relies on the power on default being zero!!!). My linux command line in filo looks like:
 
AUTOBOOT_FILE = "hde:/vmlinuz initrd=hde:/initrd.gz root=/dev/hde console=tty0 ide2=noprobe"
 
== Legacy VGA BIOS ==
 
I struggled for some time getting the VGA bios to work properly, as others
on the mailing list seem to be also. Here is a list of my findings:
 
Some people are finding that the bios initialisation code is crashing with a
random interrupt vector. This always seemed to happen at cs:ip=c000:0188. A
look at the actual instruction at that location reveals that it is an STI
instruction which enables hardware interrupt processing, not an INTXX
instruction. On freebios2, the i8259 interrupt controller is never
initialised, so it is understandable that if the vga bios has been playing
with interrupts that after the STI intruction a random interupt vector is
issued by the i8259 - and hence the problems as reported. My fix is to
include the version 1 i8259 initialisation code, and that allows the bios to
finish.
 
The next problem encounterred was that after vga initialisation, the screen
didn't come on. After groping around the XFree sources for the CLE266 I
discovered a bios call to select which output device(s) to enable, and have
added a call to that function to turn on the standard console. Anyone
wanting the TV output or LCD panel output are recommended to look at the
Xserver sources for that bios call.
 
The final problem was that the freebios2 code was setting up the video
memory window at 0xa0000 - 0xbffff as cacheable in its fixed mtrr code. This
was resolved by getting sizeram() in northbridge.c to break the main area of
memory into 2 chuncks either side of this window.
 
== MTRR's for VGA ==


I have added code to create correct mtrr's for the VGA framebuffer and the
AGP. This has meant some minor changes in mtrr.c


The next step is to create an initrd file for your Linux kernel. What? Why?
== AGP port and GART ==
The CF socket on your MII is hardwired to the PCMCIA controller and for all intents and purposes it is a PCMCIA device. This means that once Linux boots it will be under the control of the pcmcia manager. Now according to the pcmcia-utils documentation, the pcmcia manager is intended to control and configure devices on an already running system. Yet if we need the CF to be the root device, it needs to be mounted very early on in the boot sequence, before the stage where pcmcia devices would normally be configured. The answer is to use an initrd file to get the pcmcia manager running early for the CF. If you are unfamiliar with initrd then 'man initrd' will give you more background.


The AGP bridge seems to work correctly after setting it up like award. The
GART window is hard coded at address 0xd0000000, as per award, and
could/should be set by the pci_device allocation code. Linux AGP support
does not crash the system and I believe it to be fully working.


The easiest way to create an initrd is to use the script 'mkcfinitrd' which is at the bottom of this howto. This is a tailored version of the 'pcinitrd' script from the pcmcia-utils package.
== VT1211 ==
Make sure that 'ash' is available on your system as this is the tiny shell programme used during the initrd phase of booting.


It is worth mounting the initrd generated, and looking over it to make sure that it contains all of the modules necessary to load and initialise the CF. It does not need drivers for whatever you use in the pcmcia socket, as that can be initialised later on in the boot process as before.
I have created a new superio device for the vt1211, which sets up the
hardware monitor, com ports, lpt and fdc. The h/w monitor set up values are
taken from v1. None of this has been tested beyond Linux correctly spotting
the devices.


Finally gzip the file created, and move it alongside your kernel.
== 1/2 speed baud rate problem ==


Next adjust your FILO command line to pick things up from the CF. My linux command line in filo looks like:
I believe that the 1/2 speed baud rate problem is down to trying to do
things before the southbridge and certain clocks have fully settled down. By
putting a delay after the rtc_init() and before trying to use the SMB bus,
the problem seems to be rectified. The counter in the delay loop could be
optimised if anyone out there has the desire - 1000 isn't enough, whilst
5000 is.


AUTOBOOT_FILE = "hde:/vmlinuz initrd=hde:/initrd.gz root=/dev/hde console=tty0 ide4=noprobe"
== And Finally ==


The ide4=noprobe option is required to stop the kernel from probing the address used by the CF. As this address is half that used as the standard address for a fifth (i.e. ide4) controller, the kernel hangs whilst trying to initialise this device if this option is not given.
As an indicator that the BIOS is going, I've got the power LED to blink
rapidly from early on, until the BIOS has just about finished its job. Could
be first thing for newcomers to look for when they don't get any other form
of output.


Finally make sure that you have copied the necessary files onto your CF, and re-boot your computer.


{{PD-self}}
{{PD-self}}

Latest revision as of 23:22, 18 January 2014

This page describes how to use coreboot on the VIA EPIA-M mainboard.

Status

Device/functionality Status Comments
CPU
CPU works OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
L1 cache enabled OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK Always on
L2 cache enabled OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK Always on
L3 cache enabled OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Multiple CPU support OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Multi-core support OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Hardware virtualization OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
RAM
EDO OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
SDRAM OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
SO-DIMM OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
DDR OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
DDR2 OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
DDR3 OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Dual channel support OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
ECC support OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | ?
On-board Hardware
On-board IDE 3.5" OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
On-board IDE 2.5" OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" |
On-board SATA OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
On-board SCSI OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Unknown
On-board USB OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
On-board VGA OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
On-board Ethernet OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
On-board Audio OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | ?
On-board Modem OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | ?
On-board FireWire OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
On-board Smartcard reader OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
On-board CompactFlash OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
On-board PCMCIA OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
On-board Wifi OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
On-board Bluetooth OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
On-board SD card reader OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Add-on slots/cards
ISA add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Audio/Modem-Riser (AMR/CNR) cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
PCI add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | ?
Mini-PCI add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Unknown
Mini-PCI-Express add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Unknown
PCI-X add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Unknown
AGP graphics cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
PCI Express x1 add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
PCI Express x2 add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
PCI Express x4 add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
PCI Express x8 add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
PCI Express x16 add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
PCI Express x32 add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
HTX add-on cards OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Legacy / Super I/O
Floppy OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Serial port 1 (COM1) OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
Serial port 2 (COM2) OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Not tested
Parallel port OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Not tested
PS/2 keyboard OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
PS/2 mouse OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
Game port OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Infrared OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Not tested
PC speaker OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
DiskOnChip OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | NA
Input
Trackpoint OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Touchpad OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Fn Hotkeys OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Fingerprint Reader OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Laptop
Docking VGA OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Docking LAN OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Docking USB OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Docking Audio OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Docking Displayport OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Thinklight OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Webcam OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Miscellaneous
Sensors / fan control OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Not tested
Hardware watchdog OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
SMBus OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Unknown
CAN bus OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
CPU frequency scaling OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
Other powersaving features OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
ACPI OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
Reboot OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
Poweroff OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | No
Suspend OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Unknown
Nonstandard LEDs OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK
High precision event timers (HPET) OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Not tested
Random number generator (RNG) OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | N/A
Wake on modem ring OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Untested
Wake on LAN OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Untested
Wake on keyboard OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Untested
Wake on mouse OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Untested
TPM OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | Unknown
Flashrom OK=lime | TODO=red | No=red | WIP=orange | Untested=yellow | N/A=lightgray | yellow }}" | OK

VIA EPIA-M

This HOWTO contains instructions for using corebootv2 on the VIA EPIA-M mini-itx based motherboards.

Version 1.0 initial write for LinuxBIOSv2 by Nick Barker

Using materials and inspiration from:

  • EPIA HOWTO for freebios/linuxbios by Mark Wilkinson
  • Based on the K7SEM HOWTO by Brenden Bixler,
  • Which is based on the Sis 630 HOWTO by Ron Minnich.
  • Getting Started with freebios2 - a mail posting by Jay Miller


Unfortunately, there is a step in this HOWTO that can be hazardous.


The hazards include, but are not limited to:


1. Destroying your motherboard!


2. Hurting yourself!


3. Killing yourself!


Because of these hazards, you must take full responsibility if you decide to install corebootv2 following these procedures. Neither the author of this HOWTO or any organisation or individual associated with the corebootv2 project can be held responsible for any adverse consequences of your attempt to follow these procedures.


WARNING!: We assume you've built kernels, know how to open up your PC, and how to yank the flash part out while power is on and put in a different part. There is NO WARRANTY, express or implied, with this software. In fact, if you don't know what you're doing, and you get careless, you're going to end up with a nice paperweight instead of a motherboard, an emergency room bill, or a funeral service.

YOU HAVE BEEN WARNED!


Linux Distribution: Most modern distributions are supported.

Other Software Notes:

You MUST have 'as' version 2.9.5 or later.

You MUST have 'gcc' version other than 2.96.

Prerequisites

Before you start there are a few things which you need to arrange:

Since you are going to be re-programming the flash rom on the mainboard, and it is likely that you first few attempts / images will not be right, then you need a way of restoring a known working bios onto a board which is otherwise dead.

Recommended: you might want to get a Bios Saviour (RD1-PL) - this is a handy little piggy-back flash chip that saves you destroying the original flash image. This howto assumes that you have this device, though other methods and devices exist for programming flash roms.

corebootv2 sends debugging output through the first serial port. You might want to arrange a null modem serial cable for connecting this serial port to a second computer running a terminal emulation program. I use 'microcom' which is simple and allows all output to be captured into a file for later analysis. The port is set up to use 115200 baud, 8bit, No parity, 1 stop bit.

Under corebootv2 you have a choice of 'payloads'. The payload is the program which corebootv2 hands over to once it has finished initialising everything on the mainboard at boot time. The payload is included in the flash rom along with corebootv2, and usually its function is to locate and load the operating system. The 2 most common payloads are FILO, for booting Linux off an IDE disk, and Etherboot for booting a diskless workstation accross a network. This howto assumes the use of FILO.

A vga bios image. coreboot2v2 uses the vga bios of the original Via BIOS to initialise the vga. It is not directly downloadable, but you can capture it from a system running with the original bios, so you might as well capture it now.

dd if=/dev/mem of=video.bios.bin.4 bs=65536 count=1 skip=12


Getting Going

The steps for loading corebootv2 are simple:

  1. Get Linux installed on your machine.
  2. Download and install corebootv2 sources.
  3. Understand how to flash your rom.
  4. Download, Configure and build the FILO payload
  5. Configure and build corebootv2.
  6. Burn the corebootv2 image to the flash.
  7. Reset the machine -- did it work?


Options Once it has Booted:

  1. Speeding up the boot
  2. Enhancing ACPI support
  3. On EPIA-MII, booting the computer from on-board compact flash


Step 1

Get Linux installed on your corebootv2 machine. Don't forget to note which partition is / (/dev/hda3 etc.)

Step 2

Grab the corebootv2 source. cd to the directory you want the source tree to be.

Note: this will create a sub directory called corebootv2 which contains the corebootv2 source code

Download the latest code for corebootv2 from the downloads page at: http://www.coreboot.org/Download_coreboot

Having expanded the tarball, cd into the corebootv2 directory and browse around. The top level directory includes:

'src' - where all of the source files for corebootv2 are located. 'targets' - where all of the platform specific configuration files for each platform supported by corebootv2 are kept, and where the build files and build process occur. 'util' - where various utilities required for the build process and debugging are kept.

Hereafter, this howto refers to directory locations relative to these directories, unless an absolute pathlist is given.

Step 3

Whilst getting corebootv2 going on your EPIA-M, you are almost certainly going to be re-programming the flash rom several times, and there is a very high probability that at one of these stages you will get a flash rom that fails to boot your mainboard into Linux.

Before we proceed any further, it is absolutley vital that you have worked out how to program the flash chip, and how you are going to get back to your original bios when things go wrong. Otherwise you will end up with a very expensive paper weight as described earlier.

You can use a professional Data I/O burner, or you can be foolhardy and simply re-program the flash part of a running machine. However whilst getting going a BIOS SAVIOUR RD1-PL is a very inexpensive but effective device for ensuring that you always have a working BIOS to hand.

The bios saviour is a little device which plugs into the flash rom socket of the motherboard, and the original flash rom then plugs into the bios saviour. The bios saviour includes a second flash rom chip, and either of these chips can be selected as the active chip by a simple supplied electrical switch mounted on flying leads. Make sure that this switch is clearly visible, so that you know which chip you are booting from, and which chip you are about to re-program.

Decide which chip you are going to use for corebootv2, and which chip you are going to keep the original working bios in, and mark them clearly on this switch.

In the 'util/flashrom' directory is the source for the 'flashrom' utility, which is great for re-programming the flash chips on the EPIA-M / MII. Once you have built this utility:

Make sure that it can detect both flash chips on the bios saviour: with switch set to chip 1 run:

$ flashrom

Flash rom should search through a list of known flash rom device types until it finds the type of the original chip from your EPIA-M, and report what it has found.

With the switch set to chip 2, run:

$ flashrom

again and confirm that it can 'see' the second flash chip.

If your are lucky, the actual part number of the 2 chips may be different, which you can use just prior to re-programming a chip to make sure you are programming the right chip.

Make sure that you can read / write and verify a flash chip. With switch set to 1 (original BIOS) run:

$ flashrom -r original.rom

This should read the contents of the original bios into the file original.rom Confirm that the newly read file matches the original bios, run:

$ flashrom -v original.rom

Set the switch to 2 confirm if you can that flashrom 'sees' the second chip, run:

$ flashrom

- and look for the detected device type. Write the known good bios to the second chip with:

$ flashrom -w original.bios

Verify that it has written correctly with:

$ flashrom -v original.rom

With switch left at position 2, reboot the machine and make sure that it comes up correctly. If it does then you now have a working flash programming environment. If it does not, then set the switch back to 1, reboot the machine, and investigate further.

Step 4

Download FILO from http://felixx.tsn.or.jp/~ts1/filo, and expand

In the FILO source directory, run:

$ make

The first invocation of make builds the default Config file, which should be edited to meet your needs. In particular look at the line:

"AUTOBOOT_FILE ...."

and make sure that it looks sensible for your setup. The line:

AUTOBOOT_FILE "hda1:/vmlinuz root=/dev/hda2 console=ttyS0,115200" reads as:

- find a linux os image on device hda partion 1 called vmlinuz,
- load this image
- execute the image passing kernel command line parameters of: "root=/dev/hda2 console=ttyS0,115200" 

After editing Config, again run:

$ make

This will build the file 'filo.elf' which is the payload we will be using.

Copy this file to somewhere which the corebootv2 makefile can easily find it. I just tend to keep it in the root directory though I'm sure others will condem me for that practice:

$ cp filo.elf /

Make sure that you have compiled a kernel bzImage, and copied it to the file location you identified in the FILO Config file.

Step 5

The next step is to create the build environment for the epia-m. This step creates the appropriate makefiles and build directories for the epia-m. Run:

$ cd targets
$ ./buildtarget via/epia-m

This step will create a subdirectory in the targets/via/epia-m directory called epia-m, which is the build directory for corebootv2.

The main configuration file for the epia-m is in 'targets/via/epia-m/Config.lb'

If you need to make any changes to the configuration, for example you wish to locate filo.elf in a place other than '/filo.elf', or during the more advanced steps of this HOWTO, then these changes are made to this file.

You need to re-run:

$ ./buildtarget via/epia-m

after any such change.

The directory 'targets/via/epia-m' contains other sample Config.lb files, any of which can be copied through to Config.lb in order to become the current configuration.

Once you have your Config.lb set up to your needs, and the build environment created with './buildtarget', it is time to build a rom image.

Change directory into the build directory 'targets/via/epia-m/epia-m'

The configuration as set up by the buildtarget process will create a coreboot file which is exactly 196608 bytes long, which is exactly 64K bytes short of what needs to go into the 256K flash rom. The other 64K is for your vga bios which is simply merged with the coreboot image. The easiest way to make this happen is to edit the Makefile and change the line:

cat fallback/coreboot.rom > coreboot.rom

to this

cat /video.bios.bin fallback/coreboot.rom >coreboot.rom

Note: the above order of merging the files together is critical

You will need to remember to make this change every time after you have run the buildtarget program.

Run:

$ make

and wait for the build process to complete.

If all went well, then you should find a file 'coreboot.rom' in your current directory. Check that it is 262144 bytes long - i.e. exactly the right size for the flash rom chip in your EPIA-M / MII.

Step 6

NOTE: BE ADVISED THAT THIS STEP CAN KILL YOUR MOTHERBOARD ! IF YOU DO NOT HAVE A MEANS OF RECOVERING FROM FLASHING YOUR BIOS, YOU MAY/WILL BE LEFT WITH A DEAD MACHINE.

Assuming that you are using a Bios Saviour, make sure that the switch is set to the position for your corebootv2 image.

Type:

$ flashrom

to make sure it can see the flash chip, and verify its type if possible.

Only once you are happy that you are about to re-programme the desired chip, type:

$ flashrom -w coreboot.rom

and wait the few seconds it takes to program it.

Once it has finished, verify that the chip was re-rogrammed correctly - type:

$ flashrom -v coreboot.rom

Step 7

Power cycle the machine. corebootv2 should come up in a few seconds.

With a connection to the serial port set at 115200, you should see corebootv2 come up, launch FILO, and if you have a timeout set in FILO, then it may be waiting for you to confirm its boot command line.

As long as you have this command line set up correctly, and an os image in the right place, then FILO should proceed to boot into your Linux os.

If you do, CONGRATULATIONS ! It WORKED ! Pat yourself on the back, why not try the optional steps now ?

If you don't, time to start capturing the output of the serial port and talking to the coreboot mailing list.

Optional steps - for use only if step 7 was successfull.

OK so now we have a BIOS which boots your computer fully into the operating system, and depending upon your needs that may be all that you want. However corebootv2 has a few more tricks up its sleeve should you find yourself hungry for more.

Speeding up the Boot

coreboot sends its debugging output to the first serial port and, depending upon the amount of debug output selected, can be the limiting factor in the speed with which it boots your computer - regardless of whether you have anything attached to the serial port.

coreboot uses the notion of debug levels to control what is sent to the serial port. These levels range from 0 to 9 with 0 being the least verbose and 9 being the most verbose.

These levels are defined in the Config.lb file described earlier. To reduce the output set:

option  MAXIMUM_CONSOLE_LOGLEVEL=8 
option  DEFAULT_CONSOLE_LOGLEVEL=8

to lower values.

Next you will have to run 'buildtarget' again to propagate the effects of the config change. Then edit your Makefile again to include your video bios in the final merging.

Then run:

$ make clean 

followed by:

$ make

Advanced ACPI

corebootv2 now supports ACPI on the epia-m and epia-m II. In particular the interrupt processing in Linux can be done through ACPI, and crude power management support is provided. This includes software power off, and power management events from the power button.

It is possible to enhance this behaviour to provide the full capabilities of the original BIOS, which includes different sleep levels and wake from these levels upon certain events. This is achieved by using a 'grabbed' copy of the ACPI Differentiated System Descriptor Table or DSDT from the original BIOS.

For copyright reasons this table cannot be included with the source distribution of corebootv2.

You MUST have 'iasl' - Intel's ACPI Asl compiler for Unix/Linux - http://developer.intel.com/technology/iapc/acpi/downloads.htm.

To replace the corebootv2 DSDT with the grabbed one from the original BIOS:

  • Start the computer using the original BIOS, and make sure that you have ACPI set up in the kernel that you are running
  • Grab the DSDT table - 'cat /proc/acpi/dsdt >dsdt.aml'
  • Convert to asl code - 'iasl -d dsdt.aml' (creates dsdt.dsl)
  • Convert it to a C hex table - 'iasl -tc dsdt.dsl' (creates dsdt.hex)
  • Replace the file 'src/mainboard/via/epia-m/dsdt.c with dsdt.hex
  • Now re-build corebootv2, re-program the flash and power cycle.

If you wish to return to the corebootv2 DSDT, then the original file dsdt.asl can be converted into a C hex file using 'iasl -tc dsdt.asl'

The EPIA-M Porting Guide

From nick.barker9@btinternet.com Wed Oct  6 10:56:16 2004
Date: Wed, 6 Oct 2004 06:47:08 +0100
From: Nick Barker 
To: Ronald G. Minnich 
Subject: EPIA-M / MII a large patch

Ron,

As announced on the list, here is my patch for freebios2 - epia-m/mii

The patch contains both bug fixes and new features as follows:

  • ACPI power management and interrupt routing
  • Boot from onboard compact flash
  • Legacy VGA Bios working
  • mtrr's set up correctly for VGA
  • AGP and GART set up correctly
  • vt1211 h/w monitor, com ports, lpt and fdc enabled
  • 1/2 speed baud rate problem resolved


Caveat

The patch uses the memory setup code ported into C from version 1 for the EPIA-M, but has been adjusted for 256Mb only - i.e. the size that I'm currently using. This code, in northbridge/raminit.c, is an ugly hack to get the system up and booted, and I do not particularly offer it as the 'final solution'. I've always assumed that one day it would be replaced with proper autodetection - a job for someone with access to the appropriate documentation i.e. vt8623 datasheets.

I have tried to restrict any changes to epia-m specific files, however there are a few generic files that I have had to make some changes in, particularly in the ACPI, vga bios and mtrr areas. These changes 'should' be benign to other platforms.

There are other areas which I consider 'hackish', in particular the setting up of the cardbus bridge. This device is ignored altogether by the PCI detection code because it has a header type of PCI to cardbus bridge (type 2 I think). Having failed to understand the intricacies of the pci detection and configuration mechanism, I have resorted to setting up the bridge manually, and with fixed memory resources, as annotated in the code.

The Config.lb provided is set up for filo and legacy vga bios. In other words it makes an image 192K big to which a captured vga bios should be prepended.

The patch is relative to the web based CVS snapshot of 20041004-1100.

ACPI power management and interrupt routing

I have added the code which creates three new ACPI tables, and sets up the southbridge power management unit into ACPI mode.

The new tables are the:

  • Fixed ACPI Description Table (FADT)
  • Firmware ACPI Control Structure (FACS)
  • Differentiated System Description Table (DSDT)

The FADT mostly describes the power management unit, and is declared in fadt.c in the mainboard/via/epia-m directory.

The FACS is intended to provide non volatile memory to the ACPI system for suspend to disk activities. However it is currently implemented as a zeroed table. I have only included it because Linux ACPI complains if there isn't one if a FADT has been provided.

The DSDT describes the interrupt routing and power management capabilities of devices, and is what Linux uses for interrupt routing if it can. The DSDT, defined in mainboard/via/epia-m/dsdt.c is exactly that provided with the original Award bios. It has been created using the following approximate steps:

  1. Under Award Bios, 'cat /proc/acpi/dsdt > dsdt'
  2. Decompile dsdt with Intel's iasl - 'iasl -d dsdt'
  3. Compile to C table with Intel's iasl - 'iasl -tc dsdt.dsl'
  4. Copy output to mainboard/via/epia-m/dsdt.c

The award dsdt may carry the same IPR situation as the VGA bios, and it could be that the file dsdt.c should not be distributed with the code. However it is easy enough to create your own using the steps above.

The ACPI code seems to be fully functional - giving software off and reset, as well as providing power button click events (the whole reason I wrote this !!). I assume the ACPI subsystem in Linux is also shifting the processor into S1 and S2 states, and doing other things that ACPI should do, but I haven't confirmed that yet.

Boot from onboard Compact Flash

I have added a new device to the southbridge tree - southbridge/ricoh/rl5c476, which is the setup code for the Ricoh cardbus bridge found on the MII. I wasn't quite sure where to put it in the source tree, but I guessed it was more like a southbridge than anything else.

The code sets up a compact flash in the CF slot as an IDE drive based at address 0x1e8, in other words the standard address for the third IDE controller as used by Filo, Linux, and I guess Etherboot.

The code is a bit clunky in as much as it allocates fixed addresses for memory windows - which ought to be allocated by the pci detection code, but I can't figure out how to make this happen.

Filo detects the CF as drive 'hde' as long as filo has been compiled with SUPPORT_PCI=1 commented out. With SUPPORT_PCI included, filo only searches for PCI devices of the IDE controller type, whereas without it, filo will check its standard addresses for an IDE controller.

You can configure Linux to support the CF in one of two ways, depending upon your needs:

  • Standard IDE disk support. Just let the standard IDE detection code in Linux pick up the CF as a standard device. This has the advantage of being quick and easy to get going. However if you then start up pcmcia utils to deal with the pcmcia slot, you will run into difficulties as the pcmcia-utils package resets the CF slot. There might be options you can use to instruct pcmcia-utils to ignore the CF slot entirely, but I haven't found them yet.
  • PCMCIA-UTILS support. Firstly you have to tell the standard IDE detection code NOT to look for the third IDE controller, do so with a linux command line option of 'ide2=noprobe'. Next you need to set up an initrd. The pcmcia-utils HOWTO describes how to do this with 'pcinitrd'. In addition you have to add the program 'resetcf' from freebios2/util directory to the initrd, and make sure it is called just before the socket driver is loaded in the linuxrc file. This step is necessary because the yenta socket driver does not correctly clear down the state of the CF socket as left by freebios2 (detail - yenta socket driver never clears the io offset used by freebios2 to make the CF look like /dev/hde - I guess it normally relies on the power on default being zero!!!). My linux command line in filo looks like:
AUTOBOOT_FILE = "hde:/vmlinuz initrd=hde:/initrd.gz root=/dev/hde console=tty0 ide2=noprobe"

Legacy VGA BIOS

I struggled for some time getting the VGA bios to work properly, as others on the mailing list seem to be also. Here is a list of my findings:

Some people are finding that the bios initialisation code is crashing with a random interrupt vector. This always seemed to happen at cs:ip=c000:0188. A look at the actual instruction at that location reveals that it is an STI instruction which enables hardware interrupt processing, not an INTXX instruction. On freebios2, the i8259 interrupt controller is never initialised, so it is understandable that if the vga bios has been playing with interrupts that after the STI intruction a random interupt vector is issued by the i8259 - and hence the problems as reported. My fix is to include the version 1 i8259 initialisation code, and that allows the bios to finish.

The next problem encounterred was that after vga initialisation, the screen didn't come on. After groping around the XFree sources for the CLE266 I discovered a bios call to select which output device(s) to enable, and have added a call to that function to turn on the standard console. Anyone wanting the TV output or LCD panel output are recommended to look at the Xserver sources for that bios call.

The final problem was that the freebios2 code was setting up the video memory window at 0xa0000 - 0xbffff as cacheable in its fixed mtrr code. This was resolved by getting sizeram() in northbridge.c to break the main area of memory into 2 chuncks either side of this window.

MTRR's for VGA

I have added code to create correct mtrr's for the VGA framebuffer and the AGP. This has meant some minor changes in mtrr.c

AGP port and GART

The AGP bridge seems to work correctly after setting it up like award. The GART window is hard coded at address 0xd0000000, as per award, and could/should be set by the pci_device allocation code. Linux AGP support does not crash the system and I believe it to be fully working.

VT1211

I have created a new superio device for the vt1211, which sets up the hardware monitor, com ports, lpt and fdc. The h/w monitor set up values are taken from v1. None of this has been tested beyond Linux correctly spotting the devices.

1/2 speed baud rate problem

I believe that the 1/2 speed baud rate problem is down to trying to do things before the southbridge and certain clocks have fully settled down. By putting a delay after the rtc_init() and before trying to use the SMB bus, the problem seems to be rectified. The counter in the delay loop could be optimised if anyone out there has the desire - 1000 isn't enough, whilst 5000 is.

And Finally

As an indicator that the BIOS is going, I've got the power LED to blink rapidly from early on, until the BIOS has just about finished its job. Could be first thing for newcomers to look for when they don't get any other form of output.


Public domain I, the copyright holder of this work, hereby release it into the public domain. This applies worldwide.

In case this is not legally possible:
I grant anyone the right to use this work for any purpose, without any conditions, unless such conditions are required by law.