coreboot August 2010

coreboot@coreboot.org

67 participants
267 discussions

[commit] r5703 - trunk/src/southbridge/amd/rs780
by repository service 17 Aug '10

17 Aug '10

Author: zbao Date: Tue Aug 17 04:14:53 2010 New Revision: 5703 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5703 Log: Feature of lane reversal of AMD RS780 is tested. Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/southbridge/amd/rs780/rs780_gfx.c Modified: trunk/src/southbridge/amd/rs780/rs780_gfx.c ============================================================================== --- trunk/src/southbridge/amd/rs780/rs780_gfx.c Mon Aug 16 22:00:49 2010 (r5702) +++ trunk/src/southbridge/amd/rs780/rs780_gfx.c Tue Aug 17 04:14:53 2010 (r5703) @@ -1178,9 +1178,11 @@ /* Single-port/Dual-port configureation. */ switch (cfg->gfx_dual_slot) { case 0: - /* step 1, lane reversal (only need if CMOS option is enabled) */ + /* step 1, lane reversal (only need if build config option is enabled) */ if (cfg->gfx_lane_reversal) { + set_nbmisc_enable_bits(nb_dev, 0x36, 1 << 31, 1 << 31); set_nbmisc_enable_bits(nb_dev, 0x33, 1 << 2, 1 << 2); + set_nbmisc_enable_bits(nb_dev, 0x36, 1 << 31, 0 << 31); } printk(BIOS_DEBUG, "rs780_gfx_init step1.\n"); @@ -1194,10 +1196,12 @@ break; case 1: - /* step 1, lane reversal (only need if CMOS option is enabled) */ + /* step 1, lane reversal (only need if build config option is enabled) */ if (cfg->gfx_lane_reversal) { + set_nbmisc_enable_bits(nb_dev, 0x36, 1 << 31, 1 << 31); set_nbmisc_enable_bits(nb_dev, 0x33, 1 << 2, 1 << 2); set_nbmisc_enable_bits(nb_dev, 0x33, 1 << 3, 1 << 3); + set_nbmisc_enable_bits(nb_dev, 0x36, 1 << 31, 0 << 31); } printk(BIOS_DEBUG, "rs780_gfx_init step1.\n"); /* step 1.1, dual-slot gfx configuration (only need if CMOS option is enabled) */

2 1

[PATCH] Fix UMA memory range in RS780/RS785G
by Rudolf Marek 17 Aug '10

17 Aug '10

Hello, Attached patches fixes a video BIOS freeze with 128MB UMA. It looks like the internal address 0xc0000000 - 0xcfffffff was hardcoded. The change just takes the fb size to account resulting in - 0xc7ffffff for 128MB UMA. Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz> Yes it took some hours to find this out... Thanks, Rudolf

2 1

ASUS M4A77TD-PRO slow progress
by Xavi Drudis Ferran 17 Aug '10

17 Aug '10

Hello. Thanks to help from this list I could get my serial port to work with coreboot, and have been slowly progressing getting a little more log messages each time. I was keeping some questions to ask about what I'm doing that I pretended to send once I got coreboot to boot, in case I resolve them alone in the way, but It's getting longer than I thought and I thought I may ask now just in case I go too astray. Specially since skimming Qi's patch I don't see he needed all these changes for a similar board. I'm sending just the summary of the questions, I may send more details if you want or start different threads if that's best. Details on the mainboard in my previous message: http://www.coreboot.org/pipermail/coreboot/2010-June/058666.html 1.- In order to get sb700_lpc_init in sb700_early_setup.c to work I've got to modifiy pci_locate_device in order to refrain from scanning some functions in pci bus 0. For most of the adresses without a device, the system hanged when trying to get the pci id (I thought it should have returned FFF... but it stopped cold there, apparently). Serialice does no id scan, it simply uses hardcoded device addresses. And I don't know what's the purpose of scanning for devices for my mainboard that early, I guess it's because sb700_lpc_init it's used in other places where it makes sense, but then I wonder whether my change is acceptable for other mainboards, or I should somehow configure some exclusion parameter so that it can still scan all devices if needed for some other card. Or maybe better I should hardcode de device addresses in sb700_lpc_init and don't call pci_locate_device. Is there a policy about hard coded bus, dev,fn, or pci_locate_device ? 2.- I'm using a Phenom II x4 910e which is revision RB_C3. I've got to add it to some constants like AMD_FAM10_ALL and the like for ht init and some cpu errata. I've also added some new errata and modified some existing one. (I've modified CPU name assignment too, I hope it works). While looking at the latests revisions of AMD revision guide and BIOS and Kernel Developer Guide (BKDG), I realised there are more CPU models than the ones identified by the constants in amddefs.h. In fact I think a 32 bit flag value is used and there are more new CPU revisions to add than bits left unused (2). So I haven't added the new revisions from the current docs, like I did for processor names, since my RB_C3 already had a constant. But maybe something should be done to foresee the new revisions ? Has people already used RB_C3 processors with coreboot? Should soem bits that are used in the same cases be folded into one, or should the value be extended to 64 bits or something ? 3.- It currently stops at fidvid setting, after starting other cores (stage2, I think, it's hard to read the log when they all write at once). Sometimes it continues until decompressing CBFS and stops when entering ram stage, but I'm trying to concentrate in the earliest point of failure. By browsing fidvid.c and the BKDG it seems it is not up to date, in particular apparently has fixed values for rev B CPUs, and I can't find some of the procedures required by current BKDG. I suspect some use of configuration data before setting it up, after power up, to calculate ramp or slam values for voltage transitions, and apparently it won't work with all voltages (maybe some cases can't happen?). In fact I can't seem to understand how to code some of the missing(?) procedures (like setting vid and fid for dual power plane mainboards, which amd docs say it's mainboard-specific and I can't find either hooks to use in fibvid.c to make it dependend on the mainboard or hints on what do I have to tell the voltage regulators in ASUS M4a77td-pro to comply with AMD docs). So I wonder whether I'm looking to unused code, or whether not implementing the whole BKDG is on purpose, or I'm just not understanding what I read. So, in general, is all this normal, because I'm using hardware that hasn't been used before with coreboot, or I'm just lost in irrelevant details and everything should just work, so I should look elsewhere ? Thanks.

3 3

amd rs780 gfx lane reversal patch
by She, Kerry 16 Aug '10

16 Aug '10

Hi, all Amd rs780 feature Lane reversal is tested. Please see the attachment Thanks -- Regards Kerry She <Kerry.she(a)amd.com>

4 3

[commit] r5701 - trunk/util/sconfig
by repository service 16 Aug '10

16 Aug '10

Author: stepan Date: Mon Aug 16 20:21:56 2010 New Revision: 5701 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5701 Log: sconfig parser: - print erroneous string in error message - print line numbers starting from 1 instead of 0 - exit with return code 1 on errors - check return values of fopen operations - only create output file if input file was parsed without errors Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Modified: trunk/util/sconfig/main.c Modified: trunk/util/sconfig/main.c ============================================================================== --- trunk/util/sconfig/main.c Mon Aug 16 20:04:13 2010 (r5700) +++ trunk/util/sconfig/main.c Mon Aug 16 20:21:56 2010 (r5701) @@ -89,7 +89,9 @@ void yyerror (char const *str) { - fprintf (stderr, "line %d: %s\n", linenum, str); + extern char *yytext; + fprintf (stderr, "line %d: %s: %s\n", linenum + 1, yytext, str); + exit(1); } void postprocess_devtree(void) { @@ -408,12 +410,18 @@ sprintf(headers.next->name, "mainboard/%s", mainboard); FILE *filec = fopen(devtree, "r"); - yyrestart(filec); + if (!filec) { + fprintf(stderr, "Could not open file '%s' for reading: ", devtree); + perror(NULL); + exit(1); + } - FILE *staticc = fopen(outputc, "w"); + yyrestart(filec); lastdev = head = &root; + yyparse(); + fclose(filec); if ((head->type == chip) && (!head->chiph_exists)) { @@ -422,6 +430,13 @@ while (head->next != tmp) head = head->next; } + FILE *staticc = fopen(outputc, "w"); + if (!staticc) { + fprintf(stderr, "Could not open file '%s' for writing: ", outputc); + perror(NULL); + exit(1); + } + fprintf(staticc, "#include <device/device.h>\n"); fprintf(staticc, "#include <device/pci.h>\n"); struct header *h = &headers; @@ -435,5 +450,6 @@ walk_device_tree(staticc, &root, pass1, NULL); fclose(staticc); + return 0; }

1 0

[commit] r5700 - trunk/payloads/libpayload/libc
by repository service 16 Aug '10

16 Aug '10

Author: oxygene Date: Mon Aug 16 20:04:13 2010 New Revision: 5700 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5700 Log: Fix strcmp and strncmp. They failed in several important scenarios Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Modified: trunk/payloads/libpayload/libc/string.c Modified: trunk/payloads/libpayload/libc/string.c ============================================================================== --- trunk/payloads/libpayload/libc/string.c Mon Aug 16 19:51:47 2010 (r5699) +++ trunk/payloads/libpayload/libc/string.c Mon Aug 16 20:04:13 2010 (r5700) @@ -91,7 +91,7 @@ { int i; - for (i = 0; 1; i++) { + for (i = 0; s1[i] != '\0'; i++) { if (tolower(s1[i]) != tolower(s2[i])) return s1[i] - s2[i]; } @@ -116,7 +116,7 @@ return s1[i] - s2[i]; } - return 0; + return s1[i] - s2[i]; } /** @@ -132,12 +132,12 @@ { int i; - for (i = 0; 1; i++) { + for (i = 0; s1[i] != '\0'; i++) { if (s1[i] != s2[i]) return s1[i] - s2[i]; } - return 0; + return s1[i] - s2[i]; } /**

1 0

[commit] r5699 - trunk/payloads/libpayload/include/pci
by repository service 16 Aug '10

16 Aug '10

Author: oxygene Date: Mon Aug 16 19:51:47 2010 New Revision: 5699 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5699 Log: Add #define that states the libpci interface version we implement (flashrom needs it) Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Modified: trunk/payloads/libpayload/include/pci/pci.h Modified: trunk/payloads/libpayload/include/pci/pci.h ============================================================================== --- trunk/payloads/libpayload/include/pci/pci.h Mon Aug 16 18:25:23 2010 (r5698) +++ trunk/payloads/libpayload/include/pci/pci.h Mon Aug 16 19:51:47 2010 (r5699) @@ -30,6 +30,9 @@ #ifndef _PCI_PCI_H #define _PCI_PCI_H +/* we implement at least this version */ +#define PCI_LIB_VERSION 0x020200 + #include <pci.h> #define PCI_CLASS_DEVICE REG_CLASS_DEV

1 0

[commit] r5698 - trunk/src/devices
by repository service 16 Aug '10

16 Aug '10

Author: myles Date: Mon Aug 16 18:25:23 2010 New Revision: 5698 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5698 Log: Call mainboard init functions. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Acked-by: Peter Stuge <peter(a)stuge.se> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/src/devices/device.c Modified: trunk/src/devices/device.c ============================================================================== --- trunk/src/devices/device.c Sun Aug 15 13:37:41 2010 (r5697) +++ trunk/src/devices/device.c Mon Aug 16 18:25:23 2010 (r5698) @@ -1104,6 +1104,9 @@ printk(BIOS_INFO, "Initializing devices...\n"); + /* First call the mainboard init. */ + init_dev(&dev_root); + /* now initialize everything. */ for (link = dev_root.link_list; link; link = link->next) init_link(link);

1 0

Trac reminder: list of new ticket(s)
by coreboot tracker 16 Aug '10

16 Aug '10

1 0

global variables in romstage
by Patrick Georgi 15 Aug '10

15 Aug '10

Hi, I was told about an issue with our romstage handling, as the linker happily links in global variables (with addresses in ROM). That obviously doesn't work for writable values, but is a silent error (until things _really_ go wrong on runtime), so I looked for a way to break coreboot at build time in such a scenario. Two possible solutions, both need to be added to src/arch/i386/init/ldscript_fallback_cbfs.lb: 1. _bogus = ASSERT((SIZEOF(.bss) + SIZEOF(.data)) == 0, "Do not use global variables in romstage"); This one looks for the size of .bss and .data (initialized and uninitialized globals) and breaks the build if it finds any. It doesn't tell, which global variables are involved. 2. Add .bss and .data to /DISCARD/. That way, the linker complains about "missing" symbols (as they were discarded), but only if they were used by any surviving code. This means, it's no problem that the global is defined. If you use it later-on, it "mysteriously" breaks. The error message is rather cryptic, too: `variable' referenced in section `.rom.text' of coreboot-builds/kontron_986lcd-m/mainboard/kontron/986lcd-m/crt0.initobj.o: defined in discarded section `.data' of coreboot-builds/kontron_986lcd-m/mainboard/kontron/986lcd-m/crt0.initobj.o collect2: ld returned 1 exit status I tend to prefer the first option, but it doesn't give _any_ clues which variable is responsible (except for "look for globals"), but at least it does tell the user what the real problem is. Opinions? There might also be a good opportunity for some naming cleanup: Rename and move ldscript_fallback_cbfs.lb to src/arch/i386/coreboot_rom.ld. Or better call it "romstage.ld" (and adapt coreboot_ram.ld in arch/i386 in the same way)? Regards, Patrick

6 10

← Newer
1
...
16
17
18
19
20
21
22
...
27
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 2010