Read-only mirror of https://review.coreboot.org/coreboot.git. Synced every hour. We don't handle Pull Requests.
https://coreboot.org
- C 93.8%
- ASL 2.2%
- Makefile 1.1%
- C++ 0.5%
- Pawn 0.5%
- Other 1.8%
7e806b90e6
I just uncovered this problem while trying to get the lx going.
The symptom was that the northbridge ops were never getting run,
in particular the phase 2 ops for the geodelx were not running. The
reason was that the ops struct member for the device was not set.
How is the ops struct member set?
Currently, the ops vector for a static device (i.e. a device created from the
dts) has to be set by hand, as in mainboard/emulation/qemu-x86/dts:
domain0 {
/config/("northbridge/intel/i440bxemulation");
ops = "i440bxemulation_pcidomainops";
This requirement is ridiculous (it's my fault). If we know the part,
and have the dts, we should not have to explicitly name the ops. In fact the
constructors array, defined at the end of the various device files, makes
searching for an ops struct for a dynamic device automatic. We should
support this automatic behavior for static devices too.
Given the function find_constructor
in device/device.c, why don't we just use that? The problem is that we did
not set up the device struct to include a device id, just a device path, and
find_constructor requires a device_id -- which makes sense, I hope,
as the path is its pci path (e.g. 0:1.0) and the constructors are defined by the
device id (i.e. it is the same constructor for a given part, no matter how many
of the part we have).
So, as a start to fixing this limitation (this is going to take several patches),
I've done the following:
1. add a struct device_id to the device struct.
2. extended the dev_init code in device/device.c -- this is the first function
called from lib/stage2.c -- to find a constructor for the dev->id and, if
found, set dev->ops to it.
Result: for static devices with the id set, the ops pointer will be set
automatically. Coreboot builds fine with this change.
The next change will be to add dtc commands to set ids.
Currently, we have commands like pcipath, pcidomain, etc.;
the new commands will look like pciid, domainid, etc. Once we have these
commands, we will have made it possible to set ops automatically. We
can just set the ids in the device dts file, and users will never have to
see any of this complication.
The final change will be a bit more complicated. Right now, if you look in,
e.g., northbridge/amd/geodelx/dts, you'll see that we have one dts, but
the northbridge plays three roles. We can't easily contain those three
roles in one dts (I am open to suggestions showing I am wrong).
I am going to propose that we have more than one dts file
in a directory, so instead of
northbridge/amd/geodelx/dts
we would have
northbridge/amd/geodelx/dtsdomain
northbridge/amd/geodelx/dtsapic
northbridge/amd/geodelx/dtspci
so that we could set the variables for each of these individual components.
There is no need to split geodelx.c into three .c files, however.
Finally, I will be removing the archaic vendor and device unsigned's from
the device struct in future, but as I say, I am trying to stage these changes
to keep them understandable.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://coreboot.org/repository/coreboot-v3@556 f3766cd6-281f-0410-b1cd-43a5c92072e9
|
||
|---|---|---|
| arch/x86 | ||
| device | ||
| doc/design | ||
| include | ||
| lib | ||
| mainboard | ||
| northbridge | ||
| southbridge | ||
| superio | ||
| util | ||
| COPYING | ||
| HACKING | ||
| Kconfig | ||
| Makefile | ||
| README | ||
| Rules.make | ||
-------------------------------------------------------------------------------
LinuxBIOS README
-------------------------------------------------------------------------------
LinuxBIOS is a Free Software project aimed at replacing the proprietary
BIOS you can find in most of today's computers.
It performs just a little bit of hardware initialization and then executes
one of many possible payloads.
Payloads
--------
After the basic initialization of the hardware has been performed, any
desired "payload" can be started by LinuxBIOS. Examples include:
* A Linux kernel
* FILO (a simple bootloader with filesystem support)
* GRUB2 (a free bootloader; support is in development)
* OpenBIOS (a free IEEE1275-1994 Open Firmware implementation)
* Open Firmware (a free IEEE1275-1994 Open Firmware implementation)
* SmartFirmware (a free IEEE1275-1994 Open Firmware implementation)
* GNUFI (a free, UEFI-compatible firmware)
* Etherboot (for network booting and booting from raw IDE or FILO)
* ADLO (for booting Windows 2000 or OpenBSD)
* Plan 9 (a distributed operating system)
* memtest86 (for testing your RAM)
Supported Hardware
------------------
LinuxBIOS supports a wide range of chipsets, devices, and mainboards.
For details please consult:
* http://www.linuxbios.org/Supported_Motherboards
* http://www.linuxbios.org/Supported_Chipsets_and_Devices
Build Requirements
------------------
* gcc / g++
* make
* bison
* flex
* libncurses5-dev
Optional (for generating/viewing documentation):
* lyx
* doxygen
Building And Installing
-----------------------
Note: Currently only the x86 QEMU target is supported in LinuxBIOSv3.
1) Build a payload:
THIS IS NOT IMPLEMENTED YET. PLEASE BUILD YOUR PAYLOAD MANUALLY.
$ make payload
This step is optional. The 'make payload' command will execute a
helper tool which allows you to easily build and configure a wide
variety of payloads. The result of this step is usually a file
called 'payload.elf' in the top-level directory.
2) Configure LinuxBIOS:
$ make menuconfig
Select at least the desired mainboard vendor, the mainboard device, and
the size of your ROM chip. Per default LinuxBIOS will look for a file
called 'payload.elf' in the current directory and use that as the payload.
If that's not what you want, you can change the path/filename of the
payload to use some other payload file. Or you can choose 'No payload'
in the configuration menu, in which case the resulting LinuxBIOS ROM image
will not contain any payload. You'll have to manually add a payload
later using the 'lar' utility for the LinuxBIOS ROM image to be useful.
3) Build the LinuxBIOS ROM image:
$ make
The generated ROM image is the file linuxbios.rom in the build/ directory.
4) Flash the LinuxBIOS ROM image on a BIOS chip:
$ flashrom -wv linuxbios.rom
NOTE: This step will OVERWRITE the current BIOS located on the ROM chip!
Make sure you have adequate backup facilities before performing this
step, otherwise you might not be able to recover in case of problems.
If you have any questions, please contact us on the mailing list!
The 'flashrom' tool is located in util/flashrom where you can build it
from source code by typing 'make'. Alternatively, your favorite Linux
distribution might ship a 'flashrom' package which provides the 'flashrom'
program in (e.g.) /usr/sbin. On Debian GNU/Linux systems you can get
the flashrom package via 'apt-get install flashrom'.
Testing LinuxBIOS Without Modifying Your Hardware
-------------------------------------------------
If you want to test LinuxBIOS without any risks before you really decide
to use it on your hardware, you can use the QEMU system emulator to run
LinuxBIOS virtually in QEMU.
The required steps are:
$ make menuconfig
Select 'Emulated systems' as mainboard vendor and 'QEMU x86' as
mainboard model.
$ make
$ qemu -L build -hda /dev/zero -serial stdio
This will run LinuxBIOS in QEMU and output all debugging messages (which
are usually emitted to a serial console) on stdout. It will not do
anything useful beyond that, as you provided no virtual harddrive to
QEMU (-hda /dev/zero).
If you have a full QEMU hard drive image (say /tmp/qemu.img) with a Linux
distribution installed, you can boot that Linux kernel by using a proper
FILO payload with LinuxBIOS and typing:
$ qemu -L build -hda /tmp/qemu.img -serial stdio
Installing a Linux distribution in QEMU and building the FILO payload is
beyond the scope of this document.
Website and Mailing List
------------------------
Further details on the project, a FAQ, many HOWTOs, news, development
guidelines and more can be found on the LinuxBIOS website:
http://www.linuxbios.org
You can contact us directly on the LinuxBIOS mailing list:
http://www.linuxbios.org/Mailinglist
Copyright and License
---------------------
The copyright on LinuxBIOS is owned by quite a large number of individual
developers and companies. Please check the individual source files for details.
LinuxBIOS is licensed under the terms of the GNU General Public License (GPL).
Some files are licensed under the "GPL (version 2, or any later version)",
and some files are licensed under the "GPL, version 2". For some parts,
which were derived from other Free Software projects, other (GPL-compatible)
licenses may apply. Please check the individual source files for details.
This makes the resulting LinuxBIOS images licensed under the GPL, version 2.