coreboot September 2008

coreboot@coreboot.org

59 participants
415 discussions

link representation in v3 dts
by Carl-Daniel Hailfinger 07 Sep '08

07 Sep '08

Since link representation is a difficult topic to understand and present cleanly, I tried to use the v2 S2892 Config.lb into a v3 dts. Attached are a shortened version of the v2 Config.lb and the mostly matching v3 dts. Regards, Carl-Daniel -- http://www.hailfinger.org/ /* * This file is part of the coreboot project. * * Copyright (C) 2008 Ronald G. Minnich <rminnich(a)gmail.com> * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ /{ mainboard_vendor = "Tyan"; mainboard_name = "S2892"; cpus { }; apic@0 { }; domain@0 { pci@18,0 { children_as_links; link@0 { pci@0,0 { /* HT */ /config/("southbridge/nvidia/ck804/dts"); }; pci@1,0 { /* LPC */ }; pci@1,1 { /* SMBUS */ children_as_links; /*Fill in here*/ }; pci@2,0 { /* USB 1.1 */ }; pci@2,1 { /* USB 2.0 */ }; pci@4,0 { /* ACI */ }; pci@4,1 { /* MCI */ }; pci@6,0 { /* IDE */ }; pci@7,0 { /* SATA 1 */ }; pci@8,0 { /* SATA 0 */ }; pci@9,0 { /* PCI */ bus@0 { /* Fill in here */ }; }; pci@a,0 { /* NIC */ }; pci@b,0 { /* PCIe 3 */ }; pci@c,0 { /* PCIe 2 */ }; pci@d,0 { /* PCIe 1 */ }; pci@e,0 { /* PCIe 0 */ }; }; link@1 { }; link@2 { pci@0,0 { /* HT */ /config/("southbridge/amd/amd8131/dts"); }; pci@0,1 { }; pci@1,0 { bus@0 { pci@9,0 { /* Broadcom 5704 */ }; pci@9,1 { }; }; }; pci@1,1 { }; }; }; pci@18,1 { }; pci@18,2 { }; pci@18,3 { }; ioport@2e { /config/("superio/winbond/w83627hf/dts"); com1enable = "1"; }; }; }; # sample config for tyan/s2892 chip northbridge/amd/amdk8/root_complex device apic_cluster 0 on chip cpu/amd/socket_940 device apic 0 on end end end device pci_domain 0 on chip northbridge/amd/amdk8 #mc0 device pci 18.0 on # northbridge # devices on link 0, link 0 == LDT 0 chip southbridge/nvidia/ck804 device pci 0.0 on end # HT device pci 1.0 on # LPC device pci 1.1 on # SM 0 device pci 1.1 on # SM 1 device pci 2.0 on end # USB 1.1 device pci 2.1 on end # USB 2 device pci 4.0 off end # ACI device pci 4.1 off end # MCI device pci 6.0 on end # IDE device pci 7.0 on end # SATA 1 device pci 8.0 on end # SATA 0 device pci 9.0 on # PCI chip drivers/pci/onboard device pci 6.0 on end end chip drivers/pci/onboard device pci 8.0 on end end end device pci a.0 off end # NIC device pci b.0 off end # PCI E 3 device pci c.0 off end # PCI E 2 device pci d.0 on end # PCI E 1 device pci e.0 on end # PCI E 0 end end # device pci 18.0 device pci 18.0 on end # Link 1 device pci 18.0 on # devices on link 2, link 2 == LDT 2 chip southbridge/amd/amd8131 # the on/off keyword is mandatory device pci 0.0 on end device pci 0.1 on end device pci 1.0 on chip drivers/pci/onboard device pci 9.0 on end # broadcom 5704 device pci 9.1 on end end end device pci 1.1 on end end end # device pci 18.0 device pci 18.1 on end device pci 18.2 on end device pci 18.3 on end end #mc0 end # pci_domain end # root_complex

2 1

VIA C7 + CN700 + VT8237r boards are back in stock $59.99
by bari 07 Sep '08

07 Sep '08

For anyone looking to develop with the VIA C7 + CN700 + VT8237r The pc2500e boards are back in stock: http://www.clubit.com/product_detail.cfm?itemno=A4842001 -Bari

1 0

wiki account request (for GRUB 2)
by Robert Millan 07 Sep '08

07 Sep '08

Hi, I notice in http://tracker.coreboot.org/trac/coreboot/ticket/88 that Coresystems is no longer working on GRUB 2 (that's too bad, sorry that it didn't work out, etc...). I have nothing to say about what you will be recommending as default bootloader in the future. Right now your wiki still recommends GRUB 2, and I suppose Coresystems folks will want to push for FILO. But this is not a discussion I want to be involved in (just wanted to clarify ;-)). What I'm concerned about is that http://www.coreboot.org/GRUB2 in the wiki currently points to a branch of GRUB that is (unless I missed something) no longer being maintained. And it provides information that will, over time, become more and more obsolete. I'm worried that this can reflect bad on the image of GRUB. So what I'd like is permission to keep it up to date, and reflect the current state of GRUB mainline. If you would give me a wiki account to do that, it'd be much appreciated. Thanks -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."

6 16

Cache as RAM - is it possible to execute code in cache?
by Jackie Pan 06 Sep '08

06 Sep '08

Hi all, I'm wondering if it's possible to place code into cache-emulated RAM, I tested on an intel T2300, after CAR setup, I can read/write to the mapped region, however code execution seems not working. Postcode reveals that the CPU seems to be spinning on the very first instruction in the 'RAM' region. Anyone could give some hints? thanks.

5 11

[PATCH] v3: more uniqueness in the dtc generated struct names
by Carl-Daniel Hailfinger 06 Sep '08

06 Sep '08

I managed to break dtc while working on PCI bridges: dtc only uses dev_fn as identifier for a PCI device. That gets us a name collision if we have the same dev_fn combination on multiple buses. Either we add a random unique ID to the struct name or we integrate the number of the parent device as well. A third option would be to store the complete hierarchy in the name. I decided to go for integration of parent device name. With the following device tree /{ cpus {}; domain@0 { bus@0 { pci@0,0 { }; pci@1,1 { }; pci@f,0 { bus@1 { pci@0,0 { }; }; }; }; }; }; we get the old names: dev_root dev_cpus dev_domain_0 dev_bus_0 dev_pci_0_0 dev_pci_1_1 dev_pci_f_0 dev_bus_1 dev_pci_0_0 COLLISION!!! and the new names: dev_root dev_cpus dev_domain_0 dev_domain_0_bus_0 dev_bus_0_pci_0_0 dev_bus_0_pci_1_1 dev_bus_0_pci_f_0 dev_pci_f_0_bus_1 dev_bus_1_pci_0_0 and the third option (not used) would have looked like this: dev_root dev_cpus dev_domain_0 dev_domain_0_bus_0 dev_domain_0_bus_0_pci_0_0 dev_domain_0_bus_0_pci_1_1 dev_domain_0_bus_0_pci_f_0 dev_domain_0_bus_0_pci_f_0_bus_1 dev_domain_0_bus_0_pci_f_0_bus_1_pci_0_0 Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: corebootv3-pci_scan_bus/util/dtc/flattree.c =================================================================== --- corebootv3-pci_scan_bus/util/dtc/flattree.c (Revision 846) +++ corebootv3-pci_scan_bus/util/dtc/flattree.c (Arbeitskopie) @@ -931,6 +931,7 @@ emit->endnode(etarget, treelabel); } + //fprintf(f, "//tree->label is %s, tree->parent->label is %s\n", tree->label, tree->parent ? tree->parent->label : NULL); /* now emit the device for this node, with sibling and child pointers etc. */ emit->special(f, tree); @@ -1313,8 +1314,23 @@ labeltree(struct node *tree) { struct node *child; + char *tmp1; + char *tmp2; + //printf("//tree->label is %s, tree->parent->label is %s\n", tree->label, tree->parent ? tree->parent->label : NULL); tree->label = clean(tree->name, 1); + if (tree->parent && tree->label) { + tmp1 = clean(tree->parent->name, 1); + if (strlen(tmp1)) { + tmp2 = tree->label; + tree->label = malloc(strlen(tmp1) + strlen(tmp2) + 2); + strcpy(tree->label, tmp1); + strcat(tree->label, "_"); + strcat(tree->label, tmp2); + free(tmp2); + } + free(tmp1); + } if (tree->next_sibling) labeltree(tree->next_sibling); -- http://www.hailfinger.org/

2 4

r860 - coreboot-v3/util/dtc
by svn＠coreboot.org 06 Sep '08

06 Sep '08

Author: hailfinger Date: 2008-09-06 22:39:25 +0200 (Sat, 06 Sep 2008) New Revision: 860 Modified: coreboot-v3/util/dtc/flattree.c Log: I managed to break dtc while working on PCI bridges: dtc only uses dev_fn as identifier for a PCI device. That gets us a name collision if we have the same dev_fn combination on multiple buses. Either we add a random unique ID to the struct name or we integrate the path to the parent device as well. I decided to go for integration of parent device path. With the following device tree /{ cpus {}; domain@0 { bus@0 { pci@0,0 { }; pci@1,1 { }; pci@f,0 { bus@1 { pci@0,0 { }; }; }; }; }; }; we get the old names: dev_root dev_cpus dev_domain_0 dev_bus_0 dev_pci_0_0 dev_pci_1_1 dev_pci_f_0 dev_bus_1 dev_pci_0_0 COLLISION!!! and the new names: dev_root dev_cpus dev_domain_0 dev_domain_0_bus_0 dev_domain_0_bus_0_pci_0_0 dev_domain_0_bus_0_pci_1_1 dev_domain_0_bus_0_pci_f_0 dev_domain_0_bus_0_pci_f_0_bus_1 dev_domain_0_bus_0_pci_f_0_bus_1_pci_0_0 Ron would like shorter names because they only have to be machine-readable. That's left for another patch. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Modified: coreboot-v3/util/dtc/flattree.c =================================================================== --- coreboot-v3/util/dtc/flattree.c 2008-09-06 20:30:26 UTC (rev 859) +++ coreboot-v3/util/dtc/flattree.c 2008-09-06 20:39:25 UTC (rev 860) @@ -1311,8 +1311,22 @@ labeltree(struct node *tree) { struct node *child; + char *tmp1; + char *tmp2; tree->label = clean(tree->name, 1); + if (tree->parent && tree->label) { + tmp1 = strdup(tree->parent->label); + if (strlen(tmp1)) { + tmp2 = tree->label; + tree->label = malloc(strlen(tmp1) + strlen(tmp2) + 2); + strcpy(tree->label, tmp1); + strcat(tree->label, "_"); + strcat(tree->label, tmp2); + free(tmp2); + } + free(tmp1); + } if (tree->next_sibling) labeltree(tree->next_sibling);

1 0

r859 - coreboot-v3/util/dtc
by svn＠coreboot.org 06 Sep '08

06 Sep '08

Author: hailfinger Date: 2008-09-06 22:30:26 +0200 (Sat, 06 Sep 2008) New Revision: 859 Modified: coreboot-v3/util/dtc/flattree.c Log: The .next pointer was written twice for every struct device in statictree.c. This bug was introduced in r175. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: coreboot-v3/util/dtc/flattree.c =================================================================== --- coreboot-v3/util/dtc/flattree.c 2008-09-05 10:29:33 UTC (rev 858) +++ coreboot-v3/util/dtc/flattree.c 2008-09-06 20:30:26 UTC (rev 859) @@ -661,8 +661,6 @@ } if (tree->next_sibling) fprintf(f, "\t.sibling = &dev_%s,\n", tree->next_sibling->label); - if (tree->next) - fprintf(f, "\t.next = &dev_%s,\n", tree->next->label); /* now do we do next? */ /* this will need to do a bus for every child. And, below, we're going to need to find which bus we're on*/ /* for now, let's keep it to the minimum that will work, while we see if we like this. */

1 0

current dtc patch
by ron minnich 06 Sep '08

06 Sep '08

no ack in it, for your viewing pleasure. Tested on dbe62. ron

2 5

dtc patch: make all names unique, misc. cleanup, more to come
by ron minnich 06 Sep '08

06 Sep '08

This resolves the "unique name" problem. It sets up for k8 CPUs with multiple busses per chip. Comments welcome. I realize this code is not ideal :-) ron

2 7

Kernel hang solid
by Vincent Legoll 06 Sep '08

06 Sep '08

Could someone explain the differences in linux kernel boot logs for coreboot vs BIOS that are attached. The coreboot log is here too, just in case. The total absence of reserved memory ranges seems unnatural. The DMA zone range starting at 0x00000001 looks fishy too. I'm completely lost, the hang happen at init/main.c in console_init() -- Vincent Legoll

4 7

← Newer
1
...
33
34
35
36
37
38
39
...
42
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 September 2008