coreboot August 2008

coreboot@coreboot.org

64 participants
593 discussions

visualizing the coreboot device tree
by Stefan Reinauer 30 Sep '08

30 Sep '08

See patch -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info(a)coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 This patch creates static.dot visualizing the coreboot device tree (v2) create pngs with $ fdp -o static.png -Tpng static.dot or $ dot -o static.png -Tpng static.dot edge colors: blue: parent->self relation red: self->child relation green: self->sibling relation pink: self->next relation TODO/ideas: node colors according to device type? put devices belonging to the same parent on the same level add an agenda I don't think this should be committed yet, it's just a rough try I created to debug a problem with the device tree code / resource allocator. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Index: util/newconfig/config.g =================================================================== --- util/newconfig/config.g (revision 534) +++ util/newconfig/config.g (working copy) @@ -93,6 +93,7 @@ dict = 4 statement = 5 dump = 6 + gengraph = 7 def __init__(self, *level): self.__level = level @@ -682,6 +683,15 @@ else: name = "%s %s" % (name, self.path) return name + + def graph_name(self): + name = "" + name = "%s_%d" % (self.type_name, self.instance) +# if (self.chip_or_device == 'chip'): + name = "%s %s %s" % (name, self.part, self.parent.type_name) +# else: +# name = "%s %s" % (name, self.path) + return name def dumpme(self, lvl): """Dump information about this part for debugging""" @@ -976,6 +986,56 @@ setdict(self.uses_options, name, o) exportoption(o, self.image.exported_options) + def gengraph(self, file, pass_num): + """Generate static device tree graph for this part. Two passes + are used - the first generates type information, and the second + generates instance information""" + if (pass_num == 0): + if (self.chip_or_device == 'chip'): + return; + else: + if (self.instance): + file.write("%s[shape=box, label=\"%s\"];\n" \ + % (self.instance_name, self.graph_name())) + else: + file.write("node [shape=circle] dev_root;\n") + return + # This is pass the second, which is pass number 1 + # this is really just a case statement ... + + if (self.chip_or_device == 'chip'): + if (self.instance == 0): + self.instance_name = "dev_root" + file.write("%s -> %s ;\n" % (self.instance_name, self.firstchilddevice().instance_name)) + return + + # Don't print duplicate devices, just print their children + if (self.dup): + return + + file.write("%s -> %s [color=\"#0000ff\"]\n" % \ + (self.firstparentdevice().instance_name, self.instance_name)) + links = 0 + bus = self + while(bus and (bus.path == self.path)): + child = bus.firstchilddevice() + if (child or (bus != self) or (bus.next_sibling and (bus.next_sibling.path == self.path))): + if (child): + file.write("%s -> %s [color=\"#ff0000\"]\n" % (self.instance_name, child.instance_name)) + links = links + 1 + if (1): + bus = bus.next_sibling + else: + bus = 0 + sibling = self.firstsiblingdevice(); + if (sibling): + file.write("%s -> %s [color=\"#00ff00\"]\n" % (self.instance_name, sibling.instance_name)) + chip = self.firstparentchip() + if (self.next_device): + file.write("%s -> %s [color=\"#ff00ff\"]\n" % (self.instance_name, self.next_device.instance_name)) + return + + # ----------------------------------------------------------------------------- # statements # ----------------------------------------------------------------------------- @@ -2254,7 +2314,9 @@ file.write("#include <device/pci.h>\n") for path in image.getconfigincludes().values(): file.write("#include \"%s\"\n" % path) + file.write("\n/* pass 0 */\n") gencode(image.getroot(), file, 0) + file.write("\n/* pass 1 */\n") gencode(image.getroot(), file, 1) file.close() @@ -2278,6 +2340,36 @@ kid = kid.next_sibling debug.info(debug.gencode, "DONE GENCODE") +def writegraph(image): + filename = os.path.join(img_dir, "static.dot") + print "Creating", filename + file = safe_open(filename, 'w+') + file.write("digraph devicetree {\n") + gengraph(image.getroot(), file, 0) + gengraph(image.getroot(), file, 1) + file.write("}\n") + file.close() + +def gengraph(part, file, pass_num): + debug.info(debug.gengraph, "GENGRAPH ME is") + part.gengraph(file, pass_num) + # dump the siblings -- actually are there any? not sure + debug.info(debug.gengraph, "GENGRAPH SIBLINGS are") + kid = part.next_sibling + while (kid): + kid.gengraph(file, pass_num) + kid = kid.next_sibling + # now dump the children + debug.info(debug.gengraph, "GENGRAPH KIDS are") + if (part.children): + gengraph(part.children, file, pass_num) + kid = part.next_sibling + while (kid): + if (kid.children): + gengraph(kid.children, file, pass_num) + kid = kid.next_sibling + debug.info(debug.gengraph, "DONE GENGRAPH") + def verifyparse(): """Add any run-time checks to verify that parsing the configuration was successful""" @@ -2343,6 +2435,7 @@ writeinitincludes(image) writeimagemakefile(image) writeldoptions(image) + writegraph(image) writemakefilesettings(target_dir) writemakefile(target_dir)

4 3

Information compatibility with Intel Motherboard - S3200SHV
by DANGELSER YVES 30 Sep '08

30 Sep '08

Hello, We have receive a request from one of our customer, in order to verify and qualify Coreboot with their system. Could you please let me know if you know the Intel Motherboard S3200SHV. If you can support me it will be very helpful. regards DANGELSER YVES Responsable production. I-Bus France BP 45 80 Route des Lucioles Les Espaces de Sophia 06901 Sophia Antipolis CEDEX France Email : <mailto:ydangelser@ibus.com> ydangelser(a)industrial-computers.com Tél : +33 493 00 4368 Fax : +33 493 00 4369 Mobile : +33 682 00 4873 <http://www.industrial-computers.com/> http://www.industrial-computers.com This message and any attachments are strictly confidential and intended solely for the addressee. Any unauthorized use or disclosure, in whole or in part, is prohibited. E-mails are subject to possible alteration. IBUS and the sender decline any liability if this message and/or any attachments have been altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify immediately the sender. P Préservons l'environnement en évitant d'imprimer tous les e-mails. Merci!

2 1

[PATCH 3/6] Intel EP80579 northbridge
by Ed Swierk 25 Sep '08

25 Sep '08

This patch implements support for the memory controller and PCIe interface of the Intel EP80579 Integrated Processor. The memory controller code supports only 64-bit-wide DIMMs with x8 devices and ECC. It has been tested on a development board using a single Micron MT9HTF6472PY-667D2 DIMM. Your mileage will definitely vary with other DIMMs. Signed-off-by: Ed Swierk <eswierk(a)arastra.com>

3 8

v3 CS5536 SMBus bug
by Carl-Daniel Hailfinger 15 Sep '08

15 Sep '08

v3 can't use global variables in stage1 or initram. Same applies to static local variables. See the bug below. Ideas for fixes? The generic variable infrastructure would be one option. int smbus_read_byte(u16 device, u8 address) { //BUG here! static int first_time = 1; if (first_time) { smbus_init(); first_time = 0; } return do_smbus_read_byte(SMBUS_IO_BASE, device, address); } Regards, Carl-Daniel -- http://www.hailfinger.org/

3 7

[PATCH] v3: fix PCI bus scan / device tree interaction
by Carl-Daniel Hailfinger 08 Sep '08

08 Sep '08

Remember when I said many months ago that something with PCI was fishy? That PCI devices were in the device tree twice and init functions were called multiple times? Turns out I was right and the bug is totally nasty. I finally tracked it down after tracing function calls for 6 hours in qemu. pci_scan_bus(bus, ...) is not called with the expected bus type. Instead, it is called with a domain type from pci_domain_scan_bus(). pci_scan_bus(bus, ...) looks at bus->children and expects it to be a PCI device. Of course the children of the domain are the buses and bus->children is a PCI bus. That causes all lookups in the device tree to fail horribly. This patch fixes the dts lookup, BUT it introduces new undesired behaviour: - Only the first bus of a PCI domain is scanned. That's fixable in an obvious way. - For dynamic PCI devices on qemu, have_resources is now always 0. The reason can be seen in this error message: "read_resources: bus_0(PCI_BUS: 0000) missing phase4_read_resources" Basically, we have phase4_read_resources defined for the PCI domain, but not for PCI bus 0. We can either inherit phase4_read_resources from the domain or we define phase4_read_resources for each PCI bus. I prefer the latter. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: corebootv3-pci_scan_bus/device/pci_device.c =================================================================== --- corebootv3-pci_scan_bus/device/pci_device.c (Revision 842) +++ corebootv3-pci_scan_bus/device/pci_device.c (Arbeitskopie) @@ -636,6 +636,8 @@ vendor = mainboard_pci_subsystem_vendor; if (!device) device = mainboard_pci_subsystem_device; + } else { + printk(BIOS_DEBUG, "%s: Device not on_mainboard\n", dev_path(dev)); } #endif /* Set the subsystem vendor and device ID for mainboard devices. */ @@ -1098,6 +1100,10 @@ printk(BIOS_DEBUG, "%s start bus %p, bus->dev %p\n", __func__, bus, bus->dev); + if (bus->dev->path.type != DEVICE_PATH_PCI_BUS) + printk(BIOS_ERR, "ERROR: pci_scan_bus called with incorrect " + "bus->dev->path.type, path is %s\n", dev_path(bus->dev)); + #if PCI_BUS_SEGN_BITS printk(BIOS_DEBUG, "PCI: pci_scan_bus for bus %04x:%02x\n", bus->secondary >> 8, bus->secondary & 0xff); @@ -1139,6 +1145,8 @@ if ((PCI_FUNC(devfn) == 0x00) && (!dev || (dev->enabled && ((dev->hdr_type & 0x80) != 0x80)))) { + printk(BIOS_SPEW, "Not a multi function device, or the " + "device is not present. Skip to next device.\n"); devfn += 0x07; } } @@ -1186,8 +1194,9 @@ */ unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max) { + printk(BIOS_SPEW, "pci_domain_scan_bus: calling pci_scan_bus\n"); /* There is only one link on this device, and it is always link 0. */ - return pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, max); + return pci_scan_bus(&dev->link[0].children->link[0], PCI_DEVFN(0, 0), 0xff, max); } /** @@ -1277,6 +1286,7 @@ */ unsigned int pci_scan_bridge(struct device *dev, unsigned int max) { + printk(BIOS_SPEW, "pci_scan_bridge: calling pci_scan_bus\n"); return do_pci_scan_bridge(dev, max, pci_scan_bus); } -- http://www.hailfinger.org/

4 26

[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

CAR for C7
by bari 05 Sep '08

05 Sep '08

Anyone know the status of a patch for C7 CAR? We have most of the wrinkles ironed out of the C7 + cn700 + vt8237 boards now. Many patches to follow. -Bari

4 10

#98: Eliminate false positive "unknown .. SPI chip" matches
by coreboot 04 Sep '08

04 Sep '08

#98: Eliminate false positive "unknown .. SPI chip" matches ----------------------------------+----------------------------------------- Reporter: stuge | Owner: somebody Type: defect | Status: new Priority: major | Milestone: flashrom v1.0 Component: flashrom | Version: Keywords: spi probe | Dependencies: #97 Patchstatus: patch needs review | ----------------------------------+----------------------------------------- -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/98> coreboot <http://www.coreboot.org/>

1 4

[PATCH 2/2] libpayload: support color over serial
by Ulf Jordan 03 Sep '08

03 Sep '08

This patch adds support for color output over serial from libpayload/tinycurses. It assumes that the ACS patch has been applied first. Build and run tested (coreinfo+libpayload+coreboot-v3 in QEMU) the same way as the ACS patch. /ulf

2 2

k8 and memory training
by ron minnich 01 Sep '08

01 Sep '08

see http://coreboot.pastebin.com/m354e6401 I can't really tell if it's working. I think there is a bug in simnow spd values. Computed size of the dimms from spd data is correct. The byte at 31 in SPD claims we only have 128 MB of RAM, which is wrong. It is right for one DIMM module, but we have two; it's a factor of two off. So I've made it a warning, not an error, if spd byte 31 and computed size don't agree. ron

2 3

← Newer
1
2
3
4
5
6
7
...
60
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 August 2008