coreboot January 2008

coreboot@coreboot.org

79 participants
347 discussions

[LinuxBIOS] Welcome to coreboot.
by ron minnich 18 Jan '08

18 Jan '08

Welcome to coreboot! It's been 10 years (in octal anyway!) since the first successful LinuxBIOS boot. In those days, by design, LinuxBIOS looked like this: LinuxBIOS = (core boot code) + (Linux kernel) We did not consider LinuxBIOS to be separable in any way from Linux, and in fact the name LinuxBIOS really meant just that -- Linux as the BIOS. In the early config tool, there was no 'payload' keyword: there was a 'linux' keyword, since only linux payloads were supported. Several things happened in the following years. While this: LinuxBIOS = (core boot code) + (Linux 2.2 kernel) fit easily in 512 Kbytes, this: LinuxBIOS = (core boot code) + (Linux 2.4 kernel) required 1 Mbyte. At about the same time we moved to 2.4, vendors moved the flash sizes ... down. In 1999, 1 Mbyte flash sizes were common on the cluster nodes we intended to use LinuxBIOS on; by 2001, 256KB was the limit, and it was physically impossible to put anything larger than 512KB on the systems.The result was that LinuxBIOS could no longer use Linux on these systems! At that point, people started to change to this: LinuxBIOS = (core boot code) + (Etherboot) But, that was a little confusing. LinuxBIOS did not really mean "Etherboot". So we actually did this with the name: BIOS ROM = (LinuxBIOS) + (Etherboot) In other words, we shrunk the scope of LinuxBIOS to mean 'the core boot code'. So, what we really meant was "core boot code" but we called it "LinuxBIOS". Of course, people did not stop there. By now, we have seen: BIOS ROM = (LinuxBIOS) + (Open Firmware) BIOS ROM = (LinuxBIOS) + (Slim Line Open Firmware) BIOS ROM = (LinuxBIOS) + (FILO) BIOS ROM = (LinuxBIOS) + (GRUB 2) BIOS ROM = (LinuxBIOS) + (Plan 9 loader) BIOS ROM = (LinuxBIOS) + (Plan 9 kernel) BIOS ROM = (LinuxBIOS) + (WIN CE loader) BIOS ROM = (LinuxBIOS) + (Open BIOS) BIOS ROM = (LinuxBIOS) + (Linux kernel) BIOS ROM = (LinuxBIOS) + (ADLO) (which lets us boot Windows) BIOS ROM = (LinuxBIOS) + (Tiano Core) And many other uses we don't even know about! It may well be that a larger variety of BIOSes have been supported on the LinuxBIOS core boot code than any other software. As you can see, what LinuxBIOS has really meant for the past few years is "the core boot code". In almost every case, when a system has shipped with "LinuxBIOS", what it has really shipped with is the "core boot code" + "a boot loader such as FILO". There has been no Linux in the ROM on these systems. At the same time, the use of the name "Linux" in "LinuxBIOS" has led to lots of confusion. Many companies had trouble thinking about the name, as they assumed (not unreasonably) that we were requiring Linux in ROM. As a result, starting last year, we decided to look at a new name. We had lots of candidates, and discussed the name with many companies. In the end, the name that seemed to stick was "coreboot". It makes a lot of sense: the code we are working on is the "core boot code". So, starting this year, the 10th (base 8!) anniversary of the first LinuxBIOS boot, we are transitioning to the name coreboot. As you can see from the above, coreboot can support all kinds of software, still including Linux. What of the name LinuxBIOS? It still has meaning. When a company ships a system that looks like this: BIOS ROM = (coreboot) + (Linux 2.6 kernel) What do we call it? Well, that system is LinuxBIOS in the original sense of the term -- Linux as the BIOS. And, as it happens, more and more companies are shipping systems configured this way. This name change was a lot of work. A great deal of behind-the-scenes work has been done by Stefan Reinauer, so I hope you will join me in thanking Stefan for a job well done. We will make the changes slowly and with a lot of preparation. You have already seen the IRC channel change, and host names change over to coreboot.org. At some point in the next three months you will see a change in the svn repository name. We're going to be very careful to ensure nothing breaks. As always, thanks for all your help and support. I look forward to the next 10 (base 10!) years. Ron Minnich

7 8

Config.lb versus static.c inconsistency.
by Steve Isaacs 18 Jan '08

18 Jan '08

I'm seeing something I need help explaining. Basically, I have three devices that are not being enabled. Here is what is being shown as part of the pci_scan_bus for bus 00. I've added some diagnostic information to the spew for the function being called and for one of the devices I'm interested in. pci_probe_dev:PCI: 00:03.6 [14e4/b514] enabled pci_probe_dev:PCI: 00:03.7 [14e4/b514] enabled pci_probe_dev:dev->device 0x00000420 dev->ops 0x00011D80 disabled pci_probe_dev:PCI: 00:04.0 [1166/0420] disabled pci_probe_dev:PCI: 00:04.1 [1166/042a] enabled pci_probe_dev:PCI: 00:05.0 [1166/0422] disabled pci_probe_dev:PCI: 00:05.1 [1166/042a] enabled The device 00:04.0 is a PCIe bridge. Here's an excerpt from Config.lb for that device. Note that it is configured to be "on". end device pci 3.0 on # EXB0 0x0420 -- Essential end device pci 3.1 on # IOMMU 0x042A -- Essential end device pci 4.0 on # EXB1 0x0422 And, finally, here's an excerpt from the generated static.c for the same device. struct device _dev56 = { .ops = 0, .bus = &_dev8.link[1], .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x3,0)}}}, .enabled = 0, .on_mainboard = 1, .link = { }, .links = 0, .sibling = &_dev57, .next=&_dev57 }; The same is occurring for two other devices in addition to this one. Any suggestions? Thanks, Steve

2 2

mail archive urls not matching up?
by Robinson Tryon 17 Jan '08

17 Jan '08

While updating content on the wiki, I noticed that there are some discrepancies between urls. For example, these two urls give the same content: http://www.linuxbios.org/pipermail/linuxbios/2007-September/024916.html http://www.coreboot.org/pipermail/linuxbios/2007-September/024916.html But this one does not match: http://www.coreboot.org/pipermail/coreboot/2007-September/024916.html Any idea why this is happening? (were the archives regenerated at some point?)

2 2

Commerical support for Linux BIOS
by Phani Babu Giddi 17 Jan '08

17 Jan '08

Hello All, Are there companies which are providing BIOS Firware based on "Linux BIOS" Regards, Phani

5 6

r556 - in coreboot-v3: device include/device
by svn＠coreboot.org 17 Jan '08

17 Jan '08

Author: rminnich Date: 2008-01-17 17:32:12 +0100 (Thu, 17 Jan 2008) New Revision: 556 Modified: coreboot-v3/device/device.c coreboot-v3/include/device/device.h Log: This change is for tidying up some unfinished business in the device code. 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(a)gmail.com> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: coreboot-v3/device/device.c =================================================================== --- coreboot-v3/device/device.c 2008-01-17 05:37:41 UTC (rev 555) +++ coreboot-v3/device/device.c 2008-01-17 16:32:12 UTC (rev 556) @@ -88,21 +88,6 @@ } /** - * Initialization tasks for the device tree code. - * - * At present, merely sets up last_dev_p, which used to be done by - * Fucking Magic (FM) in the config tool. - */ -void dev_init(void) -{ - struct device *dev; - - for (dev = all_devices; dev; dev = dev->next) { - last_dev_p = &dev->next; - } -} - -/** * The default constructor, which simply sets the ops pointer. * * Initialize device->ops of a newly allocated device structure. @@ -149,6 +134,30 @@ } /** + * Initialization tasks for the device tree code. + * + * Sets up last_dev_p, which used to be done by + * Fucking Magic (FM) in the config tool. Also, for each of the + * devices, tries to find the constructor, and from there, the ops, + * for the device. + */ +void dev_init(void) +{ + struct device *dev; + struct constructor *c; + + for (dev = all_devices; dev; dev = dev->next) { + c = find_constructor(&dev->id); + /* note the difference from the constructor function below. + * we are not allocating the device here, just setting the ops. + */ + if (c) + dev->ops = c->ops; + last_dev_p = &dev->next; + } +} + +/** * Given a path, find a constructor, and run it. * * Given a path, call find_constructor to find the constructor for it. @@ -725,6 +734,9 @@ printk(BIOS_DEBUG, "Phase 2: Early setup...\n"); for (dev = all_devices; dev; dev = dev->next) { printk(BIOS_SPEW, "%s: dev %s: ", __FUNCTION__, dev->dtsname); + printk(BIOS_SPEW, "%s: ops %p ops->phase2_setup_scan_bus %p\n", + __FUNCTION__, dev->ops, + dev->ops? dev->ops->phase2_setup_scan_bus : "None"); if (dev->ops && dev->ops->phase2_setup_scan_bus) { printk(BIOS_SPEW, "Calling phase2 phase2_setup_scan_bus..."); Modified: coreboot-v3/include/device/device.h =================================================================== --- coreboot-v3/include/device/device.h 2008-01-17 05:37:41 UTC (rev 555) +++ coreboot-v3/include/device/device.h 2008-01-17 16:32:12 UTC (rev 556) @@ -185,9 +185,11 @@ struct device * next; /* chain of all devices */ struct device_path path; + struct device_id id; char dtsname[MAX_DTSNAME_SIZE]; /* the name from the dts */ - unsigned vendor; - unsigned device; + /* XXX remove this soon */ + unsigned device, vendor; + /* XXX */ u16 status; u8 revision; u8 cache_line;

1 0

chipset "NVIDIA® nForce 570 SLI MCP"
by qweasdyxc0＠googlemail.com 17 Jan '08

17 Jan '08

Hi! Since last year v2 is (almost?) running on the Gigabyte GA-M57SLI-S4. This board uses chipset "NVIDIA® nForce 570 SLI MCP" (see http://www.coreboot.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial or http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?Prod…) As a newbie my first question is, of course, a stupid one: the "MSI "K9N SLI Platinum" uses the same chipset (see http://global.msi.com.tw/index.php?func=proddesc&prod_no=251&maincat_no=1&c…). Well, actually I would prefere another chipset, but what is the problem in terms of LinuxBIOS to get this (MSI) board working/running LB (the same level as the Gigabyte one)? Of course I kind of studied more than once the mailing list, the wiki and many relatet sites. Please keep in mind, I'm an absolute beginner to LB an just wondering why. And I'm looking to get into this holy stuff. Anyway thanks for the great work! Peter

1 0

[PATCH] (resend) fix the flashrom problem on m57sli boards with SPI flash
by Florentin Demetrescu 17 Jan '08

17 Jan '08

This patch fixes the decoding of the IO address range 0x0800->0x085f into the LPC device of the MCP55 southbridge, enabling flashrom access to the SPI interface of the IT8716 SIO chip. Signed-off-by: Florentin Demetrescu <echelon(a)free.fr> Patch file attached. Thanks, Florentin

3 3

flashrom problems on VIA EPIA
by George V. Adamov 17 Jan '08

17 Jan '08

I tried to use flashrom from LB/util/flashrom this what I have got first run to test # ./flashrom Calibrating delay loop... ok No LinuxBIOS table found Found chipset "VT8235": Enabling flash write... Ok Found board "VIA EPIA M/MII/... " Enabling flash write... Ok SST39SF020A found at physical address: 0xfffc0000 Flash part is SST39SF020A (256Kb) Ok, onla ENABLING flash write, but NOT flashing. # That"s seems to be ok, board and flash part indeed matches to the hardware ))) Now I ma trying to flash #./flashrom -w linuxbios.rom Calibrating delay loop... ok No LinuxBIOS table found Found chipset "VT8235": Enabling flash write... Ok Found board "VIA EPIA M/MII/... " Enabling flash write... Ok SST39SF020A found at physical address: 0xfffc0000 Flash part is SST39SF020A (256Kb) linuxbios.rom: Bad address # so, I tried to save image from flash, and tried to flash whith saved image and got the same Bad address. Could somebody tell what the trouble is?

2 1

This change is for tidying up some unfinished business in the device code.
by ron minnich 17 Jan '08

17 Jan '08

This is the beginning of a set of needed changes to get the geode running. Comments welcome. I'll hold off on further patches until people get a look at this and see if it is ok. Thanks! ron

2 1

Re: [coreboot] [LinuxBIOS] PATCH: lx car that returns from disable_car
by ron minnich 17 Jan '08

17 Jan '08

On Jan 11, 2008 4:01 PM, Marc Jones <marc.jones(a)amd.com> wrote: > Ron, > > I think I am up to the same point you are. It looks like there is a > problem in the device scanning. > > void dev_phase2(void) should call geodelx_pci_domain_phase2() for the > southbridge device. > > Here is the output. Is this the correct order? It seems strange. > > Phase 2: Early setup... > dev_phase2: dev root: > dev_phase2: dev cpus: > dev_phase2: dev device0_0: > dev_phase2: dev southbridge: > dev_phase2: dev domain0: > Phase 2: Done. > I just realized there was no dts in northbridge/amd/geodelx ... this is a possible problem. patch attached. ron

2 2

← Newer
1
...
17
18
19
20
21
22
23
...
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2008