coreboot September 2008

coreboot@coreboot.org

59 participants
415 discussions

using COM2 on Geode GX-1 system (v2)?
by Jonathan Sturges 09 Sep '08

09 Sep '08

Hi, I have a perfectly working coreboot v2 image for a GX-1 target of mine, but when I tried to switch it from COM1 to COM2, I can't make it work. I thought it would be as easy as updating TTYS0_BASE from 0x3f8 to 0x2f8 in Options.lb, but that doesn't work. What's the trick to making this work? thanks, Jonathan

2 1

global_vars
by Kevin O'Connor 09 Sep '08

09 Sep '08

Hi, I was looking through the v3 code and came across this: void *bottom_of_stack(void) { /* -4 because CONFIG_CARBASE + CONFIG_CARSIZE - 4 is initial %esp */ return (void *)(CONFIG_CARBASE + CONFIG_CARSIZE - 4); } struct global_vars *global_vars(void) { return *(struct global_vars **)(bottom_of_stack() - sizeof(struct global_var\ s *)); } [...] void __attribute__((stdcall)) stage1_main(u32 bist, u32 init_detected) { struct global_vars globvars; If I understand the code correctly, the global_vars() function is trying to get at the stack variable globvars declared in stage1_main. It's not valid to do that - the compiler is free to re-order stack variables, change them, or otherwise do funky things. A better way to do this would be to have some assembler code prior to stage1_main() reserve the space for globvars. -Kevin

2 2

[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

[RFC] v3 dtc testsuite
by Carl-Daniel Hailfinger 08 Sep '08

08 Sep '08

Hi, the v3 dtc code has been an area where we had bugs in the past, and I believe we might hit some old bugs and/or introduce new bugs in the future. I'd like to spot bugs as early as possible during compile time, not as random corruption/crash/misbehaviour during runtime. I have a simple testcase dts on my disk which caused the generated statictree.c to explode during compilation. That dtc bug was fixed by the struct naming patch in r860. There also is a more complicated torture dts for which statictree.c will cause runtime NULL dereferences. Checking this at compile time would require the build system to compile statictree.c and a verification walker with HOSTCC before including it in the build. Should we introduce compile-time checks for any possible bugs, especially those we already hit in the past? What do you think? Regards, Carl-Daniel -- http://www.hailfinger.org/

3 2

Status of M2N SLI Deluxe Patch
by fred 08 Sep '08

08 Sep '08

Using SVN from 08/28/08 with Uwe Hermann's v2_asus_m2n_sli_deluxe_firsttry.patch applied, I get coreboot-2.0.0.0Fallback Sun Sep 7 16:18:34 PDT 2008 starting... *sysinfo range: [000cf000,000cf730) bsp_apicid=00 Enabling routing table for node 00 done. Enabling UP settings coherent_ht_finalize done core0 started: started ap apicid: 01 SBLink=00 NC node|link=00 begin msr fid, vid 310a16160a110202 set fid failed for apicid =00 end msr fid, vid 310a160a0a110210 mcp55_num:01 Machine then powers itself off. Any ideas on how to fix this ?

1 0

acpi stuff for winxp
by Kevin O'Connor 07 Sep '08

07 Sep '08

Hi Rudolf, As requested, I'm sending the current diff for my tree. It's a wild scattering of half baked things. I'll describe the important stuff here - the rest of the patch is just junk: * Windows really wants fadt->smi_cmd, fadt->acpi_enable, and fadt->acpi_disable to be non zero. * The coreboot acpi_facs_t table has incorrect pad (it has 33, but it should be 31). I'm not sure if this confuses Windows, or if it causes other acpi tables to be aligned in a way that Windows doesn't like. * Windows needs a _CRS definition for PCI0. I grabbed one from qemu after applying a patch proposed on the qemu mailing list: http://lists.nongnu.org/archive/html/qemu-devel/2008-08/txtXJHrYIW0Lp.txt * Windows install needs an ACPI KBD definition - otherwise you can't use the keyboard during the install. Again, I just copied it (along with MOU, RTC, FD0) from qemu. I've also disabled coreboot from running the vga rom. I do want coreboot to copy the rom into ram - but only so seabios can run it. I've also hacked coreboot so that it puts the pir, mptable, and acpi tables into high memory - this ensures that they wont get overwritten when the seabios payload is deployed. (Seabios will find the tables that need to be in 0xf0000 and relocate them.) -Kevin

1 0

Re: [coreboot] r3569 - trunk/util/flashrom
by Stefan Reinauer 07 Sep '08

07 Sep '08

svn(a)coreboot.org wrote: > Author: stuge > Date: 2008-09-07 05:14:27 +0200 (Sun, 07 Sep 2008) > New Revision: 3569 > > Modified: > trunk/util/flashrom/udelay.c > Log: > flashrom: Debug print actual time base calculated by myusec_calibrate_delay() > > Signed-off-by: Peter Stuge <peter(a)stuge.se> > Acked-by: Peter Stuge <peter(a)stuge.se> > > > Modified: trunk/util/flashrom/udelay.c > =================================================================== > --- trunk/util/flashrom/udelay.c 2008-09-05 21:23:02 UTC (rev 3568) > +++ trunk/util/flashrom/udelay.c 2008-09-07 03:14:27 UTC (rev 3569) > @@ -55,6 +55,12 @@ > // compute one microsecond. That will be count / time > micro = count / timeusec; > > - printf_debug("%ldM loops per second. ", (unsigned long)micro); > + gettimeofday(&start, 0); > + myusec_delay(100); > + gettimeofday(&end, 0); > + timeusec = 1000000 * (end.tv_sec - start.tv_sec) + > + (end.tv_usec - start.tv_usec); > + printf_debug("%ldM loops per second, 100 myus = %ld us. ", > + (unsigned long)micro, timeusec); > printf("OK.\n"); > } > I think that reads really weird. What's myus supposed to be, except an ancient greek city? Stefan -- 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

2 1

r861 - coreboot-v3/include
by svn＠coreboot.org 07 Sep '08

07 Sep '08

Author: uwe Date: 2008-09-07 19:18:10 +0200 (Sun, 07 Sep 2008) New Revision: 861 Modified: coreboot-v3/include/spd.h Log: Port some of the recent SPD DDR2 #defines from v2 to v3 (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: coreboot-v3/include/spd.h =================================================================== --- coreboot-v3/include/spd.h 2008-09-06 20:39:25 UTC (rev 860) +++ coreboot-v3/include/spd.h 2008-09-07 17:18:10 UTC (rev 861) @@ -75,6 +75,17 @@ #define SPD_CMD_SIGNAL_INPUT_HOLD_TIME 33 /* Command and address signal input hold time */ #define SPD_DATA_SIGNAL_INPUT_SETUP_TIME 34 /* Data signal input setup time */ #define SPD_DATA_SIGNAL_INPUT_HOLD_TIME 35 /* Data signal input hold time */ +#define SPD_WRITE_RECOVERY_TIME 36 /* Write recovery time (tWR) */ +#define SPD_INT_WRITE_TO_READ_DELAY 37 /* Internal write to read command delay (tWTR) */ +#define SPD_INT_READ_TO_PRECHARGE_DELAY 38 /* Internal read to precharge command delay (tRTP) */ +#define SPD_MEM_ANALYSIS_PROBE_PARAMS 39 /* Memory analysis probe characteristics */ +#define SPD_BYTE_41_42_EXTENSION 40 /* Extension of byte 41 (tRC) and byte 42 (tRFC) */ +#define SPD_MIN_ACT_TO_ACT_AUTO_REFRESH 41 /* Minimum active to active auto refresh (tRCmin) */ +#define SPD_MIN_AUTO_REFRESH_TO_ACT 42 /* Minimum auto refresh to active/auto refresh (tRFC) */ +#define SPD_MAX_DEVICE_CYCLE_TIME 43 /* Maximum device cycle time (tCKmax) */ +#define SPD_MAX_DQS_DQ_SKEW 44 /* Maximum skew between DQS and DQ (tDQSQ) */ +#define SPD_MAX_READ_DATAHOLD_SKEW 45 /* Maximum read data-hold skew factor (tQHS) */ +#define SPD_PLL_RELOCK_TIME 46 /* PLL relock time */ #define SPD_SPD_DATA_REVISION_CODE 62 /* SPD data revision code */ #define SPD_CHECKSUM_FOR_BYTES_0_TO_62 63 /* Checksum for bytes 0-62 */ #define SPD_MANUFACTURER_JEDEC_ID_CODE 64 /* Manufacturer's JEDEC ID code, per EIA/JEP106 (bytes 64-71) */ @@ -107,6 +118,7 @@ #define SPD_MEMORY_TYPE_SGRAM_DDR 6 #define SPD_MEMORY_TYPE_SDRAM_DDR 7 #define SPD_MEMORY_TYPE_SDRAM_DDR2 8 +#define SPD_MEMORY_TYPE_SDRAM_DDR3 0xb /* SPD_MODULE_VOLTAGE values. */ #define SPD_VOLTAGE_TTL 0 /* 5.0 Volt/TTL */ @@ -130,6 +142,11 @@ #define SPD_CAS_LATENCY_3_5 0x20 #define SPD_CAS_LATENCY_4_0 0x40 +#define SPD_CAS_LATENCY_DDR2_3 (1 << 3) +#define SPD_CAS_LATENCY_DDR2_4 (1 << 4) +#define SPD_CAS_LATENCY_DDR2_5 (1 << 5) +#define SPD_CAS_LATENCY_DDR2_6 (1 << 6) + /* SPD_SUPPORTED_BURST_LENGTHS values. */ #define SPD_BURST_LENGTH_1 1 #define SPD_BURST_LENGTH_2 2 @@ -145,4 +162,3 @@ u8 spd_read_byte(u16 device, u8 address); #endif /* _SPD_H_ */ -

1 0

r3569 build service
by coreboot information 07 Sep '08

07 Sep '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "stuge" checked in revision 3569 to the coreboot source repository and caused the following changes: Change Log: flashrom: Debug print actual time base calculated by myusec_calibrate_delay() Signed-off-by: Peter Stuge <peter(a)stuge.se> Acked-by: Peter Stuge <peter(a)stuge.se> Build Log: Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3569&device=epia-cn&vendor… If something broke during this checkin please be a pain in stuge's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

r3569 - trunk/util/flashrom
by svn＠coreboot.org 07 Sep '08

07 Sep '08

Author: stuge Date: 2008-09-07 05:14:27 +0200 (Sun, 07 Sep 2008) New Revision: 3569 Modified: trunk/util/flashrom/udelay.c Log: flashrom: Debug print actual time base calculated by myusec_calibrate_delay() Signed-off-by: Peter Stuge <peter(a)stuge.se> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/util/flashrom/udelay.c =================================================================== --- trunk/util/flashrom/udelay.c 2008-09-05 21:23:02 UTC (rev 3568) +++ trunk/util/flashrom/udelay.c 2008-09-07 03:14:27 UTC (rev 3569) @@ -55,6 +55,12 @@ // compute one microsecond. That will be count / time micro = count / timeusec; - printf_debug("%ldM loops per second. ", (unsigned long)micro); + gettimeofday(&start, 0); + myusec_delay(100); + gettimeofday(&end, 0); + timeusec = 1000000 * (end.tv_sec - start.tv_sec) + + (end.tv_usec - start.tv_usec); + printf_debug("%ldM loops per second, 100 myus = %ld us. ", + (unsigned long)micro, timeusec); printf("OK.\n"); }

1 0

← Newer
1
...
32
33
34
35
36
37
38
...
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