From peter at stuge.se Wed Sep 1 00:39:18 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 1 Sep 2010 00:39:18 +0200 Subject: [coreboot] [PATCH] use Kconfig for both options on Lippert boards In-Reply-To: <4C7D44E1.8060403@LiPPERTEmbedded.de> References: <4C7CF5FF.1020307@LiPPERTEmbedded.de> <4C7D44E1.8060403@LiPPERTEmbedded.de> Message-ID: <20100831223918.28439.qmail@stuge.se> Jens Rottmann wrote: > > Maybe make that one option per port instead, > > I had considered this but decided against it. Oh well. > It is simply not feasible to make _everything_ configurable, I'm not sure I agree about feasible. I agree it's not worthwhile though. You know your customers best, but from my experience with embedded customers, more configurability is better. :) > one has to draw a line somewhere. Yes of course. > Like disabling devices completely to save power, I/O resources and IRQs. > Or moving PCI INT A-D or legacy devices to a different IRQ line. I guess you already know that PCI interrupts are locked to whatever the VSA blob configures for the virtualized devices. I do agree about disabling and I/O and interrupts as far as possible.. > making sure that a certain bit pattern is written as early as > possible to the LPT data port This is a good point. It could make sense to have hooks already in the bootblock. > you'd have to start with devicetree.cb, I know. This is one part of coreboot "infrastructure" that I think needs some improvement. A first step would be interrupt routing. It might also be nice to make it a little easier to use devicetree.cb from the coreboot code. > > Maybe also make an (expert?) option to disable the LED? > > The '1' I write to it makes sure it's initally off. That makes sense. Thanks for clarifying. //Peter From peter at stuge.se Wed Sep 1 01:02:42 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 1 Sep 2010 01:02:42 +0200 Subject: [coreboot] alix 2d2 In-Reply-To: <4C7D4F8C.7030105@LiPPERTEmbedded.de> References: <4C7D2DE9.5040906@LiPPERTEmbedded.de> <4C7D32C0.8050409@LiPPERTEmbedded.de> <4C7D4F8C.7030105@LiPPERTEmbedded.de> Message-ID: <20100831230242.31419.qmail@stuge.se> Jens Rottmann wrote: > What do you think about this (attached)? (Renaming of the alix2d3/ > directory to alix2d/ is not included in the patch, please do this > manually before applying.) Maybe even ALIX.2 and alix2 if it turns out .2Cx works too, which wouldn't surprise me. //Peter From mylesgw at gmail.com Wed Sep 1 01:34:09 2010 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 31 Aug 2010 17:34:09 -0600 Subject: [coreboot] Real mode ebx corruption Message-ID: Has anyone seen corruption of ebx when using real mode for option ROMs? I'm running the same ROM with SeaBIOS and real mode, and a series of writes (ax = 1ab1 bx = b10d) works fine with SeaBIOS, but several of the bx values are corrupted to b100 with real mode. The only hint I can find is: // Put registers back on the stack. The assembler code // will later pop them. // What happens here is that we force (volatile!) changing // the values of the parameters of this function. We do this // because we know that they stay alive on the stack after // we leave this function. Don't say this is bollocks. *(volatile u32 *)&eax = reg_info.eax; *(volatile u32 *)&ecx = reg_info.ecx; *(volatile u32 *)&edx = reg_info.edx; *(volatile u32 *)&ebx = reg_info.ebx; Since it's real mode, it seems like the only place for corruption is the call & return. Am I missing something? Thanks, Myles From illdred at gmail.com Wed Sep 1 01:24:37 2010 From: illdred at gmail.com (illdred) Date: Tue, 31 Aug 2010 16:24:37 -0700 Subject: [coreboot] via pc3500g Message-ID: <20100831162437.15f9ee96@dirigible.network87.inet> Good day, I would like to use coreboot on my machine. I have a VIA PC3500G motherboard. VIA C7 cpu, VIA CN896 northbirdge, VIA 8237A southbridge Will it work? looks to me like the only unsupported piece is the northbridge. lspci -tvnn -+-[0000:80]---01.0 VIA Technologies, Inc. VT1708/A [Azalia HDAC] (VIA High Definition Audio Controller) [1106:3288] \-[0000:00]-+-00.0 VIA Technologies, Inc. CN896/VN896/P4M900 Host Bridge [1106:0364] +-00.1 VIA Technologies, Inc. CN896/VN896/P4M900 Host Bridge [1106:1364] +-00.2 VIA Technologies, Inc. CN896/VN896/P4M900 Host Bridge [1106:2364] +-00.3 VIA Technologies, Inc. CN896/VN896/P4M900 Host Bridge [1106:3364] +-00.4 VIA Technologies, Inc. CN896/VN896/P4M900 Host Bridge [1106:4364] +-00.5 VIA Technologies, Inc. CN896/VN896/P4M900 I/O APIC Interrupt Controller [1106:5364] +-00.6 VIA Technologies, Inc. CN896/VN896/P4M900 Security Device [1106:6364] +-00.7 VIA Technologies, Inc. CN896/VN896/P4M900 Host Bridge [1106:7364] +-01.0-[01]-- +-02.0-[02]--+-00.0 ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO] [1002:94c3] | \-00.1 ATI Technologies Inc RV610 audio device [Radeon HD 2400 PRO] [1002:aa10] +-03.0-[03]-- +-0f.0 VIA Technologies, Inc. Device [1106:5337] +-0f.1 VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] +-10.0 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] +-10.1 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] +-10.2 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] +-10.3 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] +-10.4 VIA Technologies, Inc. USB 2.0 [1106:3104] +-11.0 VIA Technologies, Inc. VT8237A PCI to ISA Bridge [1106:3337] +-11.7 VIA Technologies, Inc. VT8251 Ultra VLINK Controller [1106:287e] +-13.0 VIA Technologies, Inc. VT8237A Host Bridge [1106:337b] \-13.1-[04-05]--+-04.0-[05]--+-00.0 ATI Technologies Inc RV 610LE PCI [Radeon HD 2400] [1002:94cc] | \-00.1 ATI Technologies Inc RV610 audio device [Radeon HD 2400 PRO] [1002:aa10] \-0e.0 VIA Technologies, Inc. VT6102 [Rhine-II] [1106:3065] superiotool -dV superiotool r5728 Probing for ... Probing for ITE Super I/O (init=standard) at 0x2e... Found ITE IT8716F (id=0x8716, rev=0x1) at 0x2e Register dump: idx 20 21 22 23 24 2b val 87 16 01 10 1e 00 def 87 16 01 00 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 val 00 00 00 00 04 00 80 def 00 03 f0 06 02 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 00 50 00 7f def 00 03 f8 04 00 50 00 7f LDN 0x02 (COM2) idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 00 50 00 7f def 00 02 f8 03 00 50 00 7f LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 00 00 00 00 00 04 08 def 00 03 78 07 78 07 03 03 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 02 90 00 00 00 00 00 0a 00 80 00 ff def 00 02 90 02 30 09 00 00 00 00 00 NA NA LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 00 00 60 00 64 00 02 48 def 01 00 60 00 64 01 02 00 LDN 0x06 (Mouse) idx 30 70 71 f0 val 00 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 01 00 00 00 00 81 1f 00 00 08 00 08 20 00 01 00 38 00 00 00 00 00 00 00 60 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 03 00 00 3f 00 def 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA 00 LDN 0x08 (MIDI port) idx 30 60 61 70 f0 val 00 03 00 0a 00 def 00 03 00 0a 00 LDN 0x09 (Game port) idx 30 60 61 val 00 02 01 def 00 02 01 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 flashrom -V flashrom v0.9.2-r1001 on Linux 2.6.33-dirigible33 (i686), built with libpci 3.1.7, GCC 4.5.0 20100520 (prerelease) flashrom is free software, get the source code at http://www.flashrom.org Initializing internal programmer No coreboot table found. DMI string system-manufacturer: " " DMI string system-product-name: " " DMI string system-version: " " DMI string baseboard-manufacturer: "PC1" DMI string baseboard-product-name: "PC3500G" DMI string baseboard-version: "3.x" DMI string chassis-type: "Desktop" Found ITE Super I/O, id 8716 Found chipset "VIA VT8237A", enabling flash write... OK. This chipset supports the following protocols: Non-SPI. Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff enabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled Serial flash pin 29 Serial flash port 0x0820 Calibrating delay loop... 387M loops per second, delay more than 10% too short, recalculating... 381M loops per second, delay more than 10% too short, recalculating... 434M loops per second, delay more than 10% too short, recalculating... 436M loops per second, delay more than 10% too short, recalculating... 436M loops per second, delay loop is unreliable, trying to continue 10 myus = 10 us, 100 myus = 89 us, 1000 myus = 873 us, 10000 myus = 31905 us, OK. Probing for Macronix MX25L4005, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2013 Chip status register is 00 Chip status register: Status Register Write Disable (SRWD) is not set Chip status register: Bit 6 is not set Chip status register: Bit 5 / Block Protect 3 (BP3) is not set Chip status register: Bit 4 / Block Protect 2 (BP2) is not set Chip status register: Bit 3 / Block Protect 1 (BP1) is not set Chip status register: Bit 2 / Block Protect 0 (BP0) is not set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set Found chip "Macronix MX25L4005" (512 KB, SPI) at physical address 0xfff80000. === This flash part has status UNTESTED for operations: ERASE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom at flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -Vw, -VE), and mention which mainboard or programmer you tested. Thanks for your help! === From peter at stuge.se Wed Sep 1 02:51:10 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 1 Sep 2010 02:51:10 +0200 Subject: [coreboot] via pc3500g In-Reply-To: <20100831162437.15f9ee96@dirigible.network87.inet> References: <20100831162437.15f9ee96@dirigible.network87.inet> Message-ID: <20100901005110.13924.qmail@stuge.se> illdred wrote: > I would like to use coreboot on my machine. .. > VIA C7 cpu, VIA CN896 northbirdge, VIA 8237A southbridge .. > Will it work? No, not without development work. > looks to me like the only unsupported piece is the northbridge. That's not so "only" - adding support for a northbridge is a significant effort. That said, 896 is similar to other 8xx chipsets which are already supported. Would you be interested in working on the project of supporting also 896? //Peter From wt at penguintechs.org Wed Sep 1 03:13:52 2010 From: wt at penguintechs.org (Warren Turkal) Date: Tue, 31 Aug 2010 18:13:52 -0700 Subject: [coreboot] [PATCH] added ich10r gpio support to intel tool In-Reply-To: <1283221612.3127.3.camel@dualcore.traverse> References: <1283163410.3795.11.camel@mattotaupa> <1283221612.3127.3.camel@dualcore.traverse> Message-ID: Thanks, wt On Mon, Aug 30, 2010 at 7:26 PM, Nathan Williams wrote: > On Mon, 2010-08-30 at 18:52 -0700, Warren Turkal wrote: >> BTW, is there a git tree that is maintained and up to date? I'd rather >> not use git svn if I could avoid it. >> >> Thanks, >> wt > > Hi Warren, > > I have a hourly cron job keeping this git tree updated: > > git://github.com/ngwill/coreboot.git > > Regards, > Nathan > > From wt at penguintechs.org Wed Sep 1 03:15:33 2010 From: wt at penguintechs.org (Warren Turkal) Date: Tue, 31 Aug 2010 18:15:33 -0700 Subject: [coreboot] [PATCH] added ich10r gpio support to intel tool In-Reply-To: References: <1283163410.3795.11.camel@mattotaupa> <1283221612.3127.3.camel@dualcore.traverse> Message-ID: BTW, any reason not to add this info the wiki somewhere? Thanks, wt On Tue, Aug 31, 2010 at 6:13 PM, Warren Turkal wrote: > Thanks, > wt > > On Mon, Aug 30, 2010 at 7:26 PM, Nathan Williams wrote: >> On Mon, 2010-08-30 at 18:52 -0700, Warren Turkal wrote: >>> BTW, is there a git tree that is maintained and up to date? I'd rather >>> not use git svn if I could avoid it. >>> >>> Thanks, >>> wt >> >> Hi Warren, >> >> I have a hourly cron job keeping this git tree updated: >> >> git://github.com/ngwill/coreboot.git >> >> Regards, >> Nathan >> >> > From illdred at gmail.com Wed Sep 1 04:25:14 2010 From: illdred at gmail.com (illdred) Date: Tue, 31 Aug 2010 19:25:14 -0700 Subject: [coreboot] via pc3500g In-Reply-To: <20100901005110.13924.qmail@stuge.se> References: <20100831162437.15f9ee96@dirigible.network87.inet> <20100901005110.13924.qmail@stuge.se> Message-ID: <20100831192514.7c2c9694@dirigible.network87.inet> On Wed, 1 Sep 2010 02:51:10 +0200 Peter Stuge wrote: > illdred wrote: > > I would like to use coreboot on my machine. > .. > > VIA C7 cpu, VIA CN896 northbirdge, VIA 8237A southbridge > .. > > Will it work? > > No, not without development work. > > > > looks to me like the only unsupported piece is the northbridge. > > That's not so "only" - adding support for a northbridge is a > significant effort. > > That said, 896 is similar to other 8xx chipsets which are already > supported. Would you be interested in working on the project of > supporting also 896? > > > //Peter > Yes, I would be interested. let me know what I can do to assist. I'll join up on the #coreboot irc thanks for writing back to me Fraser From corey.osgood at gmail.com Wed Sep 1 05:31:42 2010 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 31 Aug 2010 23:31:42 -0400 Subject: [coreboot] via pc3500g In-Reply-To: <20100831192514.7c2c9694@dirigible.network87.inet> References: <20100831162437.15f9ee96@dirigible.network87.inet> <20100901005110.13924.qmail@stuge.se> <20100831192514.7c2c9694@dirigible.network87.inet> Message-ID: On Tue, Aug 31, 2010 at 10:25 PM, illdred wrote: > On Wed, 1 Sep 2010 02:51:10 +0200 > Peter Stuge wrote: > >> illdred wrote: >> > I would like to use coreboot on my machine. >> .. >> > VIA C7 cpu, VIA CN896 northbirdge, VIA 8237A southbridge >> .. >> > Will it work? >> >> No, not without development work. >> >> >> > looks to me like the only unsupported piece is the northbridge. >> >> That's not so "only" - adding support for a northbridge is a >> significant effort. >> >> That said, 896 is similar to other 8xx chipsets which are already >> supported. Would you be interested in working on the project of >> supporting also 896? >> >> >> //Peter >> > > Yes, I would be interested. let me know what I can do to assist. > > I'll join up on the #coreboot irc > > thanks for writing back to me > Since there's no public datasheet for the CN896, about the only possibility is to look at the VX800 port, compare what it does to lspci -xxx from your CN896 system, and see how well they match up. If they're similar enough, you may be able to rip the northbridge/memory init code out of the vx800 and use it to boot up the cn896...but it's a long shot. You may also be able to use SerialICE to see what the factory BIOS does and copy it, but what's the point of using coreboot if you're just using it to do the same thing the factory bios does? -Corey From svn at coreboot.org Wed Sep 1 05:40:57 2010 From: svn at coreboot.org (repository service) Date: Wed, 01 Sep 2010 05:40:57 +0200 Subject: [coreboot] [commit] r5761 - trunk/util/inteltool Message-ID: Author: cozzie Date: Wed Sep 1 05:40:57 2010 New Revision: 5761 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5761 Log: Add support for dumping GPIOS on Intel ICH10R. This information comes from the Intel ICH10 Family Datasheet. Signed-off-by: Warren Turkal Acked-by: Corey Osgood Modified: trunk/util/inteltool/gpio.c Modified: trunk/util/inteltool/gpio.c ============================================================================== --- trunk/util/inteltool/gpio.c Tue Aug 31 21:19:16 2010 (r5760) +++ trunk/util/inteltool/gpio.c Wed Sep 1 05:40:57 2010 (r5761) @@ -152,6 +152,41 @@ { 0x3C, 4, "RESERVED" } }; +static const io_register_t ich10_gpio_registers[] = { + { 0x00, 4, "GPIO_USE_SEL" }, + { 0x04, 4, "GP_IO_SEL" }, + { 0x08, 4, "RESERVED" }, + { 0x0c, 4, "GP_LVL" }, + { 0x10, 4, "RESERVED" }, + { 0x14, 4, "RESERVED" }, + { 0x18, 4, "GPO_BLINK" }, + { 0x1c, 4, "GP_SER_BLINK" }, + { 0x20, 4, "GP_SB_CMDSTS" }, + { 0x24, 4, "GP_SB_DATA" }, + { 0x28, 4, "RESERVED" }, + { 0x2c, 4, "GPI_INV" }, + { 0x30, 4, "GPIO_USE_SEL2" }, + { 0x34, 4, "GP_IO_SEL2" }, + { 0x38, 4, "GP_LVL2" }, + { 0x3C, 4, "RESERVED" }, + { 0x40, 4, "GPIO_USE_SEL3" }, + { 0x44, 4, "GPIO_SEL3" }, + { 0x48, 4, "GPIO_LVL3" }, + { 0x4c, 4, "RESERVED" }, + { 0x50, 4, "RESERVED" }, + { 0x54, 4, "RESERVED" }, + { 0x58, 4, "RESERVED" }, + { 0x5c, 4, "RESERVED" }, + { 0x60, 4, "GP_RST_SEL" }, + { 0x64, 4, "RESERVED" }, + { 0x68, 4, "RESERVED" }, + { 0x6c, 4, "RESERVED" }, + { 0x70, 4, "RESERVED" }, + { 0x74, 4, "RESERVED" }, + { 0x78, 4, "RESERVED" }, + { 0x7c, 4, "RESERVED" }, +}; + int print_gpios(struct pci_dev *sb) { int i, size; @@ -161,6 +196,11 @@ printf("\n============= GPIOS =============\n\n"); switch (sb->device_id) { + case PCI_DEVICE_ID_INTEL_ICH10R: + gpiobase = pci_read_word(sb, 0x48) & 0xfffc; + gpio_registers = ich10_gpio_registers; + size = ARRAY_SIZE(ich10_gpio_registers); + break; case PCI_DEVICE_ID_INTEL_ICH9DH: case PCI_DEVICE_ID_INTEL_ICH9DO: case PCI_DEVICE_ID_INTEL_ICH9R: From corey.osgood at gmail.com Wed Sep 1 05:42:00 2010 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 31 Aug 2010 23:42:00 -0400 Subject: [coreboot] [PATCH] added ich10r gpio support to intel tool In-Reply-To: References: <1283163410.3795.11.camel@mattotaupa> Message-ID: On Mon, Aug 30, 2010 at 9:52 PM, Warren Turkal wrote: > I clearly included the patch without my sign off. Here's another > exported from my git tree. Acked-by: Corey Osgood And committed in r5761. Is RCBA/ACPI support in the works? -Corey From svn at coreboot.org Wed Sep 1 05:53:54 2010 From: svn at coreboot.org (repository service) Date: Wed, 01 Sep 2010 05:53:54 +0200 Subject: [coreboot] build service results for r5761 Message-ID: Dear coreboot readers! This is the automatic build system of coreboot. The developer "cozzie" checked in revision 5761 to the coreboot repository. This caused the following changes: Change Log: Add support for dumping GPIOS on Intel ICH10R. This information comes from the Intel ICH10 Family Datasheet. Signed-off-by: Warren Turkal Acked-by: Corey Osgood Build Log: Compilation of a-trend:atc-6220 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5761&device=atc-6220&vendor=a-trend&num=2 If something broke during this checkin please be a pain in cozzie'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 From scott at notabs.org Wed Sep 1 07:16:23 2010 From: scott at notabs.org (Scott) Date: Wed, 1 Sep 2010 00:16:23 -0500 Subject: [coreboot] timeout during PS/2 keyboard init Message-ID: Hello, While testing on AMD simnow I encounter a timeout in keyboard.c line 246: /* All is well - enable keyboard interface */ if (!kbc_input_buffer_empty()) return; outb(0x60, KBD_COMMAND); if (!kbc_input_buffer_empty()) return; outb(0x61, KBD_DATA); /* send cmd: enable keyboard and IRQ 1 */ if (kbc_output_buffer_full()) { printk(BIOS_ERR, "Timeout during final keyboard enable\n"); <======= return; } It seems like line 245 should call kbc_input_buffer_empty() instead of kbc_output_buffer_full() because the previous I/O does not cause the keyboard to generate any data. On simnow, this causes a boot delay of a minute or so. On real hardware, It appears it could cause a boot delay of 400 ms. Does anyone testing with real hardware ever notice the "Timeout during final keyboard enable" message when logging is enabled? Thanks, Scott From wt at penguintechs.org Wed Sep 1 11:18:10 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 02:18:10 -0700 Subject: [coreboot] [PATCH] added ich10r gpio support to intel tool In-Reply-To: References: <1283163410.3795.11.camel@mattotaupa> Message-ID: On Tue, Aug 31, 2010 at 8:42 PM, Corey Osgood wrote: > Is RCBA/ACPI support in the works? I'm about to send the RCBA support. Thanks, wt From wt at penguintechs.org Wed Sep 1 11:22:18 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 02:22:18 -0700 Subject: [coreboot] [PATCH] Add support for dumping RCBA registers for i7. In-Reply-To: <1283332401-10749-1-git-send-email-wt@penguintechs.org> References: <1283332401-10749-1-git-send-email-wt@penguintechs.org> Message-ID: BTW, I also took the opportunity to put the list if lexicographical order. wt On Wed, Sep 1, 2010 at 2:13 AM, Warren Turkal wrote: > Signed-off-by: Warren Turkal > --- > ?util/inteltool/rootcmplx.c | ? ?5 +++-- > ?1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/util/inteltool/rootcmplx.c b/util/inteltool/rootcmplx.c > index 215c150..cb5d2a3 100644 > --- a/util/inteltool/rootcmplx.c > +++ b/util/inteltool/rootcmplx.c > @@ -36,14 +36,15 @@ int print_rcba(struct pci_dev *sb) > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH7M: > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH7DH: > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH7MDH: > + ? ? ? case PCI_DEVICE_ID_INTEL_ICH8: > + ? ? ? case PCI_DEVICE_ID_INTEL_ICH8M: > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH9DH: > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH9DO: > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH9R: > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH9: > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH9M: > ? ? ? ?case PCI_DEVICE_ID_INTEL_ICH9ME: > - ? ? ? case PCI_DEVICE_ID_INTEL_ICH8M: > - ? ? ? case PCI_DEVICE_ID_INTEL_ICH8: > + ? ? ? case PCI_DEVICE_ID_INTEL_ICH10R: > ? ? ? ?case PCI_DEVICE_ID_INTEL_NM10: > ? ? ? ? ? ? ? ?rcba_phys = pci_read_long(sb, 0xf0) & 0xfffffffe; > ? ? ? ? ? ? ? ?break; > -- > 1.7.1 > > From JRottmann at LiPPERTEmbedded.de Wed Sep 1 11:31:49 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Wed, 01 Sep 2010 11:31:49 +0200 Subject: [coreboot] [PATCH] use Kconfig for both options on Lippert boards In-Reply-To: <4C7D44E1.8060403@LiPPERTEmbedded.de> References: <4C7CF5FF.1020307@LiPPERTEmbedded.de> <4C7D44E1.8060403@LiPPERTEmbedded.de> Message-ID: <4C7E1D85.4060400@LiPPERTEmbedded.de> Good morning Peter, > > It is simply not feasible to make _everything_ configurable, > I'm not sure I agree about feasible. I mean that no matter how hard you try, there will _always_ be one application left which needs something changed that no one had foreseen. But that's exactly the strong point of an open source BIOS. The source adds the last, ultimate layer of configurability. > from my experience with embedded customers, more configurability > is better. :) Absolutely!! > > Or moving PCI INT A-D or legacy devices to a different IRQ line. > I guess you already know that PCI interrupts are locked to whatever > the VSA blob configures for the virtualized devices. I meant the mapping INT A --> IRQ 10 etc. I already had a patch for this (attached) but also decided against it, because this should be generic and _not_ done individually at the board level and the device tree is a better place for it anyway. > > you'd have to start with devicetree.cb, > A first step would be interrupt routing. I agree 100%! Regards, Jens -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: IRQs.diff URL: From wt at penguintechs.org Wed Sep 1 11:53:24 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 02:53:24 -0700 Subject: [coreboot] [PATCH 0/2] Improve inteltool. Message-ID: <1283334806-11501-1-git-send-email-wt@penguintechs.org> Here's a small set of patches for improving inteltool. Warren Turkal (2): Add support for dumping RCBA registers for i7. Add support for dumping ACPI registers for i7. util/inteltool/powermgt.c | 65 ++++++++++++++++++++++++++++++++++++++++++++ util/inteltool/rootcmplx.c | 5 ++- 2 files changed, 68 insertions(+), 2 deletions(-) From wt at penguintechs.org Wed Sep 1 11:53:26 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 02:53:26 -0700 Subject: [coreboot] [PATCH 2/2] Add support for dumping ACPI registers for i7. In-Reply-To: <1283334806-11501-1-git-send-email-wt@penguintechs.org> References: <1283334806-11501-1-git-send-email-wt@penguintechs.org> Message-ID: <1283334806-11501-3-git-send-email-wt@penguintechs.org> Signed-off-by: Warren Turkal --- util/inteltool/powermgt.c | 65 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-) diff --git a/util/inteltool/powermgt.c b/util/inteltool/powermgt.c index 5f93835..3032f4d 100644 --- a/util/inteltool/powermgt.c +++ b/util/inteltool/powermgt.c @@ -21,6 +21,66 @@ #include #include "inteltool.h" +static const io_register_t ich10_pm_registers[] = { + { 0x00, 2, "PM1_STS" }, // PM1 Status; ACPI pointer: PM1a_EVT_BLK + { 0x02, 2, "PM1_EN" }, // PM1 Enables; ACPI pointer: PM1a_EVT_BLK+2 + { 0x04, 4, "PM1_CNT" }, // PM1 Control; ACPI pointer: PM1a_CNT_BLK + { 0x08, 4, "PM1_TMR" }, // PM1 Timer; ACPI pointer: PMTMR_BLK + { 0x0c, 4, "RESERVED" }, + { 0x10, 4, "PROC_CNT" }, // Processor Control; ACPI pointer: P_BLK +#if DANGEROUS_REGISTERS + /* These registers return 0 on read, but reading them may cause + * the system to enter Cx states, which might hang the system. + */ + { 0x14, 1, "LV2 (Mobile)" }, + { 0x15, 1, "LV3 (Mobile)" }, + { 0x16, 1, "LV4 (Mobile)" }, +#endif + { 0x17, 2, "RESERVED" }, + { 0x19, 1, "RESERVED" }, + { 0x1a, 2, "RESERVED" }, + { 0x1c, 4, "RESERVED" }, + { 0x20, 8, "GPE0_STS" }, // General Purpose Event 0 Status; ACPI pointer: GPE0_BLK + { 0x2C, 4, "GPE0_EN" }, // General Purpose Event 0 Enables; ACPI pointer: GPE0_BLK+8 + { 0x30, 4, "SMI_EN" }, + { 0x34, 4, "SMI_STS" }, + { 0x38, 2, "ALT_GP_SMI_EN" }, + { 0x3a, 2, "ALT_GP_SMI_STS" }, + { 0x3c, 1, "UPRWC" }, // USB Per-Port registers write control; + { 0x3d, 2, "RESERVED" }, + { 0x3f, 1, "RESERVED" }, + { 0x40, 2, "RESERVED" }, + { 0x42, 1, "GPE_CNTL" }, + { 0x43, 1, "RESERVED" }, + { 0x44, 2, "DEVACT_STS" }, // Device Activity Status + { 0x46, 2, "RESERVED" }, + { 0x48, 4, "RESERVED" }, + { 0x4c, 4, "RESERVED" }, + { 0x50, 1, "PM2_CNT (Mobile)" }, // PM2 Control (Mobile only); ACPI pointer: PM2a_CNT_BLK + { 0x51, 1, "RESERVED" }, + { 0x52, 2, "RESERVED" }, + { 0x54, 4, "C3_RES (Mobile)" }, + { 0x58, 4, "RESERVED" }, + { 0x5c, 4, "RESERVED" }, + /* Here start the TCO registers */ + { 0x60, 2, "TCO_RLD" }, + { 0x62, 1, "TCO_DAT_IN" }, + { 0x63, 1, "TCO_DAT_OUT" }, + { 0x64, 2, "TCO1_STS" }, + { 0x66, 2, "TCO2_STS" }, + { 0x68, 2, "TCO1_CNT" }, + { 0x6a, 2, "TCO2_CNT" }, + { 0x6c, 2, "TCO_MESSAGE" }, + { 0x6e, 1, "TCO_WDCNT" }, + { 0x6f, 1, "RESERVED" }, + { 0x70, 1, "SW_IRQ_GEN" }, + { 0x71, 1, "RESERVED" }, + { 0x72, 2, "TCO_TMR" }, + { 0x74, 4, "RESERVED" }, + { 0x78, 4, "RESERVED" }, + { 0x7c, 4, "RESERVED" }, +}; + static const io_register_t ich9_pm_registers[] = { { 0x00, 2, "PM1_STS" }, // PM1 Status; ACPI pointer: PM1a_EVT_BLK { 0x02, 2, "PM1_EN" }, // PM1 Enables; ACPI pointer: PM1a_EVT_BLK+2 @@ -473,6 +533,11 @@ int print_pmbase(struct pci_dev *sb) printf("\n============= PMBASE ============\n\n"); switch (sb->device_id) { + case PCI_DEVICE_ID_INTEL_ICH10R: + pmbase = pci_read_word(sb, 0x40) & 0xff80; + pm_registers = ich10_pm_registers; + size = ARRAY_SIZE(ich10_pm_registers); + break; case PCI_DEVICE_ID_INTEL_ICH7: case PCI_DEVICE_ID_INTEL_ICH7M: case PCI_DEVICE_ID_INTEL_ICH7DH: -- 1.7.1 From wt at penguintechs.org Wed Sep 1 11:53:25 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 02:53:25 -0700 Subject: [coreboot] [PATCH 1/2] Add support for dumping RCBA registers for i7. In-Reply-To: <1283334806-11501-1-git-send-email-wt@penguintechs.org> References: <1283334806-11501-1-git-send-email-wt@penguintechs.org> Message-ID: <1283334806-11501-2-git-send-email-wt@penguintechs.org> Signed-off-by: Warren Turkal --- util/inteltool/rootcmplx.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/util/inteltool/rootcmplx.c b/util/inteltool/rootcmplx.c index 215c150..cb5d2a3 100644 --- a/util/inteltool/rootcmplx.c +++ b/util/inteltool/rootcmplx.c @@ -36,14 +36,15 @@ int print_rcba(struct pci_dev *sb) case PCI_DEVICE_ID_INTEL_ICH7M: case PCI_DEVICE_ID_INTEL_ICH7DH: case PCI_DEVICE_ID_INTEL_ICH7MDH: + case PCI_DEVICE_ID_INTEL_ICH8: + case PCI_DEVICE_ID_INTEL_ICH8M: case PCI_DEVICE_ID_INTEL_ICH9DH: case PCI_DEVICE_ID_INTEL_ICH9DO: case PCI_DEVICE_ID_INTEL_ICH9R: case PCI_DEVICE_ID_INTEL_ICH9: case PCI_DEVICE_ID_INTEL_ICH9M: case PCI_DEVICE_ID_INTEL_ICH9ME: - case PCI_DEVICE_ID_INTEL_ICH8M: - case PCI_DEVICE_ID_INTEL_ICH8: + case PCI_DEVICE_ID_INTEL_ICH10R: case PCI_DEVICE_ID_INTEL_NM10: rcba_phys = pci_read_long(sb, 0xf0) & 0xfffffffe; break; -- 1.7.1 From patrick at georgi-clan.de Wed Sep 1 13:22:21 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 01 Sep 2010 13:22:21 +0200 Subject: [coreboot] [PATCH] use Kconfig for both options on Lippert boards In-Reply-To: <4C7E1D85.4060400@LiPPERTEmbedded.de> References: <4C7CF5FF.1020307@LiPPERTEmbedded.de> <4C7D44E1.8060403@LiPPERTEmbedded.de> <4C7E1D85.4060400@LiPPERTEmbedded.de> Message-ID: <4C7E376D.6070301@georgi-clan.de> Am 01.09.2010 11:31, schrieb Jens Rottmann: > I meant the mapping INT A --> IRQ 10 etc. I already had a patch for this > (attached) but also decided against it, because this should be generic > and _not_ done individually at the board level and the device tree is a > better place for it anyway. That data doesn't belong in code, yes. Unfortunately we don't have a very good place for it at all, at the moment. The plan is to fix that, but I can't give a schedule, so _any_ support you provide will (very likely) need to be rewritten at some point (once we have a framework for that), so don't waste too much time to make it pretty. Patrick From stefan.reinauer at coresystems.de Wed Sep 1 13:30:55 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 01 Sep 2010 13:30:55 +0200 Subject: [coreboot] [PATCH] option_table.h race Message-ID: <4C7E396F.5080307@coresystems.de> See patch. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix_option_race.diff URL: From stefan.reinauer at coresystems.de Wed Sep 1 13:59:44 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 01 Sep 2010 13:59:44 +0200 Subject: [coreboot] [PATCH] use Kconfig for both options on Lippert boards In-Reply-To: <4C7E376D.6070301@georgi-clan.de> References: <4C7CF5FF.1020307@LiPPERTEmbedded.de> <4C7D44E1.8060403@LiPPERTEmbedded.de> <4C7E1D85.4060400@LiPPERTEmbedded.de> <4C7E376D.6070301@georgi-clan.de> Message-ID: <4C7E4030.7030301@coresystems.de> On 9/1/10 1:22 PM, Patrick Georgi wrote: > Am 01.09.2010 11:31, schrieb Jens Rottmann: >> I meant the mapping INT A --> IRQ 10 etc. I already had a patch for this >> (attached) but also decided against it, because this should be generic >> and _not_ done individually at the board level and the device tree is a >> better place for it anyway. > That data doesn't belong in code, yes. Unfortunately we don't have a > very good place for it at all, at the moment. > The plan is to fix that, but I can't give a schedule, so _any_ support > you provide will (very likely) need to be rewritten at some point > (once we have a framework for that), so don't waste too much time to > make it pretty. Actually, I think for the mapping we do have a mechanism in some mainboards already, and it's stored in the device tree. http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/mainboard/kontron/986lcd-m/devicetree.cb In addition, the IRQ routing information itself should also be stored in the device tree, and that, unfortunately, lacks a framework to do so. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From wt at penguintechs.org Wed Sep 1 11:13:21 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 02:13:21 -0700 Subject: [coreboot] [PATCH] Add support for dumping RCBA registers for i7. Message-ID: <1283332401-10749-1-git-send-email-wt@penguintechs.org> Signed-off-by: Warren Turkal --- util/inteltool/rootcmplx.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/util/inteltool/rootcmplx.c b/util/inteltool/rootcmplx.c index 215c150..cb5d2a3 100644 --- a/util/inteltool/rootcmplx.c +++ b/util/inteltool/rootcmplx.c @@ -36,14 +36,15 @@ int print_rcba(struct pci_dev *sb) case PCI_DEVICE_ID_INTEL_ICH7M: case PCI_DEVICE_ID_INTEL_ICH7DH: case PCI_DEVICE_ID_INTEL_ICH7MDH: + case PCI_DEVICE_ID_INTEL_ICH8: + case PCI_DEVICE_ID_INTEL_ICH8M: case PCI_DEVICE_ID_INTEL_ICH9DH: case PCI_DEVICE_ID_INTEL_ICH9DO: case PCI_DEVICE_ID_INTEL_ICH9R: case PCI_DEVICE_ID_INTEL_ICH9: case PCI_DEVICE_ID_INTEL_ICH9M: case PCI_DEVICE_ID_INTEL_ICH9ME: - case PCI_DEVICE_ID_INTEL_ICH8M: - case PCI_DEVICE_ID_INTEL_ICH8: + case PCI_DEVICE_ID_INTEL_ICH10R: case PCI_DEVICE_ID_INTEL_NM10: rcba_phys = pci_read_long(sb, 0xf0) & 0xfffffffe; break; -- 1.7.1 From stefan.reinauer at coresystems.de Wed Sep 1 17:03:03 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 01 Sep 2010 17:03:03 +0200 Subject: [coreboot] device tree rework (was: Re: [PATCH] use Kconfig for both options on Lippert boards) In-Reply-To: <20100831223918.28439.qmail@stuge.se> References: <4C7CF5FF.1020307@LiPPERTEmbedded.de> <4C7D44E1.8060403@LiPPERTEmbedded.de> <20100831223918.28439.qmail@stuge.se> Message-ID: <4C7E6B27.3030600@coresystems.de> Peter Stuge wrote: > Jens Rottmann wrote: >>> Maybe make that one option per port instead, >> I had considered this but decided against it. > Oh well. > > >> It is simply not feasible to make _everything_ configurable, > I'm not sure I agree about feasible. I agree it's not worthwhile > though. You know your customers best, but from my experience with > embedded customers, more configurability is better. :) > It also changes the code from "do the minimal effort for hardware init" to "parse a lot of different options and make sure all possible combinations make sense and work". I'm not saying we shouldn't. I'm just saying it'll be a shift in principles. (And a lot of effort if done right) >> you'd have to start with devicetree.cb, > I know. This is one part of coreboot "infrastructure" that I think > needs some improvement. A first step would be interrupt routing. > > It might also be nice to make it a little easier to use devicetree.cb > from the coreboot code. Now that we have a good grip on the device tree and sconfig is increasingly stable, we should discuss how to get the routing into our device tree. Suggestions? Some brainstorming: - every device that has an APIC needs to have IRQ routing information. Every bridge, even? - what about 8259? Virtual Wire? - We need to represent the IO apics in the device tree so we can walk the system for dynamic boot time table creation. - any of the i945 ports would be an easy initial target, as they have i945_pci_irqs.asl, ich7_pci_irqs.asl, irq_tables.c and mptable.c in separate files, so they could be replaced easily by something auto generated. *.asl could (at least for now) be created from the device tree at compile time. - A good first start (and relatively easy, since its only refactoring) would also be to factor out interrupt routing from the K8/Fam10 boards into separate files, and move their acpi code to the north/southbridge like it's done on i945/ich7. Any takers? Stefan From mylesgw at gmail.com Wed Sep 1 17:12:40 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 1 Sep 2010 09:12:40 -0600 Subject: [coreboot] timeout during PS/2 keyboard init In-Reply-To: References: Message-ID: On Tue, Aug 31, 2010 at 11:16 PM, Scott wrote: > Hello, > > While testing on AMD simnow I encounter a timeout in keyboard.c line 246: > > /* All is well - enable keyboard interface */ > if (!kbc_input_buffer_empty()) return; > outb(0x60, KBD_COMMAND); > if (!kbc_input_buffer_empty()) return; > outb(0x61, KBD_DATA); ? /* send cmd: enable keyboard and IRQ 1 */ > if (kbc_output_buffer_full()) { > ? ? ? ?printk(BIOS_ERR, "Timeout during final keyboard enable\n"); <======= > ? ? ? ?return; > } > > It seems like line 245 should call kbc_input_buffer_empty() instead of > kbc_output_buffer_full() because the previous I/O does not cause the > keyboard to generate any data. > > On simnow, this causes a boot delay of a minute or so. On real hardware, > It appears it could cause a boot delay of 400 ms. Does anyone testing > with real hardware ever notice the "Timeout during final keyboard enable" > message when logging is enabled? if (!timeout) { printk(BIOS_INFO, "Keyboard controller output buffer result timeout\n"); } I see this one in hardware. Thanks, Myles From mylesgw at gmail.com Wed Sep 1 17:26:50 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 1 Sep 2010 09:26:50 -0600 Subject: [coreboot] [PATCH] option_table.h race In-Reply-To: <4C7E396F.5080307@coresystems.de> References: <4C7E396F.5080307@coresystems.de> Message-ID: The only thing that worries me is this include. from src/include/pc80/mc146818rtc.h: #include It seems like usually when we make initobj, we stop including the c file. Acked-by: Myles Watson Thanks, Myles From stefan.reinauer at coresystems.de Wed Sep 1 18:20:38 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 01 Sep 2010 18:20:38 +0200 Subject: [coreboot] [PATCH] option_table.h race In-Reply-To: References: <4C7E396F.5080307@coresystems.de> Message-ID: <4C7E7D56.7070705@coresystems.de> On 9/1/10 5:26 PM, Myles Watson wrote: > The only thing that worries me is this include. > > from src/include/pc80/mc146818rtc.h: > #include > > It seems like usually when we make initobj, we stop including the c file. Yes... Another problem though. It's guarded by #ifdef __ROMCC__ so it only gets included on romcc targets. We could remove the C include from there and move it to the romstage.c files, to make it more obvious which .c files get sucked in on the targets. Not sure what else we could do.. There are 4 other places where a .c file is included in a .h file: ./src/arch/i386/include/bootblock_common.h:#include ./src/include/console/console.h:#include ./src/include/console/console.h:#include "lib/ne2k.c" ./src/include/console/console.h:#include ./src/include/pc80/mc146818rtc.h:#include In addition: - We have an unknown number of .h files that contain functions - We include .c files in 148 romstage.c files and in these: ./cpu/amd/car/post_cache_as_ram.c ./cpu/amd/dualcore/amd_sibling.c ./cpu/amd/dualcore/dualcore.c ./cpu/amd/model_10xxx/init_cpus.c ./cpu/amd/quadcore/amd_sibling.c ./cpu/amd/quadcore/quadcore.c ./cpu/amd/sc520/raminit.c ./drivers/ati/ragexl/xlinit.c ./lib/lzma.c ./mainboard/getac/p470/mainboard.c ./mainboard/getac/p470/mainboard_smi.c ./northbridge/amd/amdfam10/bootblock.c ./northbridge/amd/amdfam10/debug.c ./northbridge/amd/amdfam10/northbridge.c ./northbridge/amd/amdfam10/raminit_amdmct.c ./northbridge/amd/amdht/h3finit.c ./northbridge/amd/amdht/ht_wrapper.c ./northbridge/amd/amdk8/raminit_f.c ./northbridge/amd/amdk8/raminit_test.c ./northbridge/intel/i82830/raminit.c ./northbridge/intel/i945/early_init.c ./northbridge/intel/i945/raminit.c ./northbridge/via/vx800/raminit.c ./pc80/usbdebug_serial.c ./pc80/vga/vga.c ./southbridge/amd/amd8111/amd8111_reset.c ./southbridge/amd/amd8111/bootblock.c ./southbridge/amd/cs5530/cs5530_vga.c ./southbridge/amd/sb600/sb600_early_setup.c ./southbridge/amd/sb600/sb600_reset.c ./southbridge/amd/sb600/sb600_sm.c ./southbridge/amd/sb700/sb700_early_setup.c ./southbridge/amd/sb700/sb700_reset.c ./southbridge/amd/sb700/sb700_sm.c ./southbridge/broadcom/bcm5785/bcm5785_early_setup.c ./southbridge/broadcom/bcm5785/bcm5785_reset.c ./southbridge/broadcom/bcm5785/bootblock.c ./southbridge/intel/i82801dx/i82801dx_smihandler.c ./southbridge/intel/i82801gx/i82801gx_smihandler.c ./southbridge/nvidia/ck804/ck804_reset.c ./southbridge/nvidia/mcp55/mcp55_reset.c ./southbridge/sis/sis966/sis966_reset.c Stefan From svn at coreboot.org Wed Sep 1 18:27:14 2010 From: svn at coreboot.org (repository service) Date: Wed, 01 Sep 2010 18:27:14 +0200 Subject: [coreboot] [commit] r5762 - in trunk/src: include/pc80 mainboard/amd/dbm690t pc80 Message-ID: Author: stepan Date: Wed Sep 1 18:27:13 2010 New Revision: 5762 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5762 Log: Fix race condition in option_table.h generation by moving the include statement to those files that actually need it. This significantly reduces the number of dependencies, so it's no longer extremely ugly to specify them manually (see the src/pc80/Makefile.inc portion) Also, drop the AMD DBM690T work around for the issue. Signed-off-by: Stefan Reinauer Acked-by: Myles Watson Modified: trunk/src/include/pc80/mc146818rtc.h trunk/src/mainboard/amd/dbm690t/Kconfig trunk/src/pc80/Makefile.inc trunk/src/pc80/mc146818rtc.c trunk/src/pc80/mc146818rtc_early.c Modified: trunk/src/include/pc80/mc146818rtc.h ============================================================================== --- trunk/src/include/pc80/mc146818rtc.h Wed Sep 1 05:40:57 2010 (r5761) +++ trunk/src/include/pc80/mc146818rtc.h Wed Sep 1 18:27:13 2010 (r5762) @@ -81,14 +81,6 @@ #define PC_CKS_RANGE_END 45 #define PC_CKS_LOC 46 -/* coreboot cmos checksum is usually only built over bytes 49..125 - * LB_CKS_RANGE_START, LB_CKS_RANGE_END and LB_CKS_LOC are defined - * in option_table.h - */ -#if CONFIG_HAVE_OPTION_TABLE -#include -#endif - #ifndef UTIL_BUILD_OPTION_TABLE #include static inline unsigned char cmos_read(unsigned char addr) Modified: trunk/src/mainboard/amd/dbm690t/Kconfig ============================================================================== --- trunk/src/mainboard/amd/dbm690t/Kconfig Wed Sep 1 05:40:57 2010 (r5761) +++ trunk/src/mainboard/amd/dbm690t/Kconfig Wed Sep 1 18:27:13 2010 (r5762) @@ -25,12 +25,6 @@ string default amd/dbm690t -# This is a temporary fix, and should be removed when the race condition for -# building option_table.h is fixed. -config WARNINGS_ARE_ERRORS - bool - default n - config DCACHE_RAM_BASE hex default 0xc8000 Modified: trunk/src/pc80/Makefile.inc ============================================================================== --- trunk/src/pc80/Makefile.inc Wed Sep 1 05:40:57 2010 (r5761) +++ trunk/src/pc80/Makefile.inc Wed Sep 1 18:27:13 2010 (r5762) @@ -8,3 +8,4 @@ subdirs-y += vga $(obj)/pc80/mc146818rtc.o : $(OPTION_TABLE_H) +$(obj)/pc80/mc146818rtc_early.initobj.o : $(OPTION_TABLE_H) Modified: trunk/src/pc80/mc146818rtc.c ============================================================================== --- trunk/src/pc80/mc146818rtc.c Wed Sep 1 05:40:57 2010 (r5761) +++ trunk/src/pc80/mc146818rtc.c Wed Sep 1 18:27:13 2010 (r5762) @@ -2,6 +2,9 @@ #include #include #include +#if CONFIG_USE_OPTION_TABLE +#include +#endif /* control registers - Moto names */ Modified: trunk/src/pc80/mc146818rtc_early.c ============================================================================== --- trunk/src/pc80/mc146818rtc_early.c Wed Sep 1 05:40:57 2010 (r5761) +++ trunk/src/pc80/mc146818rtc_early.c Wed Sep 1 18:27:13 2010 (r5762) @@ -1,6 +1,10 @@ #include #include +#if CONFIG_USE_OPTION_TABLE +#include +#endif + #ifndef CONFIG_MAX_REBOOT_CNT #error "CONFIG_MAX_REBOOT_CNT not defined" #endif From mylesgw at gmail.com Wed Sep 1 18:28:28 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 1 Sep 2010 10:28:28 -0600 Subject: [coreboot] [PATCH] option_table.h race In-Reply-To: <4C7E7D56.7070705@coresystems.de> References: <4C7E396F.5080307@coresystems.de> <4C7E7D56.7070705@coresystems.de> Message-ID: On Wed, Sep 1, 2010 at 10:20 AM, Stefan Reinauer wrote: > ?On 9/1/10 5:26 PM, Myles Watson wrote: >> The only thing that worries me is this include. >> >> from src/include/pc80/mc146818rtc.h: >> #include >> >> It seems like usually when we make initobj, we stop including the c file. > Yes... Another problem though. Yes. A problem for another day. I was just noting that it made it harder to follow. Thanks, Myles From svn at coreboot.org Wed Sep 1 18:39:53 2010 From: svn at coreboot.org (repository service) Date: Wed, 01 Sep 2010 18:39:53 +0200 Subject: [coreboot] build service results for r5762 Message-ID: Dear coreboot readers! This is the automatic build system of coreboot. The developer "stepan" checked in revision 5762 to the coreboot repository. This caused the following changes: Change Log: Fix race condition in option_table.h generation by moving the include statement to those files that actually need it. This significantly reduces the number of dependencies, so it's no longer extremely ugly to specify them manually (see the src/pc80/Makefile.inc portion) Also, drop the AMD DBM690T work around for the issue. Signed-off-by: Stefan Reinauer Acked-by: Myles Watson Build Log: Compilation of a-trend:atc-6220 has been fixed If something broke during this checkin please be a pain in stepan'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 From scott at notabs.org Wed Sep 1 20:50:12 2010 From: scott at notabs.org (Scott) Date: Wed, 1 Sep 2010 13:50:12 -0500 Subject: [coreboot] AMD Tilapia / simnow: endless looping in function pci_scan_bus Message-ID: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> Hello, When booting the AMD Tilapia coreboot BIOS on simnow I encounter an endless loop in pci_scan_bus(). The reason is that pci_scan_bus expects a valid argument for max_devfn, yet receives 0xFFFFFFFF. The origin of the invalid max_devfn argument is line 596 of hypertransport.c: max = pci_scan_bus(bus, 0x00, ((next_unitid-1) << 3)|7, max); With my setup, next_unitid is zero, which causes a bad argument to be passed to pci_scan_bus. As a work-around, I change the code to recognize and handle this case by passing 0xFF (all devices). Does anyone else encounter this situation on AMD boards? I ask because I am using simnow in place of real hardware. Thanks, Scott From mylesgw at gmail.com Wed Sep 1 21:21:50 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 1 Sep 2010 13:21:50 -0600 Subject: [coreboot] AMD Tilapia / simnow: endless looping in function pci_scan_bus In-Reply-To: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> Message-ID: On Wed, Sep 1, 2010 at 12:50 PM, Scott wrote: > Hello, > > When booting the AMD Tilapia coreboot BIOS on simnow I encounter > an endless loop in pci_scan_bus(). The reason is that pci_scan_bus > expects a valid argument for max_devfn, yet receives 0xFFFFFFFF. > > The origin of the invalid max_devfn argument is line 596 of > hypertransport.c: > > ? max = pci_scan_bus(bus, 0x00, ((next_unitid-1) << 3)|7, max); > > With my setup, next_unitid is zero, which causes a bad argument > to be passed to pci_scan_bus. As a work-around, I change the code > to recognize and handle this case by passing 0xFF (all devices). > > Does anyone else encounter this situation on AMD boards? I ask > because I am using simnow in place of real hardware. Juhana Helovuo reported this in the thread "Porting to Asus M4A785-M". Thanks, Myles From scott at notabs.org Wed Sep 1 22:00:14 2010 From: scott at notabs.org (Scott) Date: Wed, 1 Sep 2010 15:00:14 -0500 Subject: [coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> Message-ID: <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> -----Original Message----- From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Myles Watson Sent: Wednesday, September 01, 2010 02:22 PM To: Scott Cc: coreboot at coreboot.org Subject: Re: [coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus On Wed, Sep 1, 2010 at 12:50 PM, Scott wrote: > Hello, > > When booting the AMD Tilapia coreboot BIOS on simnow I encounter > an endless loop in pci_scan_bus(). The reason is that pci_scan_bus > expects a valid argument for max_devfn, yet receives 0xFFFFFFFF. > > The origin of the invalid max_devfn argument is line 596 of > hypertransport.c: > > ? max = pci_scan_bus(bus, 0x00, ((next_unitid-1) << 3)|7, max); > > With my setup, next_unitid is zero, which causes a bad argument > to be passed to pci_scan_bus. As a work-around, I change the code > to recognize and handle this case by passing 0xFF (all devices). > > Does anyone else encounter this situation on AMD boards? I ask > because I am using simnow in place of real hardware. Juhana Helovuo reported this in the thread "Porting to Asus M4A785-M". Thanks, Myles -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Thanks Myles. That problem description and work-around matches my situation exactly. Even if the bad value passed to pci_scan_bus is only a side-effect of another problem, special handling for it should be considered in order to simplify debugging. The same thead covers another problem I encounter with Tilapia. When I enable ACPI table generation, an overlap causes the seabios payload to overwrite the ACPI tables. I temporarily worked around this problem by deselecting GFXUMA. I am using PCI video so I can boot with no uma. Thanks, Scott From wt at penguintechs.org Wed Sep 1 22:54:00 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 13:54:00 -0700 Subject: [coreboot] [PATCH 4/4] Add DMIBAR support for Intel X58 southbridge. In-Reply-To: <1283373697-16398-5-git-send-email-wt@penguintechs.org> References: <1283373697-16398-1-git-send-email-wt@penguintechs.org> <1283373697-16398-5-git-send-email-wt@penguintechs.org> Message-ID: The output for this is smaller than I expected, so it would be nice to get another pair of eyes on this. I implemented this with information contained in the following doc: Intel 320838 (X58 Express Chipset) Section 17.12.4.5 (DMI RCBAR) Thanks, wt On Wed, Sep 1, 2010 at 1:41 PM, Warren Turkal wrote: > Signed-off-by: Warren Turkal > --- > ?util/inteltool/pcie.c | ? ?3 +++ > ?1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/util/inteltool/pcie.c b/util/inteltool/pcie.c > index 0201342..2c0f6a4 100644 > --- a/util/inteltool/pcie.c > +++ b/util/inteltool/pcie.c > @@ -114,6 +114,9 @@ int print_dmibar(struct pci_dev *nb) > ? ? ? ?case PCI_DEVICE_ID_INTEL_82810E_MC: > ? ? ? ? ? ? ? ?printf("This northbrigde does not have DMIBAR.\n"); > ? ? ? ? ? ? ? ?return 1; > + ? ? ? case PCI_DEVICE_ID_INTEL_X58: > + ? ? ? ? ? ? ? dmibar_phys = pci_read_long(nb, 0x50) & 0xfffff000; > + ? ? ? ? ? ? ? break; > ? ? ? ?default: > ? ? ? ? ? ? ? ?printf("Error: Dumping DMIBAR on this northbridge is not (yet) supported.\n"); > ? ? ? ? ? ? ? ?return 1; > -- > 1.7.1 > > From svn at coreboot.org Wed Sep 1 23:03:04 2010 From: svn at coreboot.org (repository service) Date: Wed, 01 Sep 2010 23:03:04 +0200 Subject: [coreboot] [commit] r5763 - in trunk: src/devices util/sconfig Message-ID: Author: myles Date: Wed Sep 1 23:03:03 2010 New Revision: 5763 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5763 Log: Simplify last_dev_p so that it matches comments. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/devices/device.c trunk/util/sconfig/main.c Modified: trunk/src/devices/device.c ============================================================================== --- trunk/src/devices/device.c Wed Sep 1 18:27:13 2010 (r5762) +++ trunk/src/devices/device.c Wed Sep 1 23:03:03 2010 (r5763) @@ -42,7 +42,7 @@ /** Linked list of ALL devices */ struct device *all_devices = &dev_root; /** Pointer to the last device */ -extern struct device **last_dev_p; +extern struct device *last_dev; /** Linked list of free resources */ struct resource *free_resources = NULL; @@ -95,8 +95,8 @@ /* Append a new device to the global device list. * The list is used to find devices once everything is set up. */ - *last_dev_p = dev; - last_dev_p = &dev->next; + last_dev->next = dev; + last_dev = dev; spin_unlock(&dev_lock); return dev; Modified: trunk/util/sconfig/main.c ============================================================================== --- trunk/util/sconfig/main.c Wed Sep 1 18:27:13 2010 (r5762) +++ trunk/util/sconfig/main.c Wed Sep 1 23:03:03 2010 (r5763) @@ -446,7 +446,7 @@ } fprintf(staticc, "\n/* pass 0 */\n"); walk_device_tree(staticc, &root, pass0, NULL); - fprintf(staticc, "\n/* pass 1 */\nstruct mainboard_config mainboard_info_0;\nstruct device **last_dev_p = &%s.next;\n", lastdev->name); + fprintf(staticc, "\n/* pass 1 */\nstruct mainboard_config mainboard_info_0;\nstruct device *last_dev = &%s;\n", lastdev->name); walk_device_tree(staticc, &root, pass1, NULL); fclose(staticc); From wt at penguintechs.org Wed Sep 1 22:41:34 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 13:41:34 -0700 Subject: [coreboot] [PATCH 1/4] Add support for dumping RCBA registers for i7. In-Reply-To: <1283373697-16398-1-git-send-email-wt@penguintechs.org> References: <1283373697-16398-1-git-send-email-wt@penguintechs.org> Message-ID: <1283373697-16398-2-git-send-email-wt@penguintechs.org> Signed-off-by: Warren Turkal --- util/inteltool/rootcmplx.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/util/inteltool/rootcmplx.c b/util/inteltool/rootcmplx.c index 215c150..cb5d2a3 100644 --- a/util/inteltool/rootcmplx.c +++ b/util/inteltool/rootcmplx.c @@ -36,14 +36,15 @@ int print_rcba(struct pci_dev *sb) case PCI_DEVICE_ID_INTEL_ICH7M: case PCI_DEVICE_ID_INTEL_ICH7DH: case PCI_DEVICE_ID_INTEL_ICH7MDH: + case PCI_DEVICE_ID_INTEL_ICH8: + case PCI_DEVICE_ID_INTEL_ICH8M: case PCI_DEVICE_ID_INTEL_ICH9DH: case PCI_DEVICE_ID_INTEL_ICH9DO: case PCI_DEVICE_ID_INTEL_ICH9R: case PCI_DEVICE_ID_INTEL_ICH9: case PCI_DEVICE_ID_INTEL_ICH9M: case PCI_DEVICE_ID_INTEL_ICH9ME: - case PCI_DEVICE_ID_INTEL_ICH8M: - case PCI_DEVICE_ID_INTEL_ICH8: + case PCI_DEVICE_ID_INTEL_ICH10R: case PCI_DEVICE_ID_INTEL_NM10: rcba_phys = pci_read_long(sb, 0xf0) & 0xfffffffe; break; -- 1.7.1 From wt at penguintechs.org Wed Sep 1 22:41:37 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 13:41:37 -0700 Subject: [coreboot] [PATCH 4/4] Add DMIBAR support for Intel X58 southbridge. In-Reply-To: <1283373697-16398-1-git-send-email-wt@penguintechs.org> References: <1283373697-16398-1-git-send-email-wt@penguintechs.org> Message-ID: <1283373697-16398-5-git-send-email-wt@penguintechs.org> Signed-off-by: Warren Turkal --- util/inteltool/pcie.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/util/inteltool/pcie.c b/util/inteltool/pcie.c index 0201342..2c0f6a4 100644 --- a/util/inteltool/pcie.c +++ b/util/inteltool/pcie.c @@ -114,6 +114,9 @@ int print_dmibar(struct pci_dev *nb) case PCI_DEVICE_ID_INTEL_82810E_MC: printf("This northbrigde does not have DMIBAR.\n"); return 1; + case PCI_DEVICE_ID_INTEL_X58: + dmibar_phys = pci_read_long(nb, 0x50) & 0xfffff000; + break; default: printf("Error: Dumping DMIBAR on this northbridge is not (yet) supported.\n"); return 1; -- 1.7.1 From wt at penguintechs.org Wed Sep 1 22:41:36 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 13:41:36 -0700 Subject: [coreboot] [PATCH 3/4] Remove some errant spaces. In-Reply-To: <1283373697-16398-1-git-send-email-wt@penguintechs.org> References: <1283373697-16398-1-git-send-email-wt@penguintechs.org> Message-ID: <1283373697-16398-4-git-send-email-wt@penguintechs.org> Signed-off-by: Warren Turkal --- util/inteltool/pcie.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/util/inteltool/pcie.c b/util/inteltool/pcie.c index b4ad732..0201342 100644 --- a/util/inteltool/pcie.c +++ b/util/inteltool/pcie.c @@ -98,17 +98,17 @@ int print_dmibar(struct pci_dev *nb) case PCI_DEVICE_ID_INTEL_82975X: dmibar_phys = pci_read_long(nb, 0x4c) & 0xfffffffe; break; - case PCI_DEVICE_ID_INTEL_PM965: + case PCI_DEVICE_ID_INTEL_PM965: case PCI_DEVICE_ID_INTEL_Q965: - case PCI_DEVICE_ID_INTEL_82Q35: - case PCI_DEVICE_ID_INTEL_82G33: - case PCI_DEVICE_ID_INTEL_82Q33: + case PCI_DEVICE_ID_INTEL_82Q35: + case PCI_DEVICE_ID_INTEL_82G33: + case PCI_DEVICE_ID_INTEL_82Q33: case PCI_DEVICE_ID_INTEL_GS45: case PCI_DEVICE_ID_INTEL_ATOM_DXXX: case PCI_DEVICE_ID_INTEL_ATOM_NXXX: - dmibar_phys = pci_read_long(nb, 0x68) & 0xfffffffe; - dmibar_phys |= ((uint64_t)pci_read_long(nb, 0x6c)) << 32; - break; + dmibar_phys = pci_read_long(nb, 0x68) & 0xfffffffe; + dmibar_phys |= ((uint64_t)pci_read_long(nb, 0x6c)) << 32; + break; case PCI_DEVICE_ID_INTEL_82810: case PCI_DEVICE_ID_INTEL_82810DC: case PCI_DEVICE_ID_INTEL_82810E_MC: -- 1.7.1 From wt at penguintechs.org Wed Sep 1 22:41:33 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 13:41:33 -0700 Subject: [coreboot] [PATCH 0/4] Improve inteltool for my motherboard Message-ID: <1283373697-16398-1-git-send-email-wt@penguintechs.org> Here's another update to my series of patches to improve support for my motherboard configuration in inteltool. Please review and/or commit these patches. Thanks, wt Warren Turkal (4): Add support for dumping RCBA registers for i7. Add support for dumping ACPI registers for i7. Remove some errant spaces. Add DMIBAR support for Intel X58 southbridge. util/inteltool/pcie.c | 17 +++++++----- util/inteltool/powermgt.c | 65 ++++++++++++++++++++++++++++++++++++++++++++ util/inteltool/rootcmplx.c | 5 ++- 3 files changed, 78 insertions(+), 9 deletions(-) From wt at penguintechs.org Wed Sep 1 22:41:35 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 13:41:35 -0700 Subject: [coreboot] [PATCH 2/4] Add support for dumping ACPI registers for i7. In-Reply-To: <1283373697-16398-1-git-send-email-wt@penguintechs.org> References: <1283373697-16398-1-git-send-email-wt@penguintechs.org> Message-ID: <1283373697-16398-3-git-send-email-wt@penguintechs.org> Signed-off-by: Warren Turkal --- util/inteltool/powermgt.c | 65 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-) diff --git a/util/inteltool/powermgt.c b/util/inteltool/powermgt.c index 5f93835..3032f4d 100644 --- a/util/inteltool/powermgt.c +++ b/util/inteltool/powermgt.c @@ -21,6 +21,66 @@ #include #include "inteltool.h" +static const io_register_t ich10_pm_registers[] = { + { 0x00, 2, "PM1_STS" }, // PM1 Status; ACPI pointer: PM1a_EVT_BLK + { 0x02, 2, "PM1_EN" }, // PM1 Enables; ACPI pointer: PM1a_EVT_BLK+2 + { 0x04, 4, "PM1_CNT" }, // PM1 Control; ACPI pointer: PM1a_CNT_BLK + { 0x08, 4, "PM1_TMR" }, // PM1 Timer; ACPI pointer: PMTMR_BLK + { 0x0c, 4, "RESERVED" }, + { 0x10, 4, "PROC_CNT" }, // Processor Control; ACPI pointer: P_BLK +#if DANGEROUS_REGISTERS + /* These registers return 0 on read, but reading them may cause + * the system to enter Cx states, which might hang the system. + */ + { 0x14, 1, "LV2 (Mobile)" }, + { 0x15, 1, "LV3 (Mobile)" }, + { 0x16, 1, "LV4 (Mobile)" }, +#endif + { 0x17, 2, "RESERVED" }, + { 0x19, 1, "RESERVED" }, + { 0x1a, 2, "RESERVED" }, + { 0x1c, 4, "RESERVED" }, + { 0x20, 8, "GPE0_STS" }, // General Purpose Event 0 Status; ACPI pointer: GPE0_BLK + { 0x2C, 4, "GPE0_EN" }, // General Purpose Event 0 Enables; ACPI pointer: GPE0_BLK+8 + { 0x30, 4, "SMI_EN" }, + { 0x34, 4, "SMI_STS" }, + { 0x38, 2, "ALT_GP_SMI_EN" }, + { 0x3a, 2, "ALT_GP_SMI_STS" }, + { 0x3c, 1, "UPRWC" }, // USB Per-Port registers write control; + { 0x3d, 2, "RESERVED" }, + { 0x3f, 1, "RESERVED" }, + { 0x40, 2, "RESERVED" }, + { 0x42, 1, "GPE_CNTL" }, + { 0x43, 1, "RESERVED" }, + { 0x44, 2, "DEVACT_STS" }, // Device Activity Status + { 0x46, 2, "RESERVED" }, + { 0x48, 4, "RESERVED" }, + { 0x4c, 4, "RESERVED" }, + { 0x50, 1, "PM2_CNT (Mobile)" }, // PM2 Control (Mobile only); ACPI pointer: PM2a_CNT_BLK + { 0x51, 1, "RESERVED" }, + { 0x52, 2, "RESERVED" }, + { 0x54, 4, "C3_RES (Mobile)" }, + { 0x58, 4, "RESERVED" }, + { 0x5c, 4, "RESERVED" }, + /* Here start the TCO registers */ + { 0x60, 2, "TCO_RLD" }, + { 0x62, 1, "TCO_DAT_IN" }, + { 0x63, 1, "TCO_DAT_OUT" }, + { 0x64, 2, "TCO1_STS" }, + { 0x66, 2, "TCO2_STS" }, + { 0x68, 2, "TCO1_CNT" }, + { 0x6a, 2, "TCO2_CNT" }, + { 0x6c, 2, "TCO_MESSAGE" }, + { 0x6e, 1, "TCO_WDCNT" }, + { 0x6f, 1, "RESERVED" }, + { 0x70, 1, "SW_IRQ_GEN" }, + { 0x71, 1, "RESERVED" }, + { 0x72, 2, "TCO_TMR" }, + { 0x74, 4, "RESERVED" }, + { 0x78, 4, "RESERVED" }, + { 0x7c, 4, "RESERVED" }, +}; + static const io_register_t ich9_pm_registers[] = { { 0x00, 2, "PM1_STS" }, // PM1 Status; ACPI pointer: PM1a_EVT_BLK { 0x02, 2, "PM1_EN" }, // PM1 Enables; ACPI pointer: PM1a_EVT_BLK+2 @@ -473,6 +533,11 @@ int print_pmbase(struct pci_dev *sb) printf("\n============= PMBASE ============\n\n"); switch (sb->device_id) { + case PCI_DEVICE_ID_INTEL_ICH10R: + pmbase = pci_read_word(sb, 0x40) & 0xff80; + pm_registers = ich10_pm_registers; + size = ARRAY_SIZE(ich10_pm_registers); + break; case PCI_DEVICE_ID_INTEL_ICH7: case PCI_DEVICE_ID_INTEL_ICH7M: case PCI_DEVICE_ID_INTEL_ICH7DH: -- 1.7.1 From wt at penguintechs.org Thu Sep 2 01:34:36 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 16:34:36 -0700 Subject: [coreboot] [PATCH] Add cscope support to the Makefile. Message-ID: <1283384076-17646-1-git-send-email-wt@penguintechs.org> Signed-off-by: Warren Turkal --- Makefile | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index cc3eb4e..06902ba 100644 --- a/Makefile +++ b/Makefile @@ -330,6 +330,9 @@ $(obj)/build.h: .xcompile printf "#endif\n" >> $(obj)/build.ht mv $(obj)/build.ht $(obj)/build.h +cscope: + cscope -bR + doxy: doxygen doxygen: $(DOXYGEN) documentation/Doxyfile.coreboot @@ -354,7 +357,10 @@ clean-for-update: doxygen-clean clean: clean-for-update rm -f $(obj)/coreboot* .ccwrap -distclean: +clean-cscope: + rm -f cscope.out + +distclean: clean-cscope rm -rf $(obj) rm -f .config .config.old ..config.tmp .kconfig.d .tmpconfig* .ccwrap .xcompile @@ -383,5 +389,5 @@ $(objutil)/romcc/romcc: $(top)/util/romcc/romcc.c @# http://www.coreboot.org/pipermail/coreboot/2010-February/055825.html $(HOSTCC) -g $(STACK) -Wall -o $@ $< -.PHONY: $(PHONY) clean distclean doxygen doxy coreboot .xcompile +.PHONY: $(PHONY) clean clean-cscope distclean doxygen doxy coreboot .xcompile -- 1.7.1 From scott at notabs.org Thu Sep 2 07:40:50 2010 From: scott at notabs.org (Scott) Date: Thu, 2 Sep 2010 00:40:50 -0500 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' Message-ID: <0703EF8685AB4BB091774844213B7DF6@m3a78> Hello, The subversion comment for -r 5571 states: The AMD Fam10 code breaks with coreboot 4.5.0. Potentially caused by reordering. Going back to 4.4.4 which is known working on Fam10 until gcc or the Fam10 code is fixed. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer I encountered the same problem and debugged it. The AP code that disables cache as ram before the final halt has to be all inline. Function calls require a valid stack, and the stack is kept in the very cache as ram that the code is disabling. I found with gcc 450, the code for rdmsr, disable_cache, and enable_cache and not getting inlined as intended. Function calls are generated, and the first one after the AP clears msr 268 fails. The solution is to force these functions to generate inline code by adding __attribute__((always_inline)) to their declarations: Index: src/include/cpu/x86/msr.h =================================================================== --- src/include/cpu/x86/msr.h (revision 5763) +++ src/include/cpu/x86/msr.h (working copy) @@ -29,7 +29,7 @@ msr_t msr; } msrinit_t; -static inline msr_t rdmsr(unsigned index) +static inline __attribute__((always_inline)) msr_t rdmsr(unsigned index) { msr_t result; __asm__ __volatile__ ( @@ -40,7 +40,7 @@ return result; } -static inline void wrmsr(unsigned index, msr_t msr) +static inline __attribute__((always_inline)) void wrmsr(unsigned index, msr_t msr) { __asm__ __volatile__ ( "wrmsr" Index: src/include/cpu/x86/cache.h =================================================================== --- src/include/cpu/x86/cache.h (revision 5763) +++ src/include/cpu/x86/cache.h (working copy) @@ -74,7 +74,7 @@ asm volatile("invd" ::: "memory"); } -static inline void enable_cache(void) +static inline __attribute__((always_inline)) void enable_cache(void) { unsigned long cr0; cr0 = read_cr0(); @@ -82,7 +82,7 @@ write_cr0(cr0); } -static inline void disable_cache(void) +static inline __attribute__((always_inline)) void disable_cache(void) { /* Disable and write back the cache */ unsigned long cr0; Thanks, Scott From wt at penguintechs.org Thu Sep 2 07:41:17 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 22:41:17 -0700 Subject: [coreboot] [PATCH] Add cscope support to the Makefile. In-Reply-To: <1283384076-17646-1-git-send-email-wt@penguintechs.org> References: <1283384076-17646-1-git-send-email-wt@penguintechs.org> Message-ID: Hmm...I meant to add a note asking for someone to review and possibly commit this. Would someone mind. It's a simple addition to the top-level makefile to generate a cscope symbol database so that jumping around the code becomes simpler. It's something like an improved version of ctags. Thanks, wt On Wed, Sep 1, 2010 at 4:34 PM, Warren Turkal wrote: > Signed-off-by: Warren Turkal > --- > ?Makefile | ? 10 ++++++++-- > ?1 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index cc3eb4e..06902ba 100644 > --- a/Makefile > +++ b/Makefile > @@ -330,6 +330,9 @@ $(obj)/build.h: .xcompile > ? ? ? ?printf "#endif\n" >> $(obj)/build.ht > ? ? ? ?mv $(obj)/build.ht $(obj)/build.h > > +cscope: > + ? ? ? cscope -bR > + > ?doxy: doxygen > ?doxygen: > ? ? ? ?$(DOXYGEN) documentation/Doxyfile.coreboot > @@ -354,7 +357,10 @@ clean-for-update: doxygen-clean > ?clean: clean-for-update > ? ? ? ?rm -f $(obj)/coreboot* .ccwrap > > -distclean: > +clean-cscope: > + ? ? ? rm -f cscope.out > + > +distclean: clean-cscope > ? ? ? ?rm -rf $(obj) > ? ? ? ?rm -f .config .config.old ..config.tmp .kconfig.d .tmpconfig* .ccwrap .xcompile > > @@ -383,5 +389,5 @@ $(objutil)/romcc/romcc: $(top)/util/romcc/romcc.c > ? ? ? ?@# http://www.coreboot.org/pipermail/coreboot/2010-February/055825.html > ? ? ? ?$(HOSTCC) -g $(STACK) -Wall -o $@ $< > > -.PHONY: $(PHONY) clean distclean doxygen doxy coreboot .xcompile > +.PHONY: $(PHONY) clean clean-cscope distclean doxygen doxy coreboot .xcompile > > -- > 1.7.1 > > From wt at penguintechs.org Thu Sep 2 08:54:24 2010 From: wt at penguintechs.org (Warren Turkal) Date: Wed, 1 Sep 2010 23:54:24 -0700 Subject: [coreboot] RFC: inteltool architecture not sufficient for Core i7/x58/ich10 motherboard I have Message-ID: I have a problem with inteltool. It's architecture is too limiting for getting the PCIEXBAR and MCHBAR. The inteltool assumes that these values will come from the Northbridge. However, on my setup, these values reside in the CPU. I am looking for options. I see the following two overly broad options to solve my problem: 1) Radically change the inteltool to support this info. 2) Program yet another tool. I'm inclined to say that 1 is the better option. However, I don't have good design in mind for inteltool. Does anyone have any ideas for how to represent these differences in where the registers are found and if they even exist. Thanks, wt From juhe at iki.fi Thu Sep 2 09:18:15 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Thu, 02 Sep 2010 10:18:15 +0300 Subject: [coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus In-Reply-To: <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> Message-ID: <4C7F4FB7.8070107@iki.fi> 1.9.2010 23:00, Scott kirjoitti: > Thanks Myles. That problem description and work-around matches my > situation exactly. Even if the bad value passed to pci_scan_bus is > only a side-effect of another problem, special handling for it should > be considered in order to simplify debugging. > > The same thead covers another problem I encounter with Tilapia. When > I enable ACPI table generation, an overlap causes the seabios payload > to overwrite the ACPI tables. I temporarily worked around this problem > by deselecting GFXUMA. I am using PCI video so I can boot with no uma. Hello, I had similar problems recently. I did a patch for Asus M4A785-M, which is derived from the AMD Tilapia port. The patch can be found at http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html There is another patch that sets up UMA and coreboot/ACPI/etc. tables as reserved areas in the multiboot tables. Without this patch booting with Grub to Linux suffers from the same problem of overwriting tables. http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html I do not know if these are going to be integrated to the Coreboot trunk, but currently they are available as patch files. How does SeaBIOS detect which RAM is usable and which is not? Maybe the memory conflict with UMA and ACPI tables could be avoided in a similar manner? Best regards, Juhana Helovuo From paulepanter at users.sourceforge.net Thu Sep 2 10:59:48 2010 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Thu, 02 Sep 2010 10:59:48 +0200 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <0703EF8685AB4BB091774844213B7DF6@m3a78> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> Message-ID: <1283417989.3990.4.camel@mattotaupa> Dear Scott, Am Donnerstag, den 02.09.2010, 00:40 -0500 schrieb Scott: > The subversion comment for -r 5571 states: > > The AMD Fam10 code breaks with coreboot 4.5.0. > Potentially caused by reordering. Going back to 4.4.4 > which is known working on Fam10 until gcc or the Fam10 code is fixed. > > Signed-off-by: Stefan Reinauer > Acked-by: Stefan Reinauer > > > I encountered the same problem and debugged it. The AP code that disables > cache as ram before the final halt has to be all inline. Function calls > require a valid stack, and the stack is kept in the very cache as ram that > the code is disabling. I found with gcc 450, the code for rdmsr, disable_cache, > and enable_cache and not getting inlined as intended. Function calls are s/and/are/ > generated, and the first one after the AP clears msr 268 fails. The solution > is to force these functions to generate inline code by adding > __attribute__((always_inline)) to their declarations: great find!!! Could you please send a patch according to the development guidelines. Especially do not forget to add your Signed-off-by line. Just to leave no doubt, could you please add that you tested your fix using GCC 4.5.0 with the used hardware. [?] Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From paulepanter at users.sourceforge.net Thu Sep 2 11:11:05 2010 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Thu, 02 Sep 2010 11:11:05 +0200 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <1283417989.3990.4.camel@mattotaupa> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <1283417989.3990.4.camel@mattotaupa> Message-ID: <1283418665.3990.5.camel@mattotaupa> Dear Scott, Am Donnerstag, den 02.09.2010, 10:59 +0200 schrieb Paul Menzel: > Am Donnerstag, den 02.09.2010, 00:40 -0500 schrieb Scott: > > > The subversion comment for -r 5571 states: > > > > The AMD Fam10 code breaks with coreboot 4.5.0. > > Potentially caused by reordering. Going back to 4.4.4 > > which is known working on Fam10 until gcc or the Fam10 code is fixed. > > > > Signed-off-by: Stefan Reinauer > > Acked-by: Stefan Reinauer > > > > > > I encountered the same problem and debugged it. The AP code that disables > > cache as ram before the final halt has to be all inline. Function calls > > require a valid stack, and the stack is kept in the very cache as ram that > > the code is disabling. I found with gcc 450, the code for rdmsr, disable_cache, > > and enable_cache and not getting inlined as intended. Function calls are > > s/and/are/ > > > generated, and the first one after the AP clears msr 268 fails. The solution > > is to force these functions to generate inline code by adding > > __attribute__((always_inline)) to their declarations: > > great find!!! Could you please send a patch according to the development > guidelines. Especially do not forget to add your Signed-off-by line. They are documented in the Wiki [1]. > Just to leave no doubt, could you please add that you tested your fix > using GCC 4.5.0 with the used hardware. > > [?] Thanks, Paul [1] http://www.coreboot.org/Development_Guidelines -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From scott at notabs.org Thu Sep 2 19:56:04 2010 From: scott at notabs.org (Scott) Date: Thu, 2 Sep 2010 12:56:04 -0500 Subject: [coreboot] revision 5762 change causing AMD Tilapia build to fail Message-ID: Hello, The include file change of rev 5762 is causing the AMD Tilapia build to fail for me. The work-around I found is to add: #include to src/cpu/amd/quadcore/quadcore.c. Thanks, Scott From svn at coreboot.org Thu Sep 2 20:29:31 2010 From: svn at coreboot.org (repository service) Date: Thu, 02 Sep 2010 20:29:31 +0200 Subject: [coreboot] [commit] r5764 - in trunk/src: include/pc80 mainboard/amd/dbm690t pc80 Message-ID: Author: myles Date: Thu Sep 2 20:29:31 2010 New Revision: 5764 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5764 Log: Revert 5762. It silently broke a lot of boards because abuild was broken. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/include/pc80/mc146818rtc.h trunk/src/mainboard/amd/dbm690t/Kconfig trunk/src/pc80/Makefile.inc trunk/src/pc80/mc146818rtc.c trunk/src/pc80/mc146818rtc_early.c Modified: trunk/src/include/pc80/mc146818rtc.h ============================================================================== --- trunk/src/include/pc80/mc146818rtc.h Wed Sep 1 23:03:03 2010 (r5763) +++ trunk/src/include/pc80/mc146818rtc.h Thu Sep 2 20:29:31 2010 (r5764) @@ -81,6 +81,14 @@ #define PC_CKS_RANGE_END 45 #define PC_CKS_LOC 46 +/* coreboot cmos checksum is usually only built over bytes 49..125 + * LB_CKS_RANGE_START, LB_CKS_RANGE_END and LB_CKS_LOC are defined + * in option_table.h + */ +#if CONFIG_HAVE_OPTION_TABLE +#include +#endif + #ifndef UTIL_BUILD_OPTION_TABLE #include static inline unsigned char cmos_read(unsigned char addr) Modified: trunk/src/mainboard/amd/dbm690t/Kconfig ============================================================================== --- trunk/src/mainboard/amd/dbm690t/Kconfig Wed Sep 1 23:03:03 2010 (r5763) +++ trunk/src/mainboard/amd/dbm690t/Kconfig Thu Sep 2 20:29:31 2010 (r5764) @@ -25,6 +25,12 @@ string default amd/dbm690t +# This is a temporary fix, and should be removed when the race condition for +# building option_table.h is fixed. +config WARNINGS_ARE_ERRORS + bool + default n + config DCACHE_RAM_BASE hex default 0xc8000 Modified: trunk/src/pc80/Makefile.inc ============================================================================== --- trunk/src/pc80/Makefile.inc Wed Sep 1 23:03:03 2010 (r5763) +++ trunk/src/pc80/Makefile.inc Thu Sep 2 20:29:31 2010 (r5764) @@ -8,4 +8,3 @@ subdirs-y += vga $(obj)/pc80/mc146818rtc.o : $(OPTION_TABLE_H) -$(obj)/pc80/mc146818rtc_early.initobj.o : $(OPTION_TABLE_H) Modified: trunk/src/pc80/mc146818rtc.c ============================================================================== --- trunk/src/pc80/mc146818rtc.c Wed Sep 1 23:03:03 2010 (r5763) +++ trunk/src/pc80/mc146818rtc.c Thu Sep 2 20:29:31 2010 (r5764) @@ -2,9 +2,6 @@ #include #include #include -#if CONFIG_USE_OPTION_TABLE -#include -#endif /* control registers - Moto names */ Modified: trunk/src/pc80/mc146818rtc_early.c ============================================================================== --- trunk/src/pc80/mc146818rtc_early.c Wed Sep 1 23:03:03 2010 (r5763) +++ trunk/src/pc80/mc146818rtc_early.c Thu Sep 2 20:29:31 2010 (r5764) @@ -1,10 +1,6 @@ #include #include -#if CONFIG_USE_OPTION_TABLE -#include -#endif - #ifndef CONFIG_MAX_REBOOT_CNT #error "CONFIG_MAX_REBOOT_CNT not defined" #endif From svn at coreboot.org Thu Sep 2 20:36:29 2010 From: svn at coreboot.org (repository service) Date: Thu, 02 Sep 2010 20:36:29 +0200 Subject: [coreboot] [commit] r5765 - trunk/util/abuild Message-ID: Author: myles Date: Thu Sep 2 20:36:29 2010 New Revision: 5765 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5765 Log: Fix abuild to build all boards. Revision 5754 changed the way vendors and boards were specified in Kconfig, and abuild depended on that. Since that rev it has only built qemu. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/util/abuild/abuild Modified: trunk/util/abuild/abuild ============================================================================== --- trunk/util/abuild/abuild Thu Sep 2 20:29:31 2010 (r5764) +++ trunk/util/abuild/abuild Thu Sep 2 20:36:29 2010 (r5765) @@ -166,9 +166,9 @@ else printf " Creating config file... " xml " autogenerated" - grep "depends[\t ]on[\t ]*VENDOR" src/mainboard/$VENDOR/$MAINBOARD/../Kconfig | \ + grep "if[\t ]*VENDOR" src/mainboard/$VENDOR/$MAINBOARD/../Kconfig | \ sed "s,^.*\(VENDOR_.*\)[^A-Z0-9_]*,CONFIG_\1=y," > .config - grep "config[\t ]*BOARD" src/mainboard/$VENDOR/$MAINBOARD/Kconfig | \ + grep "if[\t ]*BOARD" src/mainboard/$VENDOR/$MAINBOARD/Kconfig | \ sed "s,^.*\(BOARD_.*\)[^A-Z0-9_]*,CONFIG_\1=y," >> .config grep "select[\t ]*ARCH" src/mainboard/$VENDOR/$MAINBOARD/Kconfig | \ sed "s,^.*\(ARCH_.*\)[^A-Z0-9_]*,CONFIG_\1=y," >> .config From svn at coreboot.org Thu Sep 2 20:43:39 2010 From: svn at coreboot.org (repository service) Date: Thu, 02 Sep 2010 20:43:39 +0200 Subject: [coreboot] build service results for r5764 Message-ID: Dear coreboot readers! This is the automatic build system of coreboot. The developer "myles" checked in revision 5764 to the coreboot repository. This caused the following changes: Change Log: Revert 5762. It silently broke a lot of boards because abuild was broken. Signed-off-by: Myles Watson Acked-by: Myles Watson Build Log: Compilation of a-trend:atc-6220 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5764&device=atc-6220&vendor=a-trend&num=2 If something broke during this checkin please be a pain in myles'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 From mylesgw at gmail.com Thu Sep 2 20:44:10 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 2 Sep 2010 12:44:10 -0600 Subject: [coreboot] revision 5762 change causing AMD Tilapia build to fail In-Reply-To: References: Message-ID: On Thu, Sep 2, 2010 at 11:56 AM, Scott wrote: > Hello, > > The include file change of rev 5762 is causing the AMD Tilapia > build to fail for me. The work-around I found is to add: Thanks for the report; rev 5765 should work. Thanks, Myles From scott at notabs.org Thu Sep 2 20:50:45 2010 From: scott at notabs.org (Scott) Date: Thu, 2 Sep 2010 13:50:45 -0500 Subject: [coreboot] revision 5762 change causing AMD Tilapia build tofail In-Reply-To: References: Message-ID: -----Original Message----- From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Myles Watson Sent: Thursday, September 02, 2010 01:44 PM To: Scott Cc: coreboot at coreboot.org Subject: Re: [coreboot] revision 5762 change causing AMD Tilapia build tofail On Thu, Sep 2, 2010 at 11:56 AM, Scott wrote: > Hello, > > The include file change of rev 5762 is causing the AMD Tilapia > build to fail for me. The work-around I found is to add: Thanks for the report; rev 5765 should work. Thanks, Myles -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Hello Myles, Thanks, it works now. Thanks, Scott From svn at coreboot.org Thu Sep 2 21:07:20 2010 From: svn at coreboot.org (repository service) Date: Thu, 02 Sep 2010 21:07:20 +0200 Subject: [coreboot] build service results for r5765 Message-ID: Dear coreboot readers! This is the automatic build system of coreboot. The developer "myles" checked in revision 5765 to the coreboot repository. This caused the following changes: Change Log: Fix abuild to build all boards. Revision 5754 changed the way vendors and boards were specified in Kconfig, and abuild depended on that. Since that rev it has only built qemu. Signed-off-by: Myles Watson Acked-by: Myles Watson Build Log: Compilation of a-trend:atc-6220 has been fixed Compilation of digitallogic:adl855pc has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5765&device=adl855pc&vendor=digitallogic&num=2 Compilation of intel:mtarvon has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5765&device=mtarvon&vendor=intel&num=2 Compilation of lanner:em8510 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5765&device=em8510&vendor=lanner&num=2 If something broke during this checkin please be a pain in myles'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 From svn at coreboot.org Thu Sep 2 22:30:32 2010 From: svn at coreboot.org (repository service) Date: Thu, 02 Sep 2010 22:30:32 +0200 Subject: [coreboot] [commit] r5766 - trunk/src/northbridge/intel/i855 Message-ID: Author: myles Date: Thu Sep 2 22:30:31 2010 New Revision: 5766 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5766 Log: Trivial warning fix for adl855pc. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/northbridge/intel/i855/raminit.c Modified: trunk/src/northbridge/intel/i855/raminit.c ============================================================================== --- trunk/src/northbridge/intel/i855/raminit.c Thu Sep 2 20:36:29 2010 (r5765) +++ trunk/src/northbridge/intel/i855/raminit.c Thu Sep 2 22:30:31 2010 (r5766) @@ -872,10 +872,14 @@ static void spd_update(const struct mem_controller *ctrl, u8 reg, u32 new_value) { +#if CONFIG_DEBUG_RAM_SETUP u32 value1 = pci_read_config32(ctrl->d0, reg); +#endif pci_write_config32(ctrl->d0, reg, new_value); +#if CONFIG_DEBUG_RAM_SETUP u32 value2 = pci_read_config32(ctrl->d0, reg); PRINTK_DEBUG("update reg %02x, old: %08x, new: %08x, read back: %08x\n", reg, value1, new_value, value2); +#endif } /* if ram still doesn't work do this function */ From svn at coreboot.org Thu Sep 2 22:49:58 2010 From: svn at coreboot.org (repository service) Date: Thu, 02 Sep 2010 22:49:58 +0200 Subject: [coreboot] build service results for r5766 Message-ID: Dear coreboot readers! This is the automatic build system of coreboot. The developer "myles" checked in revision 5766 to the coreboot repository. This caused the following changes: Change Log: Trivial warning fix for adl855pc. Signed-off-by: Myles Watson Acked-by: Myles Watson Build Log: Compilation of digitallogic:adl855pc has been fixed Compilation of intel:mtarvon is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5766&device=mtarvon&vendor=intel&num=2 Compilation of lanner:em8510 has been fixed If something broke during this checkin please be a pain in myles'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 From scott at notabs.org Thu Sep 2 23:03:35 2010 From: scott at notabs.org (Scott) Date: Thu, 2 Sep 2010 16:03:35 -0500 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <0703EF8685AB4BB091774844213B7DF6@m3a78> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> Message-ID: <1446358636964B60A97BC93F7ACA5FDC@m3a78> Signed-off-by: Scott Duplichan The attached patch allows the use of gcc 4.5.0 for AMD builds. The AMD Tilapia BIOS built with gcc 4.5.0 and this patch has passed testing on the simnow target only. Can someone confirm that the attached patch allows an AMD family 10h BIOS such as Tilapia to work on real hardware? At the same time I will try to get the change tested on real hardware. Root cause: After function STOP_CAR_AND_CPU disables cache as ram, the cache as ram stack can no longer be used. Called functions must be inlined to avoid stack usage. Also, the compiler must keep local variables register based and not allocated them from the stack. With gcc 4.5.0, some functions declared as inline are not being inlined. This patch forces these functions to always be inlined by adding the qualifier __attribute__((always_inline)) to their declaration. Thanks, Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: amd-gcc-450.patch Type: application/octet-stream Size: 1251 bytes Desc: not available URL: From mylesgw at gmail.com Thu Sep 2 23:42:50 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 2 Sep 2010 15:42:50 -0600 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <1446358636964B60A97BC93F7ACA5FDC@m3a78> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <1446358636964B60A97BC93F7ACA5FDC@m3a78> Message-ID: > Root cause: After function STOP_CAR_AND_CPU disables cache as > ram, the cache as ram stack can no longer be used. Called > functions must be inlined to avoid stack usage. Also, the > compiler must keep local variables register based and not > allocated them from the stack. With gcc 4.5.0, some functions > declared as inline are not being inlined. This patch forces > these functions to always be inlined by adding the qualifier > __attribute__((always_inline)) to their declaration. Should we do something like #define INLINE __attribute__((always_inline)) and replace all (or most) inline directives with INLINE? There are probably other places where the code depends on inline working. Thanks, Myles From peter at stuge.se Thu Sep 2 23:51:58 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 2 Sep 2010 23:51:58 +0200 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <1446358636964B60A97BC93F7ACA5FDC@m3a78> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <1446358636964B60A97BC93F7ACA5FDC@m3a78> Message-ID: <20100902215158.3574.qmail@stuge.se> Scott wrote: > The AMD Tilapia BIOS built with gcc 4.5.0 Please keep in mind that coreboot is not a BIOS. Some/many use the term BIOS to mean any firmware, but since coreboot only does one part of what a BIOS would do I think it's important to keep the two terms separate. There are e.g. no interrupt services at all in coreboot, and the generic payload interface in coreboot are IMO distinguishing features for coreboot, making it difficult to equate coreboot with a BIOS. If coreboot is used together with a SeaBIOS payload in a system then there is certainly a BIOS, but that would be SeaBIOS then. //Peter From svn at coreboot.org Fri Sep 3 00:02:54 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 00:02:54 +0200 Subject: [coreboot] [commit] r5767 - trunk/src/mainboard/intel/mtarvon Message-ID: Author: myles Date: Fri Sep 3 00:02:53 2010 New Revision: 5767 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5767 Log: Fix compilation for mtarvon. CAR initialization does early_mtrr_init, jarell/debug.c isn't ready for gcc, and skip_romstage() doesn't compile. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/mainboard/intel/mtarvon/romstage.c Modified: trunk/src/mainboard/intel/mtarvon/romstage.c ============================================================================== --- trunk/src/mainboard/intel/mtarvon/romstage.c Thu Sep 2 22:30:31 2010 (r5766) +++ trunk/src/mainboard/intel/mtarvon/romstage.c Fri Sep 3 00:02:53 2010 (r5767) @@ -33,7 +33,6 @@ #include "southbridge/intel/i3100/i3100_early_lpc.c" #include "northbridge/intel/i3100/raminit.h" #include "superio/intel/i3100/i3100.h" -#include "cpu/x86/lapic/boot_cpu.c" #include "cpu/x86/mtrr/earlymtrr.c" #include "superio/intel/i3100/i3100_early_serial.c" #include "northbridge/intel/i3100/memory_initialized.c" @@ -52,10 +51,11 @@ #include "northbridge/intel/i3100/raminit.c" #include "lib/generic_sdram.c" -#include "../jarrell/debug.c" +#if 0 /* skip_romstage doesn't compile with gcc */ #include "arch/i386/lib/stages.c" +#endif -static void main(unsigned long bist) +void main(unsigned long bist) { msr_t msr; u16 perf; @@ -72,11 +72,12 @@ }; if (bist == 0) { +#if 0 /* skip_romstage doesn't compile with gcc */ /* Skip this if there was a built in self test failure */ - early_mtrr_init(); if (memory_initialized()) { skip_romstage(); } +#endif } /* Set up the console */ i3100_enable_superio(); From svn at coreboot.org Fri Sep 3 00:21:04 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 00:21:04 +0200 Subject: [coreboot] build service results for r5767 Message-ID: Dear coreboot readers! This is the automatic build system of coreboot. The developer "myles" checked in revision 5767 to the coreboot repository. This caused the following changes: Change Log: Fix compilation for mtarvon. CAR initialization does early_mtrr_init, jarell/debug.c isn't ready for gcc, and skip_romstage() doesn't compile. Signed-off-by: Myles Watson Acked-by: Myles Watson Build Log: Compilation of intel:mtarvon has been fixed If something broke during this checkin please be a pain in myles'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 From peter at stuge.se Fri Sep 3 00:32:57 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 3 Sep 2010 00:32:57 +0200 Subject: [coreboot] util directory In-Reply-To: <4C7B96D0.1000206@coresystems.de> References: <4C7B96D0.1000206@coresystems.de> Message-ID: <20100902223257.8867.qmail@stuge.se> Stefan Reinauer wrote: > abuild .. > > Are they necessary for building a coreboot image? > yes. Hm - is that true? It's also possible to build by running make manually. //Peter From paulepanter at users.sourceforge.net Fri Sep 3 00:45:49 2010 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Fri, 03 Sep 2010 00:45:49 +0200 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <79BDD6CE91A9470CBB707288E08DE90C@m3a78> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <1283417989.3990.4.camel@mattotaupa> <1283418665.3990.5.camel@mattotaupa> <79BDD6CE91A9470CBB707288E08DE90C@m3a78> Message-ID: <1283467549.13822.28.camel@mattotaupa> Dear Scott, Am Donnerstag, den 02.09.2010, 16:06 -0500 schrieb Scott: > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Paul Menzel > Sent: Thursday, September 02, 2010 04:11 AM > To: coreboot at coreboot.org > Subject: Re: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' > Am Donnerstag, den 02.09.2010, 10:59 +0200 schrieb Paul Menzel: > > Am Donnerstag, den 02.09.2010, 00:40 -0500 schrieb Scott: > > > > > The subversion comment for -r 5571 states: > > > > > > The AMD Fam10 code breaks with coreboot 4.5.0. > > > Potentially caused by reordering. Going back to 4.4.4 > > > which is known working on Fam10 until gcc or the Fam10 code is fixed. > > > > > > Signed-off-by: Stefan Reinauer > > > Acked-by: Stefan Reinauer > > > > > > > > > I encountered the same problem and debugged it. The AP code that disables > > > cache as ram before the final halt has to be all inline. Function calls > > > require a valid stack, and the stack is kept in the very cache as ram that > > > the code is disabling. I found with gcc 450, the code for rdmsr, disable_cache, > > > and enable_cache and not getting inlined as intended. Function calls are > > > > s/and/are/ > > > > > generated, and the first one after the AP clears msr 268 fails. The solution > > > is to force these functions to generate inline code by adding > > > __attribute__((always_inline)) to their declarations: > > > > great find!!! Could you please send a patch according to the development > > guidelines. Especially do not forget to add your Signed-off-by line. > > They are documented in the Wiki [1]. > > > Just to leave no doubt, could you please add that you tested your fix > > using GCC 4.5.0 with the used hardware. > > > > [.] > OK, I resubmitted it. Currently tested on simnow only. I will make a > Tilapia binary and ask the AMD guys to test it. By the way, the patch > file has Windows style line endings. I wonder if others can use it easily... I guess next time this message should go to the list since it contains information interesting to the others too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From paulepanter at users.sourceforge.net Fri Sep 3 00:52:47 2010 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Fri, 03 Sep 2010 00:52:47 +0200 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <1283467549.13822.28.camel@mattotaupa> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <1283417989.3990.4.camel@mattotaupa> <1283418665.3990.5.camel@mattotaupa> <79BDD6CE91A9470CBB707288E08DE90C@m3a78> <1283467549.13822.28.camel@mattotaupa> Message-ID: <1283467967.13822.33.camel@mattotaupa> Dear Scott, Am Freitag, den 03.09.2010, 00:45 +0200 schrieb Paul Menzel: > Am Donnerstag, den 02.09.2010, 16:06 -0500 schrieb Scott: > > -----Original Message----- > > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Paul Menzel > > Sent: Thursday, September 02, 2010 04:11 AM > > To: coreboot at coreboot.org > > Subject: Re: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' > > > Am Donnerstag, den 02.09.2010, 10:59 +0200 schrieb Paul Menzel: > > > Am Donnerstag, den 02.09.2010, 00:40 -0500 schrieb Scott: > > > > > > > The subversion comment for -r 5571 states: > > > > > > > > The AMD Fam10 code breaks with coreboot 4.5.0. > > > > Potentially caused by reordering. Going back to 4.4.4 > > > > which is known working on Fam10 until gcc or the Fam10 code is fixed. > > > > > > > > Signed-off-by: Stefan Reinauer > > > > Acked-by: Stefan Reinauer > > > > > > > > > > > > I encountered the same problem and debugged it. The AP code that disables > > > > cache as ram before the final halt has to be all inline. Function calls > > > > require a valid stack, and the stack is kept in the very cache as ram that > > > > the code is disabling. I found with gcc 450, the code for rdmsr, disable_cache, > > > > and enable_cache and not getting inlined as intended. Function calls are > > > > > > s/and/are/ > > > > > > > generated, and the first one after the AP clears msr 268 fails. The solution > > > > is to force these functions to generate inline code by adding > > > > __attribute__((always_inline)) to their declarations: > > > > > > great find!!! Could you please send a patch according to the development > > > guidelines. Especially do not forget to add your Signed-off-by line. > > > > They are documented in the Wiki [1]. > > > > > Just to leave no doubt, could you please add that you tested your fix > > > using GCC 4.5.0 with the used hardware. > > > > > > [.] > > > OK, I resubmitted it. Currently tested on simnow only. I will make a > > Tilapia binary and ask the AMD guys to test it. By the way, the patch > > file has Windows style line endings. I wonder if others can use it easily... > > I guess next time this message should go to the list since it contains > information interesting to the others too. [I hit ?Sent? too early. I am sorry!] ? therefore I am replying to the list again. I hope other will have time to test this. We will see if the developers have a problem when committing your patch. If yes, I guess Patrick can give you a hint on how to circumvent this problem. Thanks, Paul PS: Do you know if you can configure Outlook to use a style when replying similar to everyone else is using on this list, i. e. use a line ?Joe Doe wrote on ?? and afterward quoting everything by putting ?>? in front of every line? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From svn at coreboot.org Fri Sep 3 10:53:07 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 10:53:07 +0200 Subject: [coreboot] [commit] r5768 - in trunk/util/crossgcc: . patches Message-ID: Author: oxygene Date: Fri Sep 3 10:53:06 2010 New Revision: 5768 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5768 Log: The current workaround for binutils on mingw (or any non texinfo system) failed. While we're at it, improve DESTDIR handling Signed-off-by: Patrick Georgi Acked-by: Patrick Georgi Added: trunk/util/crossgcc/patches/binutils-2.20.1_no-bfd-doc.patch Modified: trunk/util/crossgcc/buildgcc Modified: trunk/util/crossgcc/buildgcc ============================================================================== --- trunk/util/crossgcc/buildgcc Fri Sep 3 00:02:53 2010 (r5767) +++ trunk/util/crossgcc/buildgcc Fri Sep 3 10:53:06 2010 (r5768) @@ -372,9 +372,6 @@ else printf "Building binutils ${BINUTILS_VERSION} ... " ( - # workaround for building binutils 2.20.1 on MINGW: - touch binutils-${BINUTILS_VERSION}/bfd/doc/bfd.info - # now build binutils cd build-binutils rm -f .failed ../binutils-${BINUTILS_VERSION}/configure --prefix=$TARGETDIR --target=${TARGETARCH} \ @@ -394,6 +391,7 @@ printf "Building GCC ${GCC_VERSION} ... " ( cd build-gcc + export PATH=$PATH:$DESTDIR$TARGETDIR/bin rm -f .failed # GCC does not honour HOSTCFLAGS at all. CFLAGS are used for # both target and host object files. This is pretty misdesigned. @@ -423,7 +421,7 @@ printf "Building GDB ${GDB_VERSION} ... " ( cd build-gdb - export PATH=$PATH:$PREFIX/bin + export PATH=$PATH:$DESTDIR$TARGETDIR/bin rm -f .failed CFLAGS="$HOSTCFLAGS" ../gdb-${GDB_VERSION}/configure --prefix=$TARGETDIR --target=${TARGETARCH} \ --without-python --disable-werror --disable-nls Added: trunk/util/crossgcc/patches/binutils-2.20.1_no-bfd-doc.patch ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/util/crossgcc/patches/binutils-2.20.1_no-bfd-doc.patch Fri Sep 3 10:53:06 2010 (r5768) @@ -0,0 +1,11 @@ +--- binutils-2.20.1/bfd/Makefile.in~ 2010-07-25 10:56:45 +0000 ++++ binutils-2.20.1/bfd/Makefile.in 2010-07-25 10:19:24 +0000 +@@ -320,7 +320,7 @@ + # RELEASE=y + INCDIR = $(srcdir)/../include + CSEARCH = -I. -I$(srcdir) -I$(INCDIR) +-SUBDIRS = doc po ++SUBDIRS = po + bfddocdir = doc + libbfd_la_LDFLAGS = $(am__append_1) -release `cat libtool-soversion` \ + @SHARED_LDFLAGS@ $(am__empty) From svn at coreboot.org Fri Sep 3 10:57:33 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 10:57:33 +0200 Subject: [coreboot] [commit] r5769 - trunk Message-ID: Author: oxygene Date: Fri Sep 3 10:57:32 2010 New Revision: 5769 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5769 Log: Add convenience rules for cscope to Makefile. Signed-off-by: Warren Turkal Acked-by: Patrick Georgi Modified: trunk/Makefile Modified: trunk/Makefile ============================================================================== --- trunk/Makefile Fri Sep 3 10:53:06 2010 (r5768) +++ trunk/Makefile Fri Sep 3 10:57:32 2010 (r5769) @@ -330,6 +330,9 @@ printf "#endif\n" >> $(obj)/build.ht mv $(obj)/build.ht $(obj)/build.h +cscope: + cscope -bR + doxy: doxygen doxygen: $(DOXYGEN) documentation/Doxyfile.coreboot @@ -354,7 +357,10 @@ clean: clean-for-update rm -f $(obj)/coreboot* .ccwrap -distclean: +clean-cscope: + rm -f cscope.out + +distclean: clean-cscope rm -rf $(obj) rm -f .config .config.old ..config.tmp .kconfig.d .tmpconfig* .ccwrap .xcompile @@ -383,5 +389,5 @@ @# http://www.coreboot.org/pipermail/coreboot/2010-February/055825.html $(HOSTCC) -g $(STACK) -Wall -o $@ $< -.PHONY: $(PHONY) clean distclean doxygen doxy coreboot .xcompile +.PHONY: $(PHONY) clean clean-cscope cscope distclean doxygen doxy coreboot .xcompile From svn at coreboot.org Fri Sep 3 11:31:13 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 11:31:13 +0200 Subject: [coreboot] [commit] r5770 - trunk/util/inteltool Message-ID: Author: oxygene Date: Fri Sep 3 11:31:13 2010 New Revision: 5770 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5770 Log: Add DMIBAR support for Intel X58 southbridge Signed-off-by: Warren Turkal Acked-by: Patrick Georgi Modified: trunk/util/inteltool/pcie.c Modified: trunk/util/inteltool/pcie.c ============================================================================== --- trunk/util/inteltool/pcie.c Fri Sep 3 10:57:32 2010 (r5769) +++ trunk/util/inteltool/pcie.c Fri Sep 3 11:31:13 2010 (r5770) @@ -114,6 +114,9 @@ case PCI_DEVICE_ID_INTEL_82810E_MC: printf("This northbrigde does not have DMIBAR.\n"); return 1; + case PCI_DEVICE_ID_INTEL_X58: + dmibar_phys = pci_read_long(nb, 0x50) & 0xfffff000; + break; default: printf("Error: Dumping DMIBAR on this northbridge is not (yet) supported.\n"); return 1; From svn at coreboot.org Fri Sep 3 11:32:18 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 11:32:18 +0200 Subject: [coreboot] [commit] r5771 - trunk/util/inteltool Message-ID: Author: oxygene Date: Fri Sep 3 11:32:17 2010 New Revision: 5771 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5771 Log: Remove some errant spaces Signed-off-by: Warren Turkal Acked-by: Patrick Georgi Modified: trunk/util/inteltool/pcie.c Modified: trunk/util/inteltool/pcie.c ============================================================================== --- trunk/util/inteltool/pcie.c Fri Sep 3 11:31:13 2010 (r5770) +++ trunk/util/inteltool/pcie.c Fri Sep 3 11:32:17 2010 (r5771) @@ -98,17 +98,17 @@ case PCI_DEVICE_ID_INTEL_82975X: dmibar_phys = pci_read_long(nb, 0x4c) & 0xfffffffe; break; - case PCI_DEVICE_ID_INTEL_PM965: + case PCI_DEVICE_ID_INTEL_PM965: case PCI_DEVICE_ID_INTEL_Q965: - case PCI_DEVICE_ID_INTEL_82Q35: - case PCI_DEVICE_ID_INTEL_82G33: - case PCI_DEVICE_ID_INTEL_82Q33: + case PCI_DEVICE_ID_INTEL_82Q35: + case PCI_DEVICE_ID_INTEL_82G33: + case PCI_DEVICE_ID_INTEL_82Q33: case PCI_DEVICE_ID_INTEL_GS45: case PCI_DEVICE_ID_INTEL_ATOM_DXXX: case PCI_DEVICE_ID_INTEL_ATOM_NXXX: - dmibar_phys = pci_read_long(nb, 0x68) & 0xfffffffe; - dmibar_phys |= ((uint64_t)pci_read_long(nb, 0x6c)) << 32; - break; + dmibar_phys = pci_read_long(nb, 0x68) & 0xfffffffe; + dmibar_phys |= ((uint64_t)pci_read_long(nb, 0x6c)) << 32; + break; case PCI_DEVICE_ID_INTEL_82810: case PCI_DEVICE_ID_INTEL_82810DC: case PCI_DEVICE_ID_INTEL_82810E_MC: From svn at coreboot.org Fri Sep 3 11:33:53 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 11:33:53 +0200 Subject: [coreboot] [commit] r5772 - trunk/util/inteltool Message-ID: Author: oxygene Date: Fri Sep 3 11:33:50 2010 New Revision: 5772 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5772 Log: Add support for dumping RCBA registers for i7 Signed-off-by: Warren Turkal Acked-by: Patrick Georgi Modified: trunk/util/inteltool/rootcmplx.c Modified: trunk/util/inteltool/rootcmplx.c ============================================================================== --- trunk/util/inteltool/rootcmplx.c Fri Sep 3 11:32:17 2010 (r5771) +++ trunk/util/inteltool/rootcmplx.c Fri Sep 3 11:33:50 2010 (r5772) @@ -36,14 +36,15 @@ case PCI_DEVICE_ID_INTEL_ICH7M: case PCI_DEVICE_ID_INTEL_ICH7DH: case PCI_DEVICE_ID_INTEL_ICH7MDH: + case PCI_DEVICE_ID_INTEL_ICH8: + case PCI_DEVICE_ID_INTEL_ICH8M: case PCI_DEVICE_ID_INTEL_ICH9DH: case PCI_DEVICE_ID_INTEL_ICH9DO: case PCI_DEVICE_ID_INTEL_ICH9R: case PCI_DEVICE_ID_INTEL_ICH9: case PCI_DEVICE_ID_INTEL_ICH9M: case PCI_DEVICE_ID_INTEL_ICH9ME: - case PCI_DEVICE_ID_INTEL_ICH8M: - case PCI_DEVICE_ID_INTEL_ICH8: + case PCI_DEVICE_ID_INTEL_ICH10R: case PCI_DEVICE_ID_INTEL_NM10: rcba_phys = pci_read_long(sb, 0xf0) & 0xfffffffe; break; From svn at coreboot.org Fri Sep 3 11:36:38 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 11:36:38 +0200 Subject: [coreboot] [commit] r5773 - trunk/util/inteltool Message-ID: Author: oxygene Date: Fri Sep 3 11:36:37 2010 New Revision: 5773 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5773 Log: Add support for dumping ACPI registers for i7 Signed-off-by: Warren Turkal Acked-by: Patrick Georgi Modified: trunk/util/inteltool/powermgt.c Modified: trunk/util/inteltool/powermgt.c ============================================================================== --- trunk/util/inteltool/powermgt.c Fri Sep 3 11:33:50 2010 (r5772) +++ trunk/util/inteltool/powermgt.c Fri Sep 3 11:36:37 2010 (r5773) @@ -21,6 +21,66 @@ #include #include "inteltool.h" +static const io_register_t ich10_pm_registers[] = { + { 0x00, 2, "PM1_STS" }, // PM1 Status; ACPI pointer: PM1a_EVT_BLK + { 0x02, 2, "PM1_EN" }, // PM1 Enables; ACPI pointer: PM1a_EVT_BLK+2 + { 0x04, 4, "PM1_CNT" }, // PM1 Control; ACPI pointer: PM1a_CNT_BLK + { 0x08, 4, "PM1_TMR" }, // PM1 Timer; ACPI pointer: PMTMR_BLK + { 0x0c, 4, "RESERVED" }, + { 0x10, 4, "PROC_CNT" }, // Processor Control; ACPI pointer: P_BLK +#if DANGEROUS_REGISTERS + /* These registers return 0 on read, but reading them may cause + * the system to enter Cx states, which might hang the system. + */ + { 0x14, 1, "LV2 (Mobile)" }, + { 0x15, 1, "LV3 (Mobile)" }, + { 0x16, 1, "LV4 (Mobile)" }, +#endif + { 0x17, 2, "RESERVED" }, + { 0x19, 1, "RESERVED" }, + { 0x1a, 2, "RESERVED" }, + { 0x1c, 4, "RESERVED" }, + { 0x20, 8, "GPE0_STS" }, // General Purpose Event 0 Status; ACPI pointer: GPE0_BLK + { 0x2C, 4, "GPE0_EN" }, // General Purpose Event 0 Enables; ACPI pointer: GPE0_BLK+8 + { 0x30, 4, "SMI_EN" }, + { 0x34, 4, "SMI_STS" }, + { 0x38, 2, "ALT_GP_SMI_EN" }, + { 0x3a, 2, "ALT_GP_SMI_STS" }, + { 0x3c, 1, "UPRWC" }, // USB Per-Port registers write control; + { 0x3d, 2, "RESERVED" }, + { 0x3f, 1, "RESERVED" }, + { 0x40, 2, "RESERVED" }, + { 0x42, 1, "GPE_CNTL" }, + { 0x43, 1, "RESERVED" }, + { 0x44, 2, "DEVACT_STS" }, // Device Activity Status + { 0x46, 2, "RESERVED" }, + { 0x48, 4, "RESERVED" }, + { 0x4c, 4, "RESERVED" }, + { 0x50, 1, "PM2_CNT (Mobile)" }, // PM2 Control (Mobile only); ACPI pointer: PM2a_CNT_BLK + { 0x51, 1, "RESERVED" }, + { 0x52, 2, "RESERVED" }, + { 0x54, 4, "C3_RES (Mobile)" }, + { 0x58, 4, "RESERVED" }, + { 0x5c, 4, "RESERVED" }, + /* Here start the TCO registers */ + { 0x60, 2, "TCO_RLD" }, + { 0x62, 1, "TCO_DAT_IN" }, + { 0x63, 1, "TCO_DAT_OUT" }, + { 0x64, 2, "TCO1_STS" }, + { 0x66, 2, "TCO2_STS" }, + { 0x68, 2, "TCO1_CNT" }, + { 0x6a, 2, "TCO2_CNT" }, + { 0x6c, 2, "TCO_MESSAGE" }, + { 0x6e, 1, "TCO_WDCNT" }, + { 0x6f, 1, "RESERVED" }, + { 0x70, 1, "SW_IRQ_GEN" }, + { 0x71, 1, "RESERVED" }, + { 0x72, 2, "TCO_TMR" }, + { 0x74, 4, "RESERVED" }, + { 0x78, 4, "RESERVED" }, + { 0x7c, 4, "RESERVED" }, +}; + static const io_register_t ich9_pm_registers[] = { { 0x00, 2, "PM1_STS" }, // PM1 Status; ACPI pointer: PM1a_EVT_BLK { 0x02, 2, "PM1_EN" }, // PM1 Enables; ACPI pointer: PM1a_EVT_BLK+2 @@ -473,6 +533,11 @@ printf("\n============= PMBASE ============\n\n"); switch (sb->device_id) { + case PCI_DEVICE_ID_INTEL_ICH10R: + pmbase = pci_read_word(sb, 0x40) & 0xff80; + pm_registers = ich10_pm_registers; + size = ARRAY_SIZE(ich10_pm_registers); + break; case PCI_DEVICE_ID_INTEL_ICH7: case PCI_DEVICE_ID_INTEL_ICH7M: case PCI_DEVICE_ID_INTEL_ICH7DH: From JRottmann at LiPPERTEmbedded.de Fri Sep 3 11:47:01 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Fri, 03 Sep 2010 11:47:01 +0200 Subject: [coreboot] [PATCH] sync Road-/SpaceRunner with current standard BIOSes Message-ID: <4C80C415.9000301@LiPPERTEmbedded.de> Update RoadRunner and SpaceRunner config to get in sync with current standard BIOSes RRLX0013 and SRLX0013. Specifically move SPI and PME I/Os to 0x1228 and 0x298 and switch SIO watchdog to ext. 48 MHz CLKIN. Signed-off-by: Jens Rottmann --- --- src/mainboard/lippert/roadrunner-lx/devicetree.cb (rev 5767) +++ src/mainboard/lippert/roadrunner-lx/devicetree.cb (working copy) @@ -48,8 +48,8 @@ irq 0x70 = 7 end device pnp 2e.4 on # EC - io 0x60 = 0x290 - io 0x62 = 0x230 + io 0x60 = 0x290 # EC + io 0x62 = 0x298 # PME irq 0x70 = 9 end device pnp 2e.5 on # PS/2 keyboard @@ -61,8 +61,8 @@ irq 0x70 = 12 end device pnp 2e.7 on # GPIO - io 0x62 = 0x1220 - # io 0x64 = 0x1200 + io 0x62 = 0x1220 # Simple I/O + # io 0x64 = 0x1228 # SPI end device pnp 2e.8 off # MIDI io 0x60 = 0x300 --- src/mainboard/lippert/roadrunner-lx/romstage.c (rev 5767) +++ src/mainboard/lippert/roadrunner-lx/romstage.c (working copy) @@ -63,16 +63,15 @@ static const u16 sio_init_table[] = { // hi=data, lo=index 0x0707, // select LDN 7 (GPIO, SPI, watchdog, ...) - 0x1E2C, // disable ATXPowerGood - will cause a reboot! - 0x0423, // don't delay POWerOK1/2 - 0x9072, // watchdog triggers POWOK, counts seconds + 0x1E2C, // disable ATXPG; VIN6,FAN4/5,VIN3 enabled, VIN7 internal + 0x1423, // don't delay PoWeROK1/2 - triggers 2nd reset + 0x9072, // watchdog triggers PWROK, counts seconds #if !CONFIG_USE_WATCHDOG_ON_BOOT - 0x0073, 0x0074, // disable watchdog by setting timeout to 0 + 0x0073, 0x0074, // disarm watchdog by changing 56 s timeout to 0 #endif 0xBF25, 0x372A, 0xF326, // select GPIO function for most pins 0xBF27, 0xFF28, 0x2529, // (GP36=FAN_CTL3, GP13=PWROK1) - 0x1E2C, // VIN6=enabled?, FAN4/5 enabled, VIN7=internal, VIN3=enabled - 0x46B8, 0x0CB9, // enable pullups + 0x46B8, 0x0CB9, // enable pullups on RS485_EN 0x36C0, // enable Simple-I/O for GP15,14,12,11= LIVE_LED, WD_ACTIVE, RS485_EN2,1 0xFFC3, // enable Simple-I/O for GP47-40 (GPIOs on Supervisory Connector) 0x26C8, // config GP15,12,11 as output; GP14 as input --- src/mainboard/lippert/spacerunner-lx/devicetree.cb (rev 5767) +++ src/mainboard/lippert/spacerunner-lx/devicetree.cb (working copy) @@ -49,8 +49,8 @@ irq 0x70 = 7 end device pnp 2e.4 on # EC - io 0x60 = 0x290 - io 0x62 = 0x230 + io 0x60 = 0x290 # EC + io 0x62 = 0x298 # PME irq 0x70 = 9 end device pnp 2e.5 on # PS/2 keyboard @@ -62,8 +62,8 @@ irq 0x70 = 12 end device pnp 2e.7 on # GPIO - io 0x62 = 0x1220 - io 0x64 = 0x1200 + io 0x62 = 0x1220 # Simple I/O + io 0x64 = 0x1228 # SPI end device pnp 2e.8 off # MIDI io 0x60 = 0x300 --- src/mainboard/lippert/spacerunner-lx/romstage.c (rev 5767) +++ src/mainboard/lippert/spacerunner-lx/romstage.c (working copy) @@ -129,16 +129,15 @@ static const u16 sio_init_table[] = { // hi=data, lo=index 0x0707, // select LDN 7 (GPIO, SPI, watchdog, ...) - 0x1E2C, // disable ATXPowerGood - 0x0423, // don't delay POWerOK1/2 - 0x9072, // watchdog triggers POWOK, counts seconds + 0x072C, // VIN6 enabled, FAN4/5 disabled, VIN7,VIN3 internal + 0x1423, // don't delay PoWeROK1/2 + 0x9072, // watchdog triggers PWROK, counts seconds #if !CONFIG_USE_WATCHDOG_ON_BOOT - 0x0073, 0x0074, // disable watchdog by setting timeout to 0 + 0x0073, 0x0074, // disarm watchdog by changing 56 s timeout to 0 #endif 0xBF25, 0x172A, 0xF326, // select GPIO function for most pins 0xFF27, 0xDF28, 0x2729, // (GP45=SUSB, GP23,22,16,15=SPI, GP13=PWROK1) - 0x072C, // VIN6=enabled?, FAN4/5 disabled, VIN7=internal, VIN3=internal - 0x66B8, 0x0CB9, // enable pullups + 0x66B8, 0x0CB9, // enable pullups on SPI, RS485_EN 0x07C0, // enable Simple-I/O for GP12-10= RS485_EN2,1, LIVE_LED 0x07C8, // config GP12-10 as output 0x2DF5, // map Hw Monitor Thermal Output to GP55 _ From Kerry.She at amd.com Fri Sep 3 12:13:27 2010 From: Kerry.She at amd.com (She, Kerry) Date: Fri, 3 Sep 2010 18:13:27 +0800 Subject: [coreboot] [PATCH 1/2] Amd_ddr2_mct_InitPhyCompensation Message-ID: Hello, AMD DDR2 MCT function InitPhyCompensation() compliant with AGESA code. Signed-off-by: Kerry She -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: amd_ddr_InitPhyCompensation.patch Type: application/octet-stream Size: 661 bytes Desc: amd_ddr_InitPhyCompensation.patch URL: From Kerry.She at amd.com Fri Sep 3 12:14:43 2010 From: Kerry.She at amd.com (She, Kerry) Date: Fri, 3 Sep 2010 18:14:43 +0800 Subject: [coreboot] [PATCH 2/2] Amd_ddr3_mct_InitPhyCompensation Message-ID: Hello, AMD DDR3 MCT function InitPhyCompensation() compliant with AGESA code. Signed-off-by: Kerry She -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: amd_ddr3_InitPhyCompensation.patch Type: application/octet-stream Size: 676 bytes Desc: amd_ddr3_InitPhyCompensation.patch URL: From kevin at koconnor.net Fri Sep 3 14:25:07 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Fri, 3 Sep 2010 08:25:07 -0400 Subject: [coreboot] MS-6147, SeaBIOS, and OpenBSD. In-Reply-To: <20100827092106.GA28159@mea.homelinux.org> References: <20100827092106.GA28159@mea.homelinux.org> Message-ID: <20100903122507.GA30715@morn.localdomain> On Fri, Aug 27, 2010 at 11:21:06AM +0200, Mats Erik Andersson wrote: > Hello again, > > two years have passed since I developed the support for MS-6147. > Now I return to slowly activate myself again. In a first run > I would like to report the following: > > 1. Coreboot-v4.0, svn rev 5740, works well on MSI MS-6147. > > 2. In the overview of supported mainboards, there ought to > be an entry "Y" for MSI MS-6147, stipulating that the > DIL32-ROM is set in a socket. > > 3. SeaBIOS works on MS-6147, but I had to strip down most > functionality in order to fit the combined image into > the 64 kB available (120 byte to spare!) since the > standard fallback duplication was left intact. No VGA > BIOS was included. > > 4. From this minimal SeaBIOS payload, I did successfully > boot into a fully functional OpenBSD 4.4, which I as > always use with a serial console. The disk is a 1GB > Compact Flash card. Wow! Coreboot and seabios in a 64KiB flash - that's pretty impressive. Were you using lzma compression with this? -Kevin From mrtadis at gmail.com Fri Sep 3 14:31:36 2010 From: mrtadis at gmail.com (Tadas S) Date: Fri, 3 Sep 2010 15:31:36 +0300 Subject: [coreboot] DIP32 top hat flash Message-ID: These sockets are good because their pins are hard to bend, so I used it on the bottom of the "pie": http://rocky.digikey.com/weblib/Mill-Max/Web%20Photos/110-13-632-41-001000.jpg This ones pins are easier to bend, so I used them to bend Chip Enable pins. http://www.buyicnow.com/pic/SOCKET/P00001177.jpg If part is deselected (Chip Enable floating), Chip Enable pin should be high, but my flash part doesn't have internal pull-ups, so sometimes during flashing deselected chip was badly flashed. I soldered external 200 kilohm resistors to pull-up both Chip Enable pins. Now it works for me :) I hope someone will have time to update wiki :) Thanks, Tadas -------------- next part -------------- An HTML attachment was scrubbed... URL: From JRottmann at LiPPERTEmbedded.de Fri Sep 3 16:44:40 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Fri, 03 Sep 2010 16:44:40 +0200 Subject: [coreboot] [PATCH] libpayload: scan all PCI functions for USB Message-ID: <4C8109D8.1030100@LiPPERTEmbedded.de> The AMD CS5536's USB controllers are located at device 0F, functions 4 and 5. They're not found if only function 0 is checked. So if a device exists at all, try all its functions. usb_controller_initialize() will silently skip all device classes != 0C03. Signed-off-by: Jens Rottmann --- --- payloads/libpayload/drivers/usb/usbinit.c (rev 5767) +++ payloads/libpayload/drivers/usb/usbinit.c (working copy) @@ -126,7 +126,7 @@ */ for (bus = 0; bus < 256; bus++) for (dev = 0; dev < 32; dev++) - if (pci_read_config32 (PCI_DEV(bus, dev, 0), 8) >> 16 == 0x0c03) + if (pci_read_config16(PCI_DEV(bus, dev, 0), 10) != 0xFFFF) for (func = 7; func >= 0 ; func--) usb_controller_initialize (bus, dev, func); usb_poll(); _ From quatrox at member.fsf.org Fri Sep 3 15:47:13 2010 From: quatrox at member.fsf.org (Flemming Richter Mikkelsen) Date: Fri, 3 Sep 2010 15:47:13 +0200 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <1446358636964B60A97BC93F7ACA5FDC@m3a78> Message-ID: On 2010-09-02, Myles Watson wrote: > > Root cause: After function STOP_CAR_AND_CPU disables cache as > > ram, the cache as ram stack can no longer be used. Called > > functions must be inlined to avoid stack usage. Also, the > > compiler must keep local variables register based and not > > allocated them from the stack. With gcc 4.5.0, some functions > > declared as inline are not being inlined. This patch forces > > these functions to always be inlined by adding the qualifier > > __attribute__((always_inline)) to their declaration. > > Should we do something like > > #define INLINE __attribute__((always_inline)) > > and replace all (or most) inline directives with INLINE? There are > probably other places where the code depends on inline working. gcc supports -Winline and this warning should, if not already, be enabled by default (in the Makefiles). From mylesgw at gmail.com Fri Sep 3 16:46:39 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 3 Sep 2010 08:46:39 -0600 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <1446358636964B60A97BC93F7ACA5FDC@m3a78> Message-ID: On Fri, Sep 3, 2010 at 7:47 AM, Flemming Richter Mikkelsen wrote: > On 2010-09-02, Myles Watson wrote: >> > Root cause: After function STOP_CAR_AND_CPU disables cache as >> > ram, the cache as ram stack can no longer be used. Called >> > functions must be inlined to avoid stack usage. Also, the >> > compiler must keep local variables register based and not >> > allocated them from the stack. With gcc 4.5.0, some functions >> > declared as inline are not being inlined. This patch forces >> > these functions to always be inlined by adding the qualifier >> > __attribute__((always_inline)) to their declaration. >> >> Should we do something like >> >> #define INLINE __attribute__((always_inline)) >> >> and replace all (or most) inline directives with INLINE? ?There are >> probably other places where the code depends on inline working. > > > gcc supports -Winline and this warning should, if not already, be > enabled by default (in the Makefiles). It isn't. Tyan s2895 has 27 warnings just in romstage.c when -Winline is specified. Thanks, Myles From patrick at georgi-clan.de Fri Sep 3 16:48:43 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Fri, 03 Sep 2010 16:48:43 +0200 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <1446358636964B60A97BC93F7ACA5FDC@m3a78> Message-ID: <4C810ACB.3030706@georgi-clan.de> Am 03.09.2010 15:47, schrieb Flemming Richter Mikkelsen: > gcc supports -Winline and this warning should, if not already, be > enabled by default (in the Makefiles). I doubt this option is really very useful. We often inline at places where we advise it, but where there's no harm if it isn't inlined. The code that requires that attribute _requires_ inlining. Given that we use -Werror, -Winline (which is triggered by heuristics) is a really bad idea in my opinion. Regards, Patrick From svn at coreboot.org Fri Sep 3 16:54:51 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 16:54:51 +0200 Subject: [coreboot] [commit] r5774 - trunk/payloads/libpayload/drivers/usb Message-ID: Author: oxygene Date: Fri Sep 3 16:54:50 2010 New Revision: 5774 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5774 Log: The AMD CS5536's USB controllers are located at device 0F, functions 4 and 5. They're not found if only function 0 is checked. So if a device exists at all, try all its functions. usb_controller_initialize() will silently skip all device classes != 0C03. (changed to continue to use 32bit accesses -pg) Signed-off-by: Jens Rottmann Acked-by: Patrick Georgi Modified: trunk/payloads/libpayload/drivers/usb/usbinit.c Modified: trunk/payloads/libpayload/drivers/usb/usbinit.c ============================================================================== --- trunk/payloads/libpayload/drivers/usb/usbinit.c Fri Sep 3 11:36:37 2010 (r5773) +++ trunk/payloads/libpayload/drivers/usb/usbinit.c Fri Sep 3 16:54:50 2010 (r5774) @@ -126,7 +126,7 @@ */ for (bus = 0; bus < 256; bus++) for (dev = 0; dev < 32; dev++) - if (pci_read_config32 (PCI_DEV(bus, dev, 0), 8) >> 16 == 0x0c03) + if (pci_read_config32 (PCI_DEV(bus, dev, 0), 8) >> 16 != 0xffff) for (func = 7; func >= 0 ; func--) usb_controller_initialize (bus, dev, func); usb_poll(); From patrick at georgi-clan.de Fri Sep 3 16:55:15 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Fri, 03 Sep 2010 16:55:15 +0200 Subject: [coreboot] [PATCH] libpayload: scan all PCI functions for USB In-Reply-To: <4C8109D8.1030100@LiPPERTEmbedded.de> References: <4C8109D8.1030100@LiPPERTEmbedded.de> Message-ID: <4C810C53.6010003@georgi-clan.de> Am 03.09.2010 16:44, schrieb Jens Rottmann: > The AMD CS5536's USB controllers are located at device 0F, functions 4 > and 5. They're not found if only function 0 is checked. So if a device > exists at all, try all its functions. usb_controller_initialize() will > silently skip all device classes != 0C03. Oh my.. I suppose that's technically legal. *sigh* Good catch! I kept the access at 32bit, as this is not a 16bit value, and somewhere hidden in some addendum to some obscure PCI standard they certainly require 32bit accesses, with some hardware out there probably relying on conformance to that. If the 32bit access is actually an issue for your hardware, please note so and we can try the change. > Signed-off-by: Jens Rottmann Acked-by: Patrick Georgi and committed in r5774 Thanks, Patrick From JRottmann at LiPPERTEmbedded.de Fri Sep 3 17:13:28 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Fri, 03 Sep 2010 17:13:28 +0200 Subject: [coreboot] CS5536 OHCI not working Message-ID: <4C811098.8010101@LiPPERTEmbedded.de> Hi, is OHCI / USB storage support supposed to be working or is this still very early experimental stuff? If it's known to work only on few supported chipsets yet, then never mind, just ignore me, we don't actually need this, I just fancied giving it a try. But if it's supposed to be mostly working now, you might be interested to hear that this is all I'm getting: FILO version 0.6.0 (root at jensrv) Fri Sep 3 16:49:08 CEST 2010 00:0f.5 2095:1022.5 EHCI controller Not supported. 00:0f.4 2094:1022.4 OHCI controller OHCI Version 1.0 fullspeed device doing control transfer with 0. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8c0, condition: f doing control transfer with 1. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8d0, condition: f doing control transfer with 1. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8d0, condition: f device 0x0951:0x160b is USB 2.0 doing control transfer with 1. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8d0, condition: f doing control transfer with 1. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8d0, condition: f doing control transfer with 1. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8c0, condition: f (MSC) it uses SCSI transparent command set it uses Bulk-Only Transport protocol using endpoint 81 as in, 2 as out doing control transfer with 1. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8d0, condition: f has 1 luns Waiting for device to become ready... bulk: 1f bytes from 233035, finalize: 0, maxpacketsize: 40 doing bulk transfer with 1(2). first_td at f6bf8a0, last f6bf8b0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f bulk: d bytes from 233028, finalize: 1, maxpacketsize: 40 doing bulk transfer with 1(1). first_td at f6bf8a0, last f6bf8b0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f intst: 44; ctrl: b4; cmdst: 4; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f [ ... continues infinitely ... ] I added a counter forcing the loop @ libpayload/drivers/usb/ohci.c:206 to break after 50 repetitions, but this didn't get me anywhere: in the end USB storage would report a complete bogus nr of sectors for my thumb drive. I'd like to be more helpful, but I don't have a clue what this loop is for, or what wait_for_ed() does or who this Ed person is anyway. ;-) Cheers, Jens From svn at coreboot.org Fri Sep 3 17:16:36 2010 From: svn at coreboot.org (repository service) Date: Fri, 03 Sep 2010 17:16:36 +0200 Subject: [coreboot] [commit] r5775 - in trunk/src/mainboard/lippert: roadrunner-lx spacerunner-lx Message-ID: Author: myles Date: Fri Sep 3 17:16:36 2010 New Revision: 5775 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5775 Log: Update RoadRunner and SpaceRunner config to get in sync with current standard BIOSes RRLX0013 and SRLX0013. Specifically move SPI and PME I/Os to 0x1228 and 0x298 and switch SIO watchdog to ext. 48 MHz CLKIN. Signed-off-by: Jens Rottmann Acked-by: Myles Watson Modified: trunk/src/mainboard/lippert/roadrunner-lx/devicetree.cb trunk/src/mainboard/lippert/roadrunner-lx/romstage.c trunk/src/mainboard/lippert/spacerunner-lx/devicetree.cb trunk/src/mainboard/lippert/spacerunner-lx/romstage.c Modified: trunk/src/mainboard/lippert/roadrunner-lx/devicetree.cb ============================================================================== --- trunk/src/mainboard/lippert/roadrunner-lx/devicetree.cb Fri Sep 3 16:54:50 2010 (r5774) +++ trunk/src/mainboard/lippert/roadrunner-lx/devicetree.cb Fri Sep 3 17:16:36 2010 (r5775) @@ -48,8 +48,8 @@ irq 0x70 = 7 end device pnp 2e.4 on # EC - io 0x60 = 0x290 - io 0x62 = 0x230 + io 0x60 = 0x290 # EC + io 0x62 = 0x298 # PME irq 0x70 = 9 end device pnp 2e.5 on # PS/2 keyboard @@ -61,8 +61,8 @@ irq 0x70 = 12 end device pnp 2e.7 on # GPIO - io 0x62 = 0x1220 - # io 0x64 = 0x1200 + io 0x62 = 0x1220 # Simple I/O + # io 0x64 = 0x1228 # SPI end device pnp 2e.8 off # MIDI io 0x60 = 0x300 Modified: trunk/src/mainboard/lippert/roadrunner-lx/romstage.c ============================================================================== --- trunk/src/mainboard/lippert/roadrunner-lx/romstage.c Fri Sep 3 16:54:50 2010 (r5774) +++ trunk/src/mainboard/lippert/roadrunner-lx/romstage.c Fri Sep 3 17:16:36 2010 (r5775) @@ -63,16 +63,15 @@ static const u16 sio_init_table[] = { // hi=data, lo=index 0x0707, // select LDN 7 (GPIO, SPI, watchdog, ...) - 0x1E2C, // disable ATXPowerGood - will cause a reboot! - 0x0423, // don't delay POWerOK1/2 - 0x9072, // watchdog triggers POWOK, counts seconds + 0x1E2C, // disable ATXPG; VIN6,FAN4/5,VIN3 enabled, VIN7 internal + 0x1423, // don't delay PoWeROK1/2 - triggers 2nd reset + 0x9072, // watchdog triggers PWROK, counts seconds #if !CONFIG_USE_WATCHDOG_ON_BOOT - 0x0073, 0x0074, // disable watchdog by setting timeout to 0 + 0x0073, 0x0074, // disarm watchdog by changing 56 s timeout to 0 #endif 0xBF25, 0x372A, 0xF326, // select GPIO function for most pins 0xBF27, 0xFF28, 0x2529, // (GP36=FAN_CTL3, GP13=PWROK1) - 0x1E2C, // VIN6=enabled?, FAN4/5 enabled, VIN7=internal, VIN3=enabled - 0x46B8, 0x0CB9, // enable pullups + 0x46B8, 0x0CB9, // enable pullups on RS485_EN 0x36C0, // enable Simple-I/O for GP15,14,12,11= LIVE_LED, WD_ACTIVE, RS485_EN2,1 0xFFC3, // enable Simple-I/O for GP47-40 (GPIOs on Supervisory Connector) 0x26C8, // config GP15,12,11 as output; GP14 as input Modified: trunk/src/mainboard/lippert/spacerunner-lx/devicetree.cb ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/devicetree.cb Fri Sep 3 16:54:50 2010 (r5774) +++ trunk/src/mainboard/lippert/spacerunner-lx/devicetree.cb Fri Sep 3 17:16:36 2010 (r5775) @@ -49,8 +49,8 @@ irq 0x70 = 7 end device pnp 2e.4 on # EC - io 0x60 = 0x290 - io 0x62 = 0x230 + io 0x60 = 0x290 # EC + io 0x62 = 0x298 # PME irq 0x70 = 9 end device pnp 2e.5 on # PS/2 keyboard @@ -62,8 +62,8 @@ irq 0x70 = 12 end device pnp 2e.7 on # GPIO - io 0x62 = 0x1220 - io 0x64 = 0x1200 + io 0x62 = 0x1220 # Simple I/O + io 0x64 = 0x1228 # SPI end device pnp 2e.8 off # MIDI io 0x60 = 0x300 Modified: trunk/src/mainboard/lippert/spacerunner-lx/romstage.c ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/romstage.c Fri Sep 3 16:54:50 2010 (r5774) +++ trunk/src/mainboard/lippert/spacerunner-lx/romstage.c Fri Sep 3 17:16:36 2010 (r5775) @@ -129,16 +129,15 @@ static const u16 sio_init_table[] = { // hi=data, lo=index 0x0707, // select LDN 7 (GPIO, SPI, watchdog, ...) - 0x1E2C, // disable ATXPowerGood - 0x0423, // don't delay POWerOK1/2 - 0x9072, // watchdog triggers POWOK, counts seconds + 0x072C, // VIN6 enabled, FAN4/5 disabled, VIN7,VIN3 internal + 0x1423, // don't delay PoWeROK1/2 + 0x9072, // watchdog triggers PWROK, counts seconds #if !CONFIG_USE_WATCHDOG_ON_BOOT - 0x0073, 0x0074, // disable watchdog by setting timeout to 0 + 0x0073, 0x0074, // disarm watchdog by changing 56 s timeout to 0 #endif 0xBF25, 0x172A, 0xF326, // select GPIO function for most pins 0xFF27, 0xDF28, 0x2729, // (GP45=SUSB, GP23,22,16,15=SPI, GP13=PWROK1) - 0x072C, // VIN6=enabled?, FAN4/5 disabled, VIN7=internal, VIN3=internal - 0x66B8, 0x0CB9, // enable pullups + 0x66B8, 0x0CB9, // enable pullups on SPI, RS485_EN 0x07C0, // enable Simple-I/O for GP12-10= RS485_EN2,1, LIVE_LED 0x07C8, // config GP12-10 as output 0x2DF5, // map Hw Monitor Thermal Output to GP55 From mylesgw at gmail.com Fri Sep 3 17:17:22 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 3 Sep 2010 09:17:22 -0600 Subject: [coreboot] [PATCH] sync Road-/SpaceRunner with current standard BIOSes In-Reply-To: <4C80C415.9000301@LiPPERTEmbedded.de> References: <4C80C415.9000301@LiPPERTEmbedded.de> Message-ID: On Fri, Sep 3, 2010 at 3:47 AM, Jens Rottmann wrote: > Update RoadRunner and SpaceRunner config to get in sync with current > standard BIOSes RRLX0013 and SRLX0013. ?Specifically move SPI and PME > I/Os to 0x1228 and 0x298 and switch SIO watchdog to ext. 48 MHz CLKIN. > > Signed-off-by: Jens Rottmann Rev 5775. Thanks, Myles From patrick at georgi-clan.de Fri Sep 3 18:23:05 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Fri, 03 Sep 2010 18:23:05 +0200 Subject: [coreboot] CS5536 OHCI not working In-Reply-To: <4C811098.8010101@LiPPERTEmbedded.de> References: <4C811098.8010101@LiPPERTEmbedded.de> Message-ID: <4C8120E9.8010000@georgi-clan.de> Am 03.09.2010 17:13, schrieb Jens Rottmann: > is OHCI / USB storage support supposed to be working or is this still > very early experimental stuff? It's still rather fresh code (from Google Summer of Code 2010), and only tested on a single southbridge so far. > If it's known to work only on few supported chipsets yet, then never > mind, just ignore me, we don't actually need this, I just fancied giving > it a try. It's supposed to work everywhere, but given the experiences I had with the UHCI code, this is probably unrealistic ;-) > But if it's supposed to be mostly working now, you might be interested > to hear that this is all I'm getting: Thank you, this is indeed interesting to me! > doing control transfer with 0. first_td at f6bf8a0 > intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8c0, condition: f These debug messages can be disabled by commenting out USB_DEBUG in payloads/libpayload/drivers/usb/ohci.c > it uses SCSI transparent command set > it uses Bulk-Only Transport protocol > using endpoint 81 as in, 2 as out > doing control transfer with 1. first_td at f6bf8a0 > intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8d0, condition: f > has 1 luns Up to here it indicates that things are going rather well - both control and bulk transfers (the two transfer types important for mass storage devices) work. > Waiting for device to become ready... bulk: 1f bytes from 233035, finalize: 0, maxpacketsize: 40 > doing bulk transfer with 1(2). first_td at f6bf8a0, last f6bf8b0 > intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f > bulk: d bytes from 233028, finalize: 1, maxpacketsize: 40 > doing bulk transfer with 1(1). first_td at f6bf8a0, last f6bf8b0 > intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f > [ ... continues infinitely ... ] > > I added a counter forcing the loop @ libpayload/drivers/usb/ohci.c:206 > to break after 50 repetitions, but this didn't get me anywhere: in the > end USB storage would report a complete bogus nr of sectors for my thumb > drive. It's possible that this is more of a problem of your thumb drive than of the USB stack. Thumb drives often do weird stuff at that point, which is why there's a timeout. If you have some other USB storage devices and some time, I'd like to see some logs (maybe by personal email, not to the list) with these. Should some of them really work, we can still try to figure out what to do about the thumb drive you tried here. > I'd like to be more helpful, but I don't have a clue what this loop is > for, or what wait_for_ed() does or who this Ed person is anyway. ;-) It's the endpoint descriptor ;-) Basically, the function is a loop waiting for the scheduled operation to finish. Thanks, Patrick From stefan.reinauer at coresystems.de Fri Sep 3 20:46:19 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Fri, 03 Sep 2010 20:46:19 +0200 Subject: [coreboot] [commit] r5775 - in trunk/src/mainboard/lippert: roadrunner-lx spacerunner-lx In-Reply-To: References: Message-ID: <4C81427B.2020709@coresystems.de> On 9/3/10 5:16 PM, repository service wrote: > device pnp 2e.7 on # GPIO > - io 0x62 = 0x1220 > - io 0x64 = 0x1200 > + io 0x62 = 0x1220 # Simple I/O > + io 0x64 = 0x1228 # SPI > end Are these IO ports? If so, you might be seeing a double allocation because coreboot starts dynamic io resources at 0x1000 while static ones usually live below 0x1000. Stefan From peter at stuge.se Fri Sep 3 20:49:20 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 3 Sep 2010 20:49:20 +0200 Subject: [coreboot] [commit] r5775 - in trunk/src/mainboard/lippert: roadrunner-lx spacerunner-lx In-Reply-To: References: Message-ID: <20100903184920.32565.qmail@stuge.se> repository service wrote: > +++ trunk/src/mainboard/lippert/roadrunner-lx/devicetree.cb Fri Sep 3 17:16:36 2010 (r5775) .. > @@ -61,8 +61,8 @@ > irq 0x70 = 12 > end > device pnp 2e.7 on # GPIO > - io 0x62 = 0x1220 > - # io 0x64 = 0x1200 > + io 0x62 = 0x1220 # Simple I/O > + # io 0x64 = 0x1228 # SPI Why is SPI commented out for roadrunner? If not supported on the board then I think it should be removed. //Peter From benbarszcz at gmail.com Fri Sep 3 20:46:49 2010 From: benbarszcz at gmail.com (BeBa) Date: Fri, 3 Sep 2010 20:46:49 +0200 Subject: [coreboot] guidance needed with GA-6BXC rev 2.0 Message-ID: <20100903204649.4434a326@gmail.com> Hi, I have never used coreboot before and would like to try it out with ga-6BXC. According to the wiki (http://www.coreboot.org/GIGABYTE_GA-6BXC) one needs nothing special to get coreboot going with this board. First, I will use my other computer with amd64 bit gentoo distro to build coreboot with a payload. should I do anything special to the 'make' command in coreboot in order for it to work in ga-6BXC which is equipped with a 32bit proccesor? thanks for any answers BenBa From peter at stuge.se Sat Sep 4 01:52:11 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 4 Sep 2010 01:52:11 +0200 Subject: [coreboot] MS-6147, SeaBIOS, and OpenBSD. In-Reply-To: <20100827092106.GA28159@mea.homelinux.org> References: <20100827092106.GA28159@mea.homelinux.org> Message-ID: <20100903235211.6105.qmail@stuge.se> Mats Erik Andersson wrote: > 2. In the overview of supported mainboards, there ought to > be an entry "Y" for MSI MS-6147, stipulating that the > DIL32-ROM is set in a socket. Done. Flashrom too? > fully functional OpenBSD Nice! //Peter From peter at stuge.se Sat Sep 4 02:11:44 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 4 Sep 2010 02:11:44 +0200 Subject: [coreboot] CS5536 OHCI not working In-Reply-To: <4C8120E9.8010000@georgi-clan.de> References: <4C811098.8010101@LiPPERTEmbedded.de> <4C8120E9.8010000@georgi-clan.de> Message-ID: <20100904001144.8317.qmail@stuge.se> Patrick Georgi wrote: > > in the end USB storage would report a complete bogus nr of > > sectors for my thumb drive. > > It's possible that this is more of a problem of your thumb drive > than of the USB stack. Indeed. Especially if the drive is actually a high speed device then frequently it will not work perfectly running at full speed. An interesting data point would be for you to attach the drive when the system is running Linux, *without* the ehci_hcd driver loaded, only ohci_hcd. //Peter From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 4 04:46:06 2010 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 04 Sep 2010 04:46:06 +0200 Subject: [coreboot] [flashrom] Re: flashrom patch: add support for Abit AB-BM6 board In-Reply-To: References: Message-ID: <4C81B2EE.2060104@gmx.net> Hi Tim, it seems your flashrom patch from exactly two years ago slipped through the cracks until now. I'm very sorry about that. Do you still own the board? If yes, could you please run download latest flashrom (at least 0.9.2, preferably latest svn) and provide the output of the following commands (as root): flashrom -V superiotool -deV flashrom supports DMI matching since a few months, so it may be possible to identify your board that way. And with superiotool output, we could perhaps improve matching a bit more. You already provided full lspci -nnvvxx output at http://marc.info/?l=linuxbios&m=122276697617977&w=2 so I'm not going to request that again. (I couldn't link to the coreboot.org mailing list archives because that message is corrupt). On 03.09.2008 11:42, Tim ter Laak wrote: > This patch adds support for the Abit AB-BM6 mainboard to flashrom. > > The biggest part is a generic function to lower a GPIO line on the > PIIX4E southbridge, copied and adapted from its ich_gpio_raise() > counterpart (mostly lower instead of raise, followed names from the > PIIX4E datasheet). The board specific function then uses this to lower > GPO 26. > > Signed-off-by: Tim ter Laak > > +/** > + * Suited for Abit AB-BM6. > + */ > +static int piix4_gpio26_lower(const char *name) > +{ > + return piix4_gpio_lower(name, 0x8086, 0x7113, 0x40, 0x34, 0xffc0, 26); With current flashrom, the line above would look like this: return intel_piix4_gpo_set(26, 0); > +} > + > + > + > +/** > * Suited for Acorp 6A815EPD. > */ > static int board_acorp_6a815epd(const char *name) > @@ -672,6 +724,8 @@ > NULL, NULL, "GIGABYTE GA-7VT600", board_biostar_p4m80_m4}, > {0x1106, 0x3149, 0x1462, 0x7094, 0x10ec, 0x8167, 0x1462, 0x094c, > NULL, NULL, "MSI K8T Neo2", w83627thf_gpio4_4_raise_2e}, > + {0x8086, 0x7190, 0x0000, 0x0000, 0x8086, 0x7110, 0x0000, 0x0000, > + "abit", "ab-bm6", "Abit AB-BM6", piix4_gpio26_lower}, > {0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL} /* Keep this */ > }; If DMI is useful on your board, we could try to match the DMI strings and avoid the -m abit:ab-bm6 parameter for flashrom. Regards, Carl-Daniel -- http://www.hailfinger.org/ From wt at penguintechs.org Sat Sep 4 05:12:02 2010 From: wt at penguintechs.org (Warren Turkal) Date: Fri, 3 Sep 2010 20:12:02 -0700 Subject: [coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus In-Reply-To: <4C7F4FB7.8070107@iki.fi> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> Message-ID: Who's responsible for the tilapia port? I am trying to assign this to someone in the patchwork system, but I don't know who to assign it to. Also, is there a testbed that can run this change to make sure it doesn't break non-tilapia systems? Thanks, wt On Thu, Sep 2, 2010 at 12:18 AM, Juhana Helovuo wrote: > 1.9.2010 23:00, Scott kirjoitti: > >> Thanks Myles. That problem description and work-around matches my >> situation exactly. Even if the bad value passed to pci_scan_bus is >> only a side-effect of another problem, special handling for it should >> be considered in order to simplify debugging. >> >> The same thead covers another problem I encounter with Tilapia. When >> I enable ACPI table generation, an overlap causes the seabios payload >> to overwrite the ACPI tables. I temporarily worked around this problem >> by deselecting GFXUMA. I am using PCI video so I can boot with no uma. > > Hello, > > I had similar problems recently. I did a patch for Asus M4A785-M, which is > derived from the AMD Tilapia port. > > The patch can be found at > http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html > > There is another patch that sets up UMA and coreboot/ACPI/etc. tables as > reserved areas in the multiboot tables. Without this patch booting with Grub > to Linux suffers from the same problem of overwriting tables. > > http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html > > I do not know if these are going to be integrated to the Coreboot trunk, but > currently they are available as patch files. > > How does SeaBIOS detect which RAM is usable and which is not? Maybe the > memory conflict with UMA and ACPI tables could be avoided in a similar > manner? > > Best regards, > Juhana Helovuo > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From svn at coreboot.org Sat Sep 4 08:13:03 2010 From: svn at coreboot.org (repository service) Date: Sat, 04 Sep 2010 08:13:03 +0200 Subject: [coreboot] [commit] r5776 - in trunk/src/northbridge/amd/amdmct: mct mct_ddr3 Message-ID: Author: oxygene Date: Sat Sep 4 08:13:02 2010 New Revision: 5776 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5776 Log: AMD DDR2 and DDR3 MCT function InitPhyCompensation() compliant with AGESA code. Signed-off-by: Kerry She Acked-by: Patrick Georgi Modified: trunk/src/northbridge/amd/amdmct/mct/mct_d.c trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Modified: trunk/src/northbridge/amd/amdmct/mct/mct_d.c ============================================================================== --- trunk/src/northbridge/amd/amdmct/mct/mct_d.c Fri Sep 3 17:16:36 2010 (r5775) +++ trunk/src/northbridge/amd/amdmct/mct/mct_d.c Sat Sep 4 08:13:02 2010 (r5776) @@ -3461,9 +3461,10 @@ i = 0; /* use i for the dct setting required */ if (pDCTstat->MAdimms[0] < 4) i = 1; - if (((pDCTstat->Speed == 2) || (pDCTstat->Speed == 3)) && (pDCTstat->MAdimms[i] == 4)) + if (((pDCTstat->Speed == 2) || (pDCTstat->Speed == 3)) && (pDCTstat->MAdimms[i] == 4)) { dword &= 0xF18FFF18; index_reg = 0x98; /* force dct = 0 */ + } } Set_NB32_index_wait(dev, index_reg, 0x0a, dword); Modified: trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c ============================================================================== --- trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Fri Sep 3 17:16:36 2010 (r5775) +++ trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Sat Sep 4 08:13:02 2010 (r5776) @@ -3127,9 +3127,10 @@ i = 0; /* use i for the dct setting required */ if (pDCTstat->MAdimms[0] < 4) i = 1; - if (((pDCTstat->Speed == 2) || (pDCTstat->Speed == 3)) && (pDCTstat->MAdimms[i] == 4)) + if (((pDCTstat->Speed == 2) || (pDCTstat->Speed == 3)) && (pDCTstat->MAdimms[i] == 4)) { dword &= 0xF18FFF18; index_reg = 0x98; /* force dct = 0 */ + } } Set_NB32_index_wait(dev, index_reg, 0x0a, dword); From Nick.Lemberger at lkfd.net Sat Sep 4 00:07:57 2010 From: Nick.Lemberger at lkfd.net (Nick Lemberger) Date: Fri, 03 Sep 2010 17:07:57 -0500 Subject: [coreboot] SuperMicro h8dmr-i2 slowness in v4 Message-ID: <4C812B6D020000FE0000D531@mail.lkfd.net> Hello, I'm having some trouble with current releases of coreboot on a Supermicro H8DMR-i2. The initial problem, it takes about 2 minutes to show the: "coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting..." and equally as long after the warm reset. The second, the system freezes at "Clearning initial memory region:" for about a half hour before proceeding. After that, everything works as expected. There has been some list chatter about a similar problem with the H8DME, but that was based upon the H8DMR code so it's odd that it found it's way here. I've attached the full serial output if that's at all useful. Vitals: Vendor: Supermicro MainBoard: H8DMR-i2 NorthVBridge: Fam10h SouthBridge: NVIDIA MCP55 Super I/O: Winbond? W83627EHG CPU: AMD Opteron Any suggestions are welcome, TIA, Nicholas Lemberger ---snip--- coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting... BSP Family_Model: 00100f23 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1022, current patch id = 0x00000000 microcode: rev id (1062) does not match this patch. microcode: Not updated! Fix microcode_updates[] POST: 0x33 cpuSetAMDMSR done POST: 0x34 Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 00 00 01 AMD_CB_ManualBUIDSwapList() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 02 ff Exit amd_ht_init() POST: 0x35 cpuSetAMDPCI 00 done cpuSetAMDPCI 01 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f23 F3xD8: 03001b12 F3xDC: 0000542c Prep FID/VID Node:01 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f23 F3xD8: 03001b12 F3xDC: 0000542c setup_remote_node: 01 done Start node 01 done. POPSOSTT: :0 0xx3630 Co rcoer0 es0:t ar t--e-d :{ 0A1PI sItD a=rt _04o thNeODrE_cIoD r=es (01) oOinREiIt Dn =o de00:} 0 0-- - c :rmiesc:ro c03o de S etqarutiv aotlhenetr creovre id- n o= de0ix1d0: 202,0 ccurorreesnt: 0p3at ::i niidt =n o0dex0: 000010 0 PPPOO0cO0oSSSTrTT :es m0:00ixxcx r0333o0300 c o dSe :ccctoooa rrrrreeetexx xv :::o ti hd --e -(r---- --1 0 c6{o{{ r 2 )AAAePP Pd-IIICCCo eInIIDoDsD d===eni OcOR00d0:21 3m 0NNaNtOO1O DDcDhEE EcII ItDDoD r h=ei==s s00: 0p 000 a0tC3CCO OI hRREEE.PII --:-: - e i:===c r0000PPPOox231OOS}SSc3}} T TTo7:d x ----0-00:sx t Na cc 3330or00mmmiiitt c erudrr oocccop dcaccooorraopoorddeeetd eeaeexxx:::d:p:: i ! eece Fqqiq------iuudu:ii---xi v vv {a{{ma*al O ilAceeAAeAPnPPrnnPtt ItIIoCCc 0C I1rIIorreeDseDDd evv tv=a ==_ uii ri 0d0pdd0t5e7 6d a d N=Nt==N 2 2=22=02=D0*D0E xE[xExI1IA1I]1D 0D0DP0 2 DtM , ,, 2c0s p0 0cc11tcu1Su uu aCCrerCrrrrOOttrOAeReeRReEEdMnEnnIttII t- D DD S*p pp=aa==R a At tt 00P0ccc hh2d h13} } }o0 n3 i ii-dd-es-d- - - r i-=-== n t0 c0c00c00rfiexmmmi0i00itd_ _ s 5 r0ro0o00oi*cd c0c00o00ovAo0d0d00diPed e0e00: nn eetesmmmiiqaqtqiuacccuguieiirrrrooov2vvtaaeccca loalldooddedpee d eeneit:ctt*:: i drrrArrree:eeePe vvvv vv0 0 iii4ii6idsdddd 1)0 0 ( ( a(=11=r1= 0 00 t0e06066x2dx2x21)1) t ttt 02*2dd2d2o 2oo2,e,eA,e ss sP c c c unu0unnroor7rortrttrsete e nmanmnmtatarta t t ttecpcpcpadhahaht t hhhhhh cc 3000 i iiisPsiisd d O d p pSpaT==a=a tt: t0ccc 00xxxhhh00x00... 0 0mm0m0i0 r 0ii0cc00c ceccoo00oBoo0 ogdiddmmmieiiene: c:cc:r Fr roNoNNIoccocooDoVotott dId deuuueDe: :ppp: d M ddraarSraetetteRv eveev 0d dd!!iix!id ddc 0 FFF (i(0(ii1xx11x10 00060mmm662227iii)c))1ccrr r d0oododooxccoceoee2ooddsdss0eae e nn_6_n_ouoou0up1tptth0h1 d mmaa4maatatt at0teteesscxcsch[[[h4h c ]]] tt0t h i teetctctccc p p 0ppuupup3a aSSaSte SD cthAhAhAPOMMM... M MM nodededemSSiR iRiRc c 0c rrxr o3dooddco9occoonon eP: e : avvavtit i iinnNTNnNoiiio:otttttt 0 ___ufxuuffiipi3ppdddddada tiieddeedEddnd___ss!!!sd ttt FFFaaaFiiiIgggeexxxDe2nneeep0ppuuu1S1SSeee4t ttAAA0MxMMDDD4McMMSSS0RR0R 4c0 d3ddooo n m c d_ipiinn5ni5iittt__n__fffuimiiddd:v0vviii1dd __ssstttaaagggeee222 aaapppiiiccciiiddd::: 000765 POST: 0x3b fill_mem_ctrl() POST: 0x3d POST: 0x40 raminit_amdmct() raminit_amdmct begin: Node: 00 base: 00 limit: 3ffffff BottomIO: e00000 Node: 01 base: 4200000 limit: 81fffff BottomIO: e00000 Copy dram map from Node 0 to Node 01 raminit_amdmct end: POST: 0x41 v_esp=000cbf38 testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: From patrick at georgi-clan.de Sat Sep 4 09:42:09 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Sat, 04 Sep 2010 09:42:09 +0200 Subject: [coreboot] SuperMicro h8dmr-i2 slowness in v4 In-Reply-To: <4C812B6D020000FE0000D531@mail.lkfd.net> References: <4C812B6D020000FE0000D531@mail.lkfd.net> Message-ID: <4C81F851.3090707@georgi-clan.de> Am 04.09.2010 00:07, schrieb Nick Lemberger: > The initial problem, it takes about 2 minutes to show the: > "coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting..." > and equally as long after the warm reset. > > The second, the system freezes at "Clearning initial memory region:" for > about a half hour before proceeding. After that, everything works as > expected. I guess both stem from a known cache setup issue on AMD chipsets. Unfortunately no one worked on it yet. Patrick From hagigatali at gmail.com Sat Sep 4 12:52:00 2010 From: hagigatali at gmail.com (ali hagigat) Date: Sat, 4 Sep 2010 15:22:00 +0430 Subject: [coreboot] --divide!! and .xcompile Message-ID: I found the following variable in .xcompile: CC:=gcc -Wa,--divide -fno-stack-protector -Wl,--build-id=none It seems that there is no definition of --divide option for GNU assembler. What is it supposed to do? From patrick at georgi-clan.de Sat Sep 4 13:23:34 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Sat, 04 Sep 2010 13:23:34 +0200 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: Message-ID: <4C822C36.4060608@georgi-clan.de> Am 04.09.2010 12:52, schrieb ali hagigat: > I found the following variable in .xcompile: > > CC:=gcc -Wa,--divide -fno-stack-protector -Wl,--build-id=none > > It seems that there is no definition of --divide option for GNU > assembler. What is it supposed to do? It changes the parser behaviour. In some configurations "/" is interpreted as comment, while we need it to be the division operator. Patrick From peter at stuge.se Sat Sep 4 15:20:05 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 4 Sep 2010 15:20:05 +0200 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: Message-ID: <20100904132005.18489.qmail@stuge.se> ali hagigat wrote: > It seems that there is no definition of --divide option for GNU > assembler. http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions From mylesgw at gmail.com Sat Sep 4 23:23:58 2010 From: mylesgw at gmail.com (Myles Watson) Date: Sat, 4 Sep 2010 15:23:58 -0600 Subject: [coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus In-Reply-To: <4C7F4FB7.8070107@iki.fi> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> Message-ID: > I had similar problems recently. I did a patch for Asus M4A785-M, which is > derived from the AMD Tilapia port. > > The patch can be found at > http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html It would be a lot easier to review if you split the patch into smaller pieces. 1. Use svn cp to copy the tilapia board directory for your board 2. Make the changes so it works for your board (just copy the files you already have from another location) 3. svn diff This will produce a patch with only your changes. Split out work-around patches as well. Something is broken for your board, and that needs to be fixed, but I don't think we should change the PCI scan code. > There is another patch that sets up UMA and coreboot/ACPI/etc. tables as > reserved areas in the multiboot tables. Without this patch booting with Grub > to Linux suffers from the same problem of overwriting tables. > > http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html > > I do not know if these are going to be integrated to the Coreboot trunk, but > currently they are available as patch files. To be committed, patches need to be Signed-off and Acked. If you've tested the multiboot patch and it works for you, you could send an Acked-by: to the list, and it will most likely get committed. If you still have other changes that you'd like to make, then submit another version of the patch with your Signed-off-by: tag. > How does SeaBIOS detect which RAM is usable and which is not? Maybe the > memory conflict with UMA and ACPI tables could be avoided in a similar > manner? SeaBIOS reads the Coreboot tables. Thanks, Myles From mylesgw at gmail.com Sat Sep 4 23:26:06 2010 From: mylesgw at gmail.com (Myles Watson) Date: Sat, 4 Sep 2010 15:26:06 -0600 Subject: [coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> Message-ID: On Fri, Sep 3, 2010 at 9:12 PM, Warren Turkal wrote: > Who's responsible for the tilapia port? In general we haven't made specific people responsible for ports. Generally there is someone who cares more because they use it. That may be you :) Thanks, Myles From footplus at gmail.com Sun Sep 5 00:00:30 2010 From: footplus at gmail.com (=?UTF-8?B?QXVyw6lsaWVu?=) Date: Sun, 5 Sep 2010 00:00:30 +0200 Subject: [coreboot] [PATCH] Geode LX and Alix.2 support enhancements Message-ID: Hi everyone, Here are 2 patches: Geode LX RAMBASE @1M support: ---- Geode LX MSRs are now set up to allow early access to memory above 1Mb for loading coreboot_ram. An arbitrary amount (~500M) is set up, but is corrected shortly after, in the northbridge init code, so that should work in about every case on LX boards. I made modifications of RAMBASE to every board using LX northbridge, because the code setting the MSR access is done for all boards using LX. However, RAMBASE @0x4000 should still work in case of problems. Also added an explanation text about what is done. I only have Alix.2d13 board, so I can't say if this patch breaks things for other boards. Alix.2[cd][23] support enhancements ---- !!!! Please $ svn mv alix2d alix2 before applying this patch. !!!! I decided to rename the boards Alix.2 and support the following variants: 2c2, 2c3, 2d2, 2d3, 2d13 - see help text -. 2d1 may also work, but differ more: different ram size, and no USB, so I can't say. I also added a submenu to configure which onboard LEDs should be lit at boot. Finally, I clarified the comments in irq_routing.c. Please tell me what you think :) Signed-off-by: Aur?lien Guillaume Best regards, -- Aur?lien Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: alix2-support-enhancements.diff Type: application/octet-stream Size: 8090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: geode-lx-rambase-at-1m.diff Type: application/octet-stream Size: 4791 bytes Desc: not available URL: From uwe at hermann-uwe.de Sun Sep 5 00:29:54 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 5 Sep 2010 00:29:54 +0200 Subject: [coreboot] [flashrom] ABIT IP35-E flashrom read success, hardware info In-Reply-To: References: Message-ID: <20100904222954.GH19625@greenwood> On Wed, Aug 18, 2010 at 12:20:16AM +0400, ????? ?????? wrote: > ABIT IP35-E > > > flashrom -V : http://flashrom.pastebin.com/Gp13xD95 > > flashrom read : http://flashrom.pastebin.com/kNH3fWbg > > superiotool : http://flashrom.pastebin.com/jXa2PuMU > > inteltool : http://flashrom.pastebin.com/VABjFXcn > > lspci : http://flashrom.pastebin.com/XjmiqT34 > > lspnp : http://flashrom.pastebin.com/w03WA0XV > > dmidecode : http://flashrom.pastebin.com/62Dk1FZz > > biosdecode : http://flashrom.pastebin.com/qwmMAKyr > > dmesg : http://flashrom.pastebin.com/QxBZdzXf > > acpitool : http://flashrom.pastebin.com/VhF6f5yB > > rom image : http://rghost.net/2370899 Just for reference, these seem to be the same logs as here: http://www.flashrom.org/pipermail/flashrom/2010-September/004620.html Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From Zheng.Bao at amd.com Sun Sep 5 04:00:42 2010 From: Zheng.Bao at amd.com (Bao, Zheng) Date: Sun, 5 Sep 2010 10:00:42 +0800 Subject: [coreboot] AMD Tilapia / simnow: endless looping infunctionpci_scan_bus In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78><0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> Message-ID: Please see the log when the mahogany_fam10 was created. That is r5221. That is the problem located in folder amdht, which is about HT initialization of Family 10. Zheng > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Warren Turkal > Sent: Saturday, September 04, 2010 11:12 AM > To: Juhana Helovuo > Cc: Scott; coreboot at coreboot.org > Subject: Re: [coreboot] AMD Tilapia / simnow: endless looping > infunctionpci_scan_bus > > Who's responsible for the tilapia port? I am trying to assign this to > someone in the patchwork system, but I don't know who to assign it to. > > Also, is there a testbed that can run this change to make sure it > doesn't break non-tilapia systems? > > Thanks, > wt > > On Thu, Sep 2, 2010 at 12:18 AM, Juhana Helovuo wrote: > > 1.9.2010 23:00, Scott kirjoitti: > > > >> Thanks Myles. That problem description and work-around matches my > >> situation exactly. Even if the bad value passed to pci_scan_bus is > >> only a side-effect of another problem, special handling for it should > >> be considered in order to simplify debugging. > >> > >> The same thead covers another problem I encounter with Tilapia. When > >> I enable ACPI table generation, an overlap causes the seabios payload > >> to overwrite the ACPI tables. I temporarily worked around this problem > >> by deselecting GFXUMA. I am using PCI video so I can boot with no uma. > > > > Hello, > > > > I had similar problems recently. I did a patch for Asus M4A785-M, which > is > > derived from the AMD Tilapia port. > > > > The patch can be found at > > http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html > > > > There is another patch that sets up UMA and coreboot/ACPI/etc. tables as > > reserved areas in the multiboot tables. Without this patch booting with > Grub > > to Linux suffers from the same problem of overwriting tables. > > > > http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html > > > > I do not know if these are going to be integrated to the Coreboot trunk, > but > > currently they are available as patch files. > > > > How does SeaBIOS detect which RAM is usable and which is not? Maybe the > > memory conflict with UMA and ACPI tables could be avoided in a similar > > manner? > > > > Best regards, > > Juhana Helovuo > > > > -- > > coreboot mailing list: coreboot at coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From hagigatali at gmail.com Sun Sep 5 07:15:49 2010 From: hagigatali at gmail.com (ali hagigat) Date: Sun, 5 Sep 2010 09:45:49 +0430 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: <20100904132005.18489.qmail@stuge.se> References: <20100904132005.18489.qmail@stuge.se> Message-ID: Thank you all for the replies. Peter, the link you wrote is broken! http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions Should i execute, util/crossgcc/buildgcc to change and patch the original Linux GCC? That will be all? or I may have to change some other things. Please excuse me if my question is a repeat. On Sat, Sep 4, 2010 at 5:50 PM, Peter Stuge wrote: > ali hagigat wrote: >> It seems that there is no definition of --divide option for GNU >> assembler. > > http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From corey.osgood at gmail.com Sun Sep 5 07:30:02 2010 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 5 Sep 2010 01:30:02 -0400 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: <20100904132005.18489.qmail@stuge.se> Message-ID: On Sun, Sep 5, 2010 at 1:15 AM, ali hagigat wrote: > Thank you all for the replies. > Peter, the link you wrote is broken! > http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions Works fine for me: --divide On SVR4-derived platforms, the character `/' is treated as a comment character, which means that it cannot be used in expressions. The `--divide' option turns `/' into a normal character. This does not disable `/' at the beginning of a line starting a comment, or affect using `#' for starting a comment. > > Should i execute, util/crossgcc/buildgcc to change and patch the > original Linux GCC? No, crossgcc should fetch it's own "known good" version of gcc and patch it. Trying to patch some other version of gcc will probably fail. -Corey > That will be all? or I may have to change some other things. > Please excuse me if my question is a repeat. > > On Sat, Sep 4, 2010 at 5:50 PM, Peter Stuge wrote: >> ali hagigat wrote: >>> It seems that there is no definition of --divide option for GNU >>> assembler. >> >> http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From hagigatali at gmail.com Sun Sep 5 07:46:14 2010 From: hagigatali at gmail.com (ali hagigat) Date: Sun, 5 Sep 2010 10:16:14 +0430 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: <20100904132005.18489.qmail@stuge.se> Message-ID: Many thanks Corey. The link is OK, i was mistaken. My machine is Linux, Fedora 12, should i execute util/crossgcc/buildgcc to change the GCC of the system? So how util/crossgcc/buildgcc works? because there is already a GCC rpm installed, then it will install another one and the previous version is uninstalled? If I use Fedora 12 GCC, when it executes 'gcc -Wa,--divide" and the option(--divide) is unknown, how come it can compile the files by it without errors? On Sun, Sep 5, 2010 at 10:00 AM, Corey Osgood wrote: > On Sun, Sep 5, 2010 at 1:15 AM, ali hagigat wrote: >> Thank you all for the replies. >> Peter, the link you wrote is broken! >> http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions > > Works fine for me: > > --divide > ? ?On SVR4-derived platforms, the character `/' is treated as a > comment character, which means that it cannot be used in expressions. > The `--divide' option turns `/' into a normal character. This does not > disable `/' at the beginning of a line starting a comment, or affect > using `#' for starting a comment. > >> >> Should i execute, util/crossgcc/buildgcc to change and patch the >> original Linux GCC? > > No, crossgcc should fetch it's own "known good" version of gcc and > patch it. Trying to patch some other version of gcc will probably > fail. > > -Corey > >> That will be all? or I may have to change some other things. >> Please excuse me if my question is a repeat. >> >> On Sat, Sep 4, 2010 at 5:50 PM, Peter Stuge wrote: >>> ali hagigat wrote: >>>> It seems that there is no definition of --divide option for GNU >>>> assembler. >>> >>> http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions >>> >>> -- >>> coreboot mailing list: coreboot at coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > From svn at coreboot.org Sun Sep 5 07:52:34 2010 From: svn at coreboot.org (repository service) Date: Sun, 05 Sep 2010 07:52:34 +0200 Subject: [coreboot] [commit] r5777 - trunk/src/northbridge/amd/amdmct/mct_ddr3 Message-ID: Author: zbao Date: Sun Sep 5 07:52:33 2010 New Revision: 5777 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5777 Log: Trivial. Currently the max frequency is preset as 400Mhz. We need to set a platform specific value. Before that, we can set it manually if the boards need to run in a higher frequency, which has been tested on Tilapia. Signed-off-by: Zheng Bao Acked-by: Zheng Bao Modified: trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Modified: trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c ============================================================================== --- trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Sat Sep 4 08:13:02 2010 (r5776) +++ trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Sun Sep 5 07:52:33 2010 (r5777) @@ -1295,6 +1295,7 @@ * Specific information. Return the least of these three in * DCTStatStruc.PresetmaxFreq. */ + /* TODO: Set the proper max frequency in wrappers/mcti_d.c. */ u16 proposedFreq; u16 word; From corey.osgood at gmail.com Sun Sep 5 08:07:22 2010 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 5 Sep 2010 02:07:22 -0400 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: <20100904132005.18489.qmail@stuge.se> Message-ID: On Sun, Sep 5, 2010 at 1:46 AM, ali hagigat wrote: > Many thanks Corey. The link is OK, i was mistaken. > My machine is Linux, Fedora 12, should i execute > util/crossgcc/buildgcc to change the GCC of the system? > So how util/crossgcc/buildgcc works? because there is already a GCC > rpm installed, then it will install another one and the previous > version is uninstalled? No, the crossgcc toolchin will by default live in ~/xgcc (specified by "TARGETDIR=`pwd`/xgcc", overridden with -D switch). To point to it, you do: $ PATH="/path/to/coreboot/util/crossgcc/xgcc/bin":$PATH; make At least I think that's all you've got to do, haven't had to use it yet myself. -Corey > If I use Fedora 12 GCC, when it executes 'gcc -Wa,--divide" and the > option(--divide) is unknown, how come it can compile the files by it > without errors? > > On Sun, Sep 5, 2010 at 10:00 AM, Corey Osgood wrote: >> On Sun, Sep 5, 2010 at 1:15 AM, ali hagigat wrote: >>> Thank you all for the replies. >>> Peter, the link you wrote is broken! >>> http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions >> >> Works fine for me: >> >> --divide >> ? ?On SVR4-derived platforms, the character `/' is treated as a >> comment character, which means that it cannot be used in expressions. >> The `--divide' option turns `/' into a normal character. This does not >> disable `/' at the beginning of a line starting a comment, or affect >> using `#' for starting a comment. >> >>> >>> Should i execute, util/crossgcc/buildgcc to change and patch the >>> original Linux GCC? >> >> No, crossgcc should fetch it's own "known good" version of gcc and >> patch it. Trying to patch some other version of gcc will probably >> fail. >> >> -Corey >> >>> That will be all? or I may have to change some other things. >>> Please excuse me if my question is a repeat. >>> >>> On Sat, Sep 4, 2010 at 5:50 PM, Peter Stuge wrote: >>>> ali hagigat wrote: >>>>> It seems that there is no definition of --divide option for GNU >>>>> assembler. >>>> >>>> http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions >>>> >>>> -- >>>> coreboot mailing list: coreboot at coreboot.org >>>> http://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >>> -- >>> coreboot mailing list: coreboot at coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> >> > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From corey.osgood at gmail.com Sun Sep 5 08:08:14 2010 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 5 Sep 2010 02:08:14 -0400 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: <20100904132005.18489.qmail@stuge.se> Message-ID: On Sun, Sep 5, 2010 at 2:07 AM, Corey Osgood wrote: > On Sun, Sep 5, 2010 at 1:46 AM, ali hagigat wrote: >> Many thanks Corey. The link is OK, i was mistaken. >> My machine is Linux, Fedora 12, should i execute >> util/crossgcc/buildgcc to change the GCC of the system? >> So how util/crossgcc/buildgcc works? because there is already a GCC >> rpm installed, then it will install another one and the previous >> version is uninstalled? > > No, the crossgcc toolchin will by default live in ~/xgcc Sorry, that should have been /xgcc -Corey > (specified by > "TARGETDIR=`pwd`/xgcc", overridden with -D switch). To point to it, > you do: > > $ PATH="/path/to/coreboot/util/crossgcc/xgcc/bin":$PATH; make > > At least I think that's all you've got to do, haven't had to use it yet myself. > > -Corey > >> If I use Fedora 12 GCC, when it executes 'gcc -Wa,--divide" and the >> option(--divide) is unknown, how come it can compile the files by it >> without errors? >> >> On Sun, Sep 5, 2010 at 10:00 AM, Corey Osgood wrote: >>> On Sun, Sep 5, 2010 at 1:15 AM, ali hagigat wrote: >>>> Thank you all for the replies. >>>> Peter, the link you wrote is broken! >>>> http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions >>> >>> Works fine for me: >>> >>> --divide >>> ? ?On SVR4-derived platforms, the character `/' is treated as a >>> comment character, which means that it cannot be used in expressions. >>> The `--divide' option turns `/' into a normal character. This does not >>> disable `/' at the beginning of a line starting a comment, or affect >>> using `#' for starting a comment. >>> >>>> >>>> Should i execute, util/crossgcc/buildgcc to change and patch the >>>> original Linux GCC? >>> >>> No, crossgcc should fetch it's own "known good" version of gcc and >>> patch it. Trying to patch some other version of gcc will probably >>> fail. >>> >>> -Corey >>> >>>> That will be all? or I may have to change some other things. >>>> Please excuse me if my question is a repeat. >>>> >>>> On Sat, Sep 4, 2010 at 5:50 PM, Peter Stuge wrote: >>>>> ali hagigat wrote: >>>>>> It seems that there is no definition of --divide option for GNU >>>>>> assembler. >>>>> >>>>> http://sourceware.org/binutils/docs/as/i386_002dOptions.html#i386_002dOptions >>>>> >>>>> -- >>>>> coreboot mailing list: coreboot at coreboot.org >>>>> http://www.coreboot.org/mailman/listinfo/coreboot >>>>> >>>> >>>> -- >>>> coreboot mailing list: coreboot at coreboot.org >>>> http://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > From hagigatali at gmail.com Sun Sep 5 09:00:01 2010 From: hagigatali at gmail.com (ali hagigat) Date: Sun, 5 Sep 2010 11:30:01 +0430 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: <20100904132005.18489.qmail@stuge.se> Message-ID: Is there any document or link to explain what changes has been done in GCC, binutils, gdb and it seems all GNU tool chain components have changed! If I do not change GNU tool chain, the final coreboot.rom will be an incorrect image and it can not be run? From patrick at georgi-clan.de Sun Sep 5 09:01:46 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Sun, 05 Sep 2010 09:01:46 +0200 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: <20100904132005.18489.qmail@stuge.se> Message-ID: <4C83405A.8050002@georgi-clan.de> Am 05.09.2010 09:00, schrieb ali hagigat: > Is there any document or link to explain what changes has been done in > GCC, binutils, gdb and it seems all GNU tool chain components have > changed! > If I do not change GNU tool chain, the final coreboot.rom will be an > incorrect image and it can not be run? Our changes are minor. The main problem is that distributions (such as the Fedora stuff you use) modify their toolchain a lot - often incompatibly with coreboot. Patrick From hagigatali at gmail.com Sun Sep 5 09:04:58 2010 From: hagigatali at gmail.com (ali hagigat) Date: Sun, 5 Sep 2010 11:34:58 +0430 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: <20100904132005.18489.qmail@stuge.se> Message-ID: Why the following link does not mention to execute util/crossgcc/buildgcc before doing "make"? http://www.coreboot.org/Build_HOWTO Anyway I ran util/crossgcc/buildgcc and here is the result: Welcome to the coresystems cross toolchain builder v1.01 (May 18th, 2010) Downloading tar balls ... * gmp-5.0.1.tar.bz2 (cached) * mpfr-2.4.2.tar.bz2 (cached) * mpc-0.8.2.tar.gz (cached) * libelf-0.8.13.tar.gz (cached) * gcc-core-4.4.4.tar.bz2 (cached) * binutils-2.20.1.tar.bz2 (downloading) * gdb-7.1.tar.bz2 (downloading) Downloaded tar balls ... ok Unpacking and patching ... * gmp-5.0.1.tar.bz2 bzip2: Compressed file ends unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzip2: Inappropriate ioctl for device Input file = (stdin), output file = (stdout) It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. tar: Child returned status 2 tar: Exiting with failure status due to previous errors * mpfr-2.4.2.tar.bz2 o mpfr-2.4.2_allpatches_20100308.patch * mpc-0.8.2.tar.gz * libelf-0.8.13.tar.gz * gcc-core-4.4.4.tar.bz2 bzip2: Compressed file ends unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzip2: Inappropriate ioctl for device Input file = (stdin), output file = (stdout) It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now * binutils-2.20.1.tar.bz2 * gdb-7.1.tar.bz2 Unpacked and patched ... ok Building GMP 5.0.1 ... failed From peter at stuge.se Sun Sep 5 09:10:55 2010 From: peter at stuge.se (Peter Stuge) Date: Sun, 5 Sep 2010 09:10:55 +0200 Subject: [coreboot] --divide!! and .xcompile In-Reply-To: References: <20100904132005.18489.qmail@stuge.se> Message-ID: <20100905071055.32213.qmail@stuge.se> ali hagigat wrote: > Why the following link does not mention to execute > util/crossgcc/buildgcc before doing "make"? > http://www.coreboot.org/Build_HOWTO In a perfect world it would not be neccessary. But unfortunately it seems that many distributions mess up their toolchains. > * gmp-5.0.1.tar.bz2 > > bzip2: Compressed file ends unexpectedly; > perhaps it is corrupted? *Possible* reason follows. > bzip2: Inappropriate ioctl for device > Input file = (stdin), output file = (stdout) > > It is possible that the compressed file(s) have become corrupted. What part of these messages are difficult to understand? > You can use the -tvv option to test integrity of such files. Did you do this? I'm sure you understand that you will annoy a lot of people by sending error messages which include suggestions for further action to the mailing list and expect to get help if you have not tried to take those actions yourself already. I am sure you agree that replies such as my "Did you try the suggestion that was shown?" are not something that the mailing list should be telling you! //Peter From uwe at hermann-uwe.de Sun Sep 5 17:49:59 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 5 Sep 2010 17:49:59 +0200 Subject: [coreboot] #95: Run coreboot in VirtualBox In-Reply-To: <054.38c6002614f4bf3935a8b7fb1b396409@coreboot.org> References: <039.8e5fad36b203068bd3071c0f2771ba88@coreboot.org> <054.38c6002614f4bf3935a8b7fb1b396409@coreboot.org> Message-ID: <20100905154959.GA3256@greenwood> On Mon, Jun 28, 2010 at 10:49:55PM -0000, coreboot wrote: > #95: Run coreboot in VirtualBox > ----------------------------------+----------------------------------------- > Reporter: uwe | Owner: somebody > Type: enhancement | Status: closed > Priority: minor | Milestone: > Component: misc | Resolution: invalid > Keywords: | Dependencies: > Patch Status: there is no patch | > ----------------------------------+----------------------------------------- > Changes (by stepan): > > * status: reopened => closed > * resolution: => invalid > > > Comment: > > Another year of no effort on this one. It simply doesn't seem to be an > "issue", so it shouldn't be in the "issue tracker". Maybe this idea would > be better suited for the "Ideas" page in the wiki? > http://www.coreboot.org/Ideas Yup, done. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From anton.kochkov at gmail.com Sun Sep 5 17:55:45 2010 From: anton.kochkov at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQmtC+0YfQutC+0LI=?=) Date: Sun, 5 Sep 2010 19:55:45 +0400 Subject: [coreboot] [inteltool] renamed in bridgetool, added support of other non-Intel chipsets. Message-ID: inteltool: renamed in bridgetool, added support of other chipsets. Signed-off-by: Anton Kochkov --- -------------- next part -------------- A non-text attachment was scrubbed... Name: bridgetool.patch Type: application/octet-stream Size: 30259 bytes Desc: not available URL: From benbarszcz at gmail.com Sun Sep 5 18:23:58 2010 From: benbarszcz at gmail.com (BeBa) Date: Sun, 5 Sep 2010 18:23:58 +0200 Subject: [coreboot] filo prompt, how to access usb disk? Message-ID: <20100905182358.03d8c783@gmail.com> Hi, I just flashed a ga-6bxc and find no way to access its usb sticks. Filo has been compiled with IDE_NEW_DISK and USB_STACK. filo> kernel uda1:/vmlinuz spits out: File not found. I think that the devices are not seen at all. Is there a way to find it out? probe seems to check only IDE stuff, is that true? If so, then hwat else can I try? thanks BeBa From stefan.reinauer at coresystems.de Sun Sep 5 18:57:50 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Sun, 05 Sep 2010 18:57:50 +0200 Subject: [coreboot] filo prompt, how to access usb disk? In-Reply-To: <20100905182358.03d8c783@gmail.com> References: <20100905182358.03d8c783@gmail.com> Message-ID: <4C83CC0E.2060107@coresystems.de> On 9/5/10 6:23 PM, BeBa wrote: > Hi, > I just flashed a ga-6bxc and find no way to access its usb sticks. > Filo has been compiled with IDE_NEW_DISK and USB_STACK. > filo> kernel uda1:/vmlinuz > spits out: File not found. This means that there is no file with that name on the first USB device. > I think that the devices are not seen at all. Is there a way to find it > out? Did you check the serial log? Did you try plugging in the stick after FILO was up? > probe seems to check only IDE stuff, is that true? Yes. Regards, Stefan From benbarszcz at gmail.com Sun Sep 5 19:05:48 2010 From: benbarszcz at gmail.com (BeBa) Date: Sun, 5 Sep 2010 19:05:48 +0200 Subject: [coreboot] filo prompt, how to access usb disk? In-Reply-To: <4C83CC0E.2060107@coresystems.de> References: <20100905182358.03d8c783@gmail.com> <4C83CC0E.2060107@coresystems.de> Message-ID: <20100905190548.7f97476f@gmail.com> On Sun, 05 Sep 2010 18:57:50 +0200 Stefan Reinauer wrote: > Did you check the serial log? Did you try plugging in the stick after > FILO was up? I've plugged in an usb stick right now, I can see no output on the serial console. (serial log?). Tapping on the ESC button gives me a brisk view of what is in there but it is too quick for me to remember. I am using minicom 2.1 any hists? regards BeBa From benbarszcz at gmail.com Sun Sep 5 19:13:09 2010 From: benbarszcz at gmail.com (BeBa) Date: Sun, 5 Sep 2010 19:13:09 +0200 Subject: [coreboot] filo prompt, how to access usb disk? In-Reply-To: <4C83CC0E.2060107@coresystems.de> References: <20100905182358.03d8c783@gmail.com> <4C83CC0E.2060107@coresystems.de> Message-ID: <20100905191309.60ed7a2f@gmail.com> On Sun, 05 Sep 2010 18:57:50 +0200 Stefan Reinauer wrote: > This means that there is no file with that name on the first USB > device. I am positive on the file names that are there on the usb sticks. In addition some CDs do not boot, others do. Sysrcd doesn't, puppy 4.1 does. USB disks do not work, though, here. That's why my suspicion falls at the device descovery. regards BeBa From kevin at koconnor.net Sun Sep 5 20:21:08 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Sun, 5 Sep 2010 14:21:08 -0400 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method Message-ID: <20100905182108.GA32750@morn.localdomain> This patch enhances cbfstool so that it can support "cbfstool ROM add-lzma FILE NAME" calls. This is useful for callers that wish to add an lzma compressed raw file. Right now, SeaBIOS supports lzma raw files for things like floppy images. Today, adding one of these files requires a two step process - for example: $ lzma -zc /path/to/myfloppy.img > myfloppy.img.lzma $ cbfstool coreboot.rom add myfloppy.img.lzma floppyimg/MyFloppy.lzma raw Unfortunately, various versions of "lzma" are quirky and the above can be troublesome. With the patch below, a user need only execute: $ cbfstool coreboot.rom add-lzma myfloppy.img floppyimg/MyFloppy.lzma Signed-off-by: Kevin O'Connor Index: util/cbfstool/cbfs.h =================================================================== --- util/cbfstool/cbfs.h (revision 5777) +++ util/cbfstool/cbfs.h (working copy) @@ -73,6 +73,7 @@ #define CBFS_COMPONENT_OPTIONROM 0x30 #define CBFS_COMPONENT_BOOTSPLASH 0x40 #define CBFS_COMPONENT_RAW 0x50 +#define CBFS_COMPONENT_LZMA_RAW 0x40000050 #define CBFS_COMPONENT_VSA 0x51 #define CBFS_COMPONENT_MBI 0x52 #define CBFS_COMPONENT_MICROCODE 0x53 Index: util/cbfstool/common.c =================================================================== --- util/cbfstool/common.c (revision 5777) +++ util/cbfstool/common.c (working copy) @@ -142,6 +142,7 @@ {CBFS_COMPONENT_OPTIONROM, "optionrom"}, {CBFS_COMPONENT_BOOTSPLASH, "bootsplash"}, {CBFS_COMPONENT_RAW, "raw"}, + {CBFS_COMPONENT_LZMA_RAW, "lzma-raw"}, {CBFS_COMPONENT_VSA, "vsa"}, {CBFS_COMPONENT_MBI, "mbi"}, {CBFS_COMPONENT_MICROCODE, "microcode"}, Index: util/cbfstool/cbfstool.c =================================================================== --- util/cbfstool/cbfstool.c (revision 5777) +++ util/cbfstool/cbfstool.c (working copy) @@ -18,6 +18,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA */ +#include #include #include #include @@ -28,6 +29,7 @@ CMD_ADD, CMD_ADD_PAYLOAD, CMD_ADD_STAGE, + CMD_ADD_LZMA, CMD_CREATE, CMD_LOCATE, CMD_PRINT @@ -187,6 +189,73 @@ return 0; } +static int cbfs_add_lzma(int argc, char **argv) +{ + char *romname = argv[1]; + char *cmd = argv[2]; + void *rom = loadrom(romname); + + if (rom == NULL) { + printf("Could not load ROM image '%s'.\n", romname); + return 1; + } + + if (argc < 5) { + printf("not enough arguments to '%s'.\n", cmd); + return 1; + } + + char *filename = argv[3]; + char *cbfsname = argv[4]; + + uint32_t filesize = 0; + void *filedata = loadfile(filename, &filesize, 0, SEEK_SET); + if (filedata == NULL) { + printf("Could not load file '%s'.\n", filename); + return 1; + } + + uint32_t base = 0; + void *cbfsfile = NULL; + + uint32_t type = CBFS_COMPONENT_LZMA_RAW; + if (argc > 5) { + if (intfiletype(argv[5]) != ((uint64_t) - 1)) + type = intfiletype(argv[5]); + else + type = strtoul(argv[5], NULL, 0); + } + if (argc > 6) { + base = strtoul(argv[6], NULL, 0); + } + uint32_t compresssize = filesize; + void *compressed_data; + for (;;) { + compressed_data = malloc(compresssize); + if (! compressed_data) { + printf("Could not allocate %d space\n", compresssize); + return 1; + } + uint32_t actualsize = compresssize; + extern void do_lzma_compress(char *in, int in_len, + char *out, int *out_len); + do_lzma_compress(filedata, filesize, compressed_data, + &compresssize); + if (compresssize <= actualsize) + break; + // Try again with required size. + free(compressed_data); + } + + cbfsfile = create_cbfs_file(cbfsname, compressed_data, + &compresssize, type, &base); + if (add_file_to_cbfs(cbfsfile, compresssize, base)) + return 1; + if (writerom(romname, rom, romsize)) + return 1; + return 0; +} + static int cbfs_create(int argc, char **argv) { char *romname = argv[1]; @@ -249,6 +318,7 @@ {CMD_ADD, "add", cbfs_add}, {CMD_ADD_PAYLOAD, "add-payload", cbfs_add_payload}, {CMD_ADD_STAGE, "add-stage", cbfs_add_stage}, + {CMD_ADD_LZMA, "add-lzma", cbfs_add_lzma}, {CMD_CREATE, "create", cbfs_create}, {CMD_LOCATE, "locate", cbfs_locate}, {CMD_PRINT, "print", cbfs_print} @@ -265,6 +335,7 @@ " add FILE NAME TYPE [base address] Add a component\n" " add-payload FILE NAME [COMP] [base] Add a payload to the ROM\n" " add-stage FILE NAME [COMP] [base] Add a stage to the ROM\n" + " add-lzma FILE NAME [TYPE] [base] Lzma compress and add\n" " create SIZE BOOTBLOCK [ALIGN] Create a ROM file\n" " locate FILE NAME ALIGN Find a place for a file of that size\n" " print Show the contents of the ROM\n\n" From peter at stuge.se Sun Sep 5 20:26:41 2010 From: peter at stuge.se (Peter Stuge) Date: Sun, 5 Sep 2010 20:26:41 +0200 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <20100905182108.GA32750@morn.localdomain> References: <20100905182108.GA32750@morn.localdomain> Message-ID: <20100905182641.28794.qmail@stuge.se> Kevin O'Connor wrote: > This patch enhances cbfstool so that it can support "cbfstool ROM > add-lzma FILE NAME" calls. It has slightly different semantics than plain add. I think an option to enable compression would be nicer, so that there's just one generic add command. //Peter From timl at scintilla.utwente.nl Sun Sep 5 22:55:19 2010 From: timl at scintilla.utwente.nl (Tim ter Laak) Date: Sun, 5 Sep 2010 22:55:19 +0200 (CEST) Subject: [coreboot] [flashrom] Re: flashrom patch: add support for Abit AB-BM6 board In-Reply-To: <4C81B2EE.2060104@gmx.net> References: <4C81B2EE.2060104@gmx.net> Message-ID: On Sat, 4 Sep 2010, Carl-Daniel Hailfinger wrote: > Hi Tim, > > it seems your flashrom patch from exactly two years ago slipped through > the cracks until now. I'm very sorry about that. No problem. To be honest, I thought you as maintainers were, for understandable reasons, not too keen on letting in too many new board ID parameters at the time. I actually considered the thread properly closed, no bad feelings there. > Do you still own the board? If yes, could you please run download latest > flashrom (at least 0.9.2, preferably latest svn) and provide the output > of the following commands (as root): > flashrom -V > superiotool -deV I do, as a matter of fact I use it every now and again to program the occasional flash rom :) The full output is appended in-line to the end of this mail. > flashrom supports DMI matching since a few months, so it may be possible > to identify your board that way. And with superiotool output, we could > perhaps improve matching a bit more. > If DMI is useful on your board, we could try to match the DMI strings > and avoid the -m abit:ab-bm6 parameter for flashrom. The combination of the 'baseboard-manufacturer' and 'baseboard-product-name' DMI strings looks promising. (The empty contents of other strings is completely in line with expectations; after all the BIOS didn't bother to assign subsystem IDs to the PCI devices of the chipset either.) I'll be poking around in the source in the next few days to port my patch to the current version of flashrom. It would take a while to get up to speed again though, so I'm also open to testing other people's patches. Kind regards, Tim ter Laak. --- flashrom output: flashrom v0.9.2-r1153 on Linux 2.6.25-2-686 (i686), built with libpci 3.0.0, GCC 4.3.1, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OS timer resolution is 4 usecs, 200M loops per second, 10 myus = 13 us, 100 myus = 103 us, 1000 myus = 1002 us, 10000 myus = 10071 us, 16 myus = 20 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: " " DMI string system-product-name: " " DMI string system-version: " " DMI string baseboard-manufacturer: " http://www.abit.com.tw" DMI string baseboard-product-name: "i440BX-W977 (BM6)" DMI string baseboard-version: " " DMI string chassis-type: "Unknown" Found chipset "Intel PIIX4/4E/4M", enabling flash write... chipset PCI ID is 8086:7110, OK. This chipset supports the following protocols: Parallel. Probing for AMD Am29F010A/B, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BB, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BT, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F016D, 2048 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F080B, 1024 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV081B, 1024 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMIC A25L05PT, 64 KB: skipped. Probing for AMIC A25L05PU, 64 KB: skipped. Probing for AMIC A25L10PT, 128 KB: skipped. Probing for AMIC A25L10PU, 128 KB: skipped. Probing for AMIC A25L20PT, 256 KB: skipped. Probing for AMIC A25L20PU, 256 KB: skipped. Probing for AMIC A25L40PT, 512 KB: skipped. Probing for AMIC A25L40PU, 512 KB: skipped. Probing for AMIC A25L80P, 1024 KB: skipped. Probing for AMIC A25L16PT, 2048 KB: skipped. Probing for AMIC A25L16PU, 2048 KB: skipped. Probing for AMIC A25L512, 64 KB: skipped. Probing for AMIC A25L010, 128 KB: skipped. Probing for AMIC A25L020, 256 KB: skipped. Probing for AMIC A25L040, 512 KB: skipped. Probing for AMIC A25L080, 1024 KB: skipped. Probing for AMIC A25L016, 2048 KB: skipped. Probing for AMIC A25L032, 4096 KB: skipped. Probing for AMIC A25LQ032, 4096 KB: skipped. Probing for AMIC A29002B, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29002T, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for AMIC A49LF040A, 512 KB: skipped. Probing for ASD AE49F2008, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT25DF021, 256 KB: skipped. Probing for Atmel AT25DF041A, 512 KB: skipped. Probing for Atmel AT25DF081, 1024 KB: skipped. Probing for Atmel AT25DF081A, 1024 KB: skipped. Probing for Atmel AT25DF161, 2048 KB: skipped. Probing for Atmel AT25DF321, 4096 KB: skipped. Probing for Atmel AT25DF321A, 4096 KB: skipped. Probing for Atmel AT25DF641, 8192 KB: skipped. Probing for Atmel AT25DQ161, 2048 KB: skipped. Probing for Atmel AT25F512B, 64 KB: skipped. Probing for Atmel AT25FS010, 128 KB: skipped. Probing for Atmel AT25FS040, 512 KB: skipped. Probing for Atmel AT26DF041, 512 KB: skipped. Probing for Atmel AT26DF081A, 1024 KB: skipped. Probing for Atmel AT26DF161, 2048 KB: skipped. Probing for Atmel AT26DF161A, 2048 KB: skipped. Probing for Atmel AT26F004, 512 KB: skipped. Probing for Atmel AT29C512, 64 KB: probe_jedec_common: id1 0x41, id2 0xa4, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT29C010A, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT29C020, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT29C040A, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT45CS1282, 16896 KB: skipped. Probing for Atmel AT45DB011D, 128 KB: skipped. Probing for Atmel AT45DB021D, 256 KB: skipped. Probing for Atmel AT45DB041D, 512 KB: skipped. Probing for Atmel AT45DB081D, 1024 KB: skipped. Probing for Atmel AT45DB161D, 2048 KB: skipped. Probing for Atmel AT45DB321C, 4224 KB: skipped. Probing for Atmel AT45DB321D, 4096 KB: skipped. Probing for Atmel AT45DB642D, 8192 KB: skipped. Probing for Atmel AT49BV512, 64 KB: probe_jedec_common: id1 0x41, id2 0xa4, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49F020, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49F002(N), 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49F002(N)T, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for EMST F49B002UA, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for EMST F25L008A, 1024 KB: skipped. Probing for Eon EN25B05, 64 KB: skipped. Probing for Eon EN25B05T, 64 KB: skipped. Probing for Eon EN25B10, 128 KB: skipped. Probing for Eon EN25B10T, 128 KB: skipped. Probing for Eon EN25B20, 256 KB: skipped. Probing for Eon EN25B20T, 256 KB: skipped. Probing for Eon EN25B40, 512 KB: skipped. Probing for Eon EN25B40T, 512 KB: skipped. Probing for Eon EN25B80, 1024 KB: skipped. Probing for Eon EN25B80T, 1024 KB: skipped. Probing for Eon EN25B16, 2048 KB: skipped. Probing for Eon EN25B16T, 2048 KB: skipped. Probing for Eon EN25B32, 4096 KB: skipped. Probing for Eon EN25B32T, 4096 KB: skipped. Probing for Eon EN25B64, 8192 KB: skipped. Probing for Eon EN25B64T, 8192 KB: skipped. Probing for Eon EN25D16, 2048 KB: skipped. Probing for Eon EN25F05, 64 KB: skipped. Probing for Eon EN25F10, 128 KB: skipped. Probing for Eon EN25F20, 256 KB: skipped. Probing for Eon EN25F40, 512 KB: skipped. Probing for Eon EN25F80, 1024 KB: skipped. Probing for Eon EN25F16, 2048 KB: skipped. Probing for Eon EN25F32, 4096 KB: skipped. Probing for Eon EN29F010, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F002(A)(N)B, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F002(A)(N)T, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F004BC, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F004TC, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F400BC, 512 KB: probe_m29f400bt: id1 0x25, id2 0x2d Probing for Fujitsu MBM29F400TC, 512 KB: probe_m29f400bt: id1 0x25, id2 0x2d Probing for Hyundai HY29F002T, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Hyundai HY29F002B, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F001BX-B, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F001BX-T, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F002BC-T, 256 KB: probe_82802ab: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004S5, 512 KB: probe_82802ab: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004BV/BE-B, 512 KB: probe_82802ab: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004BV/BE-T, 512 KB: probe_82802ab: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F400BV/CV/CE-B, 512 KB: probe_82802ab: id1 0x25, id2 0x2d, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F400BV/CV/CE-T, 512 KB: probe_82802ab: id1 0x25, id2 0x2d, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 KB: skipped. Probing for Intel 82802AC, 1024 KB: skipped. Probing for Macronix MX25L512, 64 KB: skipped. Probing for Macronix MX25L1005, 128 KB: skipped. Probing for Macronix MX25L2005, 256 KB: skipped. Probing for Macronix MX25L4005, 512 KB: skipped. Probing for Macronix MX25L8005, 1024 KB: skipped. Probing for Macronix MX25L1605, 2048 KB: skipped. Probing for Macronix MX25L1635D, 2048 KB: skipped. Probing for Macronix MX25L3205, 4096 KB: skipped. Probing for Macronix MX25L3235D, 4096 KB: skipped. Probing for Macronix MX25L6405, 8192 KB: skipped. Probing for Macronix MX25L12805, 16384 KB: skipped. Probing for Macronix MX29F001B, 128 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F001T, 128 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F002B, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F002T, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29LV040, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51000B, 64 KB: probe_jedec_common: id1 0x41, id2 0xa4, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51000T, 64 KB: probe_jedec_common: id1 0x41, id2 0xa4, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51400B, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51400T, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29LC51000, 64 KB: probe_jedec_common: id1 0x41, id2 0xa4, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29LC51001, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29LC51002, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Numonyx M25PE10, 128 KB: skipped. Probing for Numonyx M25PE20, 256 KB: skipped. Probing for Numonyx M25PE40, 512 KB: skipped. Probing for Numonyx M25PE80, 1024 KB: skipped. Probing for Numonyx M25PE16, 2048 KB: skipped. Probing for PMC Pm25LV010, 128 KB: skipped. Probing for PMC Pm25LV016B, 2048 KB: skipped. Probing for PMC Pm25LV020, 256 KB: skipped. Probing for PMC Pm25LV040, 512 KB: skipped. Probing for PMC Pm25LV080B, 1024 KB: skipped. Probing for PMC Pm25LV512, 64 KB: skipped. Probing for PMC Pm29F002T, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm29F002B, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV010, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV020, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV040, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 KB: skipped. Probing for PMC Pm49FL004, 512 KB: skipped. Probing for Sanyo LF25FW203A, 2048 KB: skipped. Probing for Sharp LHF00L04, 1024 KB: skipped. Probing for Spansion S25FL008A, 1024 KB: skipped. Probing for Spansion S25FL016A, 2048 KB: skipped. Probing for SST SST25VF016B, 2048 KB: skipped. Probing for SST SST25VF032B, 4096 KB: skipped. Probing for SST SST25VF064C, 8192 KB: skipped. Probing for SST SST25VF040.REMS, 512 KB: skipped. Probing for SST SST25VF040B, 512 KB: skipped. Probing for SST SST25LF040A.RES, 512 KB: skipped. Probing for SST SST25VF040B.REMS, 512 KB: skipped. Probing for SST SST25VF080B, 1024 KB: skipped. Probing for SST SST28SF040A, 512 KB: probe_82802ab: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SST SST29EE010, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for SST SST29LE010, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for SST SST29EE020A, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SST SST29LE020, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SST SST39SF512, 64 KB: probe_jedec_common: id1 0x41, id2 0xa4, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39SF010A, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for SST SST39SF020A, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SST SST39SF040, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF512, 64 KB: probe_jedec_common: id1 0x41, id2 0xa4, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF010, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF020, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF040, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SST SST39VF080, 1024 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 KB: skipped. Probing for SST SST49LF003A/B, 384 KB: skipped. Probing for SST SST49LF004A/B, 512 KB: skipped. Probing for SST SST49LF004C, 512 KB: skipped. Probing for SST SST49LF008A, 1024 KB: skipped. Probing for SST SST49LF008C, 1024 KB: skipped. Probing for SST SST49LF016C, 2048 KB: skipped. Probing for SST SST49LF020, 256 KB: skipped. Probing for SST SST49LF020A, 256 KB: skipped. Probing for SST SST49LF040, 512 KB: skipped. Probing for SST SST49LF040B, 512 KB: skipped. Probing for SST SST49LF080A, 1024 KB: skipped. Probing for SST SST49LF160C, 2048 KB: skipped. Probing for ST M25P05-A, 64 KB: skipped. Probing for ST M25P05.RES, 64 KB: skipped. Probing for ST M25P10-A, 128 KB: skipped. Probing for ST M25P10.RES, 128 KB: skipped. Probing for ST M25P20, 256 KB: skipped. Probing for ST M25P40, 512 KB: skipped. Probing for ST M25P40-old, 512 KB: skipped. Probing for ST M25P80, 1024 KB: skipped. Probing for ST M25P16, 2048 KB: skipped. Probing for ST M25P32, 4096 KB: skipped. Probing for ST M25P64, 8192 KB: skipped. Probing for ST M25P128, 16384 KB: skipped. Probing for ST M29F002B, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for ST M29F002T/NT, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for ST M29F040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for ST M29F400BB, 512 KB: probe_m29f400bt: id1 0x25, id2 0x2d Probing for ST M29F400BT, 512 KB: probe_m29f400bt: id1 0x25, id2 0x2d Probing for ST M29W010B, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for ST M29W040B, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for ST M29W512B, 64 KB: probe_jedec_common: id1 0x41, id2 0xa4, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 KB: skipped. Probing for ST M50FLW040B, 512 KB: skipped. Probing for ST M50FLW080A, 1024 KB: skipped. Probing for ST M50FLW080B, 1024 KB: skipped. Probing for ST M50FW002, 256 KB: skipped. Probing for ST M50FW016, 2048 KB: skipped. Probing for ST M50FW040, 512 KB: skipped. Probing for ST M50FW080, 1024 KB: skipped. Probing for ST M50LPW116, 2048 KB: skipped. Probing for SyncMOS/MoselVitelic {F,S,V}29C51001B, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51001T, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51002B, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51002T, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51004B, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51004T, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {S,V}29C31004B, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {S,V}29C31004T, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for TI TMS29F002RB, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for TI TMS29F002RT, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Winbond W25Q80, 1024 KB: skipped. Probing for Winbond W25Q16, 2048 KB: skipped. Probing for Winbond W25Q32, 4096 KB: skipped. Probing for Winbond W25Q64, 8192 KB: skipped. Probing for Winbond W25x10, 128 KB: skipped. Probing for Winbond W25x20, 256 KB: skipped. Probing for Winbond W25x40, 512 KB: skipped. Probing for Winbond W25x80, 1024 KB: skipped. Probing for Winbond W25x16, 2048 KB: skipped. Probing for Winbond W25x32, 4096 KB: skipped. Probing for Winbond W25x64, 8192 KB: skipped. Probing for Winbond W29C011, 128 KB: probe_jedec_common: id1 0x25, id2 0xb1, id1 is normal flash content, id2 is normal flash content Probing for Winbond W29C020C, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Winbond W29C040P, 512 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Winbond W29EE011, 128 KB: Probing disabled for Winbond W29EE011 because the probing sequence puts the AMIC A49LF040A in a funky state. Use 'flashrom -c W29EE011' if you have a board with this chip. Probing for Winbond W39V040A, 512 KB: skipped. Probing for Winbond W39V040B, 512 KB: skipped. Probing for Winbond W39V040C, 512 KB: skipped. Probing for Winbond W39V040FA, 512 KB: skipped. Probing for Winbond W39V080A, 1024 KB: skipped. Probing for Winbond W49F002U, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49F020, 256 KB: probe_jedec_common: id1 0x25, id2 0x4c, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002A, 256 KB: skipped. Probing for Winbond W49V002FA, 256 KB: skipped. Probing for Winbond W39V080FA, 1024 KB: skipped. Probing for Winbond W39V080FA (dual mode), 512 KB: skipped. Probing for AMIC unknown AMIC SPI chip, 0 KB: skipped. Probing for Atmel unknown Atmel SPI chip, 0 KB: skipped. Probing for Eon unknown Eon SPI chip, 0 KB: skipped. Probing for Macronix unknown Macronix SPI chip, 0 KB: skipped. Probing for PMC unknown PMC SPI chip, 0 KB: skipped. Probing for SST unknown SST SPI chip, 0 KB: skipped. Probing for ST unknown ST SPI chip, 0 KB: skipped. Probing for Sanyo unknown Sanyo SPI chip, 0 KB: skipped. Probing for Generic unknown SPI chip (RDID), 0 KB: skipped. Probing for Generic unknown SPI chip (REMS), 0 KB: skipped. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. --- superiotool output: superiotool r5728 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for ITE Super I/O (init=standard) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=standard) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0x00, rev=0x00 Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0x00, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... Found Winbond W83977EF/EG (id=0x52, rev=0xf1) at 0x3f0 Register dump: idx 02 20 21 22 23 24 25 26 28 2a 2b 2c 2d 2e 2f val ff 52 f1 ff fe 84 00 00 00 00 00 00 00 00 ff def RR 52 MM ff fe MM 00 MM 00 00 00 00 RR RR RR LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 01 03 f0 06 02 0c 00 ff 00 00 def 01 03 f0 06 02 0e 00 ff 00 00 LDN 0x01 (Parallel port) idx 30 60 61 70 74 f0 val 01 03 78 07 03 07 def 01 03 78 07 04 3f LDN 0x02 (COM1) idx 30 60 61 70 f0 val 00 00 00 00 00 def 01 03 f8 04 00 LDN 0x03 (COM2) idx 30 60 61 70 f0 f1 val 00 00 00 00 00 00 def 01 02 f8 03 00 00 LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 42 def 01 00 60 00 64 01 0c 83 LDN 0x07 (GPIO 1) idx 30 60 61 62 63 64 65 70 72 e0 e1 e2 e3 e4 e5 e6 e7 f1 val 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 def 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 LDN 0x08 (GPIO 2) idx 30 60 61 70 72 e8 e9 ea eb ec ed f0 f1 f2 f3 f4 val 00 00 00 00 00 01 01 01 01 01 01 00 ff 00 00 00 def 00 00 00 00 00 01 01 01 01 01 01 00 RR 00 00 00 LDN 0x0a (ACPI) idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f3 f4 f6 f7 f9 fe ff val 00 00 00 ed ff 00 00 00 00 00 00 8f 3c 00 00 00 00 00 00 def 00 00 00 00 MM MM MM 00 00 00 00 00 00 00 00 00 00 RR RR Hardware monitor (0x0004) Probing for Winbond Super I/O (init=0x88) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for VIA Super I/O at 0x3f0... PCI device 1106:0686 not found. From kevin at koconnor.net Sun Sep 5 23:34:07 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Sun, 5 Sep 2010 17:34:07 -0400 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <20100905182641.28794.qmail@stuge.se> References: <20100905182108.GA32750@morn.localdomain> <20100905182641.28794.qmail@stuge.se> Message-ID: <20100905213407.GA12340@morn.localdomain> On Sun, Sep 05, 2010 at 08:26:41PM +0200, Peter Stuge wrote: > Kevin O'Connor wrote: > > This patch enhances cbfstool so that it can support "cbfstool ROM > > add-lzma FILE NAME" calls. > > It has slightly different semantics than plain add. I think an option > to enable compression would be nicer, so that there's just one > generic add command. There are three add commands right now: add, add-payload, add-stage. The cbfstool code can't easily handle per-command options. So, doing something like "cbfstool ROM add -c lzma FILE NAME" wont be easy. I can refactor the code so that "add" and "add-lzma" share the same code. Another possibility would be to add getopt to cbfstool and move compression selection for all add commands to it. For example, something like "cbfstool -c lzma ROM add-payload FILE NAME". However, that would require changing the build to use the new form everywhere. -Kevin From scott at notabs.org Mon Sep 6 05:32:17 2010 From: scott at notabs.org (Scott Duplichan) Date: Sun, 5 Sep 2010 22:32:17 -0500 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' References: <0703EF8685AB4BB091774844213B7DF6@m3a78> Message-ID: <2F6225DCDF084C9D8CFD78A8C6B10AA3@m3a78> Resend: one more attempt to get this patch right. The previous submission included the patch as an attachement. The attachment contained Windows-style line endings. The attachment is missing from the mailing list archive: "A non-text attachment was scrubbed". http://www.coreboot.org/pipermail/coreboot/2010-September/060090.html This time the patch is inline, which hopefully will solve the eol-style problem. The attached patch allows the use of gcc 4.5.0 for AMD builds. The AMD Tilapia BIOS built with gcc 4.5.0 and this patch has passed testing on the simnow target only. Can someone confirm that the attached patch allows an AMD family 10h BIOS such as Tilapia to work on real hardware? At the same time I will try to get the change tested on real hardware. Root cause: After function STOP_CAR_AND_CPU disables cache as ram, the cache as ram stack can no longer be used. Called functions must be inlined to avoid stack usage. Also, the compiler must keep local variables register based and not allocated them from the stack. With gcc 4.5.0, some functions declared as inline are not being inlined. This patch forces these functions to always be inlined by adding the qualifier __attribute__((always_inline)) to their declaration. Update: Still no test reports for real hardware are available. If we cannot get this change tested on real hardware, I suggest we conditionally compile in only if gcc 4.5.0 or later is used. Thanks, Scott Signed-off-by: Scott Duplichan Index: src/include/cpu/x86/msr.h =================================================================== --- src/include/cpu/x86/msr.h (revision 5777) +++ src/include/cpu/x86/msr.h (working copy) @@ -29,7 +29,7 @@ msr_t msr; } msrinit_t; -static inline msr_t rdmsr(unsigned index) +static inline __attribute__((always_inline)) msr_t rdmsr(unsigned index) { msr_t result; __asm__ __volatile__ ( @@ -40,7 +40,7 @@ return result; } -static inline void wrmsr(unsigned index, msr_t msr) +static inline __attribute__((always_inline)) void wrmsr(unsigned index, msr_t msr) { __asm__ __volatile__ ( "wrmsr" Index: src/include/cpu/x86/cache.h =================================================================== --- src/include/cpu/x86/cache.h (revision 5777) +++ src/include/cpu/x86/cache.h (working copy) @@ -74,7 +74,7 @@ asm volatile("invd" ::: "memory"); } -static inline void enable_cache(void) +static inline __attribute__((always_inline)) void enable_cache(void) { unsigned long cr0; cr0 = read_cr0(); @@ -82,7 +82,7 @@ write_cr0(cr0); } -static inline void disable_cache(void) +static inline __attribute__((always_inline)) void disable_cache(void) { /* Disable and write back the cache */ unsigned long cr0; From condor at stz-bg.com Mon Sep 6 09:33:31 2010 From: condor at stz-bg.com (Condor) Date: Mon, 6 Sep 2010 10:33:31 +0300 Subject: [coreboot] Question about did my MB is supported Message-ID: <17cbabbf32cfd76a10071882260e5e12.squirrel@mail.stz-bg.com> Hello all, i read information on the coreboot site but i still doubt did my MB is supported. I expect to run Linux with lilo and Windows 7 32 bit. Here is information for my MB answering questions from FAQ: Will coreboot work on my machine? 1. My board vendor is ASUSTeK, CPU P4 2.8 GHz, no idea for others things :S 2. lspci output: # lspci -tvnn -[0000:00]-+-00.0 Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface [8086:2570] +-01.0-[01]----00.0 ATI Technologies Inc RV630 PRO AGP [Radeon HD 2600 PRO AGP] [1002:9587] +-06.0 Intel Corporation 82865G/PE/P Processor to I/O Memory Interface [8086:2576] +-1d.0 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 [8086:24d2] +-1d.1 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 [8086:24d4] +-1d.2 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 [8086:24d7] +-1d.3 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 [8086:24de] +-1d.7 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller [8086:24dd] +-1e.0-[02]----05.0 Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller [11ab:4320] +-1f.0 Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge [8086:24d0] +-1f.1 Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller [8086:24db] +-1f.2 Intel Corporation 82801EB (ICH5) SATA Controller [8086:24d1] +-1f.3 Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller [8086:24d3] \-1f.5 Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller [8086:24d5] 3. IO Chip: Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Found Winbond W83627THF/THG (id=0x82, rev=0x84) at 0x2e Register dump: idx 20 21 22 23 24 25 26 28 29 2a 2b 2c 2d 2e 2f val 82 84 ff fe e2 00 00 20 00 00 1a 58 20 00 ff def 82 NA ff 00 MM 00 MM 00 00 00 MM MM MM 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 01 03 f0 06 02 0e 00 ff 00 00 def 01 03 f0 06 02 0e 00 ff 00 00 LDN 0x01 (Parallel port) idx 30 60 61 70 74 f0 val 00 03 78 00 04 3c def 01 03 78 07 04 3f LDN 0x02 (COM1) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 01 03 f8 04 00 LDN 0x03 (COM2) idx 30 60 61 70 f0 f1 val 01 02 f8 03 00 00 def 01 02 f8 03 00 00 LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 83 def 01 00 60 00 64 01 0c 80 LDN 0x07 (GPIO 1, GPIO 5, game port, MIDI port) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 val 08 02 01 03 30 00 ff ff ff ff d3 00 def 00 02 01 03 30 09 ff 00 00 ff 00 00 LDN 0x08 (GPIO 2) idx 30 f0 f1 f2 f3 f4 f5 f6 f7 val 01 ff 38 00 00 ff 00 00 00 def 00 ff 00 00 00 RR 00 00 00 LDN 0x09 (GPIO 3, GPIO 4) idx 30 f0 f1 f2 f3 f4 f5 f6 val 03 ef 40 00 00 fe 01 00 def 00 ff 00 00 00 ff 00 00 LDN 0x0a (ACPI) idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f3 f4 f6 f7 f9 fe ff val 01 00 00 00 ae 04 00 00 00 10 00 af 37 00 00 00 00 00 00 def 00 00 00 00 MM MM 00 00 00 00 00 00 00 00 00 00 00 RR RR LDN 0x0b (Hardware monitor) idx 30 60 61 70 val 01 02 90 00 def 00 00 00 00 4. flashrom -v ./flashrom -V flashrom v0.9.2-r1153 on Linux 2.6.35.4-smp (i686), built with libpci 3.1.5, GCC 4.4.4, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OS timer resolution is 1 usecs, 1579M loops per second, 10 myus = 10 us, 100 myus = 94 us, 1000 myus = 1015 us, 10000 myus = 12684 us, 4 myus = 5 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "System manufacturer" DMI string system-product-name: "System Product Name" DMI string system-version: "System Version" DMI string baseboard-manufacturer: "ASUSTeK Computer Inc." DMI string baseboard-product-name: "P4P800SE" DMI string baseboard-version: "Rev 2.xx" DMI string chassis-type: "" Found chipset "Intel ICH5/ICH5R", enabling flash write... chipset PCI ID is 8086:24d0, BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x0 OK. This chipset supports the following protocols: FWH. --- cut --- Probing for PMC Pm49FL004, 512 KB: probe_jedec_common: id1 0x9d, id2 0x6e Found chip "PMC Pm49FL004" (512 KB, LPC,FWH) at physical address 0xfff80000. Probing for Sanyo LF25FW203A, 2048 KB: skipped. --- cut --- 5. URL of my main board: It's seems is very hard to be find but i think is that one: http://support.asus.com/search/search.aspx?keyword=p4p800se&SLanguage=en-us 6. No idea what can be that information. Thank you. Regards, Condor From JRottmann at LiPPERTEmbedded.de Mon Sep 6 10:09:27 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Mon, 06 Sep 2010 10:09:27 +0200 Subject: [coreboot] [commit] r5775 - in trunk/src/mainboard/lippert: roadrunner-lx spacerunner-lx In-Reply-To: <4C81427B.2020709@coresystems.de> References: <4C81427B.2020709@coresystems.de> Message-ID: <4C84A1B7.3030102@LiPPERTEmbedded.de> Hi, >> - io 0x62 = 0x1220 >> - io 0x64 = 0x1200 >> + io 0x62 = 0x1220 # Simple I/O >> + io 0x64 = 0x1228 # SPI > you might be seeing a double allocation because coreboot > starts dynamic io resources at 0x1000 while static ones > usually live below 0x1000. Yes, I'm aware of that. Not only coreboot, our standard BIOS, too, starts assigning PCI I/O resources at 0x1000. The problem is that the 1220 base addr for Simple I/O (GPIOs) had already been in use from the start, in our very first standard BIOSes, which Insyde had done for us. Later we bought the sources and I took over, but I couldn't change the GPIOs' addresses any more, it might have broken existing customers' applications. :-( So I'm stuck with 1220 for GPIOs. Only moving SPI seemed safe, so I put it adjacent and marked 1220-122F as reserved with ACPI PnP. Luckily our standard BIOS always assigns the first PCI resource at 1000 and the next at 1400, so we never experienced any actual conflicts so far. Thanks a lot for paying attention!! Cheers, Jens From arne.gleditsch at numascale.com Mon Sep 6 10:12:06 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Mon, 06 Sep 2010 10:12:06 +0200 Subject: [coreboot] SuperMicro h8dmr-i2 slowness in v4 In-Reply-To: <4C812B6D020000FE0000D531@mail.lkfd.net> (Nick Lemberger's message of "Fri, 03 Sep 2010 17:07:57 -0500") References: <4C812B6D020000FE0000D531@mail.lkfd.net> Message-ID: <87aanv1eax.fsf@taniquetil.gledits.ch> "Nick Lemberger" writes: > Hello, > > I'm having some trouble with current releases of coreboot on a > Supermicro H8DMR-i2. > > The initial problem, it takes about 2 minutes to show the: > "coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting..." > and equally as long after the warm reset. > > The second, the system freezes at "Clearning initial memory region:" for > about a half hour before proceeding. After that, everything works as > expected. > > There has been some list chatter about a similar problem with the H8DME, > but that was based upon the H8DMR code so it's odd that it found it's > way here. I've attached the full serial output if that's at all useful. Can you see if the patches posted in http://article.gmane.org/gmane.linux.bios/57707 make any difference for you? -- Arne. From patrick at georgi-clan.de Mon Sep 6 11:40:10 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Mon, 06 Sep 2010 11:40:10 +0200 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <20100905213407.GA12340@morn.localdomain> References: <20100905182108.GA32750@morn.localdomain> <20100905182641.28794.qmail@stuge.se> <20100905213407.GA12340@morn.localdomain> Message-ID: <4C84B6FA.4040203@georgi-clan.de> Am 05.09.2010 23:34, schrieb Kevin O'Connor: > Another possibility would be to add getopt to cbfstool and move > compression selection for all add commands to it. For example, > something like "cbfstool -c lzma ROM add-payload FILE NAME". However, > that would require changing the build to use the new form everywhere. We could move compression out of subheader fields into the regular file header, so every file could be compressed (though for some it wouldn't be useful, eg. romstages or EC roms), and then make this a global variable. However, we had our reasons not to do this. Pick your poison Patrick From stefan.reinauer at coresystems.de Mon Sep 6 11:43:30 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Mon, 06 Sep 2010 11:43:30 +0200 Subject: [coreboot] Question about did my MB is supported In-Reply-To: <17cbabbf32cfd76a10071882260e5e12.squirrel@mail.stz-bg.com> References: <17cbabbf32cfd76a10071882260e5e12.squirrel@mail.stz-bg.com> Message-ID: <4C84B7C2.4060708@coresystems.de> On 9/6/10 9:33 AM, Condor wrote: > Hello all, > i read information on the coreboot site but i still doubt did my MB is > supported. I expect to run Linux with lilo and Windows 7 32 bit. > > Here is information for my MB answering questions from FAQ: Will coreboot > work on my machine? > > # lspci -tvnn > -[0000:00]-+-00.0 Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub > Interface [8086:2570] Dear Condor, sorry to say, coreboot does not support the i865 north bridge yet. Stefan From stefan.reinauer at coresystems.de Mon Sep 6 12:03:27 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Mon, 06 Sep 2010 12:03:27 +0200 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <2F6225DCDF084C9D8CFD78A8C6B10AA3@m3a78> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <2F6225DCDF084C9D8CFD78A8C6B10AA3@m3a78> Message-ID: <4C84BC6F.3080601@coresystems.de> On 9/6/10 5:32 AM, Scott Duplichan wrote: > Resend: one more attempt to get this patch right. The previous > submission included the patch as an attachement. The attachment > contained Windows-style line endings. The attachment is missing > from the mailing list archive: "A non-text attachment was scrubbed". > http://www.coreboot.org/pipermail/coreboot/2010-September/060090.html The patch is there, just click on the link below the message. (Unfortunately with a wrong name) > Root cause: After function STOP_CAR_AND_CPU disables cache as > ram, the cache as ram stack can no longer be used. Called > functions must be inlined to avoid stack usage. Also, the > compiler must keep local variables register based and not > allocated them from the stack. With gcc 4.5.0, some functions > declared as inline are not being inlined. This patch forces > these functions to always be inlined by adding the qualifier > __attribute__((always_inline)) to their declaration. I think this explanation should go into the two files that get the always_inline attributes so people looking at this code 3ys (or months) from now know why it was done this way. > Update: Still no test reports for real hardware are available. > If we cannot get this change tested on real hardware, I suggest > we conditionally compile in only if gcc 4.5.0 or later is used. I think it's safe to use it as is, though I don't have a Tilapia to test it on. > Signed-off-by: Scott Duplichan With the explanation above added to each of the two files, this is Acked-by: Stefan Reinauer However, I think we should additionally look at "fixing" AMD's CAR code to not call C functions with neither CAR or RAM backing them. I reworked all CAR code to behave like that a while ago (ie. , but the AMD code was considerably more complex . The complexity of the code also brings along some bugs that currently need workarounds[1]. A proper fix for this would be nice, but it's hard to determine what's wrong with the current code. Should you have some insights on this, please share! Stefan [1] http://article.gmane.org/gmane.linux.bios/57707 -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From stefan.reinauer at coresystems.de Mon Sep 6 12:08:03 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Mon, 06 Sep 2010 12:08:03 +0200 Subject: [coreboot] AMD cache setup is broken (was: SuperMicro h8dmr-i2 slowness in v4) In-Reply-To: <87aanv1eax.fsf@taniquetil.gledits.ch> References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> Message-ID: <4C84BD83.2030502@coresystems.de> On 9/6/10 10:12 AM, Arne Georg Gleditsch wrote: > "Nick Lemberger" writes: >> Hello, >> >> I'm having some trouble with current releases of coreboot on a >> Supermicro H8DMR-i2. >> >> The initial problem, it takes about 2 minutes to show the: >> "coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting..." >> and equally as long after the warm reset. >> >> The second, the system freezes at "Clearning initial memory region:" for >> about a half hour before proceeding. After that, everything works as >> expected. >> >> There has been some list chatter about a similar problem with the H8DME, >> but that was based upon the H8DMR code so it's odd that it found it's >> way here. I've attached the full serial output if that's at all useful. > Can you see if the patches posted in > http://article.gmane.org/gmane.linux.bios/57707 make any difference for > you? > Did we ever figure out what is causing this? The patch would require 4KB more stack on all supported systems, so if we can we should do things differently. Also, it's not really guaranteed that the code works from the new location since we don't compile coreboot with -fPIC (and as far as I understand the GCC guys, even that would not help), so I am a bit hesitant to check this in. Stefan From arne.gleditsch at numascale.com Mon Sep 6 12:49:41 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Mon, 06 Sep 2010 12:49:41 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <4C84BD83.2030502@coresystems.de> (Stefan Reinauer's message of "Mon, 06 Sep 2010 12:08:03 +0200") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> Message-ID: <8762yj170a.fsf@taniquetil.gledits.ch> Stefan Reinauer writes: >> Can you see if the patches posted in >> http://article.gmane.org/gmane.linux.bios/57707 make any difference for >> you? >> > Did we ever figure out what is causing this? The last time I really dug into this, it was fairly obvious that it was caused by instruction fetch thrashing towards the ROM. I tried to amend this with MTRR settings, but I was unable to make that work correctly. For some reason it seemed like the HT requests were sublty changed when the MTRR was applied, and didn't hit the legacy southbridge properly. > The patch would require 4KB more stack on all supported systems, so if > we can we should do things differently. It doesn't have to be stack, but it is nice to have it memory mananged in some way. The unrv2b patch I posted addressing the same problem was even more kludgy. > Also, it's not really guaranteed that the code works from the new > location since we don't compile coreboot with -fPIC (and as far as I > understand the GCC guys, even that would not help), so I am a bit > hesitant to check this in. Agreed, it is a bit icky. Not sure what the best way to handle that is, though. On the pro side, I assume breakage here is going to be obvious, and (supposing these patches actually help Nick) this is an issue people are running into with some regularity. -- Arne. From svn at coreboot.org Mon Sep 6 16:00:03 2010 From: svn at coreboot.org (coreboot tracker) Date: Mon, 06 Sep 2010 16:00:03 +0200 Subject: [coreboot] Trac reminder: list of new ticket(s) Message-ID: An HTML attachment was scrubbed... URL: From kevin at koconnor.net Mon Sep 6 15:49:14 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 09:49:14 -0400 Subject: [coreboot] [PATCH] cbfstool default type for add command. Message-ID: <20100906134914.GA8531@morn.localdomain> The "raw" type is a good default for the "add" command. Allow the user to add files without specifying a type ("raw" will be assumed). Signed-off-by: Kevin O'Connor --- util/cbfstool/cbfstool.c | 16 +++++++--------- 1 files changed, 7 insertions(+), 9 deletions(-) diff --git a/util/cbfstool/cbfstool.c b/util/cbfstool/cbfstool.c index 7c22a65..311a3e8 100644 --- a/util/cbfstool/cbfstool.c +++ b/util/cbfstool/cbfstool.c @@ -70,15 +70,13 @@ static int cbfs_add(int argc, char **argv) uint32_t base = 0; void *cbfsfile = NULL; - if (argc < 6) { - printf("not enough arguments to 'add'.\n"); - return 1; + uint32_t type = CBFS_COMPONENT_RAW; + if (argc > 5) { + if (intfiletype(argv[5]) != ((uint64_t) - 1)) + type = intfiletype(argv[5]); + else + type = strtoul(argv[5], NULL, 0); } - uint32_t type; - if (intfiletype(argv[5]) != ((uint64_t) - 1)) - type = intfiletype(argv[5]); - else - type = strtoul(argv[5], NULL, 0); if (argc > 6) { base = strtoul(argv[6], NULL, 0); } @@ -332,7 +330,7 @@ void usage(void) " cbfstool FILE COMMAND [PARAMETERS]...\n\n" "OPTIONs:\n" " -h Display this help message\n\n" "COMMANDs:\n" - " add FILE NAME TYPE [base address] Add a component\n" + " add FILE NAME [TYPE] [base address] Add a component\n" " add-payload FILE NAME [COMP] [base] Add a payload to the ROM\n" " add-stage FILE NAME [COMP] [base] Add a stage to the ROM\n" " add-lzma FILE NAME [TYPE] [base] Lzma compress and add\n" -- 1.7.2.2 From JRottmann at LiPPERTEmbedded.de Mon Sep 6 16:33:26 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Mon, 06 Sep 2010 16:33:26 +0200 Subject: [coreboot] CS5536 OHCI not working In-Reply-To: <4C812EE3.1010707@LiPPERTEmbedded.de> References: <4C811098.8010101@LiPPERTEmbedded.de> <4C8120E9.8010000@georgi-clan.de> <4C812EE3.1010707@LiPPERTEmbedded.de> Message-ID: <4C84FBB6.8090407@LiPPERTEmbedded.de> Hi Peter, >> It's possible that this is more of a problem of your thumb drive >> than of the USB stack. > Indeed. Especially if the drive is actually a high speed device then > frequently it will not work perfectly running at full speed. In the meantime I've tested 1 USB keyboard and 8 storage devices from different vendors (2 card readers, 1 M-Systems uDOC, 5 thumb drives, 1 of which is an ancient USB 1.1 only). None worked. > An interesting data point would be for you to attach the drive when > the system is running Linux, *without* the ehci_hcd driver loaded, > only ohci_hcd. Tried that with the 1st card reader which had made me write the original message. Works with OHCI-only in Linux. Cheers, Jens From kevin at koconnor.net Mon Sep 6 16:37:06 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 10:37:06 -0400 Subject: [coreboot] [PATCH] Enable qemu memory range 0xc0000-0xfffff automatically. Message-ID: <20100906143705.GA15094@morn.localdomain> Instead of requiring users to modify qemu to allow writes to 0xc0000-0xfffff, have coreboot qemu support enable the memory range at startup. Signed-off-by: Kevin O'Connor --- src/mainboard/emulation/qemu-x86/mainboard.c | 41 +++++++++++++++++++++----- 1 files changed, 33 insertions(+), 8 deletions(-) diff --git a/src/mainboard/emulation/qemu-x86/mainboard.c b/src/mainboard/emulation/qemu-x86/mainboard.c index 7ab02d9..55fc5c3 100644 --- a/src/mainboard/emulation/qemu-x86/mainboard.c +++ b/src/mainboard/emulation/qemu-x86/mainboard.c @@ -10,15 +10,15 @@ /* not sure how these are routed in qemu */ static const unsigned char enetIrqs[4] = { 11, 0, 0, 0 }; -static void qemu_init(device_t dev) +static void qemu_nb_init(device_t dev) { - /* The VGA OPROM already lives at 0xc0000, - * force coreboot to use it. - */ - dev->on_mainboard = 1; - - /* Now do the usual initialization */ - pci_dev_init(dev); + // Map memory at 0xc0000 - 0xfffff + int i; + uint8_t v = pci_read_config8(dev, 0x59); + v |= 0x30; + pci_write_config8(dev, 0x59, v); + for (i=0; i<6; i++) + pci_write_config8(dev, 0x5a + i, 0x33); /* This sneaked in here, because Qemu does not * emulate a SuperIO chip @@ -32,6 +32,31 @@ static void qemu_init(device_t dev) pci_assign_irqs(0, 3, enetIrqs); } +static struct device_operations nb_operations = { + .read_resources = pci_dev_read_resources, + .set_resources = pci_dev_set_resources, + .enable_resources = pci_dev_enable_resources, + .init = qemu_nb_init, + .ops_pci = 0, +}; + +static const struct pci_driver nb_driver __pci_driver = { + .ops = &nb_operations, + .vendor = 0x8086, + .device = 0x1237, +}; + +static void qemu_init(device_t dev) +{ + /* The VGA OPROM already lives at 0xc0000, + * force coreboot to use it. + */ + dev->on_mainboard = 1; + + /* Now do the usual initialization */ + pci_dev_init(dev); +} + static struct device_operations vga_operations = { .read_resources = pci_dev_read_resources, .set_resources = pci_dev_set_resources, -- 1.7.2.2 From kevin at koconnor.net Mon Sep 6 17:16:58 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 11:16:58 -0400 Subject: [coreboot] [PATCH] Wait for RTC power well on vt8237r early smbus. Message-ID: <20100906151658.GA18582@morn.localdomain> Code must not access the smbus registers before the RTC power well is ready (PSON gating). Some boards boot faster than this power well stabilization, and thus see bad data when accessing the smbus registers. --- src/southbridge/via/vt8237r/vt8237r.h | 1 + src/southbridge/via/vt8237r/vt8237r_early_smbus.c | 9 +++++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/src/southbridge/via/vt8237r/vt8237r.h b/src/southbridge/via/vt8237r/vt8237r.h index 54a46f8..d54c533 100644 --- a/src/southbridge/via/vt8237r/vt8237r.h +++ b/src/southbridge/via/vt8237r/vt8237r.h @@ -47,6 +47,7 @@ #define IDE_UDMA 0x50 /* SMBus */ +#define VT8237R_PSON 0x82 #define VT8237R_POWER_WELL 0x94 #define VT8237R_SMBUS_IO_BASE_REG 0xd0 #define VT8237R_SMBUS_HOST_CONF 0xd2 diff --git a/src/southbridge/via/vt8237r/vt8237r_early_smbus.c b/src/southbridge/via/vt8237r/vt8237r_early_smbus.c index 357ad81..4372a4a 100644 --- a/src/southbridge/via/vt8237r/vt8237r_early_smbus.c +++ b/src/southbridge/via/vt8237r/vt8237r_early_smbus.c @@ -132,12 +132,15 @@ u8 smbus_read_byte(u8 dimm, u8 offset) return val; } +#define PSONREADY_TIMEOUT 0x7fffffff + /** * Enable the SMBus on VT8237R-based systems. */ void enable_smbus(void) { device_t dev; + int loops; /* Power management controller */ dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA, @@ -150,6 +153,12 @@ void enable_smbus(void) die("Power management controller not found\n"); } + /* Make sure the RTC power well is up before touching smbus. */ + loops = 0; + while (!(pci_read_config8(dev, VT8237R_PSON) & (1<<6)) + && loops < PSONREADY_TIMEOUT) + ++loops; + /* * 7 = SMBus Clock from RTC 32.768KHz * 5 = Internal PLL reset from susp -- 1.7.2.2 From kevin at koconnor.net Mon Sep 6 17:27:06 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 11:27:06 -0400 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <4C84B6FA.4040203@georgi-clan.de> References: <20100905182108.GA32750@morn.localdomain> <20100905182641.28794.qmail@stuge.se> <20100905213407.GA12340@morn.localdomain> <4C84B6FA.4040203@georgi-clan.de> Message-ID: <20100906152705.GA18831@morn.localdomain> On Mon, Sep 06, 2010 at 11:40:10AM +0200, Patrick Georgi wrote: > We could move compression out of subheader fields into the regular file > header, so every file could be compressed (though for some it wouldn't > be useful, eg. romstages or EC roms), and then make this a global variable. > > However, we had our reasons not to do this. Pick your poison I wasn't looking to rework the CBFS format. Right now, it can be a pain for SeaBIOS users to add certain compressed files like floppies. Today they need to do: $ lzma -zc /path/to/myfloppy.img > myfloppy.img.lzma $ cbfstool coreboot.rom add myfloppy.img.lzma floppyimg/MyFloppy.lzma raw Unfortunately, not everyone has the "lzma" tool, and some distro versions of that tool are quirky. So, I'm looking for a helper to cbfstool to make adding compressed raw files simpler for end users. I've also been thinking of adding another helper - "add-string". So a user could do something like: "cbfstool ROM add-string '5500' cfg/boot-menu-delay". As I think this may be a straight forward way to pass simple config items into SeaBIOS. -Kevin From mylesgw at gmail.com Mon Sep 6 17:34:14 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 6 Sep 2010 09:34:14 -0600 Subject: [coreboot] [PATCH] Enable qemu memory range 0xc0000-0xfffff automatically. In-Reply-To: References: <20100906143705.GA15094@morn.localdomain> Message-ID: On Mon, Sep 6, 2010 at 8:37 AM, Kevin O'Connor wrote: > Instead of requiring users to modify qemu to allow writes to > 0xc0000-0xfffff, have coreboot qemu support enable the memory range at > startup. > > Signed-off-by: Kevin O'Connor Should we add a northbridge? ?It seems too bad to put northbridge code in the mainboard. I like the idea though. Acked-by: Myles Watson Thanks, Myles > ?src/mainboard/emulation/qemu-x86/mainboard.c | ? 41 +++++++++++++++++++++----- > ?1 files changed, 33 insertions(+), 8 deletions(-) > > diff --git a/src/mainboard/emulation/qemu-x86/mainboard.c b/src/mainboard/emulation/qemu-x86/mainboard.c > index 7ab02d9..55fc5c3 100644 > --- a/src/mainboard/emulation/qemu-x86/mainboard.c > +++ b/src/mainboard/emulation/qemu-x86/mainboard.c > @@ -10,15 +10,15 @@ > ?/* not sure how these are routed in qemu */ > ?static const unsigned char enetIrqs[4] = { 11, 0, 0, 0 }; > > -static void qemu_init(device_t dev) > +static void qemu_nb_init(device_t dev) > ?{ > - ? ? ? /* The VGA OPROM already lives at 0xc0000, > - ? ? ? ?* force coreboot to use it. > - ? ? ? ?*/ > - ? ? ? dev->on_mainboard = 1; > - > - ? ? ? /* Now do the usual initialization */ > - ? ? ? pci_dev_init(dev); > + ? ? ? // Map memory at 0xc0000 - 0xfffff > + ? ? ? int i; > + ? ? ? uint8_t v = pci_read_config8(dev, 0x59); > + ? ? ? v |= 0x30; > + ? ? ? pci_write_config8(dev, 0x59, v); > + ? ? ? for (i=0; i<6; i++) > + ? ? ? ? ? ? ? pci_write_config8(dev, 0x5a + i, 0x33); > > ? ? ? ?/* This sneaked in here, because Qemu does not > ? ? ? ? * emulate a SuperIO chip > @@ -32,6 +32,31 @@ static void qemu_init(device_t dev) > ? ? ? ?pci_assign_irqs(0, 3, enetIrqs); > ?} > > +static struct device_operations nb_operations = { > + ? ? ? .read_resources ? = pci_dev_read_resources, > + ? ? ? .set_resources ? ?= pci_dev_set_resources, > + ? ? ? .enable_resources = pci_dev_enable_resources, > + ? ? ? .init ? ? ? ? ? ? = qemu_nb_init, > + ? ? ? .ops_pci ? ? ? ? ?= 0, > +}; > + > +static const struct pci_driver nb_driver __pci_driver = { > + ? ? ? .ops = &nb_operations, > + ? ? ? .vendor = 0x8086, > + ? ? ? .device = 0x1237, > +}; > + > +static void qemu_init(device_t dev) > +{ > + ? ? ? /* The VGA OPROM already lives at 0xc0000, > + ? ? ? ?* force coreboot to use it. > + ? ? ? ?*/ > + ? ? ? dev->on_mainboard = 1; > + > + ? ? ? /* Now do the usual initialization */ > + ? ? ? pci_dev_init(dev); > +} > + > ?static struct device_operations vga_operations = { > ? ? ? ?.read_resources ? = pci_dev_read_resources, > ? ? ? ?.set_resources ? ?= pci_dev_set_resources, > -- > 1.7.2.2 > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From kevin at koconnor.net Mon Sep 6 17:38:44 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 11:38:44 -0400 Subject: [coreboot] [PATCH] Enable qemu memory range 0xc0000-0xfffff automatically. In-Reply-To: References: <20100906143705.GA15094@morn.localdomain> Message-ID: <20100906153844.GA20111@morn.localdomain> On Mon, Sep 06, 2010 at 09:34:14AM -0600, Myles Watson wrote: > On Mon, Sep 6, 2010 at 8:37 AM, Kevin O'Connor wrote: > > Instead of requiring users to modify qemu to allow writes to > > 0xc0000-0xfffff, have coreboot qemu support enable the memory range at > > startup. > > > > Signed-off-by: Kevin O'Connor > > Should we add a northbridge? ?It seems too bad to put northbridge code > in the mainboard. I think it's more of a qemu platform thing than a real northbridge chip thing. > > I like the idea though. > > Acked-by: Myles Watson > Thanks. I don't have commit access, so someone else will have to check it in. -Kevin From JRottmann at LiPPERTEmbedded.de Mon Sep 6 18:24:00 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Mon, 06 Sep 2010 18:24:00 +0200 Subject: [coreboot] [PATCH] Geode LX and Alix.2 support enhancements Message-ID: <4C8515A0.4080400@LiPPERTEmbedded.de> Hi, rev 5777 + geode-lx-rambase-at-1m.diff compiles & boots fine for LiPPERT RoadRunner-LX and SpaceRunner-LX. For geode-lx-rambase-at-1m.diff: Tested-by: Jens Rottmann Cheers, Jens From scott at notabs.org Mon Sep 6 19:19:42 2010 From: scott at notabs.org (Scott Duplichan) Date: Mon, 6 Sep 2010 12:19:42 -0500 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <8762yj170a.fsf@taniquetil.gledits.ch> References: <4C812B6D020000FE0000D531@mail.lkfd.net><87aanv1eax.fsf@taniquetil.gledits.ch><4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> Message-ID: <05F28A7E6D2248C3963F2A7E67526E7C@m3a78> -----Original Message----- From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Arne Georg Gleditsch Sent: Monday, September 06, 2010 05:50 AM To: coreboot at coreboot.org Subject: Re: [coreboot] AMD cache setup is broken Stefan Reinauer writes: >> Can you see if the patches posted in >> http://article.gmane.org/gmane.linux.bios/57707 make any difference for >> you? >> > Did we ever figure out what is causing this? The last time I really dug into this, it was fairly obvious that it was caused by instruction fetch thrashing towards the ROM. I tried to amend this with MTRR settings, but I was unable to make that work correctly. For some reason it seemed like the HT requests were sublty changed when the MTRR was applied, and didn't hit the legacy southbridge properly. > The patch would require 4KB more stack on all supported systems, so if > we can we should do things differently. It doesn't have to be stack, but it is nice to have it memory mananged in some way. The unrv2b patch I posted addressing the same problem was even more kludgy. > Also, it's not really guaranteed that the code works from the new > location since we don't compile coreboot with -fPIC (and as far as I > understand the GCC guys, even that would not help), so I am a bit > hesitant to check this in. Agreed, it is a bit icky. Not sure what the best way to handle that is, though. On the pro side, I assume breakage here is going to be obvious, and (supposing these patches actually help Nick) this is an issue people are running into with some regularity. -- Arne. -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot One necessary condition for caching MMIO such as the flash chip on AMD family 10h processors is not well known: If the processor has an L3 cache, then bit 15 of msr C001_102A (ClLinesToNbDis) must be set. This bit needs to eventually be cleared in order for the OS to use the L3 cache. But BIOS must not clear this bit until cacheable accesses to the flash chip are no longer needed. This situation applies only to family 10h processors that have L3 cache. Often BIOS clears this bit too early and slow execution results.As an experiment, you could add code to set this bit before the slow function and see what happens. Last night I tried to debug this code on simnow. An HT modeling problem kept me from getting past HT init. I may try it again today. The recommended cacheability setting for MMIO is WP. At the point the simnow model hangs in HT init, the setting is WB. While this should be OK for family 10h, it will be important to use WP for families 14h and 15. ClLinesToNbDis is properly set for MMIO caching at this point (HT init): ------------Effective memory type and destination by address------------ NORMAL NORMAL NORMAL SMM SMM SMM READ WRITE EXECUTE READ WRITE EXECUTE 00000-C3FFF UC MMIO.................... UC MMIO.................... C4000-CFFFF WB DRAM.................... WB DRAM.................... D0000-FFFFF UC MMIO.................... UC MMIO.................... 00100000-00FFFFFF UC DRAM 01000000-FFEFFFFF UC MMIO FFF00000-FFF7FFFF WB MMIO <=== really should be WP FFF80000-FFFFFFFF UC MMIO -msr c001102a 00000040_010080C8 <=== good at this point Thanks, Scott From peter at stuge.se Mon Sep 6 19:25:36 2010 From: peter at stuge.se (Peter Stuge) Date: Mon, 6 Sep 2010 19:25:36 +0200 Subject: [coreboot] [PATCH] Wait for RTC power well on vt8237r early smbus. In-Reply-To: <20100906151658.GA18582@morn.localdomain> References: <20100906151658.GA18582@morn.localdomain> Message-ID: <20100906172536.7876.qmail@stuge.se> Kevin O'Connor wrote: > Code must not access the smbus registers before the RTC power well is > ready (PSON gating). Some boards boot faster than this power well > stabilization, and thus see bad data when accessing the smbus > registers. > --- > src/southbridge/via/vt8237r/vt8237r.h | 1 + > src/southbridge/via/vt8237r/vt8237r_early_smbus.c | 9 +++++++++ > 2 files changed, 10 insertions(+), 0 deletions(-) Hint: use git commit -s to add Signed-off-by: automatically. Acked-by: Peter Stuge From patrick at georgi-clan.de Mon Sep 6 19:32:09 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Mon, 06 Sep 2010 19:32:09 +0200 Subject: [coreboot] CS5536 OHCI not working In-Reply-To: <4C84FBB6.8090407@LiPPERTEmbedded.de> References: <4C811098.8010101@LiPPERTEmbedded.de> <4C8120E9.8010000@georgi-clan.de> <4C812EE3.1010707@LiPPERTEmbedded.de> <4C84FBB6.8090407@LiPPERTEmbedded.de> Message-ID: <4C852599.60409@georgi-clan.de> Am 06.09.2010 16:33, schrieb Jens Rottmann: > In the meantime I've tested 1 USB keyboard and 8 storage devices from > different vendors (2 card readers, 1 M-Systems uDOC, 5 thumb drives, 1 > of which is an ancient USB 1.1 only). None worked. I'll try again - might have messed up something when integrating to the public tree :-( keyboard won't work on OHCI yet - the interrupt transfer model needs rework before I'll enable it for the non-UHCI controllers. Thanks, Patrick From stefan.reinauer at coresystems.de Mon Sep 6 19:34:55 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Mon, 06 Sep 2010 19:34:55 +0200 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <20100906152705.GA18831@morn.localdomain> References: <20100905182108.GA32750@morn.localdomain> <20100905182641.28794.qmail@stuge.se> <20100905213407.GA12340@morn.localdomain> <4C84B6FA.4040203@georgi-clan.de> <20100906152705.GA18831@morn.localdomain> Message-ID: <4C85263F.4050905@coresystems.de> On 9/6/10 5:27 PM, Kevin O'Connor wrote: > I've also been thinking of adding another helper - "add-string". So a > user could do something like: "cbfstool ROM add-string '5500' > cfg/boot-menu-delay". As I think this may be a straight forward way > to pass simple config items into SeaBIOS. What's a "string" supposed to be in that context? Stefan From patrick at georgi-clan.de Mon Sep 6 19:36:28 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Mon, 06 Sep 2010 19:36:28 +0200 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <4C85263F.4050905@coresystems.de> References: <20100905182108.GA32750@morn.localdomain> <20100905182641.28794.qmail@stuge.se> <20100905213407.GA12340@morn.localdomain> <4C84B6FA.4040203@georgi-clan.de> <20100906152705.GA18831@morn.localdomain> <4C85263F.4050905@coresystems.de> Message-ID: <4C85269C.7060703@georgi-clan.de> Am 06.09.2010 19:34, schrieb Stefan Reinauer: > On 9/6/10 5:27 PM, Kevin O'Connor wrote: >> I've also been thinking of adding another helper - "add-string". So a >> user could do something like: "cbfstool ROM add-string '5500' >> cfg/boot-menu-delay". As I think this may be a straight forward way >> to pass simple config items into SeaBIOS. > What's a "string" supposed to be in that context? Sounds like a reinvention of our CMOS stuff... Patrick From timl at scintilla.utwente.nl Mon Sep 6 19:47:16 2010 From: timl at scintilla.utwente.nl (Tim ter Laak) Date: Mon, 6 Sep 2010 19:47:16 +0200 (CEST) Subject: [coreboot] [flashrom] Re: flashrom patch: add support for Abit AB-BM6 board In-Reply-To: References: <4C81B2EE.2060104@gmx.net> Message-ID: This patch adds support for the Abit BM6 board, using DMI string identification. Signed-off-by: Tim ter Laak --- On Sun, 5 Sep 2010, Tim ter Laak wrote: > On Sat, 4 Sep 2010, Carl-Daniel Hailfinger wrote: > >> flashrom supports DMI matching since a few months, so it may be possible >> to identify your board that way. And with superiotool output, we could >> perhaps improve matching a bit more. > >> If DMI is useful on your board, we could try to match the DMI strings >> and avoid the -m abit:ab-bm6 parameter for flashrom. > > The combination of the 'baseboard-manufacturer' and 'baseboard-product-name' > DMI strings looks promising. > (The empty contents of other strings is completely in line with expectations; > after all the BIOS didn't bother to assign subsystem IDs to the PCI devices > of the chipset either.) > > I'll be poking around in the source in the next few days to port my patch to > the current version of flashrom. It would take a while to get up to speed > again though, so I'm also open to testing other people's patches. Well, that was a lot easier than expected. As per commit log message at the top of this mail, the patch is attached. Patch is tested and seems to work fine. Tim. -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_ab-bm6.patch Type: text/x-diff Size: 1627 bytes Desc: URL: From kevin at koconnor.net Mon Sep 6 19:58:12 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 13:58:12 -0400 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <4C85263F.4050905@coresystems.de> References: <20100905182108.GA32750@morn.localdomain> <20100905182641.28794.qmail@stuge.se> <20100905213407.GA12340@morn.localdomain> <4C84B6FA.4040203@georgi-clan.de> <20100906152705.GA18831@morn.localdomain> <4C85263F.4050905@coresystems.de> Message-ID: <20100906175812.GA4967@morn.localdomain> On Mon, Sep 06, 2010 at 07:34:55PM +0200, Stefan Reinauer wrote: > On 9/6/10 5:27 PM, Kevin O'Connor wrote: > > I've also been thinking of adding another helper - "add-string". So a > > user could do something like: "cbfstool ROM add-string '5500' > > cfg/boot-menu-delay". As I think this may be a straight forward way > > to pass simple config items into SeaBIOS. > What's a "string" supposed to be in that context? It would be passing in the file contents on the command-line instead of in a file. So, for example: $ cbfstool ROM add-string '5500' cfg/boot-menu-delay would be the equivalent of: $ echo '5500' > myfile $ cbfstool ROM add myfile cfg/boot-menu-delay -Kevin From kevin at koconnor.net Mon Sep 6 20:12:50 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 14:12:50 -0400 Subject: [coreboot] [PATCH] Wait for RTC power well on vt8237r early smbus. In-Reply-To: <20100906172536.7876.qmail@stuge.se> References: <20100906151658.GA18582@morn.localdomain> <20100906172536.7876.qmail@stuge.se> Message-ID: <20100906181250.GC4967@morn.localdomain> On Mon, Sep 06, 2010 at 07:25:36PM +0200, Peter Stuge wrote: > Kevin O'Connor wrote: > > Code must not access the smbus registers before the RTC power well is > > ready (PSON gating). Some boards boot faster than this power well > > stabilization, and thus see bad data when accessing the smbus > > registers. > > --- > > src/southbridge/via/vt8237r/vt8237r.h | 1 + > > src/southbridge/via/vt8237r/vt8237r_early_smbus.c | 9 +++++++++ > > 2 files changed, 10 insertions(+), 0 deletions(-) > > Hint: use git commit -s to add Signed-off-by: automatically. Sorry about that: Signed-off-by: Kevin O'Connor > Acked-by: Peter Stuge Thanks - I don't have commit access so someone will need to check it in. -Kevin From flashrom at mkarcher.dialup.fu-berlin.de Mon Sep 6 19:58:07 2010 From: flashrom at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Mon, 06 Sep 2010 19:58:07 +0200 Subject: [coreboot] [flashrom] flashrom patch: add support for Abit AB-BM6 board In-Reply-To: References: <4C81B2EE.2060104@gmx.net> Message-ID: <1283795887.27123.1.camel@aquila> Am Montag, den 06.09.2010, 19:47 +0200 schrieb Tim ter Laak: > Signed-off-by: Tim ter Laak > Well, that was a lot easier than expected. As per commit log message at > the top of this mail, the patch is attached. Patch is tested and seems to > work fine. Please also add the board to print.c, leave the URL NULL if you can't find any. Otherwise it will be missing from flashrom -L and the Wiki. Regards, Michael Karcher From kevin at koconnor.net Mon Sep 6 20:10:39 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 14:10:39 -0400 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <4C85269C.7060703@georgi-clan.de> References: <20100905182108.GA32750@morn.localdomain> <20100905182641.28794.qmail@stuge.se> <20100905213407.GA12340@morn.localdomain> <4C84B6FA.4040203@georgi-clan.de> <20100906152705.GA18831@morn.localdomain> <4C85263F.4050905@coresystems.de> <4C85269C.7060703@georgi-clan.de> Message-ID: <20100906181039.GB4967@morn.localdomain> On Mon, Sep 06, 2010 at 07:36:28PM +0200, Patrick Georgi wrote: > Am 06.09.2010 19:34, schrieb Stefan Reinauer: > > On 9/6/10 5:27 PM, Kevin O'Connor wrote: > >> I've also been thinking of adding another helper - "add-string". So a > >> user could do something like: "cbfstool ROM add-string '5500' > >> cfg/boot-menu-delay". As I think this may be a straight forward way > >> to pass simple config items into SeaBIOS. > > What's a "string" supposed to be in that context? > Sounds like a reinvention of our CMOS stuff... It serves a similar role. I don't much like CMOS because I've found it flaky on boards. I also want to be able to config boot order - for example, a boot order might be something like "cdrom,disk,pci00:13.1,floppy" for cdrom, hard drive, BEV on an optionrom (eg, nic), and floppy. Hard drive order might be like "ata1-0,usb1234:4567,pci00:13.1/1" for an ata drive, USB drive, and a BCV on an optionrom (eg, scsi drive). I think encoding this into CMOS would be a lot harder than encoding into a string in CBFS. Anyway, this is just in the though phase. I only raised it because I thought it might be a sibling to the proposed "add-lzma". -Kevin From patrick at georgi-clan.de Mon Sep 6 21:05:39 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Mon, 06 Sep 2010 21:05:39 +0200 Subject: [coreboot] [PATCH] cbfstool "add-lzma" method In-Reply-To: <20100906181039.GB4967@morn.localdomain> References: <20100905182108.GA32750@morn.localdomain> <20100905182641.28794.qmail@stuge.se> <20100905213407.GA12340@morn.localdomain> <4C84B6FA.4040203@georgi-clan.de> <20100906152705.GA18831@morn.localdomain> <4C85263F.4050905@coresystems.de> <4C85269C.7060703@georgi-clan.de> <20100906181039.GB4967@morn.localdomain> Message-ID: <4C853B83.4030607@georgi-clan.de> Am 06.09.2010 20:10, schrieb Kevin O'Connor: > It serves a similar role. I don't much like CMOS because I've found > it flaky on boards. I also want to be able to config boot order - for > example, a boot order might be something like > "cdrom,disk,pci00:13.1,floppy" for cdrom, hard drive, BEV on an > optionrom (eg, nic), and floppy. Hard drive order might be like > "ata1-0,usb1234:4567,pci00:13.1/1" for an ata drive, USB drive, and a > BCV on an optionrom (eg, scsi drive). I think encoding this into CMOS > would be a lot harder than encoding into a string in CBFS. We use a string in CMOS for that on kontron/986lcd-m > Anyway, this is just in the though phase. I only raised it because I > thought it might be a sibling to the proposed "add-lzma". add-lzma somewhat breaks the CBFS design as is. hence the question how this can be made consistent. Patrick From svn at coreboot.org Mon Sep 6 22:20:47 2010 From: svn at coreboot.org (repository service) Date: Mon, 06 Sep 2010 22:20:47 +0200 Subject: [coreboot] [commit] r5778 - trunk/src/mainboard/emulation/qemu-x86 Message-ID: Author: myles Date: Mon Sep 6 22:20:47 2010 New Revision: 5778 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5778 Log: Update RoadRunner and SpaceRunner config to get in sync with current standard BIOSes RRLX0013 and SRLX0013. Specifically move SPI and PME I/Os to 0x1228 and 0x298 and switch SIO watchdog to ext. 48 MHz CLKIN. Signed-off-by: Jens Rottmann Acked-by: Myles Watson Modified: trunk/src/mainboard/emulation/qemu-x86/mainboard.c Modified: trunk/src/mainboard/emulation/qemu-x86/mainboard.c ============================================================================== --- trunk/src/mainboard/emulation/qemu-x86/mainboard.c Sun Sep 5 07:52:33 2010 (r5777) +++ trunk/src/mainboard/emulation/qemu-x86/mainboard.c Mon Sep 6 22:20:47 2010 (r5778) @@ -10,15 +10,15 @@ /* not sure how these are routed in qemu */ static const unsigned char enetIrqs[4] = { 11, 0, 0, 0 }; -static void qemu_init(device_t dev) +static void qemu_nb_init(device_t dev) { - /* The VGA OPROM already lives at 0xc0000, - * force coreboot to use it. - */ - dev->on_mainboard = 1; - - /* Now do the usual initialization */ - pci_dev_init(dev); + /* Map memory at 0xc0000 - 0xfffff */ + int i; + uint8_t v = pci_read_config8(dev, 0x59); + v |= 0x30; + pci_write_config8(dev, 0x59, v); + for (i=0; i<6; i++) + pci_write_config8(dev, 0x5a + i, 0x33); /* This sneaked in here, because Qemu does not * emulate a SuperIO chip @@ -32,6 +32,31 @@ pci_assign_irqs(0, 3, enetIrqs); } +static struct device_operations nb_operations = { + .read_resources = pci_dev_read_resources, + .set_resources = pci_dev_set_resources, + .enable_resources = pci_dev_enable_resources, + .init = qemu_nb_init, + .ops_pci = 0, +}; + +static const struct pci_driver nb_driver __pci_driver = { + .ops = &nb_operations, + .vendor = 0x8086, + .device = 0x1237, +}; + +static void qemu_init(device_t dev) +{ + /* The VGA OPROM already lives at 0xc0000, + * force coreboot to use it. + */ + dev->on_mainboard = 1; + + /* Now do the usual initialization */ + pci_dev_init(dev); +} + static struct device_operations vga_operations = { .read_resources = pci_dev_read_resources, .set_resources = pci_dev_set_resources, From mylesgw at gmail.com Mon Sep 6 22:22:48 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 6 Sep 2010 14:22:48 -0600 Subject: [coreboot] [PATCH] Enable qemu memory range 0xc0000-0xfffff automatically. In-Reply-To: <20100906153844.GA20111@morn.localdomain> References: <20100906143705.GA15094@morn.localdomain> <20100906153844.GA20111@morn.localdomain> Message-ID: On Mon, Sep 6, 2010 at 9:38 AM, Kevin O'Connor wrote: > On Mon, Sep 06, 2010 at 09:34:14AM -0600, Myles Watson wrote: >> On Mon, Sep 6, 2010 at 8:37 AM, Kevin O'Connor wrote: >> > Instead of requiring users to modify qemu to allow writes to >> > 0xc0000-0xfffff, have coreboot qemu support enable the memory range at >> > startup. >> > >> > Signed-off-by: Kevin O'Connor >> >> Should we add a northbridge? ?It seems too bad to put northbridge code >> in the mainboard. > > I think it's more of a qemu platform thing than a real northbridge > chip thing. > >> >> I like the idea though. >> >> Acked-by: Myles Watson Committed in 5778. Sorry I botched the commit message. Thanks, Myles From kevin at koconnor.net Tue Sep 7 01:23:24 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 19:23:24 -0400 Subject: [coreboot] [PATCH 0/4] Misc speed improvements Message-ID: These patches reduce the boot time for me on my epia-cn. (From payload launch in 2.273s down to 0.610s.) Where possible, I tried to make the changes apply to other boards. However, I have not tested any other boards. Kevin O'Connor (4): Make initializing PS2 keyboard optional. Enable TSC calibration with timer2 by default. Reduce TSC calibrations from 20ms to 2ms. Don't preload the rom code during the VIA CAR setup. src/Kconfig | 14 ++++++++++++++ src/cpu/via/car/cache_as_ram.inc | 2 ++ src/cpu/x86/Kconfig | 2 +- src/cpu/x86/tsc/delay_tsc.c | 4 ++-- src/pc80/keyboard.c | 2 ++ 5 files changed, 21 insertions(+), 3 deletions(-) -- 1.7.2.2 From kevin at koconnor.net Tue Sep 7 01:23:56 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 19:23:56 -0400 Subject: [coreboot] [PATCH 2/4] Enable TSC calibration with timer2 by default. In-Reply-To: References: Message-ID: <653639f7559fcf14685c35907fd9e733c2e89901.1283815188.git.kevin@koconnor.net> Enable TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 by default. Without this set, almost all boards use the inb(0x80) method. Unfortunately, that method takes over a second to calibrate, and it's results are not as reliable. There is a chance that some boards may not work well with the timer2 method. This is likely rare, because both libpayload and seabios use the timer2 method unconditionally and there has not been reports of an issue. Should a board not support the more accurate timer2 mechanism, it will need to be updated to actively disable it. Signed-off-by: Kevin O'Connor --- src/cpu/x86/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/cpu/x86/Kconfig b/src/cpu/x86/Kconfig index 325991e..8cd999e 100644 --- a/src/cpu/x86/Kconfig +++ b/src/cpu/x86/Kconfig @@ -21,7 +21,7 @@ config UDELAY_TSC config TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 bool - default n + default y config XIP_ROM_BASE hex -- 1.7.2.2 From kevin at koconnor.net Tue Sep 7 01:23:42 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 19:23:42 -0400 Subject: [coreboot] [PATCH 1/4] Make initializing PS2 keyboard optional. In-Reply-To: References: Message-ID: <53241126486840e63685efc05e61ee3b9dac2b9b.1283815188.git.kevin@koconnor.net> Add a DRIVERS_PS2_KEYBOARD option which controls the PS2 keyboard initialization. Not all payloads require it and some keyboards take a long time to init. Signed-off-by: Kevin O'Connor --- src/Kconfig | 14 ++++++++++++++ src/pc80/keyboard.c | 2 ++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index ec3a13b..ebbb14a 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -120,6 +120,20 @@ endmenu menu "Generic Drivers" source src/drivers/Kconfig + +config DRIVERS_PS2_KEYBOARD + bool "PS2 Keyboard init" + default y + help + Enable this option to initialize PS2 keyboards found connected + to the PS2 port. Some payloads (eg, filo) require this + option. Other payloads (eg, SeaBIOS, Linux) do not require + it. Initializing a PS2 keyboard can take several hundred + milliseconds. + + If you know you will only use a payload which does not require + this option, then you can say "n" here to speed up boot time. + Otherwise say "y". endmenu config PCI_BUS_SEGN_BITS diff --git a/src/pc80/keyboard.c b/src/pc80/keyboard.c index dee6279..9dadf0e 100644 --- a/src/pc80/keyboard.c +++ b/src/pc80/keyboard.c @@ -162,6 +162,8 @@ static u8 send_keyboard(u8 command) void pc_keyboard_init(struct pc_keyboard *keyboard) { u8 regval; + if (!CONFIG_DRIVERS_PS2_KEYBOARD) + return; printk(BIOS_DEBUG, "Keyboard init...\n"); /* Run a keyboard controller self-test */ -- 1.7.2.2 From kevin at koconnor.net Tue Sep 7 01:24:29 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 19:24:29 -0400 Subject: [coreboot] [PATCH 4/4] Don't preload the rom code during the VIA CAR setup. In-Reply-To: References: Message-ID: It should not be necessary to read in the rom during CAR setup. Removing the code preloading reduces the boot time. Signed-off-by: Kevin O'Connor --- src/cpu/via/car/cache_as_ram.inc | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/cpu/via/car/cache_as_ram.inc b/src/cpu/via/car/cache_as_ram.inc index eaa4ac9..4bbefef 100644 --- a/src/cpu/via/car/cache_as_ram.inc +++ b/src/cpu/via/car/cache_as_ram.inc @@ -139,10 +139,12 @@ clear_fixed_var_mtrr_out: xorl $0x5c5c5c5c,%eax rep stosl +#ifdef CARTEST movl REAL_XIP_ROM_BASE, %esi movl %esi, %edi movl $(CONFIG_XIP_ROM_SIZE>>2), %ecx rep lodsl +#endif /* The key point of this CAR code is C7 cache does not turn into * "no fill" mode, which is not compatible with general CAR code. -- 1.7.2.2 From kevin at koconnor.net Tue Sep 7 01:24:11 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 6 Sep 2010 19:24:11 -0400 Subject: [coreboot] [PATCH 3/4] Reduce TSC calibrations from 20ms to 2ms. In-Reply-To: References: Message-ID: <7986f0442d0e6007a1d479241229158fc4f902b9.1283815188.git.kevin@koconnor.net> 2ms is enough time to accurately obtain the clock rate. Signed-off-by: Kevin O'Connor --- src/cpu/x86/tsc/delay_tsc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/cpu/x86/tsc/delay_tsc.c b/src/cpu/x86/tsc/delay_tsc.c index 27c89e3..1127867 100644 --- a/src/cpu/x86/tsc/delay_tsc.c +++ b/src/cpu/x86/tsc/delay_tsc.c @@ -18,8 +18,8 @@ static unsigned long clocks_per_usec; * device. */ -#define CALIBRATE_INTERVAL ((20*CLOCK_TICK_RATE)/1000) /* 20ms */ -#define CALIBRATE_DIVISOR (20*1000) /* 20ms / 20000 == 1usec */ +#define CALIBRATE_INTERVAL ((2*CLOCK_TICK_RATE)/1000) /* 2ms */ +#define CALIBRATE_DIVISOR (2*1000) /* 2ms / 2000 == 1usec */ static unsigned long long calibrate_tsc(void) { -- 1.7.2.2 From scott at notabs.org Tue Sep 7 02:40:59 2010 From: scott at notabs.org (Scott Duplichan) Date: Mon, 6 Sep 2010 19:40:59 -0500 Subject: [coreboot] AMD cache setup is broken References: <4C812B6D020000FE0000D531@mail.lkfd.net><87aanv1eax.fsf@taniquetil.gledits.ch><4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> Message-ID: <673D2439DC3046D0903811C4830EA052@m3a78> Stefan Reinauer writes: >> Can you see if the patches posted in >> http://article.gmane.org/gmane.linux.bios/57707 make any difference for >> you? >> > Did we ever figure out what is causing this? The last time I really dug into this, it was fairly obvious that it was caused by instruction fetch thrashing towards the ROM. I tried to amend this with MTRR settings, but I was unable to make that work correctly. For some reason it seemed like the HT requests were sublty changed when the MTRR was applied, and didn't hit the legacy southbridge properly. > The patch would require 4KB more stack on all supported systems, so if > we can we should do things differently. It doesn't have to be stack, but it is nice to have it memory mananged in some way. The unrv2b patch I posted addressing the same problem was even more kludgy. > Also, it's not really guaranteed that the code works from the new > location since we don't compile coreboot with -fPIC (and as far as I > understand the GCC guys, even that would not help), so I am a bit > hesitant to check this in. Agreed, it is a bit icky. Not sure what the best way to handle that is, though. On the pro side, I assume breakage here is going to be obvious, and (supposing these patches actually help Nick) this is an issue people are running into with some regularity. -- Arne. -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot One necessary condition for caching MMIO such as the flash chip on AMD family 10h processors is not well known: If the processor has an L3 cache, then bit 15 of msr C001_102A (ClLinesToNbDis) must be set. This bit needs to eventually be cleared in order for the OS to use the L3 cache. But BIOS must not clear this bit until cacheable accesses to the flash chip are no longer needed. This situation applies only to family 10h processors that have L3 cache. Often BIOS clears this bit too early and slow execution results.As an experiment, you could add code to set this bit before the slow function and see what happens. Last night I tried to debug this code on simnow. An HT modeling problem kept me from getting past HT init. I may try it again today. The recommended cacheability setting for MMIO is WP. At the point the simnow model hangs in HT init, the setting is WB. While this should be OK for family 10h, it will be important to use WP for families 14h and 15. ClLinesToNbDis is properly set for MMIO caching at this point (HT init): ------------Effective memory type and destination by address------------ NORMAL NORMAL NORMAL SMM SMM SMM READ WRITE EXECUTE READ WRITE EXECUTE 00000-C3FFF UC MMIO.................... UC MMIO.................... C4000-CFFFF WB DRAM.................... WB DRAM.................... D0000-FFFFF UC MMIO.................... UC MMIO.................... 00100000-00FFFFFF UC DRAM 01000000-FFEFFFFF UC MMIO FFF00000-FFF7FFFF WB MMIO <=== really should be WP FFF80000-FFFFFFFF UC MMIO -msr c001102a 00000040_010080C8 <=== good at this point Thanks, Scott Simnow testing with Tilapia confirms that the coreboot AMD family 10h code _does_ have the problem of clearing ClLinesToNbDis too early. To confirm this problem, someone testing on real AMD family 10h hardware should remove the msr C001_001a write from STOP_CAR_AND_CPU() and from mct_ClrClToNB_D(). An AMD F10h system running an optimized legacy bios can boot to a DOS ptompt in less than one second. There is no reason coreboot should be any slower. Thanks, Scott From patrick at georgi-clan.de Tue Sep 7 08:55:58 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 07 Sep 2010 08:55:58 +0200 Subject: [coreboot] [PATCH 1/4] Make initializing PS2 keyboard optional. In-Reply-To: <53241126486840e63685efc05e61ee3b9dac2b9b.1283815188.git.kevin@koconnor.net> References: <53241126486840e63685efc05e61ee3b9dac2b9b.1283815188.git.kevin@koconnor.net> Message-ID: <4C85E1FE.2040706@georgi-clan.de> Am 07.09.2010 01:23, schrieb Kevin O'Connor: > + Enable this option to initialize PS2 keyboards found connected > + to the PS2 port. Some payloads (eg, filo) require this > + option. Other payloads (eg, SeaBIOS, Linux) do not require If that's only libpayload that's lacking this kind of init, maybe we should reimplement it there, and drop this init altogether? Patrick From footplus at gmail.com Tue Sep 7 09:02:45 2010 From: footplus at gmail.com (=?UTF-8?B?QXVyw6lsaWVu?=) Date: Tue, 7 Sep 2010 09:02:45 +0200 Subject: [coreboot] [PATCH] Geode LX and Alix.2 support enhancements In-Reply-To: <4C8515A0.4080400@LiPPERTEmbedded.de> References: <4C8515A0.4080400@LiPPERTEmbedded.de> Message-ID: On Mon, Sep 6, 2010 at 6:24 PM, Jens Rottmann wrote: > Hi, > > rev 5777 + geode-lx-rambase-at-1m.diff compiles & boots fine for LiPPERT > RoadRunner-LX and SpaceRunner-LX. > > For geode-lx-rambase-at-1m.diff: > Tested-by: Jens Rottmann > > Thanks for testing :) -- Aur?lien Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: From timl at scintilla.utwente.nl Tue Sep 7 09:06:07 2010 From: timl at scintilla.utwente.nl (Tim ter Laak) Date: Tue, 7 Sep 2010 09:06:07 +0200 (CEST) Subject: [coreboot] [flashrom] flashrom patch: add support for Abit AB-BM6 board In-Reply-To: <1283795887.27123.1.camel@aquila> References: <4C81B2EE.2060104@gmx.net> <1283795887.27123.1.camel@aquila> Message-ID: This patch adds support for the Abit BM6 board, using DMI string identification, and lists it in print.c . Signed-off-by: Tim ter Laak --- On Mon, 6 Sep 2010, Michael Karcher wrote: > Please also add the board to print.c, leave the URL NULL if you can't > find any. Otherwise it will be missing from flashrom -L and the Wiki. I've attached an updated patch that adds this. Tim. -------------- next part -------------- Index: print.c =================================================================== --- print.c (revision 1153) +++ print.c (working copy) @@ -283,6 +283,7 @@ B("A-Trend", "ATC-6220", 1, "http://www.motherboard.cz/mb/atrend/atc6220.htm", NULL), B("abit", "AN-M2", 1, "http://www.abit.com.tw/page/de/motherboard/motherboard_detail.php?DEFTITLE=Y&fMTYPE=Socket%20AM2&pMODEL_NAME=AN-M2", NULL), B("abit", "AX8", 1, "http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?DEFTITLE=Y&fMTYPE=Socket%20939&pMODEL_NAME=AX8", NULL), + B("abit", "BM6", 1, "http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=BM6&fMTYPE=Socket%20370", NULL), B("abit", "Fatal1ty F-I90HD", 1, "http://www.abit.com.tw/page/de/motherboard/motherboard_detail.php?pMODEL_NAME=Fatal1ty+F-I90HD&fMTYPE=LGA775", NULL), B("abit", "IC7", 1, "http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=IC7&fMTYPE=Socket%20478", NULL), B("abit", "IP35", 1, "http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?fMTYPE=LGA775&pMODEL_NAME=IP35", NULL), Index: board_enable.c =================================================================== --- board_enable.c (revision 1153) +++ board_enable.c (working copy) @@ -1093,6 +1093,15 @@ /* * Suited for: + * - Abit AB-BM6 + */ +static int intel_piix4_gpo26_lower(void) +{ + return intel_piix4_gpo_set(26, 0); +} + +/* + * Suited for: * - Intel SE440BX-2 */ static int intel_piix4_gpo27_lower(void) @@ -1763,6 +1772,7 @@ /* first pci-id set [4], second pci-id set [4], dmi identifier coreboot id [2], vendor name board name max_rom_... OK? flash enable */ #if defined(__i386__) || defined(__x86_64__) {0x10DE, 0x0547, 0x147B, 0x1C2F, 0x10DE, 0x0548, 0x147B, 0x1C2F, NULL, NULL, NULL, "abit", "AN-M2", 0, NT, nvidia_mcp_gpio2_raise}, + {0x8086, 0x7190, 0, 0, 0x8086, 0x7110, 0, 0, "^i440BX-W977 (BM6)$", NULL, NULL, "abit", "BM6", 0, OK, intel_piix4_gpo26_lower}, {0x8086, 0x24d3, 0x147b, 0x1014, 0x8086, 0x2578, 0x147b, 0x1014, NULL, NULL, NULL, "abit", "IC7", 0, NT, intel_ich_gpio23_raise}, {0x8086, 0x2930, 0x147b, 0x1084, 0x11ab, 0x4364, 0x147b, 0x1084, NULL, NULL, NULL, "abit", "IP35", 0, OK, intel_ich_gpio16_raise}, {0x8086, 0x2930, 0x147b, 0x1083, 0x10ec, 0x8167, 0x147b, 0x1083, NULL, NULL, NULL, "abit", "IP35 Pro", 0, OK, intel_ich_gpio16_raise}, From patrick at georgi-clan.de Tue Sep 7 09:07:36 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 07 Sep 2010 09:07:36 +0200 Subject: [coreboot] [PATCH 2/4] Enable TSC calibration with timer2 by default. In-Reply-To: <653639f7559fcf14685c35907fd9e733c2e89901.1283815188.git.kevin@koconnor.net> References: <653639f7559fcf14685c35907fd9e733c2e89901.1283815188.git.kevin@koconnor.net> Message-ID: <4C85E4B8.9000203@georgi-clan.de> Am 07.09.2010 01:23, schrieb Kevin O'Connor: > Enable TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 by default. Without this > set, almost all boards use the inb(0x80) method. Unfortunately, that > method takes over a second to calibrate, and it's results are not as > reliable. > > There is a chance that some boards may not work well with the timer2 > method. This is likely rare, because both libpayload and seabios use > the timer2 method unconditionally and there has not been reports of an > issue. Should a board not support the more accurate timer2 mechanism, > it will need to be updated to actively disable it. How about this instead? It allows boards that require the workaround to simply "select" it. Signed-off-by: Patrick Georgi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 20100907-1-tsc-defaults-to-timer2 URL: From patrick at georgi-clan.de Tue Sep 7 09:10:27 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 07 Sep 2010 09:10:27 +0200 Subject: [coreboot] [PATCH 4/4] Don't preload the rom code during the VIA CAR setup. In-Reply-To: References: Message-ID: <4C85E563.8000604@georgi-clan.de> Am 07.09.2010 01:24, schrieb Kevin O'Connor: > +#ifdef CARTEST > movl REAL_XIP_ROM_BASE, %esi > movl %esi, %edi > movl $(CONFIG_XIP_ROM_SIZE>>2), %ecx > rep lodsl > +#endif Can this be removed altogether then? Patrick From flashrom at mkarcher.dialup.fu-berlin.de Tue Sep 7 09:18:52 2010 From: flashrom at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Tue, 07 Sep 2010 09:18:52 +0200 Subject: [coreboot] [flashrom] flashrom patch: add support for Abit AB-BM6 board In-Reply-To: References: <4C81B2EE.2060104@gmx.net> <1283795887.27123.1.camel@aquila> Message-ID: <1283843932.27123.2.camel@aquila> Am Dienstag, den 07.09.2010, 09:06 +0200 schrieb Tim ter Laak: > This patch adds support for the Abit BM6 board, using DMI string > identification, and lists it in print.c . > > Signed-off-by: Tim ter Laak Acked-by: Michael Karcher If no one else beats me to it, I will commit tonight. Regards, Michael Karcher From svn at coreboot.org Tue Sep 7 09:43:11 2010 From: svn at coreboot.org (repository service) Date: Tue, 07 Sep 2010 09:43:11 +0200 Subject: [coreboot] [commit] r5779 - in trunk/src: cpu/amd/model_lx mainboard/amd/db800 mainboard/amd/norwich mainboard/artecgroup/dbe61 mainboard/digitallogic/msm800sev mainboard/iei/pcisa-lx-800-r10 mainboard/lipper... Message-ID: Author: oxygene Date: Tue Sep 7 09:43:10 2010 New Revision: 5779 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5779 Log: Set up an arbitrary amount of system memory on Geode LX, so coreboot_ram can be unpacked to 1MB. The value is quickly replaced with the real value later, thus causing no harm. Move RAMBASE to the default of 1MB for the affected boards Signed-off-by: Aurelien Guillaume Acked-by: Patrick Georgi Modified: trunk/src/cpu/amd/model_lx/msrinit.c trunk/src/mainboard/amd/db800/Kconfig trunk/src/mainboard/amd/norwich/Kconfig trunk/src/mainboard/artecgroup/dbe61/Kconfig trunk/src/mainboard/digitallogic/msm800sev/Kconfig trunk/src/mainboard/iei/pcisa-lx-800-r10/Kconfig trunk/src/mainboard/lippert/roadrunner-lx/Kconfig trunk/src/mainboard/lippert/spacerunner-lx/Kconfig trunk/src/mainboard/pcengines/alix1c/Kconfig trunk/src/mainboard/pcengines/alix2d/Kconfig trunk/src/mainboard/traverse/geos/Kconfig trunk/src/mainboard/winent/pl6064/Kconfig Modified: trunk/src/cpu/amd/model_lx/msrinit.c ============================================================================== --- trunk/src/cpu/amd/model_lx/msrinit.c Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/cpu/amd/model_lx/msrinit.c Tue Sep 7 09:43:10 2010 (r5779) @@ -39,6 +39,19 @@ {MSR_GLIU1_BASE1, {.hi = 0x20000000,.lo = 0x000fff80}}, // 0x00000-0x7FFFF {MSR_GLIU1_BASE2, {.hi = 0x20000000,.lo = 0x080fffe0}}, // 0x80000-0x9FFFF {MSR_GLIU1_SHADOW, {.hi = 0x2000FFFF,.lo = 0xFFFF0003}}, // 0xC0000-0xFFFFF + + /* Pre-setup access to memory above 1Mb. Here we set up about 500Mb of memory. + * It doesn't really matter in fact how much, however, because the only usage + * of this extended memory will be to host the coreboot_ram stage at RAMBASE, + * currently 1Mb. + * These registers will be set to their correct value by the Northbridge init code. + * + * WARNING: if coreboot_ram could not be loaded, these registers are probably + * incorrectly set here. You may comment the following two lines and set RAMBASE + * to 0x4000 to revert to the previous behavior for LX-boards. + */ + {MSR_GLIU0_SYSMEM, {.hi = 0x2000001F,.lo = 0x6BF00100}}, // 0x100000-0x1F6BF000 + {MSR_GLIU1_SYSMEM, {.hi = 0x2000001F,.lo = 0x6BF00100}}, // 0x100000-0x1F6BF000 }; static void msr_init(void) Modified: trunk/src/mainboard/amd/db800/Kconfig ============================================================================== --- trunk/src/mainboard/amd/db800/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/amd/db800/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -25,8 +25,4 @@ int default 4 -config RAMBASE - hex - default 0x4000 - endif # BOARD_AMD_DB800 Modified: trunk/src/mainboard/amd/norwich/Kconfig ============================================================================== --- trunk/src/mainboard/amd/norwich/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/amd/norwich/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -24,8 +24,4 @@ int default 6 -config RAMBASE - hex - default 0x4000 - endif # BOARD_AMD_NORWICH Modified: trunk/src/mainboard/artecgroup/dbe61/Kconfig ============================================================================== --- trunk/src/mainboard/artecgroup/dbe61/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/artecgroup/dbe61/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -24,8 +24,4 @@ int default 3 -#config RAMBASE -# hex -# default 0x4000 - endif # BOARD_ARTECGROUP_DBE61 Modified: trunk/src/mainboard/digitallogic/msm800sev/Kconfig ============================================================================== --- trunk/src/mainboard/digitallogic/msm800sev/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/digitallogic/msm800sev/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -25,8 +25,4 @@ int default 9 -config RAMBASE - hex - default 0x4000 - endif # BOARD_DIGITALLOGIC_MSM800SEV Modified: trunk/src/mainboard/iei/pcisa-lx-800-r10/Kconfig ============================================================================== --- trunk/src/mainboard/iei/pcisa-lx-800-r10/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/iei/pcisa-lx-800-r10/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -24,8 +24,4 @@ int default 9 -config RAMBASE - hex - default 0x4000 - endif # BOARD_IEI_PCISA_LX_800_R10 Modified: trunk/src/mainboard/lippert/roadrunner-lx/Kconfig ============================================================================== --- trunk/src/mainboard/lippert/roadrunner-lx/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/lippert/roadrunner-lx/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -27,10 +27,6 @@ int default 7 -config RAMBASE - hex - default 0x4000 - config ONBOARD_UARTS_RS485 bool "Switch on-board serial ports to RS485" default n Modified: trunk/src/mainboard/lippert/spacerunner-lx/Kconfig ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/lippert/spacerunner-lx/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -28,10 +28,6 @@ int default 7 -config RAMBASE - hex - default 0x4000 - config ONBOARD_UARTS_RS485 bool "Switch on-board serial ports to RS485" default n Modified: trunk/src/mainboard/pcengines/alix1c/Kconfig ============================================================================== --- trunk/src/mainboard/pcengines/alix1c/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/pcengines/alix1c/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -25,8 +25,4 @@ int default 5 -config RAMBASE - hex - default 0x4000 - endif # BOARD_PCENGINES_ALIX1C Modified: trunk/src/mainboard/pcengines/alix2d/Kconfig ============================================================================== --- trunk/src/mainboard/pcengines/alix2d/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/pcengines/alix2d/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -24,8 +24,4 @@ int default 7 -config RAMBASE - hex - default 0x4000 - endif # BOARD_PCENGINES_ALIX2D Modified: trunk/src/mainboard/traverse/geos/Kconfig ============================================================================== --- trunk/src/mainboard/traverse/geos/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/traverse/geos/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -24,8 +24,4 @@ int default 6 -config RAMBASE - hex - default 0x4000 - endif # BOARD_TRAVERSE_GEOS Modified: trunk/src/mainboard/winent/pl6064/Kconfig ============================================================================== --- trunk/src/mainboard/winent/pl6064/Kconfig Mon Sep 6 22:20:47 2010 (r5778) +++ trunk/src/mainboard/winent/pl6064/Kconfig Tue Sep 7 09:43:10 2010 (r5779) @@ -25,8 +25,4 @@ int default 7 -config RAMBASE - hex - default 0x4000 - endif # BOARD_WINENT_PL6064 From JRottmann at LiPPERTEmbedded.de Tue Sep 7 09:44:24 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Tue, 07 Sep 2010 09:44:24 +0200 Subject: [coreboot] [commit] r5778 - trunk/src/mainboard/emulation/qemu-x86 Message-ID: <4C85ED58.9090309@LiPPERTEmbedded.de> Hi, something went wrong with commit r5778, it's the wrong commit description and I definitely never signed off this patch. Regards, Jens From patrick at georgi-clan.de Tue Sep 7 09:44:46 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 07 Sep 2010 09:44:46 +0200 Subject: [coreboot] [PATCH] Geode LX and Alix.2 support enhancements In-Reply-To: References: Message-ID: <4C85ED6E.2010307@georgi-clan.de> Am 05.09.2010 00:00, schrieb Aur?lien: > Geode LX RAMBASE @1M support: This one is in. I also removed RAMBASE from Alix.2d (which would be part of your second patch). > Alix.2[cd][23] support enhancements > ---- I'll leave this to someone else, who knows Alix better than I do. Thanks, Patrick From arne.gleditsch at numascale.com Tue Sep 7 09:47:12 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Tue, 07 Sep 2010 09:47:12 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <05F28A7E6D2248C3963F2A7E67526E7C@m3a78> (Scott Duplichan's message of "Mon, 6 Sep 2010 12:19:42 -0500") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <05F28A7E6D2248C3963F2A7E67526E7C@m3a78> Message-ID: <87vd6iov0f.fsf@taniquetil.gledits.ch> "Scott Duplichan" writes: > One necessary condition for caching MMIO such as the flash chip on > AMD family 10h processors is not well known: > > If the processor has an L3 cache, then bit 15 of msr C001_102A > (ClLinesToNbDis) must be set. This bit needs to eventually be cleared > in order for the OS to use the L3 cache. But BIOS must not clear this > bit until cacheable accesses to the flash chip are no longer needed. > This situation applies only to family 10h processors that have L3 cache. > Often BIOS clears this bit too early and slow execution results.As an > experiment, you could add code to set this bit before the slow function > and see what happens. This is certainly interesting information. I'd like to test this out on real hardware, but I'm afraid I can't promise it'll be in the immediate future. -- Arne. From patrick at georgi-clan.de Tue Sep 7 09:49:08 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 07 Sep 2010 09:49:08 +0200 Subject: [coreboot] [commit] r5778 - trunk/src/mainboard/emulation/qemu-x86 In-Reply-To: <4C85ED58.9090309@LiPPERTEmbedded.de> References: <4C85ED58.9090309@LiPPERTEmbedded.de> Message-ID: <4C85EE74.2090904@georgi-clan.de> Am 07.09.2010 09:44, schrieb Jens Rottmann: > something went wrong with commit r5778, it's the wrong commit > description and I definitely never signed off this patch. Myles probably copy&pasted from the wrong mail. I fixed it up on the server. Patrick From svn at coreboot.org Tue Sep 7 09:53:27 2010 From: svn at coreboot.org (repository service) Date: Tue, 07 Sep 2010 09:53:27 +0200 Subject: [coreboot] [commit] r5780 - trunk/src/cpu/x86/tsc Message-ID: Author: oxygene Date: Tue Sep 7 09:53:26 2010 New Revision: 5780 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5780 Log: 2ms is enough time to accurately obtain the clock rate. Signed-off-by: Kevin O'Connor Acked-by: Patrick Georgi Modified: trunk/src/cpu/x86/tsc/delay_tsc.c Modified: trunk/src/cpu/x86/tsc/delay_tsc.c ============================================================================== --- trunk/src/cpu/x86/tsc/delay_tsc.c Tue Sep 7 09:43:10 2010 (r5779) +++ trunk/src/cpu/x86/tsc/delay_tsc.c Tue Sep 7 09:53:26 2010 (r5780) @@ -18,8 +18,8 @@ * device. */ -#define CALIBRATE_INTERVAL ((20*CLOCK_TICK_RATE)/1000) /* 20ms */ -#define CALIBRATE_DIVISOR (20*1000) /* 20ms / 20000 == 1usec */ +#define CALIBRATE_INTERVAL ((2*CLOCK_TICK_RATE)/1000) /* 2ms */ +#define CALIBRATE_DIVISOR (2*1000) /* 2ms / 2000 == 1usec */ static unsigned long long calibrate_tsc(void) { From patrick at georgi-clan.de Tue Sep 7 09:54:11 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 07 Sep 2010 09:54:11 +0200 Subject: [coreboot] [PATCH 3/4] Reduce TSC calibrations from 20ms to 2ms. In-Reply-To: <7986f0442d0e6007a1d479241229158fc4f902b9.1283815188.git.kevin@koconnor.net> References: <7986f0442d0e6007a1d479241229158fc4f902b9.1283815188.git.kevin@koconnor.net> Message-ID: <4C85EFA3.1070604@georgi-clan.de> Am 07.09.2010 01:24, schrieb Kevin O'Connor: > 2ms is enough time to accurately obtain the clock rate. > > Signed-off-by: Kevin O'Connor Acked-by: Patrick Georgi In as r5780 Thanks, Patrick From svn at coreboot.org Tue Sep 7 11:18:09 2010 From: svn at coreboot.org (repository service) Date: Tue, 07 Sep 2010 11:18:09 +0200 Subject: [coreboot] [commit] r5781 - in trunk/src: mainboard/amd/dbm690t mainboard/amd/mahogany mainboard/amd/mahogany_fam10 mainboard/amd/pistachio mainboard/amd/tilapia_fam10 mainboard/asrock/939a785gmh mainboard/gi... Message-ID: Author: oxygene Date: Tue Sep 7 11:18:08 2010 New Revision: 5781 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5781 Log: Remove unused ide0_enable and sata0_enable entries from SB7xx and SB600. Signed-off-by: Rudolf Marek Acked-by: Stefan Reinauer Modified: trunk/src/mainboard/amd/dbm690t/devicetree.cb trunk/src/mainboard/amd/mahogany/devicetree.cb trunk/src/mainboard/amd/mahogany_fam10/devicetree.cb trunk/src/mainboard/amd/pistachio/devicetree.cb trunk/src/mainboard/amd/tilapia_fam10/devicetree.cb trunk/src/mainboard/asrock/939a785gmh/devicetree.cb trunk/src/mainboard/gigabyte/ma785gmt/devicetree.cb trunk/src/mainboard/gigabyte/ma78gm/devicetree.cb trunk/src/mainboard/jetway/pa78vm5/devicetree.cb trunk/src/mainboard/kontron/kt690/devicetree.cb trunk/src/mainboard/technexion/tim5690/devicetree.cb trunk/src/mainboard/technexion/tim8690/devicetree.cb trunk/src/southbridge/amd/sb600/chip.h trunk/src/southbridge/amd/sb600/sb600_ide.c trunk/src/southbridge/amd/sb700/chip.h Modified: trunk/src/mainboard/amd/dbm690t/devicetree.cb ============================================================================== --- trunk/src/mainboard/amd/dbm690t/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/amd/dbm690t/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -106,8 +106,6 @@ device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # ACI 0x4382 device pci 14.6 on end # MCI 0x438e - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb600 end # device pci 18.0 Modified: trunk/src/mainboard/amd/mahogany/devicetree.cb ============================================================================== --- trunk/src/mainboard/amd/mahogany/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/amd/mahogany/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -106,10 +106,7 @@ end #LPC device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # USB 2 - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE - register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb700 end # device pci 18.0 Modified: trunk/src/mainboard/amd/mahogany_fam10/devicetree.cb ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/amd/mahogany_fam10/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -97,10 +97,7 @@ end #LPC device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # USB 2 - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE - register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb700 end # device pci 18.0 Modified: trunk/src/mainboard/amd/pistachio/devicetree.cb ============================================================================== --- trunk/src/mainboard/amd/pistachio/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/amd/pistachio/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -68,9 +68,6 @@ device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # ACI 0x4382 device pci 14.6 on end # MCI 0x438e - register "ide0_enable" = "1" - register "sata0_enable" = "1" - register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb600 end # device pci 18.0 Modified: trunk/src/mainboard/amd/tilapia_fam10/devicetree.cb ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/amd/tilapia_fam10/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -98,10 +98,7 @@ end #LPC device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # USB 2 - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE - register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb700 end # device pci 18.0 Modified: trunk/src/mainboard/asrock/939a785gmh/devicetree.cb ============================================================================== --- trunk/src/mainboard/asrock/939a785gmh/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/asrock/939a785gmh/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -116,10 +116,7 @@ end #LPC device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # USB 2 - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE - register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb700 end # device pci 18.0 Modified: trunk/src/mainboard/gigabyte/ma785gmt/devicetree.cb ============================================================================== --- trunk/src/mainboard/gigabyte/ma785gmt/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/gigabyte/ma785gmt/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -98,10 +98,7 @@ end #LPC device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # USB 2 - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE - register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb700 end # device pci 18.0 Modified: trunk/src/mainboard/gigabyte/ma78gm/devicetree.cb ============================================================================== --- trunk/src/mainboard/gigabyte/ma78gm/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/gigabyte/ma78gm/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -97,10 +97,7 @@ end #LPC device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # USB 2 - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE - register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb700 end # device pci 18.0 Modified: trunk/src/mainboard/jetway/pa78vm5/devicetree.cb ============================================================================== --- trunk/src/mainboard/jetway/pa78vm5/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/jetway/pa78vm5/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -97,10 +97,7 @@ end #LPC device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # USB 2 - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE - register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb700 end # device pci 18.0 Modified: trunk/src/mainboard/kontron/kt690/devicetree.cb ============================================================================== --- trunk/src/mainboard/kontron/kt690/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/kontron/kt690/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -110,8 +110,6 @@ device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # ACI 0x4382 device pci 14.6 on end # MCI 0x438e - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "hda_viddid" = "0x10ec0888" end #southbridge/amd/sb600 end # device pci 18.0 Modified: trunk/src/mainboard/technexion/tim5690/devicetree.cb ============================================================================== --- trunk/src/mainboard/technexion/tim5690/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/technexion/tim5690/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -106,8 +106,6 @@ device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # ACI 0x4382 device pci 14.6 on end # MCI 0x438e - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb600 end # device pci 18.0 Modified: trunk/src/mainboard/technexion/tim8690/devicetree.cb ============================================================================== --- trunk/src/mainboard/technexion/tim8690/devicetree.cb Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/mainboard/technexion/tim8690/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) @@ -106,8 +106,6 @@ device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # ACI 0x4382 device pci 14.6 on end # MCI 0x438e - register "ide0_enable" = "1" - register "sata0_enable" = "1" register "hda_viddid" = "0x10ec0882" end #southbridge/amd/sb600 end # device pci 18.0 Modified: trunk/src/southbridge/amd/sb600/chip.h ============================================================================== --- trunk/src/southbridge/amd/sb600/chip.h Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/southbridge/amd/sb600/chip.h Tue Sep 7 11:18:08 2010 (r5781) @@ -22,8 +22,6 @@ struct southbridge_amd_sb600_config { - u32 ide0_enable : 1; - u32 sata0_enable : 1; u32 hda_viddid; }; struct chip_operations; Modified: trunk/src/southbridge/amd/sb600/sb600_ide.c ============================================================================== --- trunk/src/southbridge/amd/sb600/sb600_ide.c Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/southbridge/amd/sb600/sb600_ide.c Tue Sep 7 11:18:08 2010 (r5781) @@ -26,11 +26,9 @@ static void ide_init(struct device *dev) { - struct southbridge_amd_sb600_config *conf; /* Enable ide devices so the linux ide driver will work */ u32 dword; u8 byte; - conf = dev->chip_info; /* RPR10.1 disable MSI */ dword = pci_read_config32(dev, 0x70); Modified: trunk/src/southbridge/amd/sb700/chip.h ============================================================================== --- trunk/src/southbridge/amd/sb700/chip.h Tue Sep 7 09:53:26 2010 (r5780) +++ trunk/src/southbridge/amd/sb700/chip.h Tue Sep 7 11:18:08 2010 (r5781) @@ -22,10 +22,7 @@ struct southbridge_amd_sb700_config { - u32 ide0_enable : 1; - u32 sata0_enable : 1; u32 boot_switch_sata_ide : 1; - u32 hda_viddid; }; struct chip_operations; extern struct chip_operations southbridge_amd_sb700_ops; From mylesgw at gmail.com Tue Sep 7 16:37:29 2010 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 7 Sep 2010 08:37:29 -0600 Subject: [coreboot] [commit] r5778 - trunk/src/mainboard/emulation/qemu-x86 In-Reply-To: <4C85ED58.9090309@LiPPERTEmbedded.de> References: <4C85ED58.9090309@LiPPERTEmbedded.de> Message-ID: <4008F8BB0FD241A4B46D41BD57152CCE@chimp> > something went wrong with commit r5778, it's the wrong commit > description and I definitely never signed off this patch. Yes. That's my fault. Sorry. Myles From JRottmann at LiPPERTEmbedded.de Tue Sep 7 18:19:49 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Tue, 07 Sep 2010 18:19:49 +0200 Subject: [coreboot] [PATCH] LiPPERT Cool LiteRunner-LX support Message-ID: <4C866625.9030006@LiPPERTEmbedded.de> This should take care of LiteRunner-LX support. Hurricane-LX will follow soon (I hope). Cheers, Jens -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LiteRunner-LX.diff URL: From uwe at hermann-uwe.de Tue Sep 7 19:11:45 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 7 Sep 2010 19:11:45 +0200 Subject: [coreboot] [flashrom] flashrom patch: add support for Abit AB-BM6 board In-Reply-To: <1283843932.27123.2.camel@aquila> References: <4C81B2EE.2060104@gmx.net> <1283795887.27123.1.camel@aquila> <1283843932.27123.2.camel@aquila> Message-ID: <20100907171145.GW19625@greenwood> On Tue, Sep 07, 2010 at 09:18:52AM +0200, Michael Karcher wrote: > Am Dienstag, den 07.09.2010, 09:06 +0200 schrieb Tim ter Laak: > > This patch adds support for the Abit BM6 board, using DMI string > > identification, and lists it in print.c . > > > > Signed-off-by: Tim ter Laak > Acked-by: Michael Karcher > > If no one else beats me to it, I will commit tonight. Looks good to me too, but two small requests: > Index: board_enable.c > =================================================================== > --- board_enable.c (revision 1153) > +++ board_enable.c (working copy) > @@ -1093,6 +1093,15 @@ > > /* > * Suited for: > + * - Abit AB-BM6 s/Abit/abit/ for consistency (though we may change the convention later). And: "AB-BM6" should be just "BM6" as that's the name on the website. Where does the "AB-" prefix come from? Does it say so on the PCB or something? Either way: Acked-by: Uwe Hermann Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From svn at coreboot.org Tue Sep 7 19:33:18 2010 From: svn at coreboot.org (repository service) Date: Tue, 07 Sep 2010 19:33:18 +0200 Subject: [coreboot] [commit] r5782 - in trunk/src/mainboard/lippert: . literunner-lx Message-ID: Author: myles Date: Tue Sep 7 19:33:17 2010 New Revision: 5782 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5782 Log: Add support for LiPPERT Cool LiteRunner-LX (PC/104 board with AMD Geode-LX, CS5536, ITE IT8712F), based on very similar SpaceRunner-LX. Signed-off-by: Jens Rottmann Acked-by: Myles Watson Added: trunk/src/mainboard/lippert/literunner-lx/ - copied from r5781, trunk/src/mainboard/lippert/spacerunner-lx/ Modified: trunk/src/mainboard/lippert/Kconfig trunk/src/mainboard/lippert/literunner-lx/Kconfig trunk/src/mainboard/lippert/literunner-lx/chip.h trunk/src/mainboard/lippert/literunner-lx/devicetree.cb trunk/src/mainboard/lippert/literunner-lx/irq_tables.c trunk/src/mainboard/lippert/literunner-lx/mainboard.c trunk/src/mainboard/lippert/literunner-lx/romstage.c Modified: trunk/src/mainboard/lippert/Kconfig ============================================================================== --- trunk/src/mainboard/lippert/Kconfig Tue Sep 7 11:18:08 2010 (r5781) +++ trunk/src/mainboard/lippert/Kconfig Tue Sep 7 19:33:17 2010 (r5782) @@ -5,6 +5,8 @@ config BOARD_LIPPERT_FRONTRUNNER bool "Cool Frontrunner" +config BOARD_LIPPERT_LITERUNNER_LX + bool "Cool LiteRunner-LX" config BOARD_LIPPERT_ROADRUNNER_LX bool "Cool RoadRunner-LX" config BOARD_LIPPERT_SPACERUNNER_LX @@ -13,6 +15,7 @@ endchoice source "src/mainboard/lippert/frontrunner/Kconfig" +source "src/mainboard/lippert/literunner-lx/Kconfig" source "src/mainboard/lippert/roadrunner-lx/Kconfig" source "src/mainboard/lippert/spacerunner-lx/Kconfig" Modified: trunk/src/mainboard/lippert/literunner-lx/Kconfig ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/Kconfig Tue Sep 7 11:18:08 2010 (r5781) +++ trunk/src/mainboard/lippert/literunner-lx/Kconfig Tue Sep 7 19:33:17 2010 (r5782) @@ -1,4 +1,4 @@ -if BOARD_LIPPERT_SPACERUNNER_LX +if BOARD_LIPPERT_LITERUNNER_LX config BOARD_SPECIFIC_OPTIONS # dummy def_bool y @@ -18,27 +18,28 @@ config MAINBOARD_DIR string - default lippert/spacerunner-lx + default lippert/literunner-lx config MAINBOARD_PART_NUMBER string - default "Cool SpaceRunner-LX" + default "Cool LiteRunner-LX" config IRQ_SLOT_COUNT int - default 7 + default 5 config ONBOARD_UARTS_RS485 - bool "Switch on-board serial ports to RS485" + bool "Switch on-board serial ports 1 & 2 to RS485" default n help - If selected, both on-board serial ports will operate in RS485 mode - instead of RS232. + If selected, the first two on-board serial ports will operate in RS485 + mode instead of RS232. config ONBOARD_IDE_SLAVE - bool "Make on-board SSD act as Slave" + bool "Make on-board CF socket act as Slave" default n help - If selected, the on-board SSD will act as IDE Slave instead of Master. + If selected, the on-board Compact Flash card socket will act as IDE + Slave instead of Master. -endif # BOARD_LIPPERT_SPACERUNNER_LX +endif # BOARD_LIPPERT_LITERUNNER_LX Modified: trunk/src/mainboard/lippert/literunner-lx/chip.h ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/chip.h Tue Sep 7 11:18:08 2010 (r5781) +++ trunk/src/mainboard/lippert/literunner-lx/chip.h Tue Sep 7 19:33:17 2010 (r5782) @@ -1,7 +1,7 @@ /* * This file is part of the coreboot project. * - * Copyright (C) 2008 LiPPERT Embedded Computers GmbH + * Copyright (C) 2010 LiPPERT Embedded Computers GmbH * * 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 Modified: trunk/src/mainboard/lippert/literunner-lx/devicetree.cb ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/devicetree.cb Tue Sep 7 11:18:08 2010 (r5781) +++ trunk/src/mainboard/lippert/literunner-lx/devicetree.cb Tue Sep 7 19:33:17 2010 (r5782) @@ -8,27 +8,24 @@ # SIRQ Mode = Active(Quiet) mode. Save power.... # Invert mask = IRQ 12 and 1 are active high. Keyboard and mouse, # UARTs, etc IRQs. OK - register "lpc_serirq_enable" = "0x000012DA" # 00010010 11011010 - register "lpc_serirq_polarity" = "0x0000ED25" # inverse of above + register "lpc_serirq_enable" = "0x0000129A" # 00010010 10011010 + register "lpc_serirq_polarity" = "0x0000ED65" # inverse of above register "lpc_serirq_mode" = "1" register "enable_gpio_int_route" = "0x0D0C0700" register "enable_ide_nand_flash" = "0" # 0:ide mode, 1:flash register "enable_USBP4_device" = "0" # 0:host, 1:device register "enable_USBP4_overcurrent" = "0" # 0:off, xxxx:overcurrent setting CS5536 Data Book (pages 380-381) - register "com1_enable" = "0" + register "com1_enable" = "1" register "com1_address" = "0x3E8" register "com1_irq" = "6" register "com2_enable" = "0" register "com2_address" = "0x2E8" register "com2_irq" = "6" - register "unwanted_vpci[0]" = "0x80007B00" # Audio: 1<<31 + Device 0x0F<<11 + Function 3<<8 - register "unwanted_vpci[1]" = "0" # End of list has a zero - device pci 8.0 on end # Slot4 - device pci 9.0 on end # Slot3 - device pci a.0 on end # Slot2 - device pci b.0 on end # Slot1 + register "unwanted_vpci[0]" = "0" # End of list has a zero + device pci 8.0 on end # Ethernet 2 device pci c.0 on end # IT8888 - device pci e.0 on end # Ethernet + device pci d.0 on end # Mini-PCI + device pci e.0 on end # Ethernet 1 device pci f.0 on # ISA Bridge chip superio/ite/it8712f device pnp 2e.0 off # Floppy @@ -76,7 +73,7 @@ end end device pci f.2 on end # IDE - device pci f.3 off end # Audio + device pci f.3 on end # Audio device pci f.4 on end # OHCI device pci f.5 on end # EHCI end Modified: trunk/src/mainboard/lippert/literunner-lx/irq_tables.c ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/irq_tables.c Tue Sep 7 11:18:08 2010 (r5781) +++ trunk/src/mainboard/lippert/literunner-lx/irq_tables.c Tue Sep 7 19:33:17 2010 (r5782) @@ -1,7 +1,7 @@ /* * This file is part of the coreboot project. * - * Copyright (C) 2008 LiPPERT Embedded Computers GmbH + * Copyright (C) 2010 LiPPERT Embedded Computers GmbH * * 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 @@ -18,7 +18,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -/* Based on irq_tables.c from AMD's DB800 mainboard. */ +/* Based on irq_tables.c from the SpaceRunner-LX mainboard. */ #include #include @@ -55,17 +55,15 @@ 0x002B, /* Device */ 0, /* Crap (miniport) */ {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, /* u8 rfu[11] */ - 0xE0, /* u8 checksum, this has to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ + 0xB8, /* u8 checksum, this has to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { /* If you change the number of entries, change the CONFIG_IRQ_SLOT_COUNT above! */ /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* CPU */ {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* chipset */ - {0x00, (0x0E << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* ethernet */ - {0x00, (0x0B << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x1, 0x0}, /* slot1 */ - {0x00, (0x0A << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x2, 0x0}, /* slot2 */ - {0x00, (0x09 << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x3, 0x0}, /* slot3 */ - {0x00, (0x08 << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x4, 0x0}, /* slot4 */ + {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* ethernet 1 */ + {0x00, (0x08 << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* ethernet 2 */ + {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}}, 0x1, 0x0}, /* Mini-PCI */ } }; Modified: trunk/src/mainboard/lippert/literunner-lx/mainboard.c ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/mainboard.c Tue Sep 7 11:18:08 2010 (r5781) +++ trunk/src/mainboard/lippert/literunner-lx/mainboard.c Tue Sep 7 19:33:17 2010 (r5782) @@ -1,7 +1,7 @@ /* * This file is part of the coreboot project. * - * Copyright (C) 2008 LiPPERT Embedded Computers GmbH + * Copyright (C) 2010 LiPPERT Embedded Computers GmbH * * 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 @@ -18,7 +18,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -/* Based on mainboard.c from AMD's DB800 mainboard. */ +/* Based on mainboard.c from the SpaceRunner-LX mainboard. */ #include #include @@ -36,6 +36,9 @@ #define SIO_GP1X_CONFIG 0x01 #endif +/* Bit0 enables COM3's transceiver, bit1 disables the RS485 receiver (e.g. for IR). */ +#define SIO_GP2X_CONFIG 0x00 + static const u16 ec_init_table[] = { /* hi=data, lo=index */ 0x1900, /* Enable monitoring */ 0x3050, /* VIN4,5 enabled */ @@ -49,7 +52,7 @@ static void init(struct device *dev) { unsigned int gpio_base, i; - printk(BIOS_DEBUG, "LiPPERT SpaceRunner-LX ENTER %s\n", __func__); + printk(BIOS_DEBUG, "LiPPERT LiteRunner-LX ENTER %s\n", __func__); /* Init CS5536 GPIOs */ gpio_base = pci_read_config32(dev_find_device(PCI_VENDOR_ID_AMD, @@ -73,8 +76,10 @@ /* bit2 = RS485_EN2, bit1 = RS485_EN1, bit0 = Live LED */ outb(SIO_GP1X_CONFIG, 0x1220); /* Simple-I/O GP17-10 */ + /* bit1 = COM3_RX_EN, bit0 = COM3_TX_EN */ + outb(SIO_GP2X_CONFIG, 0x1221); /* Simple-I/O GP27-20 */ - printk(BIOS_DEBUG, "LiPPERT SpaceRunner-LX EXIT %s\n", __func__); + printk(BIOS_DEBUG, "LiPPERT LiteRunner-LX EXIT %s\n", __func__); } static void enable_dev(struct device *dev) @@ -83,6 +88,6 @@ } struct chip_operations mainboard_ops = { - CHIP_NAME("LiPPERT SpaceRunner-LX Mainboard") + CHIP_NAME("LiPPERT LiteRunner-LX Mainboard") .enable_dev = enable_dev, }; Modified: trunk/src/mainboard/lippert/literunner-lx/romstage.c ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/romstage.c Tue Sep 7 11:18:08 2010 (r5781) +++ trunk/src/mainboard/lippert/literunner-lx/romstage.c Tue Sep 7 19:33:17 2010 (r5782) @@ -2,7 +2,7 @@ * This file is part of the coreboot project. * * Copyright (C) 2007 Advanced Micro Devices, Inc. - * Copyright (C) 2008 LiPPERT Embedded Computers GmbH + * Copyright (C) 2010 LiPPERT Embedded Computers GmbH * * 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 @@ -19,7 +19,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -/* Based on romstage.c from AMD's DB800 and DBM690T mainboards. */ +/* Based on romstage.c from the SpaceRunner-LX mainboard. */ #include #include @@ -40,7 +40,7 @@ #include "southbridge/amd/cs5536/cs5536_early_setup.c" #include "superio/ite/it8712f/it8712f_early_serial.c" -/* Bit0 enables Spread Spectrum, bit1 makes on-board SSD act as IDE slave. */ +/* Bit0 enables Spread Spectrum, bit1 makes on-board CF slot act as IDE slave. */ #if CONFIG_ONBOARD_IDE_SLAVE #define SMC_CONFIG 0x03 #else @@ -137,9 +137,12 @@ #endif 0xBF25, 0x172A, 0xF326, // select GPIO function for most pins 0xFF27, 0xDF28, 0x2729, // (GP45=SUSB, GP23,22,16,15=SPI, GP13=PWROK1) - 0x66B8, 0x0CB9, // enable pullups on SPI, RS485_EN + 0x66B8, 0x0FB9, // enable pullups on SPI, RS485_EN, COM3_R/TX_EN 0x07C0, // enable Simple-I/O for GP12-10= RS485_EN2,1, LIVE_LED + 0x03C1, // enable Simple-I/O for GP21-20= COM3_RX_EN,TX_EN + 0xFFC2, // enable Simple-I/O for GP37-30 0x07C8, // config GP12-10 as output + 0x03C9, // config GP21-20 as output 0x2DF5, // map Hw Monitor Thermal Output to GP55 0x08F8, // map GP LED Blinking 1 to GP10=LIVE_LED (deactivate Simple I/O to use) }; From mylesgw at gmail.com Tue Sep 7 19:35:27 2010 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 7 Sep 2010 11:35:27 -0600 Subject: [coreboot] [PATCH] LiPPERT Cool LiteRunner-LX support In-Reply-To: <4C866625.9030006@LiPPERTEmbedded.de> References: <4C866625.9030006@LiPPERTEmbedded.de> Message-ID: On Tue, Sep 7, 2010 at 10:19 AM, Jens Rottmann wrote: > This should take care of LiteRunner-LX support. ?Hurricane-LX will > follow soon (I hope). > > Cheers, > Jens > > Add support for LiPPERT Cool LiteRunner-LX (PC/104 board with AMD > Geode-LX, CS5536, ITE IT8712F), based on very similar SpaceRunner-LX. I used svn cp to copy the spacerunner-lx directory first, to make the diff smaller and keep the history intact. > Signed-off-by: Jens Rottmann Acked-by: Myles Watson Rev 5782. Thanks, Myles From timl at scintilla.utwente.nl Tue Sep 7 21:10:35 2010 From: timl at scintilla.utwente.nl (Tim ter Laak) Date: Tue, 7 Sep 2010 21:10:35 +0200 (CEST) Subject: [coreboot] [flashrom] flashrom patch: add support for Abit AB-BM6 board In-Reply-To: <20100907171145.GW19625@greenwood> References: <4C81B2EE.2060104@gmx.net> <1283795887.27123.1.camel@aquila> <1283843932.27123.2.camel@aquila> <20100907171145.GW19625@greenwood> Message-ID: This patch adds support for the Abit BM6 board, using DMI string identification, and lists it in print.c [v3]. Signed-off-by: Tim ter Laak --- On Tue, 7 Sep 2010, Uwe Hermann wrote: > Looks good to me too, but two small requests: > >> + * - Abit AB-BM6 > > s/Abit/abit/ for consistency (though we may change the convention later). > > And: "AB-BM6" should be just "BM6" as that's the name on the website. > Where does the "AB-" prefix come from? Does it say so on the PCB or > something? Fair enough. It's worth it to keep an eye on grep-ability ;) And yeah, the AB-BM6 is the marking on the board itself. On closer inspection, the AB part must be there just to express the Abit brand, as I cannot find their name printed anywhere on the board. Updated patch is attached. Tim. > Either way: > > Acked-by: Uwe Hermann -------------- next part -------------- Index: print.c =================================================================== --- print.c (revision 1155) +++ print.c (working copy) @@ -283,6 +283,7 @@ B("A-Trend", "ATC-6220", 1, "http://www.motherboard.cz/mb/atrend/atc6220.htm", NULL), B("abit", "AN-M2", 1, "http://www.abit.com.tw/page/de/motherboard/motherboard_detail.php?DEFTITLE=Y&fMTYPE=Socket%20AM2&pMODEL_NAME=AN-M2", NULL), B("abit", "AX8", 1, "http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?DEFTITLE=Y&fMTYPE=Socket%20939&pMODEL_NAME=AX8", NULL), + B("abit", "BM6", 1, "http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=BM6&fMTYPE=Socket%20370", NULL), B("abit", "Fatal1ty F-I90HD", 1, "http://www.abit.com.tw/page/de/motherboard/motherboard_detail.php?pMODEL_NAME=Fatal1ty+F-I90HD&fMTYPE=LGA775", NULL), B("abit", "IC7", 1, "http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=IC7&fMTYPE=Socket%20478", NULL), B("abit", "IP35", 1, "http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?fMTYPE=LGA775&pMODEL_NAME=IP35", NULL), Index: board_enable.c =================================================================== --- board_enable.c (revision 1155) +++ board_enable.c (working copy) @@ -1103,6 +1103,15 @@ /* * Suited for: + * - abit BM6 + */ +static int intel_piix4_gpo26_lower(void) +{ + return intel_piix4_gpo_set(26, 0); +} + +/* + * Suited for: * - Intel SE440BX-2 */ static int intel_piix4_gpo27_lower(void) @@ -1773,6 +1782,7 @@ /* first pci-id set [4], second pci-id set [4], dmi identifier coreboot id [2], vendor name board name max_rom_... OK? flash enable */ #if defined(__i386__) || defined(__x86_64__) {0x10DE, 0x0547, 0x147B, 0x1C2F, 0x10DE, 0x0548, 0x147B, 0x1C2F, NULL, NULL, NULL, "abit", "AN-M2", 0, NT, nvidia_mcp_gpio2_raise}, + {0x8086, 0x7190, 0, 0, 0x8086, 0x7110, 0, 0, "^i440BX-W977 (BM6)$", NULL, NULL, "abit", "BM6", 0, OK, intel_piix4_gpo26_lower}, {0x8086, 0x24d3, 0x147b, 0x1014, 0x8086, 0x2578, 0x147b, 0x1014, NULL, NULL, NULL, "abit", "IC7", 0, NT, intel_ich_gpio23_raise}, {0x8086, 0x2930, 0x147b, 0x1084, 0x11ab, 0x4364, 0x147b, 0x1084, NULL, NULL, NULL, "abit", "IP35", 0, OK, intel_ich_gpio16_raise}, {0x8086, 0x2930, 0x147b, 0x1083, 0x10ec, 0x8167, 0x147b, 0x1083, NULL, NULL, NULL, "abit", "IP35 Pro", 0, OK, intel_ich_gpio16_raise}, From svn at coreboot.org Wed Sep 8 00:30:15 2010 From: svn at coreboot.org (repository service) Date: Wed, 08 Sep 2010 00:30:15 +0200 Subject: [coreboot] [commit] r5783 - in trunk/src: . devices/oprom Message-ID: Author: myles Date: Wed Sep 8 00:30:15 2010 New Revision: 5783 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5783 Log: Make a Kconfig option for debugging output from realmode emulation. Trivial. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/Kconfig trunk/src/devices/oprom/x86.c trunk/src/devices/oprom/x86_interrupts.c Modified: trunk/src/Kconfig ============================================================================== --- trunk/src/Kconfig Tue Sep 7 19:33:17 2010 (r5782) +++ trunk/src/Kconfig Wed Sep 8 00:30:15 2010 (r5783) @@ -543,6 +543,17 @@ If unsure, say N. +config REALMODE_DEBUG + bool "Enable debug messages for option ROM execution" + default n + depends on PCI_OPTION_ROM_RUN_REALMODE + help + This option enables additional x86emu related debug messages. + + Note: This option will increase the time to emulate a ROM. + + If unsure, say N. + config X86EMU_DEBUG bool "Output verbose x86emu debug messages" default n Modified: trunk/src/devices/oprom/x86.c ============================================================================== --- trunk/src/devices/oprom/x86.c Tue Sep 7 19:33:17 2010 (r5782) +++ trunk/src/devices/oprom/x86.c Wed Sep 8 00:30:15 2010 (r5783) @@ -329,6 +329,7 @@ cs = cs_ip >> 16; flags = stackflags; +#if CONFIG_REALMODE_DEBUG printk(BIOS_DEBUG, "oprom: INT# 0x%x\n", intnumber); printk(BIOS_DEBUG, "oprom: eax: %08x ebx: %08x ecx: %08x edx: %08x\n", eax, ebx, ecx, edx); @@ -336,6 +337,7 @@ ebp, esp, edi, esi); printk(BIOS_DEBUG, "oprom: ip: %04x cs: %04x flags: %08x\n", ip, cs, flags); +#endif // Fetch arguments from the stack and put them into // a structure that we want to pass on to our sub interrupt Modified: trunk/src/devices/oprom/x86_interrupts.c ============================================================================== --- trunk/src/devices/oprom/x86_interrupts.c Tue Sep 7 19:33:17 2010 (r5782) +++ trunk/src/devices/oprom/x86_interrupts.c Wed Sep 8 00:30:15 2010 (r5783) @@ -156,8 +156,10 @@ break; } +#if CONFIG_REALMODE_DEBUG printk(BIOS_DEBUG, "0x%x: bus %d devfn 0x%x reg 0x%x val 0x%x\n", func, bus, devfn, reg, regs->ecx); +#endif regs->eax = 0; retval = 0; break; From peter at stuge.se Wed Sep 8 00:34:33 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 8 Sep 2010 00:34:33 +0200 Subject: [coreboot] [commit] r5783 - in trunk/src: . devices/oprom In-Reply-To: References: Message-ID: <20100907223433.27022.qmail@stuge.se> repository service wrote: > +config REALMODE_DEBUG > + bool "Enable debug messages for option ROM execution" > + default n > + depends on PCI_OPTION_ROM_RUN_REALMODE > + help > + This option enables additional x86emu related debug messages. x86emu? //Peter From svn at coreboot.org Wed Sep 8 01:28:00 2010 From: svn at coreboot.org (repository service) Date: Wed, 08 Sep 2010 01:28:00 +0200 Subject: [coreboot] [commit] r5784 - trunk/src/devices/oprom Message-ID: Author: myles Date: Wed Sep 8 01:27:59 2010 New Revision: 5784 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5784 Log: My Jmicron SATA card depends on the BIOS not clearing AL when setting AH. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/devices/oprom/x86_interrupts.c Modified: trunk/src/devices/oprom/x86_interrupts.c ============================================================================== --- trunk/src/devices/oprom/x86_interrupts.c Wed Sep 8 00:30:15 2010 (r5783) +++ trunk/src/devices/oprom/x86_interrupts.c Wed Sep 8 01:27:59 2010 (r5784) @@ -99,7 +99,8 @@ } if (dev) { unsigned short busdevfn; - regs->eax = 0; + regs->eax &= 0xffff00ff; /* Clear AH */ + regs->eax |= PCIBIOS_SUCCESSFUL; // busnum is an unsigned char; // devfn is an int, so we mask it off. busdevfn = (dev->bus->secondary << 8) @@ -108,7 +109,8 @@ regs->ebx = busdevfn; retval = 0; } else { - regs->eax = PCIBIOS_NODEV; + regs->eax &= 0xffff00ff; /* Clear AH */ + regs->eax |= PCIBIOS_NODEV; retval = -1; } break; @@ -125,7 +127,8 @@ if (!dev) { printk(BIOS_DEBUG, "0x%x: BAD DEVICE bus %d devfn 0x%x\n", func, bus, devfn); // Or are we supposed to return PCIBIOS_NODEV? - regs->eax = PCIBIOS_BADREG; + regs->eax &= 0xffff00ff; /* Clear AH */ + regs->eax |= PCIBIOS_BADREG; retval = -1; return retval; } @@ -160,11 +163,14 @@ printk(BIOS_DEBUG, "0x%x: bus %d devfn 0x%x reg 0x%x val 0x%x\n", func, bus, devfn, reg, regs->ecx); #endif - regs->eax = 0; + regs->eax &= 0xffff00ff; /* Clear AH */ + regs->eax |= PCIBIOS_SUCCESSFUL; retval = 0; break; default: printk(BIOS_ERR, "UNSUPPORTED PCIBIOS FUNCTION 0x%x\n", func); + regs->eax &= 0xffff00ff; /* Clear AH */ + regs->eax |= PCIBIOS_UNSUPPORTED; retval = -1; break; } From mylesgw at gmail.com Wed Sep 8 01:38:10 2010 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 7 Sep 2010 17:38:10 -0600 Subject: [coreboot] [PATCH] basic realmode handlers for int 0x10 and int 0x16 Message-ID: My Jmicron SATA card writes the name of the hard drive to the screen. This redirects that output to the console and implements a basic keyboard stub. Signed-off-by: Myles Watson It makes the image a little bit larger (512 bytes after compression), so I'm wondering if I should wrap it in a Kconfig option. It doesn't seem worth the mess in the code for such a little bit of space. Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: int_handlers.diff Type: text/x-diff Size: 2857 bytes Desc: not available URL: From mylesgw at gmail.com Wed Sep 8 01:39:52 2010 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 7 Sep 2010 17:39:52 -0600 Subject: [coreboot] [commit] r5783 - in trunk/src: . devices/oprom In-Reply-To: <20100907223433.27022.qmail@stuge.se> References: <20100907223433.27022.qmail@stuge.se> Message-ID: On Tue, Sep 7, 2010 at 4:34 PM, Peter Stuge wrote: > repository service wrote: >> +config REALMODE_DEBUG >> + ? ? bool "Enable debug messages for option ROM execution" >> + ? ? default n >> + ? ? depends on PCI_OPTION_ROM_RUN_REALMODE >> + ? ? help >> + ? ? ? This option enables additional x86emu related debug messages. > > x86emu? The code lives in src/devices/oprom/x86emu... Suggestions? Thanks, Myles From peter at stuge.se Wed Sep 8 02:16:25 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 8 Sep 2010 02:16:25 +0200 Subject: [coreboot] [commit] r5783 - in trunk/src: . devices/oprom In-Reply-To: References: <20100907223433.27022.qmail@stuge.se> Message-ID: <20100908001625.7363.qmail@stuge.se> Myles Watson wrote: > >> +config REALMODE_DEBUG > >> + ? ? bool "Enable debug messages for option ROM execution" > >> + ? ? default n > >> + ? ? depends on PCI_OPTION_ROM_RUN_REALMODE > >> + ? ? help > >> + ? ? ? This option enables additional x86emu related debug messages. > > > > x86emu? > The code lives in src/devices/oprom/x86emu... > > Suggestions? "REALMODE" is a bit confusing if it is emulated after all. Or? //Peter From kevin at koconnor.net Wed Sep 8 02:23:30 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Tue, 7 Sep 2010 20:23:30 -0400 Subject: [coreboot] [PATCH 2/4] Enable TSC calibration with timer2 by default. In-Reply-To: <4C85E4B8.9000203@georgi-clan.de> References: <653639f7559fcf14685c35907fd9e733c2e89901.1283815188.git.kevin@koconnor.net> <4C85E4B8.9000203@georgi-clan.de> Message-ID: <20100908002330.GA2963@morn.localdomain> On Tue, Sep 07, 2010 at 09:07:36AM +0200, Patrick Georgi wrote: > Am 07.09.2010 01:23, schrieb Kevin O'Connor: > > Enable TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 by default. Without this > > set, almost all boards use the inb(0x80) method. Unfortunately, that > > method takes over a second to calibrate, and it's results are not as > > reliable. > > > > There is a chance that some boards may not work well with the timer2 > > method. This is likely rare, because both libpayload and seabios use > > the timer2 method unconditionally and there has not been reports of an > > issue. Should a board not support the more accurate timer2 mechanism, > > it will need to be updated to actively disable it. > How about this instead? It allows boards that require the workaround to > simply "select" it. > > Signed-off-by: Patrick Georgi That looks like a better approach. Acked-by: Kevin O'Connor As an aside, I'm not sure of the value of TSC based delays if inb(0x80) is used to time it. If the code assumes inb(0x80) is 1 usecond, I'd think it could as easily use UDELAY_IO instead. I guess we'll need to see if any boards need the new TSC_CALIBRATE_WITH_IO setting. -Kevin From kevin at koconnor.net Wed Sep 8 02:25:34 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Tue, 7 Sep 2010 20:25:34 -0400 Subject: [coreboot] [PATCH 1/4] Make initializing PS2 keyboard optional. In-Reply-To: <4C85E1FE.2040706@georgi-clan.de> References: <53241126486840e63685efc05e61ee3b9dac2b9b.1283815188.git.kevin@koconnor.net> <4C85E1FE.2040706@georgi-clan.de> Message-ID: <20100908002534.GB2963@morn.localdomain> On Tue, Sep 07, 2010 at 08:55:58AM +0200, Patrick Georgi wrote: > Am 07.09.2010 01:23, schrieb Kevin O'Connor: > > + Enable this option to initialize PS2 keyboards found connected > > + to the PS2 port. Some payloads (eg, filo) require this > > + option. Other payloads (eg, SeaBIOS, Linux) do not require > If that's only libpayload that's lacking this kind of init, maybe we > should reimplement it there, and drop this init altogether? I think libpayload should be updated. I think adding the option to coreboot is a good intermediate step. It will give folks time to update their payloads. I'm also not sure if plan9 (or other less common payloads) will have the proper support. -Kevin From rminnich at gmail.com Wed Sep 8 02:34:38 2010 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Sep 2010 17:34:38 -0700 Subject: [coreboot] [PATCH 1/4] Make initializing PS2 keyboard optional. In-Reply-To: <20100908002534.GB2963@morn.localdomain> References: <53241126486840e63685efc05e61ee3b9dac2b9b.1283815188.git.kevin@koconnor.net> <4C85E1FE.2040706@georgi-clan.de> <20100908002534.GB2963@morn.localdomain> Message-ID: On Tue, Sep 7, 2010 at 5:25 PM, Kevin O'Connor wrote: > I think libpayload should be updated. ?I think adding the option to > coreboot is a good intermediate step. ?It will give folks time to > update their payloads. ?I'm also not sure if plan9 (or other less > common payloads) will have the proper support. > There's more and more movement in Plan 9 toward ARM, but that said, if this kind of thing has to go into Plan 9 I think we can make it happen. ron From kevin at koconnor.net Wed Sep 8 02:28:27 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Tue, 7 Sep 2010 20:28:27 -0400 Subject: [coreboot] [PATCH 4/4] Don't preload the rom code during the VIA CAR setup. In-Reply-To: <4C85E563.8000604@georgi-clan.de> References: <4C85E563.8000604@georgi-clan.de> Message-ID: <20100908002826.GC2963@morn.localdomain> On Tue, Sep 07, 2010 at 09:10:27AM +0200, Patrick Georgi wrote: > Am 07.09.2010 01:24, schrieb Kevin O'Connor: > > +#ifdef CARTEST > > movl REAL_XIP_ROM_BASE, %esi > > movl %esi, %edi > > movl $(CONFIG_XIP_ROM_SIZE>>2), %ecx > > rep lodsl > > +#endif > Can this be removed altogether then? The next few lines in the file also reference CARTEST: #ifdef CARTEST movl REAL_XIP_ROM_BASE, %esi movl %esi, %edi movl $(CONFIG_XIP_ROM_SIZE>>2), %ecx rep lodsl #endif /* The key point of this CAR code is C7 cache does not turn into * "no fill" mode, which is not compatible with general CAR code. */ movl $(CacheBase + CacheSize - 4), %eax movl %eax, %esp #ifdef CARTEST testok: post_code(0x40) ... I think anyone wanting to run with CARTEST will want the rom preloaded (to ensure they're doing an accurate test). -Kevin From mylesgw at gmail.com Wed Sep 8 04:01:28 2010 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 7 Sep 2010 20:01:28 -0600 Subject: [coreboot] [commit] r5783 - in trunk/src: . devices/oprom In-Reply-To: <20100908001625.7363.qmail@stuge.se> References: <20100907223433.27022.qmail@stuge.se> <20100908001625.7363.qmail@stuge.se> Message-ID: <4F2C423D4F4E4525BA86E6E405543389@chimp> > Myles Watson wrote: > > >> +config REALMODE_DEBUG > > >> + ? ? bool "Enable debug messages for option ROM execution" > > >> + ? ? default n > > >> + ? ? depends on PCI_OPTION_ROM_RUN_REALMODE > > >> + ? ? help > > >> + ? ? ? This option enables additional x86emu related debug messages. > > > > > > x86emu? > > The code lives in src/devices/oprom/x86emu... > > > > Suggestions? > > "REALMODE" is a bit confusing if it is emulated after all. Or? I think in this case a minimal BIOS is what's being "emulated." The ROM is executed in real mode. Thanks, Myles From peter at stuge.se Wed Sep 8 04:10:33 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 8 Sep 2010 04:10:33 +0200 Subject: [coreboot] [commit] r5783 - in trunk/src: . devices/oprom In-Reply-To: <4F2C423D4F4E4525BA86E6E405543389@chimp> References: <20100908001625.7363.qmail@stuge.se> <4F2C423D4F4E4525BA86E6E405543389@chimp> Message-ID: <20100908021033.21483.qmail@stuge.se> Myles Watson wrote: > > > The code lives in src/devices/oprom/x86emu... > > > > "REALMODE" is a bit confusing if it is emulated after all. Or? > > I think in this case a minimal BIOS is what's being "emulated." > The ROM is executed in real mode. Ok. How does x86emu fit in there? It's a realmode emulator.. :) I think I asked this before, sorry, but I find it really confusing. //Peter From liutao1980 at gmail.com Wed Sep 8 03:40:05 2010 From: liutao1980 at gmail.com (Liu Tao) Date: Wed, 8 Sep 2010 09:40:05 +0800 Subject: [coreboot] [PATCH] libpayload string.c fix In-Reply-To: References: Message-ID: Hello, the patch fixes strcmp()/strncmp()/strcasecmp()/strncasecmp() in libpayload string.c Signed-off-by: Liu Tao -- Regards, Liu Tao -------------- next part -------------- A non-text attachment was scrubbed... Name: string.patch Type: application/octet-stream Size: 1582 bytes Desc: not available URL: From mylesgw at gmail.com Wed Sep 8 04:20:39 2010 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 7 Sep 2010 20:20:39 -0600 Subject: [coreboot] [commit] r5783 - in trunk/src: . devices/oprom In-Reply-To: <20100908021033.21483.qmail@stuge.se> References: <20100908001625.7363.qmail@stuge.se><4F2C423D4F4E4525BA86E6E405543389@chimp> <20100908021033.21483.qmail@stuge.se> Message-ID: > > > > The code lives in src/devices/oprom/x86emu... > > > > > > "REALMODE" is a bit confusing if it is emulated after all. Or? > > > > I think in this case a minimal BIOS is what's being "emulated." > > The ROM is executed in real mode. > > Ok. How does x86emu fit in there? It's a realmode emulator.. :) > I think I asked this before, sorry, but I find it really confusing. It's the filename of where the code lives. It was written & merged before I'd heard of Coreboot. I like Kconfig options & help that give a hint as to where in the tree you can find things. Thanks, Myles From liutao1980 at gmail.com Wed Sep 8 03:32:46 2010 From: liutao1980 at gmail.com (Liu Tao) Date: Wed, 8 Sep 2010 09:32:46 +0800 Subject: [coreboot] libpayload string.c fix Message-ID: fix strcmp()/strncmp()/strcasecmp()/strncasecmp() -- Regards, Liu Tao -------------- next part -------------- A non-text attachment was scrubbed... Name: string.patch Type: application/octet-stream Size: 1582 bytes Desc: not available URL: From JRottmann at LiPPERTEmbedded.de Wed Sep 8 11:05:23 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Wed, 08 Sep 2010 11:05:23 +0200 Subject: [coreboot] [PATCH] LiPPERT Cool LiteRunner-LX support In-Reply-To: References: <4C866625.9030006@LiPPERTEmbedded.de> Message-ID: <4C8751D3.50900@LiPPERTEmbedded.de> Hi Myles, > I used svn cp to copy the spacerunner-lx directory first, to make the > diff smaller and keep the history intact. Good thinking! :) > Acked-by: Myles Watson > Rev 5782. Thank you very much!!! Cheers, Jens From svn at coreboot.org Wed Sep 8 12:27:14 2010 From: svn at coreboot.org (repository service) Date: Wed, 08 Sep 2010 12:27:14 +0200 Subject: [coreboot] [commit] r5785 - trunk/payloads/libpayload/libc Message-ID: Author: oxygene Date: Wed Sep 8 12:27:13 2010 New Revision: 5785 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5785 Log: Changes to str*cmp functions. Fixes a couple more corner cases. Signed-off-by: Liu Tao Acked-by: Patrick Georgi Modified: trunk/payloads/libpayload/libc/string.c Modified: trunk/payloads/libpayload/libc/string.c ============================================================================== --- trunk/payloads/libpayload/libc/string.c Wed Sep 8 01:27:59 2010 (r5784) +++ trunk/payloads/libpayload/libc/string.c Wed Sep 8 12:27:13 2010 (r5785) @@ -89,14 +89,15 @@ */ int strcasecmp(const char *s1, const char *s2) { - int i; + int i, res; - for (i = 0; s1[i] != '\0'; i++) { - if (tolower(s1[i]) != tolower(s2[i])) - return s1[i] - s2[i]; + for (i = 0; 1; i++) { + res = tolower(s1[i]) - tolower(s2[i]); + if (res || (s1[i] == '\0')) + break; } - return 0; + return res; } /** @@ -109,14 +110,16 @@ */ int strncasecmp(const char *s1, const char *s2, size_t maxlen) { - int i; + int i, res; + res = 0; for (i = 0; i < maxlen; i++) { - if (tolower(s1[i]) != tolower(s2[i])) - return s1[i] - s2[i]; + res = tolower(s1[i]) - tolower(s2[i]); + if (res || (s1[i] == '\0')) + break; } - return s1[i] - s2[i]; + return res; } /** @@ -130,14 +133,15 @@ */ int strcmp(const char *s1, const char *s2) { - int i; + int i, res; - for (i = 0; s1[i] != '\0'; i++) { - if (s1[i] != s2[i]) - return s1[i] - s2[i]; + for (i = 0; 1; i++) { + res = s1[i] - s2[i]; + if (res || (s1[i] == '\0')) + break; } - return s1[i] - s2[i]; + return res; } /** @@ -150,14 +154,16 @@ */ int strncmp(const char *s1, const char *s2, size_t maxlen) { - int i; + int i, res; + res = 0; for (i = 0; i < maxlen; i++) { - if (s1[i] != s2[i]) - return s1[i] - s2[i]; + res = s1[i] - s2[i]; + if (res || (s1[i] == '\0')) + break; } - return 0; + return res; } /** From patrick at georgi-clan.de Wed Sep 8 12:27:38 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 08 Sep 2010 12:27:38 +0200 Subject: [coreboot] [PATCH] libpayload string.c fix In-Reply-To: References: Message-ID: <4C87651A.4070306@georgi-clan.de> Am 08.09.2010 03:40, schrieb Liu Tao: > Signed-off-by: Liu Tao Thank you, committed in r5785 Regards, Patrick From svn at coreboot.org Wed Sep 8 12:53:44 2010 From: svn at coreboot.org (repository service) Date: Wed, 08 Sep 2010 12:53:44 +0200 Subject: [coreboot] [commit] r5786 - trunk/src/cpu/via/car Message-ID: Author: oxygene Date: Wed Sep 8 12:53:44 2010 New Revision: 5786 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5786 Log: It should not be necessary to read in the rom during CAR setup. Removing the code preloading reduces the boot time. Preload code is enabled when doing CARTEST (not exposed to Kconfig given that it's a pure debugging measure) Signed-off-by: Kevin O'Connor Acked-by: Patrick Georgi Modified: trunk/src/cpu/via/car/cache_as_ram.inc Modified: trunk/src/cpu/via/car/cache_as_ram.inc ============================================================================== --- trunk/src/cpu/via/car/cache_as_ram.inc Wed Sep 8 12:27:13 2010 (r5785) +++ trunk/src/cpu/via/car/cache_as_ram.inc Wed Sep 8 12:53:44 2010 (r5786) @@ -139,10 +139,12 @@ xorl $0x5c5c5c5c,%eax rep stosl +#ifdef CARTEST movl REAL_XIP_ROM_BASE, %esi movl %esi, %edi movl $(CONFIG_XIP_ROM_SIZE>>2), %ecx rep lodsl +#endif /* The key point of this CAR code is C7 cache does not turn into * "no fill" mode, which is not compatible with general CAR code. From patrick at georgi-clan.de Wed Sep 8 12:54:03 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 08 Sep 2010 12:54:03 +0200 Subject: [coreboot] [PATCH 4/4] Don't preload the rom code during the VIA CAR setup. In-Reply-To: <20100908002826.GC2963@morn.localdomain> References: <4C85E563.8000604@georgi-clan.de> <20100908002826.GC2963@morn.localdomain> Message-ID: <4C876B4B.4070502@georgi-clan.de> Am 08.09.2010 02:28, schrieb Kevin O'Connor: > I think anyone wanting to run with CARTEST will want the rom preloaded > (to ensure they're doing an accurate test). True. It's in as r5786 Patrick From mats.andersson at gisladisker.se Wed Sep 8 12:55:35 2010 From: mats.andersson at gisladisker.se (Mats Erik Andersson) Date: Wed, 8 Sep 2010 12:55:35 +0200 Subject: [coreboot] MS-6147, SeaBIOS, and OpenBSD. In-Reply-To: <20100903235211.6105.qmail@stuge.se> References: <20100827092106.GA28159@mea.homelinux.org> <20100903235211.6105.qmail@stuge.se> Message-ID: <20100908105535.GA25437@mea.homelinux.org> I have worked on variations on the previous setup. l?rdag den 4 september 2010 klockan 01:52 skrev Peter Stuge detta: > Mats Erik Andersson wrote: > > 2. In the overview of supported mainboards, there ought to > > be an entry "Y" for MSI MS-6147, stipulating that the > > DIL32-ROM is set in a socket. > > Done. Flashrom too? Yes, and in fact the untested erasure of EON EN29F002NT can now be marked as working for Flashrom, besides the already known read/write. > > > fully functional OpenBSD > > Nice! > Now, when using the full 256kB capacity, some quirks surface in practice. I have extracted the VGA-BIOS from the original Award-BIOS, and I have incorporated it with Coreboot. The graphics chip is ATI 3D Rage Pro AGP, with pci-id 1002:4742. Thus I do arrive at a serial console, as well as the usual text console. This is a good thing, if not for other reasons that I managed to amalgamate CBFS/VGA-BIOS/SeaBIOS! When booting Debian GNU/Linux via Coreboot/SeaBIOS, the kernel complains [0.204012] weird, boot CPU(#0) not listed by BIOS. Harmless, but annoying. Is CBFS saving somespace? The booting from SeaBIOS is troublesome. Switching floppy and CD-ROM booting off, did not help. I had to switch PNP, DMA and 32bit-PIO off too, before I got bootable systems. It is annoying that the OS commences only after "WARNING - Timeout at await_ide:39!". This message originates in SeaBIOS, but would CBFS or SeaBIOS be the one to blame the most for this lost time? The uhci_hcd circuitry is detected, but it is not assigned an IRQ, so Linux as well as OpenBSD considers it to be broken. SeaBIOS reports an io-port 0x20c0, though. Neither Linux, nor OpenBSD, are able to accomplish a complete power down, as power supply is still applied after shutdown. Moving the single DIMM to another socket, makes the nortbridge initialisation fail immediately after printing "Northbridge following SDRAM init". I thought I had solved that issue two years ago. Did I not, or have other mechanisms been implemented since then? This must be investigated again. In fact, booting is successful with only DIMM2 being populated, not when DIMM1 is used in its stead. Best regards for now, Mats E A From svn at coreboot.org Wed Sep 8 12:58:04 2010 From: svn at coreboot.org (repository service) Date: Wed, 08 Sep 2010 12:58:04 +0200 Subject: [coreboot] [commit] r5787 - in trunk/src: cpu/x86 cpu/x86/tsc southbridge/amd/cs5536 Message-ID: Author: oxygene Date: Wed Sep 8 12:58:02 2010 New Revision: 5787 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5787 Log: Make timer2 the default choice for TSC initialization. For boards where timer2 is unusable, there's still the IO based initialization available using the Kconfig option TSC_CALIBRATE_WITH_IO Signed-off-by: Patrick Georgi Acked-by: Kevin O'Connor Modified: trunk/src/cpu/x86/Kconfig trunk/src/cpu/x86/tsc/delay_tsc.c trunk/src/southbridge/amd/cs5536/Kconfig Modified: trunk/src/cpu/x86/Kconfig ============================================================================== --- trunk/src/cpu/x86/Kconfig Wed Sep 8 12:53:44 2010 (r5786) +++ trunk/src/cpu/x86/Kconfig Wed Sep 8 12:58:02 2010 (r5787) @@ -19,7 +19,7 @@ bool default n -config TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 +config TSC_CALIBRATE_WITH_IO bool default n Modified: trunk/src/cpu/x86/tsc/delay_tsc.c ============================================================================== --- trunk/src/cpu/x86/tsc/delay_tsc.c Wed Sep 8 12:53:44 2010 (r5786) +++ trunk/src/cpu/x86/tsc/delay_tsc.c Wed Sep 8 12:58:02 2010 (r5787) @@ -7,7 +7,7 @@ static unsigned long clocks_per_usec; -#if (CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 == 1) +#if !CONFIG_TSC_CALIBRATE_WITH_IO #define CLOCK_TICK_RATE 1193180U /* Underlying HZ */ /* ------ Calibrate the TSC ------- @@ -82,7 +82,7 @@ return 0; } -#else /* CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 */ +#else /* CONFIG_TSC_CALIBRATE_WITH_IO */ /* * this is the "no timer2" version. Modified: trunk/src/southbridge/amd/cs5536/Kconfig ============================================================================== --- trunk/src/southbridge/amd/cs5536/Kconfig Wed Sep 8 12:53:44 2010 (r5786) +++ trunk/src/southbridge/amd/cs5536/Kconfig Wed Sep 8 12:58:02 2010 (r5787) @@ -19,12 +19,5 @@ config SOUTHBRIDGE_AMD_CS5536 bool - select TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 - -config UDELAY_TSC - bool - default y - depends on SOUTHBRIDGE_AMD_CS5536 - - + select UDELAY_TSC From patrick at georgi-clan.de Wed Sep 8 12:58:47 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 08 Sep 2010 12:58:47 +0200 Subject: [coreboot] [PATCH 2/4] Enable TSC calibration with timer2 by default. In-Reply-To: <20100908002330.GA2963@morn.localdomain> References: <653639f7559fcf14685c35907fd9e733c2e89901.1283815188.git.kevin@koconnor.net> <4C85E4B8.9000203@georgi-clan.de> <20100908002330.GA2963@morn.localdomain> Message-ID: <4C876C67.50209@georgi-clan.de> Am 08.09.2010 02:23, schrieb Kevin O'Connor: > As an aside, I'm not sure of the value of TSC based delays if > inb(0x80) is used to time it. If the code assumes inb(0x80) is 1 > usecond, I'd think it could as easily use UDELAY_IO instead. I guess > we'll need to see if any boards need the new TSC_CALIBRATE_WITH_IO > setting. As I understand it, TSC from IO is still more reliable than UDELAY_IO as it uses a _large_ sampling of IO accesses to average out timing. But I'm not sure how much difference that really makes. Patrick From svn at coreboot.org Wed Sep 8 13:00:26 2010 From: svn at coreboot.org (repository service) Date: Wed, 08 Sep 2010 13:00:26 +0200 Subject: [coreboot] [commit] r5788 - trunk/src/southbridge/via/vt8237r Message-ID: Author: oxygene Date: Wed Sep 8 13:00:25 2010 New Revision: 5788 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5788 Log: Code must not access the smbus registers before the RTC power well is ready (PSON gating). Some boards boot faster than this power well stabilization, and thus see bad data when accessing the smbus registers. Signed-off-by: Kevin O'Connor Acked-by: Peter Stuge Modified: trunk/src/southbridge/via/vt8237r/vt8237r.h trunk/src/southbridge/via/vt8237r/vt8237r_early_smbus.c Modified: trunk/src/southbridge/via/vt8237r/vt8237r.h ============================================================================== --- trunk/src/southbridge/via/vt8237r/vt8237r.h Wed Sep 8 12:58:02 2010 (r5787) +++ trunk/src/southbridge/via/vt8237r/vt8237r.h Wed Sep 8 13:00:25 2010 (r5788) @@ -47,6 +47,7 @@ #define IDE_UDMA 0x50 /* SMBus */ +#define VT8237R_PSON 0x82 #define VT8237R_POWER_WELL 0x94 #define VT8237R_SMBUS_IO_BASE_REG 0xd0 #define VT8237R_SMBUS_HOST_CONF 0xd2 Modified: trunk/src/southbridge/via/vt8237r/vt8237r_early_smbus.c ============================================================================== --- trunk/src/southbridge/via/vt8237r/vt8237r_early_smbus.c Wed Sep 8 12:58:02 2010 (r5787) +++ trunk/src/southbridge/via/vt8237r/vt8237r_early_smbus.c Wed Sep 8 13:00:25 2010 (r5788) @@ -132,12 +132,15 @@ return val; } +#define PSONREADY_TIMEOUT 0x7fffffff + /** * Enable the SMBus on VT8237R-based systems. */ void enable_smbus(void) { device_t dev; + int loops; /* Power management controller */ dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA, @@ -150,6 +153,12 @@ die("Power management controller not found\n"); } + /* Make sure the RTC power well is up before touching smbus. */ + loops = 0; + while (!(pci_read_config8(dev, VT8237R_PSON) & (1<<6)) + && loops < PSONREADY_TIMEOUT) + ++loops; + /* * 7 = SMBus Clock from RTC 32.768KHz * 5 = Internal PLL reset from susp From patrick at georgi-clan.de Wed Sep 8 13:08:11 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 08 Sep 2010 13:08:11 +0200 Subject: [coreboot] MS-6147, SeaBIOS, and OpenBSD. In-Reply-To: <20100908105535.GA25437@mea.homelinux.org> References: <20100827092106.GA28159@mea.homelinux.org> <20100903235211.6105.qmail@stuge.se> <20100908105535.GA25437@mea.homelinux.org> Message-ID: <4C876E9B.5050307@georgi-clan.de> Am 08.09.2010 12:55, schrieb Mats Erik Andersson: > with pci-id 1002:4742. Thus I do arrive at a serial console, as well as > the usual text console. This is a good thing, if not for other reasons > that I managed to amalgamate CBFS/VGA-BIOS/SeaBIOS! I guess you meant "coreboot"? CBFS is just the filesystem. > When booting Debian GNU/Linux via Coreboot/SeaBIOS, the kernel complains > > [0.204012] weird, boot CPU(#0) not listed by BIOS. Some of the tables (mptable and the like) are probably incomplete or missing. The completeness of tables and ACPI varies a lot between boards. We work on unifying the code, to improve matters for existing boards and simplify support for new ones, but it's far from completed. > "WARNING - Timeout at await_ide:39!". Might be incomplete IDE init. coreboot usually (depends on chipset) does no init at all. Some chipset docs actually require some (eg. figure out if 80-pin cables are used, and set a bit if so) > The uhci_hcd circuitry is detected, but it is not assigned an IRQ, > so Linux as well as OpenBSD considers it to be broken. SeaBIOS > reports an io-port 0x20c0, though. IO Ports are assigned properly in generic code, but assigning IRQ is mainboard/chipset specific code. > Neither Linux, nor OpenBSD, are able to accomplish a complete power down, > as power supply is still applied after shutdown. The board has no ACPI support at all (and we don't do APM either). That might be the reason why this isn't working. > Moving the single DIMM to another socket, makes the nortbridge > initialisation fail immediately after printing > > "Northbridge following SDRAM init". Again, chipset specific code. Regards, Patrick From mats.andersson at gisladisker.se Wed Sep 8 13:40:59 2010 From: mats.andersson at gisladisker.se (Mats Erik Andersson) Date: Wed, 8 Sep 2010 13:40:59 +0200 Subject: [coreboot] MS-6147, SeaBIOS, and OpenBSD. In-Reply-To: <4C876E9B.5050307@georgi-clan.de> References: <20100827092106.GA28159@mea.homelinux.org> <20100903235211.6105.qmail@stuge.se> <20100908105535.GA25437@mea.homelinux.org> <4C876E9B.5050307@georgi-clan.de> Message-ID: <20100908114059.GA26414@mea.homelinux.org> onsdag den 8 september 2010 klockan 13:08 skrev Patrick Georgi detta: > Am 08.09.2010 12:55, schrieb Mats Erik Andersson: > > with pci-id 1002:4742. Thus I do arrive at a serial console, as well as > > the usual text console. This is a good thing, if not for other reasons > > that I managed to amalgamate CBFS/VGA-BIOS/SeaBIOS! > I guess you meant "coreboot"? CBFS is just the filesystem. > Yes! > > > Neither Linux, nor OpenBSD, are able to accomplish a complete power down, > > as power supply is still applied after shutdown. > The board has no ACPI support at all (and we don't do APM either). That > might be the reason why this isn't working. > Does this fit with the fact that with the original Award-BIOS, Linux as well as OpenBSD are able to cut the power supply? > > Regards, > Patrick > Thank you for your previous explanations. Regards, Mats E A From patrick at georgi-clan.de Wed Sep 8 14:42:40 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 08 Sep 2010 14:42:40 +0200 Subject: [coreboot] MS-6147, SeaBIOS, and OpenBSD. In-Reply-To: <20100908114059.GA26414@mea.homelinux.org> References: <20100827092106.GA28159@mea.homelinux.org> <20100903235211.6105.qmail@stuge.se> <20100908105535.GA25437@mea.homelinux.org> <4C876E9B.5050307@georgi-clan.de> <20100908114059.GA26414@mea.homelinux.org> Message-ID: <4C8784C0.50503@georgi-clan.de> Am 08.09.2010 13:40, schrieb Mats Erik Andersson: > Does this fit with the fact that with the original Award-BIOS, > Linux as well as OpenBSD are able to cut the power supply? Sorry, "board" == "board support code in coreboot" Patrick From arne.gleditsch at numascale.com Wed Sep 8 15:53:27 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Wed, 08 Sep 2010 15:53:27 +0200 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87wrrpipw6.fsf@taniquetil.gledits.ch> (Arne Georg Gleditsch's message of "Tue, 17 Aug 2010 10:50:49 +0200") References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> Message-ID: <87lj7ctk88.fsf@taniquetil.gledits.ch> Arne Georg Gleditsch writes: > I intend to rework the MMCONF patch to map the MMCONF area into 32-bit > address space, [..] Please find appended. This patch gets rid of the %gs magic altogether, fixes a few alignment wrinkles and sets up and registers the MMCONF area for AMD Fam10h CPUs (where selected by mainboard configuration). It removes a bit of code that proved troublesome in MMCONF setups from mcp55_early_setup_car.c, as per earlier discussion. (The way the patch hooks add_northbridge_resources via s2912_fam10/mainboard.c replicates a well-used pattern that perhaps ought to be simplified. HAVE_NORTHBRIDGE_RESOURCES would remove otherwise empty add_mainboard_resources from a lot of mainboard.c files.) Signed-off-by: Arne Georg Gleditsch -- Arne. -------------- next part -------------- A non-text attachment was scrubbed... Name: mmconf-patch.diff Type: text/x-diff Size: 13860 bytes Desc: not available URL: From mylesgw at gmail.com Wed Sep 8 16:40:38 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 8 Sep 2010 08:40:38 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87lj7ctk88.fsf@taniquetil.gledits.ch> References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> Message-ID: On Wed, Sep 8, 2010 at 7:53 AM, Arne Georg Gleditsch wrote: > Arne Georg Gleditsch writes: >> I intend to rework the MMCONF patch to map the MMCONF area into 32-bit >> address space, [..] > > Please find appended. ?This patch gets rid of the %gs magic altogether, > fixes a few alignment wrinkles and sets up and registers the MMCONF area > for AMD Fam10h CPUs (where selected by mainboard configuration). ?It > removes a bit of code that proved troublesome in MMCONF setups from > mcp55_early_setup_car.c, as per earlier discussion. > > (The way the patch hooks add_northbridge_resources via > s2912_fam10/mainboard.c replicates a well-used pattern that perhaps > ought to be simplified. ?HAVE_NORTHBRIDGE_RESOURCES would remove > otherwise empty add_mainboard_resources from a lot of mainboard.c > files.) I'm confused why you wouldn't add the resource from the northbridge code. Is there a reason to have it be a mainboard resource? +config MMCONF_SUPPORT + bool + default y + depends on NORTHBRIDGE_AMD_AMDFAM10 You could use select for MMCONF_SUPPORT. I think it should be selected in the northbridge or in the mainboard, but not both. Instead of adding the reserved area directly to the coreboot tables, you should add it before resource allocation and let the rest happen automatically. Thanks, Myles From arne.gleditsch at numascale.com Wed Sep 8 17:00:18 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Wed, 08 Sep 2010 17:00:18 +0200 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: (Myles Watson's message of "Wed, 8 Sep 2010 08:40:38 -0600") References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> Message-ID: <87k4mwxou5.fsf@taniquetil.gledits.ch> Myles Watson writes: > I'm confused why you wouldn't add the resource from the northbridge > code. Is there a reason to have it be a mainboard resource? Not really, but there's no existing infrastructure for having add_northbridge_resources be called except by way of add_mainboard_resources. As far as I can tell. I think this may warrant changing, but preferrably as a separate step. > +config MMCONF_SUPPORT > + bool > + default y > + depends on NORTHBRIDGE_AMD_AMDFAM10 > > You could use select for MMCONF_SUPPORT. I think it should be > selected in the northbridge or in the mainboard, but not both. MMCONF_SUPPORT is selected in the northbridge, MMCONF_SUPPORT_DEFAULT is selected in the mainboard config to actually activate the functionality. This was the way I read the existing code, perhaps this two-level approach is not be required? Either way, I think you want to select this on a mainboard-by-mainboard basis, at least initially. There is a potential for breakage, like the one we experienced with the nvidia southbridge. > Instead of adding the reserved area directly to the coreboot tables, > you should add it before resource allocation and let the rest happen > automatically. I'm sorry, I'm not at all familiar with the resource allocation framework. I tried to model this on the corresponding code for relevant Intel mainboards. How would you change it, precisely? -- Arne. From mylesgw at gmail.com Wed Sep 8 18:04:16 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 8 Sep 2010 10:04:16 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87k4mwxou5.fsf@taniquetil.gledits.ch> References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> Message-ID: On Wed, Sep 8, 2010 at 9:00 AM, Arne Georg Gleditsch wrote: > Myles Watson writes: >> I'm confused why you wouldn't add the resource from the northbridge >> code. ?Is there a reason to have it be a mainboard resource? > > Not really, but there's no existing infrastructure for having > add_northbridge_resources be called except by way of > add_mainboard_resources. ?As far as I can tell. ?I think this may > warrant changing, but preferrably as a separate step. > >> +config MMCONF_SUPPORT >> + ? ? bool >> + ? ? default y >> + ? ? depends on NORTHBRIDGE_AMD_AMDFAM10 >> >> You could use select for MMCONF_SUPPORT. ?I think it should be >> selected in the northbridge or in the mainboard, but not both. > > MMCONF_SUPPORT is selected in the northbridge, MMCONF_SUPPORT_DEFAULT is > selected in the mainboard config to actually activate the functionality. > This was the way I read the existing code, perhaps this two-level > approach is not be required? ?Either way, I think you want to select > this on a mainboard-by-mainboard basis, at least initially. ?There is a > potential for breakage, like the one we experienced with the nvidia > southbridge. OK. >> Instead of adding the reserved area directly to the coreboot tables, >> you should add it before resource allocation and let the rest happen >> automatically. > > I'm sorry, I'm not at all familiar with the resource allocation > framework. ?I tried to model this on the corresponding code for relevant > Intel mainboards. ?How would you change it, precisely? Fair question. It's been a long time since I've thought about MMCONF, but here are a couple of ways that I think it could be done: I. Use a hard-coded address for MMCONF only for pre-RAM 1. Add a resource to read_resources in the northbridge that gives the size but isn't fixed 2. The resource allocator will find a good place for it 3. In set resource update the address so that future accesses work II. Use a hard-coded fixed address always 1. Add a fixed resource to read_resources in the northbridge 2. The resource allocator will avoid it Either way, if the area needs to end up reserved in the coreboot tables, then the code should live there. If we need a new resource flag that says create an entry for this, then I think that would be the way to go. I nominate IORESOURCE_RESERVE. I started a patch that applied over yours, but I think discussing the way to go in higher-level terms is the right first step. Much of your patch is unrelated to this discussion. If we split the bug fixes into a separate patch and get that committed I'd be happy to help make this work. Thanks, Myles From mylesgw at gmail.com Wed Sep 8 18:46:15 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 8 Sep 2010 10:46:15 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> Message-ID: Here's a first stab at what I mean. It compiles, but I don't have the board to test. Signed-off-by: Myles Watson Patrick and Stefan, Could you comment. I'd like it even better if the resources were added earlier, but I didn't want to change too much at once. Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: kontron_res.diff Type: text/x-diff Size: 4872 bytes Desc: not available URL: From mylesgw at gmail.com Wed Sep 8 18:48:53 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 8 Sep 2010 10:48:53 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87k4mwxou5.fsf@taniquetil.gledits.ch> References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> Message-ID: >> Instead of adding the reserved area directly to the coreboot tables, >> you should add it before resource allocation and let the rest happen >> automatically. > > I'm sorry, I'm not at all familiar with the resource allocation > framework. ?I tried to model this on the corresponding code for relevant > Intel mainboards. ?How would you change it, precisely? I'd forgotten that this was the way it was done. I agree that you did it the same way that it had been done before. It's often hard to review a patch without reviewing the mechanisms it uses. Thanks, Myles From marcj303 at gmail.com Wed Sep 8 20:29:28 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 8 Sep 2010 12:29:28 -0600 Subject: [coreboot] timeout during PS/2 keyboard init In-Reply-To: References: Message-ID: On Tue, Aug 31, 2010 at 11:16 PM, Scott wrote: > Hello, > > While testing on AMD simnow I encounter a timeout in keyboard.c line 246: > > /* All is well - enable keyboard interface */ > if (!kbc_input_buffer_empty()) return; > outb(0x60, KBD_COMMAND); > if (!kbc_input_buffer_empty()) return; > outb(0x61, KBD_DATA); ? /* send cmd: enable keyboard and IRQ 1 */ > if (kbc_output_buffer_full()) { > ? ? ? ?printk(BIOS_ERR, "Timeout during final keyboard enable\n"); <======= > ? ? ? ?return; > } > > It seems like line 245 should call kbc_input_buffer_empty() instead of > kbc_output_buffer_full() because the previous I/O does not cause the > keyboard to generate any data. > > On simnow, this causes a boot delay of a minute or so. On real hardware, > It appears it could cause a boot delay of 400 ms. Does anyone testing > with real hardware ever notice the "Timeout during final keyboard enable" > message when logging is enabled? > > Thanks, > Scott > Yes, That should be a input buffer empty check since there isn't an ack to that command. Send a qucik patch and signed-off-by, I will ack it. Marc -- http://se-eng.com From marcj303 at gmail.com Wed Sep 8 20:38:16 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 8 Sep 2010 12:38:16 -0600 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <673D2439DC3046D0903811C4830EA052@m3a78> References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> Message-ID: On Mon, Sep 6, 2010 at 6:40 PM, Scott Duplichan wrote: > Stefan Reinauer writes: >>> Can you see if the patches posted in >>> http://article.gmane.org/gmane.linux.bios/57707 make any difference for >>> you? >>> >> Did we ever figure out what is causing this? > > The last time I really dug into this, it was fairly obvious that it was > caused by instruction fetch thrashing towards the ROM. ?I tried to amend > this with MTRR settings, but I was unable to make that work correctly. > For some reason it seemed like the HT requests were sublty changed when > the MTRR was applied, and didn't hit the legacy southbridge properly. > >> The patch would require 4KB more stack on all supported systems, so if >> we can we should do things differently. > > It doesn't have to be stack, but it is nice to have it memory mananged > in some way. ?The unrv2b patch I posted addressing the same problem was > even more kludgy. > >> Also, it's not really guaranteed that the code works from the new >> location since we don't compile coreboot with -fPIC (and as far as I >> understand the GCC guys, even that would not help), so I am a bit >> hesitant to check this in. > > Agreed, it is a bit icky. ?Not sure what the best way to handle that is, > though. ?On the pro side, I assume breakage here is going to be obvious, > and (supposing these patches actually help Nick) this is an issue people > are running into with some regularity. > > -- > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Arne. > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > > > > One necessary condition for caching MMIO such as the flash chip on > AMD family 10h processors is not well known: > > If the processor has an L3 cache, then bit 15 of msr C001_102A > (ClLinesToNbDis) must be set. This bit needs to eventually be cleared > in order for the OS to use the L3 cache. But BIOS must not clear this > bit until cacheable accesses to the flash chip are no longer needed. > This situation applies only to family 10h processors that have L3 cache. > Often BIOS clears this bit too early and slow execution results.As an > experiment, you could add code to set this bit before the slow function > and see what happens. > > Last night I tried to debug this code on simnow. An HT modeling problem > kept me from getting past HT init. I may try it again today. > > The recommended cacheability setting for MMIO is WP. At the point the > simnow model hangs in HT init, the setting is WB. While this should > be OK for family 10h, it will be important to use WP for families > 14h and 15. ClLinesToNbDis is properly set for MMIO caching at this point > (HT init): > > ------------Effective memory type and destination by address------------ > > ? ? ? ? ? ? NORMAL ? ?NORMAL ? ?NORMAL ? ? SMM ? ? ? SMM ? ? ? SMM > ? ? ? ? ? ? READ ? ? ?WRITE ? ? EXECUTE ? ?READ ? ? ?WRITE ? ? EXECUTE > 00000-C3FFF ?UC MMIO.................... ? ?UC MMIO.................... > C4000-CFFFF ?WB DRAM.................... ? ?WB DRAM.................... > D0000-FFFFF ?UC MMIO.................... ? ?UC MMIO.................... > > 00100000-00FFFFFF ?UC DRAM > 01000000-FFEFFFFF ?UC MMIO > FFF00000-FFF7FFFF ?WB MMIO ? <=== really should be WP > FFF80000-FFFFFFFF ?UC MMIO > > -msr c001102a > 00000040_010080C8 <=== good at this point > > Thanks, > Scott > > > > Simnow testing with Tilapia confirms that the coreboot AMD family 10h > code _does_ have the problem of clearing ClLinesToNbDis too early. To > confirm this problem, someone testing on real AMD family 10h hardware > should remove the msr C001_001a write from STOP_CAR_AND_CPU() and > from mct_ClrClToNB_D(). An AMD F10h system running an optimized legacy > bios can boot to a DOS ptompt in less than one second. There is no > reason coreboot should be any slower. > > Thanks, > Scott Ah, this makes sense now. Is c001_001a a shared msr? Is it ok for the APs to be disabled and just leave it enabled on the BSP until the ramstage is decompressed? I should have a patch ready this afternoon. Marc -- http://se-eng.com From scott at notabs.org Wed Sep 8 21:11:51 2010 From: scott at notabs.org (Scott Duplichan) Date: Wed, 8 Sep 2010 14:11:51 -0500 Subject: [coreboot] [PATCH] timeout during PS/2 keyboard init Message-ID: <5AF9C3BD93314353AD324B9F879933C3@m3a78> Thanks Marc. This patch avoids a timeout during PS/2 keyboard initialization. It can reduce KBC init time by up to 400 ms on real hardware, and by a minute or so on AMD simnow. Signed-off-by: Scott Duplichan Index: src/pc80/keyboard.c =================================================================== --- src/pc80/keyboard.c (revision 5788) +++ src/pc80/keyboard.c (working copy) @@ -242,7 +242,7 @@ outb(0x60, KBD_COMMAND); if (!kbc_input_buffer_empty()) return; outb(0x61, KBD_DATA); /* send cmd: enable keyboard and IRQ 1 */ - if (kbc_output_buffer_full()) { + if (kbc_input_buffer_empty()) { printk(BIOS_ERR, "Timeout during final keyboard enable\n"); return; } From patrick at georgi-clan.de Wed Sep 8 21:44:01 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 08 Sep 2010 21:44:01 +0200 Subject: [coreboot] [PATCH 1/4] Make initializing PS2 keyboard optional. In-Reply-To: <20100908002534.GB2963@morn.localdomain> References: <53241126486840e63685efc05e61ee3b9dac2b9b.1283815188.git.kevin@koconnor.net> <4C85E1FE.2040706@georgi-clan.de> <20100908002534.GB2963@morn.localdomain> Message-ID: <4C87E781.8030700@georgi-clan.de> Am 08.09.2010 02:25, schrieb Kevin O'Connor: > I think libpayload should be updated. I think adding the option to > coreboot is a good intermediate step. It will give folks time to > update their payloads. I'm also not sure if plan9 (or other less > common payloads) will have the proper support. Seems like Marc has found the reason in the other thread ("timeout during PS/2 keyboard init") - should we get that fixed, I'd prefer to keep the full init in coreboot unconditionally, even if it's 10-20ms. Could you try with "[PATCH] timeout during PS/2 keyboard init" (http://patchwork.coreboot.org/patch/1891/), if that gives an acceptable boot time for you? (unless I misunderstand and your gripe isn't with the overly long timeout we suffer on some chipsets, but with the time the init takes at all, however tiny) Thanks, Patrick From scott at notabs.org Wed Sep 8 21:47:02 2010 From: scott at notabs.org (Scott Duplichan) Date: Wed, 8 Sep 2010 14:47:02 -0500 Subject: [coreboot] AMD cache setup is broken In-Reply-To: References: <4C812B6D020000FE0000D531@mail.lkfd.net><87aanv1eax.fsf@taniquetil.gledits.ch><4C84BD83.2030502@coresystems.de><8762yj170a.fsf@taniquetil.gledits.ch><673D2439DC3046D0903811C4830EA052@m3a78> Message-ID: <2AB823A1470D4921A664FB35592308CE@m3a78> ]On Mon, Sep 6, 2010 at 6:40 PM, Scott Duplichan wrote: ]> Stefan Reinauer writes: ]>>> Can you see if the patches posted in ]>>> http://article.gmane.org/gmane.linux.bios/57707 make any difference for ]>>> you? ]>>> ]>> Did we ever figure out what is causing this? ]> ]> The last time I really dug into this, it was fairly obvious that it was ]> caused by instruction fetch thrashing towards the ROM. ?I tried to amend ]> this with MTRR settings, but I was unable to make that work correctly. ]> For some reason it seemed like the HT requests were sublty changed when ]> the MTRR was applied, and didn't hit the legacy southbridge properly. ]> ]>> The patch would require 4KB more stack on all supported systems, so if ]>> we can we should do things differently. ]> ]> It doesn't have to be stack, but it is nice to have it memory mananged ]> in some way. ?The unrv2b patch I posted addressing the same problem was ]> even more kludgy. ]> ]>> Also, it's not really guaranteed that the code works from the new ]>> location since we don't compile coreboot with -fPIC (and as far as I ]>> understand the GCC guys, even that would not help), so I am a bit ]>> hesitant to check this in. ]> ]> Agreed, it is a bit icky. ?Not sure what the best way to handle that is, ]> though. ?On the pro side, I assume breakage here is going to be obvious, ]> and (supposing these patches actually help Nick) this is an issue people ]> are running into with some regularity. ]> ]> -- ]> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Arne. ]> ]> -- ]> coreboot mailing list: coreboot at coreboot.org ]> http://www.coreboot.org/mailman/listinfo/coreboot ]> ]> ]> ]> One necessary condition for caching MMIO such as the flash chip on ]> AMD family 10h processors is not well known: ]> ]> If the processor has an L3 cache, then bit 15 of msr C001_102A ]> (ClLinesToNbDis) must be set. This bit needs to eventually be cleared ]> in order for the OS to use the L3 cache. But BIOS must not clear this ]> bit until cacheable accesses to the flash chip are no longer needed. ]> This situation applies only to family 10h processors that have L3 cache. ]> Often BIOS clears this bit too early and slow execution results.As an ]> experiment, you could add code to set this bit before the slow function ]> and see what happens. ]> ]> Last night I tried to debug this code on simnow. An HT modeling problem ]> kept me from getting past HT init. I may try it again today. ]> ]> The recommended cacheability setting for MMIO is WP. At the point the ]> simnow model hangs in HT init, the setting is WB. While this should ]> be OK for family 10h, it will be important to use WP for families ]> 14h and 15. ClLinesToNbDis is properly set for MMIO caching at this point ]> (HT init): ]> ]> ------------Effective memory type and destination by address------------ ]> ]> ? ? ? ? ? ? NORMAL ? ?NORMAL ? ?NORMAL ? ? SMM ? ? ? SMM ? ? ? SMM ]> ? ? ? ? ? ? READ ? ? ?WRITE ? ? EXECUTE ? ?READ ? ? ?WRITE ? ? EXECUTE ]> 00000-C3FFF ?UC MMIO.................... ? ?UC MMIO.................... ]> C4000-CFFFF ?WB DRAM.................... ? ?WB DRAM.................... ]> D0000-FFFFF ?UC MMIO.................... ? ?UC MMIO.................... ]> ]> 00100000-00FFFFFF ?UC DRAM ]> 01000000-FFEFFFFF ?UC MMIO ]> FFF00000-FFF7FFFF ?WB MMIO ? <=== really should be WP ]> FFF80000-FFFFFFFF ?UC MMIO ]> ]> -msr c001102a ]> 00000040_010080C8 <=== good at this point ]> ]> Thanks, ]> Scott ]> ]> ]> ]> Simnow testing with Tilapia confirms that the coreboot AMD family 10h ]> code _does_ have the problem of clearing ClLinesToNbDis too early. To ]> confirm this problem, someone testing on real AMD family 10h hardware ]> should remove the msr C001_001a write from STOP_CAR_AND_CPU() and ]> from mct_ClrClToNB_D(). An AMD F10h system running an optimized legacy ]> bios can boot to a DOS ptompt in less than one second. There is no ]> reason coreboot should be any slower. ]> ]> Thanks, ]> Scott ] ]Ah, this makes sense now. Is c001_001a a shared msr? Is it ok for the ]APs to be disabled and just leave it enabled on the BSP until the ]ramstage is decompressed? I should have a patch ready this afternoon. I checked on real hardware, and family 10h msr c001_102a is not shared among cores on a die. I suppose it would be OK to do what you say. I imagine that would minimize code changes. The alternative is to remove the two instances where ClLinesToNbDis is cleared early, and then clear it at some later time, before AP MSRs are synced to the BSP values. I see the BKDG was finally updated to address this situation: When BIOS is done executing from WP-IO the following steps are followed: 1. MSRC001_102A[ClLinesToNbDis]=0. ]Marc ] ]-- ]http://se-eng.com From marcj303 at gmail.com Wed Sep 8 22:16:49 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 8 Sep 2010 14:16:49 -0600 Subject: [coreboot] [PATCH] timeout during PS/2 keyboard init In-Reply-To: <5AF9C3BD93314353AD324B9F879933C3@m3a78> References: <5AF9C3BD93314353AD324B9F879933C3@m3a78> Message-ID: On Wed, Sep 8, 2010 at 1:11 PM, Scott Duplichan wrote: > Thanks Marc. This patch avoids a timeout during PS/2 keyboard > initialization. It can reduce KBC init time by up to 400 ms on > real hardware, and by a minute or so on AMD simnow. > > > Signed-off-by: Scott Duplichan > > Index: src/pc80/keyboard.c > =================================================================== > --- src/pc80/keyboard.c (revision 5788) > +++ src/pc80/keyboard.c (working copy) > @@ -242,7 +242,7 @@ > ? ? ? ?outb(0x60, KBD_COMMAND); > ? ? ? ?if (!kbc_input_buffer_empty()) return; > ? ? ? ?outb(0x61, KBD_DATA); ? /* send cmd: enable keyboard and IRQ 1 */ > - ? ? ? if (kbc_output_buffer_full()) { > + ? ? ? if (kbc_input_buffer_empty()) { I think you meant !kbc_input_buffer_empty()? Marc -- http://se-eng.com From svn at coreboot.org Wed Sep 8 23:30:08 2010 From: svn at coreboot.org (repository service) Date: Wed, 08 Sep 2010 23:30:08 +0200 Subject: [coreboot] [commit] r5789 - trunk/src/cpu/amd/model_10xxx Message-ID: Author: mjones Date: Wed Sep 8 23:30:07 2010 New Revision: 5789 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5789 Log: Trivial - remove stray characters from a comment block. Signed-off-by: Marc Jones Acked-by: Marc Jones Modified: trunk/src/cpu/amd/model_10xxx/init_cpus.c Modified: trunk/src/cpu/amd/model_10xxx/init_cpus.c ============================================================================== --- trunk/src/cpu/amd/model_10xxx/init_cpus.c Wed Sep 8 13:00:25 2010 (r5788) +++ trunk/src/cpu/amd/model_10xxx/init_cpus.c Wed Sep 8 23:30:07 2010 (r5789) @@ -877,7 +877,7 @@ /* HT Phy settings either apply to both sublinks or have * separate registers for sublink zero and one, so there * will be two table entries. So, here we only loop - cd t * through the sublink zeros in function zero. + * through the sublink zeros in function zero. */ for (j = 0; j < 4; j++) { if (AMD_CpuFindCapability(node, j, &offset)) { From scott at notabs.org Thu Sep 9 01:01:54 2010 From: scott at notabs.org (Scott Duplichan) Date: Wed, 8 Sep 2010 18:01:54 -0500 Subject: [coreboot] [PATCH] timeout during PS/2 keyboard init In-Reply-To: References: <5AF9C3BD93314353AD324B9F879933C3@m3a78> Message-ID: <0984FC1823304EB6BAB26C319C950DD3@m3a78> ]-----Original Message----- ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Marc Jones ]Sent: Wednesday, September 08, 2010 03:17 PM ]To: Scott Duplichan ]Cc: coreboot at coreboot.org ]Subject: Re: [coreboot] [PATCH] timeout during PS/2 keyboard init ] ]On Wed, Sep 8, 2010 at 1:11 PM, Scott Duplichan wrote: ]> Thanks Marc. This patch avoids a timeout during PS/2 keyboard ]> initialization. It can reduce KBC init time by up to 400 ms on ]> real hardware, and by a minute or so on AMD simnow. ]> ]> ]> Signed-off-by: Scott Duplichan ]> ]> Index: src/pc80/keyboard.c ]> =================================================================== ]> --- src/pc80/keyboard.c (revision 5788) ]> +++ src/pc80/keyboard.c (working copy) ]> @@ -242,7 +242,7 @@ ]> ? ? ? ?outb(0x60, KBD_COMMAND); ]> ? ? ? ?if (!kbc_input_buffer_empty()) return; ]> ? ? ? ?outb(0x61, KBD_DATA); ? /* send cmd: enable keyboard and IRQ 1 */ ]> - ? ? ? if (kbc_output_buffer_full()) { ]> + ? ? ? if (kbc_input_buffer_empty()) { ] ] ]I think you meant !kbc_input_buffer_empty()? Good catch. You are correct. While the previous patch avoids the timeout, it does not correct the reversed check for when to log the error message. The revised patch below includes the logging fix, in addition to the timeout avoidance of the original patch. ]Marc ] ]-- ]http://se-eng.com Signed-off-by: Scott Duplichan Index: src/pc80/keyboard.c =================================================================== --- src/pc80/keyboard.c (revision 5788) +++ src/pc80/keyboard.c (working copy) @@ -242,7 +242,7 @@ outb(0x60, KBD_COMMAND); if (!kbc_input_buffer_empty()) return; outb(0x61, KBD_DATA); /* send cmd: enable keyboard and IRQ 1 */ - if (kbc_output_buffer_full()) { + if (!kbc_input_buffer_empty()) { printk(BIOS_ERR, "Timeout during final keyboard enable\n"); return; } From kevin at koconnor.net Thu Sep 9 02:43:39 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 8 Sep 2010 20:43:39 -0400 Subject: [coreboot] [PATCH 1/4] Make initializing PS2 keyboard optional. In-Reply-To: <4C87E781.8030700@georgi-clan.de> References: <53241126486840e63685efc05e61ee3b9dac2b9b.1283815188.git.kevin@koconnor.net> <4C85E1FE.2040706@georgi-clan.de> <20100908002534.GB2963@morn.localdomain> <4C87E781.8030700@georgi-clan.de> Message-ID: <20100909004339.GA17236@morn.localdomain> On Wed, Sep 08, 2010 at 09:44:01PM +0200, Patrick Georgi wrote: > Am 08.09.2010 02:25, schrieb Kevin O'Connor: > > I think libpayload should be updated. I think adding the option to > > coreboot is a good intermediate step. It will give folks time to > > update their payloads. I'm also not sure if plan9 (or other less > > common payloads) will have the proper support. > Seems like Marc has found the reason in the other thread ("timeout > during PS/2 keyboard init") - should we get that fixed, I'd prefer to > keep the full init in coreboot unconditionally, even if it's 10-20ms. > > Could you try with "[PATCH] timeout during PS/2 keyboard init" > (http://patchwork.coreboot.org/patch/1891/), if that gives an acceptable > boot time for you? (unless I misunderstand and your gripe isn't with the > overly long timeout we suffer on some chipsets, but with the time the > init takes at all, however tiny) That patch is separate from the underlying issue. Talking to the PS2 keyboard is just plain slow. Here is my boot log (epia-cn) with no ps2 keyboard attached (Marc's patch doesn't impact this): 00.556: Primary IDE interface enabled 00.556: Secondary IDE interface enabled 00.704: No PS/2 keyboard detected. 00.705: CBFS: Could not find file pci1106,3344.rom Here is with a ps2 keyboard attached and Marc's fix not applied: 00.558: Primary IDE interface enabled 00.558: Secondary IDE interface enabled 01.367: Keyboard controller output buffer result timeout 01.368: CBFS: Could not find file pci1106,3344.rom Here it is with ps2 keyboard attached and Marc's fix applied: 00.559: Primary IDE interface enabled 00.559: Secondary IDE interface enabled 00.966: CBFS: Could not find file pci1106,3344.rom Here it is with CONFIG_DRIVERS_PS2_KEYBOARD set to 0: 00.562: Primary IDE interface enabled 00.563: Secondary IDE interface enabled 00.563: CBFS: Could not find file pci1106,3344.rom It's easy to get timing numbers on your own boards. Just grab the file tools/readserial.py from the seabios repo, and run: readserial.py /dev/ttyS0 . The tool measures data read from the serial port using the host clock; it takes into account the time it takes the target machine to write to the serial port. I've found the numbers to be very reproducible. -Kevin From arne.gleditsch at numascale.com Thu Sep 9 09:22:17 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Thu, 09 Sep 2010 09:22:17 +0200 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: (Myles Watson's message of "Wed, 8 Sep 2010 10:46:15 -0600") References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> Message-ID: <87hbhztm8m.fsf@taniquetil.gledits.ch> Myles Watson writes: > Here's a first stab at what I mean. It compiles, but I don't have the > board to test. Ok, so building on that, here's an updated version of the first patch. The resource is still fixed, but the gratuitous call through add_mainboard_resource is gone and the coreboot table manipulation is removed from the northbridge code. -- Arne. -------------- next part -------------- A non-text attachment was scrubbed... Name: mmconf-patch-002.diff Type: text/x-diff Size: 14210 bytes Desc: not available URL: From arne.gleditsch at numascale.com Thu Sep 9 09:31:32 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Thu, 09 Sep 2010 09:31:32 +0200 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87hbhztm8m.fsf@taniquetil.gledits.ch> (Arne Georg Gleditsch's message of "Thu, 09 Sep 2010 09:22:17 +0200") References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> Message-ID: <874odztlt7.fsf@taniquetil.gledits.ch> Arne Georg Gleditsch writes: > Ok, so building on that, here's an updated version of the first patch. > The resource is still fixed, but the gratuitous call through > add_mainboard_resource is gone and the coreboot table manipulation is > removed from the northbridge code. For the record, this version is also Signed-off-by: Arne Georg Gleditsch -- Arne. From arne.gleditsch at numascale.com Thu Sep 9 10:01:49 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Thu, 09 Sep 2010 10:01:49 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <2AB823A1470D4921A664FB35592308CE@m3a78> (Scott Duplichan's message of "Wed, 8 Sep 2010 14:47:02 -0500") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> Message-ID: <87wrqvs5ua.fsf@taniquetil.gledits.ch> "Scott Duplichan" writes: > I checked on real hardware, and family 10h msr c001_102a is not shared > among cores on a die. I suppose it would be OK to do what you say. I > imagine that would minimize code changes. As a minimal change, I did the following: diff --git a/src/arch/i386/lib/cbfs_and_run.c b/src/arch/i386/lib/cbfs_and_run.c index 1b86f56..2f90b0c 100644 --- a/src/arch/i386/lib/cbfs_and_run.c +++ b/src/arch/i386/lib/cbfs_and_run.c @@ -34,6 +34,12 @@ void cbfs_and_run_core(const char *filename, unsigned ebp) asm("hlt\n"); } + __asm__ volatile ( + "rdmsr\n" + "btr $15, %%eax\n" + "wrmsr\n" + :: "c"(0xc001102a) : "eax", "edx"); + print_debug("Jumping to image.\n"); __asm__ volatile ( "movl %%eax, %%ebp\n" diff --git a/src/northbridge/amd/amdmct/mct/mct_d.c b/src/northbridge/amd/amdmct/mct/mct_d.c index 3693891..fd07fa5 100644 --- a/src/northbridge/amd/amdmct/mct/mct_d.c +++ b/src/northbridge/amd/amdmct/mct/mct_d.c @@ -3189,7 +3189,7 @@ static void mct_FinalMCT_D(struct MCTStatStruc *pMCTstat, print_t("\tmct_FinalMCT_D: Clr Cl, Wb\n"); - mct_ClrClToNB_D(pMCTstat, pDCTstat); +// mct_ClrClToNB_D(pMCTstat, pDCTstat); mct_ClrWbEnhWsbDis_D(pMCTstat, pDCTstat); } I can confirm that this removes the earlier observed delays for me. Obviously, this is AMD-specific code that needs to be hooked in in a proper manner, but this definately seems to be the culprit. > The alternative is to remove the two instances where ClLinesToNbDis is > cleared early, and then clear it at some later time, before AP MSRs > are synced to the BSP values. I see the BKDG was finally updated to > address this situation: As far as I can see, this bit is cleared in the APs just before they are stopped in the rom stage. Aas they'r not in play again until well into the ram stage, I'm assuming this is ok. Pushing the ClrClToNB operation in mct_d to after the BSP is done executing from rom should be sufficient, and this seems to be confirmed by testing. -- Arne. From svn at coreboot.org Thu Sep 9 10:34:03 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 10:34:03 +0200 Subject: [coreboot] [commit] r5790 - in trunk/src: . pc80 Message-ID: Author: oxygene Date: Thu Sep 9 10:34:02 2010 New Revision: 5790 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5790 Log: Add a DRIVERS_PS2_KEYBOARD option which controls the PS2 keyboard initialization. Not all payloads require it and some keyboards take a long time to init. Signed-off-by: Kevin O'Connor Acked-by: Patrick Georgi Modified: trunk/src/Kconfig.deprecated_options trunk/src/pc80/keyboard.c Modified: trunk/src/Kconfig.deprecated_options ============================================================================== --- trunk/src/Kconfig.deprecated_options Wed Sep 8 23:30:07 2010 (r5789) +++ trunk/src/Kconfig.deprecated_options Thu Sep 9 10:34:02 2010 (r5790) @@ -31,3 +31,18 @@ help This variable specifies whether a given board has a get_bus_conf.c file containing information about bus routing. + +# Will be removed (alongside with the PS2 init code) once payloads +# reliably support PS2 init themselves. +config DRIVERS_PS2_KEYBOARD + bool "PS2 Keyboard init" + default y + help + Enable this option to initialize PS2 keyboards found connected + to the PS2 port. Some payloads (eg, filo) require this + option. Other payloads (eg, SeaBIOS, Linux) do not require + it. Initializing a PS2 keyboard can take several hundred + milliseconds. + If you know you will only use a payload which does not require + this option, then you can say "n" here to speed up boot time. + Otherwise say "y". Modified: trunk/src/pc80/keyboard.c ============================================================================== --- trunk/src/pc80/keyboard.c Wed Sep 8 23:30:07 2010 (r5789) +++ trunk/src/pc80/keyboard.c Thu Sep 9 10:34:02 2010 (r5790) @@ -162,6 +162,8 @@ void pc_keyboard_init(struct pc_keyboard *keyboard) { u8 regval; + if (!CONFIG_DRIVERS_PS2_KEYBOARD) + return; printk(BIOS_DEBUG, "Keyboard init...\n"); /* Run a keyboard controller self-test */ From patrick at georgi-clan.de Thu Sep 9 10:34:34 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 09 Sep 2010 10:34:34 +0200 Subject: [coreboot] [PATCH 1/4] Make initializing PS2 keyboard optional. In-Reply-To: <20100909004339.GA17236@morn.localdomain> References: <53241126486840e63685efc05e61ee3b9dac2b9b.1283815188.git.kevin@koconnor.net> <4C85E1FE.2040706@georgi-clan.de> <20100908002534.GB2963@morn.localdomain> <4C87E781.8030700@georgi-clan.de> <20100909004339.GA17236@morn.localdomain> Message-ID: <4C889C1A.6030908@georgi-clan.de> Am 09.09.2010 02:43, schrieb Kevin O'Connor: > That patch is separate from the underlying issue. Talking to the PS2 > keyboard is just plain slow. Here is my boot log (epia-cn) with no > ps2 keyboard attached (Marc's patch doesn't impact this): I added this patch, but moved your new config option to src/Kconfig.deprecated_options with some comment on when it's going to be gone (once payloads do ps/2 init themselves, and the code can be removed completely) Acked-by: Patrick Georgi and committed in r5790- Thanks, Patrick From patrick at georgi-clan.de Thu Sep 9 10:35:49 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 09 Sep 2010 10:35:49 +0200 Subject: [coreboot] [PATCH] basic realmode handlers for int 0x10 and int 0x16 In-Reply-To: References: Message-ID: <4C889C65.5010001@georgi-clan.de> Am 08.09.2010 01:38, schrieb Myles Watson: > My Jmicron SATA card writes the name of the hard drive to the screen. > This redirects that output to the console and implements a basic > keyboard stub. > > Signed-off-by: Myles Watson Acked-by: Patrick Georgi > It makes the image a little bit larger (512 bytes after compression), > so I'm wondering if I should wrap it in a Kconfig option. It doesn't > seem worth the mess in the code for such a little bit of space. Looks good, and 512b compressed isn't worth the trouble imho. Patrick From arne.gleditsch at numascale.com Thu Sep 9 11:16:51 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Thu, 09 Sep 2010 11:16:51 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <87wrqvs5ua.fsf@taniquetil.gledits.ch> (Arne Georg Gleditsch's message of "Thu, 09 Sep 2010 10:01:49 +0200") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> Message-ID: <87sk1js2d8.fsf@taniquetil.gledits.ch> Arne Georg Gleditsch writes: > I can confirm that this removes the earlier observed delays for me. > Obviously, this is AMD-specific code that needs to be hooked in in a > proper manner, but this definately seems to be the culprit. Apparently, it's not crucial to clear this at the exact moment we switch to using ram, so something like the appended is perhaps more appropriate. Confirmed to work on hw. Signed-off-by: Arne Georg Gleditsch -- Arne. -------------- next part -------------- A non-text attachment was scrubbed... Name: romcache-002.diff Type: text/x-diff Size: 1049 bytes Desc: not available URL: From svn at coreboot.org Thu Sep 9 11:56:19 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 11:56:19 +0200 Subject: [coreboot] [commit] r5791 - in trunk/src: cpu/amd/model_10xxx northbridge/amd/amdmct/mct Message-ID: Author: oxygene Date: Thu Sep 9 11:56:19 2010 New Revision: 5791 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5791 Log: Apparently, it's not crucial to clear this at the exact moment we switch to using ram, so something like the appended is perhaps more appropriate. Confirmed to work on hw. Signed-off-by: Arne Georg Gleditsch Acked-by: Patrick Georgi Modified: trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c trunk/src/northbridge/amd/amdmct/mct/mct_d.c Modified: trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c ============================================================================== --- trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c Thu Sep 9 10:34:02 2010 (r5790) +++ trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c Thu Sep 9 11:56:19 2010 (r5791) @@ -113,6 +113,11 @@ msr.hi &= ~(1 << (46 - 32)); wrmsr(NB_CFG_MSR, msr); + /* Clear ClLinesToNbDis */ + msr = rdmsr(BU_CFG2_MSR); + msr.lo &= ~(1 << 15); + wrmsr(BU_CFG2_MSR, msr); + /* Write protect SMM space with SMMLOCK. */ msr = rdmsr(HWCR_MSR); msr.lo |= (1 << 0); Modified: trunk/src/northbridge/amd/amdmct/mct/mct_d.c ============================================================================== --- trunk/src/northbridge/amd/amdmct/mct/mct_d.c Thu Sep 9 10:34:02 2010 (r5790) +++ trunk/src/northbridge/amd/amdmct/mct/mct_d.c Thu Sep 9 11:56:19 2010 (r5791) @@ -3189,7 +3189,7 @@ print_t("\tmct_FinalMCT_D: Clr Cl, Wb\n"); - mct_ClrClToNB_D(pMCTstat, pDCTstat); + /* ClrClToNB_D postponed til we're done executing from ROM */ mct_ClrWbEnhWsbDis_D(pMCTstat, pDCTstat); } From patrick at georgi-clan.de Thu Sep 9 11:56:39 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 09 Sep 2010 11:56:39 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <87sk1js2d8.fsf@taniquetil.gledits.ch> References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> Message-ID: <4C88AF57.7010002@georgi-clan.de> Am 09.09.2010 11:16, schrieb Arne Georg Gleditsch: > Apparently, it's not crucial to clear this at the exact moment we switch > to using ram, so something like the appended is perhaps more > appropriate. Confirmed to work on hw. > > Signed-off-by: Arne Georg Gleditsch Acked-by: Patrick Georgi and in as r5791 Thanks, Patrick From arne.gleditsch at numascale.com Thu Sep 9 11:58:08 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Thu, 09 Sep 2010 11:58:08 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <87sk1js2d8.fsf@taniquetil.gledits.ch> (Arne Georg Gleditsch's message of "Thu, 09 Sep 2010 11:16:51 +0200") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> Message-ID: <87occ7s0gf.fsf@taniquetil.gledits.ch> Arne Georg Gleditsch writes: > + /* Clear ClLinesToNbDis */ > + msr = rdmsr(BU_CFG2_MSR); > + msr.lo &= ~(1 << 15); > + wrmsr(BU_CFG2_MSR, msr); On an slightly unrelated note; do we want to clear bit 35 here as well? At the moment, this is only done for the BSP, causing the MSR settings to be inconsistent after boot. I see that errata 343 indicates that this should be cleared after CAR is disabled, so it might not matter all that much for the APs... -- Arne. From arne.gleditsch at numascale.com Thu Sep 9 12:06:30 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Thu, 09 Sep 2010 12:06:30 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <4C88AF57.7010002@georgi-clan.de> (Patrick Georgi's message of "Thu, 09 Sep 2010 11:56:39 +0200") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <4C88AF57.7010002@georgi-clan.de> Message-ID: <87k4mvs02h.fsf@taniquetil.gledits.ch> Patrick Georgi writes: > Acked-by: Patrick Georgi > > and in as r5791 Thanks Patrick, I guess we want to do this in the DDR3 path as, well. Patch appended to do so, as well as fix a minor typo in the last one. Signed-off-by: Arne Georg Gleditsch -- Arne. -------------- next part -------------- A non-text attachment was scrubbed... Name: romcache-003.diff Type: text/x-diff Size: 1092 bytes Desc: not available URL: From svn at coreboot.org Thu Sep 9 12:35:53 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 12:35:53 +0200 Subject: [coreboot] [commit] r5792 - in trunk/src/northbridge/amd/amdmct: mct mct_ddr3 Message-ID: Author: oxygene Date: Thu Sep 9 12:35:52 2010 New Revision: 5792 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5792 Log: Also improve boot time on AMD for the DDR3 code path. Fix a typo, too. Signed-off-by: Arne Georg Gleditsch Acked-by: Patrick Georgi Modified: trunk/src/northbridge/amd/amdmct/mct/mct_d.c trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Modified: trunk/src/northbridge/amd/amdmct/mct/mct_d.c ============================================================================== --- trunk/src/northbridge/amd/amdmct/mct/mct_d.c Thu Sep 9 11:56:19 2010 (r5791) +++ trunk/src/northbridge/amd/amdmct/mct/mct_d.c Thu Sep 9 12:35:52 2010 (r5792) @@ -3189,7 +3189,7 @@ print_t("\tmct_FinalMCT_D: Clr Cl, Wb\n"); - /* ClrClToNB_D postponed til we're done executing from ROM */ + /* ClrClToNB_D postponed until we're done executing from ROM */ mct_ClrWbEnhWsbDis_D(pMCTstat, pDCTstat); } Modified: trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c ============================================================================== --- trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Thu Sep 9 11:56:19 2010 (r5791) +++ trunk/src/northbridge/amd/amdmct/mct_ddr3/mct_d.c Thu Sep 9 12:35:52 2010 (r5792) @@ -2873,7 +2873,7 @@ static void mct_FinalMCT_D(struct MCTStatStruc *pMCTstat, struct DCTStatStruc *pDCTstat) { - mct_ClrClToNB_D(pMCTstat, pDCTstat); + /* ClrClToNB_D postponed until we're done executing from ROM */ mct_ClrWbEnhWsbDis_D(pMCTstat, pDCTstat); } From patrick at georgi-clan.de Thu Sep 9 12:35:58 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 09 Sep 2010 12:35:58 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <87k4mvs02h.fsf@taniquetil.gledits.ch> References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <4C88AF57.7010002@georgi-clan.de> <87k4mvs02h.fsf@taniquetil.gledits.ch> Message-ID: <4C88B88E.1070801@georgi-clan.de> Am 09.09.2010 12:06, schrieb Arne Georg Gleditsch: > I guess we want to do this in the DDR3 path as, well. Patch appended to > do so, as well as fix a minor typo in the last one. > > Signed-off-by: Arne Georg Gleditsch Acked-by: Patrick Georgi r5792 Thanks, Patrick From svn at coreboot.org Thu Sep 9 16:42:59 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 16:42:59 +0200 Subject: [coreboot] [commit] r5793 - trunk/src/devices/oprom Message-ID: Author: myles Date: Thu Sep 9 16:42:58 2010 New Revision: 5793 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5793 Log: My Jmicron SATA card writes the name of the hard drive to the screen. This redirects that output to the console and implements a basic keyboard stub. Signed-off-by: Myles Watson Acked-by: Patrick Georgi Modified: trunk/src/devices/oprom/x86.c Modified: trunk/src/devices/oprom/x86.c ============================================================================== --- trunk/src/devices/oprom/x86.c Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/devices/oprom/x86.c Thu Sep 9 16:42:58 2010 (r5793) @@ -92,8 +92,8 @@ static int intXX_unknown_handler(struct eregs *regs) { - printk(BIOS_INFO, "Unsupported software interrupt #0x%x\n", - regs->vector); + printk(BIOS_INFO, "Unsupported software interrupt #0x%x eax 0x%x\n", + regs->vector, regs->eax); return -1; } @@ -104,6 +104,75 @@ intXX_handler[intXX] = intXX_func; } +static int int10_handler(struct eregs *regs) +{ + int res=-1; + static u8 cursor_row=0, cursor_col=0; + switch((regs->eax & 0xff00)>>8) { + case 0x01: // Set cursor shape + res = 0; + break; + case 0x02: // Set cursor position + if (cursor_row != ((regs->edx >> 8) & 0xff) || + cursor_col >= (regs->edx & 0xff)) { + printk(BIOS_INFO, "\n"); + } + cursor_row = (regs->edx >> 8) & 0xff; + cursor_col = regs->edx & 0xff; + res = 0; + break; + case 0x03: // Get cursor position + regs->eax &= 0x00ff; + regs->ecx = 0x0607; + regs->edx = (cursor_row << 8) | cursor_col; + res = 0; + break; + case 0x06: // Scroll up + printk(BIOS_INFO, "\n"); + res = 0; + break; + case 0x08: // Get Character and Mode at Cursor Position + regs->eax = 0x0f00 | 'A'; // White on black 'A' + res = 0; + break; + case 0x09: // Write Character and attribute + case 0x10: // Write Character + printk(BIOS_INFO, "%c", regs->eax & 0xff); + res = 0; + break; + case 0x0f: // Get video mode + regs->eax = 0x5002; //80x25 + regs->ebx &= 0x00ff; + res = 0; + break; + default: + printk(BIOS_WARNING, "Unknown INT10 function %04x!\n", + regs->eax & 0xffff); + break; + } + return res; +} + +static int int16_handler(struct eregs *regs) +{ + int res=-1; + switch((regs->eax & 0xff00)>>8) { + case 0x00: // Check for Keystroke + regs->eax = 0x6120; // Space Bar, Space + res = 0; + break; + case 0x01: // Check for Keystroke + regs->eflags |= 1<<6; // Zero Flag set (no key available) + res = 0; + break; + default: + printk(BIOS_WARNING, "Unknown INT16 function %04x!\n", + regs->eax & 0xffff); + break; + } + return res; +} + int int12_handler(struct eregs *regs); int int15_handler(struct eregs *regs); int int1a_handler(struct eregs *regs); @@ -131,12 +200,18 @@ * interrupt handlers, such as the int15 */ switch (i) { + case 0x10: + intXX_handler[0x10] = &int10_handler; + break; case 0x12: intXX_handler[0x12] = &int12_handler; break; case 0x15: intXX_handler[0x15] = &int15_handler; break; + case 0x16: + intXX_handler[0x16] = &int16_handler; + break; case 0x1a: intXX_handler[0x1a] = &int1a_handler; break; From svn at coreboot.org Thu Sep 9 16:44:52 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 16:44:52 +0200 Subject: [coreboot] [commit] r5794 - trunk/payloads/libpayload/curses Message-ID: Author: oxygene Date: Thu Sep 9 16:44:51 2010 New Revision: 5794 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5794 Log: Only try to beep when speaker support is compiled in. Trivial change. Reported-by: Aurelien Guillaume Signed-off-by: Patrick Georgi Acked-by: Patrick Georgi Modified: trunk/payloads/libpayload/curses/tinycurses.c Modified: trunk/payloads/libpayload/curses/tinycurses.c ============================================================================== --- trunk/payloads/libpayload/curses/tinycurses.c Thu Sep 9 16:42:58 2010 (r5793) +++ trunk/payloads/libpayload/curses/tinycurses.c Thu Sep 9 16:44:51 2010 (r5794) @@ -191,7 +191,9 @@ int beep(void) { /* TODO: Flash the screen if beeping fails? */ +#ifdef CONFIG_SPEAKER speaker_tone(1760, 500); /* 1760 == note A6 */ +#endif return OK; } // bool can_change_color(void) {} From mylesgw at gmail.com Thu Sep 9 16:44:57 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 9 Sep 2010 08:44:57 -0600 Subject: [coreboot] [PATCH] basic realmode handlers for int 0x10 and int 0x16 In-Reply-To: <4C889C65.5010001@georgi-clan.de> References: <4C889C65.5010001@georgi-clan.de> Message-ID: On Thu, Sep 9, 2010 at 2:35 AM, Patrick Georgi wrote: > Am 08.09.2010 01:38, schrieb Myles Watson: >> My Jmicron SATA card writes the name of the hard drive to the screen. >> This redirects that output to the console and implements a basic >> keyboard stub. >> >> Signed-off-by: Myles Watson > Acked-by: Patrick Georgi > >> It makes the image a little bit larger (512 bytes after compression), >> so I'm wondering if I should wrap it in a Kconfig option. ?It doesn't >> seem worth the mess in the code for such a little bit of space. > Looks good, and 512b compressed isn't worth the trouble imho. Great. Rev 5793. Thanks, Myles From svn at coreboot.org Thu Sep 9 16:51:19 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 16:51:19 +0200 Subject: [coreboot] [commit] r5795 - in trunk/src: arch/i386/boot include/device Message-ID: Author: myles Date: Thu Sep 9 16:51:17 2010 New Revision: 5795 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5795 Log: Add support for reserved regions to resources and coreboot tables. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/arch/i386/boot/coreboot_table.c trunk/src/include/device/resource.h Modified: trunk/src/arch/i386/boot/coreboot_table.c ============================================================================== --- trunk/src/arch/i386/boot/coreboot_table.c Thu Sep 9 16:44:51 2010 (r5794) +++ trunk/src/arch/i386/boot/coreboot_table.c Thu Sep 9 16:51:17 2010 (r5795) @@ -488,6 +488,20 @@ return mem; } +static void lb_add_rsvd_range(void *gp, struct device *dev, struct resource *res) +{ + struct lb_memory *mem = gp; + lb_add_memory_range(mem, LB_MEM_RESERVED, res->base, res->size); +} + +static void add_lb_reserved(struct lb_memory *mem) +{ + /* Add reserved ranges */ + search_global_resources( + IORESOURCE_MEM | IORESOURCE_RESERVE, IORESOURCE_MEM | IORESOURCE_RESERVE, + lb_add_rsvd_range, mem); +} + #if CONFIG_WRITE_HIGH_TABLES == 1 extern uint64_t high_tables_base, high_tables_size; #endif @@ -562,6 +576,9 @@ high_tables_base, high_tables_size); #endif + /* Add reserved regions */ + add_lb_reserved(mem); + #if (CONFIG_HAVE_MAINBOARD_RESOURCES == 1) add_mainboard_resources(mem); #endif Modified: trunk/src/include/device/resource.h ============================================================================== --- trunk/src/include/device/resource.h Thu Sep 9 16:44:51 2010 (r5794) +++ trunk/src/include/device/resource.h Thu Sep 9 16:51:17 2010 (r5795) @@ -20,6 +20,7 @@ * to the bus below. */ #define IORESOURCE_BRIDGE 0x00080000 /* The IO resource has a bus below it. */ +#define IORESOURCE_RESERVE 0x10000000 /* The resource needs to be reserved in the Coreboot table */ #define IORESOURCE_STORED 0x20000000 /* The IO resource assignment has been stored in the device */ #define IORESOURCE_ASSIGNED 0x40000000 /* An IO resource that has been assigned a value */ #define IORESOURCE_FIXED 0x80000000 /* An IO resource the allocator must not change */ From svn at coreboot.org Thu Sep 9 16:54:08 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 16:54:08 +0200 Subject: [coreboot] [commit] r5796 - in trunk/src: arch/i386/include/arch arch/i386/lib cpu/amd/model_10xxx mainboard/tyan/s2912_fam10 northbridge/amd/amdfam10 northbridge/amd/amdmct/mct southbridge/nvidia/mcp55 Message-ID: Author: myles Date: Thu Sep 9 16:54:07 2010 New Revision: 5796 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5796 Log: Please find appended. This patch gets rid of the %gs magic altogether, fixes a few alignment wrinkles and sets up and registers the MMCONF area for AMD Fam10h CPUs (where selected by mainboard configuration). It removes a bit of code that proved troublesome in MMCONF setups from mcp55_early_setup_car.c, as per earlier discussion. Signed-off-by: Arne Georg Gleditsch Acked-by: Myles Watson Modified: trunk/src/arch/i386/include/arch/mmio_conf.h trunk/src/arch/i386/include/arch/romcc_io.h trunk/src/arch/i386/lib/pci_ops_mmconf.c trunk/src/cpu/amd/model_10xxx/init_cpus.c trunk/src/mainboard/tyan/s2912_fam10/Kconfig trunk/src/northbridge/amd/amdfam10/Kconfig trunk/src/northbridge/amd/amdfam10/early_ht.c trunk/src/northbridge/amd/amdfam10/northbridge.c trunk/src/northbridge/amd/amdmct/mct/mct_d.c trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c Modified: trunk/src/arch/i386/include/arch/mmio_conf.h ============================================================================== --- trunk/src/arch/i386/include/arch/mmio_conf.h Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/arch/i386/include/arch/mmio_conf.h Thu Sep 9 16:54:07 2010 (r5796) @@ -2,13 +2,13 @@ #define ARCH_MMIO_H 1 -//extended read, GS is already set +// Extended read, constrain to use registers as mandated by AMD MMCONFIG mechanism. static inline __attribute__((always_inline)) uint8_t read8x(uint32_t addr) { uint8_t value; __asm__ volatile ( - "movb %%gs:(%1), %0\n\t" + "movb (%1), %%al\n\t" :"=a"(value): "b" (addr) ); return value; @@ -18,7 +18,7 @@ { uint16_t value; __asm__ volatile ( - "movw %%gs:(%1), %0\n\t" + "movw (%1), %%ax\n\t" :"=a"(value): "b" (addr) ); @@ -30,7 +30,7 @@ { uint32_t value; __asm__ volatile ( - "movl %%gs:(%1), %0\n\t" + "movl (%1), %%eax\n\t" :"=a"(value): "b" (addr) ); @@ -41,7 +41,7 @@ static inline __attribute__((always_inline)) void write8x(uint32_t addr, uint8_t value) { __asm__ volatile ( - "movb %1, %%gs:(%0)\n\t" + "movb %%al, (%0)\n\t" :: "b" (addr), "a" (value) ); @@ -50,7 +50,7 @@ static inline __attribute__((always_inline)) void write16x(uint32_t addr, uint16_t value) { __asm__ volatile ( - "movw %1, %%gs:(%0)\n\t" + "movw %%ax, (%0)\n\t" :: "b" (addr), "a" (value) ); @@ -59,7 +59,7 @@ static inline __attribute__((always_inline)) void write32x(uint32_t addr, uint32_t value) { __asm__ volatile ( - "movl %1, %%gs:(%0)\n\t" + "movl %%eax, (%0)\n\t" :: "b" (addr), "a" (value) ); } Modified: trunk/src/arch/i386/include/arch/romcc_io.h ============================================================================== --- trunk/src/arch/i386/include/arch/romcc_io.h Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/arch/i386/include/arch/romcc_io.h Thu Sep 9 16:54:07 2010 (r5796) @@ -107,7 +107,7 @@ static inline __attribute__((always_inline)) uint16_t pci_mmio_read_config16(device_t dev, unsigned where) { unsigned addr; - addr = CONFIG_MMCONF_BASE_ADDRESS | dev | where; + addr = CONFIG_MMCONF_BASE_ADDRESS | dev | (where & ~1); return read16x(addr); } #endif @@ -138,7 +138,7 @@ static inline __attribute__((always_inline)) uint32_t pci_mmio_read_config32(device_t dev, unsigned where) { unsigned addr; - addr = CONFIG_MMCONF_BASE_ADDRESS | dev | where; + addr = CONFIG_MMCONF_BASE_ADDRESS | dev | (where & ~3); return read32x(addr); } #endif @@ -199,7 +199,7 @@ static inline __attribute__((always_inline)) void pci_mmio_write_config16(device_t dev, unsigned where, uint16_t value) { unsigned addr; - addr = CONFIG_MMCONF_BASE_ADDRESS | dev | where; + addr = CONFIG_MMCONF_BASE_ADDRESS | dev | (where & ~1); write16x(addr, value); } #endif @@ -230,7 +230,7 @@ static inline __attribute__((always_inline)) void pci_mmio_write_config32(device_t dev, unsigned where, uint32_t value) { unsigned addr; - addr = CONFIG_MMCONF_BASE_ADDRESS | dev | where; + addr = CONFIG_MMCONF_BASE_ADDRESS | dev | (where & ~3); write32x(addr, value); } #endif Modified: trunk/src/arch/i386/lib/pci_ops_mmconf.c ============================================================================== --- trunk/src/arch/i386/lib/pci_ops_mmconf.c Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/arch/i386/lib/pci_ops_mmconf.c Thu Sep 9 16:54:07 2010 (r5796) @@ -27,12 +27,12 @@ static uint16_t pci_mmconf_read_config16(struct bus *pbus, int bus, int devfn, int where) { - return (read16x(PCI_MMIO_ADDR(bus, devfn, where))); + return (read16x(PCI_MMIO_ADDR(bus, devfn, where) & ~1)); } static uint32_t pci_mmconf_read_config32(struct bus *pbus, int bus, int devfn, int where) { - return (read32x(PCI_MMIO_ADDR(bus, devfn, where))); + return (read32x(PCI_MMIO_ADDR(bus, devfn, where) & ~3)); } static void pci_mmconf_write_config8(struct bus *pbus, int bus, int devfn, int where, uint8_t value) @@ -42,12 +42,12 @@ static void pci_mmconf_write_config16(struct bus *pbus, int bus, int devfn, int where, uint16_t value) { - write8x(PCI_MMIO_ADDR(bus, devfn, where), value); + write16x(PCI_MMIO_ADDR(bus, devfn, where) & ~1, value); } static void pci_mmconf_write_config32(struct bus *pbus, int bus, int devfn, int where, uint32_t value) { - write8x(PCI_MMIO_ADDR(bus, devfn, where), value); + write32x(PCI_MMIO_ADDR(bus, devfn, where) & ~3, value); } Modified: trunk/src/cpu/amd/model_10xxx/init_cpus.c ============================================================================== --- trunk/src/cpu/amd/model_10xxx/init_cpus.c Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/cpu/amd/model_10xxx/init_cpus.c Thu Sep 9 16:54:07 2010 (r5796) @@ -57,32 +57,28 @@ static void set_EnableCf8ExtCfg(void) { } #endif -/*[39:8] */ -#define PCI_MMIO_BASE 0xfe000000 -/* because we will use gs to store hi, so need to make sure lo can start - from 0, So PCI_MMIO_BASE & 0x00ffffff should be equal to 0*/ + +#define _ULLx(x) x ## ULL +#define _ULL(x) _ULLx(x) + +/*[63:0] */ +#define PCI_MMIO_BASE _ULL(CONFIG_MMCONF_BASE_ADDRESS) static void set_pci_mmio_conf_reg(void) { #if CONFIG_MMCONF_SUPPORT +# if PCI_MMIO_BASE > 0xffffffff +# error CONFIG_MMCONF_BASE_ADDRESS must currently fit in 32 bits! +# endif msr_t msr; msr = rdmsr(0xc0010058); msr.lo &= ~(0xfff00000 | (0xf << 2)); - // 256 bus per segment, MMIO reg will be 4G , enable MMIO Config space - msr.lo |= ((8 + CONFIG_PCI_BUS_SEGN_BITS) << 2) | (1 << 0); + // 256 buses, one segment. Total 256M address space. + msr.lo |= (PCI_MMIO_BASE & 0xfff00000) | (8 << 2) | (1 << 0); msr.hi &= ~(0x0000ffff); - msr.hi |= (PCI_MMIO_BASE >> (32 - 8)); - wrmsr(0xc0010058, msr); // MMIO Config Base Address Reg - - //mtrr for that range? - // set_var_mtrr_x(7, PCI_MMIO_BASE<<8, PCI_MMIO_BASE>>(32-8), 0x00000000, 0x01, MTRR_TYPE_UNCACHEABLE); - - set_wrap32dis(); - - msr.hi = (PCI_MMIO_BASE >> (32 - 8)); - msr.lo = 0; - wrmsr(0xc0000101, msr); //GS_Base Reg + msr.hi |= (PCI_MMIO_BASE >> (32)); + wrmsr(0xc0010058, msr); // MMIO Config Base Address Reg #endif } Modified: trunk/src/mainboard/tyan/s2912_fam10/Kconfig ============================================================================== --- trunk/src/mainboard/tyan/s2912_fam10/Kconfig Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/mainboard/tyan/s2912_fam10/Kconfig Thu Sep 9 16:54:07 2010 (r5796) @@ -18,6 +18,7 @@ select ENABLE_APIC_EXT_ID select AMDMCT select TINY_BOOTBLOCK + select MMCONF_SUPPORT_DEFAULT config MAINBOARD_DIR string Modified: trunk/src/northbridge/amd/amdfam10/Kconfig ============================================================================== --- trunk/src/northbridge/amd/amdfam10/Kconfig Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/northbridge/amd/amdfam10/Kconfig Thu Sep 9 16:54:07 2010 (r5796) @@ -23,6 +23,7 @@ select HAVE_DEBUG_SMBUS select HYPERTRANSPORT_PLUGIN_SUPPORT select NORTHBRIDGE_AMD_AMDFAM10_ROOT_COMPLEX + select MMCONF_SUPPORT config AGP_APERTURE_SIZE hex @@ -54,6 +55,16 @@ default n depends on NORTHBRIDGE_AMD_AMDFAM10 +config MMCONF_BASE_ADDRESS + hex + default 0xe0000000 + depends on NORTHBRIDGE_AMD_AMDFAM10 + +config MMCONF_BUS_NUMBER + int + default 256 + depends on NORTHBRIDGE_AMD_AMDFAM10 + config BOOTBLOCK_NORTHBRIDGE_INIT string default "northbridge/amd/amdfam10/bootblock.c" Modified: trunk/src/northbridge/amd/amdfam10/early_ht.c ============================================================================== --- trunk/src/northbridge/amd/amdfam10/early_ht.c Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/northbridge/amd/amdfam10/early_ht.c Thu Sep 9 16:54:07 2010 (r5796) @@ -129,7 +129,7 @@ PCI_HT_CAP_SLAVE_CTRL0 : PCI_HT_CAP_SLAVE_CTRL1; do { - ctrl = pci_read_config16(devx, pos + ctrl_off); + ctrl = pci_io_read_config16(devx, pos + ctrl_off); /* Is this the end of the hypertransport chain? */ if (ctrl & (1 << 6)) { goto out; @@ -144,8 +144,8 @@ * if its transient */ ctrl |= ((1 << 4) | (1 <<8)); // Link fail + Crc - pci_write_config16(devx, pos + ctrl_off, ctrl); - ctrl = pci_read_config16(devx, pos + ctrl_off); + pci_io_write_config16(devx, pos + ctrl_off, ctrl); + ctrl = pci_io_read_config16(devx, pos + ctrl_off); if (ctrl & ((1 << 4) | (1 << 8))) { // can not clear the error break; Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c ============================================================================== --- trunk/src/northbridge/amd/amdfam10/northbridge.c Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/northbridge/amd/amdfam10/northbridge.c Thu Sep 9 16:54:07 2010 (r5796) @@ -1440,9 +1440,29 @@ { } +static void cpu_bus_read_resources(device_t dev) +{ +#if CONFIG_MMCONF_SUPPORT + struct resource *resource = new_resource(dev, 0xc0010058); + resource->base = CONFIG_MMCONF_BASE_ADDRESS; + resource->size = CONFIG_MMCONF_BUS_NUMBER * 4096*256; + resource->flags = IORESOURCE_MEM | IORESOURCE_RESERVE | + IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; +#endif +} + +static void cpu_bus_set_resources(device_t dev) +{ + struct resource *resource = find_resource(dev, 0xc0010058); + if (resource) { + report_resource_stored(dev, resource, " "); + } + pci_dev_set_resources(dev); +} + static struct device_operations cpu_bus_ops = { - .read_resources = cpu_bus_noop, - .set_resources = cpu_bus_noop, + .read_resources = cpu_bus_read_resources, + .set_resources = cpu_bus_set_resources, .enable_resources = cpu_bus_noop, .init = cpu_bus_init, .scan_bus = cpu_bus_scan, Modified: trunk/src/northbridge/amd/amdmct/mct/mct_d.c ============================================================================== --- trunk/src/northbridge/amd/amdmct/mct/mct_d.c Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/northbridge/amd/amdmct/mct/mct_d.c Thu Sep 9 16:54:07 2010 (r5796) @@ -1970,7 +1970,7 @@ reg = 0x40 + (q << 2) + reg_off; /* Base[q] reg.*/ val = Get_NB32(dev, reg); if (!(val & 3)) { /* (CSEnable|Spare==1)bank is enabled already? */ - reg = 0x60 + (q << 1) + reg_off; /*Mask[q] reg.*/ + reg = 0x60 + ((q << 1) & 0xc) + reg_off; /*Mask[q] reg.*/ val = Get_NB32(dev, reg); val >>= 19; val++; Modified: trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c ============================================================================== --- trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c Thu Sep 9 16:51:17 2010 (r5795) +++ trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c Thu Sep 9 16:54:07 2010 (r5796) @@ -267,8 +267,13 @@ RES_PCI_IO, PCI_ADDR(0, 6, 0, 0x74), 0xFFFFFFC0, 0x00000000, RES_PCI_IO, PCI_ADDR(0, 6, 0, 0xC0), 0x00000000, 0xCB8410DE, RES_PCI_IO, PCI_ADDR(0, 6, 0, 0xC4), 0xFFFFFFF8, 0x00000007, - - RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, + /* The following operation hangs when performed via MMCFG: + pci_read_config32(romcc): 00010000:0078: 20040000 + setup_resource_map_x_offset: 10000, 78: 20040000 + pci_write_config32(romcc): 00010000:0078: 19040000 + (hang) + Response missing? */ + /* RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, */ #if MCP55_USE_AZA == 1 RES_PCI_IO, PCI_ADDR(0, 6, 1, 0x40), 0x00000000, 0xCB8410DE, From mylesgw at gmail.com Thu Sep 9 16:56:14 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 9 Sep 2010 08:56:14 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <874odztlt7.fsf@taniquetil.gledits.ch> References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> <874odztlt7.fsf@taniquetil.gledits.ch> Message-ID: On Thu, Sep 9, 2010 at 1:31 AM, Arne Georg Gleditsch wrote: > Arne Georg Gleditsch writes: >> Ok, so building on that, here's an updated version of the first patch. >> The resource is still fixed, but the gratuitous call through >> add_mainboard_resource is gone and the coreboot table manipulation is >> removed from the northbridge code. > > For the record, this version is also > > Signed-off-by: Arne Georg Gleditsch Acked-by: Myles Watson Rev 5795. Rev 5796. I split it into two to make it easier to understand. I almost split it again so that your bug fixes were separate from the board-specific code. Thanks, Myles From scott at notabs.org Thu Sep 9 17:02:58 2010 From: scott at notabs.org (Scott Duplichan) Date: Thu, 9 Sep 2010 10:02:58 -0500 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <87occ7s0gf.fsf@taniquetil.gledits.ch> References: <4C812B6D020000FE0000D531@mail.lkfd.net><87aanv1eax.fsf@taniquetil.gledits.ch><4C84BD83.2030502@coresystems.de><8762yj170a.fsf@taniquetil.gledits.ch><673D2439DC3046D0903811C4830EA052@m3a78><2AB823A1470D4921A664FB35592308CE@m3a78><87wrqvs5ua.fsf@taniquetil.gledits.ch><87sk1js2d8.fsf@taniquetil.gledits.ch> <87occ7s0gf.fsf@taniquetil.gledits.ch> Message-ID: ]-----Original Message----- ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Arne Georg Gleditsch ]Sent: Thursday, September 09, 2010 04:58 AM ]To: Scott Duplichan ]Cc: 'Marc Jones'; coreboot at coreboot.org ]Subject: Re: [coreboot] AMD cache setup is broken ] ]Arne Georg Gleditsch writes: ]> + /* Clear ClLinesToNbDis */ ]> + msr = rdmsr(BU_CFG2_MSR); ]> + msr.lo &= ~(1 << 15); ]> + wrmsr(BU_CFG2_MSR, msr); ] ]On an slightly unrelated note; do we want to clear bit 35 here as well? ]At the moment, this is only done for the BSP, causing the MSR settings ]to be inconsistent after boot. I see that errata 343 indicates that ]this should be cleared after CAR is disabled, so it might not matter all ]that much for the APs... I think it would be best to clear bit 35 of msr c001_102a in the AP cores as well as the BSP core. Otherwise, the OS might see AP cores having slightly lower performance than the BSP core. This bit affects family 10h revC and newer (45 nm). Thanks, Scott ] ]-- ] Arne. From mylesgw at gmail.com Thu Sep 9 17:04:05 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 9 Sep 2010 09:04:05 -0600 Subject: [coreboot] [PATCH] i945 mainboard resources Message-ID: I think we should get rid of HAVE_MAINBOARD_RESOURCES. Here's a patch that does that for i945 boards. The Roda board provided add_mainboard_resources(), but it was never called because it didn't select HAVE_MAINBOARD_RESOURCES in Kconfig. Testing & suggestions welcome. Signed-off-by: Myles Watson Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: kontron_res.diff Type: text/x-diff Size: 6442 bytes Desc: not available URL: From mylesgw at gmail.com Thu Sep 9 17:23:24 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 9 Sep 2010 09:23:24 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> <874odztlt7.fsf@taniquetil.gledits.ch> Message-ID: - - RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, + /* The following operation hangs when performed via MMCFG: + pci_read_config32(romcc): 00010000:0078: 20040000 + setup_resource_map_x_offset: 10000, 78: 20040000 + pci_write_config32(romcc): 00010000:0078: 19040000 + (hang) + Response missing? */ + /* RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, */ I forgot to ask if you'd tried setting the SyncOnWdError bit (20) in function 3, register 0x44. That could help further debug this problem. For me it caused a reboot instead of a hang when there was a response missing. Bit 21 could also be helpful. Since we don't have the chipset documentation, it makes me a little worried to leave out one of the settings. Maybe we could use non MMCONF writes for that setting. Thanks, Myles From svn at coreboot.org Thu Sep 9 18:00:20 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 18:00:20 +0200 Subject: [coreboot] [commit] r5797 - trunk/src/devices/oprom/yabel Message-ID: Author: myles Date: Thu Sep 9 18:00:20 2010 New Revision: 5797 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5797 Log: Make huge macros inline functions for readability. Remove warnings. Trivial. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/devices/oprom/yabel/mem.c trunk/src/devices/oprom/yabel/vbe.c Modified: trunk/src/devices/oprom/yabel/mem.c ============================================================================== --- trunk/src/devices/oprom/yabel/mem.c Thu Sep 9 16:54:07 2010 (r5796) +++ trunk/src/devices/oprom/yabel/mem.c Thu Sep 9 18:00:20 2010 (r5797) @@ -19,149 +19,177 @@ #include "mem.h" #include "compat/time.h" +#if !defined(CONFIG_YABEL_DIRECTHW) || (!CONFIG_YABEL_DIRECTHW) + // define a check for access to certain (virtual) memory regions (interrupt handlers, BIOS Data Area, ...) #if CONFIG_X86EMU_DEBUG static u8 in_check = 0; // to avoid recursion... -u16 ebda_segment; -u32 ebda_size; -//TODO: these macros have grown so large, that they should be changed to an inline function, -//just for the sake of readability... +static inline void DEBUG_CHECK_VMEM_READ(u32 _addr, u32 _rval) +{ + u16 ebda_segment; + u32 ebda_size; + if (!((debug_flags & DEBUG_CHECK_VMEM_ACCESS) && (in_check == 0))) + return; + in_check = 1; + /* determine ebda_segment and size + * since we are using my_rdx calls, make sure, this is after setting in_check! */ + /* offset 03 in BDA is EBDA segment */ + ebda_segment = my_rdw(0x40e); + /* first value in ebda is size in KB */ + ebda_size = my_rdb(ebda_segment << 4) * 1024; + /* check Interrupt Vector Access (0000:0000h - 0000:0400h) */ + if (_addr < 0x400) { + DEBUG_PRINTF_CS_IP("%s: read from Interrupt Vector %x --> %x\n", + __func__, _addr / 4, _rval); + } + /* access to BIOS Data Area (0000:0400h - 0000:0500h)*/ + else if ((_addr >= 0x400) && (_addr < 0x500)) { + DEBUG_PRINTF_CS_IP("%s: read from BIOS Data Area: addr: %x --> %x\n", + __func__, _addr, _rval); + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* access to first 64k of memory... */ + else if (_addr < 0x10000) { + DEBUG_PRINTF_CS_IP("%s: read from segment 0000h: addr: %x --> %x\n", + __func__, _addr, _rval); + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* read from PMM_CONV_SEGMENT */ + else if ((_addr <= ((PMM_CONV_SEGMENT << 4) | 0xffff)) && (_addr >= (PMM_CONV_SEGMENT << 4))) { + DEBUG_PRINTF_CS_IP("%s: read from PMM Segment %04xh: addr: %x --> %x\n", + __func__, PMM_CONV_SEGMENT, _addr, _rval); + /* HALT_SYS(); */ + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* read from PNP_DATA_SEGMENT */ + else if ((_addr <= ((PNP_DATA_SEGMENT << 4) | 0xffff)) && (_addr >= (PNP_DATA_SEGMENT << 4))) { + DEBUG_PRINTF_CS_IP("%s: read from PnP Data Segment %04xh: addr: %x --> %x\n", + __func__, PNP_DATA_SEGMENT, _addr, _rval); + /* HALT_SYS(); */ + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* read from EBDA Segment */ + else if ((_addr <= ((ebda_segment << 4) | (ebda_size - 1))) && (_addr >= (ebda_segment << 4))) { + DEBUG_PRINTF_CS_IP("%s: read from Extended BIOS Data Area %04xh, size: %04x: addr: %x --> %x\n", + __func__, ebda_segment, ebda_size, _addr, _rval); + } + /* read from BIOS_DATA_SEGMENT */ + else if ((_addr <= ((BIOS_DATA_SEGMENT << 4) | 0xffff)) && (_addr >= (BIOS_DATA_SEGMENT << 4))) { + DEBUG_PRINTF_CS_IP("%s: read from BIOS Data Segment %04xh: addr: %x --> %x\n", + __func__, BIOS_DATA_SEGMENT, _addr, _rval); + /* for PMM debugging */ + /*if (_addr == BIOS_DATA_SEGMENT << 4) { + X86EMU_trace_on(); + M.x86.debug &= ~DEBUG_DECODE_NOPRINT_F; + }*/ + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + in_check = 0; +} -#define DEBUG_CHECK_VMEM_READ(_addr, _rval) \ - if ((debug_flags & DEBUG_CHECK_VMEM_ACCESS) && (in_check == 0)) { \ - in_check = 1; \ - /* determine ebda_segment and size \ - * since we are using my_rdx calls, make sure, this is after setting in_check! */ \ - /* offset 03 in BDA is EBDA segment */ \ - ebda_segment = my_rdw(0x40e); \ - /* first value in ebda is size in KB */ \ - ebda_size = my_rdb(ebda_segment << 4) * 1024; \ - /* check Interrupt Vector Access (0000:0000h - 0000:0400h) */ \ - if (_addr < 0x400) { \ - DEBUG_PRINTF_CS_IP("%s: read from Interrupt Vector %x --> %x\n", \ - __func__, _addr / 4, _rval); \ - } \ - /* access to BIOS Data Area (0000:0400h - 0000:0500h)*/ \ - else if ((_addr >= 0x400) && (addr < 0x500)) { \ - DEBUG_PRINTF_CS_IP("%s: read from BIOS Data Area: addr: %x --> %x\n", \ - __func__, _addr, _rval); \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* access to first 64k of memory... */ \ - else if (_addr < 0x10000) { \ - DEBUG_PRINTF_CS_IP("%s: read from segment 0000h: addr: %x --> %x\n", \ - __func__, _addr, _rval); \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* read from PMM_CONV_SEGMENT */ \ - else if ((_addr <= ((PMM_CONV_SEGMENT << 4) | 0xffff)) && (_addr >= (PMM_CONV_SEGMENT << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: read from PMM Segment %04xh: addr: %x --> %x\n", \ - __func__, PMM_CONV_SEGMENT, _addr, _rval); \ - /* HALT_SYS(); */ \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* read from PNP_DATA_SEGMENT */ \ - else if ((_addr <= ((PNP_DATA_SEGMENT << 4) | 0xffff)) && (_addr >= (PNP_DATA_SEGMENT << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: read from PnP Data Segment %04xh: addr: %x --> %x\n", \ - __func__, PNP_DATA_SEGMENT, _addr, _rval); \ - /* HALT_SYS(); */ \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* read from EBDA Segment */ \ - else if ((_addr <= ((ebda_segment << 4) | (ebda_size - 1))) && (_addr >= (ebda_segment << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: read from Extended BIOS Data Area %04xh, size: %04x: addr: %x --> %x\n", \ - __func__, ebda_segment, ebda_size, _addr, _rval); \ - } \ - /* read from BIOS_DATA_SEGMENT */ \ - else if ((_addr <= ((BIOS_DATA_SEGMENT << 4) | 0xffff)) && (_addr >= (BIOS_DATA_SEGMENT << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: read from BIOS Data Segment %04xh: addr: %x --> %x\n", \ - __func__, BIOS_DATA_SEGMENT, _addr, _rval); \ - /* for PMM debugging */ \ - /*if (_addr == BIOS_DATA_SEGMENT << 4) { \ - X86EMU_trace_on(); \ - M.x86.debug &= ~DEBUG_DECODE_NOPRINT_F; \ - }*/ \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - in_check = 0; \ - } -#define DEBUG_CHECK_VMEM_WRITE(_addr, _val) \ - if ((debug_flags & DEBUG_CHECK_VMEM_ACCESS) && (in_check == 0)) { \ - in_check = 1; \ - /* determine ebda_segment and size \ - * since we are using my_rdx calls, make sure, this is after setting in_check! */ \ - /* offset 03 in BDA is EBDA segment */ \ - ebda_segment = my_rdw(0x40e); \ - /* first value in ebda is size in KB */ \ - ebda_size = my_rdb(ebda_segment << 4) * 1024; \ - /* check Interrupt Vector Access (0000:0000h - 0000:0400h) */ \ - if (_addr < 0x400) { \ - DEBUG_PRINTF_CS_IP("%s: write to Interrupt Vector %x <-- %x\n", \ - __func__, _addr / 4, _val); \ - } \ - /* access to BIOS Data Area (0000:0400h - 0000:0500h)*/ \ - else if ((_addr >= 0x400) && (addr < 0x500)) { \ - DEBUG_PRINTF_CS_IP("%s: write to BIOS Data Area: addr: %x <-- %x\n", \ - __func__, _addr, _val); \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* access to first 64k of memory...*/ \ - else if (_addr < 0x10000) { \ - DEBUG_PRINTF_CS_IP("%s: write to segment 0000h: addr: %x <-- %x\n", \ - __func__, _addr, _val); \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* write to PMM_CONV_SEGMENT... */ \ - else if ((_addr <= ((PMM_CONV_SEGMENT << 4) | 0xffff)) && (_addr >= (PMM_CONV_SEGMENT << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: write to PMM Segment %04xh: addr: %x <-- %x\n", \ - __func__, PMM_CONV_SEGMENT, _addr, _val); \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* write to PNP_DATA_SEGMENT... */ \ - else if ((_addr <= ((PNP_DATA_SEGMENT << 4) | 0xffff)) && (_addr >= (PNP_DATA_SEGMENT << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: write to PnP Data Segment %04xh: addr: %x <-- %x\n", \ - __func__, PNP_DATA_SEGMENT, _addr, _val); \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* write to EBDA Segment... */ \ - else if ((_addr <= ((ebda_segment << 4) | (ebda_size - 1))) && (_addr >= (ebda_segment << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: write to Extended BIOS Data Area %04xh, size: %04x: addr: %x <-- %x\n", \ - __func__, ebda_segment, ebda_size, _addr, _val); \ - } \ - /* write to BIOS_DATA_SEGMENT... */ \ - else if ((_addr <= ((BIOS_DATA_SEGMENT << 4) | 0xffff)) && (_addr >= (BIOS_DATA_SEGMENT << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: write to BIOS Data Segment %04xh: addr: %x <-- %x\n", \ - __func__, BIOS_DATA_SEGMENT, _addr, _val); \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - /* write to current CS segment... */ \ - else if ((_addr < ((M.x86.R_CS << 4) | 0xffff)) && (_addr > (M.x86.R_CS << 4))) { \ - DEBUG_PRINTF_CS_IP("%s: write to CS segment %04xh: addr: %x <-- %x\n", \ - __func__, M.x86.R_CS, _addr, _val); \ - /* dump registers */ \ - /* x86emu_dump_xregs(); */ \ - } \ - in_check = 0; \ - } +static inline void DEBUG_CHECK_VMEM_WRITE(u32 _addr, u32 _val) +{ + u16 ebda_segment; + u32 ebda_size; + if (!((debug_flags & DEBUG_CHECK_VMEM_ACCESS) && (in_check == 0))) + return; + in_check = 1; + /* determine ebda_segment and size + * since we are using my_rdx calls, make sure that this is after + * setting in_check! */ + /* offset 03 in BDA is EBDA segment */ + ebda_segment = my_rdw(0x40e); + /* first value in ebda is size in KB */ + ebda_size = my_rdb(ebda_segment << 4) * 1024; + /* check Interrupt Vector Access (0000:0000h - 0000:0400h) */ + if (_addr < 0x400) { + DEBUG_PRINTF_CS_IP("%s: write to Interrupt Vector %x <-- %x\n", + __func__, _addr / 4, _val); + } + /* access to BIOS Data Area (0000:0400h - 0000:0500h)*/ + else if ((_addr >= 0x400) && (_addr < 0x500)) { + DEBUG_PRINTF_CS_IP("%s: write to BIOS Data Area: addr: %x <-- %x\n", + __func__, _addr, _val); + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* access to first 64k of memory...*/ + else if (_addr < 0x10000) { + DEBUG_PRINTF_CS_IP("%s: write to segment 0000h: addr: %x <-- %x\n", + __func__, _addr, _val); + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* write to PMM_CONV_SEGMENT... */ + else if ((_addr <= ((PMM_CONV_SEGMENT << 4) | 0xffff)) && (_addr >= (PMM_CONV_SEGMENT << 4))) { + DEBUG_PRINTF_CS_IP("%s: write to PMM Segment %04xh: addr: %x <-- %x\n", + __func__, PMM_CONV_SEGMENT, _addr, _val); + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* write to PNP_DATA_SEGMENT... */ + else if ((_addr <= ((PNP_DATA_SEGMENT << 4) | 0xffff)) && (_addr >= (PNP_DATA_SEGMENT << 4))) { + DEBUG_PRINTF_CS_IP("%s: write to PnP Data Segment %04xh: addr: %x <-- %x\n", + __func__, PNP_DATA_SEGMENT, _addr, _val); + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* write to EBDA Segment... */ + else if ((_addr <= ((ebda_segment << 4) | (ebda_size - 1))) && (_addr >= (ebda_segment << 4))) { + DEBUG_PRINTF_CS_IP("%s: write to Extended BIOS Data Area %04xh, size: %04x: addr: %x <-- %x\n", + __func__, ebda_segment, ebda_size, _addr, _val); + } + /* write to BIOS_DATA_SEGMENT... */ + else if ((_addr <= ((BIOS_DATA_SEGMENT << 4) | 0xffff)) && (_addr >= (BIOS_DATA_SEGMENT << 4))) { + DEBUG_PRINTF_CS_IP("%s: write to BIOS Data Segment %04xh: addr: %x <-- %x\n", + __func__, BIOS_DATA_SEGMENT, _addr, _val); + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + /* write to current CS segment... */ + else if ((_addr < ((M.x86.R_CS << 4) | 0xffff)) && (_addr > (M.x86.R_CS << 4))) { + DEBUG_PRINTF_CS_IP("%s: write to CS segment %04xh: addr: %x <-- %x\n", + __func__, M.x86.R_CS, _addr, _val); + /* dump registers */ + /* x86emu_dump_xregs(); */ + } + in_check = 0; +} #else -#define DEBUG_CHECK_VMEM_READ(_addr, _rval) -#define DEBUG_CHECK_VMEM_WRITE(_addr, _val) +static inline void DEBUG_CHECK_VMEM_READ(u32 _addr, u32 _rval) {}; +static inline void DEBUG_CHECK_VMEM_WRITE(u32 _addr, u32 _val) {}; #endif -void update_time(u32); +//update time in BIOS Data Area +//DWord at offset 0x6c is the timer ticks since midnight, timer is running at 18Hz +//byte at 0x70 is timer overflow (set if midnight passed since last call to interrupt 1a function 00 +//cur_val is the current value, of offset 6c... +static void +update_time(u32 cur_val) +{ + //for convenience, we let the start of timebase be at midnight, we currently dont support + //real daytime anyway... + u64 ticks_per_day = tb_freq * 60 * 24; + // at 18Hz a period is ~55ms, converted to ticks (tb_freq is ticks/second) + u32 period_ticks = (55 * tb_freq) / 1000; + u64 curr_time = get_time(); + u64 ticks_since_midnight = curr_time % ticks_per_day; + u32 periods_since_midnight = ticks_since_midnight / period_ticks; + // if periods since midnight is smaller than last value, set overflow + // at BDA Offset 0x70 + if (periods_since_midnight < cur_val) { + my_wrb(0x470, 1); + } + // store periods since midnight at BDA offset 0x6c + my_wrl(0x46c, periods_since_midnight); +} -#if !defined(CONFIG_YABEL_DIRECTHW) || (!CONFIG_YABEL_DIRECTHW) // read byte from memory u8 my_rdb(u32 addr) @@ -467,27 +495,3 @@ wrl(addr, val); } #endif - -//update time in BIOS Data Area -//DWord at offset 0x6c is the timer ticks since midnight, timer is running at 18Hz -//byte at 0x70 is timer overflow (set if midnight passed since last call to interrupt 1a function 00 -//cur_val is the current value, of offset 6c... -void -update_time(u32 cur_val) -{ - //for convenience, we let the start of timebase be at midnight, we currently dont support - //real daytime anyway... - u64 ticks_per_day = tb_freq * 60 * 24; - // at 18Hz a period is ~55ms, converted to ticks (tb_freq is ticks/second) - u32 period_ticks = (55 * tb_freq) / 1000; - u64 curr_time = get_time(); - u64 ticks_since_midnight = curr_time % ticks_per_day; - u32 periods_since_midnight = ticks_since_midnight / period_ticks; - // if periods since midnight is smaller than last value, set overflow - // at BDA Offset 0x70 - if (periods_since_midnight < cur_val) { - my_wrb(0x470, 1); - } - // store periods since midnight at BDA offset 0x6c - my_wrl(0x46c, periods_since_midnight); -} Modified: trunk/src/devices/oprom/yabel/vbe.c ============================================================================== --- trunk/src/devices/oprom/yabel/vbe.c Thu Sep 9 16:54:07 2010 (r5796) +++ trunk/src/devices/oprom/yabel/vbe.c Thu Sep 9 18:00:20 2010 (r5797) @@ -154,7 +154,7 @@ return 0; // successfull init } -#if CONFIG_BOOTSPLASH || CONFIG_EXPERT +#if CONFIG_BOOTSPLASH // VBE Function 00h static u8 vbe_info(vbe_info_t * info) @@ -301,9 +301,7 @@ } return 0; } -#endif -#if CONFIG_EXPERT //VBE Function 08h static u8 vbe_set_palette_format(u8 format) @@ -766,9 +764,7 @@ } return 0; } -#endif -#if CONFIG_BOOTSPLASH vbe_mode_info_t mode_info; void vbe_set_graphics(void) @@ -798,7 +794,7 @@ vbe_get_mode_info(&mode_info); unsigned char *framebuffer = (unsigned char *) le32_to_cpu(mode_info.vesa.phys_base_ptr); - DEBUG_PRINTF_VBE("FRAMEBUFFER: 0x%08x\n", framebuffer); + DEBUG_PRINTF_VBE("FRAMEBUFFER: 0x%p\n", framebuffer); vbe_set_mode(&mode_info); struct jpeg_decdata *decdata; @@ -813,7 +809,7 @@ DEBUG_PRINTF_VBE("Could not find bootsplash.jpg\n"); return; } - DEBUG_PRINTF_VBE("Splash at %08x ...\n", jpeg); + DEBUG_PRINTF_VBE("Splash at %p ...\n", jpeg); dump(jpeg, 64); int ret = 0; From juhe at iki.fi Thu Sep 9 18:12:55 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Thu, 09 Sep 2010 19:12:55 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> Message-ID: <1284048775.538.23.camel@bart> On Sat, 2010-09-04 at 15:23 -0600, Myles Watson wrote: > It would be a lot easier to review if you split the patch into smaller pieces. > > 1. Use svn cp to copy the tilapia board directory for your board > 2. Make the changes so it works for your board (just copy the files > you already have from another location) > 3. svn diff > > This will produce a patch with only your changes. > > Split out work-around patches as well. Something is broken for your > board, and that needs to be fixed, but I don't think we should change > the PCI scan code. Ok, this makes sense. The previous patch I sent was unnecessarily large. There are now three smaller patches attached: (1) Changes specific to this board. Fairly small changes from AMD Tilapia. Requires (2) to work. (2) Small, hopefully non-intrusive, patches to generic code that are required to prevent hangups/crashes on this board. (3) Multiboot table patch required to get UMA and high coreboot tables locations to Grub and Linux. Independent of (1) and (2). Signed-off-by: Juhana Helovuo I tested appying these patches, building and flashing using the following procedure: 1. Check out Coreboot from SVN % svn co svn://coreboot.org/coreboot/trunk coreboot * The revision used here was 5792. 2. chdir to coreboot 3. svn cp src/mainboard/amd/tilapia_fam10 src/mainboard/asus/m4a785-m 4. patch % patch -p1 < ../patches/asus-m4a785m-small-patch.patch % patch -p1 < ../patches/multiboot-table-after-cb-table-r5756-v2.patch % patch -p1 < ../patches/generic-code-patches-for-m4a785m.patch 5. make menuconfig * Select mainboard vendor & model * ROM chip size 1 MByte * Select: Use VGA console once initialized * Select Use onboard VGA as primary video device * Add payload (grub2 and coreinfo tested to work) * Add VGA BIOS: The BIOS for the on-board ATI Radeon HD 4200 can be extracted with dd from /dev/mem as shown in http://www.coreboot.org/VGA_support . The bios_extract utility can extract some other option ROMs, but it crashes before it gets the VGA ROM. * If on-board VGA BIOS is added, set VGA device PCI IDs to "1002,9710" 6. make * The result should be a working coreboot.rom. This procedure worked for me. Can someone acknowledge that the patches do not break anything? The changes required in generic code are a bit ugly, but I am not familiar enough with Coreboot to figure out any neater solution. Best regards, Juhana Helovuo -------------- next part -------------- A non-text attachment was scrubbed... Name: asus-m4a785m-small-patch.patch Type: text/x-patch Size: 17644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: generic-code-patches-for-m4a785m.patch Type: text/x-patch Size: 4199 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: multiboot-table-after-cb-table-r5756-v2.patch Type: text/x-patch Size: 6599 bytes Desc: not available URL: From JRottmann at LiPPERTEmbedded.de Thu Sep 9 18:55:31 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Thu, 09 Sep 2010 18:55:31 +0200 Subject: [coreboot] [PATCH] LiPPERT Hurricane-LX support Message-ID: <4C891183.6090805@LiPPERTEmbedded.de> Finally!! :-) Kindly 'svn copy' src/mainboard/lippert/spacerunner-lx to src/mainboard/lippert/hurricane-lx before applying. Cheers, Jens -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Hurricane-LX.diff URL: From footplus at gmail.com Thu Sep 9 20:39:10 2010 From: footplus at gmail.com (=?UTF-8?B?QXVyw6lsaWVu?=) Date: Thu, 9 Sep 2010 20:39:10 +0200 Subject: [coreboot] [PATCH] filo: trivial compilation fix and a remark about USB support Message-ID: Hi, Below is a trivial patch for filo. filo does not compile with the grub interface right out of the SVN: coreboot/payloads/filo/build/main/grub/completions.o: In function `print_completions': completions.c:(.text+0x2f2): undefined reference to `IS_PC_SLICE_TYPE_BSD' This patch defines this macro to 0 (false), like what is done in fs/filesys.h, which fixes the problem. However, this may not be the right way to fix it. Please do check before applying. --- I also have a remark about USB support in filo: The default configuration for filo enables support for USB, although the default configuration for libpayload does not. There's no harm done, since you have to configure both, but it appears more logical to have USB disabled in both config. Anyways, that's not really a problem :) --- Signed-off-by: Aurelien Guillaume Index: main/grub/completions.c =================================================================== --- main/grub/completions.c (revision 138) +++ main/grub/completions.c (working copy) @@ -23,6 +23,7 @@ #include #include #define current_slice 0 +#define IS_PC_SLICE_TYPE_BSD(type) 0 static int do_completion; static int unique; -- Aur?lien Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: From mylesgw at gmail.com Thu Sep 9 21:39:30 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 9 Sep 2010 13:39:30 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <1284048775.538.23.camel@bart> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> Message-ID: <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> > There are now three smaller patches attached: Much nicer! Thanks. > (1) Changes specific to this board. Fairly small changes from AMD > Tilapia. Requires (2) to work. >From your mainboard's Kconfig: +config DIMM_SUPPORT + hex + default 0x0004 + depends on CPU_AMD_SOCKET_AM3 This really worries me. You shouldn't need to change the type of memory on the Socket. I looked at your board online, and they suggest that your board supports socket AM2, AM2+, and AM3. That seems like it breaks our model. I thought AM2 was DDR2 and AM3 was DDR3. Anyone want to chip in here? Marc? Stefan? ... Anyone? > (2) Small, hopefully non-intrusive, patches to generic code that are > required to prevent hangups/crashes on this board. I think these could be reduced further. I'd like to see the ISA fix be a Kconfig option in the sb700 Kconfig file. Something like SB700_SKIP_ISA_DMA_INIT which defaults to n. Then in your board you select it. It shouldn't print anything at all when it isn't selected, and probably just one "skipping" message when it is selected. Returning the value from the watchdog was good for debugging, but I don't think it's something that should be committed. In general, the fewer changes the better! > (3) Multiboot table patch required to get UMA and high coreboot tables > locations to Grub and Linux. Independent of (1) and (2). Do we need to dump the tables? It seems like generating them from the coreboot tables is nearly trivial. After you've debugged your code, I don't think anyone needs to see that debug output. Thanks, Myles From marcj303 at gmail.com Thu Sep 9 21:59:45 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 9 Sep 2010 13:59:45 -0600 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <4C88B88E.1070801@georgi-clan.de> References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <4C88AF57.7010002@georgi-clan.de> <87k4mvs02h.fsf@taniquetil.gledits.ch> <4C88B88E.1070801@georgi-clan.de> Message-ID: On Thu, Sep 9, 2010 at 4:35 AM, Patrick Georgi wrote: > Am 09.09.2010 12:06, schrieb Arne Georg Gleditsch: >> I guess we want to do this in the DDR3 path as, well. ?Patch appended to >> do so, as well as fix a minor typo in the last one. >> >> Signed-off-by: Arne Georg Gleditsch > Acked-by: Patrick Georgi > > r5792 Thanks for doing this. I got sucked into other issues yesterday.... Marc From svn at coreboot.org Thu Sep 9 22:37:01 2010 From: svn at coreboot.org (repository service) Date: Thu, 09 Sep 2010 22:37:01 +0200 Subject: [coreboot] [commit] r5798 - trunk/src/pc80 Message-ID: Author: mjones Date: Thu Sep 9 22:37:00 2010 New Revision: 5798 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5798 Log: This patch avoids a timeout during PS/2 keyboard initialization. It can reduce KBC init time by up to 400 ms on real hardware, and by a minute or so on AMD simnow. Signed-off-by: Scott Duplichan Acked-by: Marc Jones Modified: trunk/src/pc80/keyboard.c Modified: trunk/src/pc80/keyboard.c ============================================================================== --- trunk/src/pc80/keyboard.c Thu Sep 9 18:00:20 2010 (r5797) +++ trunk/src/pc80/keyboard.c Thu Sep 9 22:37:00 2010 (r5798) @@ -244,7 +244,7 @@ outb(0x60, KBD_COMMAND); if (!kbc_input_buffer_empty()) return; outb(0x61, KBD_DATA); /* send cmd: enable keyboard and IRQ 1 */ - if (kbc_output_buffer_full()) { + if (!kbc_input_buffer_empty()) { printk(BIOS_ERR, "Timeout during final keyboard enable\n"); return; } From marcj303 at gmail.com Thu Sep 9 22:37:50 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 9 Sep 2010 14:37:50 -0600 Subject: [coreboot] [PATCH] timeout during PS/2 keyboard init In-Reply-To: <0984FC1823304EB6BAB26C319C950DD3@m3a78> References: <5AF9C3BD93314353AD324B9F879933C3@m3a78> <0984FC1823304EB6BAB26C319C950DD3@m3a78> Message-ID: On Wed, Sep 8, 2010 at 5:01 PM, Scott Duplichan wrote: > ]-----Original Message----- > ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Marc Jones > ]Sent: Wednesday, September 08, 2010 03:17 PM > ]To: Scott Duplichan > ]Cc: coreboot at coreboot.org > ]Subject: Re: [coreboot] [PATCH] timeout during PS/2 keyboard init > ] > ]On Wed, Sep 8, 2010 at 1:11 PM, Scott Duplichan wrote: > ]> Thanks Marc. This patch avoids a timeout during PS/2 keyboard > ]> initialization. It can reduce KBC init time by up to 400 ms on > ]> real hardware, and by a minute or so on AMD simnow. > ]> > ]> > ]> Signed-off-by: Scott Duplichan > ]> > ]> Index: src/pc80/keyboard.c > ]> =================================================================== > ]> --- src/pc80/keyboard.c (revision 5788) > ]> +++ src/pc80/keyboard.c (working copy) > ]> @@ -242,7 +242,7 @@ > ]> ? ? ? ?outb(0x60, KBD_COMMAND); > ]> ? ? ? ?if (!kbc_input_buffer_empty()) return; > ]> ? ? ? ?outb(0x61, KBD_DATA); ? /* send cmd: enable keyboard and IRQ 1 */ > ]> - ? ? ? if (kbc_output_buffer_full()) { > ]> + ? ? ? if (kbc_input_buffer_empty()) { > ] > ] > ]I think you meant !kbc_input_buffer_empty()? > > Good catch. You are correct. While the previous patch avoids the timeout, > it does not correct the reversed check for when to log the error message. > The revised patch below includes the logging fix, in addition to the > timeout avoidance of the original patch. > > ]Marc > ] > ]-- > ]http://se-eng.com > > > Signed-off-by: Scott Duplichan > > Index: src/pc80/keyboard.c > =================================================================== > --- src/pc80/keyboard.c (revision 5788) > +++ src/pc80/keyboard.c (working copy) > @@ -242,7 +242,7 @@ > ? ? ? ?outb(0x60, KBD_COMMAND); > ? ? ? ?if (!kbc_input_buffer_empty()) return; > ? ? ? ?outb(0x61, KBD_DATA); ? /* send cmd: enable keyboard and IRQ 1 */ > - ? ? ? if (kbc_output_buffer_full()) { > + ? ? ? if (!kbc_input_buffer_empty()) { > ? ? ? ? ? ? ? ?printk(BIOS_ERR, "Timeout during final keyboard enable\n"); > ? ? ? ? ? ? ? ?return; > ? ? ? ?} > > Acked-by: Marc Jones r5798 -- http://se-eng.com From rminnich at gmail.com Thu Sep 9 23:03:15 2010 From: rminnich at gmail.com (ron minnich) Date: Thu, 9 Sep 2010 14:03:15 -0700 Subject: [coreboot] [PATCH] LiPPERT Hurricane-LX support In-Reply-To: <4C891183.6090805@LiPPERTEmbedded.de> References: <4C891183.6090805@LiPPERTEmbedded.de> Message-ID: I'm remembering why I like you lippert guys so much :-) ron From patrick at georgi-clan.de Thu Sep 9 23:15:43 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 09 Sep 2010 23:15:43 +0200 Subject: [coreboot] [PATCH] Updated HP DL165 G6 (Fam10) support Message-ID: <4C894E7F.8080000@georgi-clan.de> Hi, attached you'll find an updated patch to support HP DL165 G6 with Fam10 CPU. It's derived from Arne Gleditsch's code which you can find on http://patchwork.coreboot.org/patch/1387/ Given that its supporting patch is integrated now, I tried to bring it up to date with the various changes we did to the tree (as listed on http://www.coreboot.org/Flag_Days) I can't test it due to lack of such a board, but well, here it is, build-tested only. Originally Signed-off-by: Arne Georg Gleditsch Changes are Signed-off-by: Patrick Georgi Regards, Patrick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 20100909-1-hp-dl165_g6_fam10.diff URL: From marcj303 at gmail.com Thu Sep 9 23:52:19 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 9 Sep 2010 15:52:19 -0600 Subject: [coreboot] [PATCH] filo: trivial compilation fix and a remark about USB support In-Reply-To: References: Message-ID: On Thu, Sep 9, 2010 at 12:39 PM, Aur?lien wrote: > Hi, > Below is a trivial patch for filo. filo does not compile with the grub > interface right out of the SVN: > coreboot/payloads/filo/build/main/grub/completions.o: In function > `print_completions': > completions.c:(.text+0x2f2): undefined reference to `IS_PC_SLICE_TYPE_BSD' > This patch defines this macro to 0 (false), like what is done in > fs/filesys.h, which fixes the problem. However, this may not be the right > way to fix it. Please do check before applying. > --- > I also have a remark about USB support in filo: The default configuration > for filo enables support for USB, although the default configuration for > libpayload does not. There's no harm done, since you have to configure both, > but it appears more logical to have USB disabled in both config. Anyways, > that's not really a problem :) > --- > Signed-off-by: Aurelien Guillaume > Index: main/grub/completions.c > =================================================================== > --- main/grub/completions.c (revision 138) > +++ main/grub/completions.c (working copy) > @@ -23,6 +23,7 @@ > ?#include > ?#include > ?#define current_slice 0 > +#define IS_PC_SLICE_TYPE_BSD(type) 0 > > ?static int do_completion; > ?static int unique; > -- > Aur?lien Guillaume We should check in a lipayload config into filo that matches the default filo config. Marc -- http://se-eng.com From svn at coreboot.org Fri Sep 10 00:12:40 2010 From: svn at coreboot.org (repository service) Date: Fri, 10 Sep 2010 00:12:40 +0200 Subject: [coreboot] [commit] r5799 - trunk/src/cpu/x86/tsc Message-ID: Author: oxygene Date: Fri Sep 10 00:12:40 2010 New Revision: 5799 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5799 Log: Adapt comment, too. (trivial) Noticed-by: Uwe Hermann Signed-off-by: Patrick Georgi Acked-by: Patrick Georgi Modified: trunk/src/cpu/x86/tsc/delay_tsc.c Modified: trunk/src/cpu/x86/tsc/delay_tsc.c ============================================================================== --- trunk/src/cpu/x86/tsc/delay_tsc.c Thu Sep 9 22:37:00 2010 (r5798) +++ trunk/src/cpu/x86/tsc/delay_tsc.c Fri Sep 10 00:12:40 2010 (r5799) @@ -138,7 +138,7 @@ } -#endif /* CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2*/ +#endif /* CONFIG_TSC_CALIBRATE_WITH_IO */ void init_timer(void) { From marcj303 at gmail.com Fri Sep 10 00:45:37 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 9 Sep 2010 16:45:37 -0600 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp Message-ID: Now that we have addressed the CAR/MMIO ROM copy issue (thanks Scott and Arne), I wanted to revisit the other change that Arne proposed for memset. http://article.gmane.org/gmane.linux.bios/57707 Some people didn't like the architecture specific code for memset. I don't have a problem with it, but it did bring up a few questions. 1. Why isn't gcc generating the rep stosb itself? This should be a standard optimization. 2. Why do we have functions for memset, memcpy, etc, when gcc has builtins that could be used? Is this a remnant from romcc? Marc -- http://se-eng.com From c-d.hailfinger.devel.2006 at gmx.net Fri Sep 10 01:10:17 2010 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 10 Sep 2010 01:10:17 +0200 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: References: Message-ID: <4C896959.9080300@gmx.net> On 10.09.2010 00:45, Marc Jones wrote: > Now that we have addressed the CAR/MMIO ROM copy issue (thanks Scott > and Arne), I wanted to revisit the other change that Arne proposed for > memset. > > http://article.gmane.org/gmane.linux.bios/57707 > > Some people didn't like the architecture specific code for memset. I > don't have a problem with it, but it did bring up a few questions. > > 1. Why isn't gcc generating the rep stosb itself? This should be a > standard optimization. > > 2. Why do we have functions for memset, memcpy, etc, when gcc has > builtins that could be used? Is this a remnant from romcc? > Please note that the AMD and Intel manuals explicitly mention that some instructions which would be used by a fast memcpy will bypass the cache, and as such are unsuitable to copy CAR contents to RAM. Regards, Carl-Daniel -- http://www.hailfinger.org/ From scott at notabs.org Fri Sep 10 03:30:02 2010 From: scott at notabs.org (Scott Duplichan) Date: Thu, 9 Sep 2010 20:30:02 -0500 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: <4C896959.9080300@gmx.net> References: <4C896959.9080300@gmx.net> Message-ID: <9617B27123C44F56A182F911336057BC@m3a78> -----Original Message----- From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Thursday, September 09, 2010 06:10 PM To: Marc Jones Cc: Coreboot Subject: Re: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp ]On 10.09.2010 00:45, Marc Jones wrote: ]> Now that we have addressed the CAR/MMIO ROM copy issue (thanks Scott ]> and Arne), I wanted to revisit the other change that Arne proposed for ]> memset. ]> ]> http://article.gmane.org/gmane.linux.bios/57707 ]> ]> Some people didn't like the architecture specific code for memset. I ]> don't have a problem with it, but it did bring up a few questions. ]> ]> 1. Why isn't gcc generating the rep stosb itself? This should be a ]> standard optimization. ]> ]> 2. Why do we have functions for memset, memcpy, etc, when gcc has ]> builtins that could be used? Is this a remnant from romcc? ]> ] ]Please note that the AMD and Intel manuals explicitly mention that some ]instructions which would be used by a fast memcpy will bypass the cache, ]and as such are unsuitable to copy CAR contents to RAM. Another area to watch for when using optimized memory functions is SMI handling code. The processor saves most registers before running SMI code, but not the XMM registers. ]Regards, ]Carl-Daniel ] ]-- ]http://www.hailfinger.org/ Here are some benchmark results for an AMD family 10h desktop processor. This system uses DDR-2. This shows that for AMD processors rep movs and rep stos performance is not great, though better than a byte loop. Note that this test is for operations on large blocks. For small blocks rep or byte loop is probably best due to less setup overhead. ======= dram, memset, aligned data ======= rep stos 3,614 MB/s optimized memset 6,220 MB/s compiler memset 3,622 MB/s byte loop memset 871 MB/s ======= dram, memset, unaligned data ======= rep stos 3,101 MB/s optimized memset 6,229 MB/s compiler memset 3,621 MB/s byte loop memset 871 MB/s ======= dram, memcpy, aligned data ======= rep movs 1,754 MB/s optimized memcpy 3,979 MB/s compiler memcpy 1,865 MB/s unaligned xmm method 1 2,293 MB/s byte loop memcpy 855 MB/s aligned NT xmm unrolled 4 3,233 MB/s aligned NT xmm 2,924 MB/s aligned NT xmm unrolled 4 reverse 3,235 MB/s aligned NT xmm unrolled 4 prefetch 3,965 MB/s aligned NT xmm unrolled 8 3,217 MB/s aligned NT xmm unrolled 8 reverse 2,641 MB/s aligned NT xmm unrolled 8 prefetch 3,954 MB/s aligned NT xmm unrolled 16 2,920 MB/s aligned NT xmm unrolled 16 prefetch 3,861 MB/s ======= dram, memcpy, unaligned data ======= rep movs 1,509 MB/s optimized memcpy 3,997 MB/s compiler memcpy 1,628 MB/s unaligned xmm method 1 2,242 MB/s byte loop memcpy 854 MB/s In this report: http://article.gmane.org/gmane.linux.bios/57707, Arne may have been encountering the ClLinesToNbDis issue (assuming the memset code was running from flash). Switching to rep movs would greatly improve performance because unlike a byte loop, rep movs loops in microcode which does not cause continuous flash memory accesses. Thanks, Scott From marcj303 at gmail.com Fri Sep 10 05:49:38 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 9 Sep 2010 21:49:38 -0600 Subject: [coreboot] [patch] fintek f71859 sio Message-ID: I couldn't find any docs, but this gets the serial port to work. Signed-off-by: Marc Jones Marc -- http://se-eng.com -------------- next part -------------- A non-text attachment was scrubbed... Name: f71859.patch Type: application/octet-stream Size: 9903 bytes Desc: not available URL: From juhe at iki.fi Fri Sep 10 08:36:18 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Fri, 10 Sep 2010 09:36:18 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> Message-ID: <4C89D1E2.9060707@iki.fi> 9.9.2010 22:39, Myles Watson kirjoitti: >> There are now three smaller patches attached: > Much nicer! Thanks. > >> (1) Changes specific to this board. Fairly small changes from AMD >> Tilapia. Requires (2) to work. > > From your mainboard's Kconfig: > > +config DIMM_SUPPORT > + hex > + default 0x0004 > + depends on CPU_AMD_SOCKET_AM3 > > This really worries me. You shouldn't need to change the type of memory on > the Socket. I looked at your board online, and they suggest that your board > supports socket AM2, AM2+, and AM3. That seems like it breaks our model. I > thought AM2 was DDR2 and AM3 was DDR3. Sorry to break your design, but that was what I had to do to get the RAM working. I can confirm that I am using DDR2 memory and the CPU is this: http://products.amd.com/en-na/DesktopCPUDetail.aspx?id=615 > In general, the fewer changes the better! I agree. The patches could be smaller and neater. However, I cannot hold on to this board for arbitrarily long, since I should put it to production use now that Coreboot is working. I will see what I can do to reduce these patches further, if I just find a suitable slot of time. Best regards, Juhana Helovuo From uwe at hermann-uwe.de Fri Sep 10 09:26:08 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 10 Sep 2010 09:26:08 +0200 Subject: [coreboot] [patch] fintek f71859 sio In-Reply-To: References: Message-ID: <20100910072608.GB3256@greenwood> Hi, On Thu, Sep 09, 2010 at 09:49:38PM -0600, Marc Jones wrote: > Index: src/superio/fintek/Kconfig > =================================================================== > --- src/superio/fintek/Kconfig (revision 5799) > +++ src/superio/fintek/Kconfig (working copy) > @@ -2,3 +2,5 @@ > bool > config SUPERIO_FINTEK_F71863FG > bool > +config SUPERIO_FINTEK_F71859 > + bool > Index: src/superio/fintek/f71859/f71859_early_serial.c > =================================================================== > --- src/superio/fintek/f71859/f71859_early_serial.c (revision 0) > +++ src/superio/fintek/f71859/f71859_early_serial.c (revision 0) > @@ -0,0 +1,46 @@ > +/* > + * This file is part of the coreboot project. > + * > + * Copyright (C) 2007 Corey Osgood You can make all those files * Copyright (C) 2010 Marc Jones as each of them is trivial and cannot really be written differently. > +/* Pre-RAM driver for the Fintek F71805F/FG Super I/O chip. */ ^^^^^^^^^^ F71859 Does your chip have an "F" suffix in the name as the above ones? If yes, please add it to the name in the code/comments and file/directory names. > Property changes on: src/superio/fintek/f71859/f71859_early_serial.c > ___________________________________________________________________ > Added: svn:executable > + * Please drop the executable property from all files, it's incorrect and not needed. > +/* This chip doesn't have keyboard and mouse support. */ Should probably be dropped unless you are sure the chip doesn't have keyboard/mouse support. > +/* > + * Datasheet: > + > + */ Can be dropped. With the above changes: Signed-off-by: Uwe Hermann Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From uwe at hermann-uwe.de Fri Sep 10 09:34:51 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 10 Sep 2010 09:34:51 +0200 Subject: [coreboot] openbiosprog-spi - Open Hardware / Free Software USB-based SPI chip programmer Message-ID: <20100910073451.GC3256@greenwood> Hi, just a quick announcement I totally forgot to send out to the probably most relevant places (coreboot + flashrom) about a little hardware project I have finished a while ago: openbiosprog-spi. It's a USB-based SPI chip flasher hardware based on the FTDI FT2232H chip, all the gory details (including lots of photos) are at: http://randomprojects.org/wiki/Openbiosprog-spi http://hermann-uwe.de/blog/openbiosprog-spi-a-diy-open-hardware-and-free-software-usb-based-spi-bios-chip-flasher-using-flashrom The device is already supported by flashrom out of the box. It has a small DIP-8 socket to allow flashing DIP-8 SPI chips from newer mainboards externally (if they're in a socket). As an alternative you can also solder an 8-pin pin-header instead of the socket in order to connect to a soldered SO-8 chip on a mainboard directly using some wires. The hardware schematics and layouts were done using the open-source Kicad suite and they're CC-BY-SA 3.0 licensed. All hardware files are available from here: git clone git://gitorious.org/openbiosprog/openbiosprog-spi.git Flashrom usage of the device looks like this: flashrom -p ft2232_spi:type=2232H,port=A -w foo.bin Have fun, Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From arne.gleditsch at numascale.com Fri Sep 10 11:17:21 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Fri, 10 Sep 2010 11:17:21 +0200 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: (Myles Watson's message of "Thu, 9 Sep 2010 09:23:24 -0600") References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> <874odztlt7.fsf@taniquetil.gledits.ch> Message-ID: <87fwxix8im.fsf@taniquetil.gledits.ch> Myles Watson writes: > - > - RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, > + /* The following operation hangs when performed via MMCFG: > + pci_read_config32(romcc): 00010000:0078: 20040000 > + setup_resource_map_x_offset: 10000, 78: 20040000 > + pci_write_config32(romcc): 00010000:0078: 19040000 > + (hang) > + Response missing? */ > + /* RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, */ > > I forgot to ask if you'd tried setting the SyncOnWdError bit (20) in > function 3, register 0x44. That could help further debug this > problem. For me it caused a reboot instead of a hang when there was a > response missing. Bit 21 could also be helpful. I can have a look. I won't get a chance until Monday, though. > Since we don't have the chipset documentation, it makes me a little > worried to leave out one of the settings. Maybe we could use non > MMCONF writes for that setting. We could fall back to that, if we want to keep it. FWIW, Ed Swierk had some input on the semantics of this register the last time this came up: http://thread.gmane.org/gmane.linux.bios/57708/focus=59900 -- Arne. From crisoagf at gmail.com Fri Sep 10 13:30:30 2010 From: crisoagf at gmail.com (=?ISO-8859-1?Q?Crist=F3v=E3o_Gomes_Ferreira?=) Date: Fri, 10 Sep 2010 12:30:30 +0100 Subject: [coreboot] Gigabyte GA-6BXE: Missing ACPI support! Message-ID: Hi all! This is my first message to the coreboot mailing list, so I'd like to thank the developers for the excellent job you've done. I'm writing because, although coreboot does work on my board (a Gigabyte GA-6BXE), ACPI doesn't work, and I'd like to help, not being a programmer. What information can I send that can help you? -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Sep 10 15:23:29 2010 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 10 Sep 2010 15:23:29 +0200 Subject: [coreboot] coreboot/flashrom flyers (PDF) needed for FrOSCamp Message-ID: <4C8A3151.6020601@gmx.net> Hi, coreboot and flashrom got a nice booth at the FrOSCamp expo at ETH Zurich (Switzerland) Sept. 17-18 2010. It is sort of a Swiss FOSDEM, and FUDCon EMEA will be in the same place so there will be lots of interesting people to meet. http://wiki.froscamp.org/Welcome Not only do we have a nice and spacious booth, I even got two slots to talk about coreboot and flashrom on Saturday. If you have any coreboot/flashrom related flyers/posters in PDF/PS/... format, please send them to me ASAP so I can make sure they can be printed in time. Peter, I think you once created awesome flyers for coreboot. I'd love to reprint them and distribute them amongst FrOSCamp visitors. I would also appreciate PDFs of coreboot related talks. I do have my own slides for a coreboot introduction, but it's always a good idea to cross-check them against other presentations to make sure I don't forget anything. Regards, Carl-Daniel From anders at jenbo.dk Fri Sep 10 16:56:34 2010 From: anders at jenbo.dk (=?utf-8?B?YW5kZXJzQGplbmJvLmRr?=) Date: Fri, 10 Sep 2010 16:56:34 +0200 Subject: [coreboot] =?utf-8?q?Gigabyte_GA-6BXE=3A_Missing_ACPI_support!?= Message-ID: Hi I did the port to support this board, but I have no experience with ACPI and.still need to port it to CAR first. I was also hoping to at some point fix the ps2 mouse and parallel port although they are low on my priority list. Sadly I'm totally striped of time du to my new job and working on Ubuntu. If some one could help guide me on the way to car and where to start with implementing ACPI it would be much appreciated. - Anders ----- Reply message ----- Fra: "Crist?v?o Gomes Ferreira" Dato: fre., sep. 10, 2010 13:30 Emne: [coreboot] Gigabyte GA-6BXE: Missing ACPI support! Til: Hi all! This is my first message to the coreboot mailing list, so I'd like to thank the developers for the excellent job you've done. I'm writing because, although coreboot does work on my board (a Gigabyte GA-6BXE), ACPI doesn't work, and I'd like to help, not being a programmer. What information can I send that can help you? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcj303 at gmail.com Fri Sep 10 17:30:09 2010 From: marcj303 at gmail.com (Marc Jones) Date: Fri, 10 Sep 2010 09:30:09 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> Message-ID: On Thu, Sep 9, 2010 at 1:39 PM, Myles Watson wrote: >> There are now three smaller patches attached: > Much nicer! ?Thanks. > >> (1) Changes specific to this board. Fairly small changes from AMD >> Tilapia. Requires (2) to work. > > From your mainboard's Kconfig: > > +config DIMM_SUPPORT > + ? ? ? hex > + ? ? ? default 0x0004 > + ? ? ? depends on CPU_AMD_SOCKET_AM3 > > This really worries me. ?You shouldn't need to change the type of memory on > the Socket. ?I looked at your board online, and they suggest that your board > supports socket AM2, AM2+, and AM3. ?That seems like it breaks our model. ?I > thought AM2 was DDR2 and AM3 was DDR3. That used to be true, but you can have AM3(AM2+) with DDR2, as with this board. Yeah, thanks AMD..... :) Connecting the socket to the memory type was convenient, but I was never really comfortable with it. It may be time to disconnect them. Marc -- http://se-eng.com From mylesgw at gmail.com Fri Sep 10 17:49:39 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 10 Sep 2010 09:49:39 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> Message-ID: On Fri, Sep 10, 2010 at 9:30 AM, Marc Jones wrote: > On Thu, Sep 9, 2010 at 1:39 PM, Myles Watson wrote: >>> There are now three smaller patches attached: >> Much nicer! ?Thanks. >> >>> (1) Changes specific to this board. Fairly small changes from AMD >>> Tilapia. Requires (2) to work. >> >> From your mainboard's Kconfig: >> >> +config DIMM_SUPPORT >> + ? ? ? hex >> + ? ? ? default 0x0004 >> + ? ? ? depends on CPU_AMD_SOCKET_AM3 >> >> This really worries me. ?You shouldn't need to change the type of memory on >> the Socket. ?I looked at your board online, and they suggest that your board >> supports socket AM2, AM2+, and AM3. ?That seems like it breaks our model. ?I >> thought AM2 was DDR2 and AM3 was DDR3. > > That used to be true, but you can have AM3(AM2+) with DDR2, as with > this board. Yeah, thanks AMD..... :) Connecting the socket to the > memory type was convenient, but I was never really comfortable with > it. It may be time to disconnect them. Thanks Marc. I didn't realize that we'd gotten ourselves into a mess there. Thanks, Myles From mylesgw at gmail.com Fri Sep 10 17:54:27 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 10 Sep 2010 09:54:27 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <4C89D1E2.9060707@iki.fi> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> Message-ID: >> ?From your mainboard's Kconfig: >> >> +config DIMM_SUPPORT >> + ? ? ? hex >> + ? ? ? default 0x0004 >> + ? ? ? depends on CPU_AMD_SOCKET_AM3 >> >> This really worries me. ?You shouldn't need to change the type of memory >> on >> the Socket. ?I looked at your board online, and they suggest that your >> board >> supports socket AM2, AM2+, and AM3. ?That seems like it breaks our model. >> ?I >> thought AM2 was DDR2 and AM3 was DDR3. > > Sorry to break your design, but that was what I had to do to get the RAM > working. I wasn't offended. I just want to improve the design if it's broken. > I can confirm that I am using DDR2 memory and the CPU is this: > > http://products.amd.com/en-na/DesktopCPUDetail.aspx?id=615 Thanks. >> In general, the fewer changes the better! > > I agree. The patches could be smaller and neater. > > However, I cannot hold on to this board for arbitrarily long, since I should > put it to production use now that Coreboot is working. ?I will see what I > can do to reduce these patches further, if I just find a suitable slot of > time. I appreciate the work that you've done. I've attached patches that I've reduced a little more. Would you test/review them? If they work, I'll commit them. Signed-off-by: Myles Watson Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: asus-m4a785m-small-patch.patch Type: text/x-diff Size: 17306 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: generic-code-patches-for-m4a785m.patch Type: text/x-diff Size: 1606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: multiboot-table-after-cb-table-r5756-v2.patch Type: text/x-diff Size: 6299 bytes Desc: not available URL: From mylesgw at gmail.com Fri Sep 10 18:58:31 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 10 Sep 2010 10:58:31 -0600 Subject: [coreboot] Sockets and DIMM_SUPPORT Message-ID: Separate sockets from RAM for some sockets. Checked with abuild -C. Signed-off-by: Myles Watson Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: amd_sockets.diff Type: text/x-diff Size: 16163 bytes Desc: not available URL: From mylesgw at gmail.com Fri Sep 10 20:16:37 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 10 Sep 2010 12:16:37 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> Message-ID: Would you mind applying these and testing too? Signed-off-by: Myles Watson Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: uma.diff Type: text/x-diff Size: 2456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: reserved.diff Type: text/x-diff Size: 2809 bytes Desc: not available URL: From peter at stuge.se Fri Sep 10 20:18:25 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 10 Sep 2010 20:18:25 +0200 Subject: [coreboot] Sockets and DIMM_SUPPORT In-Reply-To: References: Message-ID: <20100910181826.1247.qmail@stuge.se> Myles Watson wrote: > Separate sockets from RAM for some sockets. > > Checked with abuild -C. > > Signed-off-by: Myles Watson > +++ svn/src/northbridge/amd/amdfam10/Kconfig .. > +config DIMM_FBDIMM > +config DIMM_DDR2 > +config DIMM_DDR3 > +config DIMM_REGISTERED Great! > +if DIMM_FB_DIMM > + config DIMM_SUPPORT > + hex > + default 0x0110 > +endif > + > +if DIMM_DDR2 > + if DIMM_REGISTERED > + config DIMM_SUPPORT > + hex > + default 0x0104 > + endif > + > + if !DIMM_REGISTERED > + config DIMM_SUPPORT > + hex > + default 0x0004 > + endif > +endif I'd prefer if this logic was in code rather than Kconfig though. Acked-by: Peter Stuge From svn at coreboot.org Fri Sep 10 20:33:24 2010 From: svn at coreboot.org (repository service) Date: Fri, 10 Sep 2010 20:33:24 +0200 Subject: [coreboot] [commit] r5800 - in trunk/src: cpu/amd/socket_AM2 cpu/amd/socket_AM2r2 cpu/amd/socket_AM3 cpu/amd/socket_ASB2 cpu/amd/socket_F cpu/amd/socket_F_1207 mainboard/amd/mahogany mainboard/amd/mahogany_fa... Message-ID: Author: myles Date: Fri Sep 10 20:33:24 2010 New Revision: 5800 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5800 Log: Move memory type information out of some AMD sockets. Signed-off-by: Myles Watson Acked-by: Peter Stuge Modified: trunk/src/cpu/amd/socket_AM2/Kconfig trunk/src/cpu/amd/socket_AM2r2/Kconfig trunk/src/cpu/amd/socket_AM3/Kconfig trunk/src/cpu/amd/socket_ASB2/Kconfig trunk/src/cpu/amd/socket_F/Kconfig trunk/src/cpu/amd/socket_F_1207/Kconfig trunk/src/mainboard/amd/mahogany/Kconfig trunk/src/mainboard/amd/mahogany_fam10/Kconfig trunk/src/mainboard/amd/pistachio/Kconfig trunk/src/mainboard/amd/serengeti_cheetah/Kconfig trunk/src/mainboard/amd/serengeti_cheetah_fam10/Kconfig trunk/src/mainboard/amd/tilapia_fam10/Kconfig trunk/src/mainboard/asus/m2v-mx_se/Kconfig trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig trunk/src/mainboard/gigabyte/m57sli/Kconfig trunk/src/mainboard/gigabyte/ma785gmt/Kconfig trunk/src/mainboard/gigabyte/ma78gm/Kconfig trunk/src/mainboard/hp/dl145_g3/Kconfig trunk/src/mainboard/jetway/pa78vm5/Kconfig trunk/src/mainboard/msi/ms7260/Kconfig trunk/src/mainboard/msi/ms9185/Kconfig trunk/src/mainboard/msi/ms9282/Kconfig trunk/src/mainboard/msi/ms9652_fam10/Kconfig trunk/src/mainboard/nvidia/l1_2pvv/Kconfig trunk/src/mainboard/supermicro/h8dme/Kconfig trunk/src/mainboard/supermicro/h8dmr/Kconfig trunk/src/mainboard/supermicro/h8dmr_fam10/Kconfig trunk/src/mainboard/supermicro/h8qme_fam10/Kconfig trunk/src/mainboard/tyan/s2912/Kconfig trunk/src/mainboard/tyan/s2912_fam10/Kconfig trunk/src/northbridge/amd/amdfam10/Kconfig trunk/src/northbridge/amd/amdk8/Kconfig Modified: trunk/src/cpu/amd/socket_AM2/Kconfig ============================================================================== --- trunk/src/cpu/amd/socket_AM2/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/cpu/amd/socket_AM2/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -10,9 +10,3 @@ default 0x11 depends on CPU_AMD_SOCKET_AM2 -# DDR2 and REG -config DIMM_SUPPORT - hex - default 0x0004 - depends on CPU_AMD_SOCKET_AM2 - Modified: trunk/src/cpu/amd/socket_AM2r2/Kconfig ============================================================================== --- trunk/src/cpu/amd/socket_AM2r2/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/cpu/amd/socket_AM2r2/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -9,12 +9,6 @@ default 0x11 depends on CPU_AMD_SOCKET_AM2R2 -# DDR2 and REG -config DIMM_SUPPORT - hex - default 0x0104 - depends on CPU_AMD_SOCKET_AM2R2 - config EXT_RT_TBL_SUPPORT bool default n Modified: trunk/src/cpu/amd/socket_AM3/Kconfig ============================================================================== --- trunk/src/cpu/amd/socket_AM3/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/cpu/amd/socket_AM3/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -9,12 +9,6 @@ default 0x11 depends on CPU_AMD_SOCKET_AM3 -# DDR3 and REG -config DIMM_SUPPORT - hex - default 0x0005 - depends on CPU_AMD_SOCKET_AM3 - config EXT_RT_TBL_SUPPORT bool default n Modified: trunk/src/cpu/amd/socket_ASB2/Kconfig ============================================================================== --- trunk/src/cpu/amd/socket_ASB2/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/cpu/amd/socket_ASB2/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -9,12 +9,6 @@ default 0x13 depends on CPU_AMD_SOCKET_ASB2 -# DDR3 and REG -config DIMM_SUPPORT - hex - default 0x0005 - depends on CPU_AMD_SOCKET_ASB2 - config EXT_RT_TBL_SUPPORT bool default n Modified: trunk/src/cpu/amd/socket_F/Kconfig ============================================================================== --- trunk/src/cpu/amd/socket_F/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/cpu/amd/socket_F/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -9,9 +9,3 @@ default 0x10 depends on CPU_AMD_SOCKET_F -# DDR2 and REG -config DIMM_SUPPORT - hex - default 0x0104 - depends on CPU_AMD_SOCKET_F - Modified: trunk/src/cpu/amd/socket_F_1207/Kconfig ============================================================================== --- trunk/src/cpu/amd/socket_F_1207/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/cpu/amd/socket_F_1207/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -8,12 +8,6 @@ default 0x10 depends on CPU_AMD_SOCKET_F_1207 -# DDR2 and REG -config DIMM_SUPPORT - hex - default 0x0104 - depends on CPU_AMD_SOCKET_F_1207 - config EXT_RT_TBL_SUPPORT bool default n Modified: trunk/src/mainboard/amd/mahogany/Kconfig ============================================================================== --- trunk/src/mainboard/amd/mahogany/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/amd/mahogany/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,7 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2 + select DIMM_DDR2 select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_AMD_RS780 Modified: trunk/src/mainboard/amd/mahogany_fam10/Kconfig ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/amd/mahogany_fam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2R2 + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_RS780 select SOUTHBRIDGE_AMD_SB700 Modified: trunk/src/mainboard/amd/pistachio/Kconfig ============================================================================== --- trunk/src/mainboard/amd/pistachio/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/amd/pistachio/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,7 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2 + select DIMM_DDR2 select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_AMD_RS690 Modified: trunk/src/mainboard/amd/serengeti_cheetah/Kconfig ============================================================================== --- trunk/src/mainboard/amd/serengeti_cheetah/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/amd/serengeti_cheetah/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_AMD_AMD8111 Modified: trunk/src/mainboard/amd/serengeti_cheetah_fam10/Kconfig ============================================================================== --- trunk/src/mainboard/amd/serengeti_cheetah_fam10/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/amd/serengeti_cheetah_fam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F_1207 + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_AMD8111 select SOUTHBRIDGE_AMD_AMD8132 Modified: trunk/src/mainboard/amd/tilapia_fam10/Kconfig ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/amd/tilapia_fam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM3 + select DIMM_DDR3 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_RS780 select SOUTHBRIDGE_AMD_SB700 Modified: trunk/src/mainboard/asus/m2v-mx_se/Kconfig ============================================================================== --- trunk/src/mainboard/asus/m2v-mx_se/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/asus/m2v-mx_se/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -22,6 +22,7 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2 + select DIMM_DDR2 select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_VIA_VT8237R Modified: trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig ============================================================================== --- trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,7 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2 + select DIMM_DDR2 select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_SIS_SIS966 Modified: trunk/src/mainboard/gigabyte/m57sli/Kconfig ============================================================================== --- trunk/src/mainboard/gigabyte/m57sli/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/gigabyte/m57sli/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,7 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2 + select DIMM_DDR2 select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_NVIDIA_MCP55 Modified: trunk/src/mainboard/gigabyte/ma785gmt/Kconfig ============================================================================== --- trunk/src/mainboard/gigabyte/ma785gmt/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/gigabyte/ma785gmt/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM3 + select DIMM_DDR3 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_RS780 select SOUTHBRIDGE_AMD_SB700 Modified: trunk/src/mainboard/gigabyte/ma78gm/Kconfig ============================================================================== --- trunk/src/mainboard/gigabyte/ma78gm/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/gigabyte/ma78gm/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2R2 + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_RS780 select SOUTHBRIDGE_AMD_SB700 Modified: trunk/src/mainboard/hp/dl145_g3/Kconfig ============================================================================== --- trunk/src/mainboard/hp/dl145_g3/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/hp/dl145_g3/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_BROADCOM_BCM21000 Modified: trunk/src/mainboard/jetway/pa78vm5/Kconfig ============================================================================== --- trunk/src/mainboard/jetway/pa78vm5/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/jetway/pa78vm5/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2R2 + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_RS780 select SOUTHBRIDGE_AMD_SB700 Modified: trunk/src/mainboard/msi/ms7260/Kconfig ============================================================================== --- trunk/src/mainboard/msi/ms7260/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/msi/ms7260/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,7 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM2 + select DIMM_DDR2 select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_NVIDIA_MCP55 Modified: trunk/src/mainboard/msi/ms9185/Kconfig ============================================================================== --- trunk/src/mainboard/msi/ms9185/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/msi/ms9185/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_BROADCOM_BCM5780 Modified: trunk/src/mainboard/msi/ms9282/Kconfig ============================================================================== --- trunk/src/mainboard/msi/ms9282/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/msi/ms9282/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_NVIDIA_MCP55 Modified: trunk/src/mainboard/msi/ms9652_fam10/Kconfig ============================================================================== --- trunk/src/mainboard/msi/ms9652_fam10/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/msi/ms9652_fam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F_1207 + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_NVIDIA_MCP55 select SUPERIO_WINBOND_W83627EHG Modified: trunk/src/mainboard/nvidia/l1_2pvv/Kconfig ============================================================================== --- trunk/src/mainboard/nvidia/l1_2pvv/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/nvidia/l1_2pvv/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_NVIDIA_MCP55 Modified: trunk/src/mainboard/supermicro/h8dme/Kconfig ============================================================================== --- trunk/src/mainboard/supermicro/h8dme/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/supermicro/h8dme/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_NVIDIA_MCP55 Modified: trunk/src/mainboard/supermicro/h8dmr/Kconfig ============================================================================== --- trunk/src/mainboard/supermicro/h8dmr/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/supermicro/h8dmr/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_NVIDIA_MCP55 Modified: trunk/src/mainboard/supermicro/h8dmr_fam10/Kconfig ============================================================================== --- trunk/src/mainboard/supermicro/h8dmr_fam10/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/supermicro/h8dmr_fam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F_1207 + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_NVIDIA_MCP55 select SUPERIO_WINBOND_W83627HF Modified: trunk/src/mainboard/supermicro/h8qme_fam10/Kconfig ============================================================================== --- trunk/src/mainboard/supermicro/h8qme_fam10/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/supermicro/h8qme_fam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F_1207 + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_AMD8132 select SOUTHBRIDGE_NVIDIA_MCP55 Modified: trunk/src/mainboard/tyan/s2912/Kconfig ============================================================================== --- trunk/src/mainboard/tyan/s2912/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/tyan/s2912/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_NVIDIA_MCP55 Modified: trunk/src/mainboard/tyan/s2912_fam10/Kconfig ============================================================================== --- trunk/src/mainboard/tyan/s2912_fam10/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/mainboard/tyan/s2912_fam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -4,6 +4,8 @@ def_bool y select ARCH_X86 select CPU_AMD_SOCKET_F_1207 + select DIMM_DDR2 + select DIMM_REGISTERED select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_NVIDIA_MCP55 select SUPERIO_WINBOND_W83627HF Modified: trunk/src/northbridge/amd/amdfam10/Kconfig ============================================================================== --- trunk/src/northbridge/amd/amdfam10/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/northbridge/amd/amdfam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -75,4 +75,52 @@ default n depends on NORTHBRIDGE_AMD_AMDFAM10 +config DIMM_FBDIMM + bool + default n + depends on NORTHBRIDGE_AMD_AMDFAM10 + +config DIMM_DDR2 + bool + default n + depends on NORTHBRIDGE_AMD_AMDFAM10 + +config DIMM_DDR3 + bool + default n + depends on NORTHBRIDGE_AMD_AMDFAM10 + +config DIMM_REGISTERED + bool + default n + depends on NORTHBRIDGE_AMD_AMDFAM10 + +if DIMM_FB_DIMM + config DIMM_SUPPORT + hex + default 0x0110 +endif + +if DIMM_DDR2 + if DIMM_REGISTERED + config DIMM_SUPPORT + hex + default 0x0104 + endif + + if !DIMM_REGISTERED + config DIMM_SUPPORT + hex + default 0x0004 + endif +endif + +if DIMM_DDR3 + if DIMM_REGISTERED + config DIMM_SUPPORT + hex + default 0x0005 + endif +endif + source src/northbridge/amd/amdfam10/root_complex/Kconfig Modified: trunk/src/northbridge/amd/amdk8/Kconfig ============================================================================== --- trunk/src/northbridge/amd/amdk8/Kconfig Fri Sep 10 00:12:40 2010 (r5799) +++ trunk/src/northbridge/amd/amdk8/Kconfig Fri Sep 10 20:33:24 2010 (r5800) @@ -53,4 +53,28 @@ default n depends on NORTHBRIDGE_AMD_AMDK8 +config DIMM_DDR2 + bool + default n + depends on NORTHBRIDGE_AMD_AMDFAM10 + +config DIMM_REGISTERED + bool + default n + depends on NORTHBRIDGE_AMD_AMDFAM10 + +if DIMM_DDR2 + if DIMM_REGISTERED + config DIMM_SUPPORT + hex + default 0x0104 + endif + + if !DIMM_REGISTERED + config DIMM_SUPPORT + hex + default 0x0004 + endif +endif + source src/northbridge/amd/amdk8/root_complex/Kconfig From mylesgw at gmail.com Fri Sep 10 20:36:02 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 10 Sep 2010 12:36:02 -0600 Subject: [coreboot] Sockets and DIMM_SUPPORT In-Reply-To: <20100910181826.1247.qmail@stuge.se> References: <20100910181826.1247.qmail@stuge.se> Message-ID: On Fri, Sep 10, 2010 at 12:18 PM, Peter Stuge wrote: > Myles Watson wrote: >> Separate sockets from RAM for some sockets. >> >> Checked with abuild -C. >> >> Signed-off-by: Myles Watson > >> +++ svn/src/northbridge/amd/amdfam10/Kconfig > .. >> +config DIMM_FBDIMM >> +config DIMM_DDR2 >> +config DIMM_DDR3 >> +config DIMM_REGISTERED > > Great! > > >> +if DIMM_FB_DIMM >> + ? ? config DIMM_SUPPORT >> + ? ? ? ? ? ? hex >> + ? ? ? ? ? ? default 0x0110 >> +endif >> + >> +if DIMM_DDR2 >> + ? ? if DIMM_REGISTERED >> + ? ? config DIMM_SUPPORT >> + ? ? ? ? ? ? hex >> + ? ? ? ? ? ? default 0x0104 >> + ? ? endif >> + >> + ? ? if !DIMM_REGISTERED >> + ? ? config DIMM_SUPPORT >> + ? ? ? ? ? ? hex >> + ? ? ? ? ? ? default 0x0004 >> + ? ? endif >> +endif > > I'd prefer if this logic was in code rather than Kconfig though. I agree. I thought this was a good intermediate step. There are some memory types that don't seem to fit the pattern very well. I'm not familiar with the fam10 RAM initialization code, and didn't want to break anything. > Acked-by: Peter Stuge Rev 5800. Thanks, Myles From peter at stuge.se Fri Sep 10 23:23:21 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 10 Sep 2010 23:23:21 +0200 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: <9617B27123C44F56A182F911336057BC@m3a78> References: <4C896959.9080300@gmx.net> <9617B27123C44F56A182F911336057BC@m3a78> Message-ID: <20100910212321.30730.qmail@stuge.se> Scott Duplichan wrote: > for AMD processors rep movs and rep stos performance is not great, > though better than a byte loop. Intel 386-Pentium is when I last did performance critical code like this. 32-bit mov,mov,add,add,dec ecx,jnz was the standard back then. rep for size optimization, but not performance. //Peter From peter at stuge.se Fri Sep 10 23:37:52 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 10 Sep 2010 23:37:52 +0200 Subject: [coreboot] [PATCH] LiPPERT Hurricane-LX support In-Reply-To: <4C891183.6090805@LiPPERTEmbedded.de> References: <4C891183.6090805@LiPPERTEmbedded.de> Message-ID: <20100910213753.32543.qmail@stuge.se> Jens Rottmann wrote: > Kindly 'svn copy' src/mainboard/lippert/spacerunner-lx to > src/mainboard/lippert/hurricane-lx before applying. > > Cheers, > Jens > Add support for LiPPERT Hurricane-LX (EPIC board with AMD Geode-LX, > CS5536, ITE IT8712F). Board support is based on the SpaceRunner-LX > (with tiny bits from the RoadRunner-LX) even though the hardware really > was the ancestor of our three other -LX boards and in fact among the > earliest Geode-LX boards on the market. (Might even have been the first > Geode-LX EPIC?) > > Signed-off-by: Jens Rottmann Acked-by: Peter Stuge (Someone please commit, I'm away from a working tree atm.) //Peter From svn at coreboot.org Fri Sep 10 23:51:34 2010 From: svn at coreboot.org (repository service) Date: Fri, 10 Sep 2010 23:51:34 +0200 Subject: [coreboot] [commit] r5801 - in trunk/src/mainboard/lippert: . hurricane-lx Message-ID: Author: myles Date: Fri Sep 10 23:51:34 2010 New Revision: 5801 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5801 Log: Add support for LiPPERT Hurricane-LX (EPIC board with AMD Geode-LX, CS5536, ITE IT8712F). Board support is based on the SpaceRunner-LX (with tiny bits from the RoadRunner-LX) even though the hardware really was the ancestor of our three other -LX boards and in fact among the earliest Geode-LX boards on the market. (Might even have been the first Geode-LX EPIC?) Signed-off-by: Jens Rottmann Acked-by: Peter Stuge Added: trunk/src/mainboard/lippert/hurricane-lx/ - copied from r5792, trunk/src/mainboard/lippert/spacerunner-lx/ Modified: trunk/src/mainboard/lippert/Kconfig trunk/src/mainboard/lippert/hurricane-lx/Kconfig trunk/src/mainboard/lippert/hurricane-lx/chip.h trunk/src/mainboard/lippert/hurricane-lx/devicetree.cb trunk/src/mainboard/lippert/hurricane-lx/irq_tables.c trunk/src/mainboard/lippert/hurricane-lx/mainboard.c trunk/src/mainboard/lippert/hurricane-lx/romstage.c Modified: trunk/src/mainboard/lippert/Kconfig ============================================================================== --- trunk/src/mainboard/lippert/Kconfig Fri Sep 10 20:33:24 2010 (r5800) +++ trunk/src/mainboard/lippert/Kconfig Fri Sep 10 23:51:34 2010 (r5801) @@ -5,6 +5,8 @@ config BOARD_LIPPERT_FRONTRUNNER bool "Cool Frontrunner" +config BOARD_LIPPERT_HURRICANE_LX + bool "Hurricane-LX" config BOARD_LIPPERT_LITERUNNER_LX bool "Cool LiteRunner-LX" config BOARD_LIPPERT_ROADRUNNER_LX @@ -15,6 +17,7 @@ endchoice source "src/mainboard/lippert/frontrunner/Kconfig" +source "src/mainboard/lippert/hurricane-lx/Kconfig" source "src/mainboard/lippert/literunner-lx/Kconfig" source "src/mainboard/lippert/roadrunner-lx/Kconfig" source "src/mainboard/lippert/spacerunner-lx/Kconfig" Modified: trunk/src/mainboard/lippert/hurricane-lx/Kconfig ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/Kconfig Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/lippert/hurricane-lx/Kconfig Fri Sep 10 23:51:34 2010 (r5801) @@ -1,4 +1,4 @@ -if BOARD_LIPPERT_SPACERUNNER_LX +if BOARD_LIPPERT_HURRICANE_LX config BOARD_SPECIFIC_OPTIONS # dummy def_bool y @@ -7,7 +7,6 @@ select NORTHBRIDGE_AMD_LX select SOUTHBRIDGE_AMD_CS5536 select SUPERIO_ITE_IT8712F - select HAVE_DEBUG_SMBUS select HAVE_PIRQ_TABLE select PIRQ_ROUTE select UDELAY_TSC @@ -18,15 +17,23 @@ config MAINBOARD_DIR string - default lippert/spacerunner-lx + default lippert/hurricane-lx config MAINBOARD_PART_NUMBER string - default "Cool SpaceRunner-LX" + default "Hurricane-LX" config IRQ_SLOT_COUNT int - default 7 + default 8 + +config BOARD_OLD_REVISION + bool "Board is old pre-3.0 revision" + default n + help + Look on the bottom side for a number like 406-0001-30. The last 2 + digits state the PCB revision (3.0 in this example). For 2.0 or older + boards choose Y, for 3.0 and newer say N. config ONBOARD_UARTS_RS485 bool "Switch on-board serial ports to RS485" @@ -35,10 +42,4 @@ If selected, both on-board serial ports will operate in RS485 mode instead of RS232. -config ONBOARD_IDE_SLAVE - bool "Make on-board SSD act as Slave" - default n - help - If selected, the on-board SSD will act as IDE Slave instead of Master. - -endif # BOARD_LIPPERT_SPACERUNNER_LX +endif # BOARD_LIPPERT_HURRICANE_LX Modified: trunk/src/mainboard/lippert/hurricane-lx/chip.h ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/chip.h Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/lippert/hurricane-lx/chip.h Fri Sep 10 23:51:34 2010 (r5801) @@ -1,7 +1,7 @@ /* * This file is part of the coreboot project. * - * Copyright (C) 2008 LiPPERT Embedded Computers GmbH + * Copyright (C) 2010 LiPPERT Embedded Computers GmbH * * 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 Modified: trunk/src/mainboard/lippert/hurricane-lx/devicetree.cb ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/devicetree.cb Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/lippert/hurricane-lx/devicetree.cb Fri Sep 10 23:51:34 2010 (r5801) @@ -21,17 +21,17 @@ register "com2_enable" = "0" register "com2_address" = "0x2E8" register "com2_irq" = "6" - register "unwanted_vpci[0]" = "0x80007B00" # Audio: 1<<31 + Device 0x0F<<11 + Function 3<<8 - register "unwanted_vpci[1]" = "0" # End of list has a zero + register "unwanted_vpci[0]" = "0" # End of list has a zero device pci 8.0 on end # Slot4 device pci 9.0 on end # Slot3 device pci a.0 on end # Slot2 device pci b.0 on end # Slot1 device pci c.0 on end # IT8888 + device pci d.0 on end # Mini-PCI device pci e.0 on end # Ethernet device pci f.0 on # ISA Bridge chip superio/ite/it8712f - device pnp 2e.0 off # Floppy + device pnp 2e.0 on # Floppy io 0x60 = 0x3f0 irq 0x70 = 6 drq 0x74 = 2 @@ -76,7 +76,7 @@ end end device pci f.2 on end # IDE - device pci f.3 off end # Audio + device pci f.3 on end # Audio device pci f.4 on end # OHCI device pci f.5 on end # EHCI end Modified: trunk/src/mainboard/lippert/hurricane-lx/irq_tables.c ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/irq_tables.c Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/lippert/hurricane-lx/irq_tables.c Fri Sep 10 23:51:34 2010 (r5801) @@ -1,7 +1,7 @@ /* * This file is part of the coreboot project. * - * Copyright (C) 2008 LiPPERT Embedded Computers GmbH + * Copyright (C) 2010 LiPPERT Embedded Computers GmbH * * 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 @@ -18,7 +18,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -/* Based on irq_tables.c from AMD's DB800 mainboard. */ +/* Based on irq_tables.c from the SpaceRunner-LX mainboard. */ #include #include @@ -55,17 +55,18 @@ 0x002B, /* Device */ 0, /* Crap (miniport) */ {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, /* u8 rfu[11] */ - 0xE0, /* u8 checksum, this has to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ + 0x36, /* u8 checksum, this has to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { /* If you change the number of entries, change the CONFIG_IRQ_SLOT_COUNT above! */ /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* CPU */ {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* chipset */ - {0x00, (0x0E << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* ethernet */ + {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* ethernet */ {0x00, (0x0B << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x1, 0x0}, /* slot1 */ {0x00, (0x0A << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x2, 0x0}, /* slot2 */ {0x00, (0x09 << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x3, 0x0}, /* slot3 */ {0x00, (0x08 << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x4, 0x0}, /* slot4 */ + {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}}, 0x5, 0x0}, /* Mini-PCI */ } }; Modified: trunk/src/mainboard/lippert/hurricane-lx/mainboard.c ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/mainboard.c Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/lippert/hurricane-lx/mainboard.c Fri Sep 10 23:51:34 2010 (r5801) @@ -1,7 +1,7 @@ /* * This file is part of the coreboot project. * - * Copyright (C) 2008 LiPPERT Embedded Computers GmbH + * Copyright (C) 2010 LiPPERT Embedded Computers GmbH * * 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 @@ -18,7 +18,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -/* Based on mainboard.c from AMD's DB800 mainboard. */ +/* Based on mainboard.c from the SpaceRunner-LX mainboard. */ #include #include @@ -29,16 +29,15 @@ #include #include "chip.h" -/* Bit0 turns off the Live LED, bit1 switches Com1 to RS485, bit2 same for Com2. */ +/* Bit1 switches Com1 to RS485, bit2 same for Com2. */ #if CONFIG_ONBOARD_UARTS_RS485 - #define SIO_GP1X_CONFIG 0x07 + #define SIO_GP1X_CONFIG 0x06 #else - #define SIO_GP1X_CONFIG 0x01 + #define SIO_GP1X_CONFIG 0x00 #endif static const u16 ec_init_table[] = { /* hi=data, lo=index */ 0x1900, /* Enable monitoring */ - 0x3050, /* VIN4,5 enabled */ 0x0351, /* TMPIN1,2 diode mode, TMPIN3 off */ 0x805C, /* Unlock zero adjust */ 0x7056, 0x3C57, /* Zero adjust TMPIN1,2 */ @@ -49,20 +48,22 @@ static void init(struct device *dev) { unsigned int gpio_base, i; - printk(BIOS_DEBUG, "LiPPERT SpaceRunner-LX ENTER %s\n", __func__); + printk(BIOS_DEBUG, "LiPPERT Hurricane-LX ENTER %s\n", __func__); /* Init CS5536 GPIOs */ gpio_base = pci_read_config32(dev_find_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA, 0), PCI_BASE_ADDRESS_1) - 1; outl(0x00000040, gpio_base + 0x00); // GPIO6 value 1 - LAN_PD# + outl(0x00000040, gpio_base + 0x08); // GPIO6 open drain 1 - LAN_PD# (jumpered GPIO per default) outl(0x00000040, gpio_base + 0x04); // GPIO6 output 1 - LAN_PD# - outl(0x04000000, gpio_base + 0x18); // GPIO10 pull up 0 - THRM_ALRM# outl(0x00000400, gpio_base + 0x34); // GPIO10 in aux1 1 - THRM_ALRM# outl(0x00000400, gpio_base + 0x20); // GPIO10 input 1 - THRM_ALRM# +#if !CONFIG_BOARD_OLD_REVISION outl(0x00000800, gpio_base + 0x94); // GPIO27 out aux2 1 - 32kHz outl(0x00000800, gpio_base + 0x84); // GPIO27 output 1 - 32kHz - outl(0x08000000, gpio_base + 0x98); // GPIO27 pull up 0 - 32kHz +#endif + outl(0x08000000, gpio_base + 0x98); // GPIO27 pull up 0 - 32kHz (new) / PM-LED (old) /* Init Environment Controller. */ for (i = 0; i < ARRAY_SIZE(ec_init_table); i++) { @@ -71,10 +72,10 @@ outb(val >> 8, 0x0296); } - /* bit2 = RS485_EN2, bit1 = RS485_EN1, bit0 = Live LED */ + /* bit2 = RS485_EN2, bit1 = RS485_EN1 */ outb(SIO_GP1X_CONFIG, 0x1220); /* Simple-I/O GP17-10 */ - printk(BIOS_DEBUG, "LiPPERT SpaceRunner-LX EXIT %s\n", __func__); + printk(BIOS_DEBUG, "LiPPERT Hurricane-LX EXIT %s\n", __func__); } static void enable_dev(struct device *dev) @@ -83,6 +84,6 @@ } struct chip_operations mainboard_ops = { - CHIP_NAME("LiPPERT SpaceRunner-LX Mainboard") + CHIP_NAME("LiPPERT Hurricane-LX Mainboard") .enable_dev = enable_dev, }; Modified: trunk/src/mainboard/lippert/hurricane-lx/romstage.c ============================================================================== --- trunk/src/mainboard/lippert/spacerunner-lx/romstage.c Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/lippert/hurricane-lx/romstage.c Fri Sep 10 23:51:34 2010 (r5801) @@ -2,7 +2,7 @@ * This file is part of the coreboot project. * * Copyright (C) 2007 Advanced Micro Devices, Inc. - * Copyright (C) 2008 LiPPERT Embedded Computers GmbH + * Copyright (C) 2010 LiPPERT Embedded Computers GmbH * * 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 @@ -19,11 +19,10 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -/* Based on romstage.c from AMD's DB800 and DBM690T mainboards. */ +/* Based on romstage.c from the SpaceRunner-LX mainboard. */ #include #include -#include #include #include #include @@ -40,66 +39,24 @@ #include "southbridge/amd/cs5536/cs5536_early_setup.c" #include "superio/ite/it8712f/it8712f_early_serial.c" -/* Bit0 enables Spread Spectrum, bit1 makes on-board SSD act as IDE slave. */ -#if CONFIG_ONBOARD_IDE_SLAVE - #define SMC_CONFIG 0x03 -#else - #define SMC_CONFIG 0x01 -#endif +/* Bit0 enables Spread Spectrum. */ +#define SMC_CONFIG 0x01 #define ManualConf 1 /* No automatic strapped PLL config */ -#define PLLMSRhi 0x0000059C /* Manual settings for the PLL */ +#define PLLMSRhi 0x0000049C /* Manual settings for the PLL */ #define PLLMSRlo 0x00DE6001 #define DIMM0 0xA0 #define DIMM1 0xA2 -static const unsigned char spdbytes[] = { // 4x Promos V58C2512164SA-J5I - 0xFF, 0xFF, // only values used by Geode-LX raminit.c are set - [SPD_MEMORY_TYPE] = SPD_MEMORY_TYPE_SDRAM_DDR, // (Fundamental) memory type - [SPD_NUM_ROWS] = 0x0D, // Number of row address bits [13] - [SPD_NUM_COLUMNS] = 0x0A, // Number of column address bits [10] - [SPD_NUM_DIMM_BANKS] = 1, // Number of module rows (banks) - 0xFF, 0xFF, 0xFF, - [SPD_MIN_CYCLE_TIME_AT_CAS_MAX] = 0x50, // SDRAM cycle time (highest CAS latency), RAS access time (tRAC) [5.0 ns in BCD] - 0xFF, 0xFF, - [SPD_REFRESH] = 0x82, // Refresh rate/type [Self Refresh, 7.8 us] - [SPD_PRIMARY_SDRAM_WIDTH] = 64, // SDRAM width (primary SDRAM) [64 bits] - 0xFF, 0xFF, 0xFF, - [SPD_NUM_BANKS_PER_SDRAM] = 4, // SDRAM device attributes, number of banks on SDRAM device - [SPD_ACCEPTABLE_CAS_LATENCIES] = 0x1C, // SDRAM device attributes, CAS latency [3, 2.5, 2] - 0xFF, 0xFF, - [SPD_MODULE_ATTRIBUTES] = 0x20, // SDRAM module attributes [differential clk] - [SPD_DEVICE_ATTRIBUTES_GENERAL] = 0x40, // SDRAM device attributes, general [Concurrent AP] - [SPD_SDRAM_CYCLE_TIME_2ND] = 0x60, // SDRAM cycle time (2nd highest CAS latency) [6.0 ns in BCD] - 0xFF, - [SPD_SDRAM_CYCLE_TIME_3RD] = 0x75, // SDRAM cycle time (3rd highest CAS latency) [7.5 ns in BCD] - 0xFF, - [SPD_tRP] = 60, // Min. row precharge time [15 ns in units of 0.25 ns] - [SPD_tRRD] = 40, // Min. row active to row active [10 ns in units of 0.25 ns] - [SPD_tRCD] = 60, // Min. RAS to CAS delay [15 ns in units of 0.25 ns] - [SPD_tRAS] = 40, // Min. RAS pulse width = active to precharge delay [40 ns] - [SPD_BANK_DENSITY] = 0x40, // Density of each row on module [256 MB] - 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, - [SPD_tRFC] = 70 // SDRAM Device Minimum Auto Refresh to Active/Auto Refresh [70 ns] -}; - static inline int spd_read_byte(unsigned int device, unsigned int address) { if (device != DIMM0) return 0xFF; /* No DIMM1, don't even try. */ -#if CONFIG_DEBUG_SMBUS - if (address >= sizeof(spdbytes) || spdbytes[address] == 0xFF) { - print_err("ERROR: spd_read_byte(DIMM0, 0x"); - print_err_hex8(address); - print_err(") returns 0xff\n"); - } -#endif - - /* Fake SPD ROM value */ - return (address < sizeof(spdbytes)) ? spdbytes[address] : 0xFF; + return smbus_read_byte(device, address); } +#if !CONFIG_BOARD_OLD_REVISION /* Send config data to System Management Controller via SMB. */ static int smc_send_config(unsigned char config_data) { @@ -118,6 +75,7 @@ smbus_stop_condition(SMBUS_IO_BASE); return 0; } +#endif #include "northbridge/amd/lx/raminit.h" #include "northbridge/amd/lx/pll_reset.c" @@ -129,19 +87,21 @@ static const u16 sio_init_table[] = { // hi=data, lo=index 0x0707, // select LDN 7 (GPIO, SPI, watchdog, ...) - 0x072C, // VIN6 enabled, FAN4/5 disabled, VIN7,VIN3 internal + 0x042C, // disable ATXPG; VIN6 enabled, FAN4/5 disabled, VIN7,VIN3 enabled 0x1423, // don't delay PoWeROK1/2 0x9072, // watchdog triggers PWROK, counts seconds #if !CONFIG_USE_WATCHDOG_ON_BOOT 0x0073, 0x0074, // disarm watchdog by changing 56 s timeout to 0 #endif 0xBF25, 0x172A, 0xF326, // select GPIO function for most pins - 0xFF27, 0xDF28, 0x2729, // (GP45=SUSB, GP23,22,16,15=SPI, GP13=PWROK1) + 0xBF27, 0xFF28, 0x2D29, // (GP36=FAN_CTL3 (PWM), GP23,22,16,15=SPI, GP13=PWROK1) 0x66B8, 0x0CB9, // enable pullups on SPI, RS485_EN - 0x07C0, // enable Simple-I/O for GP12-10= RS485_EN2,1, LIVE_LED - 0x07C8, // config GP12-10 as output + 0x07C0, // enable Simple-I/O for GP12-10= RS485_EN2,1, WD_ACTIVE + 0x06C8, // config GP12,11 as output, GP10 as input 0x2DF5, // map Hw Monitor Thermal Output to GP55 - 0x08F8, // map GP LED Blinking 1 to GP10=LIVE_LED (deactivate Simple I/O to use) +#if CONFIG_BOARD_OLD_REVISION + 0x1F2A, 0xC072, // switch GP13 to GPIO, WDT output from PWROK to KRST +#endif }; /* Early mainboard specific GPIO setup. */ @@ -161,7 +121,6 @@ void main(unsigned long bist) { - int err; post_code(0x01); static const struct mem_controller memctrl[] = { @@ -189,12 +148,22 @@ cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED); - /* bit1 = on-board IDE is slave, bit0 = Spread Spectrum */ +#if CONFIG_BOARD_OLD_REVISION + /* + * Old revision boards need a jumper shorting the power button to power + * on automatically. So we must disable the button's fail-safe function, + * or the board will shut down after 4 s. + */ + outl(0, PMS_IO_BASE + PM_FSD); // Fail-Save Delay register +#else + int err; + /* bit0 = Spread Spectrum */ if ((err = smc_send_config(SMC_CONFIG))) { print_err("ERROR "); print_err_char('0'+err); print_err(" sending config data to SMC\n"); } +#endif sdram_initialize(1, memctrl); From mylesgw at gmail.com Fri Sep 10 23:52:06 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 10 Sep 2010 15:52:06 -0600 Subject: [coreboot] [PATCH] LiPPERT Hurricane-LX support In-Reply-To: <20100910213753.32543.qmail@stuge.se> References: <4C891183.6090805@LiPPERTEmbedded.de> <20100910213753.32543.qmail@stuge.se> Message-ID: On Fri, Sep 10, 2010 at 3:37 PM, Peter Stuge wrote: > Jens Rottmann wrote: >> Kindly 'svn copy' src/mainboard/lippert/spacerunner-lx to >> src/mainboard/lippert/hurricane-lx before applying. >> >> Cheers, >> Jens > >> Add support for LiPPERT Hurricane-LX (EPIC board with AMD Geode-LX, >> CS5536, ITE IT8712F). ?Board support is based on the SpaceRunner-LX >> (with tiny bits from the RoadRunner-LX) even though the hardware really >> was the ancestor of our three other -LX boards and in fact among the >> earliest Geode-LX boards on the market. ?(Might even have been the first >> Geode-LX EPIC?) >> >> Signed-off-by: Jens Rottmann > > Acked-by: Peter Stuge Rev 5801. Thanks, Myles From marcj303 at gmail.com Fri Sep 10 23:59:38 2010 From: marcj303 at gmail.com (Marc Jones) Date: Fri, 10 Sep 2010 15:59:38 -0600 Subject: [coreboot] AMD cache setup is broken In-Reply-To: References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <4C88AF57.7010002@georgi-clan.de> <87k4mvs02h.fsf@taniquetil.gledits.ch> <4C88B88E.1070801@georgi-clan.de> Message-ID: So, after all this, I think we still need the lzma change that Arne proposed. I have found that the videobios decompress is still slow, which is after the rom caching is disabled. Marc -- http://se-eng.com From peter at stuge.se Sat Sep 11 00:01:24 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Sep 2010 00:01:24 +0200 Subject: [coreboot] [PATCH] i945 mainboard resources In-Reply-To: References: Message-ID: <20100910220124.11041.qmail@stuge.se> Myles Watson wrote: > I think we should get rid of HAVE_MAINBOARD_RESOURCES. > > Here's a patch that does that for i945 boards. The Roda board > provided add_mainboard_resources(), but it was never called because it > didn't select HAVE_MAINBOARD_RESOURCES in Kconfig. > > Testing & suggestions welcome. > > Signed-off-by: Myles Watson Acked-by: Peter Stuge Maybe it's wise to get some feedback on testing before commit? On the other hand, maybe not. I think this should work. //Peter From svn at coreboot.org Sat Sep 11 00:13:34 2010 From: svn at coreboot.org (repository service) Date: Sat, 11 Sep 2010 00:13:34 +0200 Subject: [coreboot] [commit] r5802 - in trunk/src/superio/fintek: . f71859 Message-ID: Author: mjones Date: Sat Sep 11 00:13:34 2010 New Revision: 5802 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5802 Log: Add F71859 SIO. Signed-off-by: Marc Jones Acked-by: Uwe Hermann Added: trunk/src/superio/fintek/f71859/ trunk/src/superio/fintek/f71859/Makefile.inc (contents, props changed) trunk/src/superio/fintek/f71859/chip.h (contents, props changed) trunk/src/superio/fintek/f71859/f71859.h (contents, props changed) trunk/src/superio/fintek/f71859/f71859_early_serial.c (contents, props changed) trunk/src/superio/fintek/f71859/superio.c (contents, props changed) Modified: trunk/src/superio/fintek/Kconfig trunk/src/superio/fintek/Makefile.inc Modified: trunk/src/superio/fintek/Kconfig ============================================================================== --- trunk/src/superio/fintek/Kconfig Fri Sep 10 23:51:34 2010 (r5801) +++ trunk/src/superio/fintek/Kconfig Sat Sep 11 00:13:34 2010 (r5802) @@ -2,3 +2,5 @@ bool config SUPERIO_FINTEK_F71863FG bool +config SUPERIO_FINTEK_F71859 + bool Modified: trunk/src/superio/fintek/Makefile.inc ============================================================================== --- trunk/src/superio/fintek/Makefile.inc Fri Sep 10 23:51:34 2010 (r5801) +++ trunk/src/superio/fintek/Makefile.inc Sat Sep 11 00:13:34 2010 (r5802) @@ -1,2 +1,3 @@ subdirs-y += f71805f subdirs-y += f71863fg +subdirs-y += f71859 Added: trunk/src/superio/fintek/f71859/Makefile.inc ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/src/superio/fintek/f71859/Makefile.inc Sat Sep 11 00:13:34 2010 (r5802) @@ -0,0 +1,20 @@ +## +## This file is part of the coreboot project. +## +## 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 +## + +#config chip.h +obj-$(CONFIG_SUPERIO_FINTEK_F71859) += superio.o Added: trunk/src/superio/fintek/f71859/chip.h ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/src/superio/fintek/f71859/chip.h Sat Sep 11 00:13:34 2010 (r5802) @@ -0,0 +1,28 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2010 Marc Jones + * + * 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 + */ + +#include +#include + +extern struct chip_operations superio_fintek_f71859_ops; + +struct superio_fintek_f71859_config { + struct uart8250 com1, com2; +}; Added: trunk/src/superio/fintek/f71859/f71859.h ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/src/superio/fintek/f71859/f71859.h Sat Sep 11 00:13:34 2010 (r5802) @@ -0,0 +1,24 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2010 Marc Jones + * + * 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 + */ + +/* Logical Device Numbers (LDN). */ + +#define F71859_SP1 0x03 /* UART1 */ + Added: trunk/src/superio/fintek/f71859/f71859_early_serial.c ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/src/superio/fintek/f71859/f71859_early_serial.c Sat Sep 11 00:13:34 2010 (r5802) @@ -0,0 +1,46 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2010 Marc Jones + * + * 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 + */ + +/* Pre-RAM driver for the Fintek F71859 Super I/O chip. */ + +#include +#include "f71859.h" + +static inline void pnp_enter_conf_state(device_t dev) +{ + unsigned int port = dev >> 8; + outb(0x87, port); +} + +static void pnp_exit_conf_state(device_t dev) +{ + unsigned int port = dev >> 8; + outb(0xaa, port); +} + +static void f71859_enable_serial(device_t dev, unsigned int iobase) +{ + pnp_enter_conf_state(dev); + pnp_set_logical_device(dev); + pnp_set_enable(dev, 0); + pnp_set_iobase(dev, PNP_IDX_IO0, iobase); + pnp_set_enable(dev, 1); + pnp_exit_conf_state(dev); +} Added: trunk/src/superio/fintek/f71859/superio.c ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/src/superio/fintek/f71859/superio.c Sat Sep 11 00:13:34 2010 (r5802) @@ -0,0 +1,103 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2010 Marc Jones + * Copyright (C) 2008 Corey Osgood + * + * 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 + */ + + +#include +#include +#include +#include +#include +#include +#include "chip.h" +#include "f71859.h" + +static void pnp_enter_conf_state(device_t dev) +{ + outb(0x87, dev->path.pnp.port); +} + +static void pnp_exit_conf_state(device_t dev) +{ + outb(0xaa, dev->path.pnp.port); +} + +static void f71859_init(device_t dev) +{ + struct superio_fintek_f71859_config *conf = dev->chip_info; + struct resource *res0; + + if (!dev->enabled) + return; + + switch(dev->path.pnp.device) { + /* TODO: Might potentially need code for HWM or FDC etc. */ + case F71859_SP1: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com1); + break; + } +} + +static void f71859_pnp_set_resources(device_t dev) +{ + pnp_enter_conf_state(dev); + pnp_set_resources(dev); + pnp_exit_conf_state(dev); +} + +static void f71859_pnp_enable_resources(device_t dev) +{ + pnp_enter_conf_state(dev); + pnp_enable_resources(dev); + pnp_exit_conf_state(dev); +} + +static void f71859_pnp_enable(device_t dev) +{ + pnp_enter_conf_state(dev); + pnp_set_logical_device(dev); + (dev->enabled) ? pnp_set_enable(dev, 1) : pnp_set_enable(dev, 0); + pnp_exit_conf_state(dev); +} + +static struct device_operations ops = { + .read_resources = pnp_read_resources, + .set_resources = f71859_pnp_set_resources, + .enable_resources = f71859_pnp_enable_resources, + .enable = f71859_pnp_enable, + .init = f71859_init, +}; + +static struct pnp_info pnp_dev_info[] = { + /* TODO: Some of the 0x7f8 etc. values may not be correct. */ + { &ops, F71859_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, + +}; + +static void enable_dev(device_t dev) +{ + pnp_enable_devices(dev, &ops, ARRAY_SIZE(pnp_dev_info), pnp_dev_info); +} + +struct chip_operations superio_fintek_f71859_ops = { + CHIP_NAME("Fintek F71859 Super I/O") + .enable_dev = enable_dev +}; From marcj303 at gmail.com Sat Sep 11 00:15:25 2010 From: marcj303 at gmail.com (Marc Jones) Date: Fri, 10 Sep 2010 16:15:25 -0600 Subject: [coreboot] [patch] fintek f71859 sio In-Reply-To: <20100910072608.GB3256@greenwood> References: <20100910072608.GB3256@greenwood> Message-ID: On Fri, Sep 10, 2010 at 1:26 AM, Uwe Hermann wrote: > Hi, > > On Thu, Sep 09, 2010 at 09:49:38PM -0600, Marc Jones wrote: >> Index: src/superio/fintek/Kconfig >> =================================================================== >> --- src/superio/fintek/Kconfig ? ? ? ?(revision 5799) >> +++ src/superio/fintek/Kconfig ? ? ? ?(working copy) >> @@ -2,3 +2,5 @@ >> ? ? ? bool >> ?config SUPERIO_FINTEK_F71863FG >> ? ? ? bool >> +config SUPERIO_FINTEK_F71859 >> + ? ? bool >> Index: src/superio/fintek/f71859/f71859_early_serial.c >> =================================================================== >> --- src/superio/fintek/f71859/f71859_early_serial.c ? (revision 0) >> +++ src/superio/fintek/f71859/f71859_early_serial.c ? (revision 0) >> @@ -0,0 +1,46 @@ >> +/* >> + * This file is part of the coreboot project. >> + * >> + * Copyright (C) 2007 Corey Osgood > > You can make all those files > ?* Copyright (C) 2010 Marc Jones > as each of them is trivial and cannot really be written differently. > > >> +/* Pre-RAM driver for the Fintek F71805F/FG Super I/O chip. */ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^^^^^^^^ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?F71859 > > Does your chip have an "F" suffix in the name as the above ones? If yes, > please add it to the name in the code/comments and file/directory names. > > >> Property changes on: src/superio/fintek/f71859/f71859_early_serial.c >> ___________________________________________________________________ >> Added: svn:executable >> ? ?+ * > > Please drop the executable property from all files, it's incorrect and > not needed. > > >> +/* This chip doesn't have keyboard and mouse support. */ > > Should probably be dropped unless you are sure the chip doesn't have > keyboard/mouse support. > > >> +/* >> + * Datasheet: >> + >> + */ > > Can be dropped. > > > With the above changes: > Signed-off-by: Uwe Hermann I assume that you mean acked-by. r 5802 Thanks! Marc -- http://se-eng.com From marcj303 at gmail.com Sat Sep 11 00:51:35 2010 From: marcj303 at gmail.com (Marc Jones) Date: Fri, 10 Sep 2010 16:51:35 -0600 Subject: [coreboot] [patch] IEI Kino 780 AM2 mainboard Message-ID: IEI Kino mainoard support based on Mahogany Fam10. svn copy amd/mahogany iei/kino-780am2-fam10; then apply the patch. Signed-off-by: Marc Jones -- http://se-eng.com -------------- next part -------------- A non-text attachment was scrubbed... Name: kino.patch Type: application/octet-stream Size: 10291 bytes Desc: not available URL: From marcj303 at gmail.com Sat Sep 11 00:55:07 2010 From: marcj303 at gmail.com (Marc Jones) Date: Fri, 10 Sep 2010 16:55:07 -0600 Subject: [coreboot] workaround for mahogany_fam10. Not a signed-off-by In-Reply-To: References: Message-ID: On Sun, Mar 14, 2010 at 11:41 PM, Bao, Zheng wrote: > This is for the mahogany_fam10 I just sent. It is not a signed-off-by > patch. We need to work it out about this problem. > > > Index: src/northbridge/amd/amdht/h3finit.c > =================================================================== > --- src/northbridge/amd/amdht/h3finit.c (revision 4521) > +++ src/northbridge/amd/amdht/h3finit.c (working copy) > @@ -1104,6 +1104,7 @@ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?AmdPCIRead(currentPtr, &temp); > ? ? ? ? ? ? ? ? ? ? ? ?} while (!IS_HT_SLAVE_CAPABILITY(temp)); > > +#if (CONFIG_HT_CHAIN_UNITID_BASE != 0) > ? ? ? ? ? ? ? ? ? ? ? ?AmdPCIReadBits(currentPtr, 25, 21, &unitIDcnt); > ? ? ? ? ? ? ? ? ? ? ? ?if ((unitIDcnt + currentBUID > 31) || ((secBus > == 0) && (unitIDcnt + currentBUID > 24))) > ? ? ? ? ? ? ? ? ? ? ? ?{ > @@ -1145,7 +1146,7 @@ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?STOP_HERE; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?break; > ? ? ? ? ? ? ? ? ? ? ? ?} > - > +#endif > ? ? ? ? ? ? ? ? ? ? ? ?AmdPCIReadBits(currentPtr, 26, 26, &temp); > ? ? ? ? ? ? ? ? ? ? ? ?pDat->PortList[pDat->TotalLinks*2+1].Link = > (u8)temp; > ? ? ? ? ? ? ? ? ? ? ? ?pDat->PortList[pDat->TotalLinks*2+1].Pointer = > currentPtr; > @@ -1156,6 +1157,11 @@ > ? ? ? ? ? ? ? ? ? ? ? ?depth++; > ? ? ? ? ? ? ? ? ? ? ? ?pDat->TotalLinks++; > ? ? ? ? ? ? ? ? ? ? ? ?currentBUID += unitIDcnt; > +#if CONFIG_HT_CHAIN_UNITID_BASE == 0 > + ? ? ? ? ? ? ? ? ? ? ? STOP_HERE; > + ? ? ? ? ? ? ? ? ? ? ? break; > +#endif > + > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (pDat->HtBlock->AMD_CB_EventNotify) > ? ? ? ? ? ? ? ?{ > Please give a better description to this fix when you check it in. Acked-by: Marc Jones Thanks, Marc -- http://se-eng.com From peter at stuge.se Sat Sep 11 01:39:22 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Sep 2010 01:39:22 +0200 Subject: [coreboot] [patch] IEI Kino 780 AM2 mainboard In-Reply-To: References: Message-ID: <20100910233922.30691.qmail@stuge.se> Marc Jones wrote: > IEI Kino mainoard support based on Mahogany Fam10. > svn copy amd/mahogany iei/kino-780am2-fam10; then apply the patch. > > Signed-off-by: Marc Jones > +++ coreboot/src/mainboard/iei/kino-780am2-fam10/mainboard.c 2010-09-10 10:14:37.000000000 -0600 .. > +/* FIXME - Need to find GPIO for PCIE slot. > + * Kino uses GPIO ? as PCIe slot reset, GPIO? as GFX slot reset. We need to > * pull it up before training the slot. > ***/ > void set_pcie_dereset() > { .. > + /* No PCIE slots.*/ > } > > void set_pcie_reset() > { .. > + /* No PCIE slots.*/ > } Uh? Is there or is there not a PCIe slot? > -static void mahogany_enable(device_t dev) > +static void kino_enable(device_t dev) > { > - printk(BIOS_INFO, "Mainboard MAHOGANY Enable. dev=0x%p\n", dev); > + printk(BIOS_INFO, "Mainboard Kino Enable. dev=0x%p\n", dev); > > #if (CONFIG_GFXUMA == 1) > msr_t msr, msr2; > @@ -166,6 +121,6 @@ > } > > struct chip_operations mainboard_ops = { > - CHIP_NAME("AMD MAHOGANY Mainboard") > - .enable_dev = mahogany_enable, > + CHIP_NAME("IEI Kino-780AM2 Mainboard") > + .enable_dev = kino_enable, > }; Could the mainboard enable function reuse the CHIP_NAME somehow, or maybe both should just use CONFIG_MAINBOARD_PART_NUMBER ? Acked-by: Peter Stuge From patrick at georgi-clan.de Sat Sep 11 06:30:58 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Sat, 11 Sep 2010 06:30:58 +0200 Subject: [coreboot] workaround for mahogany_fam10. Not a signed-off-by In-Reply-To: References: Message-ID: <4C8B0602.9090407@georgi-clan.de> Am 11.09.2010 00:55, schrieb Marc Jones: > Please give a better description to this fix when you check it in. Also, "Not a signed-off-by" is not the best condition to get it in. Patrick From peter at stuge.se Sat Sep 11 06:33:54 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Sep 2010 06:33:54 +0200 Subject: [coreboot] workaround for mahogany_fam10. Not a signed-off-by In-Reply-To: <4C8B0602.9090407@georgi-clan.de> References: <4C8B0602.9090407@georgi-clan.de> Message-ID: <20100911043354.707.qmail@stuge.se> Patrick Georgi wrote: > Am 11.09.2010 00:55, schrieb Marc Jones: > > Please give a better description to this fix when you check it in. > Also, "Not a signed-off-by" is not the best condition to get it in. I guess it was not really intended to be commited but rather that further work will come.. //Peter From uwe at hermann-uwe.de Sat Sep 11 12:02:49 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 11 Sep 2010 12:02:49 +0200 Subject: [coreboot] [patch] fintek f71859 sio In-Reply-To: References: <20100910072608.GB3256@greenwood> Message-ID: <20100911100249.GB6119@greenwood> On Fri, Sep 10, 2010 at 04:15:25PM -0600, Marc Jones wrote: > > With the above changes: > > Signed-off-by: Uwe Hermann > > I assume that you mean acked-by. > > r 5802 Er, yes, sorry. Pressed the wrong button. I have Signed-off-by and Acked-by lines being inserted upon pressing F4/F5 in vim. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From juhe at iki.fi Sat Sep 11 12:48:47 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Sat, 11 Sep 2010 13:48:47 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> Message-ID: <1284202127.538.41.camel@bart> On Fri, 2010-09-10 at 09:54 -0600, Myles Watson wrote: > I appreciate the work that you've done. I've attached patches that > I've reduced a little more. Would you test/review them? If they > work, I'll commit them. > > Signed-off-by: Myles Watson Thanks for your trouble of cleaning up. I tried the patches you sent just now. Since Socket/DIMM type configuration was changed in rev 5800, I tested these against rev 5799. Patching and building is ok. Booting looks fine, Grub2 comes up and loads Linux. However, Linux cannot find SATA controller, and because of that, the booting fails. (Although Grub just loaded the kernel and initrd from SATA.) Linux gives the following complaints that I have not seen before: [ 1.620006] pci 0000:00:12.0: OHCI: BIOS handoff failed (BIOS bug?) ffffffff [ 2.424005] pci 0000:00:12.1: OHCI: BIOS handoff failed (BIOS bug?) ffffffff [ 2.431115] pci 0000:00:12.2: EHCI: unrecognized capability 02 [ 3.236005] pci 0000:00:13.0: OHCI: BIOS handoff failed (BIOS bug?) ffffffff [ 4.040005] pci 0000:00:13.1: OHCI: BIOS handoff failed (BIOS bug?) ffffffff [ 4.047129] pci 0000:00:13.2: EHCI: unrecognized capability 02 [ 4.852005] pci 0000:00:14.5: OHCI: BIOS handoff failed (BIOS bug?) ffffffff ... [ 6.524010] ahci 0000:00:11.0: controller reset failed (0xffffffff) [ 6.530976] ahci 0000:00:11.0: PCI INT A disabled [ 6.536129] ahci: probe of 0000:00:11.0 failed with error -5 [ 6.542497] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19 [ 6.550296] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 6.556084] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 1 [ 6.574836] ehci_hcd 0000:00:13.2: can't setup [ 6.579802] ehci_hcd 0000:00:13.2: USB bus 1 deregistered [ 6.585744] ehci_hcd 0000:00:13.2: PCI INT B disabled [ 6.591369] ehci_hcd 0000:00:13.2: init 0000:00:13.2 fail, -110 [ 6.597905] ehci_hcd: probe of 0000:00:13.2 failed with error -110 [ 6.608546] sd 1:0:0:0: [sda] 15621984 512-byte logical blocks: (7.99 GB/7.44 GiB) [ 6.613539] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 6.613588] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 6.613609] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 6.613626] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 1 [ 6.645506] sd 1:0:0:0: [sda] Write Protect is off [ 6.650743] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't suppoA [ 6.660904] sda: sda1 sda2 < sda5 > [ 6.666370] sd 1:0:0:0: [sda] Attached SCSI disk [ 6.676803] sr0: scsi3-mmc drive: 0x/48x cd/rw xa/form2 cdda tray [ 6.683415] Uniform CD-ROM driver Revision: 3.20 [ 6.692578] sd 1:0:0:0: Attached scsi generic sg0 type 0 [ 6.698631] sr 1:0:1:0: Attached scsi generic sg1 type 5 [ 14.612006] ohci_hcd 0000:00:12.0: USB HC takeover failed! (BIOS/SMM bug) [ 14.619415] ohci_hcd 0000:00:12.0: can't setup [ 14.624264] ohci_hcd 0000:00:12.0: USB bus 1 deregistered [ 14.630262] ohci_hcd 0000:00:12.0: PCI INT A disabled [ 14.635877] ohci_hcd 0000:00:12.0: init 0000:00:12.0 fail, -16 [ 14.642263] ohci_hcd: probe of 0000:00:12.0 failed with error -16 [ 14.649008] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 14.656848] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 14.662579] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bus number 1 [ 22.668004] ohci_hcd 0000:00:12.1: USB HC takeover failed! (BIOS/SMM bug) [ 22.675470] ohci_hcd 0000:00:12.1: can't setup [ 22.680290] ohci_hcd 0000:00:12.1: USB bus 1 deregistered [ 22.686118] ohci_hcd 0000:00:12.1: PCI INT A disabled [ 22.691742] ohci_hcd 0000:00:12.1: init 0000:00:12.1 fail, -16 [ 22.698163] ohci_hcd: probe of 0000:00:12.1 failed with error -16 [ 22.704836] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 22.712793] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 22.718541] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1 [ 30.724004] ohci_hcd 0000:00:13.0: USB HC takeover failed! (BIOS/SMM bug) [ 30.731397] ohci_hcd 0000:00:13.0: can't setup [ 30.736232] ohci_hcd 0000:00:13.0: USB bus 1 deregistered [ 30.742097] ohci_hcd 0000:00:13.0: PCI INT A disabled [ 30.747628] ohci_hcd 0000:00:13.0: init 0000:00:13.0 fail, -16 [ 30.754124] ohci_hcd: probe of 0000:00:13.0 failed with error -16 [ 30.760783] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 30.768663] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 30.774442] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 1 [ 38.796004] ohci_hcd 0000:00:13.1: USB HC takeover failed! (BIOS/SMM bug) [ 38.803405] ohci_hcd 0000:00:13.1: can't setup [ 38.808328] ohci_hcd 0000:00:13.1: USB bus 1 deregistered [ 38.814324] ohci_hcd 0000:00:13.1: PCI INT A disabled [ 38.819841] ohci_hcd 0000:00:13.1: init 0000:00:13.1 fail, -16 [ 38.826275] ohci_hcd: probe of 0000:00:13.1 failed with error -16 [ 38.833071] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 38.840934] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 38.846780] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 1 [ 46.852004] ohci_hcd 0000:00:14.5: USB HC takeover failed! (BIOS/SMM bug) [ 46.859434] ohci_hcd 0000:00:14.5: can't setup [ 46.864302] ohci_hcd 0000:00:14.5: USB bus 1 deregistered [ 46.870312] ohci_hcd 0000:00:14.5: PCI INT C disabled [ 46.875922] ohci_hcd 0000:00:14.5: init 0000:00:14.5 fail, -16 [ 46.882333] ohci_hcd: probe of 0000:00:14.5 failed with error -16 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. It seems that also the USB controller initialization fails, although I did not test if it worked. Aside from the AHCI/OHCI/EHCI -drivers failing, the boot logs seem to be the same as before. I tried to look at the patch code, but could not figure out why this is happening. Best regards, Juhana Helovuo From arne.gleditsch at numascale.com Sat Sep 11 13:00:32 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Sat, 11 Sep 2010 13:00:32 +0200 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: <9617B27123C44F56A182F911336057BC@m3a78> (Scott Duplichan's message of "Thu, 9 Sep 2010 20:30:02 -0500") References: <4C896959.9080300@gmx.net> <9617B27123C44F56A182F911336057BC@m3a78> Message-ID: <878w38y27j.fsf@taniquetil.gledits.ch> "Scott Duplichan" writes: > In this report: > http://article.gmane.org/gmane.linux.bios/57707, > Arne may have been encountering the ClLinesToNbDis issue > (assuming the memset code was running from flash). Switching > to rep movs would greatly improve performance because unlike > a byte loop, rep movs loops in microcode which does not cause > continuous flash memory accesses. This was my assumption as well. After fixing the ClLinesToNbDis setting, I have removed the rep stosb code from my tree, and so far I've not observed the pathological memset behaviour that caused me to put it in in the first place. (As mentioned earlier this was never altogether deterministic, I'm assuming some critical part of the original memset loop needed to straddle cache lines or something for it to manifest.) -- Arne. From arne.gleditsch at numascale.com Sat Sep 11 13:05:03 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Sat, 11 Sep 2010 13:05:03 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: (Marc Jones's message of "Fri, 10 Sep 2010 15:59:38 -0600") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <4C88AF57.7010002@georgi-clan.de> <87k4mvs02h.fsf@taniquetil.gledits.ch> <4C88B88E.1070801@georgi-clan.de> Message-ID: <874odwy200.fsf@taniquetil.gledits.ch> Marc Jones writes: > So, after all this, I think we still need the lzma change that Arne > proposed. I have found that the videobios decompress is still slow, > which is after the rom caching is disabled. I thought the decompress itself needed to run from ROM for us to see this. What kind of video bios is this; is it embedded in the coreboot image or is it hosted on an external video card? I have a vague recollection of there being a facility or hook that allowed option roms to copy themselves from ROM to RAM, could that be involved here? -- Arne. From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 11 13:37:24 2010 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 11 Sep 2010 13:37:24 +0200 Subject: [coreboot] [patch] IEI Kino 780 AM2 mainboard In-Reply-To: <20100910233922.30691.qmail@stuge.se> References: <20100910233922.30691.qmail@stuge.se> Message-ID: <4C8B69F4.50002@gmx.net> On 11.09.2010 01:39, Peter Stuge wrote: > Marc Jones wrote: > >> -static void mahogany_enable(device_t dev) >> +static void kino_enable(device_t dev) >> { >> - printk(BIOS_INFO, "Mainboard MAHOGANY Enable. dev=0x%p\n", dev); >> + printk(BIOS_INFO, "Mainboard Kino Enable. dev=0x%p\n", dev); >> >> #if (CONFIG_GFXUMA == 1) >> msr_t msr, msr2; >> @@ -166,6 +121,6 @@ >> } >> >> struct chip_operations mainboard_ops = { >> - CHIP_NAME("AMD MAHOGANY Mainboard") >> - .enable_dev = mahogany_enable, >> + CHIP_NAME("IEI Kino-780AM2 Mainboard") >> + .enable_dev = kino_enable, >> }; >> > > Could the mainboard enable function reuse the CHIP_NAME somehow, or > maybe both should just use CONFIG_MAINBOARD_PART_NUMBER ? > I once had such a patch, but I think it was rejected for two reasons: - grepping is more difficult because you have to match in two stages - building multi-mainboard images means CONFIG_MAINBOARD_PART_NUMBER is not really meaningful. That said, I still support the idea and would be willing to update my patch. Regards, Carl-Daniel -- http://www.hailfinger.org/ From mylesgw at gmail.com Sat Sep 11 15:03:10 2010 From: mylesgw at gmail.com (Myles Watson) Date: Sat, 11 Sep 2010 07:03:10 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <1284202127.538.41.camel@bart> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> Message-ID: > I tried the patches you sent just now. Since Socket/DIMM type > configuration was changed in rev 5800, I tested these against rev 5799. > > Patching and building is ok. Booting looks fine, Grub2 comes up and > loads Linux. However, Linux cannot find SATA controller, and because of > that, the booting fails. (Although Grub just loaded the kernel and > initrd from SATA.) > > Linux gives the following complaints that I have not seen before: > It seems that also the USB controller initialization fails, although I did not test if it worked. > Aside from the AHCI/OHCI/EHCI -drivers failing, the boot logs seem to be the same as before. > > I tried to look at the patch code, but could not figure out why this is happening. So it works with my updated patch, but not with the uma & reserved patches? Or does it not work at all? Does it still work with your previous patch set? Could you send a full log with the last working version and the first broken version from this list? 1. Your original patches 2. 5799 + my board patch 3. 2 + uma.diff 4. 3 + reserved.diff uma.diff & reserved.diff should be independent, so you could try 2+reserved.diff also I attached an updated patch that should apply to 5800 if that's easier/better. Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: asus-m4a785m-small-patch.patch Type: text/x-diff Size: 17276 bytes Desc: not available URL: From mylesgw at gmail.com Sat Sep 11 15:11:57 2010 From: mylesgw at gmail.com (Myles Watson) Date: Sat, 11 Sep 2010 07:11:57 -0600 Subject: [coreboot] [PATCH] i945 mainboard resources In-Reply-To: <20100910220124.11041.qmail@stuge.se> References: <20100910220124.11041.qmail@stuge.se> Message-ID: On Fri, Sep 10, 2010 at 4:01 PM, Peter Stuge wrote: > Myles Watson wrote: >> I think we should get rid of HAVE_MAINBOARD_RESOURCES. >> >> Here's a patch that does that for i945 boards. ?The Roda board >> provided add_mainboard_resources(), but it was never called because it >> didn't select HAVE_MAINBOARD_RESOURCES in Kconfig. >> >> Testing & suggestions welcome. >> >> Signed-off-by: Myles Watson > > Acked-by: Peter Stuge Thanks. > Maybe it's wise to get some feedback on testing before commit? On the > other hand, maybe not. I think this should work. Checking it in might get me quicker test feedback :) I was hoping someone with a board would test it first, though. Thanks, Myles From footplus at gmail.com Sat Sep 11 16:11:24 2010 From: footplus at gmail.com (=?UTF-8?B?QXVyw6lsaWVu?=) Date: Sat, 11 Sep 2010 16:11:24 +0200 Subject: [coreboot] [PATCH] Raw payload extraction support in cbfstool Message-ID: Hi, If someone is interested by the feature, here's a patch to extract a raw component (other types need decoding functions, which I did not write) from a coreboot ROM. My particular use-case it that I want to embed a chunk of data (own S/N, P/N and things like that in my coreboot rom, so that this data is really tied to the hardware and survives compact flash changes, etc). It was suggested that I use DMI for this, and indeed it seems interesting, but my Alix.2 board has currently no DMI support, and the current embedding method supposes a recompilation of the rom. Hence, this method of extraction at run-time. I found that using dd on /dev/mem to extract the running rom works well, at the condition of not having STRICT_DEVMEM in the kernel, and reading the whole image in one block. On my board: # dd if=/dev/mem of=/tmp/dump.bin bs=512K count=1 skip=8191 # cbfstool /tmp/dump.bin extract boardata boarddata.bin fills boarddata.bin with the contents of the boarddata cbfs component. Of course you can use any rom image instead of the one extracted from RAM. I tried to make a patch which reads from /dev/mem directly in 2 ways: - mmap()ing /dev/mem, but it seemed that it would be too specific a modification to be accepted. - modifying the loadfile code to extensively use lseek to navigate in the file, reading it like starting at the end, and deducing the size from the CBFS header. This method works well for files, but does not for /dev/mem. So it's relatively useless. I think the problem is due to a bug/feature in /dev/mem implementation. Signed-off-by: Aurelien Guillaume Best regards. -- Aur?lien Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cbfstool-extract-raw.patch Type: application/octet-stream Size: 4307 bytes Desc: not available URL: From footplus at gmail.com Sat Sep 11 16:21:23 2010 From: footplus at gmail.com (=?UTF-8?B?QXVyw6lsaWVu?=) Date: Sat, 11 Sep 2010 16:21:23 +0200 Subject: [coreboot] [PATCH] Geode LX and Alix.2 support enhancements In-Reply-To: References: Message-ID: Hi, Could someone with Alix.2c or Alix.2d please review and ack/not ack this patch ? These are relatively trivial changes anyways. On Sun, Sep 5, 2010 at 12:00 AM, Aur?lien wrote: > > Alix.2[cd][23] support enhancements > ---- > !!!! Please $ svn mv alix2d alix2 before applying this patch. !!!! > I decided to rename the boards Alix.2 and support the following variants: > 2c2, 2c3, 2d2, 2d3, 2d13 - see help text -. 2d1 may also work, but differ > more: different ram size, and no USB, so I can't say. > I also added a submenu to configure which onboard LEDs should be lit at > boot. > Finally, I clarified the comments in irq_routing.c. > > On Tue, Sep 7, 2010 at 9:44 AM, Patrick Georgi wrote: > I'll leave this to someone else, who knows Alix better than I do. > Thanks :) Best regards, -- Aur?lien Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at notabs.org Sat Sep 11 17:34:03 2010 From: scott at notabs.org (Scott Duplichan) Date: Sat, 11 Sep 2010 10:34:03 -0500 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: <878w38y27j.fsf@taniquetil.gledits.ch> References: <4C896959.9080300@gmx.net> <9617B27123C44F56A182F911336057BC@m3a78> <878w38y27j.fsf@taniquetil.gledits.ch> Message-ID: <4CE561505A524326A71B1383A7F61A23@m3a78> ]-----Original Message----- ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Arne Georg Gleditsch ]Sent: Saturday, September 11, 2010 06:01 AM ]To: Scott Duplichan ]Cc: 'Marc Jones'; 'Carl-Daniel Hailfinger'; 'Coreboot' ]Subject: Re: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp ] ]"Scott Duplichan" writes: ]> In this report: ]> http://article.gmane.org/gmane.linux.bios/57707, ]> Arne may have been encountering the ClLinesToNbDis issue ]> (assuming the memset code was running from flash). Switching ]> to rep movs would greatly improve performance because unlike ]> a byte loop, rep movs loops in microcode which does not cause ]> continuous flash memory accesses. ] ]This was my assumption as well. After fixing the ClLinesToNbDis ]setting, I have removed the rep stosb code from my tree, and so far I've ]not observed the pathological memset behaviour that caused me to put it ]in in the first place. (As mentioned earlier this was never altogether ]deterministic, I'm assuming some critical part of the original memset ]loop needed to straddle cache lines or something for it to manifest.) Interesting point about memcpy straddling a cache line boundary. It got me thinking about what the DediProg em100 trace function shows when booting from SPI flash. With SPI, the SB initially reads a dword at a time. If the processor is not caching code, a byte loop memcpy would trigger multiple dword reads from the flash chip for every byte copied. If BIOS sets SB option PrefetchEnSPIFromHost, then the SB will switch to cache line reads, and cache the last line read. Since a byte loop memcpy fits in a cache line, it seems conceivable that memcpy performance would be good unless the function straddles a cache line boundary. I am not sure what the situation is with LPC flash. Anyway, I noticed coreboot is not setting the AMD SB bit PrefetchEnSPIFromHost. For big payloads, setting this bit could cut boot time by eliminating overhead when reading big chunks from SPI flash memory. Thanks, Scott ] ]-- ] Arne. From marcj303 at gmail.com Sat Sep 11 19:48:37 2010 From: marcj303 at gmail.com (Marc Jones) Date: Sat, 11 Sep 2010 11:48:37 -0600 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <874odwy200.fsf@taniquetil.gledits.ch> References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <4C88AF57.7010002@georgi-clan.de> <87k4mvs02h.fsf@taniquetil.gledits.ch> <4C88B88E.1070801@georgi-clan.de> <874odwy200.fsf@taniquetil.gledits.ch> Message-ID: On Sat, Sep 11, 2010 at 5:05 AM, Arne Georg Gleditsch wrote: > Marc Jones writes: >> So, after all this, I think we still need the lzma change that Arne >> proposed. I have found that the videobios decompress is still slow, >> which is after the rom caching is disabled. > > I thought the decompress itself needed to run from ROM for us to see > this. ?What kind of video bios is this; is it embedded in the coreboot > image or is it hosted on an external video card? ?I have a vague > recollection of there being a facility or hook that allowed option roms > to copy themselves from ROM to RAM, could that be involved here? This is a lzma compressed rom embeeded in the coreboot image. Marc -- http://se-eng.com From marcj303 at gmail.com Sat Sep 11 19:54:12 2010 From: marcj303 at gmail.com (Marc Jones) Date: Sat, 11 Sep 2010 11:54:12 -0600 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: <4CE561505A524326A71B1383A7F61A23@m3a78> References: <4C896959.9080300@gmx.net> <9617B27123C44F56A182F911336057BC@m3a78> <878w38y27j.fsf@taniquetil.gledits.ch> <4CE561505A524326A71B1383A7F61A23@m3a78> Message-ID: On Sat, Sep 11, 2010 at 9:34 AM, Scott Duplichan wrote: > ]-----Original Message----- > ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Arne Georg Gleditsch > ]Sent: Saturday, September 11, 2010 06:01 AM > ]To: Scott Duplichan > ]Cc: 'Marc Jones'; 'Carl-Daniel Hailfinger'; 'Coreboot' > ]Subject: Re: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp > ] > ]"Scott Duplichan" writes: > ]> In this report: > ]> http://article.gmane.org/gmane.linux.bios/57707, > ]> Arne may have been encountering the ClLinesToNbDis issue > ]> (assuming the memset code was running from flash). Switching > ]> to rep movs would greatly improve performance because unlike > ]> a byte loop, rep movs loops in microcode which does not cause > ]> continuous flash memory accesses. > ] > ]This was my assumption as well. ?After fixing the ClLinesToNbDis > ]setting, I have removed the rep stosb code from my tree, and so far I've > ]not observed the pathological memset behaviour that caused me to put it > ]in in the first place. ?(As mentioned earlier this was never altogether > ]deterministic, I'm assuming some critical part of the original memset > ]loop needed to straddle cache lines or something for it to manifest.) > > Interesting point about memcpy straddling a cache line boundary. It got > me thinking about what the DediProg em100 trace function shows when > booting from SPI flash. With SPI, the SB initially reads a dword at a > time. If the processor is not caching code, a byte loop memcpy would > trigger multiple dword reads from the flash chip for every byte copied. > If BIOS sets SB option PrefetchEnSPIFromHost, then the SB will switch > to cache line reads, and cache the last line read. Since a byte loop > memcpy fits in a cache line, it seems conceivable that memcpy performance > would be good unless the function straddles a cache line boundary. I am > not sure what the situation is with LPC flash. > > Anyway, I noticed coreboot is not setting the AMD SB bit PrefetchEnSPIFromHost. > For big payloads, setting this bit could cut boot time by eliminating > overhead when reading big chunks from SPI flash memory. Oh, we should do that. But, that doesn't really explain why gcc doesn't do a rep stos or rep mov (which should hit the cache)/ That should be an easy optimization for gcc. It also doesn't address why coreboot has a functions when we could use gcc intrinsic that should be optimized for the architecture they are built for. Marc -- http://se-eng.com From juhe at iki.fi Sat Sep 11 20:40:55 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Sat, 11 Sep 2010 21:40:55 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> Message-ID: <1284230455.538.52.camel@bart> On Sat, 2010-09-11 at 07:03 -0600, Myles Watson wrote: > > > > I tried to look at the patch code, but could not figure out why this is happening. > > So it works with my updated patch, but not with the uma & reserved > patches? Or does it not work at all? Does it still work with your > previous patch set? Hmm. Sorry about the ambiguity. Booting works ok with 5792 + my original patches. SATA controller failure was with 5799 + your simplified patches. I did not yet get to test uma.diff and reserved.diff at all. I'll do some more testing to narrow down where the failure is. The first thing to check would be to see if the cause was in different patches (original vs. simplified) or trunk code (5792 vs. 5799). Then I'll see what uma.diff and reserved.diff do. Best regards, Juhana Helovuo From peter at stuge.se Sat Sep 11 20:43:38 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Sep 2010 20:43:38 +0200 Subject: [coreboot] [patch] IEI Kino 780 AM2 mainboard In-Reply-To: <4C8B69F4.50002@gmx.net> References: <20100910233922.30691.qmail@stuge.se> <4C8B69F4.50002@gmx.net> Message-ID: <20100911184338.17286.qmail@stuge.se> Carl-Daniel Hailfinger wrote: > >> - printk(BIOS_INFO, "Mainboard MAHOGANY Enable. dev=0x%p\n", dev); > >> + printk(BIOS_INFO, "Mainboard Kino Enable. dev=0x%p\n", dev); .. > >> struct chip_operations mainboard_ops = { > >> - CHIP_NAME("AMD MAHOGANY Mainboard") > >> - .enable_dev = mahogany_enable, > >> + CHIP_NAME("IEI Kino-780AM2 Mainboard") > >> + .enable_dev = kino_enable, > >> }; > > > > Could the mainboard enable function reuse the CHIP_NAME somehow, or > > maybe both should just use CONFIG_MAINBOARD_PART_NUMBER ? > > I once had such a patch, but I think it was rejected for two reasons: > - grepping is more difficult because you have to match in two stages Maybe make more use of __func__ then. > - building multi-mainboard images means CONFIG_MAINBOARD_PART_NUMBER > is not really meaningful. Maybe it should be set by the build system per mainboard? I think we still some time left before multiboard images, but I also think that the current coreboot infrastructure is a really great starting point for it. I guess it will use the same scheme as fallback at least initially, with some method added for determining the current board, that means building one image per board anyway. //Peter From peter at stuge.se Sat Sep 11 21:59:57 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Sep 2010 21:59:57 +0200 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: References: <4C896959.9080300@gmx.net> <9617B27123C44F56A182F911336057BC@m3a78> <878w38y27j.fsf@taniquetil.gledits.ch> <4CE561505A524326A71B1383A7F61A23@m3a78> Message-ID: <20100911195957.27074.qmail@stuge.se> Marc Jones wrote: > doesn't really explain why gcc doesn't do a rep stos or rep mov > (which should hit the cache)/ That should be an easy optimization > for gcc. Except I don't think it's an optimization performance-wise. But if you enable -Os then I would expect it to use rep stosb. > It also doesn't address why coreboot has a functions when we could > use gcc intrinsic that should be optimized for the architecture > they are built for. Good point! I guess we rolled our own to be less dependent on gcc. I think it would be OK to use gcc's implementations though. //Peter From juhe at iki.fi Sat Sep 11 22:36:16 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Sat, 11 Sep 2010 23:36:16 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> Message-ID: <1284237376.538.69.camel@bart> On Sat, 2010-09-11 at 07:03 -0600, Myles Watson wrote: > So it works with my updated patch, but not with the uma & reserved > patches? Or does it not work at all? Does it still work with your > previous patch set? > > Could you send a full log with the last working version and the first > broken version from this list? > > 1. Your original patches > 2. 5799 + my board patch > 3. 2 + uma.diff > 4. 3 + reserved.diff > > uma.diff & reserved.diff should be independent, so you could try > 2+reserved.diff also > Ok, now I have some test results: * 5792 + my original patches --> boots ok * 5792 + your simplified patches --> boots ok * 5792 + your simplified patches + uma.diff --> boots ok (log attached) * 5792 + your simplified patches + uma.diff + reserved.diff --> does not build, patch seems to be for newer trunk version * 5799 + my original patches --> SATA failure (log attached) * 5799 + your simplified patches --> SATA failure * 5802 + your simplified patch for 5800 --> SATA failure My conclusion from this is that something in the trunk has broken between 5792 and 5799. Comparing the attached logs shows many small differences, most are likely irrelevant, but the following part from SB700 initialization seems relevant: @@ -1226,24 +1237,23 @@ sata_bar2=3028 sata_bar3=3044 sata_bar4=3000 -sata_bar5=d4209000 -SATA port 0 status = 23 -drive detection done after 0 ms -Primary Master device is ready after 1 tries -SATA port 1 status = 0 +sata_bar5=e4209000 +SATA port 0 status = ff +No Primary Master SATA drive on Slot0 +SATA port 1 status = ff No Primary Slave SATA drive on Slot1 -SATA port 2 status = 0 +SATA port 2 status = ff No Secondary Master SATA drive on Slot2 -SATA port 3 status = 0 +SATA port 3 status = ff No Secondary Slave SATA drive on Slot3 It looks like rev 5792 manages to initialize SATA port 0 and detect a drive, whereas rev 5799 does not. The other ports have nothing attached. I tried browsing the difference between trunk 5792 and 5799, but there was nothing obvious to me. Best regards, Juhana Helovuo -------------- next part -------------- A non-text attachment was scrubbed... Name: rev5792+simplified-board-patch+uma-diff.log Type: text/x-log Size: 92824 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rev5799+original-board-patch.log Type: text/x-log Size: 83741 bytes Desc: not available URL: From juhe at iki.fi Sat Sep 11 23:47:15 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Sun, 12 Sep 2010 00:47:15 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <1284237376.538.69.camel@bart> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> Message-ID: <1284241635.538.75.camel@bart> On Sat, 2010-09-11 at 23:36 +0300, Juhana Helovuo wrote: > On Sat, 2010-09-11 at 07:03 -0600, Myles Watson wrote: > > > So it works with my updated patch, but not with the uma & reserved > > patches? Or does it not work at all? Does it still work with your > > previous patch set? > > > > Could you send a full log with the last working version and the first > > broken version from this list? > > > > 1. Your original patches > > 2. 5799 + my board patch > > 3. 2 + uma.diff > > 4. 3 + reserved.diff > > > > uma.diff & reserved.diff should be independent, so you could try > > 2+reserved.diff also > > > > Ok, now I have some test results: > > * 5792 + my original patches --> boots ok > * 5792 + your simplified patches --> boots ok > * 5792 + your simplified patches + uma.diff --> boots ok (log attached) > * 5792 + your simplified patches + uma.diff + reserved.diff --> does not > build, patch seems to be for newer trunk version > > * 5799 + my original patches --> SATA failure (log attached) > * 5799 + your simplified patches --> SATA failure > > * 5802 + your simplified patch for 5800 --> SATA failure > > My conclusion from this is that something in the trunk has broken > between 5792 and 5799. Sorry about spamming the list, but I managed to test a few cases more: * 5795 + your simplified patches --> boots ok * 5795 + your simplified patches + uma.diff + reserved.diff --> boots ok * 5796 + your simplified patches --> SATA failure It seems to me that the patches are ok, but some trunk change from 5795 to 5796 is causing the problems. Best regards, Juhana Helovuo From marcj303 at gmail.com Sun Sep 12 22:16:49 2010 From: marcj303 at gmail.com (Marc Jones) Date: Sun, 12 Sep 2010 14:16:49 -0600 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: <20100911195957.27074.qmail@stuge.se> References: <4C896959.9080300@gmx.net> <9617B27123C44F56A182F911336057BC@m3a78> <878w38y27j.fsf@taniquetil.gledits.ch> <4CE561505A524326A71B1383A7F61A23@m3a78> <20100911195957.27074.qmail@stuge.se> Message-ID: On Sat, Sep 11, 2010 at 1:59 PM, Peter Stuge wrote: > Marc Jones wrote: >> doesn't really explain why gcc doesn't do a rep stos or rep mov >> (which should hit the cache)/ That should be an easy optimization >> for gcc. > > Except I don't think it's an optimization performance-wise. But if > you enable -Os then I would expect it to use rep stosb. > It is an optimzation over a byte copy, which is what the code does. We don't have optimized mem functions. >> It also doesn't address why coreboot has a functions when we could >> use gcc intrinsic that should be optimized for the architecture >> they are built for. > > Good point! I guess we rolled our own to be less dependent on gcc. I > think it would be OK to use gcc's implementations though. Good point, but most compilers have intrinsics for these functions, Do we need a compiler intrinsics layer? Marc -- http://se-eng.com From patrick at georgi-clan.de Sun Sep 12 23:24:36 2010 From: patrick at georgi-clan.de (Patrick Georgi) Date: Sun, 12 Sep 2010 23:24:36 +0200 Subject: [coreboot] rfc - gcc builtins and memset memcpy memmove memcmp In-Reply-To: References: <4C896959.9080300@gmx.net> <9617B27123C44F56A182F911336057BC@m3a78> <878w38y27j.fsf@taniquetil.gledits.ch> <4CE561505A524326A71B1383A7F61A23@m3a78> <20100911195957.27074.qmail@stuge.se> Message-ID: <4C8D4514.2090905@georgi-clan.de> Am 12.09.2010 22:16, schrieb Marc Jones: >> Good point! I guess we rolled our own to be less dependent on gcc. I >> think it would be OK to use gcc's implementations though. > > Good point, but most compilers have intrinsics for these functions, Do > we need a compiler intrinsics layer? I guess the original statement is to be read as "less dependent on particular instances of gcc" (ie. distro compilers, bugs in certain gcc versions). coreboot already is way too gnu specific in its use of binutils and gcc features that supporting other compilers won't make sense. The gcc intrinsics should be relatively stable, so no "layer" is necessary, I think. Regards, Patrick From arne.gleditsch at numascale.com Mon Sep 13 09:40:20 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Mon, 13 Sep 2010 09:40:20 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: (Marc Jones's message of "Sat, 11 Sep 2010 11:48:37 -0600") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <4C88AF57.7010002@georgi-clan.de> <87k4mvs02h.fsf@taniquetil.gledits.ch> <4C88B88E.1070801@georgi-clan.de> <874odwy200.fsf@taniquetil.gledits.ch> Message-ID: <87aanmrt0b.fsf@taniquetil.gledits.ch> Marc Jones writes: >> I thought the decompress itself needed to run from ROM for us to see >> this. ?What kind of video bios is this; is it embedded in the coreboot >> image or is it hosted on an external video card? ?I have a vague >> recollection of there being a facility or hook that allowed option roms >> to copy themselves from ROM to RAM, could that be involved here? > > This is a lzma compressed rom embeeded in the coreboot image. Then I don't think I quite understand what happens... The ramstage contains its own copy of ulzma, does it not? Does the copy-to-stack approach actually help in your case? How about delaying the clear ClLinesToNbDis-operation? -- Arne. From wt at penguintechs.org Mon Sep 13 09:40:27 2010 From: wt at penguintechs.org (Warren Turkal) Date: Mon, 13 Sep 2010 00:40:27 -0700 Subject: [coreboot] BUG REPORT: parallel build broken Message-ID: I couldn't file this bug report in the trac. It looked like some reCAPTCHA thing was failing. Please see below. Thanks, wt See the capture from my terminal below. I "make distclean." Then, I save a default config from menuconfig. Then, I "make -j8," which fails. A second "make -j8" works. This happens on a fully synced working copy. {{{ $ make distclean $ make menuconfig # # configuration written to .config # *** End of coreboot configuration. *** Execute 'make' to build or try 'make help'. }}} *NOTE: I saved a default config by exiting menuconfig and saving the config. This config includes support for qemu.* {{{ $ make -j8 HOSTCC util/romcc/romcc (this may take a while) ... CC southbridge/intel/i82371eb/i82371eb_isa.driver.o In file included from src/console/uart8250_console.c:3: src/include/pc80/mc146818rtc.h:89:26: error: option_table.h: No such file or directory CC southbridge/intel/i82371eb/i82371eb_ide.driver.o make: *** [build/console/uart8250_console.driver.o] Error 1 make: *** Waiting for unfinished jobs.... In file included from src/southbridge/intel/i82371eb/i82371eb_isa.c:27: src/include/pc80/mc146818rtc.h:89:26: error: CC southbridge/intel/i82371eb/i82371eb_usb.driver.o option_table.h: No such file or directory make: *** [build/southbridge/intel/i82371eb/i82371eb_isa.driver.o] Error 1 }}} Epic fail {{{ $ make -j8 ROMCC mainboard/emulation/qemu-x86/bootblock.inc ... PAYLOAD \e[1;31mnone (as specified by user)\e[0m CBFSPRINT coreboot.rom coreboot.rom: 256 kB, bootblocksize 658, romsize 262144, offset 0x0 Alignment: 64 bytes Name Offset Type Size fallback/romstage 0x0 stage 7937 fallback/coreboot_ram 0x1f40 stage 27090 (empty) 0x8980 null 226214 $ }}} Epic success. :) From arne.gleditsch at numascale.com Mon Sep 13 10:51:08 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Mon, 13 Sep 2010 10:51:08 +0200 Subject: [coreboot] AMD cache setup is broken In-Reply-To: (Scott Duplichan's message of "Thu, 9 Sep 2010 10:02:58 -0500") References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <87occ7s0gf.fsf@taniquetil.gledits.ch> Message-ID: <8762yarpqb.fsf@taniquetil.gledits.ch> "Scott Duplichan" writes: > I think it would be best to clear bit 35 of msr c001_102a in the AP > cores as well as the BSP core. Otherwise, the OS might see AP cores > having slightly lower performance than the BSP core. This bit affects > family 10h revC and newer (45 nm). Ok, so here's a patch adding this. Clearing bit 35 is done unconditionally for all fam10 cpus, is that ok? Setting is done based on processor type in defaults.h, as before. Signed-off-by: Arne Georg Gleditsch -- Arne. -------------- next part -------------- A non-text attachment was scrubbed... Name: bu_cfg2_35.diff Type: text/x-diff Size: 1149 bytes Desc: not available URL: From arne.gleditsch at numascale.com Mon Sep 13 14:36:36 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Mon, 13 Sep 2010 14:36:36 +0200 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87fwxix8im.fsf@taniquetil.gledits.ch> (Arne Georg Gleditsch's message of "Fri, 10 Sep 2010 11:17:21 +0200") References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> <874odztlt7.fsf@taniquetil.gledits.ch> <87fwxix8im.fsf@taniquetil.gledits.ch> Message-ID: <87y6b5rfaj.fsf@taniquetil.gledits.ch> Arne Georg Gleditsch writes: >> - RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, >> + /* The following operation hangs when performed via MMCFG: >> + pci_read_config32(romcc): 00010000:0078: 20040000 >> + setup_resource_map_x_offset: 10000, 78: 20040000 >> + pci_write_config32(romcc): 00010000:0078: 19040000 >> + (hang) >> + Response missing? */ >> + /* RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, */ >> >> I forgot to ask if you'd tried setting the SyncOnWdError bit (20) in >> function 3, register 0x44. That could help further debug this >> problem. For me it caused a reboot instead of a hang when there was a >> response missing. Bit 21 could also be helpful. > > I can have a look. I won't get a chance until Monday, though. Ah, I've just stumbled across something. src/mainboard/tyan/s2912_fam10/romstage.c:sio_setup does: byte = pci_read_config8(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b); byte |= 0x20; pci_write_config8(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b, byte); It appears that the offending RES_PCI_IO line is not so much hanging the system as disabling the serial console. Furthermore, the reason this does not happen when using pio-based config space accesses seems to be that several functions, for instance precisely sio_setup, are using pci_read/write_config before init_cpus has run and thus begore the MMCONF BAR is set up. This means these accesses are effectively ignored when MMCONF is enabled. Some of these are apparently required for the RES_PCI_IO in question to be set without affecting the serial output. Rather than hunt around and try to change all config accesses that might run before init_cpus to explicit pio-accesses, I've moved the BAR init to run as early as possible, in cache_as_ram. With this change, I can re-insert the RES_PCI_IO wihtout ill effects. > We could fall back to that, if we want to keep it. FWIW, Ed Swierk had > some input on the semantics of this register the last time this came up: > http://thread.gmane.org/gmane.linux.bios/57708/focus=59900 (The correct link to Ed's post is http://thread.gmane.org/gmane.linux.bios/57708/focus=58810) -- Arne. From arne.gleditsch at numascale.com Mon Sep 13 14:44:23 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Mon, 13 Sep 2010 14:44:23 +0200 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87y6b5rfaj.fsf@taniquetil.gledits.ch> (Arne Georg Gleditsch's message of "Mon, 13 Sep 2010 14:36:36 +0200") References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> <874odztlt7.fsf@taniquetil.gledits.ch> <87fwxix8im.fsf@taniquetil.gledits.ch> <87y6b5rfaj.fsf@taniquetil.gledits.ch> Message-ID: <87tyltrexk.fsf@taniquetil.gledits.ch> Arne Georg Gleditsch writes: > With this change, I can re-insert the RES_PCI_IO wihtout ill effects. Move initialization of MMCONF BAR to cache_as_ram setup phase, in order to make sure MMCONF is set up before use. Otherwise, PCI config accesses run before init_cpus() will be lost if MMCONF is enabled (unless explicitly done as port-based accesses). This obsoletes removal of RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78) in mcp55_early_setup, so reinsert. Signed-off-by: Arne Georg Gleditsch -- Arne. -------------- next part -------------- A non-text attachment was scrubbed... Name: mmconf-patch-003.diff Type: text/x-diff Size: 3490 bytes Desc: not available URL: From mylesgw at gmail.com Mon Sep 13 14:52:23 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 06:52:23 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87tyltrexk.fsf@taniquetil.gledits.ch> References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com><87pr25dkxx.fsf@taniquetil.gledits.ch><87d3y3erev.fsf@taniquetil.gledits.ch><874ohvm1yj.fsf_-_@taniquetil.gledits.ch><4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de><87wrrpipw6.fsf@taniquetil.gledits.ch><87lj7ctk88.fsf@taniquetil.gledits.ch><87k4mwxou5.fsf@taniquetil.gledits.ch><87hbhztm8m.fsf@taniquetil.gledits.ch><874odztlt7.fsf@taniquetil.gledits.ch><87fwxix8im.fsf@taniquetil.gledits.ch><87y6b5rfaj.fsf@taniquetil.gledits.ch> <87tyltrexk.fsf@taniquetil.gledits.ch> Message-ID: <9A2D7428C1DF4E73AEF7E55AB74250DF@chimp> > Arne Georg Gleditsch writes: > > With this change, I can re-insert the RES_PCI_IO wihtout ill effects. > > Move initialization of MMCONF BAR to cache_as_ram setup phase, in order > to make sure MMCONF is set up before use. Otherwise, PCI config > accesses run before init_cpus() will be lost if MMCONF is enabled > (unless explicitly done as port-based accesses). > > This obsoletes removal of RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78) in > mcp55_early_setup, so reinsert. > > Signed-off-by: Arne Georg Gleditsch Acked-by: Myles Watson Thanks for tracking it down! Myles From svn at coreboot.org Mon Sep 13 15:14:49 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 15:14:49 +0200 Subject: [coreboot] [commit] r5803 - in trunk/src: mainboard/getac/p470 mainboard/ibase/mb899 mainboard/intel/d945gclf mainboard/kontron/986lcd-m mainboard/roda/rk886ex northbridge/intel/i945 Message-ID: Author: myles Date: Mon Sep 13 15:14:48 2010 New Revision: 5803 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5803 Log: Convert i945 boards to use reserved resources instead of directly adding coreboot table entries in every mainboard. Signed-off-by: Myles Watson Acked-by: Peter Stuge Modified: trunk/src/mainboard/getac/p470/Kconfig trunk/src/mainboard/getac/p470/mainboard.c trunk/src/mainboard/ibase/mb899/Kconfig trunk/src/mainboard/ibase/mb899/mainboard.c trunk/src/mainboard/intel/d945gclf/Kconfig trunk/src/mainboard/intel/d945gclf/mainboard.c trunk/src/mainboard/kontron/986lcd-m/Kconfig trunk/src/mainboard/kontron/986lcd-m/mainboard.c trunk/src/mainboard/roda/rk886ex/mainboard.c trunk/src/northbridge/intel/i945/northbridge.c Modified: trunk/src/mainboard/getac/p470/Kconfig ============================================================================== --- trunk/src/mainboard/getac/p470/Kconfig Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/getac/p470/Kconfig Mon Sep 13 15:14:48 2010 (r5803) @@ -36,7 +36,6 @@ select HAVE_HARD_RESET select HAVE_ACPI_RESUME select HAVE_ACPI_SLIC - select HAVE_MAINBOARD_RESOURCES select MMCONF_SUPPORT select AP_IN_SIPI_WAIT select UDELAY_LAPIC Modified: trunk/src/mainboard/getac/p470/mainboard.c ============================================================================== --- trunk/src/mainboard/getac/p470/mainboard.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/getac/p470/mainboard.c Mon Sep 13 15:14:48 2010 (r5803) @@ -98,11 +98,6 @@ verb_setup(); } -int add_mainboard_resources(struct lb_memory *mem) -{ - return add_northbridge_resources(mem); -} - struct chip_operations mainboard_ops = { CHIP_NAME("Getac P470 Rugged Notebook") .enable_dev = mainboard_enable, Modified: trunk/src/mainboard/ibase/mb899/Kconfig ============================================================================== --- trunk/src/mainboard/ibase/mb899/Kconfig Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/ibase/mb899/Kconfig Mon Sep 13 15:14:48 2010 (r5803) @@ -15,7 +15,6 @@ select HAVE_HARD_RESET select HAVE_OPTION_TABLE select HAVE_ACPI_RESUME - select HAVE_MAINBOARD_RESOURCES select MMCONF_SUPPORT select HAVE_SMI_HANDLER select BOARD_ROMSIZE_KB_512 Modified: trunk/src/mainboard/ibase/mb899/mainboard.c ============================================================================== --- trunk/src/mainboard/ibase/mb899/mainboard.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/ibase/mb899/mainboard.c Mon Sep 13 15:14:48 2010 (r5803) @@ -29,11 +29,6 @@ #include #include "chip.h" -int add_mainboard_resources(struct lb_memory *mem) -{ - return add_northbridge_resources(mem); -} - #if CONFIG_PCI_OPTION_ROM_RUN_YABEL static int int15_handler(void) { Modified: trunk/src/mainboard/intel/d945gclf/Kconfig ============================================================================== --- trunk/src/mainboard/intel/d945gclf/Kconfig Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/intel/d945gclf/Kconfig Mon Sep 13 15:14:48 2010 (r5803) @@ -36,7 +36,6 @@ select HAVE_MP_TABLE select HAVE_ACPI_TABLES select HAVE_ACPI_RESUME - select HAVE_MAINBOARD_RESOURCES select MMCONF_SUPPORT select HAVE_ACPI_TABLES select HAVE_SMI_HANDLER Modified: trunk/src/mainboard/intel/d945gclf/mainboard.c ============================================================================== --- trunk/src/mainboard/intel/d945gclf/mainboard.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/intel/d945gclf/mainboard.c Mon Sep 13 15:14:48 2010 (r5803) @@ -23,11 +23,6 @@ #include #include "chip.h" -int add_mainboard_resources(struct lb_memory *mem) -{ - return add_northbridge_resources(mem); -} - struct chip_operations mainboard_ops = { CHIP_NAME("Intel D945GCLF Mainboard") }; Modified: trunk/src/mainboard/kontron/986lcd-m/Kconfig ============================================================================== --- trunk/src/mainboard/kontron/986lcd-m/Kconfig Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/kontron/986lcd-m/Kconfig Mon Sep 13 15:14:48 2010 (r5803) @@ -15,7 +15,6 @@ select HAVE_OPTION_TABLE select HAVE_HARD_RESET select HAVE_ACPI_RESUME - select HAVE_MAINBOARD_RESOURCES select MMCONF_SUPPORT select HAVE_SMI_HANDLER select BOARD_ROMSIZE_KB_1024 Modified: trunk/src/mainboard/kontron/986lcd-m/mainboard.c ============================================================================== --- trunk/src/mainboard/kontron/986lcd-m/mainboard.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/kontron/986lcd-m/mainboard.c Mon Sep 13 15:14:48 2010 (r5803) @@ -20,20 +20,13 @@ #include #include #include -#include #if defined(CONFIG_PCI_OPTION_ROM_RUN_YABEL) && CONFIG_PCI_OPTION_ROM_RUN_YABEL #include #endif #include #include -#include #include "chip.h" -int add_mainboard_resources(struct lb_memory *mem) -{ - return add_northbridge_resources(mem); -} - #if defined(CONFIG_PCI_OPTION_ROM_RUN_YABEL) && CONFIG_PCI_OPTION_ROM_RUN_YABEL static int int15_handler(void) { Modified: trunk/src/mainboard/roda/rk886ex/mainboard.c ============================================================================== --- trunk/src/mainboard/roda/rk886ex/mainboard.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/roda/rk886ex/mainboard.c Mon Sep 13 15:14:48 2010 (r5803) @@ -134,11 +134,6 @@ #endif } -int add_mainboard_resources(struct lb_memory *mem) -{ - return add_northbridge_resources(mem); -} - struct chip_operations mainboard_ops = { CHIP_NAME("Roda Computer GmbH RK886EX Rugged Notebook (ROCKY3+)") .enable_dev = mainboard_enable, Modified: trunk/src/northbridge/intel/i945/northbridge.c ============================================================================== --- trunk/src/northbridge/intel/i945/northbridge.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/northbridge/intel/i945/northbridge.c Mon Sep 13 15:14:48 2010 (r5803) @@ -70,20 +70,26 @@ /* IDG memory */ uint64_t uma_memory_base=0, uma_memory_size=0; -int add_northbridge_resources(struct lb_memory *mem) +static void add_fixed_resources(struct device *dev, int index) { + struct resource *resource; u32 pcie_config_base, pcie_config_size; printk(BIOS_DEBUG, "Adding UMA memory area\n"); - lb_add_memory_range(mem, LB_MEM_RESERVED, - uma_memory_base, uma_memory_size); - - printk(BIOS_DEBUG, "Adding PCIe config bar\n"); - get_pcie_bar(&pcie_config_base, &pcie_config_size); - lb_add_memory_range(mem, LB_MEM_RESERVED, - pcie_config_base, pcie_config_size); + resource = new_resource(dev, index); + resource->base = (resource_t) uma_memory_base; + resource->size = (resource_t) uma_memory_size; + resource->flags = IORESOURCE_MEM | IORESOURCE_RESERVE | + IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; - return 0; + if (get_pcie_bar(&pcie_config_base, &pcie_config_size)) { + printk(BIOS_DEBUG, "Adding PCIe config bar\n"); + resource = new_resource(dev, index+1); + resource->base = (resource_t) pcie_config_base; + resource->size = (resource_t) pcie_config_size; + resource->flags = IORESOURCE_MEM | IORESOURCE_RESERVE | + IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; + } } static void ram_resource(device_t dev, unsigned long index, unsigned long basek, @@ -208,6 +214,8 @@ ram_resource(dev, 5, 4096 * 1024, tomk - 4 * 1024 * 1024); } + add_fixed_resources(dev, 6); + assign_resources(dev->link_list); #if CONFIG_WRITE_HIGH_TABLES==1 From mylesgw at gmail.com Mon Sep 13 15:15:52 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 07:15:52 -0600 Subject: [coreboot] [PATCH] i945 mainboard resources In-Reply-To: <20100910220124.11041.qmail@stuge.se> References: <20100910220124.11041.qmail@stuge.se> Message-ID: On Fri, Sep 10, 2010 at 4:01 PM, Peter Stuge wrote: > Myles Watson wrote: >> I think we should get rid of HAVE_MAINBOARD_RESOURCES. >> >> Here's a patch that does that for i945 boards. ?The Roda board >> provided add_mainboard_resources(), but it was never called because it >> didn't select HAVE_MAINBOARD_RESOURCES in Kconfig. >> >> Testing & suggestions welcome. >> >> Signed-off-by: Myles Watson > > Acked-by: Peter Stuge Rev 5803. Thanks, Myles From mylesgw at gmail.com Mon Sep 13 15:20:53 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 07:20:53 -0600 Subject: [coreboot] BUG REPORT: parallel build broken In-Reply-To: References: Message-ID: > In file included from src/southbridge/intel/i82371eb/i82371eb_isa.c:27: > src/include/pc80/mc146818rtc.h:89:26: error: ? ? CC > southbridge/intel/i82371eb/i82371eb_usb.driver.o > option_table.h: No such file or directory > make: *** [build/southbridge/intel/i82371eb/i82371eb_isa.driver.o] Error 1 Thanks for the bug report. There is a problem with dependency checking which we haven't worked through yet. As long as the option table utility is built before you invoke make it will work. Thanks, Myles From svn at coreboot.org Mon Sep 13 15:23:22 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 15:23:22 +0200 Subject: [coreboot] [commit] r5804 - trunk/src/northbridge/amd/amdfam10 Message-ID: Author: myles Date: Mon Sep 13 15:23:20 2010 New Revision: 5804 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5804 Log: Fix a typo reported by Sylvain Hitier. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/northbridge/amd/amdfam10/Kconfig Modified: trunk/src/northbridge/amd/amdfam10/Kconfig ============================================================================== --- trunk/src/northbridge/amd/amdfam10/Kconfig Mon Sep 13 15:14:48 2010 (r5803) +++ trunk/src/northbridge/amd/amdfam10/Kconfig Mon Sep 13 15:23:20 2010 (r5804) @@ -95,7 +95,7 @@ default n depends on NORTHBRIDGE_AMD_AMDFAM10 -if DIMM_FB_DIMM +if DIMM_FBDIMM config DIMM_SUPPORT hex default 0x0110 From svn at coreboot.org Mon Sep 13 16:00:04 2010 From: svn at coreboot.org (coreboot tracker) Date: Mon, 13 Sep 2010 16:00:04 +0200 Subject: [coreboot] Trac reminder: list of new ticket(s) Message-ID: An HTML attachment was scrubbed... URL: From svn at coreboot.org Mon Sep 13 16:43:02 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 16:43:02 +0200 Subject: [coreboot] [commit] r5805 - in trunk/src: devices southbridge/amd/sb700 Message-ID: Author: myles Date: Mon Sep 13 16:43:02 2010 New Revision: 5805 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5805 Log: Print an error and correct pci scan limits. Skip sb700 ISA DMA init if needed. Signed-off-by: Juhana Helovuo Acked-by: Myles Watson Modified: trunk/src/devices/pci_device.c trunk/src/southbridge/amd/sb700/Kconfig trunk/src/southbridge/amd/sb700/sb700_lpc.c Modified: trunk/src/devices/pci_device.c ============================================================================== --- trunk/src/devices/pci_device.c Mon Sep 13 15:23:20 2010 (r5804) +++ trunk/src/devices/pci_device.c Mon Sep 13 16:43:02 2010 (r5805) @@ -1019,6 +1019,14 @@ printk(BIOS_DEBUG, "PCI: pci_scan_bus for bus %02x\n", bus->secondary); #endif + // Maximum sane devfn is 0xFF + if (max_devfn > 0xff) { + printk(BIOS_ERR, "PCI: pci_scan_bus limits devfn %x - devfn %x\n", + min_devfn, max_devfn ); + printk(BIOS_ERR, "PCI: pci_scan_bus upper limit too big. Using 0xff.\n"); + max_devfn=0xff; + } + old_devices = bus->children; bus->children = NULL; Modified: trunk/src/southbridge/amd/sb700/Kconfig ============================================================================== --- trunk/src/southbridge/amd/sb700/Kconfig Mon Sep 13 15:23:20 2010 (r5804) +++ trunk/src/southbridge/amd/sb700/Kconfig Mon Sep 13 16:43:02 2010 (r5805) @@ -20,3 +20,9 @@ config SOUTHBRIDGE_AMD_SB700 bool select IOAPIC + +config SOUTHBRIDGE_AMD_SB700_SKIP_ISA_DMA_INIT + bool + default n + depends on SOUTHBRIDGE_AMD_SB700 + Modified: trunk/src/southbridge/amd/sb700/sb700_lpc.c ============================================================================== --- trunk/src/southbridge/amd/sb700/sb700_lpc.c Mon Sep 13 15:23:20 2010 (r5804) +++ trunk/src/southbridge/amd/sb700/sb700_lpc.c Mon Sep 13 16:43:02 2010 (r5805) @@ -42,7 +42,11 @@ pci_write_config32(sm_dev, 0x64, dword); /* Initialize isa dma */ +#if CONFIG_SOUTHBRIDGE_AMD_SB700_SKIP_ISA_DMA_INIT + printk(BIOS_DEBUG, "Skipping isa_dma_init() to avoid getting stuck.\n"); +#else isa_dma_init(); +#endif /* Enable DMA transaction on the LPC bus */ byte = pci_read_config8(dev, 0x40); From svn at coreboot.org Mon Sep 13 16:47:23 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 16:47:23 +0200 Subject: [coreboot] [commit] r5806 - in trunk/src: arch/i386/boot include/cpu/x86 Message-ID: Author: myles Date: Mon Sep 13 16:47:22 2010 New Revision: 5806 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5806 Log: Generate multiboot tables from coreboot tables. Signed-off-by: Juhana Helovuo Acked-by: Myles Watson Modified: trunk/src/arch/i386/boot/multiboot.c trunk/src/arch/i386/boot/tables.c trunk/src/include/cpu/x86/multiboot.h Modified: trunk/src/arch/i386/boot/multiboot.c ============================================================================== --- trunk/src/arch/i386/boot/multiboot.c Mon Sep 13 16:43:02 2010 (r5805) +++ trunk/src/arch/i386/boot/multiboot.c Mon Sep 13 16:47:22 2010 (r5806) @@ -22,62 +22,16 @@ #include #include #include +#include +#include -static struct multiboot_mmap_entry *mb_mem; struct multiboot_info *mbi = NULL; -static struct { - u64 addr; - u64 len; -} reserved_mem[2]; - -static void build_mb_mem_range_nooverlap(u64 addr, u64 len) -{ - int i; - for (i = 0; i < sizeof(reserved_mem) / sizeof(reserved_mem[0]); i++) { - /* free region fully contained in reserved region, abort */ - if (addr >= reserved_mem[i].addr && addr + len <= reserved_mem[i].addr + reserved_mem[i].len) - return; - /* reserved region splits free region */ - if (addr < reserved_mem[i].addr && addr + len > reserved_mem[i].addr + reserved_mem[i].len) { - build_mb_mem_range_nooverlap(addr, reserved_mem[i].addr - addr); - build_mb_mem_range_nooverlap(reserved_mem[i].addr + reserved_mem[i].len, (addr + len) - (reserved_mem[i].addr + reserved_mem[i].len)); - return; - } - /* left overlap */ - if (addr < reserved_mem[i].addr + reserved_mem[i].len && addr + len > reserved_mem[i].addr + reserved_mem[i].len) { - len += addr; - addr = reserved_mem[i].addr + reserved_mem[i].len; - len -= addr; - /* len += addr - old_addr */ - continue; - } - /* right overlap */ - if (addr < reserved_mem[i].addr && addr + len > reserved_mem[i].addr) { - len = reserved_mem[i].addr - addr; - continue; - } - /* none of the above, just add it */ - } - - mb_mem->addr = addr; - mb_mem->len = len; - mb_mem->type = 1; - mb_mem->size = sizeof(*mb_mem) - sizeof(mb_mem->size); - mb_mem++; -} - -static void build_mb_mem_range(void *gp, struct device *dev, struct resource *res) -{ - build_mb_mem_range_nooverlap(res->base, res->size); -} - -#define ROUND(_r,_a) (((_r) + (((_a) - 1))) & ~((_a) - 1)) - -unsigned long write_multiboot_info( - unsigned long low_table_start, unsigned long low_table_end, - unsigned long rom_table_start, unsigned long rom_table_end) +unsigned long write_multiboot_info(unsigned long rom_table_end) { + static struct multiboot_mmap_entry *mb_mem; + struct lb_memory* coreboot_table; + int entries; int i; mbi = (struct multiboot_info *)rom_table_end; @@ -88,26 +42,31 @@ mbi->mmap_addr = (u32) rom_table_end; mb_mem = (struct multiboot_mmap_entry *)rom_table_end; - /* FIXME This code is broken, it does not know about high memory - * tables, nor does it reserve the coreboot table area. - */ - /* reserved regions */ - reserved_mem[0].addr = low_table_start; - reserved_mem[0].len = ROUND(low_table_end - low_table_start, 4096); - reserved_mem[1].addr = rom_table_start; - reserved_mem[1].len = ROUND(rom_table_end - rom_table_start, 4096); - - for (i = 0; i < sizeof(reserved_mem) / sizeof(reserved_mem[0]); i++) { - mb_mem->addr = reserved_mem[i].addr; - mb_mem->len = reserved_mem[i].len; - mb_mem->type = 2; - mb_mem->size = sizeof(*mb_mem) - sizeof(mb_mem->size); - mb_mem++; + /* copy regions from coreboot tables */ + coreboot_table = get_lb_mem(); + entries = (coreboot_table->size - sizeof(*coreboot_table))/sizeof(coreboot_table->map[0]); + + if (coreboot_table == NULL || entries < 1) { + printk(BIOS_INFO, "%s: Cannot find coreboot table.\n", __func__); + return (unsigned long) mb_mem; } - /* free regions */ - search_global_resources( IORESOURCE_MEM | IORESOURCE_CACHEABLE, - IORESOURCE_MEM | IORESOURCE_CACHEABLE, build_mb_mem_range, NULL); + for (i = 0; i < entries; i++) { + uint64_t entry_start = unpack_lb64(coreboot_table->map[i].start); + uint64_t entry_size = unpack_lb64(coreboot_table->map[i].size); + mb_mem->addr = entry_start; + mb_mem->len = entry_size; + switch (coreboot_table->map[i].type) { + case LB_MEM_RAM: + mb_mem->type = MULTIBOOT_MEMORY_AVAILABLE; + break; + default: // anything other than usable RAM + mb_mem->type = MULTIBOOT_MEMORY_RESERVED; + break; + } + mb_mem->size = sizeof(*mb_mem) - sizeof(mb_mem->size); + mb_mem++; + } mbi->mmap_length = ((u32) mb_mem) - mbi->mmap_addr; mbi->flags |= MB_INFO_MEM_MAP; Modified: trunk/src/arch/i386/boot/tables.c ============================================================================== --- trunk/src/arch/i386/boot/tables.c Mon Sep 13 16:43:02 2010 (r5805) +++ trunk/src/arch/i386/boot/tables.c Mon Sep 13 16:47:22 2010 (r5806) @@ -179,14 +179,6 @@ #endif -#if CONFIG_MULTIBOOT - post_code(0x9d); - - /* The Multiboot information structure */ - rom_table_end = write_multiboot_info( - low_table_start, low_table_end, - rom_table_start, rom_table_end); -#endif #define MAX_COREBOOT_TABLE_SIZE (8 * 1024) post_code(0x9d); @@ -210,8 +202,9 @@ new_high_table_pointer - high_table_pointer); } else { /* The coreboot table must be in 0-4K or 960K-1M */ - write_coreboot_table(low_table_start, low_table_end, - rom_table_start, rom_table_end); + rom_table_end = write_coreboot_table( + low_table_start, low_table_end, + rom_table_start, rom_table_end); } post_code(0x9e); @@ -224,6 +217,13 @@ cbmem_add(CBMEM_ID_RESUME, 1024 * (1024-64)); #endif +#if CONFIG_MULTIBOOT + post_code(0x9d); + + /* The Multiboot information structure */ + write_multiboot_info(rom_table_end); +#endif + // Remove before sending upstream cbmem_list(); Modified: trunk/src/include/cpu/x86/multiboot.h ============================================================================== --- trunk/src/include/cpu/x86/multiboot.h Mon Sep 13 16:43:02 2010 (r5805) +++ trunk/src/include/cpu/x86/multiboot.h Mon Sep 13 16:47:22 2010 (r5806) @@ -167,6 +167,9 @@ uint16_t vbe_interface_len; }; +#define MULTIBOOT_MEMORY_AVAILABLE 1 +#define MULTIBOOT_MEMORY_RESERVED 2 + struct multiboot_mmap_entry { uint32_t size; uint64_t addr; @@ -176,6 +179,6 @@ extern struct multiboot_info *mbi; -unsigned long write_multiboot_info(unsigned long, unsigned long, unsigned long, unsigned long); +unsigned long write_multiboot_info(unsigned long rom_table_end); #endif From svn at coreboot.org Mon Sep 13 16:49:03 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 16:49:03 +0200 Subject: [coreboot] [commit] r5807 - trunk/src/northbridge/amd/amdfam10 Message-ID: Author: myles Date: Mon Sep 13 16:49:02 2010 New Revision: 5807 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5807 Log: Port k8 UMA handling to fam10. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c ============================================================================== --- trunk/src/northbridge/amd/amdfam10/northbridge.c Mon Sep 13 16:47:22 2010 (r5806) +++ trunk/src/northbridge/amd/amdfam10/northbridge.c Mon Sep 13 16:49:02 2010 (r5807) @@ -865,6 +865,9 @@ #if CONFIG_WRITE_HIGH_TABLES==1 #define HIGH_TABLES_SIZE 64 // maximum size of high tables in KB extern uint64_t high_tables_base, high_tables_size; +#if CONFIG_GFXUMA == 1 +extern uint64_t uma_memory_base, uma_memory_size; +#endif #endif static void amdfam10_domain_set_resources(device_t dev) @@ -1038,7 +1041,11 @@ #if CONFIG_WRITE_HIGH_TABLES==1 if (high_tables_base==0) { /* Leave some space for ACPI, PIRQ and MP tables */ +#if CONFIG_GFXUMA == 1 + high_tables_base = uma_memory_base - (HIGH_TABLES_SIZE * 1024); +#else high_tables_base = (mmio_basek - HIGH_TABLES_SIZE) * 1024; +#endif high_tables_size = HIGH_TABLES_SIZE * 1024; printk(BIOS_DEBUG, " split: %dK table at =%08llx\n", HIGH_TABLES_SIZE, high_tables_base); @@ -1073,7 +1080,11 @@ i, mmio_basek, basek, limitk); if (high_tables_base==0) { /* Leave some space for ACPI, PIRQ and MP tables */ +#if CONFIG_GFXUMA == 1 + high_tables_base = uma_memory_base - (HIGH_TABLES_SIZE * 1024); +#else high_tables_base = (limitk - HIGH_TABLES_SIZE) * 1024; +#endif high_tables_size = HIGH_TABLES_SIZE * 1024; } #endif From svn at coreboot.org Mon Sep 13 16:50:22 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 16:50:22 +0200 Subject: [coreboot] [commit] r5808 - trunk/src/northbridge/amd/amdfam10 Message-ID: Author: myles Date: Mon Sep 13 16:50:20 2010 New Revision: 5808 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5808 Log: Add reserved areas for fam10. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c ============================================================================== --- trunk/src/northbridge/amd/amdfam10/northbridge.c Mon Sep 13 16:49:02 2010 (r5807) +++ trunk/src/northbridge/amd/amdfam10/northbridge.c Mon Sep 13 16:50:20 2010 (r5808) @@ -865,9 +865,22 @@ #if CONFIG_WRITE_HIGH_TABLES==1 #define HIGH_TABLES_SIZE 64 // maximum size of high tables in KB extern uint64_t high_tables_base, high_tables_size; +#endif + #if CONFIG_GFXUMA == 1 extern uint64_t uma_memory_base, uma_memory_size; -#endif + +static void add_uma_resource(struct device *dev, int index) +{ + struct resource *resource; + + printk(BIOS_DEBUG, "Adding UMA memory area\n"); + resource = new_resource(dev, index); + resource->base = (resource_t) uma_memory_base; + resource->size = (resource_t) uma_memory_size; + resource->flags = IORESOURCE_MEM | IORESOURCE_RESERVE | + IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; +} #endif static void amdfam10_domain_set_resources(device_t dev) @@ -1090,6 +1103,10 @@ #endif } +#if CONFIG_GFXUMA == 1 + add_uma_resource(dev, 7); +#endif + for(link = dev->link_list; link; link = link->next) { if (link->children) { assign_resources(link); From svn at coreboot.org Mon Sep 13 16:51:29 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 16:51:29 +0200 Subject: [coreboot] [commit] r5809 - in trunk/src/mainboard/asus: . m4a785-m Message-ID: Author: myles Date: Mon Sep 13 16:51:26 2010 New Revision: 5809 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5809 Log: Add support for Asus M4A785-M. Signed-off-by: Juhana Helovuo Acked-by: Myles Watson Added: trunk/src/mainboard/asus/m4a785-m/ - copied from r5792, trunk/src/mainboard/amd/tilapia_fam10/ Replaced: trunk/src/mainboard/asus/m4a785-m/Kconfig - copied, changed from r5800, trunk/src/mainboard/amd/tilapia_fam10/Kconfig Modified: trunk/src/mainboard/asus/Kconfig trunk/src/mainboard/asus/m4a785-m/devicetree.cb trunk/src/mainboard/asus/m4a785-m/irq_tables.c trunk/src/mainboard/asus/m4a785-m/mainboard.c trunk/src/mainboard/asus/m4a785-m/romstage.c Modified: trunk/src/mainboard/asus/Kconfig ============================================================================== --- trunk/src/mainboard/asus/Kconfig Mon Sep 13 16:50:20 2010 (r5808) +++ trunk/src/mainboard/asus/Kconfig Mon Sep 13 16:51:26 2010 (r5809) @@ -27,6 +27,8 @@ bool "A8V-E SE" config BOARD_ASUS_M2V_MX_SE bool "M2V-MX SE" +config BOARD_ASUS_M4A785M + bool "M4A785-M" config BOARD_ASUS_MEW_AM bool "MEW-AM" config BOARD_ASUS_MEW_VM @@ -49,6 +51,7 @@ source "src/mainboard/asus/a8n_e/Kconfig" source "src/mainboard/asus/a8v-e_se/Kconfig" source "src/mainboard/asus/m2v-mx_se/Kconfig" +source "src/mainboard/asus/m4a785-m/Kconfig" source "src/mainboard/asus/mew-am/Kconfig" source "src/mainboard/asus/mew-vm/Kconfig" source "src/mainboard/asus/p2b/Kconfig" Copied and modified: trunk/src/mainboard/asus/m4a785-m/Kconfig (from r5800, trunk/src/mainboard/amd/tilapia_fam10/Kconfig) ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/Kconfig Fri Sep 10 20:33:24 2010 (r5800, copy source) +++ trunk/src/mainboard/asus/m4a785-m/Kconfig Mon Sep 13 16:51:26 2010 (r5809) @@ -1,21 +1,20 @@ -if BOARD_AMD_TILAPIA_FAM10 +if BOARD_ASUS_M4A785M config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select ARCH_X86 select CPU_AMD_SOCKET_AM3 - select DIMM_DDR3 - select DIMM_REGISTERED + select DIMM_DDR2 select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_RS780 select SOUTHBRIDGE_AMD_SB700 - select SUPERIO_ITE_IT8718F + select SOUTHBRIDGE_AMD_SB700_SKIP_ISA_DMA_INIT + select SUPERIO_ITE_IT8712F select BOARD_HAS_FADT select HAVE_BUS_CONFIG select HAVE_OPTION_TABLE select GENERATE_PIRQ_TABLE select GENERATE_MP_TABLE - select HAVE_MAINBOARD_RESOURCES select CACHE_AS_RAM select HAVE_HARD_RESET select SB_HT_CHAIN_UNITID_OFFSET_ONLY @@ -30,7 +29,7 @@ config MAINBOARD_DIR string - default amd/tilapia_fam10 + default asus/m4a785-m config APIC_ID_OFFSET hex @@ -38,7 +37,7 @@ config MAINBOARD_PART_NUMBER string - default "Tilapia (Fam10)" + default "M4A785-M" config HW_MEM_HOLE_SIZEK hex @@ -74,7 +73,7 @@ config IRQ_SLOT_COUNT int - default 11 + default 19 config AMD_UCODE_PATCH_FILE string @@ -94,11 +93,11 @@ config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID hex - default 0x3060 + default 0x83a2 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID hex - default 0x1022 + default 0x1043 config RAMBASE hex @@ -108,4 +107,4 @@ hex default 0 -endif # BOARD_AMD_TILAPIA_FAM10 +endif Modified: trunk/src/mainboard/asus/m4a785-m/devicetree.cb ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/devicetree.cb Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/asus/m4a785-m/devicetree.cb Mon Sep 13 16:51:26 2010 (r5809) @@ -1,7 +1,6 @@ -# sample config for amd/tilapia_fam10 chip northbridge/amd/amdfam10/root_complex device lapic_cluster 0 on - chip cpu/amd/socket_AM3 #L1 and DDR3 + chip cpu/amd/socket_AM3 #L1 and DDR2 device lapic 0 on end end end @@ -11,15 +10,15 @@ chip southbridge/amd/rs780 device pci 0.0 on end # HT 0x9600 device pci 1.0 on end # Internal Graphics P2P bridge 0x9602 - device pci 2.0 on end # PCIE P2P bridge (external graphics) 0x9603 - device pci 3.0 on end # PCIE P2P bridge 0x960b - device pci 4.0 on end # PCIE P2P bridge 0x9604 + device pci 2.0 off end # PCIE P2P bridge (external graphics) 0x9603 + device pci 3.0 off end # PCIE P2P bridge 0x960b + device pci 4.0 off end # PCIE P2P bridge 0x9604 device pci 5.0 off end # PCIE P2P bridge 0x9605 device pci 6.0 off end # PCIE P2P bridge 0x9606 device pci 7.0 off end # PCIE P2P bridge 0x9607 device pci 8.0 off end # NB/SB Link P2P bridge - device pci 9.0 on end # - device pci a.0 on end # + device pci 9.0 off end # + device pci a.0 on end # bridge to RTL8111/8168B PCI Express Gigabit Ethernet register "gppsb_configuration" = "1" # Configuration B register "gpp_configuration" = "3" # Configuration D default register "port_enable" = "0x6fc" @@ -57,12 +56,8 @@ device pci 14.1 on end # IDE 0x439c device pci 14.2 on end # HDA 0x4383 device pci 14.3 on # LPC 0x439d - chip superio/ite/it8718f - device pnp 2e.0 off # Floppy - io 0x60 = 0x3f0 - irq 0x70 = 6 - drq 0x74 = 2 - end + chip superio/ite/it8712f + device pnp 2e.0 off end # Floppy device pnp 2e.1 on # Com1 io 0x60 = 0x3f8 irq 0x70 = 4 @@ -75,7 +70,7 @@ io 0x60 = 0x378 irq 0x70 = 7 end - device pnp 2e.4 off end # EC + device pnp 2e.4 off end # Environment Controller device pnp 2e.5 on # Keyboard io 0x60 = 0x60 io 0x62 = 0x64 @@ -87,16 +82,13 @@ device pnp 2e.7 off # GPIO, must be closed for unresolved reason. end device pnp 2e.8 off # MIDI - io 0x60 = 0x300 - irq 0x70 = 9 end device pnp 2e.9 off # GAME - io 0x60 = 0x220 end device pnp 2e.a off end # CIR - end #superio/ite/it8718f + end #superio end #LPC - device pci 14.4 on end # PCI 0x4384 + device pci 14.4 on end # PCI to PCI Bridge [1002:4384] device pci 14.5 on end # USB 2 register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE end #southbridge/amd/sb700 @@ -108,35 +100,6 @@ device pci 18.2 on end device pci 18.3 on end device pci 18.4 on end -# device pci 00.5 on end - end + end # chip northbridge end #pci_domain - #for node 32 to node 63 -# device pci_domain 0 on -# chip northbridge/amd/amdfam10 -# device pci 00.0 on end# northbridge -# device pci 00.0 on end -# device pci 00.0 on end -# device pci 00.0 on end -# device pci 00.1 on end -# device pci 00.2 on end -# device pci 00.3 on end -# device pci 00.4 on end -# device pci 00.5 on end -# end -# end #pci_domain - -# chip drivers/generic/debug -# device pnp 0.0 off end # chip name -# device pnp 0.1 on end # pci_regs_all -# device pnp 0.2 off end # mem -# device pnp 0.3 off end # cpuid -# device pnp 0.4 off end # smbus_regs_all -# device pnp 0.5 off end # dual core msr -# device pnp 0.6 off end # cache size -# device pnp 0.7 off end # tsc -# device pnp 0.8 off end # hard reset -# device pnp 0.9 off end # mcp55 -# device pnp 0.a on end # GH ext table -# end -end +end # northbridge/amd/amdfam10/root_complex Modified: trunk/src/mainboard/asus/m4a785-m/irq_tables.c ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/irq_tables.c Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/asus/m4a785-m/irq_tables.c Mon Sep 13 16:51:26 2010 (r5809) @@ -1,11 +1,12 @@ /* * This file is part of the coreboot project. * - * Copyright (C) 2010 Advanced Micro Devices, Inc. + * Copyright (C) 200x TODO * * 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; version 2 of the License. + * 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 @@ -17,97 +18,48 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#include -#include -#include -#include #include -#include - - - -static void write_pirq_info(struct irq_info *pirq_info, u8 bus, u8 devfn, - u8 link0, u16 bitmap0, u8 link1, u16 bitmap1, - u8 link2, u16 bitmap2, u8 link3, u16 bitmap3, - u8 slot, u8 rfu) -{ - pirq_info->bus = bus; - pirq_info->devfn = devfn; - pirq_info->irq[0].link = link0; - pirq_info->irq[0].bitmap = bitmap0; - pirq_info->irq[1].link = link1; - pirq_info->irq[1].bitmap = bitmap1; - pirq_info->irq[2].link = link2; - pirq_info->irq[2].bitmap = bitmap2; - pirq_info->irq[3].link = link3; - pirq_info->irq[3].bitmap = bitmap3; - pirq_info->slot = slot; - pirq_info->rfu = rfu; -} -extern u8 bus_isa; -extern u8 bus_rs780[8]; -extern u8 bus_sb700[2]; -extern unsigned long sbdn_sb700; +const struct irq_routing_table intel_irq_routing_table = { + PIRQ_SIGNATURE, /* u32 signature */ + PIRQ_VERSION, /* u16 version */ + 32 + 16 * 19, /* Max. number of devices on the bus */ + 0x00, /* Interrupt router bus */ + (0x14 << 3) | 0x3, /* Interrupt router dev */ + 0, /* IRQs devoted exclusively to PCI usage */ + 0x1002, /* Vendor */ + 0x439d, /* Device */ + 0, /* Miniport */ + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ + 0x8, /* Checksum (has to be set to some value that + * would give 0 after the sum of all bytes + * for this structure (including checksum). + */ + { + /* bus, dev | fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ + {0x01, (0x05 << 3) | 0x0, {{0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x02 << 3) | 0x0, {{0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x03 << 3) | 0x0, {{0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}, {0x03, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x04 << 3) | 0x0, {{0x01, 0xdc90}, {0x02, 0xdc90}, {0x03, 0xdc90}, {0x04, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x05 << 3) | 0x0, {{0x02, 0xdc90}, {0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x06 << 3) | 0x0, {{0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x07 << 3) | 0x0, {{0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}, {0x03, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x09 << 3) | 0x0, {{0x02, 0xdc90}, {0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x0a << 3) | 0x0, {{0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}}, 0x0, 0x0}, + {0x02, (0x00 << 3) | 0x0, {{0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}}, 0xa, 0x0}, + {0x00, (0x0b << 3) | 0x0, {{0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}, {0x03, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x0c << 3) | 0x0, {{0x01, 0xdc90}, {0x02, 0xdc90}, {0x03, 0xdc90}, {0x04, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x14 << 3) | 0x0, {{0x01, 0xdc90}, {0x02, 0xdc90}, {0x03, 0xdc90}, {0x04, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x12 << 3) | 0x0, {{0x01, 0xdc90}, {0x02, 0xdc90}, {0x03, 0xdc90}, {0x04, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x13 << 3) | 0x0, {{0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}}, 0x0, 0x0}, + {0x00, (0x11 << 3) | 0x0, {{0x0c, 0xdc90}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x0000}}, 0x0, 0x0}, + {0x0a, (0x00 << 3) | 0x0, {{0x03, 0xdc90}, {0x04, 0xdc90}, {0x01, 0xdc90}, {0x02, 0xdc90}}, 0x0, 0x0}, + {0x03, (0x05 << 3) | 0x0, {{0x0a, 0xdc90}, {0x0b, 0xdc90}, {0x0c, 0xdc90}, {0x0d, 0xdc90}}, 0xc, 0x0}, + {0x03, (0x06 << 3) | 0x0, {{0x0b, 0xdc90}, {0x0c, 0xdc90}, {0x0d, 0xdc90}, {0x0a, 0xdc90}}, 0xd, 0x0}, + } +}; unsigned long write_pirq_routing_table(unsigned long addr) { - struct irq_routing_table *pirq; - struct irq_info *pirq_info; - u32 slot_num; - u8 *v; - - u8 sum = 0; - int i; - - get_bus_conf(); /* it will find out all bus num and apic that share with mptable.c and mptable.c and acpi_tables.c */ - - /* Align the table to be 16 byte aligned. */ - addr += 15; - addr &= ~15; - - /* This table must be betweeen 0xf0000 & 0x100000 */ - printk(BIOS_INFO, "Writing IRQ routing tables to 0x%lx...", addr); - - pirq = (void *)(addr); - v = (u8 *) (addr); - - pirq->signature = PIRQ_SIGNATURE; - pirq->version = PIRQ_VERSION; - - pirq->rtr_bus = bus_sb700[0]; - pirq->rtr_devfn = ((sbdn_sb700 + 0x14) << 3) | 4; - - pirq->exclusive_irqs = 0; - - pirq->rtr_vendor = 0x1002; - pirq->rtr_device = 0x4384; - - pirq->miniport_data = 0; - - memset(pirq->rfu, 0, sizeof(pirq->rfu)); - - pirq_info = (void *)(&pirq->checksum + 1); - slot_num = 0; - - /* pci bridge */ - write_pirq_info(pirq_info, bus_sb700[0], ((sbdn_sb700 + 0x14) << 3) | 4, - 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, - 0); - pirq_info++; - slot_num++; - - pirq->size = 32 + 16 * slot_num; - - for (i = 0; i < pirq->size; i++) - sum += v[i]; - - sum = pirq->checksum - sum; - if (sum != pirq->checksum) { - pirq->checksum = sum; - } - - printk(BIOS_INFO, "write_pirq_routing_table done.\n"); - - return (unsigned long)pirq_info; + return copy_pirq_routing_table(addr); } Modified: trunk/src/mainboard/asus/m4a785-m/mainboard.c ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/mainboard.c Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/asus/m4a785-m/mainboard.c Mon Sep 13 16:51:26 2010 (r5809) @@ -21,7 +21,6 @@ #include #include #include -#include #include #include #include @@ -132,6 +131,8 @@ /* * justify the dev3 is exist or not + * NOTE: This just copied from AMD Tilapia code. + * It is completly unknown it it will work at all for Asus M4A785-A */ u8 is_dev3_present(void) { @@ -158,62 +159,6 @@ } } - -/* - * set gpio40 gfx - */ -static void set_gpio40_gfx(void) -{ - u8 byte; - u32 dword; - device_t sm_dev; - /* disable the GPIO40 as CLKREQ2# function */ - byte = pm_ioread(0xd3); - byte &= ~(1 << 7); - pm_iowrite(0xd3, byte); - - /* disable the GPIO40 as CLKREQ3# function */ - byte = pm_ioread(0xd4); - byte &= ~(1 << 0); - pm_iowrite(0xd4, byte); - - /* enable pull up for GPIO68 */ - byte = pm2_ioread(0xf1); - byte &= ~(1 << 4); - pm2_iowrite(0xf1, byte); - - /* access the smbus extended register */ - sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0)); - - /*if the dev3 is present, set the gfx to 2x8 lanes*/ - /*otherwise set the gfx to 1x16 lanes*/ - if(is_dev3_present()){ - - printk(BIOS_INFO, "Dev3 is present. GFX Configuration is Two x8 slots\n"); - /* when the gpio40 is configured as GPIO, this will enable the output */ - pci_write_config32(sm_dev, 0xf8, 0x4); - dword = pci_read_config32(sm_dev, 0xfc); - dword &= ~(1 << 10); - - /* When the gpio40 is configured as GPIO, this will represent the output value*/ - /* 1 :enable two x8 , 0 : master slot enable only */ - dword |= (1 << 26); - pci_write_config32(sm_dev, 0xfc, dword); - - }else{ - printk(BIOS_INFO, "Dev3 is not present. GFX Configuration is One x16 slot\n"); - /* when the gpio40 is configured as GPIO, this will enable the output */ - pci_write_config32(sm_dev, 0xf8, 0x4); - dword = pci_read_config32(sm_dev, 0xfc); - dword &= ~(1 << 10); - - /* When the gpio40 is configured as GPIO, this will represent the output value*/ - /* 1 :enable two x8 , 0 : master slot enable only */ - dword &= ~(1 << 26); - pci_write_config32(sm_dev, 0xfc, dword); - } -} - /* * set thermal config */ @@ -279,12 +224,12 @@ } /************************************************* -* enable the dedicated function in tilapia board. +* enable the dedicated function in m4a785m board. * This function called early than rs780_enable. *************************************************/ -static void tilapia_enable(device_t dev) +static void m4a785m_enable(device_t dev) { - printk(BIOS_INFO, "Mainboard TILAPIA Enable. dev=0x%p\n", dev); + printk(BIOS_INFO, "Mainboard M4A785M Enable. dev=0x%p\n", dev); #if (CONFIG_GFXUMA == 1) msr_t msr, msr2; @@ -328,24 +273,9 @@ set_pcie_dereset(); /* get_ide_dma66(); */ set_thermal_config(); - set_gpio40_gfx(); -} - -int add_mainboard_resources(struct lb_memory *mem) -{ - /* UMA is removed from system memory in the northbridge code, but - * in some circumstances we want the memory mentioned as reserved. - */ -#if (CONFIG_GFXUMA == 1) - printk(BIOS_INFO, "uma_memory_start=0x%llx, uma_memory_size=0x%llx \n", - uma_memory_base, uma_memory_size); - lb_add_memory_range(mem, LB_MEM_RESERVED, uma_memory_base, - uma_memory_size); -#endif - return 0; } struct chip_operations mainboard_ops = { - CHIP_NAME("AMD TILAPIA Mainboard") - .enable_dev = tilapia_enable, + CHIP_NAME("AMD M4A785M Mainboard") + .enable_dev = m4a785m_enable, }; Modified: trunk/src/mainboard/asus/m4a785-m/romstage.c ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/romstage.c Thu Sep 9 12:35:52 2010 (r5792) +++ trunk/src/mainboard/asus/m4a785-m/romstage.c Mon Sep 13 16:51:26 2010 (r5809) @@ -59,7 +59,7 @@ static int smbus_read_byte(u32 device, u32 address); -#include "superio/ite/it8718f/it8718f_early_serial.c" +#include "superio/ite/it8712f/it8712f_early_serial.c" #include "cpu/x86/mtrr/earlymtrr.c" #include #include "northbridge/amd/amdfam10/setup_resource_map.c" @@ -136,7 +136,8 @@ enable_rs780_dev8(); sb700_lpc_init(); - it8718f_enable_serial(0, CONFIG_TTYS0_BASE); + it8712f_enable_serial(0, CONFIG_TTYS0_BASE); + it8712f_kill_watchdog(); /* disable watchdog, so it does not reset while still booting */ uart_init(); console_init(); printk(BIOS_DEBUG, "\n"); From wt at penguintechs.org Mon Sep 13 16:56:17 2010 From: wt at penguintechs.org (Warren Turkal) Date: Mon, 13 Sep 2010 07:56:17 -0700 Subject: [coreboot] BUG REPORT: parallel build broken In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 6:20 AM, Myles Watson wrote: > Thanks for the bug report. ?There is a problem with dependency > checking which we haven't worked through yet. ?As long as the option > table utility is built before you invoke make it will work. I am glad that it is understood. On the second point (seemingly broken trac), who can fix the bug tracker so that I can properly file the bug? Thanks, wt From mylesgw at gmail.com Mon Sep 13 17:08:14 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 09:08:14 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <1284241635.538.75.camel@bart> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> Message-ID: On Sat, Sep 11, 2010 at 3:47 PM, Juhana Helovuo wrote: > On Sat, 2010-09-11 at 23:36 +0300, Juhana Helovuo wrote: >> On Sat, 2010-09-11 at 07:03 -0600, Myles Watson wrote: >> >> > So it works with my updated patch, but not with the uma & reserved >> > patches? ?Or does it not work at all? ?Does it still work with your >> > previous patch set? >> > >> > Could you send a full log with the last working version and the first >> > broken version from this list? >> > >> > 1. Your original patches >> > 2. 5799 + my board patch >> > 3. 2 + uma.diff >> > 4. 3 + reserved.diff >> > >> > uma.diff & reserved.diff should be independent, so you could try >> > 2+reserved.diff also >> > >> >> Ok, now I have some test results: >> >> * 5792 + my original patches --> boots ok >> * 5792 + your simplified patches --> boots ok >> * 5792 + your simplified patches + uma.diff --> boots ok (log attached) >> * 5792 + your simplified patches + uma.diff + reserved.diff --> does not >> build, patch seems to be for newer trunk version >> >> * 5799 + my original patches --> SATA failure (log attached) >> * 5799 + your simplified patches --> SATA failure >> >> * 5802 + your simplified patch for 5800 --> SATA failure >> >> My conclusion from this is that something in the trunk has broken >> between 5792 and 5799. > > Sorry about spamming the list, but I managed to test a few cases more: > > * 5795 + your simplified patches --> boots ok > * 5795 + your simplified patches + uma.diff + reserved.diff --> boots ok Thanks for tracking it down. I committed the patches as Rev 5805 (PCI & SB700) Rev 5806 (Multiboot tables) Rev 5807 (fam10 UMA) Rev 5808 (fam10 reserved regions) Rev 5809 (Asus M4A785-M) > * 5796 + your simplified patches --> SATA failure > > It seems to me that the patches are ok, but some trunk change from 5795 > to 5796 is causing the problems. There seems to be a problem with CONFIG_MMCONF_SUPPORT vs. CONFIG_MMCONF_SUPPORT_DEFAULT. This should work for you until it's fixed. If it doesn't, I need to dig a little deeper. Index: src/northbridge/amd/amdfam10/Kconfig =================================================================== --- src/northbridge/amd/amdfam10/Kconfig (revision 5804) +++ src/northbridge/amd/amdfam10/Kconfig (working copy) @@ -23,7 +23,6 @@ select HAVE_DEBUG_SMBUS select HYPERTRANSPORT_PLUGIN_SUPPORT select NORTHBRIDGE_AMD_AMDFAM10_ROOT_COMPLEX - select MMCONF_SUPPORT config AGP_APERTURE_SIZE hex Thanks, Myles From svn at coreboot.org Mon Sep 13 17:11:36 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 17:11:36 +0200 Subject: [coreboot] [commit] r5810 - in trunk/src: cpu/amd/car cpu/amd/model_10xxx southbridge/nvidia/mcp55 Message-ID: Author: myles Date: Mon Sep 13 17:11:35 2010 New Revision: 5810 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5810 Log: Move initialization of MMCONF BAR to cache_as_ram setup phase, in order to make sure MMCONF is set up before use. Otherwise, PCI config accesses run before init_cpus() will be lost if MMCONF is enabled (unless explicitly done as port-based accesses). This obsoletes removal of RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78) in mcp55_early_setup, so reinsert. Signed-off-by: Arne Georg Gleditsch Acked-by: Myles Watson Modified: trunk/src/cpu/amd/car/cache_as_ram.inc trunk/src/cpu/amd/model_10xxx/init_cpus.c trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c Modified: trunk/src/cpu/amd/car/cache_as_ram.inc ============================================================================== --- trunk/src/cpu/amd/car/cache_as_ram.inc Mon Sep 13 16:51:26 2010 (r5809) +++ trunk/src/cpu/amd/car/cache_as_ram.inc Mon Sep 13 17:11:35 2010 (r5810) @@ -27,6 +27,7 @@ /* for CAR with FAM10 */ #define CacheSizeAPStack 0x400 /* 1K */ +#define MSR_MCFG_BASE 0xC0010058 #define MSR_FAM10 0xC001102A #define jmp_if_k8(x) comisd %xmm2, %xmm1; jb x @@ -115,7 +116,7 @@ /* Errata 193: Disable clean copybacks to L3 cache to allow cached ROM. * Re-enable it in after RAM is initialized and before CAR is disabled */ - movl $0xc001102a, %ecx + movl $MSR_FAM10, %ecx rdmsr bts $15, %eax wrmsr @@ -136,6 +137,19 @@ /* Erratum 343 end */ +#if defined(CONFIG_MMCONF_SUPPORT) + /* Set MMIO Config space BAR */ + movl $MSR_MCFG_BASE, %ecx + rdmsr + + andl $(~(0xfff00000 | (0xf << 2))), %eax + orl $((CONFIG_MMCONF_BASE_ADDRESS & 0xfff00000) | (8 << 2) | (1 << 0)), %eax + andl $(~(0x0000ffff)), %edx + orl $(CONFIG_MMCONF_BASE_ADDRESS >> 32), %edx + + wrmsr +#endif + CAR_FAM10_out_post_errata: /* Set MtrrFixDramModEn for clear fixed mtrr */ Modified: trunk/src/cpu/amd/model_10xxx/init_cpus.c ============================================================================== --- trunk/src/cpu/amd/model_10xxx/init_cpus.c Mon Sep 13 16:51:26 2010 (r5809) +++ trunk/src/cpu/amd/model_10xxx/init_cpus.c Mon Sep 13 17:11:35 2010 (r5810) @@ -58,30 +58,6 @@ #endif -#define _ULLx(x) x ## ULL -#define _ULL(x) _ULLx(x) - -/*[63:0] */ -#define PCI_MMIO_BASE _ULL(CONFIG_MMCONF_BASE_ADDRESS) - -static void set_pci_mmio_conf_reg(void) -{ -#if CONFIG_MMCONF_SUPPORT -# if PCI_MMIO_BASE > 0xffffffff -# error CONFIG_MMCONF_BASE_ADDRESS must currently fit in 32 bits! -# endif - msr_t msr; - msr = rdmsr(0xc0010058); - msr.lo &= ~(0xfff00000 | (0xf << 2)); - // 256 buses, one segment. Total 256M address space. - msr.lo |= (PCI_MMIO_BASE & 0xfff00000) | (8 << 2) | (1 << 0); - msr.hi &= ~(0x0000ffff); - msr.hi |= (PCI_MMIO_BASE >> (32)); - - wrmsr(0xc0010058, msr); // MMIO Config Base Address Reg -#endif -} - typedef void (*process_ap_t) (u32 apicid, void *gp); //core_range = 0 : all cores @@ -295,9 +271,6 @@ * already set early mtrr in cache_as_ram.inc */ - /* enable access pci conf via mmio */ - set_pci_mmio_conf_reg(); - /* that is from initial apicid, we need nodeid and coreid later */ id = get_node_core_id_x(); Modified: trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c ============================================================================== --- trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c Mon Sep 13 16:51:26 2010 (r5809) +++ trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c Mon Sep 13 17:11:35 2010 (r5810) @@ -267,13 +267,7 @@ RES_PCI_IO, PCI_ADDR(0, 6, 0, 0x74), 0xFFFFFFC0, 0x00000000, RES_PCI_IO, PCI_ADDR(0, 6, 0, 0xC0), 0x00000000, 0xCB8410DE, RES_PCI_IO, PCI_ADDR(0, 6, 0, 0xC4), 0xFFFFFFF8, 0x00000007, - /* The following operation hangs when performed via MMCFG: - pci_read_config32(romcc): 00010000:0078: 20040000 - setup_resource_map_x_offset: 10000, 78: 20040000 - pci_write_config32(romcc): 00010000:0078: 19040000 - (hang) - Response missing? */ - /* RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, */ + RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, #if MCP55_USE_AZA == 1 RES_PCI_IO, PCI_ADDR(0, 6, 1, 0x40), 0x00000000, 0xCB8410DE, From mylesgw at gmail.com Mon Sep 13 17:15:47 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 09:15:47 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <9A2D7428C1DF4E73AEF7E55AB74250DF@chimp> References: <4B9117ED.5020807@numascale.com> <4B9749D3.4040508@numascale.com> <87pr25dkxx.fsf@taniquetil.gledits.ch> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> <874odztlt7.fsf@taniquetil.gledits.ch> <87fwxix8im.fsf@taniquetil.gledits.ch> <87y6b5rfaj.fsf@taniquetil.gledits.ch> <87tyltrexk.fsf@taniquetil.gledits.ch> <9A2D7428C1DF4E73AEF7E55AB74250DF@chimp> Message-ID: On Mon, Sep 13, 2010 at 6:52 AM, Myles Watson wrote: > >> Arne Georg Gleditsch writes: >> > With this change, I can re-insert the RES_PCI_IO wihtout ill effects. >> >> Move initialization of MMCONF BAR to cache_as_ram setup phase, in order >> to make sure MMCONF is set up before use. ?Otherwise, PCI config >> accesses run before init_cpus() will be lost if MMCONF is enabled >> (unless explicitly done as port-based accesses). >> >> This obsoletes removal of RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78) in >> mcp55_early_setup, so reinsert. >> >> Signed-off-by: Arne Georg Gleditsch > > Acked-by: Myles Watson Rev 5810. Arne: Could you help me understand MMCONF_SUPPORT and MMCONF_SUPPORT_DEFAULT? It looks like the area gets reserved for MMCONF_SUPPORT, even if MMCONF_SUPPORT_DEFAULT isn't selected. Thanks, Myles Thanks, Myles From JRottmann at LiPPERTEmbedded.de Mon Sep 13 17:27:03 2010 From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann) Date: Mon, 13 Sep 2010 17:27:03 +0200 Subject: [coreboot] Thank you all! Message-ID: <4C8E42C7.7080603@LiPPERTEmbedded.de> Hi all, I just wanted to thank everybody who spent their valuable time to answer my questions and review, comment, ACK and commit my patches. It's been great to work with you! Thank you all very much!! Jens From jochum at home.nl Mon Sep 13 15:27:49 2010 From: jochum at home.nl (jochum) Date: Mon, 13 Sep 2010 15:27:49 +0200 Subject: [coreboot] MSI k7D Master (760MPX chipset) Message-ID: <23aae65d443f84ceef83ae0a4d9cf88e@localhost> I have an old MSI k7D Master (760MPX chipset) that i'd love to run on coreboot. I read some old posts in the list claiming succes, however i can't find the board anywhere in the list of supported boards. Is there a coreboot version that works with this board? Cheers, Jochum The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From arne.gleditsch at numascale.com Mon Sep 13 17:49:28 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Mon, 13 Sep 2010 17:49:28 +0200 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: (Myles Watson's message of "Mon, 13 Sep 2010 09:15:47 -0600") References: <4B9117ED.5020807@numascale.com> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> <874odztlt7.fsf@taniquetil.gledits.ch> <87fwxix8im.fsf@taniquetil.gledits.ch> <87y6b5rfaj.fsf@taniquetil.gledits.ch> <87tyltrexk.fsf@taniquetil.gledits.ch> <9A2D7428C1DF4E73AEF7E55AB74250DF@chimp> Message-ID: <87zkvlwsmv.fsf@taniquetil.gledits.ch> Myles Watson writes: > Rev 5810. Thanks! > Arne: > Could you help me understand MMCONF_SUPPORT and > MMCONF_SUPPORT_DEFAULT? It looks like the area gets reserved for > MMCONF_SUPPORT, even if MMCONF_SUPPORT_DEFAULT isn't selected. My understanding of the code as it was before I started messing with it, is that MMCONF_SUPPORT is intended to indicate whether the facility is available at all, and MMCONF_SUPPORT_DEFAULT toggles the actual use of it (by Coreboot). Both src/northbridge/amd/amdfam10/northbridge.c and src/northbridge/intel/i945/northbridge.c contains code like this: #if CONFIG_MMCONF_SUPPORT_DEFAULT .ops_pci_bus = &pci_ops_mmconf, #else .ops_pci_bus = &pci_cf8_conf1, #endif which, alongside romcc_io.h's #if CONFIG_MMCONF_SUPPORT_DEFAULT return pci_mmio_read_config32(dev, where); #else return pci_io_read_config32(dev, where); #endif is more or less the only use for MMCONF_SUPPORT_DEFAULT as far as I can see. I'll leave it to others to determine if this actually makes sense. (Having SUPPORT without SUPPORT_DEFAULT gives you an MCFG area that you can communicate to the OS (at least potentially), as well as the option of explicitly doing individual config accesses via mmio instead of ports. I don't think anyone is doing either of these today.) -- Arne. From juhe at iki.fi Mon Sep 13 18:08:35 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Mon, 13 Sep 2010 19:08:35 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> Message-ID: <1284394115.3630.24.camel@bart> On Mon, 2010-09-13 at 09:08 -0600, Myles Watson wrote: > Thanks for tracking it down. I committed the patches as > Rev 5805 (PCI & SB700) > Rev 5806 (Multiboot tables) > Rev 5807 (fam10 UMA) > Rev 5808 (fam10 reserved regions) > Rev 5809 (Asus M4A785-M) Thanks a lot for all your troubles and advice! > > * 5796 + your simplified patches --> SATA failure > > > > It seems to me that the patches are ok, but some trunk change from 5795 > > to 5796 is causing the problems. > > There seems to be a problem with CONFIG_MMCONF_SUPPORT vs. > CONFIG_MMCONF_SUPPORT_DEFAULT. > > This should work for you until it's fixed. If it doesn't, I need to > dig a little deeper. Hmm. I just checked out 5810 and tested. Configuration and building go smoothly (although menuconfig gives wrong ROM size by default, should be 1 MByte), but Linux still fails on SATA and USB. I edited away MMCONF_SUPPORT before configuring like you wrote, but it does not help. Also, I ran into another problem: When I upgrade RAM from 2 GB to 4 GB (or 6 GB), executing the VGA BIOS gets stuck. Coreboot jumps into the BIOS code, but it never returns. With more RAM, the UMA gets mapped to 0xd0000000 and PCI iomem areas get mapped over real RAM, starting at 0xe0000000. In the boot log I found the following line: Warning: Can't set up MTRR hole for UMA due to pre-existing MTRR hole. This message does not appear with 2 GB RAM. More test results with 6 GB RAM: * If I disable the GFXUMA option, do not include VGA BIOS on CBFS, and install another VGA card in a PCI slot, I get the same results. Coreboot locates the BIOS on the external card, copies to low RAM, jumps into it, and gets stuck. * If I hardwire UMA start address to be 0x70000000 and UMA size 64M in mainboard.c, the BIOS does not get stuck and Coreboot launches Grub2. However, Grub2 is very unstable and crashes randomly. I also sometimes get random garbage on VGA. Loading Linux does not work, causes machine to get stuck or reboot. Apparently there is some address conflict, but where should I start looking? Best Regards, Juhana Helovuo -------------- next part -------------- A non-text attachment was scrubbed... Name: rev5795-with-6G-memory-vga-bios-stuck.log Type: text/x-log Size: 57267 bytes Desc: not available URL: From mylesgw at gmail.com Mon Sep 13 18:29:05 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 10:29:05 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <1284394115.3630.24.camel@bart> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> Message-ID: On Mon, Sep 13, 2010 at 10:08 AM, Juhana Helovuo wrote: > On Mon, 2010-09-13 at 09:08 -0600, Myles Watson wrote: > >> Thanks for tracking it down. ?I committed the patches as >> Rev 5805 (PCI & SB700) >> Rev 5806 (Multiboot tables) >> Rev 5807 (fam10 UMA) >> Rev 5808 (fam10 reserved regions) >> Rev 5809 (Asus M4A785-M) > > Thanks a lot for all your troubles and advice! > > >> > * 5796 + your simplified patches --> SATA failure >> > >> > It seems to me that the patches are ok, but some trunk change from 5795 >> > to 5796 is causing the problems. >> >> There seems to be a problem with CONFIG_MMCONF_SUPPORT vs. >> CONFIG_MMCONF_SUPPORT_DEFAULT. >> >> This should work for you until it's fixed. ?If it doesn't, I need to >> dig a little deeper. > > > Hmm. I just checked out 5810 and tested. Configuration and building go > smoothly ?(although menuconfig gives wrong ROM size by default, should > be 1 MByte), but Linux still fails on SATA and USB. > > I edited away MMCONF_SUPPORT before configuring like you wrote, but it > does not help. > > > Also, I ran into another problem: > > When I upgrade RAM from 2 GB to 4 GB (or 6 GB), executing the VGA BIOS > gets stuck. Coreboot jumps into the BIOS code, but it never returns. > > With more RAM, the UMA gets mapped to 0xd0000000 and PCI iomem areas get > mapped over real RAM, starting at 0xe0000000. In the boot log I found > the following line: > > Warning: Can't set up MTRR hole for UMA due to pre-existing MTRR hole. > > This message does not appear with 2 GB RAM. > > > More test results with 6 GB RAM: > > * If I disable the GFXUMA option, do not include VGA BIOS on CBFS, and > install another VGA card in a PCI slot, I get the same results. Coreboot > locates the BIOS on the external card, copies to low RAM, jumps into it, > and gets stuck. > > * If I hardwire UMA start address to be 0x70000000 and UMA size 64M in > mainboard.c, the BIOS does not get stuck and Coreboot launches Grub2. > However, Grub2 is very unstable and crashes randomly. I also sometimes > get random garbage on VGA. Loading Linux does not work, causes machine > to get stuck or reboot. > > Apparently there is some address conflict, but where should I start > looking? The problem seems to be that the mainboard code gets its information on the size of memory from TOP_MEM, but that hasn't been set correctly with respect to the PCI resources yet. m4a785m_enable, TOP MEM: msr.lo = 0xe0000000, msr.hi = 0x00000000 m4a785m_enable, TOP MEM2: msr2.lo = 0xa0000000, msr2.hi = 0x00000001 m4a785m_enable: uma size 0x10000000, memory start 0xd0000000 ... Root Device assign_resources, bus 0 link: 0 split: 64K table at =cfff0000 0: mmio_basek=00300000, basek=00400000, limitk=00680000 Adding UMA memory area So even though there are PCI resources located at 0xc0000000, RAM gets used for UMA at 0xd0000000 and tables get placed at 0xcfff0000. You could test that theory by hard coding the top mem logic in mainboard.c. Because the mainboard device is at the root of the tree, the northbridge initialization hasn't been done yet, so the values it wants haven't been calculated. Thanks, Myles From mylesgw at gmail.com Mon Sep 13 18:44:40 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 10:44:40 -0600 Subject: [coreboot] [PATCH] AMD MMCONF Support In-Reply-To: <87zkvlwsmv.fsf@taniquetil.gledits.ch> References: <4B9117ED.5020807@numascale.com> <87d3y3erev.fsf@taniquetil.gledits.ch> <874ohvm1yj.fsf_-_@taniquetil.gledits.ch> <4BFD022D.2030908@coresystems.de> <4C6A46E7.9040103@georgi-clan.de> <87wrrpipw6.fsf@taniquetil.gledits.ch> <87lj7ctk88.fsf@taniquetil.gledits.ch> <87k4mwxou5.fsf@taniquetil.gledits.ch> <87hbhztm8m.fsf@taniquetil.gledits.ch> <874odztlt7.fsf@taniquetil.gledits.ch> <87fwxix8im.fsf@taniquetil.gledits.ch> <87y6b5rfaj.fsf@taniquetil.gledits.ch> <87tyltrexk.fsf@taniquetil.gledits.ch> <9A2D7428C1DF4E73AEF7E55AB74250DF@chimp> <87zkvlwsmv.fsf@taniquetil.gledits.ch> Message-ID: >> Arne: >> Could you help me understand MMCONF_SUPPORT and >> MMCONF_SUPPORT_DEFAULT? ?It looks like the area gets reserved for >> MMCONF_SUPPORT, even if MMCONF_SUPPORT_DEFAULT isn't selected. > > My understanding of the code as it was before I started messing with it, > is that MMCONF_SUPPORT is intended to indicate whether the facility is > available at all, and MMCONF_SUPPORT_DEFAULT toggles the actual use of > it (by Coreboot). ?Both src/northbridge/amd/amdfam10/northbridge.c and > src/northbridge/intel/i945/northbridge.c contains code like this: > > ?#if CONFIG_MMCONF_SUPPORT_DEFAULT > ? ? ? ? ?.ops_pci_bus ? ? ?= &pci_ops_mmconf, > ?#else > ? ? ? ? ?.ops_pci_bus ? ? ?= &pci_cf8_conf1, > ?#endif > > which, alongside romcc_io.h's > > ?#if CONFIG_MMCONF_SUPPORT_DEFAULT > ? ? ? ? ?return pci_mmio_read_config32(dev, where); > ?#else > ? ? ? ? ?return pci_io_read_config32(dev, where); > ?#endif > > is more or less the only use for MMCONF_SUPPORT_DEFAULT as far as I can > see. ?I'll leave it to others to determine if this actually makes sense. > > (Having SUPPORT without SUPPORT_DEFAULT gives you an MCFG area that you > can communicate to the OS (at least potentially), as well as the option > of explicitly doing individual config accesses via mmio instead of > ports. ?I don't think anyone is doing either of these today.) Thanks for the explanation. It looks like the trouble with reserving a region for MMCONF is related to broken UMA code. Thanks, Myles From peter at stuge.se Mon Sep 13 18:49:32 2010 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Sep 2010 18:49:32 +0200 Subject: [coreboot] Thank you all! In-Reply-To: <4C8E42C7.7080603@LiPPERTEmbedded.de> References: <4C8E42C7.7080603@LiPPERTEmbedded.de> Message-ID: <20100913164932.31135.qmail@stuge.se> Hey, Jens Rottmann wrote: > I just wanted to thank everybody who spent their valuable time to answer > my questions and review, comment, ACK and commit my patches. Thanks to you and LiPPERT as well, for your interest in coreboot! :) //Peter From mylesgw at gmail.com Mon Sep 13 19:03:29 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 11:03:29 -0600 Subject: [coreboot] MSI k7D Master (760MPX chipset) In-Reply-To: <23aae65d443f84ceef83ae0a4d9cf88e@localhost> References: <23aae65d443f84ceef83ae0a4d9cf88e@localhost> Message-ID: On Mon, Sep 13, 2010 at 7:27 AM, jochum wrote: > I have an old MSI k7D Master (760MPX chipset) that i'd love to run on > coreboot. I read some old posts in the list claiming succes, however i can't > find the board anywhere in the list of supported boards. I see the chipset files in v1. http://tracker.coreboot.org/trac/coreboot/browser/branches/coreboot-v1 It would probably take some work to port it and support your board. Thanks, Myles From juhe at iki.fi Mon Sep 13 19:26:38 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Mon, 13 Sep 2010 20:26:38 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> Message-ID: <1284398798.3630.30.camel@bart> On Mon, 2010-09-13 at 10:29 -0600, Myles Watson wrote: > > The problem seems to be that the mainboard code gets its information > on the size of memory from TOP_MEM, but that hasn't been set correctly > with respect to the PCI resources yet. > > m4a785m_enable, TOP MEM: msr.lo = 0xe0000000, msr.hi = 0x00000000 > m4a785m_enable, TOP MEM2: msr2.lo = 0xa0000000, msr2.hi = 0x00000001 > m4a785m_enable: uma size 0x10000000, memory start 0xd0000000 > ... > Root Device assign_resources, bus 0 link: 0 > split: 64K table at =cfff0000 > 0: mmio_basek=00300000, basek=00400000, limitk=00680000 > Adding UMA memory area > > So even though there are PCI resources located at 0xc0000000, RAM gets > used for UMA at 0xd0000000 and tables get placed at 0xcfff0000. > > You could test that theory by hard coding the top mem logic in mainboard.c. > > Because the mainboard device is at the root of the tree, the > northbridge initialization hasn't been done yet, so the values it > wants haven't been calculated. I tried with the following: /* TOP_MEM: the top of DRAM below 4G */ msr = rdmsr(TOP_MEM); //hardwire this for testing if (msr.lo > 0x80000000) { msr.lo = 0x80000000; } This code manages to set UMA to a lower address, but the effect is the same as with hardwiring UMA address. Boot proceeds past VGA BIOS, but results in random crashes and reboots. Or did you mean some other hardwiring? Since variable "msr" here is local to the routine, I don't see how it could have effect on anything else but the UMA location and size. The value read from TOP_MEM2 isn't even used for anything but printing. Best regards, Juhana Helovuo From svn at coreboot.org Mon Sep 13 19:28:49 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 19:28:49 +0200 Subject: [coreboot] build service results for r5810 Message-ID: Dear coreboot readers! This is the automatic build system of coreboot. The developer "myles" checked in revision 5810 to the coreboot repository. This caused the following changes: Change Log: Move initialization of MMCONF BAR to cache_as_ram setup phase, in order to make sure MMCONF is set up before use. Otherwise, PCI config accesses run before init_cpus() will be lost if MMCONF is enabled (unless explicitly done as port-based accesses). This obsoletes removal of RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78) in mcp55_early_setup, so reinsert. Signed-off-by: Arne Georg Gleditsch Acked-by: Myles Watson Build Log: Compilation of amd:dbm690t has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=dbm690t&vendor=amd&num=2 Compilation of amd:mahogany has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=mahogany&vendor=amd&num=2 Compilation of amd:pistachio has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=pistachio&vendor=amd&num=2 Compilation of amd:serengeti_cheetah has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=serengeti_cheetah&vendor=amd&num=2 Compilation of arima:hdama has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=hdama&vendor=arima&num=2 Compilation of asrock:939a785gmh has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=939a785gmh&vendor=asrock&num=2 Compilation of asus:a8n_e has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=a8n_e&vendor=asus&num=2 Compilation of asus:a8v-e_se has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=a8v-e_se&vendor=asus&num=2 Compilation of asus:m2v-mx_se has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=m2v-mx_se&vendor=asus&num=2 Compilation of broadcom:blast has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=blast&vendor=broadcom&num=2 Compilation of gigabyte:ga_2761gxdk has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=ga_2761gxdk&vendor=gigabyte&num=2 Compilation of gigabyte:m57sli has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=m57sli&vendor=gigabyte&num=2 Compilation of hp:dl145_g1 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=dl145_g1&vendor=hp&num=2 Compilation of hp:dl145_g3 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=dl145_g3&vendor=hp&num=2 Compilation of ibm:e325 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=e325&vendor=ibm&num=2 Compilation of ibm:e326 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=e326&vendor=ibm&num=2 Compilation of iwill:dk8_htx has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=dk8_htx&vendor=iwill&num=2 Compilation of iwill:dk8s2 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=dk8s2&vendor=iwill&num=2 Compilation of iwill:dk8x has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=dk8x&vendor=iwill&num=2 Compilation of kontron:kt690 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=kt690&vendor=kontron&num=2 Compilation of msi:ms7135 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=ms7135&vendor=msi&num=2 Compilation of msi:ms7260 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=ms7260&vendor=msi&num=2 Compilation of msi:ms9185 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=ms9185&vendor=msi&num=2 Compilation of msi:ms9282 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=ms9282&vendor=msi&num=2 Compilation of newisys:khepri has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=khepri&vendor=newisys&num=2 Compilation of nvidia:l1_2pvv has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=l1_2pvv&vendor=nvidia&num=2 Compilation of sunw:ultra40 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=ultra40&vendor=sunw&num=2 Compilation of supermicro:h8dme has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=h8dme&vendor=supermicro&num=2 Compilation of supermicro:h8dmr has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=h8dmr&vendor=supermicro&num=2 Compilation of technexion:tim5690 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=tim5690&vendor=technexion&num=2 Compilation of technexion:tim8690 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=tim8690&vendor=technexion&num=2 Compilation of tyan:s2850 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2850&vendor=tyan&num=2 Compilation of tyan:s2875 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2875&vendor=tyan&num=2 Compilation of tyan:s2880 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2880&vendor=tyan&num=2 Compilation of tyan:s2881 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2881&vendor=tyan&num=2 Compilation of tyan:s2882 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2882&vendor=tyan&num=2 Compilation of tyan:s2885 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2885&vendor=tyan&num=2 Compilation of tyan:s2891 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2891&vendor=tyan&num=2 Compilation of tyan:s2892 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2892&vendor=tyan&num=2 Compilation of tyan:s2895 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2895&vendor=tyan&num=2 Compilation of tyan:s2912 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s2912&vendor=tyan&num=2 Compilation of tyan:s4880 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s4880&vendor=tyan&num=2 Compilation of tyan:s4882 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5810&device=s4882&vendor=tyan&num=2 If something broke during this checkin please be a pain in myles'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 From mylesgw at gmail.com Mon Sep 13 19:36:17 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 11:36:17 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <1284398798.3630.30.camel@bart> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> <1284398798.3630.30.camel@bart> Message-ID: On Mon, Sep 13, 2010 at 11:26 AM, Juhana Helovuo wrote: > On Mon, 2010-09-13 at 10:29 -0600, Myles Watson wrote: > >> >> The problem seems to be that the mainboard code gets its information >> on the size of memory from TOP_MEM, but that hasn't been set correctly >> with respect to the PCI resources yet. >> >> m4a785m_enable, TOP MEM: msr.lo = 0xe0000000, msr.hi = 0x00000000 >> m4a785m_enable, TOP MEM2: msr2.lo = 0xa0000000, msr2.hi = 0x00000001 >> m4a785m_enable: uma size 0x10000000, memory start 0xd0000000 >> ... >> Root Device assign_resources, bus 0 link: 0 >> ?split: 64K table at =cfff0000 >> 0: mmio_basek=00300000, basek=00400000, limitk=00680000 >> Adding UMA memory area >> >> So even though there are PCI resources located at 0xc0000000, RAM gets >> used for UMA at 0xd0000000 and tables get placed at 0xcfff0000. >> >> You could test that theory by hard coding the top mem logic in mainboard.c. >> >> Because the mainboard device is at the root of the tree, the >> northbridge initialization hasn't been done yet, so the values it >> wants haven't been calculated. > > I tried with the following: > > ? ? ? ?/* TOP_MEM: the top of DRAM below 4G */ > ? ? ? ?msr = rdmsr(TOP_MEM); > ? ? ? ?//hardwire this for testing > ? ? ? ?if (msr.lo > 0x80000000) { msr.lo = 0x80000000; } > > > This code manages to set UMA to a lower address, but the effect is the > same as with hardwiring UMA address. Boot proceeds past VGA BIOS, but > results in random crashes and reboots. > > Or did you mean some other hardwiring? I thought more about the problem than the solution :) > Since variable "msr" here is local to the routine, I don't see how it > could have effect on anything else but the UMA location and size. The > value read from TOP_MEM2 isn't even used for anything but printing. I was hoping that changing the uma location would be enough to affect the rest. Could you try if (msr.lo > 0xc0000000) { msr.lo = 0xc0000000; } I'm thinking that would place uma at 0xb0000000 & coreboot tables at 0xafff0000. Then could you send the log if that's still unstable. Thanks, Myles From svn at coreboot.org Mon Sep 13 19:46:14 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 19:46:14 +0200 Subject: [coreboot] [commit] r5811 - trunk/src/cpu/amd/car Message-ID: Author: myles Date: Mon Sep 13 19:46:13 2010 New Revision: 5811 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5811 Log: CONFIG_MMCONF_SUPPORT is always defined. Fix build. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/src/cpu/amd/car/cache_as_ram.inc Modified: trunk/src/cpu/amd/car/cache_as_ram.inc ============================================================================== --- trunk/src/cpu/amd/car/cache_as_ram.inc Mon Sep 13 17:11:35 2010 (r5810) +++ trunk/src/cpu/amd/car/cache_as_ram.inc Mon Sep 13 19:46:13 2010 (r5811) @@ -137,7 +137,7 @@ /* Erratum 343 end */ -#if defined(CONFIG_MMCONF_SUPPORT) +#if CONFIG_MMCONF_SUPPORT /* Set MMIO Config space BAR */ movl $MSR_MCFG_BASE, %ecx rdmsr From svn at coreboot.org Mon Sep 13 20:35:22 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 20:35:22 +0200 Subject: [coreboot] build service results for r5811 Message-ID: Dear coreboot readers! This is the automatic build system of coreboot. The developer "myles" checked in revision 5811 to the coreboot repository. This caused the following changes: Change Log: CONFIG_MMCONF_SUPPORT is always defined. Fix build. Signed-off-by: Myles Watson Acked-by: Myles Watson Build Log: Compilation of amd:dbm690t has been fixed Compilation of amd:mahogany has been fixed Compilation of amd:pistachio has been fixed Compilation of amd:serengeti_cheetah has been fixed Compilation of arima:hdama has been fixed Compilation of asrock:939a785gmh has been fixed Compilation of asus:a8n_e has been fixed Compilation of asus:a8v-e_se has been fixed Compilation of asus:m2v-mx_se has been fixed Compilation of broadcom:blast has been fixed Compilation of gigabyte:ga_2761gxdk has been fixed Compilation of gigabyte:m57sli has been fixed Compilation of hp:dl145_g1 has been fixed Compilation of hp:dl145_g3 has been fixed Compilation of ibm:e325 has been fixed Compilation of ibm:e326 has been fixed Compilation of iwill:dk8_htx has been fixed Compilation of iwill:dk8s2 has been fixed Compilation of iwill:dk8x has been fixed Compilation of kontron:kt690 has been fixed Compilation of msi:ms7135 has been fixed Compilation of msi:ms7260 has been fixed Compilation of msi:ms9185 has been fixed Compilation of msi:ms9282 has been fixed Compilation of newisys:khepri has been fixed Compilation of nvidia:l1_2pvv has been fixed Compilation of sunw:ultra40 has been fixed Compilation of supermicro:h8dme has been fixed Compilation of supermicro:h8dmr has been fixed Compilation of technexion:tim5690 has been fixed Compilation of technexion:tim8690 has been fixed Compilation of tyan:s2850 has been fixed Compilation of tyan:s2875 has been fixed Compilation of tyan:s2880 has been fixed Compilation of tyan:s2881 has been fixed Compilation of tyan:s2882 has been fixed Compilation of tyan:s2885 has been fixed Compilation of tyan:s2891 has been fixed Compilation of tyan:s2892 has been fixed Compilation of tyan:s2895 has been fixed Compilation of tyan:s2912 has been fixed Compilation of tyan:s4880 has been fixed Compilation of tyan:s4882 has been fixed If something broke during this checkin please be a pain in myles'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 From juhe at iki.fi Mon Sep 13 21:12:11 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Mon, 13 Sep 2010 22:12:11 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> <1284398798.3630.30.camel@bart> Message-ID: <1284405131.3630.37.camel@bart> On Mon, 2010-09-13 at 11:36 -0600, Myles Watson wrote: > I was hoping that changing the uma location would be enough to affect the rest. > > Could you try > > if (msr.lo > 0xc0000000) { msr.lo = 0xc0000000; } > > I'm thinking that would place uma at 0xb0000000 & coreboot tables at 0xafff0000. > > Then could you send the log if that's still unstable. > Yes, the placement is exactly as you said. This version is very unstable. On most attempts is does not get past "raminit_amdmct" phase before it starts booting from the start. If it gets to the payload, then VGA output is just random pixel noise and usually there is a spontaneous reboot in a few seconds. The log is attached. Best regards, Juhana Helovuo -------------- next part -------------- A non-text attachment was scrubbed... Name: rev5795-with-6GB-RAM-mem_top-wired.log Type: text/x-log Size: 66650 bytes Desc: not available URL: From svn at coreboot.org Mon Sep 13 21:24:38 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 21:24:38 +0200 Subject: [coreboot] [commit] r5812 - trunk/src/mainboard/iei/kino-780am2-fam10 Message-ID: Author: mjones Date: Mon Sep 13 21:24:38 2010 New Revision: 5812 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5812 Log: IEI Kino mainboard support based on Mahogany Fam10. svn copy amd/mahogany iei/kino-780am2-fam10; then apply the patch. Signed-off-by: Marc Jones Acked-by: Peter Stuge Added: trunk/src/mainboard/iei/kino-780am2-fam10/ - copied from r5802, trunk/src/mainboard/amd/mahogany_fam10/ Modified: trunk/src/mainboard/iei/kino-780am2-fam10/Kconfig trunk/src/mainboard/iei/kino-780am2-fam10/devicetree.cb trunk/src/mainboard/iei/kino-780am2-fam10/dsdt.asl trunk/src/mainboard/iei/kino-780am2-fam10/mainboard.c trunk/src/mainboard/iei/kino-780am2-fam10/mptable.c trunk/src/mainboard/iei/kino-780am2-fam10/romstage.c Modified: trunk/src/mainboard/iei/kino-780am2-fam10/Kconfig ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/Kconfig Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/iei/kino-780am2-fam10/Kconfig Mon Sep 13 21:24:38 2010 (r5812) @@ -1,4 +1,4 @@ -if BOARD_AMD_MAHOGANY_FAM10 +if BOARD_IEI_KINO_FAM10 config BOARD_SPECIFIC_OPTIONS # dummy def_bool y @@ -9,7 +9,7 @@ select NORTHBRIDGE_AMD_AMDFAM10 select SOUTHBRIDGE_AMD_RS780 select SOUTHBRIDGE_AMD_SB700 - select SUPERIO_ITE_IT8718F + select SUPERIO_FINTEK_F71859 select BOARD_HAS_FADT select HAVE_BUS_CONFIG select HAVE_OPTION_TABLE @@ -30,7 +30,7 @@ config MAINBOARD_DIR string - default amd/mahogany_fam10 + default iei/kino-780am2-fam10 config APIC_ID_OFFSET hex @@ -38,7 +38,7 @@ config MAINBOARD_PART_NUMBER string - default "Mahogany (Fam10)" + default "Kino-780AM2(Fam10)" config HW_MEM_HOLE_SIZEK hex @@ -78,7 +78,7 @@ config AMD_UCODE_PATCH_FILE string - default "mc_patch_01000095.h" + default "mc_patch_01000086.h" config RAMTOP hex @@ -94,11 +94,11 @@ config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID hex - default 0x3060 + default 0x0000 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID hex - default 0x1022 + default 0x0000 config RAMBASE hex @@ -108,4 +108,8 @@ hex default 0 -endif # BOARD_AMD_MAHOGANY_FAM10 +config FALLBACK_VGA_BIOS_ID + string + default "1002,9615" + +endif #BOARD_IEI_KINO_FAM10 Modified: trunk/src/mainboard/iei/kino-780am2-fam10/devicetree.cb ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/devicetree.cb Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/iei/kino-780am2-fam10/devicetree.cb Mon Sep 13 21:24:38 2010 (r5812) @@ -1,4 +1,4 @@ -# sample config for amd/mahogany_fam10 +# Config for iei/kino-780am2-fam10 chip northbridge/amd/amdfam10/root_complex device lapic_cluster 0 on chip cpu/amd/socket_AM2r2 #L1 and DDR2 @@ -46,17 +46,11 @@ chip drivers/generic/generic #dimm 0-0-1 device i2c 51 on end end - chip drivers/generic/generic #dimm 0-1-0 - device i2c 52 on end - end - chip drivers/generic/generic #dimm 0-1-1 - device i2c 53 on end - end end # SM device pci 14.1 on end # IDE 0x439c device pci 14.2 on end # HDA 0x4383 device pci 14.3 on # LPC 0x439d - chip superio/ite/it8718f + chip superio/fintek/f71859 device pnp 2e.0 off # Floppy io 0x60 = 0x3f0 irq 0x70 = 6 @@ -83,60 +77,17 @@ device pnp 2e.6 on # Mouse irq 0x70 = 12 end - device pnp 2e.7 off # GPIO, must be closed for unresolved reason. - end - device pnp 2e.8 off # MIDI - io 0x60 = 0x300 - irq 0x70 = 9 - end - device pnp 2e.9 off # GAME - io 0x60 = 0x220 - end - device pnp 2e.a off end # CIR - end #superio/ite/it8718f + end #SIO end #LPC device pci 14.4 on end # PCI 0x4384 device pci 14.5 on end # USB 2 register "boot_switch_sata_ide" = "0" # 0: boot from SATA. 1: IDE end #southbridge/amd/sb700 end # device pci 18.0 - - device pci 18.0 on end - device pci 18.0 on end device pci 18.1 on end device pci 18.2 on end device pci 18.3 on end - device pci 18.4 on end -# device pci 00.5 on end end end #pci_domain - #for node 32 to node 63 -# device pci_domain 0 on -# chip northbridge/amd/amdfam10 -# device pci 00.0 on end# northbridge -# device pci 00.0 on end -# device pci 00.0 on end -# device pci 00.0 on end -# device pci 00.1 on end -# device pci 00.2 on end -# device pci 00.3 on end -# device pci 00.4 on end -# device pci 00.5 on end -# end -# end #pci_domain - -# chip drivers/generic/debug -# device pnp 0.0 off end # chip name -# device pnp 0.1 on end # pci_regs_all -# device pnp 0.2 off end # mem -# device pnp 0.3 off end # cpuid -# device pnp 0.4 off end # smbus_regs_all -# device pnp 0.5 off end # dual core msr -# device pnp 0.6 off end # cache size -# device pnp 0.7 off end # tsc -# device pnp 0.8 off end # hard reset -# device pnp 0.9 off end # mcp55 -# device pnp 0.a on end # GH ext table -# end +end #root_complex -end Modified: trunk/src/mainboard/iei/kino-780am2-fam10/dsdt.asl ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/dsdt.asl Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/iei/kino-780am2-fam10/dsdt.asl Mon Sep 13 21:24:38 2010 (r5812) @@ -22,8 +22,8 @@ "DSDT.AML", /* Output filename */ "DSDT", /* Signature */ 0x02, /* DSDT Revision, needs to be 2 for 64bit */ - "AMD ", /* OEMID */ - "MAHOGANY", /* TABLE ID */ + "IEI ", /* OEMID */ + "KINO ", /* TABLE ID */ 0x00010001 /* OEM Revision */ ) { /* Start of ASL file */ @@ -1450,7 +1450,7 @@ Name(_ADR, 0x00140006) } /* end Ac97modem */ - /* ITE8718 Support */ + /* SIO Support */ OperationRegion (IOID, SystemIO, 0x2E, 0x02) /* sometimes it is 0x4E */ Field (IOID, ByteAcc, NoLock, Preserve) { Modified: trunk/src/mainboard/iei/kino-780am2-fam10/mainboard.c ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/mainboard.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/iei/kino-780am2-fam10/mainboard.c Mon Sep 13 21:24:38 2010 (r5812) @@ -35,77 +35,32 @@ void set_pcie_dereset(void); void set_pcie_reset(void); u8 is_dev3_present(void); -/* - * Mahogany uses GPIO 6 as PCIe slot reset, GPIO4 as GFX slot reset. We need to +/* TODO - Need to find GPIO for PCIE slot. + * Kino uses GPIO ? as PCIe slot reset, GPIO? as GFX slot reset. We need to * pull it up before training the slot. ***/ void set_pcie_dereset() { - u16 word; - device_t sm_dev; - /* GPIO 6 reset PCIe slot, GPIO 4 reset GFX PCIe */ - sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0)); - - word = pci_read_config16(sm_dev, 0xA8); - word |= (1 << 0) | (1 << 2); /* Set Gpio6,4 as output */ - word &= ~((1 << 8) | (1 << 10)); - pci_write_config16(sm_dev, 0xA8, word); + /* PCIE slot not yet supported.*/ } void set_pcie_reset() { - u16 word; - device_t sm_dev; - /* GPIO 6 reset PCIe slot, GPIO 4 reset GFX PCIe */ - sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0)); - - word = pci_read_config16(sm_dev, 0xA8); - word &= ~((1 << 0) | (1 << 2)); /* Set Gpio6,4 as output */ - word &= ~((1 << 8) | (1 << 10)); - pci_write_config16(sm_dev, 0xA8, word); + /* PCIE slot not yet supported.*/ } -#if 0 /* not tested yet. */ -/******************************************************** -* mahogany uses SB700 GPIO9 to detect IDE_DMA66. -* IDE_DMA66 is routed to GPIO 9. So we read Gpio 9 to -* get the cable type, 40 pin or 80 pin? -********************************************************/ -static void get_ide_dma66(void) -{ - u8 byte; - /*u32 sm_dev, ide_dev; */ - device_t sm_dev, ide_dev; - - sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0)); - - byte = pci_read_config8(sm_dev, 0xA9); - byte |= (1 << 5); /* Set Gpio9 as input */ - pci_write_config8(sm_dev, 0xA9, byte); - - ide_dev = dev_find_slot(0, PCI_DEVFN(0x14, 1)); - byte = pci_read_config8(ide_dev, 0x56); - byte &= ~(7 << 0); - if ((1 << 5) & pci_read_config8(sm_dev, 0xAA)) - byte |= 2 << 0; /* mode 2 */ - else - byte |= 5 << 0; /* mode 5 */ - pci_write_config8(ide_dev, 0x56, byte); -} -#endif /* get_ide_dma66() */ - u8 is_dev3_present(void) { return 0; } /************************************************* -* enable the dedicated function in mahogany board. +* enable the dedicated function in kino board. * This function called early than rs780_enable. *************************************************/ -static void mahogany_enable(device_t dev) +static void kino_enable(device_t dev) { - printk(BIOS_INFO, "Mainboard MAHOGANY Enable. dev=0x%p\n", dev); + printk(BIOS_INFO, "Mainboard Kino Enable. dev=0x%p\n", dev); #if (CONFIG_GFXUMA == 1) msr_t msr, msr2; @@ -166,6 +121,6 @@ } struct chip_operations mainboard_ops = { - CHIP_NAME("AMD MAHOGANY Mainboard") - .enable_dev = mahogany_enable, + CHIP_NAME("IEI Kino-780AM2 Mainboard") + .enable_dev = kino_enable, }; Modified: trunk/src/mainboard/iei/kino-780am2-fam10/mptable.c ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/mptable.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/iei/kino-780am2-fam10/mptable.c Mon Sep 13 21:24:38 2010 (r5812) @@ -43,7 +43,7 @@ { static const char sig[4] = "PCMP"; static const char oem[8] = "COREBOOT"; - static const char productid[12] = "MAHOGANY "; + static const char productid[12] = "KINO "; struct mp_config_table *mc; int j; Modified: trunk/src/mainboard/iei/kino-780am2-fam10/romstage.c ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/romstage.c Sat Sep 11 00:13:34 2010 (r5802) +++ trunk/src/mainboard/iei/kino-780am2-fam10/romstage.c Mon Sep 13 21:24:38 2010 (r5812) @@ -37,6 +37,9 @@ #define SET_FIDVID 1 #define SET_FIDVID_CORE_RANGE 0 +/* UART address and device number */ +#define SERIAL_DEV PNP_DEV(0x2e, F71859_SP1) + #include #include #include @@ -59,7 +62,7 @@ static int smbus_read_byte(u32 device, u32 address); -#include "superio/ite/it8718f/it8718f_early_serial.c" +#include "superio/fintek/f71859/f71859_early_serial.c" #include "cpu/x86/mtrr/earlymtrr.c" #include #include "northbridge/amd/amdfam10/setup_resource_map.c" @@ -136,7 +139,7 @@ enable_rs780_dev8(); sb700_lpc_init(); - it8718f_enable_serial(0, CONFIG_TTYS0_BASE); + f71859_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); uart_init(); console_init(); printk(BIOS_DEBUG, "\n"); From marcj303 at gmail.com Mon Sep 13 21:25:20 2010 From: marcj303 at gmail.com (Marc Jones) Date: Mon, 13 Sep 2010 13:25:20 -0600 Subject: [coreboot] [patch] IEI Kino 780 AM2 mainboard In-Reply-To: <20100910233922.30691.qmail@stuge.se> References: <20100910233922.30691.qmail@stuge.se> Message-ID: On Fri, Sep 10, 2010 at 5:39 PM, Peter Stuge wrote: > Marc Jones wrote: >> IEI Kino mainoard support based on Mahogany Fam10. >> svn copy amd/mahogany iei/kino-780am2-fam10; then apply the patch. >> >> Signed-off-by: Marc Jones > > >> +++ coreboot/src/mainboard/iei/kino-780am2-fam10/mainboard.c ?2010-09-10 10:14:37.000000000 -0600 > .. >> +/* FIXME - Need to find GPIO for PCIE slot. >> + * Kino uses GPIO ? as PCIe slot reset, GPIO? as GFX slot reset. We need to >> ? * pull it up before training the slot. >> ? ***/ >> ?void set_pcie_dereset() >> ?{ > .. >> + ? ? /* No PCIE slots.*/ >> ?} >> >> ?void set_pcie_reset() >> ?{ > .. >> + ? ? /* No PCIE slots.*/ >> ?} > > Uh? Is there or is there not a PCIe slot? > > >> -static void mahogany_enable(device_t dev) >> +static void kino_enable(device_t dev) >> ?{ >> - ? ? printk(BIOS_INFO, "Mainboard MAHOGANY Enable. dev=0x%p\n", dev); >> + ? ? printk(BIOS_INFO, "Mainboard Kino Enable. dev=0x%p\n", dev); >> >> ?#if (CONFIG_GFXUMA == 1) >> ? ? ? msr_t msr, msr2; >> @@ -166,6 +121,6 @@ >> ?} >> >> ?struct chip_operations mainboard_ops = { >> - ? ? CHIP_NAME("AMD MAHOGANY ? Mainboard") >> - ? ? .enable_dev = mahogany_enable, >> + ? ? CHIP_NAME("IEI Kino-780AM2 Mainboard") >> + ? ? .enable_dev = kino_enable, >> ?}; > > Could the mainboard enable function reuse the CHIP_NAME somehow, or > maybe both should just use CONFIG_MAINBOARD_PART_NUMBER ? > > > Acked-by: Peter Stuge I updated the PCIE slot comment to "Slot not yet supported". r5812 Thanks, Marc -- http://se-eng.com From mylesgw at gmail.com Mon Sep 13 21:29:35 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 13:29:35 -0600 Subject: [coreboot] [commit] r5812 - trunk/src/mainboard/iei/kino-780am2-fam10 In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 1:24 PM, repository service wrote: > Author: mjones > Date: Mon Sep 13 21:24:38 2010 > New Revision: 5812 > URL: https://tracker.coreboot.org/trac/coreboot/changeset/5812 > > Log: > IEI Kino mainboard support based on Mahogany Fam10. > svn copy amd/mahogany iei/kino-780am2-fam10; then apply the patch. > ?config AMD_UCODE_PATCH_FILE > ? ? ? ?string > - ? ? ? default "mc_patch_01000095.h" > + ? ? ? default "mc_patch_01000086.h" I'm surprised the microcode patch is specific to the mainboard. I would have thought it would be specific to a processor. Thanks, Myles From svn at coreboot.org Mon Sep 13 21:31:23 2010 From: svn at coreboot.org (repository service) Date: Mon, 13 Sep 2010 21:31:23 +0200 Subject: [coreboot] [commit] r5813 - trunk/src/mainboard/iei Message-ID: Author: mjones Date: Mon Sep 13 21:31:21 2010 New Revision: 5813 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5813 Log: IEI Kino added to IEI mainboard Kconfig. I missed this in r5812 Signed-off-by: Marc Jones Acked-by: Marc Jones Modified: trunk/src/mainboard/iei/Kconfig Modified: trunk/src/mainboard/iei/Kconfig ============================================================================== --- trunk/src/mainboard/iei/Kconfig Mon Sep 13 21:24:38 2010 (r5812) +++ trunk/src/mainboard/iei/Kconfig Mon Sep 13 21:31:21 2010 (r5813) @@ -23,6 +23,8 @@ config BOARD_IEI_JUKI_511P bool "JUKI-511P" +config BOARD_IEI_KINO_FAM10 + bool "Kino-780AM2(Fam10)" config BOARD_IEI_NOVA_4899R bool "NOVA-4899R" config BOARD_IEI_PCISA_LX_800_R10 @@ -31,6 +33,7 @@ endchoice source "src/mainboard/iei/juki-511p/Kconfig" +source "src/mainboard/iei/kino-780am2-fam10/Kconfig" source "src/mainboard/iei/nova4899r/Kconfig" source "src/mainboard/iei/pcisa-lx-800-r10/Kconfig" From mylesgw at gmail.com Mon Sep 13 21:32:35 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 13:32:35 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <1284405131.3630.37.camel@bart> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> <1284398798.3630.30.camel@bart> <1284405131.3630.37.camel@bart> Message-ID: On Mon, Sep 13, 2010 at 1:12 PM, Juhana Helovuo wrote: > On Mon, 2010-09-13 at 11:36 -0600, Myles Watson wrote: > >> I was hoping that changing the uma location would be enough to affect the rest. >> >> Could you try >> >> ? ? ? ? if (msr.lo > 0xc0000000) { msr.lo = 0xc0000000; } >> >> I'm thinking that would place uma at 0xb0000000 & coreboot tables at 0xafff0000. >> >> Then could you send the log if that's still unstable. >> > > Yes, the placement is exactly as you said. I can't see the conflict. I'll have to think about it. Marc: Do you have any insight? > This version is very unstable. On most attempts is does not get past > "raminit_amdmct" phase before it starts booting from the start. That's especially interesting because we haven't changed anything that early. > If it gets to the payload, then VGA output is just random pixel noise > and usually there is a spontaneous reboot in a few seconds. Thanks for the info, Myles From arne.gleditsch at numascale.com Mon Sep 13 21:35:49 2010 From: arne.gleditsch at numascale.com (Arne Georg Gleditsch) Date: Mon, 13 Sep 2010 21:35:49 +0200 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: (Myles Watson's message of "Mon, 13 Sep 2010 10:29:05 -0600") References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> Message-ID: <87vd69wi5m.fsf@taniquetil.gledits.ch> Myles Watson writes: > So even though there are PCI resources located at 0xc0000000, RAM gets > used for UMA at 0xd0000000 and tables get placed at 0xcfff0000. PCI resources at 0xd0000000? Doesn't this conflict with the setting of NV_BottomIO in src/northbridge/amd/amdmct/wrappers/mcti_d.c? -- Arne. From marcj303 at gmail.com Mon Sep 13 22:11:40 2010 From: marcj303 at gmail.com (Marc Jones) Date: Mon, 13 Sep 2010 14:11:40 -0600 Subject: [coreboot] [commit] r5812 - trunk/src/mainboard/iei/kino-780am2-fam10 In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 1:29 PM, Myles Watson wrote: > On Mon, Sep 13, 2010 at 1:24 PM, repository service wrote: >> Author: mjones >> Date: Mon Sep 13 21:24:38 2010 >> New Revision: 5812 >> URL: https://tracker.coreboot.org/trac/coreboot/changeset/5812 >> >> Log: >> IEI Kino mainboard support based on Mahogany Fam10. >> svn copy amd/mahogany iei/kino-780am2-fam10; then apply the patch. > >> ?config AMD_UCODE_PATCH_FILE >> ? ? ? ?string >> - ? ? ? default "mc_patch_01000095.h" >> + ? ? ? default "mc_patch_01000086.h" > > I'm surprised the microcode patch is specific to the mainboard. ?I > would have thought it would be specific to a processor. They are specific to the processor revision, but we only set the package during the build. Ideally, we would have all supported cpu version ucode file in the cbfs, and load the correct one. Marc -- http://se-eng.com From peter at stuge.se Mon Sep 13 22:18:53 2010 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Sep 2010 22:18:53 +0200 Subject: [coreboot] [commit] r5812 - trunk/src/mainboard/iei/kino-780am2-fam10 In-Reply-To: References: Message-ID: <20100913201853.29383.qmail@stuge.se> Marc Jones wrote: > Ideally, we would have all supported cpu version ucode file in the > cbfs, and load the correct one. First step; which ucode files should be included for which sockets? //Peter From mylesgw at gmail.com Mon Sep 13 22:31:51 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 14:31:51 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <87vd69wi5m.fsf@taniquetil.gledits.ch> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> <87vd69wi5m.fsf@taniquetil.gledits.ch> Message-ID: On Mon, Sep 13, 2010 at 1:35 PM, Arne Georg Gleditsch wrote: > Myles Watson writes: >> So even though there are PCI resources located at 0xc0000000, RAM gets >> used for UMA at 0xd0000000 and tables get placed at 0xcfff0000. > > PCI resources at 0xd0000000? ?Doesn't this conflict with the setting of > NV_BottomIO in src/northbridge/amd/amdmct/wrappers/mcti_d.c? That could be. I'm totally ignorant of the fam10 code oustside of northbridge/amd/amdfam10. Looking at the boot log, it doesn't seem unreasonable to have PCI resources from starting at 0xc0000000. It seems like we have a couple of options: 1. Reclaim the area used for MMCONF on this board 2. Move NV_BottomIO Probably 2 is the best. It's too bad to have that hard coded. Thanks, Myles From uwe at hermann-uwe.de Tue Sep 14 01:00:24 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 14 Sep 2010 01:00:24 +0200 Subject: [coreboot] [flashrom] flashrom patch: add support for Abit AB-BM6 board In-Reply-To: References: <4C81B2EE.2060104@gmx.net> <1283795887.27123.1.camel@aquila> <1283843932.27123.2.camel@aquila> <20100907171145.GW19625@greenwood> Message-ID: <20100913230024.GQ19625@greenwood> On Tue, Sep 07, 2010 at 09:10:35PM +0200, Tim ter Laak wrote: > This patch adds support for the Abit BM6 board, using DMI string > identification, and lists it in print.c [v3]. > > Signed-off-by: Tim ter Laak Thanks a lot, committed as r1163. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From scott at notabs.org Tue Sep 14 01:37:35 2010 From: scott at notabs.org (Scott Duplichan) Date: Mon, 13 Sep 2010 18:37:35 -0500 Subject: [coreboot] coreboot and win7 Message-ID: I am able to boot Win7 using coreboot+seabios on a couple of AMD SB700 systems. Testing so far is with simnow only. Hopefully someone else can try the changes on a real board. I am still building with UMA disabled and using external PCI video instead, to avoid a payload/acpi table overlap problem. I have tested with Tilapia family 10h and Mahogany family 10h on simnow using Win7 PE edition (see attached). Usually a pass with this setup means real hardware will work, and other Win7 editions will work as well. Here are the changes: 1) Fix BSOD about "this bios is not fully acpi compliant". Windows makes this BSOD because DRAM is reported both by E820 and by SB ACPI _CRS. Also, there is a reference to undefined ACPI object TOM2. Removing the reporting of DRAM from ACPI _CRS solves these problems. 2) SB I/O APIC ID: Coreboot programs ID zero, which conflicts with processor cores. ACPI reports ID 2, which conflicts with processor cores. Win7 reprograms to match ACPI. The conflict seems harmless, at least with simnow testing. I gave the I/O APIC a unique ID just to be sure. 3) PS/2 KB and mouse were missing from ACPI which causes Win7 to ignore them. I added them. Other patches I used, unrelated to Win7: 1) Avoid an essentially infinite PCI bus scan when a bad dev_fn value is passed in from hypertransport.c. It is not clear if this can happen only on simnow. 2) Patch to allow use of gcc 4.5.0. I looked briefly at the Cheetah Win7 BSOD with coreboot+seabios. Win7 sees ACPI SCI_EN is zero, telling it to enable ACPI mode. But SMI_CMD is zero, so it can't enable ACPI mode. The BSOD results. Setting SCI_EN before Win7 launch avoids the BSOD, but causes the animated logo phase to not complete in a reasonable amount of time. I may not debug this one further because the chipset is no longer current. Thanks, Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: coreboot-win7.png Type: image/png Size: 273043 bytes Desc: not available URL: From mylesgw at gmail.com Tue Sep 14 04:38:35 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 13 Sep 2010 20:38:35 -0600 Subject: [coreboot] coreboot and win7 In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 5:37 PM, Scott Duplichan wrote: > I am able to boot Win7 using coreboot+seabios on a couple of AMD SB700 systems. > Testing so far is with simnow only. Hopefully someone else can try the changes > on a real board. I am still building with UMA disabled and using external PCI > video instead, to avoid a payload/acpi table overlap problem. Thanks for your work. I'd be interested in your tests of the latest code with the changes to the Asus M4... board. > I have tested > with Tilapia family 10h and Mahogany family 10h on simnow using Win7 PE > edition (see attached). Usually a pass with this setup means real hardware > will work, and other Win7 editions will work as well. Here are the changes: > > 1) Fix BSOD about "this bios is not fully acpi compliant". Windows makes this > BSOD because DRAM is reported both by E820 and by SB ACPI _CRS. Also, there > is a reference to undefined ACPI object TOM2. Removing the reporting of DRAM > from ACPI _CRS solves these problems. > > 2) SB I/O APIC ID: Coreboot programs ID zero, which conflicts with processor > cores. ACPI reports ID 2, which conflicts with processor cores. Win7 > reprograms to match ACPI. The conflict seems harmless, at least with simnow > testing. I gave the I/O APIC a unique ID just to be sure. > > 3) PS/2 KB and mouse were missing from ACPI which causes Win7 to ignore them. > I added them. > > Other patches I used, unrelated to Win7: > > 1) Avoid an essentially infinite PCI bus scan when a bad dev_fn value is > passed in from hypertransport.c. It is not clear if this can happen only > on simnow. This has been patched in svn now. The root cause should still be fixed, but at least it shouldn't have an infinite loop any more. Thanks, Myles From liutao1980 at gmail.com Tue Sep 14 04:49:19 2010 From: liutao1980 at gmail.com (Liu Tao) Date: Tue, 14 Sep 2010 10:49:19 +0800 Subject: [coreboot] [help] A K8/RS780/SB710 board MCE error Message-ID: Hello everyone, I'm porting coreboot v4 to a k8-rs780-sb710 based mainboard, and use amd/mahogany and amd/tilapia_fam10 codes as the reference. Now coreboot boots the board and filo loads linux,but the board crashes at a MCE error during booting process. I'm not very know the detail about the MCE, so any suggestions will be appreciated, thanks very much. The mainboard architecture: CPU: socket F Opteron 2210 EE get_cpu_rev EAX=0x40f13 (1 cpu, dual core) DIMM: DDR2 333M (x1 / x2) HT Link0: off HT Link1: RS780->SB710 HT Link2: off VGA off GFX off PCIE off coreboot code revision: modified on r5692 The MCE/panic message: HARDWARE ERROR CPU 0: Machine Check Exception: 4 Bank 0: f658a00000000833 TSC 572507f34 ADDR 6000 This is not a software problem! Run through mcelog --ascii to decode and contact your hardware vendor Kernel panic - not syncing: Machine check ------------[ cut here ]------------ WARNING: at kernel/smp.c:331 smp_call_function_mask+0x32/0x1ec() Modules linked in: Supported: Yes Pid: 1, comm: swapper Tainted: G M 2.6.27.19-5-default #1 Call Trace: [] show_trace_log_lvl+0x41/0x58 [] dump_stack+0x69/0x6f [] warn_on_slowpath+0x51/0x77 [] smp_call_function_mask+0x32/0x1ec [] smp_call_function+0x29/0x2e [] native_smp_send_stop+0x1a/0x26 [] panic+0xbc/0x169 [] mce_log+0x0/0x7e [] do_machine_check+0x31e/0x3cd [] machine_check+0x7f/0x90 [] setup_trampoline+0x20/0x30 [] native_cpu_up+0x31e/0xc64 [] _cpu_up+0x9a/0x11c [] cpu_up+0x5b/0x6f [] kernel_init+0xe1/0x1eb [] child_rip+0xa/0x11 ---[ end trace 4eaa2a86a8e2da22 ]--- mcelog --k8 --ascii HARDWARE ERROR CPU 0: Machine Check Exception: 4 Bank 0: f658a00000000833 TSC 572507f34 ADDR 6000 This is not a software problem! Run through mcelog --ascii to decode and contact your hardware vendor HARDWARE ERROR CPU 0 0 data cache TSC 572507f34 Data cache ECC error (syndrome b1) bit45 = uncorrected ecc error bit57 = processor context corrupt bit61 = error uncorrected bit62 = error overflow (multiple errors) bus error 'local node origin, request didn't time out data read mem transaction memory access, level generic' STATUS f658a00000000833 MCGSTATUS 4 This is not a software problem! Run through mcelog --ascii to decode and contact your hardware vendor Attached is the detailed boot message. -- Regards, Liu Tao -------------- next part -------------- coreboot-4.0-r Mon Sep 13 17:31:31 CST 2010 starting... BSP Family_Model: 00040f13 *sysinfo range: [000cf000,000cf730] bsp_apicid = 00 cpu_init_detectedx = 00000000 Enabling routing table for node 00 done. Enabling SMP settings 01 nodes initialized. Enabling UP settings coherent_ht_finalize done core0 started: start_other_cores() * AP 01started SBLink=01 NC node|link=01 rs780_early_setup() get_cpu_rev EAX=0x40f13. CPU Rev is K8_Fx. k8_optimization() rs780_por_init sb700_early_setup() sb700_devices_por_init() sb700_devices_por_init(): SMBus Device, BDF:0-20-0 SMBus controller enabled, sb revision is A14 sb700_devices_por_init(): IDE Device, BDF:0-20-1 sb700_devices_por_init(): LPC Device, BDF:0-20-3 sb700_devices_por_init(): P2P Bridge, BDF:0-20-4 sb700_devices_por_init(): SATA Device, BDF:0-18-0 sb700_pmio_por_init() begin msr fid, vid: hi=0xe1010, lo=0xe0a0202 Current fid_cur: 0x2, fid_max: 0xa Requested fid_new: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa fid_new = 0xa, fid_cur = 0x2 set fid failed for apicid =00 end msr fid, vid: hi=0xe100e, lo=0xe0a0202 entering optimize_link_incoherent_ht sysinfo->link_pair_num=0x1 entering ht_optimize_link pos=0xaa, unfiltered freq_cap=0x8075 pos=0xaa, filtered freq_cap=0x75 pos=0xd2, unfiltered freq_cap=0x1c75 pos=0xd2, filtered freq_cap=0x1c75 freq_cap1=0x75, freq_cap2=0x1c75 dev1 old_freq=0x0, freq=0x6, needs_reset=0x1 dev2 old_freq=0x0, freq=0x6, needs_reset=0x1 width_cap1=0x11, width_cap2=0x11 dev1 input ln_width1=0x4, ln_width2=0x4 dev1 input width=0x1 dev1 output ln_width1=0x4, ln_width2=0x4 dev1 input|output width=0x11 old dev1 input|output width=0x11 dev2 input|output width=0x11 old dev2 input|output width=0x11 after ht_optimize_link for link pair 0, reset_needed=0x1 after optimize_link_read_pointers_chain, reset_needed=0x1 rs780_htinit cpu_ht_freq=0. rs780_htinit: HT1 mode ht reset - coreboot-4.0-r Mon Sep 13 17:31:31 CST 2010 starting... BSP Family_Model: 00040f13 *sysinfo range: [000cf000,000cf730] bsp_apicid = 00 cpu_init_detectedx = 00000000 Enabling routing table for node 00 done. Enabling SMP settings 01 nodes initialized. Enabling UP settings coherent_ht_finalize done core0 started: start_other_cores() * AP 01started SBLink=01 NC node|link=01 rs780_early_setup() get_cpu_rev EAX=0x40f13. CPU Rev is K8_Fx. k8_optimization() rs780_por_init sb700_early_setup() sb700_devices_por_init() sb700_devices_por_init(): SMBus Device, BDF:0-20-0 SMBus controller enabled, sb revision is A14 sb700_devices_por_init(): IDE Device, BDF:0-20-1 sb700_devices_por_init(): LPC Device, BDF:0-20-3 sb700_devices_por_init(): P2P Bridge, BDF:0-20-4 sb700_devices_por_init(): SATA Device, BDF:0-18-0 sb700_pmio_por_init() begin msr fid, vid: hi=0xe100e, lo=0xe0a0202 Current fid_cur: 0x2, fid_max: 0xa Requested fid_new: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa FidVid table step fidvid: 0xa fid_new = 0xa, fid_cur = 0x2 set fid failed for apicid =00 end msr fid, vid: hi=0xe100e, lo=0xe0a0202 entering optimize_link_incoherent_ht sysinfo->link_pair_num=0x1 entering ht_optimize_link pos=0xaa, unfiltered freq_cap=0x8075 pos=0xaa, filtered freq_cap=0x75 pos=0xd2, unfiltered freq_cap=0x1c75 pos=0xd2, filtered freq_cap=0x1c75 freq_cap1=0x75, freq_cap2=0x1c75 dev1 old_freq=0x6, freq=0x6, needs_reset=0x0 dev2 old_freq=0x6, freq=0x6, needs_reset=0x0 width_cap1=0x11, width_cap2=0x11 dev1 input ln_width1=0x4, ln_width2=0x4 dev1 input width=0x1 dev1 output ln_width1=0x4, ln_width2=0x4 dev1 input|output width=0x11 old dev1 input|output width=0x11 dev2 input|output width=0x11 old dev2 input|output width=0x11 after ht_optimize_link for link pair 0, reset_needed=0x0 after optimize_link_read_pointers_chain, reset_needed=0x0 rs780_htinit cpu_ht_freq=0. rs780_htinit: HT1 mode fill_mem_ctrl() Ram1.00 setting up CPU 00 northbridge registers done. Ram2.00 sdram_set_spd_registers: paramx :000cedb8 DIMM socket 0, channel 0 SPD device is 0x50 DIMM socket 0, channel 1 SPD device is 0x52 DIMM socket 1, channel 0 SPD device is 0x00 DIMM socket 1, channel 1 SPD device is 0x00 DIMM socket 2, channel 0 SPD device is 0x00 DIMM socket 2, channel 1 SPD device is 0x00 DIMM socket 3, channel 0 SPD device is 0x00 DIMM socket 3, channel 1 SPD device is 0x00 sdram_set_spd_registers: dimm_mask=0x1 spd_enable_2channels: dimm_mask=0x1 spd_set_ram_size: dimm_mask=0x1 Registered spd_handle_unbuffered_dimms: dimm_mask=0x1 1 min_cycle_time: 00000250 1.1 dimm_mask: 00000001 i: 00000000 Channel 0 settings: latencies: 00000038 index: 00000000 latency: 00000003 value1: 00000050 value2: 00000500 new_cycle_time: 00000500 new_latency: 00000003 index: 00000001 latency: 00000004 value1: 0000003d value2: 00000375 new_cycle_time: 00000375 new_latency: 00000004 index: 00000002 latency: 00000005 value1: 00000030 value2: 00000300 new_cycle_time: 00000300 new_latency: 00000005 2 min_cycle_time: 00000300 2 min_latency: 00000005 1.1 dimm_mask: 00000001 i: 00000001 1.1 dimm_mask: 00000001 i: 00000002 1.1 dimm_mask: 00000001 i: 00000003 3 min_cycle_time: 00000300 3 min_latency: 00000005 4 min_cycle_time: 00000300 333MHz 333MHz spd_set_memclk: dimm_mask=0x1 spd_set_dram_timing dimm socket: 00000000 trc update_dimm_Trc: tRC (41) = 0000003c update_dimm_Trc: tRC final value = 2400 update_dimm_Trc: clocks = 12 update_dimm_Trc: clocks after adjustment = 12 trcd trrd tras update_dimm_Tras: 0 value= 0000002d update_dimm_Tras: 1 value= 00000708 update_dimm_Tras: divisor= 000000c8 update_dimm_Tras: clocks= 00000009 trp trtp twr tref twtr trfc spd_set_dram_timing: dimm_mask=0x1 Interleaved RAM end at 0x00200000 kB Lower RAM end at 0x00200000 kB Ram3 sdram_enable: tsc0[8]: 000cee90ECC enabled Initializing memory: done Handling memory hole at 0x00300000 (default) Setting variable MTRR 2, base: 0MB, range: 2048MB, type WB DQS Training:RcvrEn:Pass1: 00 train_DqsRcvrEn: begin ctrl 0 TrainRcvEn: 0 ctrl0 CTLRMaxDelay=03 train_DqsRcvrEn: end ctrl 0 done DQS Training:DQSPos: 00 train_DqsPos: begin ctrl 0 TrainDQSRdWrPos: 0 ctrl 0 TrainDQSRdWrPos: buf_a:000ce950 TrainDQSPos: MutualCSPassW[48] :000ce828 TrainDQSPos: MutualCSPassW[48] :000ce828 TrainDQSPos: MutualCSPassW[48] :000ce828 TrainDQSPos: MutualCSPassW[48] :000ce828 TrainDQSRdWrPos: 5 train_DqsPos: end ctrl 0 done DQS Training:RcvrEn:Pass2: 00 train_DqsRcvrEn: begin ctrl 0 TrainRcvEn: 0 ctrl0 CTLRMaxDelay=57 train_DqsRcvrEn: end ctrl 0 done DQS SAVE NVRAM: c2000 DQS Training:tsc[00]=000000002b63ab40 DQS Training:tsc[01]=000000002c70825b DQS Training:tsc[02]=000000002c73e4c5 DQS Training:tsc[03]=0000000034cd025d DQS Training:tsc[04]=00000000360a929b Ram4 *** Yes, the copy/decompress is taking a while, FIXME! v_esp=000cef58 testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Loading stage image. Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram Stage: loading fallback/coreboot_ram @ 0x200000 (1376256 bytes), entry @ 0x200000 Stage: done loading. Jumping to image. coreboot-4.0-r Mon Sep 13 17:31:31 CST 2010 booting... Enumerating buses... Show all devs...Before Device Enumeration. Root Device: enabled 1 APIC_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 PCI_DOMAIN: 0000: enabled 1 PCI: 00:18.0: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 0 PCI: 00:02.0: enabled 0 PCI: 00:03.0: enabled 0 PCI: 00:04.0: enabled 0 PCI: 00:05.0: enabled 0 PCI: 00:06.0: enabled 0 PCI: 00:07.0: enabled 0 PCI: 00:08.0: enabled 0 PCI: 00:09.0: enabled 0 PCI: 00:0a.0: enabled 0 PCI: 00:11.0: enabled 1 PCI: 00:12.0: enabled 0 PCI: 00:12.1: enabled 0 PCI: 00:12.2: enabled 0 PCI: 00:13.0: enabled 0 PCI: 00:13.1: enabled 0 PCI: 00:13.2: enabled 0 PCI: 00:14.0: enabled 1 I2C: 00:50: enabled 1 I2C: 00:52: enabled 1 PCI: 00:14.1: enabled 1 PCI: 00:14.2: enabled 0 PCI: 00:14.3: enabled 1 PNP: 002e.0: enabled 0 PNP: 002e.1: enabled 1 PNP: 002e.2: enabled 0 PNP: 002e.3: enabled 0 PNP: 002e.4: enabled 0 PNP: 002e.5: enabled 1 PNP: 002e.6: enabled 1 PNP: 002e.7: enabled 0 PNP: 002e.8: enabled 0 PNP: 002e.9: enabled 0 PNP: 002e.a: enabled 0 PCI: 00:14.4: enabled 1 PCI: 00:14.5: enabled 0 PCI: 00:18.1: enabled 1 PCI: 00:18.2: enabled 1 PCI: 00:18.3: enabled 1 Compare with tree... Root Device: enabled 1 APIC_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 PCI_DOMAIN: 0000: enabled 1 PCI: 00:18.0: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 0 PCI: 00:02.0: enabled 0 PCI: 00:03.0: enabled 0 PCI: 00:04.0: enabled 0 PCI: 00:05.0: enabled 0 PCI: 00:06.0: enabled 0 PCI: 00:07.0: enabled 0 PCI: 00:08.0: enabled 0 PCI: 00:09.0: enabled 0 PCI: 00:0a.0: enabled 0 PCI: 00:11.0: enabled 1 PCI: 00:12.0: enabled 0 PCI: 00:12.1: enabled 0 PCI: 00:12.2: enabled 0 PCI: 00:13.0: enabled 0 PCI: 00:13.1: enabled 0 PCI: 00:13.2: enabled 0 PCI: 00:14.0: enabled 1 I2C: 00:50: enabled 1 I2C: 00:52: enabled 1 PCI: 00:14.1: enabled 1 PCI: 00:14.2: enabled 0 PCI: 00:14.3: enabled 1 PNP: 002e.0: enabled 0 PNP: 002e.1: enabled 1 PNP: 002e.2: enabled 0 PNP: 002e.3: enabled 0 PNP: 002e.4: enabled 0 PNP: 002e.5: enabled 1 PNP: 002e.6: enabled 1 PNP: 002e.7: enabled 0 PNP: 002e.8: enabled 0 PNP: 002e.9: enabled 0 PNP: 002e.a: enabled 0 PCI: 00:14.4: enabled 1 PCI: 00:14.5: enabled 0 PCI: 00:18.1: enabled 1 PCI: 00:18.2: enabled 1 PCI: 00:18.3: enabled 1 Mainboard X6000 Enable. dev=0x0021b338 x6000_enable, TOP MEM: msr.lo = 0x80000000, msr.hi = 0x00000000 x6000_enable, TOP MEM2: msr2.lo = 0x00000000, msr2.hi = 0x00000000 x6000_enable: uma size 0x10000000, memory start 0x70000000 scan_static_bus for Root Device APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 scanning... PCI: 00:18.3 siblings=1 CPU: APIC: 00 enabled malloc Enter, size 68, free_mem_ptr 00290000 malloc 00290000 CPU: APIC: 01 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:18.0 [1022/1100] bus ops PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: Using configuration type 1 rs780_enable: dev=0021b824, VID_DID=0x96001022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-0, Fun-0. enable_pcie_bar3() ...done addr=e0000000,bus=0,devfn=40 gpp_sb_init nb_dev=0x0, dev=0x40, port=0x8 NB_PCI_REG04 = 6. NB_PCI_REG84 = 3000095. NB_PCI_REG4C = 52042. PCI: 00:00.0 [1022/9600] ops PCI: 00:00.0 [1022/9600] enabled Capability: type 0x08 @ 0xc4 flags: 0x0180 PCI: 00:00.0 count: 000c static_count: 0015 PCI: 00:00.0 [1022/9600] enabled next_unitid: 0015 PCI: pci_scan_bus for bus 00 rs780_enable: dev=0021b824, VID_DID=0x96001022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-0, Fun-0. enable_pcie_bar3() ...done gpp_sb_init nb_dev=0x0, dev=0x40, port=0x8 NB_PCI_REG04 = 6. NB_PCI_REG84 = 3000095. NB_PCI_REG4C = 52042. PCI: 00:00.0 [1022/9600] enabled rs780_enable: dev=0021b9bc, VID_DID=0x96021022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-1, Fun-0. GC is accessible from now on. Capability: type 0x08 @ 0x44 Capability: type 0x0d @ 0xb0 Capability: type 0x08 @ 0x44 Capability: type 0x08 @ 0x44 Capability: type 0x0d @ 0xb0 Capability: type 0x08 @ 0x44 Capability: type 0x0d @ 0xb0 PCI: 00:01.0 [1022/9602] disabled rs780_enable: dev=0021bb54, VID_DID=0x96031022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-2,3, Fun-0. enable=0 rs780_enable: dev=0021bc64, VID_DID=0x960b1022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-2,3, Fun-0. enable=0 rs780_enable: dev=0021bcec, VID_DID=0x96041022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-4,5,6,7, Fun-0. enable=0 rs780_enable: dev=0021bd74, VID_DID=0x96051022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-4,5,6,7, Fun-0. enable=0 rs780_enable: dev=0021bdfc, VID_DID=0x96061022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-4,5,6,7, Fun-0. enable=0 rs780_enable: dev=0021be84, VID_DID=0x96071022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-4,5,6,7, Fun-0. enable=0 rs780_enable: dev=0021bf0c, VID_DID=0x960a1022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-8, Fun-0. enable=0 disable_pcie_bar3() ...done rs780_enable: dev=0021bf94, VID_DID=0x96081022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-9, 10, Fun-0. enable=0 enable_pcie_bar3() ...done rs780_enable: dev=0021c01c, VID_DID=0x96091022 nb_devfn = 0x0 sb_devfn = 0x40 Bus-0, Dev-9, 10, Fun-0. enable=0 enable_pcie_bar3() ...done sb700_enable() PCI: 00:11.0 [1002/4390] ops PCI: 00:11.0 [1002/4390] enabled sb700_enable() sb700_enable() sb700_enable() sb700_enable() sb700_enable() sb700_enable() sb700_enable() PCI: 00:14.0 [1002/4385] bus ops PCI: 00:14.0 [1002/4385] enabled sb700_enable() PCI: 00:14.1 [1002/439c] ops PCI: 00:14.1 [1002/439c] enabled sb700_enable() sb700_enable() PCI: 00:14.3 [1002/439d] bus ops PCI: 00:14.3 [1002/439d] enabled sb700_enable() PCI: 00:14.4 [1002/4384] bus ops PCI: 00:14.4 [1002/4384] enabled sb700_enable() scan_static_bus for PCI: 00:14.0 smbus: PCI: 00:14.0[0]->I2C: 01:50 enabled smbus: PCI: 00:14.0[0]->I2C: 01:52 enabled scan_static_bus for PCI: 00:14.0 done scan_static_bus for PCI: 00:14.3 malloc Enter, size 2560, free_mem_ptr 00290044 malloc 00290044 PNP: 002e.0 disabled PNP: 002e.1 enabled PNP: 002e.2 disabled PNP: 002e.3 disabled PNP: 002e.4 disabled PNP: 002e.5 enabled PNP: 002e.6 enabled PNP: 002e.7 disabled PNP: 002e.8 disabled PNP: 002e.9 disabled PNP: 002e.a disabled scan_static_bus for PCI: 00:14.3 done do_pci_scan_bridge for PCI: 00:14.4 malloc Enter, size 24, free_mem_ptr 00290a44 malloc 00290a44 PCI: pci_scan_bus for bus 01 malloc Enter, size 68, free_mem_ptr 00290a5c malloc 00290a5c PCI: 01:04.0 [10ec/8169] enabled PCI: pci_scan_bus returning with max=001 do_pci_scan_bridge returns max 1 PCI: pci_scan_bus returning with max=001 PCI: pci_scan_bus returning with max=001 PCI_DOMAIN: 0000 passpw: enabled scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device read_resources bus 0 link: 0 APIC_CLUSTER: 0 read_resources bus 0 link: 0 APIC: 00 missing read_resources APIC: 01 missing read_resources APIC_CLUSTER: 0 read_resources bus 0 link: 0 done PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:18.0 read_resources bus 0 link: 1 PCI: 00:14.0 read_resources bus 1 link: 0 I2C: 01:50 missing read_resources I2C: 01:52 missing read_resources PCI: 00:14.0 read_resources bus 1 link: 0 done PCI: 00:14.3 read_resources bus 0 link: 0 PCI: 00:14.3 read_resources bus 0 link: 0 done PCI: 00:14.4 read_resources bus 1 link: 0 PCI: 00:14.4 read_resources bus 1 link: 0 done PCI: 00:18.0 read_resources bus 0 link: 1 done PCI: 00:18.0 read_resources bus 0 link: 2 PCI: 00:18.0 read_resources bus 0 link: 2 done PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done Done reading resources. Show resources in subtree (Root Device)...After reading. Root Device child on link 0 APIC_CLUSTER: 0 APIC_CLUSTER: 0 child on link 0 APIC: 00 APIC: 00 APIC: 01 PCI_DOMAIN: 0000 child on link 0 PCI: 00:18.0 PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags 40040100 index 10000000 PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags 40040200 index 10000100 PCI: 00:18.0 PCI: 00:18.0 resource base c00003 size 0 align 0 gran 0 limit cfff10 flags 1 index 101b0 PCI: 00:18.0 resource base e00003 size 0 align 0 gran 0 limit efff10 flags 1 index 101b8 PCI: 00:18.0 resource base 0 size 0 align 12 gran 12 limit ffff flags 80100 index 10000 PCI: 00:18.0 resource base 0 size 0 align 20 gran 20 limit ffffffffff flags 81200 index 10002 PCI: 00:18.0 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80200 index 10001 PCI: 00:00.0 PCI: 00:00.0 resource base 0 size 10000000 align 28 gran 28 limit ffffffffffffffff flags 201 index 1c PCI: 00:01.0 PCI: 00:02.0 PCI: 00:03.0 PCI: 00:04.0 PCI: 00:05.0 PCI: 00:06.0 PCI: 00:07.0 PCI: 00:08.0 PCI: 00:09.0 PCI: 00:0a.0 PCI: 00:11.0 PCI: 00:11.0 resource base 0 size 8 align 3 gran 3 limit ffff flags 100 index 10 PCI: 00:11.0 resource base 0 size 4 align 2 gran 2 limit ffff flags 100 index 14 PCI: 00:11.0 resource base 0 size 8 align 3 gran 3 limit ffff flags 100 index 18 PCI: 00:11.0 resource base 0 size 4 align 2 gran 2 limit ffff flags 100 index 1c PCI: 00:11.0 resource base 0 size 10 align 4 gran 4 limit ffff flags 100 index 20 PCI: 00:11.0 resource base 0 size 400 align 10 gran 10 limit ffffffff flags 200 index 24 PCI: 00:12.0 PCI: 00:12.1 PCI: 00:12.2 PCI: 00:13.0 PCI: 00:13.1 PCI: 00:13.2 PCI: 00:14.0 child on link 0 I2C: 01:50 PCI: 00:14.0 resource base fec00000 size 1000 align 8 gran 8 limit ffffffff flags 80000200 index 74 PCI: 00:14.0 resource base b00 size 10 align 8 gran 8 limit ffff flags 80000100 index 90 I2C: 01:50 I2C: 01:52 PCI: 00:14.1 PCI: 00:14.1 resource base 0 size 8 align 3 gran 3 limit ffff flags 100 index 10 PCI: 00:14.1 resource base 0 size 4 align 2 gran 2 limit ffff flags 100 index 14 PCI: 00:14.1 resource base 0 size 8 align 3 gran 3 limit ffff flags 100 index 18 PCI: 00:14.1 resource base 0 size 4 align 2 gran 2 limit ffff flags 100 index 1c PCI: 00:14.1 resource base 0 size 10 align 4 gran 4 limit ffff flags 100 index 20 PCI: 00:14.2 PCI: 00:14.3 child on link 0 PNP: 002e.0 PCI: 00:14.3 resource base 0 size 1 align 0 gran 0 limit ffffffff flags 200 index a0 PCI: 00:14.3 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0040100 index 10000000 PCI: 00:14.3 resource base ff800000 size 800000 align 0 gran 0 limit 0 flags c0040200 index 10000100 PCI: 00:14.3 resource base fec00000 size 1000 align 0 gran 0 limit 0 flags c0000200 index 3 PNP: 002e.0 PNP: 002e.0 resource base 3f0 size 8 align 3 gran 3 limit 7ff flags c0000100 index 60 PNP: 002e.0 resource base 6 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.0 resource base 2 size 1 align 0 gran 0 limit 0 flags c0000800 index 74 PNP: 002e.1 PNP: 002e.1 resource base 3f8 size 8 align 3 gran 3 limit 7ff flags c0000100 index 60 PNP: 002e.1 resource base 4 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.2 PNP: 002e.2 resource base 2f8 size 8 align 3 gran 3 limit 7ff flags c0000100 index 60 PNP: 002e.2 resource base 3 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.3 PNP: 002e.3 resource base 378 size 8 align 3 gran 3 limit 7ff flags c0000100 index 60 PNP: 002e.3 resource base 7 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.3 resource base 0 size 1 align 0 gran 0 limit 0 flags 800 index 74 PNP: 002e.4 PNP: 002e.4 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 60 PNP: 002e.4 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 62 PNP: 002e.4 resource base 0 size 1 align 0 gran 0 limit 0 flags 400 index 70 PNP: 002e.5 PNP: 002e.5 resource base 60 size 1 align 0 gran 0 limit ffffffff flags c0000100 index 60 PNP: 002e.5 resource base 64 size 1 align 0 gran 0 limit ffffffff flags c0000100 index 62 PNP: 002e.5 resource base 1 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.6 PNP: 002e.6 resource base c size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.7 PNP: 002e.7 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 62 PNP: 002e.7 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 64 PNP: 002e.8 PNP: 002e.8 resource base 300 size 2 align 1 gran 1 limit 7ff flags c0000100 index 60 PNP: 002e.8 resource base 9 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.9 PNP: 002e.9 resource base 220 size 1 align 0 gran 0 limit ffffffff flags c0000100 index 60 PNP: 002e.a PCI: 00:14.4 child on link 0 PCI: 01:04.0 PCI: 00:14.4 resource base 0 size 0 align 12 gran 12 limit ffff flags 80102 index 1c PCI: 00:14.4 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 81202 index 24 PCI: 00:14.4 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80202 index 20 PCI: 01:04.0 PCI: 01:04.0 resource base 0 size 100 align 8 gran 8 limit ffff flags 100 index 10 PCI: 01:04.0 resource base 0 size 100 align 8 gran 8 limit ffffffff flags 200 index 14 PCI: 01:04.0 resource base 0 size 8000 align 15 gran 15 limit ffffffff flags 2200 index 30 PCI: 00:14.5 PCI: 00:18.1 PCI: 00:18.2 PCI: 00:18.3 PCI: 00:18.3 resource base 0 size 4000000 align 26 gran 26 limit ffffffff flags 200 index 94 PCI_DOMAIN: 0000 compute_resources_io: base: 0 size: 0 align: 0 gran: 0 limit: ffff PCI: 00:18.0 compute_resources_io: base: 0 size: 0 align: 12 gran: 12 limit: ffff PCI: 00:14.4 compute_resources_io: base: 0 size: 0 align: 12 gran: 12 limit: ffff PCI: 01:04.0 10 * [0x0 - 0xff] io PCI: 00:14.4 compute_resources_io: base: 100 size: 1000 align: 12 gran: 12 limit: ffff done PCI: 00:14.4 1c * [0x0 - 0xfff] io PCI: 00:11.0 20 * [0x1000 - 0x100f] io PCI: 00:14.1 20 * [0x1010 - 0x101f] io PCI: 00:11.0 10 * [0x1020 - 0x1027] io PCI: 00:11.0 18 * [0x1028 - 0x102f] io PCI: 00:14.1 10 * [0x1030 - 0x1037] io PCI: 00:14.1 18 * [0x1038 - 0x103f] io PCI: 00:11.0 14 * [0x1040 - 0x1043] io PCI: 00:11.0 1c * [0x1044 - 0x1047] io PCI: 00:14.1 14 * [0x1048 - 0x104b] io PCI: 00:14.1 1c * [0x104c - 0x104f] io PCI: 00:18.0 compute_resources_io: base: 1050 size: 2000 align: 12 gran: 12 limit: ffff done PCI: 00:18.0 10000 * [0x0 - 0x1fff] io PCI_DOMAIN: 0000 compute_resources_io: base: 2000 size: 2000 align: 12 gran: 0 limit: ffff done PCI_DOMAIN: 0000 compute_resources_mem: base: 0 size: 0 align: 0 gran: 0 limit: ffffffff PCI: 00:18.0 compute_resources_prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffff PCI: 00:14.4 compute_resources_prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff PCI: 00:14.4 compute_resources_prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff done PCI: 00:18.0 compute_resources_prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffff done PCI: 00:18.0 compute_resources_mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff PCI: 00:14.4 compute_resources_mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff PCI: 01:04.0 30 * [0x0 - 0x7fff] mem PCI: 01:04.0 14 * [0x8000 - 0x80ff] mem PCI: 00:14.4 compute_resources_mem: base: 8100 size: 100000 align: 20 gran: 20 limit: ffffffff done PCI: 00:00.0 1c * [0x0 - 0xfffffff] mem PCI: 00:14.4 20 * [0x10000000 - 0x100fffff] mem PCI: 00:11.0 24 * [0x10100000 - 0x101003ff] mem PCI: 00:14.3 a0 * [0x10100400 - 0x10100400] mem PCI: 00:18.0 compute_resources_mem: base: 10100401 size: 10200000 align: 28 gran: 20 limit: ffffffff done PCI: 00:18.0 10001 * [0x0 - 0x101fffff] mem PCI: 00:18.3 94 * [0x14000000 - 0x17ffffff] mem PCI_DOMAIN: 0000 compute_resources_mem: base: 18000000 size: 18000000 align: 28 gran: 0 limit: ffffffff done avoid_fixed_resources: PCI_DOMAIN: 0000 avoid_fixed_resources:@PCI_DOMAIN: 0000 10000000 limit 0000ffff avoid_fixed_resources:@PCI_DOMAIN: 0000 10000100 limit ffffffff constrain_resources: PCI_DOMAIN: 0000 constrain_resources: PCI: 00:18.0 constrain_resources: PCI: 00:00.0 constrain_resources: PCI: 00:11.0 constrain_resources: PCI: 00:14.0 constrain_resources: I2C: 01:50 constrain_resources: I2C: 01:52 constrain_resources: PCI: 00:14.1 constrain_resources: PCI: 00:14.3 constrain_resources: PNP: 002e.1 constrain_resources: PNP: 002e.5 constrain_resources: PNP: 002e.6 constrain_resources: PCI: 00:14.4 constrain_resources: PCI: 01:04.0 constrain_resources: PCI: 00:18.1 constrain_resources: PCI: 00:18.2 constrain_resources: PCI: 00:18.3 avoid_fixed_resources2: PCI_DOMAIN: 0000 at 10000000 limit 0000ffff lim->base 00001000 lim->limit 0000ffff avoid_fixed_resources2: PCI_DOMAIN: 0000 at 10000100 limit ffffffff lim->base 00000000 lim->limit febfffff Setting resources... PCI_DOMAIN: 0000 allocate_resources_io: base:1000 size:2000 align:12 gran:0 limit:ffff Assigned: PCI: 00:18.0 10000 * [0x1000 - 0x2fff] io PCI_DOMAIN: 0000 allocate_resources_io: next_base: 3000 size: 2000 align: 12 gran: 0 done PCI: 00:18.0 allocate_resources_io: base:1000 size:2000 align:12 gran:12 limit:ffff Assigned: PCI: 00:14.4 1c * [0x1000 - 0x1fff] io Assigned: PCI: 00:11.0 20 * [0x2000 - 0x200f] io Assigned: PCI: 00:14.1 20 * [0x2010 - 0x201f] io Assigned: PCI: 00:11.0 10 * [0x2020 - 0x2027] io Assigned: PCI: 00:11.0 18 * [0x2028 - 0x202f] io Assigned: PCI: 00:14.1 10 * [0x2030 - 0x2037] io Assigned: PCI: 00:14.1 18 * [0x2038 - 0x203f] io Assigned: PCI: 00:11.0 14 * [0x2040 - 0x2043] io Assigned: PCI: 00:11.0 1c * [0x2044 - 0x2047] io Assigned: PCI: 00:14.1 14 * [0x2048 - 0x204b] io Assigned: PCI: 00:14.1 1c * [0x204c - 0x204f] io PCI: 00:18.0 allocate_resources_io: next_base: 2050 size: 2000 align: 12 gran: 12 done PCI: 00:14.4 allocate_resources_io: base:1000 size:1000 align:12 gran:12 limit:ffff Assigned: PCI: 01:04.0 10 * [0x1000 - 0x10ff] io PCI: 00:14.4 allocate_resources_io: next_base: 1100 size: 1000 align: 12 gran: 12 done PCI_DOMAIN: 0000 allocate_resources_mem: base:e0000000 size:18000000 align:28 gran:0 limit:febfffff Assigned: PCI: 00:18.0 10001 * [0xe0000000 - 0xf01fffff] mem Assigned: PCI: 00:18.3 94 * [0xf4000000 - 0xf7ffffff] mem PCI_DOMAIN: 0000 allocate_resources_mem: next_base: f8000000 size: 18000000 align: 28 gran: 0 done PCI: 00:18.0 allocate_resources_prefmem: base:febfffff size:0 align:20 gran:20 limit:febfffff PCI: 00:18.0 allocate_resources_prefmem: next_base: febfffff size: 0 align: 20 gran: 20 done PCI: 00:14.4 allocate_resources_prefmem: base:febfffff size:0 align:20 gran:20 limit:febfffff PCI: 00:14.4 allocate_resources_prefmem: next_base: febfffff size: 0 align: 20 gran: 20 done PCI: 00:18.0 allocate_resources_mem: base:e0000000 size:10200000 align:28 gran:20 limit:febfffff Assigned: PCI: 00:00.0 1c * [0xe0000000 - 0xefffffff] mem Assigned: PCI: 00:14.4 20 * [0xf0000000 - 0xf00fffff] mem Assigned: PCI: 00:11.0 24 * [0xf0100000 - 0xf01003ff] mem Assigned: PCI: 00:14.3 a0 * [0xf0100400 - 0xf0100400] mem PCI: 00:18.0 allocate_resources_mem: next_base: f0100401 size: 10200000 align: 28 gran: 20 done PCI: 00:14.4 allocate_resources_mem: base:f0000000 size:100000 align:20 gran:20 limit:febfffff Assigned: PCI: 01:04.0 30 * [0xf0000000 - 0xf0007fff] mem Assigned: PCI: 01:04.0 14 * [0xf0008000 - 0xf00080ff] mem PCI: 00:14.4 allocate_resources_mem: next_base: f0008100 size: 100000 align: 20 gran: 20 done Root Device assign_resources, bus 0 link: 0 node 0 : uma_memory_base/1024=0x001c0000, mmio_basek=0x00380000, basek=0x00000300, limitk=0x00200000 node 0: UMA memory starts below mmio_basek 0: mmio_basek=00380000, basek=00000300, limitk=00200000 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:18.0 101d8 <- [0x0000001000 - 0x0000002fff] size 0x00002000 gran 0x0c io PCI: 00:18.0 101b0 <- [0x00e0000000 - 0x00f01fffff] size 0x10200000 gran 0x14 mem PCI: 00:18.0 assign_resources, bus 0 link: 1 PCI: 00:00.0 1c <- [0x00e0000000 - 0x00efffffff] size 0x10000000 gran 0x1c mem64 PCI: 00:11.0 10 <- [0x0000002020 - 0x0000002027] size 0x00000008 gran 0x03 io PCI: 00:11.0 14 <- [0x0000002040 - 0x0000002043] size 0x00000004 gran 0x02 io PCI: 00:11.0 18 <- [0x0000002028 - 0x000000202f] size 0x00000008 gran 0x03 io PCI: 00:11.0 1c <- [0x0000002044 - 0x0000002047] size 0x00000004 gran 0x02 io PCI: 00:11.0 20 <- [0x0000002000 - 0x000000200f] size 0x00000010 gran 0x04 io PCI: 00:11.0 24 <- [0x00f0100000 - 0x00f01003ff] size 0x00000400 gran 0x0a mem ERROR: PCI: 00:14.0 74 mem size: 0x0000001000 not assigned ERROR: PCI: 00:14.0 90 io size: 0x0000000010 not assigned PCI: 00:14.0 assign_resources, bus 1 link: 0 PCI: 00:14.0 assign_resources, bus 1 link: 0 PCI: 00:14.1 10 <- [0x0000002030 - 0x0000002037] size 0x00000008 gran 0x03 io PCI: 00:14.1 14 <- [0x0000002048 - 0x000000204b] size 0x00000004 gran 0x02 io PCI: 00:14.1 18 <- [0x0000002038 - 0x000000203f] size 0x00000008 gran 0x03 io PCI: 00:14.1 1c <- [0x000000204c - 0x000000204f] size 0x00000004 gran 0x02 io PCI: 00:14.1 20 <- [0x0000002010 - 0x000000201f] size 0x00000010 gran 0x04 io PCI: 00:14.3 a0 <- [0x00f0100400 - 0x00f0100400] size 0x00000001 gran 0x00 mem PCI: 00:14.3 assign_resources, bus 0 link: 0 PNP: 002e.1 60 <- [0x00000003f8 - 0x00000003ff] size 0x00000008 gran 0x03 io PNP: 002e.1 70 <- [0x0000000004 - 0x0000000004] size 0x00000001 gran 0x00 irq PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] size 0x00000001 gran 0x00 io PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] size 0x00000001 gran 0x00 io PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] size 0x00000001 gran 0x00 irq PNP: 002e.6 70 <- [0x000000000c - 0x000000000c] size 0x00000001 gran 0x00 irq PCI: 00:14.3 assign_resources, bus 0 link: 0 PCI: 00:14.4 1c <- [0x0000001000 - 0x0000001fff] size 0x00001000 gran 0x0c bus 01 io PCI: 00:14.4 24 <- [0x00febfffff - 0x00febffffe] size 0x00000000 gran 0x14 bus 01 prefmem PCI: 00:14.4 20 <- [0x00f0000000 - 0x00f00fffff] size 0x00100000 gran 0x14 bus 01 mem PCI: 00:14.4 assign_resources, bus 1 link: 0 PCI: 01:04.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io PCI: 01:04.0 14 <- [0x00f0008000 - 0x00f00080ff] size 0x00000100 gran 0x08 mem PCI: 01:04.0 30 <- [0x00f0000000 - 0x00f0007fff] size 0x00008000 gran 0x0f romem PCI: 00:14.4 assign_resources, bus 1 link: 0 PCI: 00:18.0 assign_resources, bus 0 link: 1 PCI: 00:18.3 94 <- [0x00f4000000 - 0x00f7ffffff] size 0x04000000 gran 0x1a mem PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Show resources in subtree (Root Device)...After assigning values. Root Device child on link 0 APIC_CLUSTER: 0 APIC_CLUSTER: 0 child on link 0 APIC: 00 APIC: 00 APIC: 01 PCI_DOMAIN: 0000 child on link 0 PCI: 00:18.0 PCI_DOMAIN: 0000 resource base 1000 size 2000 align 12 gran 0 limit ffff flags 40040100 index 10000000 PCI_DOMAIN: 0000 resource base e0000000 size 18000000 align 28 gran 0 limit febfffff flags 40040200 index 10000100 PCI_DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index 10 PCI_DOMAIN: 0000 resource base c0000 size 7ff40000 align 0 gran 0 limit 0 flags e0004200 index 20 PCI: 00:18.0 PCI: 00:18.0 resource base e00003 size 0 align 0 gran 0 limit efff10 flags 1 index 101b8 PCI: 00:18.0 resource base 1000 size 2000 align 12 gran 12 limit ffff flags 60080100 index 101d8 PCI: 00:18.0 resource base febfffff size 0 align 20 gran 20 limit febfffff flags 40081200 index 10002 PCI: 00:18.0 resource base e0000000 size 10200000 align 28 gran 20 limit febfffff flags 60080200 index 101b0 PCI: 00:00.0 PCI: 00:00.0 resource base e0000000 size 10000000 align 28 gran 28 limit febfffff flags 60000201 index 1c PCI: 00:01.0 PCI: 00:02.0 PCI: 00:03.0 PCI: 00:04.0 PCI: 00:05.0 PCI: 00:06.0 PCI: 00:07.0 PCI: 00:08.0 PCI: 00:09.0 PCI: 00:0a.0 PCI: 00:11.0 PCI: 00:11.0 resource base 2020 size 8 align 3 gran 3 limit ffff flags 60000100 index 10 PCI: 00:11.0 resource base 2040 size 4 align 2 gran 2 limit ffff flags 60000100 index 14 PCI: 00:11.0 resource base 2028 size 8 align 3 gran 3 limit ffff flags 60000100 index 18 PCI: 00:11.0 resource base 2044 size 4 align 2 gran 2 limit ffff flags 60000100 index 1c PCI: 00:11.0 resource base 2000 size 10 align 4 gran 4 limit ffff flags 60000100 index 20 PCI: 00:11.0 resource base f0100000 size 400 align 10 gran 10 limit febfffff flags 60000200 index 24 PCI: 00:12.0 PCI: 00:12.1 PCI: 00:12.2 PCI: 00:13.0 PCI: 00:13.1 PCI: 00:13.2 PCI: 00:14.0 child on link 0 I2C: 01:50 PCI: 00:14.0 resource base fec00000 size 1000 align 8 gran 8 limit ffffffff flags 80000200 index 74 PCI: 00:14.0 resource base b00 size 10 align 8 gran 8 limit ffff flags 80000100 index 90 I2C: 01:50 I2C: 01:52 PCI: 00:14.1 PCI: 00:14.1 resource base 2030 size 8 align 3 gran 3 limit ffff flags 60000100 index 10 PCI: 00:14.1 resource base 2048 size 4 align 2 gran 2 limit ffff flags 60000100 index 14 PCI: 00:14.1 resource base 2038 size 8 align 3 gran 3 limit ffff flags 60000100 index 18 PCI: 00:14.1 resource base 204c size 4 align 2 gran 2 limit ffff flags 60000100 index 1c PCI: 00:14.1 resource base 2010 size 10 align 4 gran 4 limit ffff flags 60000100 index 20 PCI: 00:14.2 PCI: 00:14.3 child on link 0 PNP: 002e.0 PCI: 00:14.3 resource base f0100400 size 1 align 0 gran 0 limit febfffff flags 60000200 index a0 PCI: 00:14.3 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0040100 index 10000000 PCI: 00:14.3 resource base ff800000 size 800000 align 0 gran 0 limit 0 flags c0040200 index 10000100 PCI: 00:14.3 resource base fec00000 size 1000 align 0 gran 0 limit 0 flags c0000200 index 3 PNP: 002e.0 PNP: 002e.0 resource base 3f0 size 8 align 3 gran 3 limit 7ff flags c0000100 index 60 PNP: 002e.0 resource base 6 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.0 resource base 2 size 1 align 0 gran 0 limit 0 flags c0000800 index 74 PNP: 002e.1 PNP: 002e.1 resource base 3f8 size 8 align 3 gran 3 limit 7ff flags e0000100 index 60 PNP: 002e.1 resource base 4 size 1 align 0 gran 0 limit 0 flags e0000400 index 70 PNP: 002e.2 PNP: 002e.2 resource base 2f8 size 8 align 3 gran 3 limit 7ff flags c0000100 index 60 PNP: 002e.2 resource base 3 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.3 PNP: 002e.3 resource base 378 size 8 align 3 gran 3 limit 7ff flags c0000100 index 60 PNP: 002e.3 resource base 7 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.3 resource base 0 size 1 align 0 gran 0 limit 0 flags 800 index 74 PNP: 002e.4 PNP: 002e.4 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 60 PNP: 002e.4 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 62 PNP: 002e.4 resource base 0 size 1 align 0 gran 0 limit 0 flags 400 index 70 PNP: 002e.5 PNP: 002e.5 resource base 60 size 1 align 0 gran 0 limit ffffffff flags e0000100 index 60 PNP: 002e.5 resource base 64 size 1 align 0 gran 0 limit ffffffff flags e0000100 index 62 PNP: 002e.5 resource base 1 size 1 align 0 gran 0 limit 0 flags e0000400 index 70 PNP: 002e.6 PNP: 002e.6 resource base c size 1 align 0 gran 0 limit 0 flags e0000400 index 70 PNP: 002e.7 PNP: 002e.7 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 62 PNP: 002e.7 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 64 PNP: 002e.8 PNP: 002e.8 resource base 300 size 2 align 1 gran 1 limit 7ff flags c0000100 index 60 PNP: 002e.8 resource base 9 size 1 align 0 gran 0 limit 0 flags c0000400 index 70 PNP: 002e.9 PNP: 002e.9 resource base 220 size 1 align 0 gran 0 limit ffffffff flags c0000100 index 60 PNP: 002e.a PCI: 00:14.4 child on link 0 PCI: 01:04.0 PCI: 00:14.4 resource base 1000 size 1000 align 12 gran 12 limit ffff flags 60080102 index 1c PCI: 00:14.4 resource base febfffff size 0 align 20 gran 20 limit febfffff flags 60081202 index 24 PCI: 00:14.4 resource base f0000000 size 100000 align 20 gran 20 limit febfffff flags 60080202 index 20 PCI: 01:04.0 PCI: 01:04.0 resource base 1000 size 100 align 8 gran 8 limit ffff flags 60000100 index 10 PCI: 01:04.0 resource base f0008000 size 100 align 8 gran 8 limit febfffff flags 60000200 index 14 PCI: 01:04.0 resource base f0000000 size 8000 align 15 gran 15 limit febfffff flags 60002200 index 30 PCI: 00:14.5 PCI: 00:18.1 PCI: 00:18.2 PCI: 00:18.3 PCI: 00:18.3 resource base f4000000 size 4000000 align 26 gran 26 limit febfffff flags 60000200 index 94 Done allocating resources. Enabling resources... PCI: 00:18.0 cmd <- 00 PCI: 00:18.1 subsystem <- 4e43/6000 PCI: 00:18.1 cmd <- 00 PCI: 00:18.2 subsystem <- 4e43/6000 PCI: 00:18.2 cmd <- 00 PCI: 00:18.3 cmd <- 00 PCI: 00:00.0 subsystem <- 4e43/6000 PCI: 00:00.0 cmd <- 06 PCI: 00:11.0 cmd <- 03 PCI: 00:14.0 subsystem <- 4e43/6000 PCI: 00:14.0 cmd <- 403 PCI: 00:14.1 subsystem <- 4e43/6000 PCI: 00:14.1 cmd <- 01 PCI: 00:14.3 subsystem <- 4e43/6000 PCI: 00:14.3 cmd <- 0f sb700 lpc decode:PNP: 002e.1, base=0x000003f8, end=0x000003ff sb700 lpc decode:PNP: 002e.5, base=0x00000060, end=0x00000060 sb700 lpc decode:PNP: 002e.5, base=0x00000064, end=0x00000064 PCI: 00:14.4 bridge ctrl <- 0003 PCI: 00:14.4 cmd <- 07 PCI: 01:04.0 cmd <- 03 done. Initializing devices... APIC_CLUSTER: 0 init start_eip=0x00001000, offset=0x00210000, code_size=0x0000005b Initializing CPU #0 CPU: vendor AMD device 40f13 CPU: family 0f, model 41, stepping 03 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB ADDRESS_MASK_HIGH=0xff Setting variable MTRR 1, base: 2048MB, range: 256MB, type WB ADDRESS_MASK_HIGH=0xff Setting variable MTRR 2, base: 1792MB, range: 256MB, type UC ADDRESS_MASK_HIGH=0xff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model Dual-Core AMD Opteron(tm) Processor 2210 EE Setting up local apic... apic_id: 0x00 done. Clearing memory 32768K - 2097152K: ------------------------------- done CPU #0 initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 1. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 1. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #1 Waiting for 1 CPUS to stop CPU: vendor AMD device 40f13 CPU: family 0f, model 41, stepping 03 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB ADDRESS_MASK_HIGH=0xff Setting variable MTRR 1, base: 2048MB, range: 256MB, type WB ADDRESS_MASK_HIGH=0xff Setting variable MTRR 2, base: 1792MB, range: 256MB, type UC ADDRESS_MASK_HIGH=0xff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model Dual-Core AMD Opteron(tm) Processor 2210 EE Setting up local apic... apic_id: 0x01 done. CPU #1 initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 00:18.1 init Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram CBFS: follow chain: fff80000 + 38 + e2fc + align -> fff8e340 Check fallback/payload CBFS: follow chain: fff8e340 + 38 + 7e83 + align -> fff96200 Check CBFS: follow chain: fff96200 + 28 + 59db8 + align -> ffff0000 CBFS: Could not find file pci1022,1101.rom PCI: 00:18.2 init Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram CBFS: follow chain: fff80000 + 38 + e2fc + align -> fff8e340 Check fallback/payload CBFS: follow chain: fff8e340 + 38 + 7e83 + align -> fff96200 Check CBFS: follow chain: fff96200 + 28 + 59db8 + align -> ffff0000 CBFS: Could not find file pci1022,1102.rom PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:00.0 init pcie_init in rs780_ht.c PCI: 00:11.0 init sata_bar0=2020 sata_bar1=2040 sata_bar2=2028 sata_bar3=2044 sata_bar4=2000 sata_bar5=f0100000 SATA port 0 status = 23 drive detection done after 0 ms Primary Master device is ready after 1 tries SATA port 1 status = 0 No Primary Slave SATA drive on Slot1 SATA port 2 status = 0 No Secondary Master SATA drive on Slot2 SATA port 3 status = 0 No Secondary Slave SATA drive on Slot3 PCI: 00:14.0 init sm_init(). IOAPIC: Clearing IOAPIC at 0xfec00000 IOAPIC: 23 interrupts IOAPIC: reg 0x00000000 value 0x00000000 0x00010000 IOAPIC: reg 0x00000001 value 0x00000000 0x00010000 IOAPIC: reg 0x00000002 value 0x00000000 0x00010000 IOAPIC: reg 0x00000003 value 0x00000000 0x00010000 IOAPIC: reg 0x00000004 value 0x00000000 0x00010000 IOAPIC: reg 0x00000005 value 0x00000000 0x00010000 IOAPIC: reg 0x00000006 value 0x00000000 0x00010000 IOAPIC: reg 0x00000007 value 0x00000000 0x00010000 IOAPIC: reg 0x00000008 value 0x00000000 0x00010000 IOAPIC: reg 0x00000009 value 0x00000000 0x00010000 IOAPIC: reg 0x0000000a value 0x00000000 0x00010000 IOAPIC: reg 0x0000000b value 0x00000000 0x00010000 IOAPIC: reg 0x0000000c value 0x00000000 0x00010000 IOAPIC: reg 0x0000000d value 0x00000000 0x00010000 IOAPIC: reg 0x0000000e value 0x00000000 0x00010000 IOAPIC: reg 0x0000000f value 0x00000000 0x00010000 IOAPIC: reg 0x00000010 value 0x00000000 0x00010000 IOAPIC: reg 0x00000011 value 0x00000000 0x00010000 IOAPIC: reg 0x00000012 value 0x00000000 0x00010000 IOAPIC: reg 0x00000013 value 0x00000000 0x00010000 IOAPIC: reg 0x00000014 value 0x00000000 0x00010000 IOAPIC: reg 0x00000015 value 0x00000000 0x00010000 IOAPIC: reg 0x00000016 value 0x00000000 0x00010000 set power on after power fail ++++++++++no set NMI+++++ RTC Init sm_init() end PCI: 00:14.1 init Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram CBFS: follow chain: fff80000 + 38 + e2fc + align -> fff8e340 Check fallback/payload CBFS: follow chain: fff8e340 + 38 + 7e83 + align -> fff96200 Check CBFS: follow chain: fff96200 + 28 + 59db8 + align -> ffff0000 CBFS: Could not find file pci1002,439c.rom PCI: 00:14.3 init PCI: 00:14.4 init PNP: 002e.1 init PNP: 002e.5 init Keyboard init... No PS/2 keyboard detected. PNP: 002e.6 init PCI: 01:04.0 init Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram CBFS: follow chain: fff80000 + 38 + e2fc + align -> fff8e340 Check fallback/payload CBFS: follow chain: fff8e340 + 38 + 7e83 + align -> fff96200 Check CBFS: follow chain: fff96200 + 28 + 59db8 + align -> ffff0000 CBFS: Could not find file pci10ec,8169.rom On card, rom address for PCI: 01:04.0 = f0000000 PCI Expansion ROM, signature 0xfff0, INIT size 0x1fe00, data ptr 0xfff0 Incorrect Expansion ROM Header Signature fff0 Devices initialized Show all devs...After init. Root Device: enabled 1 APIC_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 PCI_DOMAIN: 0000: enabled 1 PCI: 00:18.0: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 0 PCI: 00:02.0: enabled 0 PCI: 00:03.0: enabled 0 PCI: 00:04.0: enabled 0 PCI: 00:05.0: enabled 0 PCI: 00:06.0: enabled 0 PCI: 00:07.0: enabled 0 PCI: 00:08.0: enabled 0 PCI: 00:09.0: enabled 0 PCI: 00:0a.0: enabled 0 PCI: 00:11.0: enabled 1 PCI: 00:12.0: enabled 0 PCI: 00:12.1: enabled 0 PCI: 00:12.2: enabled 0 PCI: 00:13.0: enabled 0 PCI: 00:13.1: enabled 0 PCI: 00:13.2: enabled 0 PCI: 00:14.0: enabled 1 I2C: 01:50: enabled 1 I2C: 01:52: enabled 1 PCI: 00:14.1: enabled 1 PCI: 00:14.2: enabled 0 PCI: 00:14.3: enabled 1 PNP: 002e.0: enabled 0 PNP: 002e.1: enabled 1 PNP: 002e.2: enabled 0 PNP: 002e.3: enabled 0 PNP: 002e.4: enabled 0 PNP: 002e.5: enabled 1 PNP: 002e.6: enabled 1 PNP: 002e.7: enabled 0 PNP: 002e.8: enabled 0 PNP: 002e.9: enabled 0 PNP: 002e.a: enabled 0 PCI: 00:14.4: enabled 1 PCI: 00:14.5: enabled 0 PCI: 00:18.1: enabled 1 PCI: 00:18.2: enabled 1 PCI: 00:18.3: enabled 1 APIC: 01: enabled 1 PCI: 01:04.0: enabled 1 Initializing CBMEM area to 0x6fff0000 (65536 bytes) Adding CBMEM entry as no. 1 Moving GDT to 6fff0200...ok High Tables Base is 6fff0000. Writing IRQ routing tables to 0xf0000...write_pirq_routing_table done. Adding CBMEM entry as no. 2 Writing IRQ routing tables to 0x6fff0400...write_pirq_routing_table done. PIRQ table: 48 bytes. Wrote the mp table end at: 000f0410 - 000f054c Adding CBMEM entry as no. 3 Wrote the mp table end at: 6fff1410 - 6fff154c MP table: 332 bytes. Adding CBMEM entry as no. 4 ACPI: Writing ACPI tables at 6fff2400... ACPI: * HPET ACPI: added table 1/32 Length now 40 ACPI: * MADT ACPI: added table 2/32 Length now 44 ACPI: * SSDT processor_brand=Dual-Core AMD Opteron(tm) Processor 2210 EE Pstates Algorithm ... No intermediate P-states are supported ACPI: added table 3/32 Length now 48 ACPI: * FACS ACPI: * DSDT ACPI: * DSDT @ 6fff27c2 Length 298c ACPI: * FADT pm_base: 0x0800 ACPI: added table 4/32 Length now 52 ACPI: done. ACPI tables: 11842 bytes. Multiboot Information structure has been written. Adding CBMEM entry as no. 5 Writing high table forward entry at 0x00000500 Wrote coreboot table at: 00000500 - 00000518 checksum afde New low_table_end: 0x00000518 Now going to write high coreboot table at 0x6fffe000 rom_table_end = 0x6fffe000 Adjust low_table_end from 0x00000518 to 0x00001000 Adjust rom_table_end from 0x6fffe000 to 0x70000000 Adding high table area uma_memory_start=0x70000000, uma_memory_size=0x10000000 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000c0000-000000006ffeffff: RAM 3. 000000006fff0000-000000006fffffff: CONFIGURATION TABLES 4. 0000000070000000-000000007fffffff: RESERVED Wrote coreboot table at: 6fffe000 - 6fffe1b4 checksum 268e coreboot table: 436 bytes. 0. FREE SPACE 70000000 00000000 1. GDT 6fff0200 00000200 2. IRQ TABLE 6fff0400 00001000 3. SMP TABLE 6fff1400 00001000 4. ACPI 6fff2400 0000bc00 5. COREBOOT 6fffe000 00002000 Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram CBFS: follow chain: fff80000 + 38 + e2fc + align -> fff8e340 Check fallback/payload Got a payload Loading segment from rom address 0xfff8e378 parameter section (skipped) Loading segment from rom address 0xfff8e394 data (compression=1) malloc Enter, size 36, free_mem_ptr 00290aa0 malloc 00290aa0 New segment dstaddr 0x100000 memsize 0x133b40 srcaddr 0xfff8e416 filesize 0x7db8 (cleaned up) New segment addr 0x100000 size 0x133b40 offset 0xfff8e416 filesize 0x7db8 Loading segment from rom address 0xfff8e3b0 data (compression=1) malloc Enter, size 36, free_mem_ptr 00290ac4 malloc 00290ac4 New segment dstaddr 0x233b40 memsize 0x48 srcaddr 0xfff961ce filesize 0x2d (cleaned up) New segment addr 0x233b40 size 0x48 offset 0xfff961ce filesize 0x2d Loading segment from rom address 0xfff8e3cc Entry Point 0x00100000 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000133b40 filesz: 0x0000000000007db8 lb: [0x0000000000200000, 0x0000000000350000) segment: [0x0000000000100000, 0x0000000000107db8, 0x0000000000233b40) bounce: [0x000000006fc50000, 0x000000006fc57db8, 0x000000006fd83b40) Post relocation: addr: 0x000000006fc50000 memsz: 0x0000000000133b40 filesz: 0x0000000000007db8 using LZMA [ 0x6fc50000, 6fc61b24, 0x6fd83b40) <- fff8e416 Clearing Segment: addr: 0x000000006fc61b24 memsz: 0x000000000012201c dest 6fc50000, end 6fd83b40, bouncebuffer 6fd50000 move prefix around: from 6fc50000, to 00100000, amount: 100000 Loading Segment: addr: 0x0000000000233b40 memsz: 0x0000000000000048 filesz: 0x000000000000002d lb: [0x0000000000200000, 0x0000000000350000) segment: [0x0000000000233b40, 0x0000000000233b6d, 0x0000000000233b88) bounce: [0x000000006fd83b40, 0x000000006fd83b6d, 0x000000006fd83b88) Post relocation: addr: 0x000000006fd83b40 memsz: 0x0000000000000048 filesz: 0x000000000000002d using LZMA [ 0x6fd83b40, 6fd83b88, 0x6fd83b88) <- fff961ce dest 6fd83b40, end 6fd83b88, bouncebuffer 6fd50000 Loaded segments Jumping to boot code at 100000 entry = 0x00100000 lb_start = 0x00200000 lb_size = 0x00150000 adjust = 0x6fca0000 buffer = 0x6fd50000 elf_boot_notes = 0x0021b298 adjusted_boot_notes = 0x6febb298 FILO version 0.6.0 (liutao at eda7) Tue Sep 7 16:14:09 CST 2010 boot EAX = 0x2badb002 boot EBX = 0xf0830 boot arg = 0xf0830 Press for default boot, or for boot prompt... timed out boot: hda2:/vmlinuz initrd=hda2:/initrd console=ttyS0,115200 IDE time out reset failed, but slave may exist hda: LBA48 320GB: Hitachi HTS543232L9A300 Not a bootable ELF image: hda2:/vmlinuz Found Linux version 2.6.27.19-5-default (geeko at buildhost) #1 SMP Wed Sep 8 11:36:24 EDT 2010 (protocol 0x209) (loadflags 0x1) bzImage. Setting up paramters at 0x90000 %016Lx - %016Lx (0) %016Lx - %016Lx (4096) %016Lx - %016Lx (786432) %016Lx - %016Lx (1878982656) %016Lx - %016Lx (1879048192) ramtop=0x80000000 ext_mem_k=64512, alt_mem_k=2096128 original command line: "initrd=hda2:/initrd console=ttyS0,115200" kernel command line at 0x91000 debug, name = initrd, len = 6 initrd=hda2:/initrd debug, name = console, len = 7 kernel command line (20 bytes): "console=ttyS0,115200" offset=0x3200 addr=0x100000 size=0x262be0 Loading kernel... ok debug, initrd_file set to: hda2:/initrdstart=0x6f8e8000 end=0x6febbaf5 Loading initrd... ok EIP=0x100000 Jumping to entry point... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.27.19-5-default (geeko at buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Wed Sep 8 11:36:24 EDT 2010 Command line: console=ttyS0,115200 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000001000 type 16 BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 000000006fff0000 (usable) BIOS-e820: 000000006fff0000 - 0000000070000000 type 16 BIOS-e820: 0000000070000000 - 0000000080000000 (reserved) DMI not present or invalid. last_pfn = 0x6fff0 max_arch_pfn = 0x3ffffffff x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 init_memory_mapping last_map_addr: 6fff0000 end: 6fff0000 RAMDISK: 6f8e8000 - 6febbaf5 ACPI: RSDP 000F0800, 0014 (r0 CORE ) ACPI: RSDT 6FFF2424, 0034 (r1 CORE COREBOOT 0 CORE 0) ACPI: HPET 6FFF24C8, 0038 (r1 CORE COREBOOT 0 CORE 0) ACPI: APIC 6FFF2500, 005C (r1 CORE COREBOOT 0 CORE 0) ACPI: SSDT 6FFF255C, 0226 (r2 CORE DYNADATA 2A CORE 2A) ACPI: FACP 6FFF514E, 00F4 (r1 CORE COREBOOT 0 CORE 0) ACPI: DSDT 6FFF27C2, 298C (r2 NCIC X6000 10001 INTL 20090123) ACPI: FACS 6FFF2782, 0040 Scanning NUMA topology in Northbridge 24 No NUMA configuration found Faking a node at 0000000000000000-000000006fff0000 Bootmem setup node 0 0000000000000000-000000006fff0000 NODE_DATA [000000000000a000 - 0000000000021fff] bootmap [0000000000022000 - 000000000002ffff] pages e (6 early reservations) ==> bootmem [0000000000 - 006fff0000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000] #2 [0000200000 - 0000bb78b8] TEXT DATA BSS ==> [0000200000 - 0000bb78b8] #3 [006f8e8000 - 006febbaf5] RAMDISK ==> [006f8e8000 - 006febbaf5] #4 [000009f000 - 0000100000] BIOS reserved ==> [000009f000 - 0000100000] #5 [0000008000 - 000000a000] PGTABLE ==> [0000008000 - 000000a000] found SMP MP-table at [ffff8800000f0400] 000f0400 Zone PFN ranges: DMA 0x00000001 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00100000 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x00000001 -> 0x000000a0 0: 0x000000c0 -> 0x0006fff0 ACPI: PM-Timer IO Port: 0x818 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: HPET id: 0x102282a0 base: 0xfed00000 Using ACPI (MADT) for SMP configuration information SMP: Allowing 2 CPUs, 0 hotplug CPUs PM: Registered nosave memory: 00000000000a0000 - 00000000000c0000 Allocating PCI resources starting at 88000000 (gap: 80000000:80000000) PERCPU: Allocating 61344 bytes of per cpu data Built 1 zonelists in Node order, mobility grouping on. Total pages: 448944 Policy zone: DMA32 Kernel command line: console=ttyS0,115200 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) TSC: PIT calibration confirmed by PMTIMER. TSC: using PIT calibration value Detected 1002.539 MHz processor. Console: colour dummy device 80x25 console [ttyS0] enabled Checking aperture... No AGP bridge found Node 0: aperture @ f4000000 size 64 MB Memory: 1789456k/1834944k available (2686k kernel code, 45356k reserved, 3105k data, 788k init) HPET config register value = 0xFFFFFFFF. Disabling HPET Calibrating delay loop (skipped), value calculated using timer frequency.. 2005.07 BogoMIPS (lpj=4010156) kdb version 4.4 by Keith Owens, Scott Lurndal. Copyright SGI, All Rights Reserved kdb_cmd[0]: defcmd archkdb "" "First line arch debugging" kdb_cmd[7]: defcmd archkdbcpu "" "archkdb with only tasks on cpus" kdb_cmd[14]: defcmd archkdbshort "" "archkdb with less detailed backtrace" kdb_cmd[21]: defcmd archkdbcommon "" "Common arch debugging" Security Framework initialized AppArmor: AppArmor initialized Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 using C1E aware idle routine ACPI: Core revision 20080609 ACPI: Checking initramfs for custom DSDT Parsing all Control Methods: Table [DSDT](id 0001) - 540 Objects with 51 Devices 123 Methods 14 Regions ACPI Error (dswload-0334): [\_PR_.CPU0] Namespace lookup failure, AE_ALREADY_EXISTS ACPI Exception (psloop-0226): AE_ALREADY_EXISTS, During name lookup/catalog [20080609] tbxface-0596 [00] tb_load_namespace : ACPI Tables successfully acquired evxfevnt-0079 [00] enable : System is already in ACPI mode Setting APIC routing to flat ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: Dual-Core AMD Opteron(tm) Processor 2210 EE stepping 03 Using local APIC timer interrupts. Detected 12.531 MHz APIC timer. HARDWARE ERROR CPU 0: Machine Check Exception: 4 Bank 0: f647200000000833 TSC 56a8442e5 ADDR 6000 This is not a software problem! Run through mcelog --ascii to decode and contact your hardware vendor Kernel panic - not syncing: Machine check ------------[ cut here ]------------ WARNING: at kernel/smp.c:331 smp_call_function_mask+0x32/0x1ec() Modules linked in: Supported: Yes Pid: 1, comm: swapper Tainted: G M 2.6.27.19-5-default #1 Call Trace: [] show_trace_log_lvl+0x41/0x58 [] dump_stack+0x69/0x6f [] warn_on_slowpath+0x51/0x77 [] smp_call_function_mask+0x32/0x1ec [] smp_call_function+0x29/0x2e [] native_smp_send_stop+0x1a/0x26 [] panic+0xbc/0x169 [] mce_log+0x0/0x7e [] do_machine_check+0x31e/0x3cd [] machine_check+0x7f/0x90 [] setup_trampoline+0x20/0x30 [] native_cpu_up+0x31e/0xc64 [] _cpu_up+0x9a/0x11c [] cpu_up+0x5b/0x6f [] kernel_init+0xe1/0x1eb [] child_rip+0xa/0x11 ---[ end trace 4eaa2a86a8e2da22 ]--- From scott at notabs.org Tue Sep 14 05:07:50 2010 From: scott at notabs.org (Scott Duplichan) Date: Mon, 13 Sep 2010 22:07:50 -0500 Subject: [coreboot] [PATCH] correct 'Fix for Erratum 343 for AMD Fam10h CPUs' Message-ID: <2EB0521595C845F79F340D266EE6D5B8@m3a78> This patch corrects a coding error in the original implementation of 'Erratum 343 for AMD Fam10h CPUs' (rev 4345). The original code sets msr c001_102a bit 3 when bit 35 was intended. Signed-off-by: Scott Duplichan Index: src/cpu/amd/car/cache_as_ram.inc =================================================================== --- src/cpu/amd/car/cache_as_ram.inc (revision 5813) +++ src/cpu/amd/car/cache_as_ram.inc (working copy) @@ -129,8 +129,8 @@ /* execute special read command for msr-register. Result is then in the EDX:EAX-registers (MSBs in EDX) */ rdmsr - /* Set bit 35 to 1 in EAX */ - bts $35, %eax + /* Set bit 35 to 1 in EDX:EAX */ + bts $35-32, %edx /* write back the modified register EDX:EAX to the MSR specified in ECX */ wrmsr From scott at notabs.org Tue Sep 14 05:15:32 2010 From: scott at notabs.org (Scott Duplichan) Date: Mon, 13 Sep 2010 22:15:32 -0500 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <8762yarpqb.fsf@taniquetil.gledits.ch> References: <4C812B6D020000FE0000D531@mail.lkfd.net><87aanv1eax.fsf@taniquetil.gledits.ch><4C84BD83.2030502@coresystems.de><8762yj170a.fsf@taniquetil.gledits.ch><673D2439DC3046D0903811C4830EA052@m3a78><2AB823A1470D4921A664FB35592308CE@m3a78><87wrqvs5ua.fsf@taniquetil.gledits.ch><87sk1js2d8.fsf@taniquetil.gledits.ch><87occ7s0gf.fsf@taniquetil.gledits.ch> <8762yarpqb.fsf@taniquetil.gledits.ch> Message-ID: <0EF599E03B5F42D581CE5F4D71FAC485@m3a78> ]-----Original Message----- ]From: coreboot-bounces+scott=notabs.org at coreboot.org [mailto:coreboot-]bounces+scott=notabs.org at coreboot.org] On Behalf Of Arne Georg Gleditsch ]Sent: Monday, September 13, 2010 03:51 AM ]To: Scott Duplichan ]Cc: 'Marc Jones'; coreboot at coreboot.org ]Subject: Re: [coreboot] AMD cache setup is broken ] ]"Scott Duplichan" writes: ]> I think it would be best to clear bit 35 of msr c001_102a in the AP ]> cores as well as the BSP core. Otherwise, the OS might see AP cores ]> having slightly lower performance than the BSP core. This bit affects ]> family 10h revC and newer (45 nm). ] ]Ok, so here's a patch adding this. Clearing bit 35 is done ]unconditionally for all fam10 cpus, is that ok? Setting is done based ]on processor type in defaults.h, as before. Thanks. This looks correct to me. I used simnow/tilapia to confirm bit 35 gets cleared in all cores. I found bit 35 never actually gets set. I submitted a patch to correct that. Once that patch is applied, I can see bit 35 gets set in all cores, then gets cleared in all cores. Thanks, Scott ] ]Signed-off-by: Arne Georg Gleditsch ] ]-- ] Arne. From svn at coreboot.org Tue Sep 14 19:28:41 2010 From: svn at coreboot.org (repository service) Date: Tue, 14 Sep 2010 19:28:41 +0200 Subject: [coreboot] [commit] r5814 - trunk/src/cpu/amd/car Message-ID: Author: mjones Date: Tue Sep 14 19:28:41 2010 New Revision: 5814 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5814 Log: This patch corrects a coding error in the original implementation of 'Erratum 343 for AMD Fam10h CPUs' (rev 4345). The original code sets msr c001_102a bit 3 when bit 35 was intended. Signed-off-by: Scott Duplichan Acked-by: Marc Jones Modified: trunk/src/cpu/amd/car/cache_as_ram.inc Modified: trunk/src/cpu/amd/car/cache_as_ram.inc ============================================================================== --- trunk/src/cpu/amd/car/cache_as_ram.inc Mon Sep 13 21:31:21 2010 (r5813) +++ trunk/src/cpu/amd/car/cache_as_ram.inc Tue Sep 14 19:28:41 2010 (r5814) @@ -129,8 +129,8 @@ /* execute special read command for msr-register. Result is then in the EDX:EAX-registers (MSBs in EDX) */ rdmsr - /* Set bit 35 to 1 in EAX */ - bts $35, %eax + /* Set bit 35 to 1 in EAX:EDX */ + bts $35-32, %edx /* write back the modified register EDX:EAX to the MSR specified in ECX */ wrmsr From marcj303 at gmail.com Tue Sep 14 19:29:02 2010 From: marcj303 at gmail.com (Marc Jones) Date: Tue, 14 Sep 2010 11:29:02 -0600 Subject: [coreboot] [PATCH] correct 'Fix for Erratum 343 for AMD Fam10h CPUs' In-Reply-To: <2EB0521595C845F79F340D266EE6D5B8@m3a78> References: <2EB0521595C845F79F340D266EE6D5B8@m3a78> Message-ID: On Mon, Sep 13, 2010 at 9:07 PM, Scott Duplichan wrote: > This patch corrects a coding error in the original implementation > of 'Erratum 343 for AMD Fam10h CPUs' (rev 4345). The original code > sets msr c001_102a bit 3 when bit 35 was intended. > > > Signed-off-by: Scott Duplichan > > Index: src/cpu/amd/car/cache_as_ram.inc > =================================================================== > --- src/cpu/amd/car/cache_as_ram.inc ? ?(revision 5813) > +++ src/cpu/amd/car/cache_as_ram.inc ? ?(working copy) > @@ -129,8 +129,8 @@ > ? ? ? ?/* execute special read command for msr-register. Result is then in the EDX:EAX-registers (MSBs in EDX) */ > ? ? ? ?rdmsr > > - ? ? ? /* Set bit 35 to 1 in EAX */ > - ? ? ? bts ? ? $35, %eax > + ? ? ? /* Set bit 35 to 1 in EDX:EAX */ > + ? ? ? bts ? ? $35-32, %edx > > ? ? ? ?/* write back the modified register EDX:EAX to the MSR specified in ECX */ > ? ? ? ?wrmsr > Nice catch Scott. That for all the help recently. Acked-by: Marc Jones r5814 Marc -- http://se-eng.com From marcj303 at gmail.com Tue Sep 14 21:30:16 2010 From: marcj303 at gmail.com (Marc Jones) Date: Tue, 14 Sep 2010 13:30:16 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> <87vd69wi5m.fsf@taniquetil.gledits.ch> Message-ID: On Mon, Sep 13, 2010 at 2:31 PM, Myles Watson wrote: > On Mon, Sep 13, 2010 at 1:35 PM, Arne Georg Gleditsch > wrote: >> Myles Watson writes: >>> So even though there are PCI resources located at 0xc0000000, RAM gets >>> used for UMA at 0xd0000000 and tables get placed at 0xcfff0000. >> >> PCI resources at 0xd0000000? ?Doesn't this conflict with the setting of >> NV_BottomIO in src/northbridge/amd/amdmct/wrappers/mcti_d.c? > > That could be. ?I'm totally ignorant of the fam10 code oustside of > northbridge/amd/amdfam10. > > Looking at the boot log, it doesn't seem unreasonable to have PCI > resources from starting at 0xc0000000. > > It seems like we have a couple of options: > 1. Reclaim the area used for MMCONF on this board > 2. Move NV_BottomIO > > Probably 2 is the best. ?It's too bad to have that hard coded. > Yes, option 2 is best. These options may need to move to the mainboard directory now that they need to be changed. Marc -- http://se-eng.com From scott at notabs.org Tue Sep 14 23:38:43 2010 From: scott at notabs.org (Scott Duplichan) Date: Tue, 14 Sep 2010 16:38:43 -0500 Subject: [coreboot] coreboot and win7 In-Reply-To: References: Message-ID: <20D437FDDC5442DFA5322FB94CE7683C@m3a78> ]-----Original Message----- ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Myles Watson ]Sent: Monday, September 13, 2010 09:39 PM ]To: Scott Duplichan ]Cc: coreboot at coreboot.org ]Subject: Re: [coreboot] coreboot and win7 ] ]On Mon, Sep 13, 2010 at 5:37 PM, Scott Duplichan wrote: ]> I am able to boot Win7 using coreboot+seabios on a couple of AMD SB700 systems. ]> Testing so far is with simnow only. Hopefully someone else can try the changes ]> on a real board. I am still building with UMA disabled and using external PCI ]> video instead, to avoid a payload/acpi table overlap problem. ]Thanks for your work. ] ]I'd be interested in your tests of the latest code with the changes to ]the Asus M4... board. ] ]> I have tested ]> with Tilapia family 10h and Mahogany family 10h on simnow using Win7 PE ]> edition (see attached). Usually a pass with this setup means real hardware ]> will work, and other Win7 editions will work as well. Here are the changes: ]> ]> 1) Fix BSOD about "this bios is not fully acpi compliant". Windows makes this ]> BSOD because DRAM is reported both by E820 and by SB ACPI _CRS. Also, there ]> is a reference to undefined ACPI object TOM2. Removing the reporting of DRAM ]> from ACPI _CRS solves these problems. ]> ]> 2) SB I/O APIC ID: Coreboot programs ID zero, which conflicts with processor ]> cores. ACPI reports ID 2, which conflicts with processor cores. Win7 ]> reprograms to match ACPI. The conflict seems harmless, at least with simnow ]> testing. I gave the I/O APIC a unique ID just to be sure. ]> ]> 3) PS/2 KB and mouse were missing from ACPI which causes Win7 to ignore them. ]> I added them. ]> ]> Other patches I used, unrelated to Win7: ]> ]> 1) Avoid an essentially infinite PCI bus scan when a bad dev_fn value is ]> passed in from hypertransport.c. It is not clear if this can happen only ]> on simnow. ]This has been patched in svn now. The root cause should still be ]fixed, but at least it shouldn't have an infinite loop any more. Ah yes, great! ]Thanks, ]Myles Here is an acpi patch that lets asustek m4a785-m boot win7. It is tested on simnow with the PE edition of win7. I didn't encounter any uma-payload overlap problem, so I left uma enabled. However, simnow doesn't emulate uma graphics for rs780, so I tested using a pci video card: Signed-off-by: Scott Duplichan Index: src/mainboard/asus/m4a785-m/Kconfig =================================================================== --- src/mainboard/asus/m4a785-m/Kconfig (revision 5814) +++ src/mainboard/asus/m4a785-m/Kconfig (working copy) @@ -21,7 +21,7 @@ select LIFT_BSP_APIC_ID select SERIAL_CPU_INIT select AMDMCT - select GENERATE_ACPI_TABLES + select HAVE_ACPI_TABLES select BOARD_ROMSIZE_KB_1024 select ENABLE_APIC_EXT_ID select TINY_BOOTBLOCK Index: src/mainboard/asus/m4a785-m/dsdt.asl =================================================================== --- src/mainboard/asus/m4a785-m/dsdt.asl (revision 5814) +++ src/mainboard/asus/m4a785-m/dsdt.asl (working copy) @@ -22,8 +22,8 @@ "DSDT.AML", /* Output filename */ "DSDT", /* Signature */ 0x02, /* DSDT Revision, needs to be 2 for 64bit */ - "AMD ", /* OEMID */ - "TILAPIA ", /* TABLE ID */ + "ASUS ", /* OEMID */ + "M4A785-M", /* TABLE ID */ 0x00010001 /* OEM Revision */ ) { /* Start of ASL file */ @@ -33,8 +33,6 @@ /* FIXME the patching is not done yet! */ /* Memory related values */ Name(LOMH, 0x0) /* Start of unused memory in C0000-E0000 range */ - Name(PBAD, 0x0) /* Address of BIOS area (If TOM2 != 0, Addr >> 16) */ - Name(PBLN, 0x0) /* Length of BIOS area */ Name(PCBA, 0xE0000000) /* Base address of PCIe config space */ Name(HPBA, 0xFED00000) /* Base address of HPET table */ @@ -1167,8 +1165,6 @@ /* _SB.PCI0 */ /* Note: Only need HID on Primary Bus */ Device(PCI0) { - External (TOM1) - External (TOM2) Name(_HID, EISAID("PNP0A03")) Name(_ADR, 0x00180000) /* Dev# = BSP Dev#, Func# = 0 */ Method(_BBN, 0) { /* Bus number = 0 */ @@ -1390,6 +1386,63 @@ }) } /* End Device(_SB.PCI0.LpcIsaBr.SPKR) */ + + Device (KBD) + { + Name (_HID, EisaId ("PNP0303")) + Name (_CID, EisaId ("PNP030B")) + Method (_STA, 0, NotSerialized) + { + Return (0x0f) + } + Method (_CRS, 0, NotSerialized) + { + Name (TMP, ResourceTemplate () { + IO (Decode16, 0x0060, 0x0060, 0x01, 0x01) + IO (Decode16, 0x0064, 0x0064, 0x01, 0x01) + IRQNoFlags () {1} + }) + Return (TMP) + } + } + + /* PS/2 mouse */ + Device (MOU) + { + Name (_HID, EisaId ("PNP0F13")) + Method (_STA, 0, NotSerialized) + { + Return (0x0f) + } + Method (_CRS, 0, NotSerialized) + { + Name (TMP, ResourceTemplate () { + IRQNoFlags () {12} + }) + Return (TMP) + } + } + + /* PS/2 floppy controller */ + Device (FDC0) + { + Name (_HID, EisaId ("PNP0700")) + Method (_STA, 0, NotSerialized) + { + Return (0x0f) + } + Method (_CRS, 0, NotSerialized) + { + Name (BUF0, ResourceTemplate () { + IO (Decode16, 0x03F2, 0x03F2, 0x00, 0x04) + IO (Decode16, 0x03F7, 0x03F7, 0x00, 0x01) + IRQNoFlags () {6} + DMA (Compatibility, NotBusMaster, Transfer8) {2} + }) + Return (BUF0) + } + } + Device(PIC) { Name(_HID,EISAID("PNP0000")) /* AT Interrupt Controller */ Name(_CRS, ResourceTemplate() { @@ -1544,48 +1597,11 @@ 0xF300 /* length */ ) - Memory32Fixed(READWRITE, 0, 0xA0000, BSMM) Memory32Fixed(READONLY, 0x000A0000, 0x00020000, VGAM) /* VGA memory space */ Memory32Fixed(READONLY, 0x000C0000, 0x00020000, EMM1) /* Assume C0000-E0000 empty */ Memory32Fixed(READONLY, 0x000E0000, 0x00020000, RDBS) /* BIOS ROM area */ - /* DRAM Memory from 1MB to TopMem */ - Memory32Fixed(READWRITE, 0x00100000, 0, DMLO) /* 1MB to TopMem */ - /* BIOS space just below 4GB */ - DWORDMemory( - ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, - 0x00, /* Granularity */ - 0x00000000, /* Min */ - 0x00000000, /* Max */ - 0x00000000, /* Translation */ - 0x00000001, /* Max-Min, RLEN */ - ,, - PCBM - ) - - /* DRAM memory from 4GB to TopMem2 */ - QWORDMemory(ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, - 0x00000000, /* Granularity */ - 0x00000000, /* Min */ - 0x00000000, /* Max */ - 0x00000000, /* Translation */ - 0x00000001, /* Max-Min, RLEN */ - ,, - DMHI - ) - - /* BIOS space just below 16EB */ - QWORDMemory(ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, - 0x00000000, /* Granularity */ - 0x00000000, /* Min */ - 0x00000000, /* Max */ - 0x00000000, /* Translation */ - 0x00000001, /* Max-Min, RLEN */ - ,, - PEBM - ) - }) /* End Name(_SB.PCI0.CRES) */ Method(_CRS, 0) { @@ -1593,41 +1609,12 @@ CreateDWordField(CRES, ^EMM1._BAS, EM1B) CreateDWordField(CRES, ^EMM1._LEN, EM1L) - CreateDWordField(CRES, ^DMLO._BAS, DMLB) - CreateDWordField(CRES, ^DMLO._LEN, DMLL) - CreateDWordField(CRES, ^PCBM._MIN, PBMB) - CreateDWordField(CRES, ^PCBM._LEN, PBML) - CreateQWordField(CRES, ^DMHI._MIN, DMHB) - CreateQWordField(CRES, ^DMHI._LEN, DMHL) - CreateQWordField(CRES, ^PEBM._MIN, EBMB) - CreateQWordField(CRES, ^PEBM._LEN, EBML) - If(LGreater(LOMH, 0xC0000)){ Store(0xC0000, EM1B) /* Hole above C0000 and below E0000 */ Subtract(LOMH, 0xC0000, EM1L) /* subtract start, assumes allocation from C0000 going up */ } - /* Set size of memory from 1MB to TopMem */ - Subtract(TOM1, 0x100000, DMLL) - - /* - * If(LNotEqual(TOM2, 0x00000000)){ - * Store(0x100000000,DMHB) DRAM from 4GB to TopMem2 - * Subtract(TOM2, 0x100000000, DMHL) - * } - */ - - /* If there is no memory above 4GB, put the BIOS just below 4GB */ - If(LEqual(TOM2, 0x00000000)){ - Store(PBAD,PBMB) /* Reserve the "BIOS" space */ - Store(PBLN,PBML) - } - Else { /* Otherwise, put the BIOS just below 16EB */ - ShiftLeft(PBAD,16,EBMB) /* Reserve the "BIOS" space */ - Store(PBLN,EBML) - } - Return(CRES) /* note to change the Name buffer */ } /* end of Method(_SB.PCI0._CRS) */ Index: src/northbridge/amd/amdfam10/amdfam10_acpi.c =================================================================== --- src/northbridge/amd/amdfam10/amdfam10_acpi.c (revision 5814) +++ src/northbridge/amd/amdfam10/amdfam10_acpi.c (working copy) @@ -195,7 +195,6 @@ int i; u32 dword; - msr_t msr; // the offset could be different if have different HC_NUMS, and HC_POSSIBLE_NUM and ssdt.asl BUSN = ssdt+0x3b; //+5 will be next BUSN @@ -231,9 +230,6 @@ *SBLK = (u8)(sysconf.sblk); - msr = rdmsr(TOP_MEM); - int_to_stream(msr.lo, TOM1); - int_to_stream(sysconf.sbdn, SBDN); for(i=0;i References: <20D437FDDC5442DFA5322FB94CE7683C@m3a78> Message-ID: <4C8FEBDF.3060805@georgi-clan.de> Am 14.09.2010 23:38, schrieb Scott Duplichan: > --- src/mainboard/asus/m4a785-m/dsdt.asl (revision 5814) > +++ src/mainboard/asus/m4a785-m/dsdt.asl (working copy) > @@ -22,8 +22,8 @@ > "DSDT.AML", /* Output filename */ > "DSDT", /* Signature */ > 0x02, /* DSDT Revision, needs to be 2 for 64bit */ > - "AMD ", /* OEMID */ > - "TILAPIA ", /* TABLE ID */ > + "ASUS ", /* OEMID */ > + "M4A785-M", /* TABLE ID */ Where does that come from? Regards, Patrick From peter at stuge.se Tue Sep 14 23:53:50 2010 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Sep 2010 23:53:50 +0200 Subject: [coreboot] coreboot and win7 In-Reply-To: <4C8FEBDF.3060805@georgi-clan.de> References: <20D437FDDC5442DFA5322FB94CE7683C@m3a78> <4C8FEBDF.3060805@georgi-clan.de> Message-ID: <20100914215350.23114.qmail@stuge.se> Patrick Georgi wrote: > > --- src/mainboard/asus/m4a785-m/dsdt.asl (revision 5814) > > +++ src/mainboard/asus/m4a785-m/dsdt.asl (working copy) > > @@ -22,8 +22,8 @@ > > "DSDT.AML", /* Output filename */ > > "DSDT", /* Signature */ > > 0x02, /* DSDT Revision, needs to be 2 for 64bit */ > > - "AMD ", /* OEMID */ > > - "TILAPIA ", /* TABLE ID */ > > + "ASUS ", /* OEMID */ > > + "M4A785-M", /* TABLE ID */ > Where does that come from? I think it's to make the names in the ACPI tables match the actual board. //Peter From scott at notabs.org Tue Sep 14 23:54:14 2010 From: scott at notabs.org (Scott Duplichan) Date: Tue, 14 Sep 2010 16:54:14 -0500 Subject: [coreboot] coreboot and win7 In-Reply-To: <4C8FEBDF.3060805@georgi-clan.de> References: <20D437FDDC5442DFA5322FB94CE7683C@m3a78> <4C8FEBDF.3060805@georgi-clan.de> Message-ID: <0CB9F4251AF44909B0AE79EB6E001AD7@m3a78> ]-----Original Message----- ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Patrick ]Georgi ]Sent: Tuesday, September 14, 2010 04:41 PM ]To: coreboot at coreboot.org ]Subject: Re: [coreboot] coreboot and win7 ] ]Am 14.09.2010 23:38, schrieb Scott Duplichan: ]> --- src/mainboard/asus/m4a785-m/dsdt.asl (revision 5814) ]> +++ src/mainboard/asus/m4a785-m/dsdt.asl (working copy) ]> @@ -22,8 +22,8 @@ ]> "DSDT.AML", /* Output filename */ ]> "DSDT", /* Signature */ ]> 0x02, /* DSDT Revision, needs to be 2 for 64bit */ ]> - "AMD ", /* OEMID */ ]> - "TILAPIA ", /* TABLE ID */ ]> + "ASUS ", /* OEMID */ ]> + "M4A785-M", /* TABLE ID */ ]Where does that come from? I am not sure I understand the question. This part of the patch is not essential and cosmetic only. Apparently amd tilapia was the starting point for the asustek m4a785-m project, and the IDs are still reporting amd tilapia. So I updated them. I think only a few utilities ever report this information. Thanks, Scott ]Regards, ]Patrick ] ]-- From scott at notabs.org Wed Sep 15 05:42:08 2010 From: scott at notabs.org (Scott Duplichan) Date: Tue, 14 Sep 2010 22:42:08 -0500 Subject: [coreboot] [PATCH] make I/O APIC IDs and processor APIC IDs unique (asus/m4a785-m) Message-ID: <84EE4926AB0F408B9D609983F6BFCEE4@m3a78> For the AMD SB700 projects, the SB ioapic id is being assigned the same value as one of the processor core local apic ids. Apparently this is not such a serious problem as I had once thought. On the other hand, AMD recommends using a unique value for each apic id. Assigning a unique id to the SB ioapic is not as simple as choosing the next biggest available value, because the ioapic is traditionally a 4-bit value. Though the south bridge has an option for an 8-bit ioapic id, using such a value might confuse older operating systems. Choosing the next available id value for the ioapic works when the number of processor cores is small, and that is what the AMD BKDG recommends. If this would result in an ioapic id that exceeds 4 bits, the recommendation is to lift the processor local apic id numbering so that ioapics can be assigned values starting at zero. The patch below attempts to implement these recommendations. The case of lifting local apic ids has not been tested. In order to meet the 4-bit ioapic id limit without lifting the processor local apic id values, the patch reduces MAX_PHYSICAL_CPUS from 2 to 1, which is consistent with the currently supported boards and processors. The patch is for asus/m4a785-m, but can be adapted for other supported sb700 desktop projects. Tested by booting amd/m4a785-m/seabios to win7 on simnow. The initial and final ioapic id, as well as the value in the acpi apic table, are 8. Signed-off-by: Scott Duplichan Index: src/southbridge/amd/sb700/sb700_sm.c =================================================================== --- src/southbridge/amd/sb700/sb700_sm.c (revision 5814) +++ src/southbridge/amd/sb700/sb700_sm.c (working copy) @@ -57,12 +57,20 @@ printk(BIOS_INFO, "sm_init().\n"); ioapic_base = pci_read_config32(dev, 0x74) & (0xffffffe0); /* some like mem resource, but does not have enable bit */ - /* Don't rename APIC ID */ - /* TODO: We should call setup_ioapic() here. But kernel hangs if cpu is K8. - * We need to check out why and change back. */ + clear_ioapic(ioapic_base); + /* I/O APIC IDs are normally limited to 4-bits. Enforce this limit. */ + #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16) + /* Assign the ioapic ID the next available number after the processor core local APIC IDs */ + setup_ioapic(ioapic_base, CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS); + #elif (CONFIG_APIC_ID_OFFSET > 0) + /* Assign the ioapic ID the value 0. Processor APIC IDs follow. */ + setup_ioapic(ioapic_base, 0); + #else + #error "The processor APIC IDs must be lifted to make room for the I/O APIC ID" + #endif - /* 2.10 Interrupt Routing/Filtering */ + /* 2.10 Interrupt Routing/Filtering */ dword = pci_read_config8(dev, 0x62); dword |= 3; pci_write_config8(dev, 0x62, dword); Index: src/mainboard/asus/m4a785-m/Kconfig =================================================================== --- src/mainboard/asus/m4a785-m/Kconfig (revision 5814) +++ src/mainboard/asus/m4a785-m/Kconfig (working copy) @@ -49,7 +49,7 @@ config MAX_PHYSICAL_CPUS int - default 2 + default 1 config HW_MEM_HOLE_SIZE_AUTO_INC bool Index: src/mainboard/asus/m4a785-m/acpi_tables.c =================================================================== --- src/mainboard/asus/m4a785-m/acpi_tables.c (revision 5814) +++ src/mainboard/asus/m4a785-m/acpi_tables.c (working copy) @@ -70,7 +70,13 @@ current = acpi_create_madt_lapics(current); /* Write SB700 IOAPIC, only one */ - current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, 2, + #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16) + #define IO_APIC_ID (CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS) + #else + #define IO_APIC_ID 0 + #endif + current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, + IO_APIC_ID, IO_APIC_ADDR, 0); current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *) From peter at stuge.se Wed Sep 15 12:53:24 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Sep 2010 12:53:24 +0200 Subject: [coreboot] [PATCH] make I/O APIC IDs and processor APIC IDs unique (asus/m4a785-m) In-Reply-To: <84EE4926AB0F408B9D609983F6BFCEE4@m3a78> References: <84EE4926AB0F408B9D609983F6BFCEE4@m3a78> Message-ID: <20100915105324.28649.qmail@stuge.se> Scott Duplichan wrote: > Assigning a unique id to the SB ioapic is not as simple as choosing > the next biggest available value, because the ioapic is > traditionally a 4-bit value. Did you look at how the K8 support does this? I think this may already be handled there, maybe it's a useful reference. > +++ src/southbridge/amd/sb700/sb700_sm.c (working copy) > + #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16) .. > +++ src/mainboard/asus/m4a785-m/acpi_tables.c (working copy) > + #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16) > + #define IO_APIC_ID (CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS) > + #else > + #define IO_APIC_ID 0 > + #endif Is there a header file in north or southbridge that could be used to store the logic? //Peter From anders at jenbo.dk Wed Sep 15 13:51:37 2010 From: anders at jenbo.dk (Anders Jenbo) Date: Wed, 15 Sep 2010 13:51:37 +0200 Subject: [coreboot] Ali m1541 Message-ID: What is the Lilly hood of porting coreboot to a mb based on the Ali m1541 chipset? - Anders From libv at skynet.be Wed Sep 15 14:27:12 2010 From: libv at skynet.be (Luc Verhaegen) Date: Wed, 15 Sep 2010 14:27:12 +0200 Subject: [coreboot] Ali m1541 In-Reply-To: References: Message-ID: <20100915122712.GA2808@skynet.be> On Wed, Sep 15, 2010 at 01:51:37PM +0200, Anders Jenbo wrote: > What is the Lilly hood of porting coreboot to a mb based on the Ali m1541 chipset? > > - Anders How old is that board that you are talking about? My Asus P5A is 12years old, at least, and barely wants to boot still. Maybe ali chipsets are not worth ones time any more. Luc Verhaegen. From anders at jenbo.dk Wed Sep 15 17:29:33 2010 From: anders at jenbo.dk (=?utf-8?B?YW5kZXJzQGplbmJvLmRr?=) Date: Wed, 15 Sep 2010 17:29:33 +0200 Subject: [coreboot] =?utf-8?q?Ali_m1541?= Message-ID: Its slot1 old ;) Mvh Anders ----- Reply message ----- Fra: "Luc Verhaegen" Dato: ons., sep. 15, 2010 14:27 Emne: [coreboot] Ali m1541 Til: "Anders Jenbo" Cc: "coreboot at coreboot.org" On Wed, Sep 15, 2010 at 01:51:37PM +0200, Anders Jenbo wrote: > What is the Lilly hood of porting coreboot to a mb based on the Ali m1541 chipset? > > - Anders How old is that board that you are talking about? My Asus P5A is 12years old, at least, and barely wants to boot still. Maybe ali chipsets are not worth ones time any more. Luc Verhaegen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcj303 at gmail.com Wed Sep 15 19:36:25 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 15 Sep 2010 11:36:25 -0600 Subject: [coreboot] [PATCH] make I/O APIC IDs and processor APIC IDs unique (asus/m4a785-m) In-Reply-To: <20100915105324.28649.qmail@stuge.se> References: <84EE4926AB0F408B9D609983F6BFCEE4@m3a78> <20100915105324.28649.qmail@stuge.se> Message-ID: On Wed, Sep 15, 2010 at 4:53 AM, Peter Stuge wrote: > Scott Duplichan wrote: >> Assigning a unique id to the SB ioapic is not as simple as choosing >> the next biggest available value, because the ioapic is >> traditionally a 4-bit value. > > Did you look at how the K8 support does this? I think this may > already be handled there, maybe it's a useful reference. > K8 and Fa10 have the same option to lift the BSP APIC ID, The code looks stale and I don't think that it would be enough for FAM10. For K8 you only need to move one ID to make room for the SB (2*8). For FAM10, you need to lift more than just the BSP. > >> +++ src/southbridge/amd/sb700/sb700_sm.c ? ? ?(working copy) >> + ? #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16) > .. Have you tried setting CONFIG_APIC_ID_OFFSET? > >> +++ src/mainboard/asus/m4a785-m/acpi_tables.c (working copy) >> + ? #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16) >> + ? #define IO_APIC_ID (CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS) >> + ? #else >> + ? #define IO_APIC_ID 0 >> + ? #endif > > Is there a header file in north or southbridge that could be used to > store the logic? I agree, this doesn't belong in acpi code. IO_APIC_ID could be used in the sb700_sm.c as well. Marc -- http://se-eng.com From scott at notabs.org Wed Sep 15 20:00:47 2010 From: scott at notabs.org (Scott Duplichan) Date: Wed, 15 Sep 2010 13:00:47 -0500 Subject: [coreboot] [PATCH] make I/O APIC IDs and processor APIC IDs unique (asus/m4a785-m) In-Reply-To: References: <84EE4926AB0F408B9D609983F6BFCEE4@m3a78><20100915105324.28649.qmail@stuge.se> Message-ID: <03CAB578FC734AA8B8E6FDB7F9E5873E@m3a78> ]-----Original Message----- ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Marc Jones ]Sent: Wednesday, September 15, 2010 12:36 PM ]To: coreboot at coreboot.org ]Subject: Re: [coreboot] [PATCH] make I/O APIC IDs and processor APIC IDs unique (asus/m4a785-m) ] ]On Wed, Sep 15, 2010 at 4:53 AM, Peter Stuge wrote: ]> Scott Duplichan wrote: ]>> Assigning a unique id to the SB ioapic is not as simple as choosing ]>> the next biggest available value, because the ioapic is ]>> traditionally a 4-bit value. ]> ]> Did you look at how the K8 support does this? I think this may ]> already be handled there, maybe it's a useful reference. ]> ] ]K8 and Fa10 have the same option to lift the BSP APIC ID, The code ]looks stale and I don't think that it would be enough for FAM10. For ]K8 you only need to move one ID to make room for the SB (2*8). For ]FAM10, you need to lift more than just the BSP. ] ] ]> ]>> +++ src/southbridge/amd/sb700/sb700_sm.c ? ? ?(working copy) ]>> + ? #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16) ]> .. ] ]Have you tried setting CONFIG_APIC_ID_OFFSET? I didn't even test this method because AMD recommends starting the processor local apic ids at zero if possible. That is for better compatibility with some older operating systems I believe. I think none of the coreboot AMD projects currently support >= 16 cores, so processor apic IDs can start at zero for the time being. But even if this lifting method resolves the ID conflict, it does not solve the problem of passing the io apic id to the os through acpi. Currently the acpi tables use a hard-coded value of 2 for the io apic id. So there are two problems: ID conflict, and ACPI reporting. ]> ]>> +++ src/mainboard/asus/m4a785-m/acpi_tables.c (working copy) ]>> + ? #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16) ]>> + ? #define IO_APIC_ID (CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS) ]>> + ? #else ]>> + ? #define IO_APIC_ID 0 ]>> + ? #endif ]> ]> Is there a header file in north or southbridge that could be used to ]> store the logic? ] ]I agree, this doesn't belong in acpi code. IO_APIC_ID could be used ]in the sb700_sm.c as well. It seems like a generic sysconf structure is needed. sb700_sm.c could use such a structure to pass the io apic id base to acpi_tables.c. ]Marc ] ]-- ]http://se-eng.com From marcj303 at gmail.com Wed Sep 15 18:27:22 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 15 Sep 2010 10:27:22 -0600 Subject: [coreboot] [help] A K8/RS780/SB710 board MCE error In-Reply-To: References: Message-ID: Hi Liu, On Mon, Sep 13, 2010 at 8:49 PM, Liu Tao wrote: > Hello everyone, > > I'm porting coreboot v4 to a k8-rs780-sb710 based mainboard, ?and use > amd/mahogany > and amd/tilapia_fam10 codes as the reference. Now coreboot boots the > board and filo loads linux,but the board crashes at a MCE error during > booting process. I'm not very know the detail about the MCE, so any > suggestions will be appreciated, thanks very much. > > The mainboard architecture: > CPU: socket F Opteron 2210 EE get_cpu_rev EAX=0x40f13 (1 cpu, dual core) > DIMM: DDR2 333M (x1 / x2) > HT Link0: off > HT Link1: RS780->SB710 > HT Link2: off > VGA off > GFX off > PCIE off > > coreboot code ?revision: modified on r5692 > > The MCE/panic message: > > HARDWARE ERROR > CPU 0: Machine Check Exception: ? ? ? ? ? ? ? ?4 Bank 0: f658a00000000833 > TSC 572507f34 ADDR 6000 > This is not a software problem! > Run through mcelog --ascii to decode and contact your hardware vendor > Kernel panic - not syncing: Machine check > ------------[ cut here ]------------ > WARNING: at kernel/smp.c:331 smp_call_function_mask+0x32/0x1ec() > Modules linked in: > Supported: Yes > Pid: 1, comm: swapper Tainted: G ? M ? ? ?2.6.27.19-5-default #1 > > Call Trace: > ?[] show_trace_log_lvl+0x41/0x58 > ?[] dump_stack+0x69/0x6f > ?[] warn_on_slowpath+0x51/0x77 > ?[] smp_call_function_mask+0x32/0x1ec > ?[] smp_call_function+0x29/0x2e > ?[] native_smp_send_stop+0x1a/0x26 > ?[] panic+0xbc/0x169 > ?[] mce_log+0x0/0x7e > ?[] do_machine_check+0x31e/0x3cd > ?[] machine_check+0x7f/0x90 > ?[] setup_trampoline+0x20/0x30 > ?[] native_cpu_up+0x31e/0xc64 > ?[] _cpu_up+0x9a/0x11c > ?[] cpu_up+0x5b/0x6f > ?[] kernel_init+0xe1/0x1eb > ?[] child_rip+0xa/0x11 > > ---[ end trace 4eaa2a86a8e2da22 ]--- > > mcelog --k8 --ascii > > HARDWARE ERROR > CPU 0: Machine Check Exception: ? ? ? ? ? ? ? ?4 Bank 0: f658a00000000833 > TSC 572507f34 ADDR 6000 > This is not a software problem! > Run through mcelog --ascii to decode and contact your hardware vendor > HARDWARE ERROR > CPU 0 0 data cache TSC 572507f34 > ?Data cache ECC error (syndrome b1) > ? ? ? bit45 = uncorrected ecc error > ? ? ? bit57 = processor context corrupt > ? ? ? bit61 = error uncorrected > ? ? ? bit62 = error overflow (multiple errors) > ?bus error 'local node origin, request didn't time out > ? ? ?data read mem transaction > ? ? ?memory access, level generic' > STATUS f658a00000000833 MCGSTATUS 4 > This is not a software problem! > Run through mcelog --ascii to decode and contact your hardware vendor > > Attached is the detailed boot message. I haven't worked with K8 is a while, but it seems like this could be a real CPU problem. Do you have another CPU to test with? The other possibility is that there is a missing errata or workaround for your CPU. You could review the AMD K8 revision guide for cache and MCA/MCE issues. Please let us know what you find. Marc -- http://se-eng.com From marcj303 at gmail.com Wed Sep 15 20:32:21 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 15 Sep 2010 12:32:21 -0600 Subject: [coreboot] AMD cache setup is broken In-Reply-To: <0EF599E03B5F42D581CE5F4D71FAC485@m3a78> References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <87occ7s0gf.fsf@taniquetil.gledits.ch> <8762yarpqb.fsf@taniquetil.gledits.ch> <0EF599E03B5F42D581CE5F4D71FAC485@m3a78> Message-ID: On Mon, Sep 13, 2010 at 9:15 PM, Scott Duplichan wrote: > ]-----Original Message----- > ]From: coreboot-bounces+scott=notabs.org at coreboot.org [mailto:coreboot-]bounces+scott=notabs.org at coreboot.org] On Behalf Of Arne > Georg Gleditsch > ]Sent: Monday, September 13, 2010 03:51 AM > ]To: Scott Duplichan > ]Cc: 'Marc Jones'; coreboot at coreboot.org > ]Subject: Re: [coreboot] AMD cache setup is broken > ] > ]"Scott Duplichan" writes: > ]> I think it would be best to clear bit 35 of msr c001_102a in the AP > ]> cores as well as the BSP core. Otherwise, the OS might see AP cores > ]> having slightly lower performance than the BSP core. This bit affects > ]> family 10h revC and newer (45 nm). > ] > ]Ok, so here's a patch adding this. ?Clearing bit 35 is done > ]unconditionally for all fam10 cpus, is that ok? ?Setting is done based > ]on processor type in defaults.h, as before. > > Thanks. This looks correct to me. I used simnow/tilapia to confirm bit > 35 gets cleared in all cores. I found bit 35 never actually gets set. > I submitted a patch to correct that. Once that patch is applied, I can > see bit 35 gets set in all cores, then gets cleared in all cores. > > Thanks, > Scott Hi Scott, Can you Acked-by: if this is working for you. Marc -- http://se-eng.com From marcj303 at gmail.com Wed Sep 15 20:42:35 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 15 Sep 2010 12:42:35 -0600 Subject: [coreboot] Fwd: [patch] tint payload update Message-ID: ping ---------- Forwarded message ---------- From: Marc Jones Date: Mon, Aug 23, 2010 at 6:37 PM Subject: Re: [coreboot] Trouble compiling tint payload To: Andrew Guertin Cc: coreboot at coreboot.org On Mon, Aug 23, 2010 at 12:08 PM, Marc Jones wrote: > On Mon, Aug 23, 2010 at 8:33 AM, Andrew Guertin wrote: >> I figured out the problem right after sending this: when I set $CC, it >> overwrites the makefile variable that tells it to use lpgcc, so lpgcc isn't >> getting used. >> >> I changed all occurrences of "CC" in the tint makefile to "MYCC", and it >> compiled correctly. >> >> Is there a less hackish way I should solve it, and then submit a patch? Or >> does someone who knows what they're doing better want to take care of it? > > Hi Andrew, > > I have some patches for tint to add xcompile and some other build > changes to match what has gone into libpayload. I'll try to post them > later today. This patch is based on Uwe's, but patching a patch seems odd to me, so here is a new patch that builds on the previous one. Start with a clean tint0.03b and put it in the coreboot payloads directory. You no longer need to build libpayload. The make handles it for you. Add default libpayload build, xcompile, and lpgcc setup to tint. Signed-off-by: Marc Jones Let me know how it goes. Marc -- http://se-eng.com -- http://se-eng.com -------------- next part -------------- A non-text attachment was scrubbed... Name: tint_libpayload.patch Type: application/octet-stream Size: 10700 bytes Desc: not available URL: From scott at notabs.org Wed Sep 15 20:51:38 2010 From: scott at notabs.org (Scott Duplichan) Date: Wed, 15 Sep 2010 13:51:38 -0500 Subject: [coreboot] AMD cache setup is broken In-Reply-To: References: <4C812B6D020000FE0000D531@mail.lkfd.net><87aanv1eax.fsf@taniquetil.gledits.ch><4C84BD83.2030502@coresystems.de><8762yj170a.fsf@taniquetil.gledits.ch><673D2439DC3046D0903811C4830EA052@m3a78><2AB823A1470D4921A664FB35592308CE@m3a78><87wrqvs5ua.fsf@taniquetil.gledits.ch><87sk1js2d8.fsf@taniquetil.gledits.ch><87occ7s0gf.fsf@taniquetil.gledits.ch><8762yarpqb.fsf@taniquetil.gledits.ch><0EF599E03B5F42D581CE5F4D71FAC485@m3a78> Message-ID: -----Original Message----- ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Marc Jones ]Sent: Wednesday, September 15, 2010 01:32 PM ]To: Scott Duplichan ]Cc: Arne Georg Gleditsch; coreboot at coreboot.org ]Subject: Re: [coreboot] AMD cache setup is broken ] ]On Mon, Sep 13, 2010 at 9:15 PM, Scott Duplichan wrote: ]> ]-----Original Message----- ]> ]From: coreboot-bounces+scott=notabs.org at coreboot.org [mailto:coreboot-]]bounces+scott=notabs.org at coreboot.org] On Behalf Of Arne ]> Georg Gleditsch ]> ]Sent: Monday, September 13, 2010 03:51 AM ]> ]To: Scott Duplichan ]> ]Cc: 'Marc Jones'; coreboot at coreboot.org ]> ]Subject: Re: [coreboot] AMD cache setup is broken ]> ] ]> ]"Scott Duplichan" writes: ]> ]> I think it would be best to clear bit 35 of msr c001_102a in the AP ]> ]> cores as well as the BSP core. Otherwise, the OS might see AP cores ]> ]> having slightly lower performance than the BSP core. This bit affects ]> ]> family 10h revC and newer (45 nm). ]> ] ]> ]Ok, so here's a patch adding this. ?Clearing bit 35 is done ]> ]unconditionally for all fam10 cpus, is that ok? ?Setting is done based ]> ]on processor type in defaults.h, as before. ]> ]> Thanks. This looks correct to me. I used simnow/tilapia to confirm bit ]> 35 gets cleared in all cores. I found bit 35 never actually gets set. ]> I submitted a patch to correct that. Once that patch is applied, I can ]> see bit 35 gets set in all cores, then gets cleared in all cores. ]> ]> Thanks, ]> Scott ] ]Hi Scott, ] ]Can you Acked-by: if this is working for you. Thanks Marc. Here you go.. Acked-by: Scott Duplichan ]Marc ]-- ]http://se-eng.com From peter at stuge.se Wed Sep 15 20:55:11 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Sep 2010 20:55:11 +0200 Subject: [coreboot] Fwd: [patch] tint payload update In-Reply-To: References: Message-ID: <20100915185511.6788.qmail@stuge.se> Marc Jones wrote: > ping .. > Add default libpayload build, xcompile, and lpgcc setup to tint. > > Signed-off-by: Marc Jones Maybe that halt should be made into a sleep followed by returning to e.g. SeaBIOS? All those #if 0 are not so pretty. Maybe some headers can be kept now with the libpayload changes in that area. And maybe the cpp:ed out code can be made #ifndef LIBPAYLOAD or so, to get the changes into upstream. I understand that you may not have touched any of this, Marc. As for the build things, can we not get around stuffing all of that into each payload? //Peter From mylesgw at gmail.com Wed Sep 15 20:53:04 2010 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 15 Sep 2010 12:53:04 -0600 Subject: [coreboot] Fwd: [patch] tint payload update In-Reply-To: References: Message-ID: Picky observation: there are a couple of extra #if 0 #endif pairs. Combining them would make the patch simpler. @@ -337,7 +339,9 @@ static void getname (char *name) name[NAMELEN - 1] = '\0'; } } +#endif +#if 0 static void err1 () { fprintf (stderr,"Error creating %s\n",scorefile); I haven't tested it, but it looks fine. Acked-by: Myles Watson Thanks, Myles From mrtadis at gmail.com Wed Sep 15 21:24:00 2010 From: mrtadis at gmail.com (Tadas S) Date: Wed, 15 Sep 2010 22:24:00 +0300 Subject: [coreboot] Unsupported software interrupt #0x42 Message-ID: Hello, > 02.238: Calling Option ROM... > 03.227: Unsupported software interrupt #0x42 eax 0x7 > 03.232: int42 call returned error. > 04.804: ... Option ROM returned. > It's coreboot serial output with timestamps. Since I don't know much here, I would like to ask if int0x42 is the same as int0x10 and if we could assume the same handler for both of them to avoid such error? Thanks, Tadas S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcj303 at gmail.com Wed Sep 15 21:59:57 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 15 Sep 2010 13:59:57 -0600 Subject: [coreboot] Fwd: [patch] tint payload update In-Reply-To: <20100915185511.6788.qmail@stuge.se> References: <20100915185511.6788.qmail@stuge.se> Message-ID: On Wed, Sep 15, 2010 at 12:55 PM, Peter Stuge wrote: > As for the build things, can we not get around stuffing all of that > into each payload? What do you mean? It seems to me that we want each payload responsible for building its own version of libpayload. Marc -- http://se-eng.com From marcj303 at gmail.com Wed Sep 15 22:10:50 2010 From: marcj303 at gmail.com (Marc Jones) Date: Wed, 15 Sep 2010 14:10:50 -0600 Subject: [coreboot] [patch] AMD Fam10 CPUID strings Message-ID: Add more Fam10 CPUID strings from the AMD revision guide. Includes newer Phenom II. Signed-off-by: Marc Jones -- http://se-eng.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fam10names.patch Type: application/octet-stream Size: 3873 bytes Desc: not available URL: From joe at settoplinux.org Wed Sep 15 21:52:15 2010 From: joe at settoplinux.org (Joseph Smith) Date: Wed, 15 Sep 2010 15:52:15 -0400 Subject: [coreboot] Unsupported software interrupt #0x42 In-Reply-To: References: Message-ID: <4C9123EF.8020204@settoplinux.org> On 09/15/2010 03:24 PM, Tadas S wrote: > Hello, > > 02.238: Calling Option ROM... > 03.227: Unsupported software interrupt #0x42 eax 0x7 > 03.232: int42 call returned error. > 04.804: ... Option ROM returned. > > > It's coreboot serial output with timestamps. Since I don't know much > here, I would like to ask if int0x42 is the same as int0x10 and if we > could assume the same handler for both of them to avoid such error? > > > Thanks, > Tadas S. > Yes int42 is the alternate of int10 -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From peter at stuge.se Wed Sep 15 23:09:16 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Sep 2010 23:09:16 +0200 Subject: [coreboot] Fwd: [patch] tint payload update In-Reply-To: References: <20100915185511.6788.qmail@stuge.se> Message-ID: <20100915210916.25244.qmail@stuge.se> Marc Jones wrote: > > As for the build things, can we not get around stuffing all of that > > into each payload? > > What do you mean? It seems to me that we want each payload > responsible for building its own version of libpayload. I hadn't thought of that! Do we? Interesting. In a way it makes sense because different payloads need different parts of libpayload. But thinking of it as a replacement for glibc or at least crt0 then it isn't so nice to have more than one. This is how I've always thought of it until now. But ok, say we want local libpayload per payload, then I think we should still try to simplify things. Maybe provide a payload.inc Makefile stub in libpayload which the payload Makefile simply includes after setting a variable name or two? That's a different patch(set) though. :) Acked-by: Peter Stuge //Peter From paulepanter at users.sourceforge.net Wed Sep 15 23:46:58 2010 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Wed, 15 Sep 2010 23:46:58 +0200 Subject: [coreboot] [patch] AMD Fam10 CPUID strings In-Reply-To: References: Message-ID: <1284587218.21869.41.camel@mattotaupa> Dear Marc, Am Mittwoch, den 15.09.2010, 14:10 -0600 schrieb Marc Jones: > Add more Fam10 CPUID strings from the AMD revision guide. Includes > newer Phenom II. > > Signed-off-by: Marc Jones I glanced over it and just found a missing space. I do not own the hardware. Is there another check I can do? If not and with the space fixed when committing this is Acked-by: Paul Menzel > Index: coreboot/src/cpu/amd/model_10xxx/processor_name.c > =================================================================== > --- coreboot.orig/src/cpu/amd/model_10xxx/processor_name.c 2010-09-15 13:38:47.000000000 -0600 > +++ coreboot/src/cpu/amd/model_10xxx/processor_name.c 2010-09-15 13:56:53.000000000 -0600 > @@ -3,6 +3,7 @@ > * > * Copyright (C) 2007 Advanced Micro Devices, Inc. > * Copyright (C) 2008 Peter Stuge > + * Copyright (C) 2010 Marc Jones > * > * 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 [?] > @@ -93,28 +113,43 @@ > {0x00, 0x00, 0x07, "70"}, > {0x00, 0x00, 0x08, "80"}, > {0x00, 0x00, 0x09, "90"}, > + {0x00, 0x00, 0x09, " Processor"}, > + {0x00, 0x00, 0x09, "u Processor"}, > {0x00, 0x01, 0x00, "00 Dual-Core Processor"}, > {0x00, 0x01, 0x01, "00e Dual-Core Processor"}, > {0x00, 0x01, 0x02, "00B Dual-Core Processor"}, > {0x00, 0x01, 0x03, "50 Dual-Core Processor"}, > {0x00, 0x01, 0x04, "50e Dual-Core Processor"}, > {0x00, 0x01, 0x05, "50B Dual-Core Processor"}, > + {0x00, 0x01, 0x06, " Processor"}, > + {0x00, 0x01, 0x07, "e Processor"}, > + {0x00, 0x01, 0x09, "0 Processor"}, > + {0x00, 0x01, 0x0A,"0e Processor"}, ^ > + {0x00, 0x01, 0x0B, "u Processor"}, [?] Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From hjf at hjf.com.ar Thu Sep 16 04:11:08 2010 From: hjf at hjf.com.ar (Hernan Freschi) Date: Wed, 15 Sep 2010 23:11:08 -0300 Subject: [coreboot] Porting coreboot to Unknown Sis620/5595 Motherboard In-Reply-To: References: Message-ID: Hello, I'd like to port coreboot to a motherboard I have. I dont have either brand or model (it's a generic OEM board). I'm not sure what info is needed so I have uploaded: lspci -xxxvvvnnn ? ? http://pastebin.org/876731 superiotool -deV ? http://pastebin.org/876714 I'd like to know if it's possible and what are the steps to get started. Thanks, Hernan From kevin at koconnor.net Thu Sep 16 05:21:49 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 15 Sep 2010 23:21:49 -0400 Subject: [coreboot] SeaBIOS self relocation code Message-ID: <20100916032149.GA14813@morn.localdomain> Hi, I completed some code that enables SeaBIOS to relocate itself to high memory. The technique may be of interest to coreboot. The full patch series that enables SeaBIOS relocation can be seen at: http://www.seabios.org/pipermail/seabios/2010-September/000919.html Most of the patch series does cleanups and seabios specific work. The run-time code, which may be of interest to coreboot, is at: http://www.seabios.org/pipermail/seabios/2010-September/000922.html The general idea is to have the build store linker "relocation" information (see _reloc_* symbols) into the final executable, and then have the run-time code use this information so that it can self-modify all code that depends on code position. The SeaBIOS code only relocates part of itself, so the runtime relocation code is slightly more complex. A code blob that was fully relocated would be a little simpler (it would need only one call to updateRelocs). -Kevin From liutao1980 at gmail.com Thu Sep 16 08:53:06 2010 From: liutao1980 at gmail.com (Liu Tao) Date: Thu, 16 Sep 2010 14:53:06 +0800 Subject: [coreboot] [help] A K8/RS780/SB710 board MCE error In-Reply-To: References: Message-ID: On 9/16/10, Marc Jones wrote: > I haven't worked with K8 is a while, but it seems like this could be a > real CPU problem. Do you have another CPU to test with? The other > possibility is that there is a missing errata or workaround for your > CPU. You could review the AMD K8 revision guide for cache and MCA/MCE > issues. Please let us know what you find. Hi Marc, I just update coreboot from r5692 to r5814 and the problem resolved, before update the code I have met three types of MCE error: Data cache ECC error L2 cache ECC error Northbridge chipkill ECC error I have not take a detailed look at the code differences yet, but I think maybe it's related to the recent discussion of amd cache broken? -- Regards, Liu Tao From developer at nomadicus.net Thu Sep 16 05:44:07 2010 From: developer at nomadicus.net (NOMADICUS) Date: Wed, 15 Sep 2010 23:44:07 -0400 Subject: [coreboot] Toshiba Satellite U205-S5002 Message-ID: Hello Corebooters, I was on the #coreboot last night grilling people about what they know of coreboot. I was advised to create some logs for my laptop. It is a Toshiba Satellite u205-S5002. I followed the instructions on http://www.coreboot.org/Laptop#HOWTO_to_find_a_way and I wrote a script to automate the process. The script is mostly working, at least the critical parts of making the scripts. Downloading and installing all the necessary tools, well some of the dependencies are not all sorted out yet. So I suspect that these logs will provide useful information and that someone can give me a clue as to what I should do next. I had a great time learning and I am patient to learn more. The name of the script is 'coreboot.check'. -------------- next part -------------- A non-text attachment was scrubbed... Name: Toshiba_Satellite_U205-S5002_logs.tar Type: application/x-tar Size: 1556480 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: coreboot.check Type: application/octet-stream Size: 12674 bytes Desc: not available URL: From hjf at hjf.com.ar Wed Sep 15 23:30:29 2010 From: hjf at hjf.com.ar (Hernan Freschi) Date: Wed, 15 Sep 2010 18:30:29 -0300 Subject: [coreboot] Porting coreboot to Unknown Sis620/5595 Motherboard Message-ID: Hello, I'd like to port coreboot to a motherboard I have. I dont have either brand or model (it's a generic OEM board). I'm not sure what info is needed so I have uploaded: lspci -xxxvvvnnn http://pastebin.org/876731 superiotool -deV http://pastebin.org/876714 I'd like to know if it's possible and what are the steps to get started. Thanks, Hernan From libv at skynet.be Thu Sep 16 11:47:54 2010 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 16 Sep 2010 11:47:54 +0200 Subject: [coreboot] Ali m1541 In-Reply-To: <1284566934.2025.3.camel@anders-desktop> References: <20100915122712.GA2808@skynet.be> <1284566934.2025.3.camel@anders-desktop> Message-ID: <20100916094754.GA16423@skynet.be> On Wed, Sep 15, 2010 at 06:08:54PM +0200, Anders Jenbo wrote: > Sorry i was mistaking, it is Socket 7 old :p > Well, the good side of the ali is that the docs are available. But if it is the p5a, the asus specific superio will trump whatever effort that could happen. But, why bother? Find a chipset and superio that are supported, buy some board that hasn't been implemented yet from like ebay. There is tons of options there. This will get you much more recent hardware, which, when working well, gives you a freer system, that you can use yourself afterwards. Makes things more useful for the world, and give yourself more satisfaction. So forget the ali chipsets. Luc Verhaegen. From juhe at iki.fi Thu Sep 16 20:42:04 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Thu, 16 Sep 2010 21:42:04 +0300 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> <87vd69wi5m.fsf@taniquetil.gledits.ch> Message-ID: <1284662524.3702.34.camel@bart> On Mon, 2010-09-13 at 14:31 -0600, Myles Watson wrote: > On Mon, Sep 13, 2010 at 1:35 PM, Arne Georg Gleditsch > wrote: > > Myles Watson writes: > >> So even though there are PCI resources located at 0xc0000000, RAM gets > >> used for UMA at 0xd0000000 and tables get placed at 0xcfff0000. > > > > PCI resources at 0xd0000000? Doesn't this conflict with the setting of > > NV_BottomIO in src/northbridge/amd/amdmct/wrappers/mcti_d.c? > > That could be. I'm totally ignorant of the fam10 code oustside of > northbridge/amd/amdfam10. > > Looking at the boot log, it doesn't seem unreasonable to have PCI > resources from starting at 0xc0000000. > > It seems like we have a couple of options: > 1. Reclaim the area used for MMCONF on this board > 2. Move NV_BottomIO > > Probably 2 is the best. It's too bad to have that hard coded. Hello, How to proceed with finding the proper memory setup? I tried reading through amdfam10 code and RS780 southbridge code, but they are quite incomprehensible without a hardware programming manual. Is such a detailed documentation freely available somewhere, or is it under NDA only? It appears that the northbridge is quite clever in mapping memory, since Linux booted with Asus BIOS reports in /proc/iomem that there is usable RAM up to 0x19fffffff, i.e. addresses up to 6.5 GB, even though there is only 6 GB RAM installed. The "extra" addresses apparently come from the fact that there is no real RAM mapped to some addresses below 4G, and these addresses are used for PCI memory-mapped IO. Here are some parts of /proc/iomem: 00100000-cff8ffff : System RAM d0000000-dfffffff : PCI Bus 0000:01 d0000000-dfffffff : 0000:01:05.0 e0000000-efffffff : PCI MMCONFIG 0 [00-ff] e0000000-efffffff : pnp 00:0d fdf00000-fdffffff : PCI Bus 0000:02 fe900000-feafffff : PCI Bus 0000:01 feb00000-febfffff : PCI Bus 0000:02 100000000-19fffffff : System RAM My interpretation of this is roughly the following: 00000000-cfffffff is 3.25 GB RAM. d0000000-dfffffff is not RAM, but is 256M memory-mapped IO addresses to VGA e0000000-efffffff is 256M RAM, but not usable to OS, because it is the UMA f0000000-ffffffff is not RAM, but IO addresses for more PCI, APICs, and other devices 100000000-19fffffff is 2.5 GB RAM Does this look correct? If yes, then the northbridge is creating holes into RAM, in order to have PCI memory-mapped IO in 32-bit addresses. Now, if I wish to have Coreboot to cope with large memory and holes, what manuals do I need to understand and modify the codes managing this? Best regards, Juhana Helovuo From mylesgw at gmail.com Thu Sep 16 20:56:01 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 16 Sep 2010 12:56:01 -0600 Subject: [coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions In-Reply-To: <1284662524.3702.34.camel@bart> References: <65941F6CF9CF4CABBCD37A0B62E0EFDB@m3a78> <0C8ADA2D40CE4AF79530D7DFB5FD2C15@m3a78> <4C7F4FB7.8070107@iki.fi> <1284048775.538.23.camel@bart> <403EEDC42E8A4B019CE3F2F1EDE84867@chimp> <4C89D1E2.9060707@iki.fi> <1284202127.538.41.camel@bart> <1284237376.538.69.camel@bart> <1284241635.538.75.camel@bart> <1284394115.3630.24.camel@bart> <87vd69wi5m.fsf@taniquetil.gledits.ch> <1284662524.3702.34.camel@bart> Message-ID: On Thu, Sep 16, 2010 at 12:42 PM, Juhana Helovuo wrote: > On Mon, 2010-09-13 at 14:31 -0600, Myles Watson wrote: >> On Mon, Sep 13, 2010 at 1:35 PM, Arne Georg Gleditsch >> wrote: >> > Myles Watson writes: >> >> So even though there are PCI resources located at 0xc0000000, RAM gets >> >> used for UMA at 0xd0000000 and tables get placed at 0xcfff0000. >> > >> > PCI resources at 0xd0000000? ?Doesn't this conflict with the setting of >> > NV_BottomIO in src/northbridge/amd/amdmct/wrappers/mcti_d.c? >> >> That could be. ?I'm totally ignorant of the fam10 code oustside of >> northbridge/amd/amdfam10. >> >> Looking at the boot log, it doesn't seem unreasonable to have PCI >> resources from starting at 0xc0000000. >> >> It seems like we have a couple of options: >> 1. Reclaim the area used for MMCONF on this board >> 2. Move NV_BottomIO >> >> Probably 2 is the best. ?It's too bad to have that hard coded. > > Hello, > > How to proceed with finding the proper memory setup? I tried reading > through amdfam10 code and RS780 southbridge code, but they are quite > incomprehensible without a hardware programming manual. Is such a > detailed documentation freely available somewhere, or is it under NDA > only? > > It appears that the northbridge is quite clever in mapping memory, since > Linux booted with Asus BIOS reports in /proc/iomem that there is usable > RAM up to 0x19fffffff, i.e. addresses up to 6.5 GB, even though there is > only 6 GB RAM installed. > > The "extra" addresses apparently come from the fact that there is no > real RAM mapped to some addresses below 4G, and these addresses are used > for PCI memory-mapped IO. > > Here are some parts of /proc/iomem: > > 00100000-cff8ffff : System RAM > d0000000-dfffffff : PCI Bus 0000:01 > ?d0000000-dfffffff : 0000:01:05.0 > e0000000-efffffff : PCI MMCONFIG 0 [00-ff] > ?e0000000-efffffff : pnp 00:0d > fdf00000-fdffffff : PCI Bus 0000:02 > fe900000-feafffff : PCI Bus 0000:01 > feb00000-febfffff : PCI Bus 0000:02 > 100000000-19fffffff : System RAM > > My interpretation of this is roughly the following: > > ?00000000-cfffffff is 3.25 GB RAM. > ?d0000000-dfffffff is not RAM, but is 256M memory-mapped IO addresses to VGA This is UMA. UMA is RAM that's been reserved for the display (Unified Memory Architecture) > ?e0000000-efffffff is 256M RAM, but not usable to OS, because it is the UMA This is MMCONFIG, not UMA. It allows the OS to use memory mapped accesses for PCI configuration accesses. > ?f0000000-ffffffff is not RAM, but IO addresses for more PCI, APICs, and other devices memory mapped IO. > 100000000-19fffffff is 2.5 GB RAM > Does this look correct? If yes, then the northbridge is creating holes > into RAM, in order to have PCI memory-mapped IO in 32-bit addresses. That's right. > Now, if I wish to have Coreboot to cope with large memory and holes, > what manuals do I need to understand and modify the codes managing this? BKDG (BIOS and Kernel Developers' Guide) Here's the link for fam10h. The other ones are there too. http://support.amd.com/us/Processor_TechDocs/31116.pdf Thanks, Myles From frederic.stemmelin at alcatel-lucent.com Thu Sep 16 22:18:32 2010 From: frederic.stemmelin at alcatel-lucent.com (STEMMELIN, FREDERIC (FREDERIC)** CTR **) Date: Thu, 16 Sep 2010 22:18:32 +0200 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing Message-ID: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Hello, this was my first try to build a coreboot bios ever, for my tyan s2895 mobo. I get managed to build and burn the bios into a RD1 512KB bios savior chip. The computer is booting, and then crashing on Ubuntu logo (10.04 64bits version), so far so nice. Here is what i have done: My rom build computer is installed with Ubuntu 10.04 64bits version, with build-essential and some other packages (flex bison git-core g++ gdb libncurses5-dev doxygen iasl build-essential lzma-dev liblzma-dev) I downloaded latest available verszion of payload seabios, with command "git clone git://git.linuxtogo.org/home/kevin/seabios.git seabios". Then i have adapted the config.h file as follow: #define CONFIG_COREBOOT 1 #define CONFIG_DEBUG_SERIAL 1 #define CONFIG_VGAHOOKS 1 The make command has build the file => out/bios.bin.elf 1048716 bytes Now i downloaded latest coreboot files, with a "svn co svn://coreboot.org/coreboot/trunk coreboot" But, on first "make", i run into troubles: build/coreboot_ram.o: In function `__wrap___umoddi3': (.text+0x1223f): undefined reference to `__umoddi3' build/coreboot_ram.o: In function `__wrap___moddi3': (.text+0x1224a): undefined reference to `__moddi3' build/coreboot_ram.o: In function `__wrap___udivdi3': (.text+0x12255): undefined reference to `__udivdi3' build/coreboot_ram.o: In function `__wrap___divdi3': (.text+0x12260): undefined reference to `__divdi3' collect2: ld returned 1 exit status make: *** [build/coreboot_ram] Erreur 1 Then i find out (in some mailing list archive) that there is a integrated compiling toolchain in the coreboot files, under "coreboot/util/crossgcc". The command "./buildgcc" was succesfull even if it tooks some time, enought to drink a coffee. On second "make" try, same compile errors. After some researches i find out that i need to do a "rm -rf build" and a new "make menuconfig", but it didnt solved my problem, same compilation errors :( I finnaly found out that i need to also delete the .xcompile file. So after the "rm -rf build", "rm .config", "rm .xcompile" and finally a "make menuconfig", the "make" was working (i am not a programmer), yes. I burned the coreboot.rom into the RD1 chip, and restared the computer. I then saw briefly a message about pressing F12 for some configuration. After some other quick messages, which i coulnd read, i saw Ubuntu starting and then crashing on the graphical logo. This is not really a problem so far, as i was able to switch back to the original bios to get computer up and running. Now i have a 3 questions for you: Is the coreboot.rom 32bits only and is there any advantage to build a 64bits version of the coreboot bios, as i intend to run a 64bits OS ? I build the seabios with Ubuntu gcc 64bits version, it is compatible, can i mix it, with the coreboot.rom build with i386-elf coreboot toolchain ? The build seabios (bios.bin.elf) is about 1MB in size, how it is possible to put it into a smaller 512KB chip inside coreboot.rom ? I didnt put VGA bios so far into the coreboot.rom. In my opinion, it would be a good idea to mention, somewhere in the build howto, that there is a integrated toolchain in coreboot, and may be also mention not to forget to delete the .xcompile file after the toolchain was built. What are your advice for the next steps ? Put VGA bios into coreboot.rom, change Ubuntu default start to non-graphical one ? I have attached the .config file for coreboot (btw i used lzma compression for payload). Thank you very much, i really appreciate your help. Fr?d?ric Stemmelin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Kconfig.txt URL: From svn at coreboot.org Thu Sep 16 23:04:54 2010 From: svn at coreboot.org (repository service) Date: Thu, 16 Sep 2010 23:04:54 +0200 Subject: [coreboot] [commit] r5815 - trunk/src/cpu/amd/model_10xxx Message-ID: Author: mjones Date: Thu Sep 16 23:04:54 2010 New Revision: 5815 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5815 Log: Add more Fam10 CPUID strings from the AMD revision guide. Includes newer Phenom II. Signed-off-by: Marc Jones Acked-by: Paul Menzel Modified: trunk/src/cpu/amd/model_10xxx/processor_name.c Modified: trunk/src/cpu/amd/model_10xxx/processor_name.c ============================================================================== --- trunk/src/cpu/amd/model_10xxx/processor_name.c Tue Sep 14 19:28:41 2010 (r5814) +++ trunk/src/cpu/amd/model_10xxx/processor_name.c Thu Sep 16 23:04:54 2010 (r5815) @@ -3,6 +3,7 @@ * * Copyright (C) 2007 Advanced Micro Devices, Inc. * Copyright (C) 2008 Peter Stuge + * Copyright (C) 2010 Marc Jones * * 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 @@ -73,12 +74,31 @@ static const struct str_s String1_socket_AM2[] = { {0x00, 0x00, 0x00, "AMD Athlon(tm) Processor LE-"}, {0x00, 0x00, 0x01, "AMD Sempron(tm) Processor LE-"}, + {0x00, 0x00, 0x02, "AMD Sempron(tm) 1"}, + {0x00, 0x00, 0x03, "AMD Athlon(tm) II 1"}, {0x00, 0x01, 0x00, "Dual-Core AMD Opteron(tm) Processor 13"}, {0x00, 0x01, 0x01, "AMD Athlon(tm)"}, + {0x00, 0x01, 0x03, "AMD Athlon(tm) II X2 2"}, + {0x00, 0x01, 0x04, "AMD Athlon(tm) II X2 B"}, + {0x00, 0x01, 0x05, "AMD Athlon(tm) II X2"}, + {0x00, 0x01, 0x07, "AMD Phenom(tm) II X2 5"}, + {0x00, 0x01, 0x0A, "AMD Phenom(tm) II X2"}, + {0x00, 0x01, 0x0B, "AMD Phenom(tm) II X2 B"}, {0x00, 0x02, 0x00, "AMD Phenom(tm)"}, + {0x00, 0x02, 0x03, "AMD Phenom(tm) II X3 B"}, + {0x00, 0x02, 0x04, "AMD Phenom(tm) II X3"}, + {0x00, 0x02, 0x07, "AMD Athlon(tm) II X3 4"}, + {0x00, 0x02, 0x08, "AMD Phenom(tm) II X3 7"}, + {0x00, 0x02, 0x0A, "AMD Athlon(tm) II X3"}, {0x00, 0x03, 0x00, "Quad-Core AMD Opteron(tm) Processor 13"}, {0x00, 0x03, 0x01, "AMD Phenom(tm) FX-"}, {0x00, 0x03, 0x02, "AMD Phenom(tm)"}, + {0x00, 0x03, 0x03, "AMD Phenom(tm) II X4 9"}, + {0x00, 0x03, 0x04, "AMD Phenom(tm) II X4 8"}, + {0x00, 0x03, 0x07, "AMD Phenom(tm) II X4 B"}, + {0x00, 0x03, 0x08, "AMD Phenom(tm) II X4"}, + {0x00, 0x03, 0x0A, "AMD Athlon(tm) II X4 6"}, + {0x00, 0x03, 0x0F, "AMD Athlon(tm) II X4"}, {0, 0, 0, NULL} }; @@ -93,28 +113,43 @@ {0x00, 0x00, 0x07, "70"}, {0x00, 0x00, 0x08, "80"}, {0x00, 0x00, 0x09, "90"}, + {0x00, 0x00, 0x09, " Processor"}, + {0x00, 0x00, 0x09, "u Processor"}, {0x00, 0x01, 0x00, "00 Dual-Core Processor"}, {0x00, 0x01, 0x01, "00e Dual-Core Processor"}, {0x00, 0x01, 0x02, "00B Dual-Core Processor"}, {0x00, 0x01, 0x03, "50 Dual-Core Processor"}, {0x00, 0x01, 0x04, "50e Dual-Core Processor"}, {0x00, 0x01, 0x05, "50B Dual-Core Processor"}, + {0x00, 0x01, 0x06, " Processor"}, + {0x00, 0x01, 0x07, "e Processor"}, + {0x00, 0x01, 0x09, "0 Processor"}, + {0x00, 0x01, 0x0A, "0e Processor"}, + {0x00, 0x01, 0x0B, "u Processor"}, {0x00, 0x02, 0x00, "00 Triple-Core Processor"}, {0x00, 0x02, 0x01, "00e Triple-Core Processor"}, {0x00, 0x02, 0x02, "00B Triple-Core Processor"}, {0x00, 0x02, 0x03, "50 Triple-Core Processor"}, {0x00, 0x02, 0x04, "50e Triple-Core Processor"}, {0x00, 0x02, 0x05, "50B Triple-Core Processor"}, + {0x00, 0x02, 0x06, " Processor"}, + {0x00, 0x02, 0x07, "e Processor"}, + {0x00, 0x02, 0x09, "0e Processor"}, + {0x00, 0x02, 0x0A, "0 Processor"}, {0x00, 0x03, 0x00, "00 Quad-Core Processor"}, {0x00, 0x03, 0x01, "00e Quad-Core Processor"}, {0x00, 0x03, 0x02, "00B Quad-Core Processor"}, {0x00, 0x03, 0x03, "50 Quad-Core Processor"}, {0x00, 0x03, 0x04, "50e Quad-Core Processor"}, {0x00, 0x03, 0x05, "50B Quad-Core Processor"}, + {0x00, 0x03, 0x06, " Processor"}, + {0x00, 0x03, 0x07, "e Processor"}, + {0x00, 0x03, 0x09, "0e Processor"}, {0x00, 0x03, 0x0A, " SE"}, {0x00, 0x03, 0x0B, " HE"}, {0x00, 0x03, 0x0C, " EE"}, {0x00, 0x03, 0x0D, " Quad-Core Processor"}, + {0x00, 0x03, 0x0E, "0 Processor"}, {0x00, 0xFF, 0x0F, ""}, {0, 0, 0, NULL} }; From marcj303 at gmail.com Thu Sep 16 23:05:59 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 16 Sep 2010 15:05:59 -0600 Subject: [coreboot] [patch] AMD Fam10 CPUID strings In-Reply-To: <1284587218.21869.41.camel@mattotaupa> References: <1284587218.21869.41.camel@mattotaupa> Message-ID: On Wed, Sep 15, 2010 at 3:46 PM, Paul Menzel wrote: > Dear Marc, > > > Am Mittwoch, den 15.09.2010, 14:10 -0600 schrieb Marc Jones: >> Add more Fam10 CPUID strings from the AMD revision guide. Includes >> newer Phenom II. >> >> Signed-off-by: Marc Jones > > I glanced over it and just found a missing space. I do not own the > hardware. Is there another check I can do? > > If not and with the space fixed when committing this is > > Acked-by: Paul Menzel > >> Index: coreboot/src/cpu/amd/model_10xxx/processor_name.c >> =================================================================== >> --- coreboot.orig/src/cpu/amd/model_10xxx/processor_name.c ? ? ?2010-09-15 13:38:47.000000000 -0600 >> +++ coreboot/src/cpu/amd/model_10xxx/processor_name.c ? 2010-09-15 13:56:53.000000000 -0600 >> @@ -3,6 +3,7 @@ >> ? * >> ? * Copyright (C) 2007 Advanced Micro Devices, Inc. >> ? * Copyright (C) 2008 Peter Stuge >> + * Copyright (C) 2010 Marc Jones >> ? * >> ? * 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 > > [?] > >> @@ -93,28 +113,43 @@ >> ? ? ? ? {0x00, 0x00, 0x07, "70"}, >> ? ? ? ? {0x00, 0x00, 0x08, "80"}, >> ? ? ? ? {0x00, 0x00, 0x09, "90"}, >> + ? ? ? {0x00, 0x00, 0x09, " Processor"}, >> + ? ? ? {0x00, 0x00, 0x09, "u Processor"}, >> ? ? ? ? {0x00, 0x01, 0x00, "00 Dual-Core Processor"}, >> ? ? ? ? {0x00, 0x01, 0x01, "00e Dual-Core Processor"}, >> ? ? ? ? {0x00, 0x01, 0x02, "00B Dual-Core Processor"}, >> ? ? ? ? {0x00, 0x01, 0x03, "50 Dual-Core Processor"}, >> ? ? ? ? {0x00, 0x01, 0x04, "50e Dual-Core Processor"}, >> ? ? ? ? {0x00, 0x01, 0x05, "50B Dual-Core Processor"}, >> + ? ? ? {0x00, 0x01, 0x06, " Processor"}, >> + ? ? ? {0x00, 0x01, 0x07, "e Processor"}, >> + ? ? ? {0x00, 0x01, 0x09, "0 Processor"}, >> + ? ? ? {0x00, 0x01, 0x0A,"0e Processor"}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >> + ? ? ? {0x00, 0x01, 0x0B, "u Processor"}, > > [?] > > > Thanks, > > Paul Hi Paul, Thanks for the review. I fixed the missing space. r5815 Marc -- http://se-eng.com From peter at stuge.se Thu Sep 16 23:21:52 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 16 Sep 2010 23:21:52 +0200 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <20100916212152.8080.qmail@stuge.se> Hi Frederic, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > this was my first try to build a coreboot bios ever, for my tyan > s2895 mobo. Cool! Remember that coreboot is not a BIOS, all the BIOS stuff is in SeaBIOS, the coreboot payload. coreboot just does the early hardware initialization. :) > The computer is booting, and then crashing on Ubuntu logo (10.04 > 64bits version), so far so nice. This is pretty good progress for the very first try! :) > I downloaded latest available verszion of payload seabios, with > command "git clone git://git.linuxtogo.org/home/kevin/seabios.git seabios". .. > The make command has build the file => out/bios.bin.elf 1048716 bytes This is wrong. The SeaBIOS payload file should only be a few hundred kb. There is a problem with the build of SeaBIOS. > Now i downloaded latest coreboot files, with a > "svn co svn://coreboot.org/coreboot/trunk coreboot" > But, on first "make", i run into troubles: .. > Then i find out (in some mailing list archive) that there is a > integrated compiling toolchain in the coreboot files, under > "coreboot/util/crossgcc". We have discovered that the toolchains shipped in many distributions can not correctly build coreboot. So the script that makes a "reference" toolchain was created. > I burned the coreboot.rom into the RD1 chip, and restared the > computer. I then saw briefly a message about pressing F12 for some > configuration. This message is from SeaBIOS. When you see the message, coreboot has already finished. > After some other quick messages, which i coulnd read, i saw Ubuntu > starting and then crashing on the graphical logo. Too bad. :( Hopefully we can identify the reason for this. > Now i have a 3 questions for you: > > Is the coreboot.rom 32bits only and is there any advantage to build > a 64bits version of the coreboot bios, as i intend to run a 64bits OS ? coreboot.rom has both 16-bit and 32-bit code, but no 64-bit code. I don't believe it is common (at least not yet) to boot directly in 64-bit mode. Rather all operating systems will handle the switch into 64-bit mode themselves. > I build the seabios with Ubuntu gcc 64bits version, it is > compatible, can i mix it, with the coreboot.rom build with i386-elf > coreboot toolchain ? In theory yes, you can build coreboot with one toolchain, and the payload with another, that's not a problem, but it of course requires that both toolchains actually build correct binaries. :) Because of the abnormally large size of your SeaBIOS binary I think it is possible that the Ubuntu toolchain also can not build SeaBIOS correctly. I would definately try to build SeaBIOS with the i386-elf toolchain and see if the results are any different. > The build seabios (bios.bin.elf) is about 1MB in size, how it is > possible to put it into a smaller 512KB chip inside coreboot.rom ? bios.bin.elf should be much smaller. > I didnt put VGA bios so far into the coreboot.rom. Do you have a discrete graphics card in your system? I think you do, otherwise how could the graphics card have been initialized? > In my opinion, it would be a good idea to mention, somewhere in the > build howto, that there is a integrated toolchain in coreboot, and > may be also mention not to forget to delete the .xcompile file > after the toolchain was built. I think this is a good point. > What are your advice for the next steps ? Make sure that coreboot and SeaBIOS are built with maximum debug loglevel and connect a second PC to the serial port of your Tyan board. You will get quite verbose output, which you can study to follow what coreboot and SeaBIOS are doing, and you can also send the output to this mailing list to have more eyes try to find if there is a problem somewhere. > Put VGA bios into coreboot.rom, change Ubuntu default start to > non-graphical one ? I think the problems are way before Ubuntu, so the first step should be coreboot+SeaBIOS debug output, but sure, setting also the Ubuntu console to the serial port is a good idea; that way all messages from starting the system can be collected in one place. //Peter From mylesgw at gmail.com Thu Sep 16 23:24:37 2010 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 16 Sep 2010 15:24:37 -0600 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: > Now i have a 3 questions for you: > > Is the coreboot.rom 32bits only and is there any advantage to build a > 64bits version of the coreboot bios, as i intend to run a 64bits OS ? Coreboot is 32 bit, but it will work fine with a 64-bit OS. > I build the seabios with Ubuntu gcc 64bits version, it is compatible, can > i mix it, with the coreboot.rom build with i386-elf coreboot toolchain ? > The build seabios (bios.bin.elf) is about 1MB in size, how it is possible > to put it into a smaller 512KB chip inside coreboot.rom ? Most of it is empty space. When the ELF gets unpacked, it doesn't take that much space. > I didnt put VGA bios so far into the coreboot.rom. Have you tried using a separate graphics card? That would narrow down the problem. I would try adding the VGA BIOS, though. > In my opinion, it would be a good idea to mention, somewhere in the build > howto, that there is a integrated toolchain in coreboot, and may be also > mention not to forget to delete the .xcompile file after the toolchain was > built. I thought if you did a 'make clean' it deleted the .xcompile file. > What are your advice for the next steps ? I would add a Video card or put the VGA BIOS into coreboot.rom. Whichever one you find easier. Thanks, Myles From svn at coreboot.org Thu Sep 16 23:36:45 2010 From: svn at coreboot.org (repository service) Date: Thu, 16 Sep 2010 23:36:45 +0200 Subject: [coreboot] [commit] r5816 - trunk/payloads/external/tint Message-ID: Author: mjones Date: Thu Sep 16 23:36:44 2010 New Revision: 5816 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5816 Log: Add default libpayload build, xcompile, and lpgcc setup to tint. Signed-off-by: Marc Jones Acked-by: Peter Stuge Acked-by: Myles Watson Modified: trunk/payloads/external/tint/libpayload_tint.patch Modified: trunk/payloads/external/tint/libpayload_tint.patch ============================================================================== --- trunk/payloads/external/tint/libpayload_tint.patch Thu Sep 16 23:04:54 2010 (r5815) +++ trunk/payloads/external/tint/libpayload_tint.patch Thu Sep 16 23:36:44 2010 (r5816) @@ -1,15 +1,94 @@ Patch tint 0.03b to be usable as coreboot payload, linked against -the libpayload library. +the libpayload library. Signed-off-by: Uwe Hermann -diff -Naur tint-0.03b.orig/config.h tint-0.03b/config.h ---- tint-0.03b.orig/config.h 2001-12-08 00:03:24.000000000 +0100 -+++ tint-0.03b/config.h 2008-04-11 22:19:35.000000000 +0200 + +Add default libpayload build, xcompile, and lpgcc setup to tint. + +Signed-off-by: Marc Jones + +diff -rupN tintorig/Makefile tint/Makefile +--- tintorig/Makefile 2005-07-17 05:30:54.000000000 -0600 ++++ tint/Makefile 2010-08-23 18:06:24.671875000 -0600 +@@ -28,6 +28,65 @@ + # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + ++$(if $(wildcard .xcompile),,$(eval $(shell bash ./xcompile.sh &> .xcompile))) ++include .xcompile ++ ++LIBCONFIG_PATH := ../libpayload ++LIBPAYLOAD_DIR := ./libpayloadbin ++LPCC := $(LIBPAYLOAD_DIR)/libpayload/bin/lpgcc ++LPAS := $(LIBPAYLOAD_DIR)/libpayload/bin/lpas ++HAVE_LIBPAYLOAD := $(wildcard $(LIBPAYLOAD_DIR)/libpayload/lib/libpayload.a) ++LIB_CONFIG ?= defconfig ++ ++# CFLAGS := -Wall -Werror -Os ++CFLAGS := -Wall -g -Os ++TARGET := tint ++OBJS := $(TARGET).o engine.o io.o utils.o ++ ++# Make is silent per default, but 'make V=1' will show all compiler calls. ++ifneq ($(V),1) ++Q := @ ++endif ++ ++all: $(TARGET).elf ++# printf" CC $(CC)\n" ++ ++$(TARGET).elf: $(OBJS) libpayload ++ $(Q)printf " LPCC $(subst $(shell pwd)/,,$(@))\n" ++ $(Q)$(LPCC) -o $@ $(OBJS) ++ $(Q)$(OBJCOPY) --only-keep-debug $@ tint.debug ++ $(Q)$(OBJCOPY) --strip-debug $@ ++ $(Q)$(OBJCOPY) --add-gnu-debuglink=tint.debug $@ ++ ++%.o: %.c libpayload ++ $(Q)printf " LPCC $(subst $(shell pwd)/,,$(@))\n" ++ $(Q)$(LPCC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $< ++ ++%.S.o: %.S libpayload ++ $(Q)printf " LPAS $(subst $(shell pwd)/,,$(@))\n" ++ $(Q)$(LPAS) $(ASFLAGS) --32 -o $@ $< ++ ++ifneq ($(strip $(HAVE_LIBPAYLOAD)),) ++libpayload: ++ $(Q)printf "Found Libpayload $(LIBPAYLOAD_DIR).\n" ++else ++libpayload: ++ $(Q)printf "Building libpayload @ $(LIBCONFIG_PATH).\n" ++ $(Q)make -C $(LIBCONFIG_PATH) distclean ++ $(Q)make -C $(LIBCONFIG_PATH) $(LIB_CONFIG) ++ $(Q)make -C $(LIBCONFIG_PATH) DESTDIR=$(shell pwd)/$(LIBPAYLOAD_DIR) install ++endif ++ ++clean: ++ $(Q)rm -f $(TARGET).elf $(TARGET).debug *.o ++ $(Q)rm .xcompile ++ ++distclean: clean ++ $(Q)rm -rf $(LIBPAYLOAD_DIR) ++ ++# Original tint targets ++ifdef $(UNUSED) ++ + #CROSS = arm-linux- + + bindir = $(DESTDIR)/usr/games +@@ -110,3 +169,4 @@ clean: + distclean: clean + $(MAKE) -C debian clean + ++endif +diff -rupN tintorig/config.h tint/config.h +--- tintorig/config.h 2001-12-07 16:03:24.000000000 -0700 ++++ tint/config.h 2010-01-27 13:59:18.000000000 -0700 @@ -29,7 +29,16 @@ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ - + +#include +#include +#define random(x) rand(x) @@ -21,31 +100,31 @@ +#if 0 const char scorefile[] = SCOREFILE; +#endif - + #endif /* #ifndef CONFIG_H */ -diff -Naur tint-0.03b.orig/engine.c tint-0.03b/engine.c ---- tint-0.03b.orig/engine.c 2005-07-17 13:26:22.000000000 +0200 -+++ tint-0.03b/engine.c 2008-04-11 22:19:35.000000000 +0200 +diff -rupN tintorig/engine.c tint/engine.c +--- tintorig/engine.c 2005-07-17 05:26:22.000000000 -0600 ++++ tint/engine.c 2010-01-27 13:59:18.000000000 -0700 @@ -27,8 +27,12 @@ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ - + +#include "config.h" + +#if 0 #include #include +#endif - + #include "typedefs.h" #include "utils.h" -diff -Naur tint-0.03b.orig/io.c tint-0.03b/io.c ---- tint-0.03b.orig/io.c 2001-12-07 16:48:20.000000000 +0100 -+++ tint-0.03b/io.c 2008-04-11 22:19:35.000000000 +0200 +diff -rupN tintorig/io.c tint/io.c +--- tintorig/io.c 2001-12-07 08:48:20.000000000 -0700 ++++ tint/io.c 2010-01-27 13:59:18.000000000 -0700 @@ -27,9 +27,13 @@ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ - + +#include "config.h" + +#if 0 @@ -53,10 +132,10 @@ #include /* gettimeofday() */ #include /* gettimeofday() */ +#endif - + #include - -@@ -70,7 +74,11 @@ + +@@ -70,7 +74,11 @@ static int in_timeleft; /* Initialize screen */ void io_init () { @@ -68,7 +147,7 @@ start_color (); curs_set (CURSOR_INVISIBLE); out_attr = A_NORMAL; -@@ -176,11 +184,17 @@ +@@ -176,11 +184,17 @@ void out_beep () /* Read a character. Please note that you MUST call in_timeout() before in_getch() */ int in_getch () { @@ -86,102 +165,62 @@ gettimeofday (&endtv,NULL); /* Timeout? */ if (ch == ERR) -@@ -198,6 +212,7 @@ +@@ -198,6 +212,7 @@ int in_getch () in_timeleft -= endtv.tv_usec; if (in_timeleft <= 0) in_timeleft = in_timetotal; } +#endif return ch; } - -diff -Naur tint-0.03b.orig/Makefile tint-0.03b/Makefile ---- tint-0.03b.orig/Makefile 2005-07-17 13:30:54.000000000 +0200 -+++ tint-0.03b/Makefile 2008-04-11 22:19:35.000000000 +0200 -@@ -28,6 +28,36 @@ - # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -+LIBPAYLOAD_DIR := ../libpayload -+CC := $(LIBPAYLOAD_DIR)/bin/lpgcc -+AS := $(LIBPAYLOAD_DIR)/bin/lpas -+# CFLAGS := -Wall -Werror -Os -+CFLAGS := -Wall -Os -+TARGET := tint -+OBJS := $(TARGET).o engine.o io.o utils.o -+ -+all: $(TARGET).elf -+ -+$(TARGET).elf: $(OBJS) -+ $(CC) -o $@ $(OBJS) -+ -+%.o: %.c -+ $(CC) $(CFLAGS) -c -o $@ $< -+ -+%.S.o: %.S -+ $(AS) --32 -o $@ $< -+ -+clean: -+ rm -f $(TARGET).elf *.o -+ -+distclean: clean -+ -+ -+ -+ -+ -+ifdef $(UNUSED) -+ - #CROSS = arm-linux- - - bindir = $(DESTDIR)/usr/games -@@ -110,3 +140,4 @@ - distclean: clean - $(MAKE) -C debian clean - -+endif -diff -Naur tint-0.03b.orig/tint.c tint-0.03b/tint.c ---- tint-0.03b.orig/tint.c 2005-07-17 13:26:43.000000000 +0200 -+++ tint-0.03b/tint.c 2008-04-11 22:19:35.000000000 +0200 -@@ -27,6 +27,7 @@ + +diff -rupN tintorig/tint.c tint/tint.c +--- tintorig/tint.c 2005-07-17 05:26:43.000000000 -0600 ++++ tint/tint.c 2010-08-23 18:13:53.281250000 -0600 +@@ -1,4 +1,3 @@ +- + /* + * Copyright (c) Abraham vd Merwe + * All rights reserved. +@@ -27,6 +26,7 @@ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ - + +#if 0 #include #include #include -@@ -34,6 +35,7 @@ +@@ -34,6 +34,7 @@ #include #include #include +#endif - + #include "typedefs.h" #include "utils.h" -@@ -321,6 +323,7 @@ +@@ -321,6 +322,7 @@ typedef struct time_t timestamp; } score_t; - + +#if 0 static void getname (char *name) { struct passwd *pw = getpwuid (geteuid ()); -@@ -337,7 +340,9 @@ +@@ -337,7 +339,9 @@ static void getname (char *name) name[NAMELEN - 1] = '\0'; } } +#endif - + +#if 0 static void err1 () { fprintf (stderr,"Error creating %s\n",scorefile); -@@ -349,10 +354,11 @@ +@@ -349,10 +353,11 @@ static void err2 () fprintf (stderr,"Error writing to %s\n",scorefile); exit (EXIT_FAILURE); } +#endif - + void showplayerstats (engine_t *engine) { - fprintf (stderr, @@ -189,83 +228,83 @@ "\n\t PLAYER STATISTICS\n\n\t" "Score %11d\n\t" "Efficiency %11d\n\t" -@@ -360,6 +366,7 @@ +@@ -360,6 +365,7 @@ void showplayerstats (engine_t *engine) GETSCORE (engine->score),engine->status.efficiency,GETSCORE (engine->score) / getsum ()); } - + +#if 0 static void createscores (int score) { FILE *handle; -@@ -394,7 +401,9 @@ +@@ -394,7 +400,9 @@ static void createscores (int score) fprintf (stderr,"%s",scoretitle); fprintf (stderr,"\t 1* %7d %s\n\n",score,scores[0].name); } +#endif - + +#if 0 static int cmpscores (const void *a,const void *b) { int result; -@@ -412,7 +421,9 @@ +@@ -412,7 +420,9 @@ static int cmpscores (const void *a,cons /* timestamps is equal */ return 0; } +#endif - + +#if 0 static void savescores (int score) { FILE *handle; -@@ -490,11 +501,13 @@ +@@ -490,11 +500,13 @@ static void savescores (int score) } fprintf (stderr,"\n"); } +#endif - + /***************************************************************************/ /***************************************************************************/ /***************************************************************************/ - + +#if 0 static void showhelp () { fprintf (stderr,"USAGE: tint [-h] [-l level] [-n]\n"); -@@ -504,9 +517,11 @@ +@@ -504,9 +516,11 @@ static void showhelp () fprintf (stderr," -d Draw vertical dotted lines\n"); exit (EXIT_FAILURE); } +#endif - + static void parse_options (int argc,char *argv[]) { +#if 0 int i = 1; while (i < argc) { -@@ -536,10 +551,12 @@ +@@ -536,10 +550,12 @@ static void parse_options (int argc,char } i++; } +#endif } - + static void choose_level () { +#if 0 char buf[NAMELEN]; - + do -@@ -549,6 +566,8 @@ +@@ -549,6 +565,8 @@ static void choose_level () buf[strlen (buf) - 1] = '\0'; } while (!str2int (&level,buf) || level < MINLEVEL || level > MAXLEVEL); +#endif + level = 1; } - + /***************************************************************************/ -@@ -663,8 +682,15 @@ +@@ -663,8 +681,15 @@ int main (int argc,char *argv[]) if (ch != 'q') { showplayerstats (&engine); @@ -273,21 +312,21 @@ savescores (GETSCORE (engine.score)); +#endif } -+ mvprintw(10, 10, "Bye."); ++ printf("Bye.\n"); + refresh(); -+ halt(); ++ for(;;); //halt(); +#if 0 exit (EXIT_SUCCESS); +#endif } - -diff -Naur tint-0.03b.orig/utils.c tint-0.03b/utils.c ---- tint-0.03b.orig/utils.c 2001-12-07 16:49:19.000000000 +0100 -+++ tint-0.03b/utils.c 2008-04-11 22:19:35.000000000 +0200 + +diff -rupN tintorig/utils.c tint/utils.c +--- tintorig/utils.c 2001-12-07 08:49:19.000000000 -0700 ++++ tint/utils.c 2010-01-27 13:59:18.000000000 -0700 @@ -27,9 +27,13 @@ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ - + +#include "config.h" + +#if 0 @@ -295,10 +334,10 @@ #include #include +#endif - + #include "typedefs.h" - -@@ -41,8 +45,11 @@ + +@@ -41,8 +45,11 @@ void rand_init () #ifdef USE_RAND srand (time (NULL)); #else @@ -308,9 +347,9 @@ + srandom (123); +#endif } - + /* -@@ -61,6 +68,7 @@ +@@ -61,6 +68,7 @@ int rand_value (int range) * Convert an str to long. Returns TRUE if successful, * FALSE otherwise. */ @@ -318,8 +357,88 @@ bool str2int (int *i,const char *str) { char *endptr; -@@ -69,3 +77,4 @@ +@@ -69,3 +77,4 @@ bool str2int (int *i,const char *str) return TRUE; } - + +#endif +diff -rupN tintorig/xcompile.sh tint/xcompile.sh +--- tintorig/xcompile.sh 1969-12-31 17:00:00.000000000 -0700 ++++ tint/xcompile.sh 2010-03-10 15:34:51.421875000 -0700 +@@ -0,0 +1,76 @@ ++#!/bin/bash ++ ++CONFIG=defconfig ++SCRIPT_DIR=`dirname "$0"` ++ ++for make in make gmake gnumake; do ++ if [ "`$make --version 2>/dev/null | grep -c GNU`" -gt 0 ]; then ++ MAKE=$make ++ break ++ fi ++done ++ ++GCCPREFIX=invalid ++for gccprefixes in `pwd`/$SCRIPT_DIR/../../util/crossgcc/xgcc/bin/i386-elf- i386-elf- ""; do ++ TMP=`mktemp /tmp/temp.XXXX` ++ echo "mov %eax, %eax" > ${TMP}.s ++ printf "\x7fELF" > ${TMP}.compare ++ if which ${gccprefixes}as 2>/dev/null >/dev/null; then ++ printf "" ++ else ++ continue ++ fi ++ if ${gccprefixes}as --32 -o ${TMP}.o ${TMP}.s; then ++ dd bs=4 count=1 if=${TMP}.o > ${TMP}.test 2>/dev/null ++ if cmp ${TMP}.test ${TMP}.compare; then ++ GCCPREFIX=$gccprefixes ++ rm -f $TMP ${TMP}.s ${TMP}.o ${TMP}.compare ${TMP}.test ++ break ++ fi ++ fi ++ rm -f $TMP ${TMP}.s ${TMP}.o ${TMP}.compare ${TMP}.test ++done ++ ++if [ "$GCCPREFIX" = "invalid" ]; then ++ echo no suitable gcc found ++ exit 1 ++fi ++ ++#MAKEFLAGS=" \ ++# AS=\"${GCCPREFIX}as --32\" \ ++# CC=\"${GCCPREFIX}gcc -m32\" \ ++# AR=\"${GCCPREFIX}ar\" \ ++# LD=\"${GCCPREFIX}ld -b elf32-i386\" \ ++# STRIP=\"${GCCPREFIX}strip\" \ ++# NM=\"${GCCPREFIX}nm\" \ ++# HOSTCC=gcc \ ++# -j \ ++#" ++ ++cat << afteroptions ++export AS:=${GCCPREFIX}as --32 ++export CC:=${GCCPREFIX}gcc -m32 ++export CPP:=${GCCPREFIX}cpp ++export AR:=${GCCPREFIX}ar ++export LD:=${GCCPREFIX}ld -b elf32-i386 ++export STRIP:=${GCCPREFIX}strip ++export NM:=${GCCPREFIX}nm ++export OBJCOPY:=${GCCPREFIX}objcopy ++export OBJDUMP:=${GCCPREFIX}objdump ++export HOSTCC:=gcc ++afteroptions ++ ++# Should we let the payload build libpayload or do it for them? ++#test -d ./build || ( ++# BUILDDIR=$PWD ++# cd ../libpayload ++# $MAKE distclean ++# cp configs/$CONFIG .config ++# $MAKE oldconfig ++# eval $MAKE $MAKEFLAGS ++# eval $MAKE $MAKEFLAGS DESTDIR=$BUILDDIR/build install ++# cd .. ++#) ++ ++# eval $MAKE -C $SCRIPT_DIR $MAKEFLAGS ++ From marcj303 at gmail.com Thu Sep 16 23:37:24 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 16 Sep 2010 15:37:24 -0600 Subject: [coreboot] Fwd: [patch] tint payload update In-Reply-To: <20100915210916.25244.qmail@stuge.se> References: <20100915185511.6788.qmail@stuge.se> <20100915210916.25244.qmail@stuge.se> Message-ID: On Wed, Sep 15, 2010 at 3:09 PM, Peter Stuge wrote: > Marc Jones wrote: >> > As for the build things, can we not get around stuffing all of that >> > into each payload? >> >> What do you mean? It seems to me that we want each payload >> responsible for building its own version of libpayload. > > I hadn't thought of that! Do we? Interesting. > > In a way it makes sense because different payloads need different > parts of libpayload. But thinking of it as a replacement for glibc or > at least crt0 then it isn't so nice to have more than one. This is > how I've always thought of it until now. > > But ok, say we want local libpayload per payload, then I think we > should still try to simplify things. > > Maybe provide a payload.inc Makefile stub in libpayload which the > payload Makefile simply includes after setting a variable name or > two? > > That's a different patch(set) though. :) > > Acked-by: Peter Stuge > > > //Peter Thanks Myles and Peter. r5816 Updating the wiki now. Marc -- http://se-eng.com From marcj303 at gmail.com Thu Sep 16 23:39:04 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 16 Sep 2010 15:39:04 -0600 Subject: [coreboot] [help] A K8/RS780/SB710 board MCE error In-Reply-To: References: Message-ID: On Thu, Sep 16, 2010 at 12:53 AM, Liu Tao wrote: > On 9/16/10, Marc Jones wrote: >> I haven't worked with K8 is a while, but it seems like this could be a >> real CPU problem. Do you have another CPU to test with? The other >> possibility is that there is a missing errata or workaround for your >> CPU. You could review the AMD K8 revision guide for cache and MCA/MCE >> issues. Please let us know what you find. > > Hi Marc, > > I just update coreboot from r5692 to r5814 and the problem resolved, > before update the code I have met three types of MCE error: > Data cache ECC error > L2 cache ECC error > Northbridge chipkill ECC error > > I have not take a detailed look at the code differences yet, but I think > maybe it's related to the recent discussion of amd cache broken? Glad that it is workin now. It is probably not the CAR stuff, that was for fam10. Marc -- http://se-eng.com From harald.gutmann at gmx.net Thu Sep 16 23:16:12 2010 From: harald.gutmann at gmx.net (Harald Gutmann) Date: Thu, 16 Sep 2010 23:16:12 +0200 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <201009162316.12982.harald.gutmann@gmx.net> Hello Frederic, I'm sorry to get a bit "rude" in my answer, but here is what I want to say: "crashing on Ubuntu logo" Oh, that's really a nice description of what happens. No way to tell you what's the problem with your bios, without a more detailed error output. And yes you couldn't see a lot on your screen before booting Ubuntu, because coreboot is fast. My advice as a next step would be: Try to get an error log which is useful. Means, turn off the graphical stuff of Ubuntu, get a serial console, and a decent log of the failing boot process. Everything else will be a guessing around without a good chance to track the problem. BTW: That's one of the reasons why I don't like Ubuntu, people don't learn any more how kernel/boot messages look like, how much information is in there and how to interpret those messages. "Crashing Ubuntu logo" - This is as stupid as the new Ubuntu splash screen which indicates a loading bar, but at the end of the bar it starts in the beginning once again. There is not even a chance to guess in which part of booting problems occur. The same bars come around in Windows Vista/7 and iTunes setup and so on. But who whats to have a loading bar which does say exactly nothing? It seems that too much stuff gets just eye candy and showing the user that something is happening without any interesting information. Oh, once again sorry. But such things have the power to get me upset. ;) Kind regards, Harald On Thursday 16 September 2010 22:18:32 STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > Hello, > > this was my first try to build a coreboot bios ever, for my tyan s2895 > mobo. I get managed to build and burn the bios into a RD1 512KB bios > savior chip. The computer is booting, and then crashing on Ubuntu logo > (10.04 64bits version), so far so nice. > > Here is what i have done: > > My rom build computer is installed with Ubuntu 10.04 64bits version, with > build-essential and some other packages (flex bison git-core g++ gdb > libncurses5-dev doxygen iasl build-essential lzma-dev liblzma-dev) I > downloaded latest available verszion of payload seabios, with command "git > clone git://git.linuxtogo.org/home/kevin/seabios.git seabios". Then i have > adapted the config.h file as follow: > > #define CONFIG_COREBOOT 1 > #define CONFIG_DEBUG_SERIAL 1 > #define CONFIG_VGAHOOKS 1 > > The make command has build the file => out/bios.bin.elf 1048716 bytes > > Now i downloaded latest coreboot files, with a "svn co > svn://coreboot.org/coreboot/trunk coreboot" But, on first "make", i run > into troubles: > > build/coreboot_ram.o: In function `__wrap___umoddi3': > (.text+0x1223f): undefined reference to `__umoddi3' > build/coreboot_ram.o: In function `__wrap___moddi3': > (.text+0x1224a): undefined reference to `__moddi3' > build/coreboot_ram.o: In function `__wrap___udivdi3': > (.text+0x12255): undefined reference to `__udivdi3' > build/coreboot_ram.o: In function `__wrap___divdi3': > (.text+0x12260): undefined reference to `__divdi3' > collect2: ld returned 1 exit status > make: *** [build/coreboot_ram] Erreur 1 > > Then i find out (in some mailing list archive) that there is a integrated > compiling toolchain in the coreboot files, under "coreboot/util/crossgcc". > The command "./buildgcc" was succesfull even if it tooks some time, > enought to drink a coffee. > > On second "make" try, same compile errors. After some researches i find out > that i need to do a "rm -rf build" and a new "make menuconfig", but it > didnt solved my problem, same compilation errors :( I finnaly found out > that i need to also delete the .xcompile file. So after the "rm -rf > build", "rm .config", "rm .xcompile" and finally a "make menuconfig", the > "make" was working (i am not a programmer), yes. > > I burned the coreboot.rom into the RD1 chip, and restared the computer. I > then saw briefly a message about pressing F12 for some configuration. > After some other quick messages, which i coulnd read, i saw Ubuntu > starting and then crashing on the graphical logo. This is not really a > problem so far, as i was able to switch back to the original bios to get > computer up and running. > > > Now i have a 3 questions for you: > > Is the coreboot.rom 32bits only and is there any advantage to build a > 64bits version of the coreboot bios, as i intend to run a 64bits OS ? I > build the seabios with Ubuntu gcc 64bits version, it is compatible, can i > mix it, with the coreboot.rom build with i386-elf coreboot toolchain ? The > build seabios (bios.bin.elf) is about 1MB in size, how it is possible to > put it into a smaller 512KB chip inside coreboot.rom ? > > I didnt put VGA bios so far into the coreboot.rom. > > In my opinion, it would be a good idea to mention, somewhere in the build > howto, that there is a integrated toolchain in coreboot, and may be also > mention not to forget to delete the .xcompile file after the toolchain was > built. > > What are your advice for the next steps ? Put VGA bios into coreboot.rom, > change Ubuntu default start to non-graphical one ? I have attached the > .config file for coreboot (btw i used lzma compression for payload). > > Thank you very much, i really appreciate your help. > Fr?d?ric Stemmelin From scott at notabs.org Thu Sep 16 23:45:22 2010 From: scott at notabs.org (Scott Duplichan) Date: Thu, 16 Sep 2010 16:45:22 -0500 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: ]Now i have a 3 questions for you: ]The build seabios (bios.bin.elf) is about 1MB in size..., The seabios web page has links to prebuilt binaries. You could start off using one of these known-good seabios binaries to eliminate unknowns. ]I didnt put VGA bios so far into the coreboot.rom. If you see the F12 message on the connected monitor, then a suitable video bios has been found and used. By the way, I have this exact board sitting on the shelf. If I can dig up a suitable power supply, I might give it a try. Thanks, Scott From corey.osgood at gmail.com Thu Sep 16 23:59:54 2010 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 16 Sep 2010 14:59:54 -0700 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: On Thu, Sep 16, 2010 at 1:18 PM, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > The computer is booting, and then crashing on Ubuntu logo (10.04 64bits version), so far so nice. In your /etc/default/grub, comment out this line: GRUB_CMDLIN_LINUX_DEFAULT="quiet splash" and replace it with GRUB_CMDLIN_LINUX_DEFAULT="verbose" Then do "sudo update-grub" to update the config files. That should let you see exactly *where* it's failing. -Corey From anders at jenbo.dk Fri Sep 17 01:39:30 2010 From: anders at jenbo.dk (Anders Jenbo) Date: Fri, 17 Sep 2010 01:39:30 +0200 Subject: [coreboot] Ali m1541 In-Reply-To: <20100916094754.GA16423@skynet.be> References: <20100915122712.GA2808@skynet.be> <1284566934.2025.3.camel@anders-desktop> <20100916094754.GA16423@skynet.be> Message-ID: <1284680370.2171.27.camel@anders-desktop> Just thought it might be fun to implement a totally new chip set :) Already have 3 system running Coreboot. -Anders tor, 16 09 2010 kl. 11:47 +0200, skrev Luc Verhaegen: > On Wed, Sep 15, 2010 at 06:08:54PM +0200, Anders Jenbo wrote: > > Sorry i was mistaking, it is Socket 7 old :p > > > > Well, the good side of the ali is that the docs are available. But if it > is the p5a, the asus specific superio will trump whatever effort that > could happen. > > But, why bother? > > Find a chipset and superio that are supported, buy some board that > hasn't been implemented yet from like ebay. There is tons of options > there. > > This will get you much more recent hardware, which, when working > well, gives you a freer system, that you can use yourself afterwards. > Makes things more useful for the world, and give yourself more > satisfaction. > > So forget the ali chipsets. > > Luc Verhaegen. From corey.osgood at gmail.com Fri Sep 17 01:43:04 2010 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 16 Sep 2010 16:43:04 -0700 Subject: [coreboot] Ali m1541 In-Reply-To: <1284680370.2171.27.camel@anders-desktop> References: <20100915122712.GA2808@skynet.be> <1284566934.2025.3.camel@anders-desktop> <20100916094754.GA16423@skynet.be> <1284680370.2171.27.camel@anders-desktop> Message-ID: On Thu, Sep 16, 2010 at 4:39 PM, Anders Jenbo wrote: > Just thought it might be fun to implement a totally new chip set :) > Already have 3 system running Coreboot. > > -Anders Well, if it's Slot 1 it should be SDRAM, so the memory init should be extremely simple. If you can get the datasheets and want to tinker with it, why not? -Corey > > > tor, 16 09 2010 kl. 11:47 +0200, skrev Luc Verhaegen: >> On Wed, Sep 15, 2010 at 06:08:54PM +0200, Anders Jenbo wrote: >> > Sorry i was mistaking, it is Socket 7 old :p >> > >> >> Well, the good side of the ali is that the docs are available. But if it >> is the p5a, the asus specific superio will trump whatever effort that >> could happen. >> >> But, why bother? >> >> Find a chipset and superio that are supported, buy some board that >> hasn't been implemented yet from like ebay. There is tons of options >> there. >> >> This will get you much more recent hardware, which, when working >> well, gives you a freer system, that you can use yourself afterwards. >> Makes things more useful for the world, and give yourself more >> satisfaction. >> >> So forget the ali chipsets. >> >> Luc Verhaegen. > > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From anders at jenbo.dk Fri Sep 17 01:44:19 2010 From: anders at jenbo.dk (Anders Jenbo) Date: Fri, 17 Sep 2010 01:44:19 +0200 Subject: [coreboot] Porting coreboot to Unknown Sis620/5595 Motherboard In-Reply-To: References: Message-ID: <1284680659.2171.35.camel@anders-desktop> This board is a hard one to start out with i would say. You should look in to getting the documentation for the SIS 620 chip set. I see that the SIS 630 is supported by Coreboot v1 so you might want to look in to porting that to v4 and then the SIS 620. -Anders ons, 15 09 2010 kl. 18:30 -0300, skrev Hernan Freschi: > Hello, > I'd like to port coreboot to a motherboard I have. I dont have either > brand or model (it's a generic OEM board). > > I'm not sure what info is needed so I have uploaded: > > lspci -xxxvvvnnn http://pastebin.org/876731 > superiotool -deV http://pastebin.org/876714 > > I'd like to know if it's possible and what are the steps to get started. > > Thanks, > Hernan > From svn at coreboot.org Fri Sep 17 02:13:52 2010 From: svn at coreboot.org (repository service) Date: Fri, 17 Sep 2010 02:13:52 +0200 Subject: [coreboot] [commit] r5817 - trunk/src/cpu/amd/model_10xxx Message-ID: Author: mjones Date: Fri Sep 17 02:13:52 2010 New Revision: 5817 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5817 Log: Clear bit 35 of msr c001_102a in Fam10 rev C cores. Signed-off-by: Arne Georg Gleditsch Acked-by: Scott Duplichan Modified: trunk/src/cpu/amd/model_10xxx/defaults.h trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c Modified: trunk/src/cpu/amd/model_10xxx/defaults.h ============================================================================== --- trunk/src/cpu/amd/model_10xxx/defaults.h Thu Sep 16 23:36:44 2010 (r5816) +++ trunk/src/cpu/amd/model_10xxx/defaults.h Fri Sep 17 02:13:52 2010 (r5817) @@ -91,7 +91,7 @@ { BU_CFG2, AMD_DRBH_Cx , AMD_PTYPE_ALL, 0x00000000, 1 << (35-32), - 0x00000000, 1 << (35-32) }, /* Erratum 343 (set to 0 after CAR, in post_cache_as_ram() ) */ + 0x00000000, 1 << (35-32) }, /* Erratum 343 (set to 0 after CAR, in post_cache_as_ram()/model_10xxx_init() ) */ }; Modified: trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c ============================================================================== --- trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c Thu Sep 16 23:36:44 2010 (r5816) +++ trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c Fri Sep 17 02:13:52 2010 (r5817) @@ -113,9 +113,11 @@ msr.hi &= ~(1 << (46 - 32)); wrmsr(NB_CFG_MSR, msr); - /* Clear ClLinesToNbDis */ msr = rdmsr(BU_CFG2_MSR); + /* Clear ClLinesToNbDis */ msr.lo &= ~(1 << 15); + /* Clear bit 35 as per Erratum 343 */ + msr.hi &= ~(1 << (35-32)); wrmsr(BU_CFG2_MSR, msr); /* Write protect SMM space with SMMLOCK. */ From marcj303 at gmail.com Fri Sep 17 02:33:10 2010 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 16 Sep 2010 18:33:10 -0600 Subject: [coreboot] AMD cache setup is broken In-Reply-To: References: <4C812B6D020000FE0000D531@mail.lkfd.net> <87aanv1eax.fsf@taniquetil.gledits.ch> <4C84BD83.2030502@coresystems.de> <8762yj170a.fsf@taniquetil.gledits.ch> <673D2439DC3046D0903811C4830EA052@m3a78> <2AB823A1470D4921A664FB35592308CE@m3a78> <87wrqvs5ua.fsf@taniquetil.gledits.ch> <87sk1js2d8.fsf@taniquetil.gledits.ch> <87occ7s0gf.fsf@taniquetil.gledits.ch> <8762yarpqb.fsf@taniquetil.gledits.ch> <0EF599E03B5F42D581CE5F4D71FAC485@m3a78> Message-ID: On Wed, Sep 15, 2010 at 12:51 PM, Scott Duplichan wrote: > -----Original Message----- > ]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Marc Jones > ]Sent: Wednesday, September 15, 2010 01:32 PM > ]To: Scott Duplichan > ]Cc: Arne Georg Gleditsch; coreboot at coreboot.org > ]Subject: Re: [coreboot] AMD cache setup is broken > ] > ]On Mon, Sep 13, 2010 at 9:15 PM, Scott Duplichan wrote: > ]> ]-----Original Message----- > ]> ]From: coreboot-bounces+scott=notabs.org at coreboot.org [mailto:coreboot-]]bounces+scott=notabs.org at coreboot.org] On Behalf Of Arne > ]> Georg Gleditsch > ]> ]Sent: Monday, September 13, 2010 03:51 AM > ]> ]To: Scott Duplichan > ]> ]Cc: 'Marc Jones'; coreboot at coreboot.org > ]> ]Subject: Re: [coreboot] AMD cache setup is broken > ]> ] > ]> ]"Scott Duplichan" writes: > ]> ]> I think it would be best to clear bit 35 of msr c001_102a in the AP > ]> ]> cores as well as the BSP core. Otherwise, the OS might see AP cores > ]> ]> having slightly lower performance than the BSP core. This bit affects > ]> ]> family 10h revC and newer (45 nm). > ]> ] > ]> ]Ok, so here's a patch adding this. ?Clearing bit 35 is done > ]> ]unconditionally for all fam10 cpus, is that ok? ?Setting is done based > ]> ]on processor type in defaults.h, as before. > ]> > ]> Thanks. This looks correct to me. I used simnow/tilapia to confirm bit > ]> 35 gets cleared in all cores. I found bit 35 never actually gets set. > ]> I submitted a patch to correct that. Once that patch is applied, I can > ]> see bit 35 gets set in all cores, then gets cleared in all cores. > ]> > ]> Thanks, > ]> Scott > ] > ]Hi Scott, > ] > ]Can you Acked-by: if this is working for you. > > Thanks Marc. Here you go.. > > Acked-by: Scott Duplichan r5817 -- http://se-eng.com From kevin at koconnor.net Fri Sep 17 03:30:52 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Thu, 16 Sep 2010 21:30:52 -0400 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <20100916212152.8080.qmail@stuge.se> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20100916212152.8080.qmail@stuge.se> Message-ID: <20100917005151.GA23262@morn.localdomain> On Thu, Sep 16, 2010 at 11:21:52PM +0200, Peter Stuge wrote: > > I downloaded latest available verszion of payload seabios, with > > command "git clone git://git.linuxtogo.org/home/kevin/seabios.git seabios". > .. > > The make command has build the file => out/bios.bin.elf 1048716 bytes > > This is wrong. The SeaBIOS payload file should only be a few hundred > kb. There is a problem with the build of SeaBIOS. This is normal now. A lot of tool chains add padding to the elf file. When the seabios payload gets added to cbfs, this padding is removed. So, the elf size is just misleading. The real size of seabios is shown at the end of the seabios build. On my machine I'll get: Total size: 93744 Free space: 37328 Percent used: 71.5% (128KiB rom) $ ls -l out/bios.bin.elf -rwxr-xr-x 1 kevin 1048716 Sep 16 20:49 out/bios.bin.elf The real size in flash (even without lzma) is 93744 bytes. -Kevin From kevin at koconnor.net Fri Sep 17 03:30:52 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Thu, 16 Sep 2010 21:30:52 -0400 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <20100916212152.8080.qmail@stuge.se> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20100916212152.8080.qmail@stuge.se> Message-ID: <20100917005151.GA23262@morn.localdomain> On Thu, Sep 16, 2010 at 11:21:52PM +0200, Peter Stuge wrote: > > I downloaded latest available verszion of payload seabios, with > > command "git clone git://git.linuxtogo.org/home/kevin/seabios.git seabios". > .. > > The make command has build the file => out/bios.bin.elf 1048716 bytes > > This is wrong. The SeaBIOS payload file should only be a few hundred > kb. There is a problem with the build of SeaBIOS. This is normal now. A lot of tool chains add padding to the elf file. When the seabios payload gets added to cbfs, this padding is removed. So, the elf size is just misleading. The real size of seabios is shown at the end of the seabios build. On my machine I'll get: Total size: 93744 Free space: 37328 Percent used: 71.5% (128KiB rom) $ ls -l out/bios.bin.elf -rwxr-xr-x 1 kevin 1048716 Sep 16 20:49 out/bios.bin.elf The real size in flash (even without lzma) is 93744 bytes. -Kevin From kevin at koconnor.net Fri Sep 17 03:30:52 2010 From: kevin at koconnor.net (Kevin O'Connor) Date: Thu, 16 Sep 2010 21:30:52 -0400 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <20100916212152.8080.qmail@stuge.se> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20100916212152.8080.qmail@stuge.se> Message-ID: <20100917005151.GA23262@morn.localdomain> On Thu, Sep 16, 2010 at 11:21:52PM +0200, Peter Stuge wrote: > > I downloaded latest available verszion of payload seabios, with > > command "git clone git://git.linuxtogo.org/home/kevin/seabios.git seabios". > .. > > The make command has build the file => out/bios.bin.elf 1048716 bytes > > This is wrong. The SeaBIOS payload file should only be a few hundred > kb. There is a problem with the build of SeaBIOS. This is normal now. A lot of tool chains add padding to the elf file. When the seabios payload gets added to cbfs, this padding is removed. So, the elf size is just misleading. The real size of seabios is shown at the end of the seabios build. On my machine I'll get: Total size: 93744 Free space: 37328 Percent used: 71.5% (128KiB rom) $ ls -l out/bios.bin.elf -rwxr-xr-x 1 kevin 1048716 Sep 16 20:49 out/bios.bin.elf The real size in flash (even without lzma) is 93744 bytes. -Kevin From cristi.magherusan at net.utcluj.ro Fri Sep 17 09:01:58 2010 From: cristi.magherusan at net.utcluj.ro (Cristi Magherusan) Date: Fri, 17 Sep 2010 10:01:58 +0300 (EEST) Subject: [coreboot] Porting coreboot to Unknown Sis620/5595 Motherboard In-Reply-To: <1284680659.2171.35.camel@anders-desktop> References: <1284680659.2171.35.camel@anders-desktop> Message-ID: <10601.86.122.13.126.1284706918.squirrel@intranet.utcluj.ro> ?n Vin, Septembrie 17, 2010 2:44, Anders Jenbo a scris: > This board is a hard one to start out with i would say. > > > You should look in to getting the documentation for the SIS 620 chip > set. I see that the SIS 630 is supported by Coreboot v1 so you might want > to look in to porting that to v4 and then the SIS 620. > > -Anders Hi, I think I may also have such a no-name motherboard based on this chipset so I may join you in this effort (I must check, though). I took a look at the datasheets of both 620 and 630 chipsets and from what I can tell after a short look at them, they seem to be very different. This means it needs to be done from scratch eventually. In order to get support for the motherboard, we need to have support for the following components: -ITE IT8661F SuperIO (already supported by coreboot) -SiS5595 southbridge -SiS620 northbridge The first step is to get serial output out of the motherboard for debugging, by getting the SuperIO to work, then implement support for the other components according to their datasheets. Regards, Cristian -- Cristian Magherusan-Stanciu, System Engineer, Nokia Romania. From frederic.stemmelin at alcatel-lucent.com Fri Sep 17 09:36:42 2010 From: frederic.stemmelin at alcatel-lucent.com (STEMMELIN, FREDERIC (FREDERIC)** CTR **) Date: Fri, 17 Sep 2010 09:36:42 +0200 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <857948A3D868694688C70287BBC718140F28F91A@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> > The seabios web page has links to prebuilt binaries. You > could start off using one of these known-good seabios > binaries to eliminate unknowns. I will do it. I built my own seabios as i saw that the prebuilt version has a size of 1MB, and previous revision only around 100KB, that's why. I will give it a try and let you know. > If you see the F12 message on the connected monitor, then > a suitable video bios has been found and used. Good to know. > By the way, I have this exact board sitting on the shelf. > If I can dig up a suitable power supply, I might give it > a try. It would be a good idea, but only if you have time and i have many things still to try to get this board working with coreboot, and i have good hope. I didn't had time to check system logs for example. Cheers, Fr?d?ric -----Message d'origine----- De?: Scott Duplichan [mailto:scott at notabs.org] Envoy??: jeudi 16 septembre 2010 23:45 ??: STEMMELIN, FREDERIC (FREDERIC)** CTR **; coreboot at coreboot.org Objet?: Re: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing ]Now i have a 3 questions for you: ]The build seabios (bios.bin.elf) is about 1MB in size..., The seabios web page has links to prebuilt binaries. You could start off using one of these known-good seabios binaries to eliminate unknowns. ]I didnt put VGA bios so far into the coreboot.rom. If you see the F12 message on the connected monitor, then a suitable video bios has been found and used. By the way, I have this exact board sitting on the shelf. If I can dig up a suitable power supply, I might give it a try. Thanks, Scott From frederic.stemmelin at alcatel-lucent.com Fri Sep 17 09:39:06 2010 From: frederic.stemmelin at alcatel-lucent.com (STEMMELIN, FREDERIC (FREDERIC)** CTR **) Date: Fri, 17 Sep 2010 09:39:06 +0200 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <857948A3D868694688C70287BBC718140F28F91B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> > GRUB_CMDLIN_LINUX_DEFAULT="verbose" in /etc/default/grub and "sudo update-> grub" I will do it, with original VGA bios and prebuild seabios too. Cheers Fr?d?ric -----Message d'origine----- De?: Corey Osgood [mailto:corey.osgood at gmail.com] Envoy??: vendredi 17 septembre 2010 00:00 ??: STEMMELIN, FREDERIC (FREDERIC)** CTR ** Cc?: coreboot at coreboot.org Objet?: Re: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing On Thu, Sep 16, 2010 at 1:18 PM, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > The computer is booting, and then crashing on Ubuntu logo (10.04 64bits version), so far so nice. In your /etc/default/grub, comment out this line: GRUB_CMDLIN_LINUX_DEFAULT="quiet splash" and replace it with GRUB_CMDLIN_LINUX_DEFAULT="verbose" Then do "sudo update-grub" to update the config files. That should let you see exactly *where* it's failing. -Corey From frederic.stemmelin at alcatel-lucent.com Fri Sep 17 09:29:10 2010 From: frederic.stemmelin at alcatel-lucent.com (STEMMELIN, FREDERIC (FREDERIC)** CTR **) Date: Fri, 17 Sep 2010 09:29:10 +0200 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <857948A3D868694688C70287BBC718140F28F919@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> > Coreboot is 32 bit, but it will work fine with a 64-bit OS Thank's for the info > Have you tried using a separate graphics card? That would narrow down the > problem. I would try adding the VGA BIOS, though Yes, in fact there is no internal video card in my board, so i am using a external PCI card, Matrox MGA millenium. I will try with VGA bios from original Tyan bios. > I thought if you did a 'make clean' it deleted the .xcompile file. Thank's for the advice, i will remember for next time. Cheers, Fr?d?ric -----Message d'origine----- De?: Myles Watson [mailto:mylesgw at gmail.com] Envoy??: jeudi 16 septembre 2010 23:25 ??: STEMMELIN, FREDERIC (FREDERIC)** CTR **; coreboot at coreboot.org Objet?: Re: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing > Now i have a 3 questions for you: > > Is the coreboot.rom 32bits only and is there any advantage to build a > 64bits version of the coreboot bios, as i intend to run a 64bits OS ? Coreboot is 32 bit, but it will work fine with a 64-bit OS. > I build the seabios with Ubuntu gcc 64bits version, it is compatible, can > i mix it, with the coreboot.rom build with i386-elf coreboot toolchain ? > The build seabios (bios.bin.elf) is about 1MB in size, how it is possible > to put it into a smaller 512KB chip inside coreboot.rom ? Most of it is empty space. When the ELF gets unpacked, it doesn't take that much space. > I didnt put VGA bios so far into the coreboot.rom. Have you tried using a separate graphics card? That would narrow down the problem. I would try adding the VGA BIOS, though. > In my opinion, it would be a good idea to mention, somewhere in the build > howto, that there is a integrated toolchain in coreboot, and may be also > mention not to forget to delete the .xcompile file after the toolchain was > built. I thought if you did a 'make clean' it deleted the .xcompile file. > What are your advice for the next steps ? I would add a Video card or put the VGA BIOS into coreboot.rom. Whichever one you find easier. Thanks, Myles From r.marek at assembler.cz Fri Sep 17 16:48:38 2010 From: r.marek at assembler.cz (Rudolf Marek) Date: Fri, 17 Sep 2010 16:48:38 +0200 Subject: [coreboot] [PATCH] [RFC] sata PHY settings callback on SB700 Message-ID: <4C937FC6.6060003@assembler.cz> Hi from Fort Worth, Here is a proposed way how to handle the SATA PHY settings on SB700. It consists of weak function which always exists (with defaults) and a possibility to override this with normal function in main.c. This is the other way of doing that and not using the devictree.cb. Please tell if it is ok this way. I suggest all people who ported SB700 should have a look on their SATA PHY settings too because it is most likely PCB/MB dependent. This patch is not tested but it could work. Signed-off-by: Rudolf Marek My holiday ends soonish but I temped to do bit of stuff during El Paso - Forth Worth ride ;) Thanks, Rudolf -------------- next part -------------- A non-text attachment was scrubbed... Name: sata.patch Type: text/x-diff Size: 4157 bytes Desc: not available URL: From hjf at hjf.com.ar Fri Sep 17 16:33:28 2010 From: hjf at hjf.com.ar (Hernan Freschi) Date: Fri, 17 Sep 2010 11:33:28 -0300 Subject: [coreboot] Porting coreboot to Unknown Sis620/5595 Motherboard In-Reply-To: <10601.86.122.13.126.1284706918.squirrel@intranet.utcluj.ro> References: <1284680659.2171.35.camel@anders-desktop> <10601.86.122.13.126.1284706918.squirrel@intranet.utcluj.ro> Message-ID: Here's a photo of the board in question http://yfrog.com/5g20100917104133116resistj On Fri, Sep 17, 2010 at 4:01 AM, Cristi Magherusan wrote: > ?n Vin, Septembrie 17, 2010 2:44, Anders Jenbo a scris: >> This board is a hard one to start out with i would say. >> >> >> You should look in to getting the documentation for the SIS 620 chip >> set. I see that the SIS 630 is supported by Coreboot v1 so you might want >> to look in to porting that to v4 and then the SIS 620. >> >> -Anders > Hi, > > I think I may also have such a no-name motherboard based on this chipset > so I may join you in this effort (I must check, though). > > I took a look at the datasheets of both 620 and 630 chipsets and from what > I can tell after a short look at them, they seem to be very different. > This means it needs to be done from scratch eventually. > > In order to get support for the motherboard, we need to have support for > the following components: > -ITE IT8661F SuperIO (already supported by coreboot) > -SiS5595 southbridge > -SiS620 northbridge > > The first step is to get serial output out of the motherboard for > debugging, by getting the SuperIO to work, then implement support for the > other components according to their datasheets. > > Regards, > Cristian > > -- > Cristian Magherusan-Stanciu, > System Engineer, Nokia Romania. > > From mylesgw at gmail.com Fri Sep 17 17:08:30 2010 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 17 Sep 2010 09:08:30 -0600 Subject: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28F91B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <857948A3D868694688C70287BBC718140F28F91B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: > > GRUB_CMDLIN_LINUX_DEFAULT="verbose" in /etc/default/grub and "sudo > update-> grub" > I will do it, with original VGA bios and prebuild seabios too. Since there's no built-in video card on the s2895, there shouldn't be a VGA BIOS for the board. I was thinking of the s2892. My s2895 boots fine, so when you get a log & send it to the list, we should be able to figure out what's going wrong pretty easily. Thanks, Myles From peter at stuge.se Fri Sep 17 21:05:12 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 17 Sep 2010 21:05:12 +0200 Subject: [coreboot] [PATCH] [RFC] sata PHY settings callback on SB700 In-Reply-To: <4C937FC6.6060003@assembler.cz> References: <4C937FC6.6060003@assembler.cz> Message-ID: <20100917190512.30443.qmail@stuge.se> Rudolf Marek wrote: > Here is a proposed way how to handle the SATA PHY settings on SB700. > It consists of weak function which always exists (with defaults) and > a possibility to override this with normal function in main.c. This > is the other way of doing that and not using the devictree.cb. > > Please tell if it is ok this way. I feel that having these settings in devicetree.cb is the right way, but weak functions could be an excellent step in that direction! Weak functions would add a bit of structure currently missing when stuff is done directly in mainboard_init(). It's also much smaller changes to create the overrides than it is to evolve the internal devicetree API. I like it. //Peter From frederic.stemmelin at alcatel-lucent.com Fri Sep 17 23:01:03 2010 From: frederic.stemmelin at alcatel-lucent.com (STEMMELIN, FREDERIC (FREDERIC)** CTR **) Date: Fri, 17 Sep 2010 23:01:03 +0200 Subject: [coreboot] RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: References: <857948A3D868694688C70287BBC718140F28B6BC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <857948A3D868694688C70287BBC718140F28F91B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>, Message-ID: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Hello, I have tried many things since last time, but still no luck so far. I first checked the system logs to try to find the reason of last system crash (computer freezing) which do not occur with tyan stock 1.06 bios, and here is what i found out (/var/log/messages): Sep 16 21:22:51 tyan kernel: [ 0.676939] pci 0000:00:07.0: hash matches Sep 16 21:22:51 tyan kernel: [ 2.170702] sda: Sep 16 21:22:51 tyan kernel: [ 2.193411] sda1 sda2 Sep 16 21:22:51 tyan kernel: [ 2.429232] EXT4-fs (sda1): INFO: recovery required on readonly filesystem Sep 16 21:22:51 tyan kernel: [ 2.429236] EXT4-fs (sda1): write access will be enabled during recovery Sep 16 21:22:51 tyan kernel: [ 15.260291] EXT4-fs (sda1): recovery complete I dont know what the hash matches could be, and partition table result is listed on two different lines. More important in the ext4 recover from a fsck, which i have often with coreboot + seabios (i my many trials). I dont had a single fsck with stock bios, so it must be somehow related to seabios or coreboot, at least i think so. After that, i burned a new coreboot bios with latest prebuild seabios payload, and changed only two settings with "make menuconfig": I set => "Use VGA console once initialized" i was hoping not be blind anymore during boot up (before kernel booting) unset => "GDB debugging support" i guessed that boot speed would be increasing, but it was not the case. I changed then 2-3 things in file /etc/default/grub (the 'update-grub'), to see serial outout during booting and also after booting: GRUB_CMDLINE_LINUX_DEFAULT="text console=tty0 console=ttyS0,115200n8" GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1" The text part was to avoid a graphical start of Ubuntu, but computer is still freezing, and the rest if for serial output. I captured the serial output from another computer with null modem cable and 'screen -L /dev/ttyS0', which produced the screenlog file that i attached i this email. I also created the file "/etc/init/ttyS0.conf" with following content, to try to be able to login over serial, just for testing (which is working fine with stock bios): # ttyS0 - getty # # This service maintains a getty on ttyS0 from the point the system is # started until it is shut down again. start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /sbin/getty -L 115200 ttyS0 vt102 But, computer is freezing after message about apparmor stuff (dont know if it is related or not). Login over serial port is not possible, computer completely frozen. So i have a few questions again: - what does actually the option 'Use CMOS for configuration values' ? - if y press F12 (what i didnt so far) and may be change some settings (i dont know if it is possible), will it overwrite my current cmos config, which i would like to keep as it is properly configure for my stock bios ? - should i may be try another linux distribution, like Debian to check if my problem is kernel related, or even boot from a ext3 FS ? Thank you for your help. Fr?d?ric PS: Now i know why the seabios or coreboot takes longer to boot, because of RAM cleaning (thank's to serial output), and of course i made a 'make clean with rm -rf build nad rm .option before building new coreboot with prebuilt seabios. ________________________________________ De : Myles Watson [mylesgw at gmail.com] Date d'envoi : vendredi 17 septembre 2010 17:08 ? : STEMMELIN, FREDERIC (FREDERIC)** CTR ** Cc : coreboot at coreboot.org Objet : RE: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing > > GRUB_CMDLIN_LINUX_DEFAULT="verbose" in /etc/default/grub and "sudo > update-> grub" > I will do it, with original VGA bios and prebuild seabios too. Since there's no built-in video card on the s2895, there shouldn't be a VGA BIOS for the board. I was thinking of the s2892. My s2895 boots fine, so when you get a log & send it to the list, we should be able to figure out what's going wrong pretty easily. Thanks, Myles -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: screenlog_17092010_coreboot_seabios_prebuilt_text_mode.txt URL: From svn at coreboot.org Fri Sep 17 23:38:41 2010 From: svn at coreboot.org (repository service) Date: Fri, 17 Sep 2010 23:38:41 +0200 Subject: [coreboot] [commit] r5818 - trunk/src/include/cpu/x86 Message-ID: Author: mjones Date: Fri Sep 17 23:38:40 2010 New Revision: 5818 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5818 Log: AMD Fam10 code breaks with gcc 4.5.0. Root cause: After function STOP_CAR_AND_CPU disables cache as ram, the cache as ram stack can no longer be used. Called functions must be inlined to avoid stack usage. Also, the compiler must keep local variables register based and not allocated them from the stack. With gcc 4.5.0, some functions declared as inline are not being inlined. This patch forces these functions to always be inlined by adding the qualifier __attribute__((always_inline)) to their declaration. Signed-off-by: Scott Duplichan Acked-by: Stefan Reinauer Acked-by: Marc Jones Modified: trunk/src/include/cpu/x86/cache.h trunk/src/include/cpu/x86/msr.h Modified: trunk/src/include/cpu/x86/cache.h ============================================================================== --- trunk/src/include/cpu/x86/cache.h Fri Sep 17 02:13:52 2010 (r5817) +++ trunk/src/include/cpu/x86/cache.h Fri Sep 17 23:38:40 2010 (r5818) @@ -74,7 +74,17 @@ asm volatile("invd" ::: "memory"); } -static inline void enable_cache(void) +/* The following functions require the always_inline due to AMD + * function STOP_CAR_AND_CPU that disables cache as + * ram, the cache as ram stack can no longer be used. Called + * functions must be inlined to avoid stack usage. Also, the + * compiler must keep local variables register based and not + * allocated them from the stack. With gcc 4.5.0, some functions + * declared as inline are not being inlined. This patch forces + * these functions to always be inlined by adding the qualifier + * __attribute__((always_inline)) to their declaration. + */ +static inline __attribute__((always_inline)) void enable_cache(void) { unsigned long cr0; cr0 = read_cr0(); @@ -82,7 +92,7 @@ write_cr0(cr0); } -static inline void disable_cache(void) +static inline __attribute__((always_inline)) void disable_cache(void) { /* Disable and write back the cache */ unsigned long cr0; Modified: trunk/src/include/cpu/x86/msr.h ============================================================================== --- trunk/src/include/cpu/x86/msr.h Fri Sep 17 02:13:52 2010 (r5817) +++ trunk/src/include/cpu/x86/msr.h Fri Sep 17 23:38:40 2010 (r5818) @@ -29,7 +29,17 @@ msr_t msr; } msrinit_t; -static inline msr_t rdmsr(unsigned index) +/* The following functions require the always_inline due to AMD + * function STOP_CAR_AND_CPU that disables cache as + * ram, the cache as ram stack can no longer be used. Called + * functions must be inlined to avoid stack usage. Also, the + * compiler must keep local variables register based and not + * allocated them from the stack. With gcc 4.5.0, some functions + * declared as inline are not being inlined. This patch forces + * these functions to always be inlined by adding the qualifier + * __attribute__((always_inline)) to their declaration. + */ +static inline __attribute__((always_inline)) msr_t rdmsr(unsigned index) { msr_t result; __asm__ __volatile__ ( @@ -40,7 +50,7 @@ return result; } -static inline void wrmsr(unsigned index, msr_t msr) +static inline __attribute__((always_inline)) void wrmsr(unsigned index, msr_t msr) { __asm__ __volatile__ ( "wrmsr" From marcj303 at gmail.com Fri Sep 17 23:39:36 2010 From: marcj303 at gmail.com (Marc Jones) Date: Fri, 17 Sep 2010 15:39:36 -0600 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: <4C84BC6F.3080601@coresystems.de> References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <2F6225DCDF084C9D8CFD78A8C6B10AA3@m3a78> <4C84BC6F.3080601@coresystems.de> Message-ID: On Mon, Sep 6, 2010 at 4:03 AM, Stefan Reinauer wrote: > ?On 9/6/10 5:32 AM, Scott Duplichan wrote: >> Resend: one more attempt to get this patch right. The previous >> submission included the patch as an attachement. The attachment >> contained Windows-style line endings. The attachment is missing >> from the mailing list archive: "A non-text attachment was scrubbed". >> http://www.coreboot.org/pipermail/coreboot/2010-September/060090.html > The patch is there, just click on the link below the message. > (Unfortunately with a wrong name) >> Root cause: After function STOP_CAR_AND_CPU disables cache as >> ram, the cache as ram stack can no longer be used. Called >> functions must be inlined to avoid stack usage. Also, the >> compiler must keep local variables register based and not >> allocated them from the stack. With gcc 4.5.0, some functions >> declared as inline are not being inlined. This patch forces >> these functions to always be inlined by adding the qualifier >> __attribute__((always_inline)) to their declaration. > > I think this explanation should go into the two files that get the > always_inline attributes so people looking at this code 3ys (or months) > from now know why it was done this way. >> Update: Still no test reports for real hardware are available. >> If we cannot get this change tested on real hardware, I suggest >> we conditionally compile in only if gcc 4.5.0 or later is used. > I think it's safe to use it as is, though I don't have a Tilapia to test > it on. > >> Signed-off-by: Scott Duplichan > > With the explanation above added to each of the two files, this is > > Acked-by: Stefan Reinauer > > However, I think we should additionally look at "fixing" AMD's CAR code > to not call C functions with neither CAR or RAM backing them. I reworked > all CAR code to behave like that a while ago (ie. , but the AMD code was > considerably more complex . The complexity of the code also brings along > some bugs that currently need workarounds[1]. A proper fix for this > would be nice, but it's hard to determine what's wrong with the current > code. Should you have some insights on this, please share! > > Stefan Yes, this is "wrong" since memory is working at this point, I don't see why we don't do a stack switch and then disable CAR. I added comments to the code to explain why they require the new attribute. r5818 Marc -- http://se-eng.com From peter at stuge.se Fri Sep 17 23:51:37 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 17 Sep 2010 23:51:37 +0200 Subject: [coreboot] RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <20100917215137.20969.qmail@stuge.se> STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > PCI: 40:00.0 [1022/7450] bus ops > PCI: 40:00.0 [1022/7450] enabled Bus 40? > PCI: 41: 133MHz PCI-X > PCI: 42: 100MHz PCI-X And 41 and 42. > PCI: 80:00.0 [10de/005e] ops > PCI: 80:00.0 [10de/005e] enabled And 80? It's far between them.. Maybe things should work anyway, but still. > [ 1.565157] powernow-k8: Found 2 AMD Opteron(tm) Processor 256 processors (2 cpu cores) (version 2.20.00) > [ 1.574860] ACPI Warning for \_PR_.CPU0._PSS: Return Package has no elements (empty) (20090903/nspredef-433) > [ 1.584865] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. > [ 1.584868] [Firmware Bug]: powernow-k8: Try again with latest BIOS. Another problem.. Linux doesn't like our ACPI for powersaving, but this should really only mean that powersaving is disabled, so should not cause any problem with booting. //Peter From frederic.stemmelin at alcatel-lucent.com Sat Sep 18 00:14:58 2010 From: frederic.stemmelin at alcatel-lucent.com (STEMMELIN, FREDERIC (FREDERIC)** CTR **) Date: Sat, 18 Sep 2010 00:14:58 +0200 Subject: [coreboot] RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <20100917215137.20969.qmail@stuge.se> References: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>, <20100917215137.20969.qmail@stuge.se> Message-ID: <857948A3D868694688C70287BBC718140F28B6C8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In the mean time i checked RAM with memtest86+ v4.0 provided with Ubuntu 10.04, and it is not working at all, 0kb RAM detected with coreboot+seabios. On tyan bios all the RAM is detected properly (no errors on tests too). I have 4*2GB ECC RAM from crucial, dont remember ref, can probably find it somewhere. It put both memtest86 results as attachements. I dont know if memtest86+ v4.0 should work or not with seabios, or if i should use memtest payload instead (v3.5 or v4.0 ?) ________________________________________ De : coreboot-bounces at coreboot.org [coreboot-bounces at coreboot.org] de la part de Peter Stuge [peter at stuge.se] Date d'envoi : vendredi 17 septembre 2010 23:51 ? : coreboot at coreboot.org Objet : Re: [coreboot] RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > PCI: 40:00.0 [1022/7450] bus ops > PCI: 40:00.0 [1022/7450] enabled Bus 40? > PCI: 41: 133MHz PCI-X > PCI: 42: 100MHz PCI-X And 41 and 42. > PCI: 80:00.0 [10de/005e] ops > PCI: 80:00.0 [10de/005e] enabled And 80? It's far between them.. Maybe things should work anyway, but still. > [ 1.565157] powernow-k8: Found 2 AMD Opteron(tm) Processor 256 processors (2 cpu cores) (version 2.20.00) > [ 1.574860] ACPI Warning for \_PR_.CPU0._PSS: Return Package has no elements (empty) (20090903/nspredef-433) > [ 1.584865] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. > [ 1.584868] [Firmware Bug]: powernow-k8: Try again with latest BIOS. Another problem.. Linux doesn't like our ACPI for powersaving, but this should really only mean that powersaving is disabled, so should not cause any problem with booting. //Peter -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memtest_tyan_bios_106.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memtest_coreboot-seabios.txt URL: From scott at notabs.org Sat Sep 18 00:40:22 2010 From: scott at notabs.org (Scott Duplichan) Date: Fri, 17 Sep 2010 17:40:22 -0500 Subject: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' In-Reply-To: References: <0703EF8685AB4BB091774844213B7DF6@m3a78> <2F6225DCDF084C9D8CFD78A8C6B10AA3@m3a78> <4C84BC6F.3080601@coresystems.de> Message-ID: ]-----Original Message----- ]From: Marc Jones [mailto:marcj303 at gmail.com] ]Sent: Friday, September 17, 2010 04:40 PM ]To: Stefan Reinauer; Frank Vibrans; Scott ]Cc: coreboot at coreboot.org ]Subject: Re: [coreboot] [PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0' ] ]On Mon, Sep 6, 2010 at 4:03 AM, Stefan Reinauer ] wrote: ]> ?On 9/6/10 5:32 AM, Scott Duplichan wrote: ]>> Resend: one more attempt to get this patch right. The previous ]>> submission included the patch as an attachement. The attachment ]>> contained Windows-style line endings. The attachment is missing ]>> from the mailing list archive: "A non-text attachment was scrubbed". ]>> http://www.coreboot.org/pipermail/coreboot/2010-September/060090.html ]> The patch is there, just click on the link below the message. ]> (Unfortunately with a wrong name) ]>> Root cause: After function STOP_CAR_AND_CPU disables cache as ]>> ram, the cache as ram stack can no longer be used. Called ]>> functions must be inlined to avoid stack usage. Also, the ]>> compiler must keep local variables register based and not ]>> allocated them from the stack. With gcc 4.5.0, some functions ]>> declared as inline are not being inlined. This patch forces ]>> these functions to always be inlined by adding the qualifier ]>> __attribute__((always_inline)) to their declaration. ]> ]> I think this explanation should go into the two files that get the ]> always_inline attributes so people looking at this code 3ys (or months) ]> from now know why it was done this way. ]>> Update: Still no test reports for real hardware are available. ]>> If we cannot get this change tested on real hardware, I suggest ]>> we conditionally compile in only if gcc 4.5.0 or later is used. ]> I think it's safe to use it as is, though I don't have a Tilapia to test ]> it on. ]> ]>> Signed-off-by: Scott Duplichan ]> ]> With the explanation above added to each of the two files, this is ]> ]> Acked-by: Stefan Reinauer ]> ]> However, I think we should additionally look at "fixing" AMD's CAR code ]> to not call C functions with neither CAR or RAM backing them. I reworked ]> all CAR code to behave like that a while ago (ie. , but the AMD code was ]> considerably more complex . The complexity of the code also brings along ]> some bugs that currently need workarounds[1]. A proper fix for this ]> would be nice, but it's hard to determine what's wrong with the current ]> code. Should you have some insights on this, please share! ]> ]> Stefan ] ]Yes, this is "wrong" since memory is working at this point, I don't ]see why we don't do a stack switch and then disable CAR. For me, the gcc 4.5.0 crash happens before memory is initialized. It is at the conclusion of the first AP execution, where the APs do fid-vid, microcode patch, etc. The APs must leave their fixed MTRRs setup to map the lower 1MB to DRAM before HLTing, so that startup IPIs can be used to start them later. But DRAM has not been initialized, so a DRAM stack cannot be used. The crash occurs when an AP is making this transition from cache-as-ram MTRRs to startup IPI compatible MTRRs. Thanks, Scott ]I added comments to the code to explain why they require the new attribute. ] ]r5818 ] ]Marc ]-- ]http://se-eng.com From juhe at iki.fi Sat Sep 18 18:23:54 2010 From: juhe at iki.fi (Juhana Helovuo) Date: Sat, 18 Sep 2010 19:23:54 +0300 Subject: [coreboot] [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6C8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> , <20100917215137.20969.qmail@stuge.se> <857948A3D868694688C70287BBC718140F28B6C8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <1284827034.3702.59.camel@bart> On Sat, 2010-09-18 at 00:14 +0200, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > In the mean time i checked RAM with memtest86+ v4.0 provided with > Ubuntu 10.04, and it is not working at all, 0kb RAM detected with > coreboot+seabios. > On tyan bios all the RAM is detected properly (no errors on tests > too). > > I have 4*2GB ECC RAM from crucial, dont remember ref, can probably find it somewhere. Hello, My guess from your memtest86+ printouts is the following: With Tyan BIOS, memtest86+ uses BIOS call "e820" to find out the available RAM. With Coreboot + SeaBIOS, memtes86+ detects that there are Coreboot tables in memory ("LxBIOS"), but for some reason thinks that the table reports 0k memory. This may be because your memtest86+ version does not support Coreboot "high tables", and therefore detects the presence of Coreboot, but cannot read the contents of the table. Coreboot does not implement the e820 interface, but SeaBIOS should have it available. However, when memtest86+ detects that Coreboot is present, it ignores the e820 interface and tries to read the Coreboot tables. I have made a patch for memtest86+ v4.10, which adds better support for Coreboot and also multiboot tables. The patch is not my original work, but a combination of two patches, so the credit belongs to the original authors. Application instructions: * Download memtest86+ v 4.10 sources .tar.gz and untar * Apply patch, e.g. patch -p1 < ../coreboot-v4-and-multiboot-support-for-memtest86+-4.10.patch * Manually rename two files: % mv linuxbios.c coreboot.c % mv linuxbios_tables.h coreboot_tables.h * Build memtest86+ using "make" The build process creates two versions of the memtest86+ binary. "memtest" is multiboot-compatible ELF executable and "memtest.bin" is bootable image like a Linux kernel image. Choosing between these two depends on your boot method: BIOS, Coreboot only, Coreboot+SeaBIOS, or a bootloader. My success with memtest86+ has been rather limited, but maybe this works for you. Best regards, Juhana Helovuo -------------- next part -------------- A non-text attachment was scrubbed... Name: coreboot-v4-and-multiboot-support-for-memtest86+-4.10.patch Type: text/x-patch Size: 28724 bytes Desc: not available URL: From uwe at hermann-uwe.de Sat Sep 18 21:06:38 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 18 Sep 2010 21:06:38 +0200 Subject: [coreboot] [PATCH] Make ASUS P3B-F RAM init actually work by enabling SPD access Message-ID: <20100918190638.GE3256@greenwood> See patch. This fix is brought to you by SerialICE(tm), thanks! Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: v4_asus_p3b_f_raminit_fix.patch Type: text/x-diff Size: 6044 bytes Desc: not available URL: From vidwer at gmail.com Sat Sep 18 23:27:18 2010 From: vidwer at gmail.com (Idwer Vollering) Date: Sat, 18 Sep 2010 23:27:18 +0200 Subject: [coreboot] [PATCH] Make ASUS P3B-F RAM init actually work by enabling SPD access In-Reply-To: <20100918190638.GE3256@greenwood> References: <20100918190638.GE3256@greenwood> Message-ID: 2010/9/18 Uwe Hermann > See patch. > > This fix is brought to you by SerialICE(tm), thanks! > Tested on hardware with an identical southbridge (ASUS P2B rev 1.04), booting doesn't seem to be affected. Acked-by: Idwer Vollering > > Uwe. > -- > http://hermann-uwe.de | http://sigrok.org > http://randomprojects.org | http://unmaintained-free-software.org > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Zheng.Bao at amd.com Sun Sep 19 09:05:19 2010 From: Zheng.Bao at amd.com (Bao, Zheng) Date: Sun, 19 Sep 2010 15:05:19 +0800 Subject: [coreboot] [patch]: AMD DDR3 fix the register name Message-ID: Fix the typo. Field DisAutoRefresh is in DramTimngHi. Signed-off-by: Zheng Bao Index: src/northbridge/amd/amdmct/mct_ddr3/mct_d.c =================================================================== --- src/northbridge/amd/amdmct/mct_ddr3/mct_d.c (revision 5818) +++ src/northbridge/amd/amdmct/mct_ddr3/mct_d.c (working copy) @@ -1220,7 +1220,7 @@ Set_NB32(dev, 0x88 + reg_off, DramTimingLo); /*DCT Timing Low*/ if (pDCTstat->Speed > 4) { - DramTimingLo |= 1 << DisAutoRefresh; + DramTimingHi |= 1 << DisAutoRefresh; } DramTimingHi |= 0x000018FF; Set_NB32(dev, 0x8c + reg_off, DramTimingHi); /*DCT Timing Hi*/ -------------- next part -------------- A non-text attachment was scrubbed... Name: amd_ddr3_fix_register.patch Type: application/octet-stream Size: 645 bytes Desc: amd_ddr3_fix_register.patch URL: From hagigatali at gmail.com Sun Sep 19 13:06:48 2010 From: hagigatali at gmail.com (ali hagigat) Date: Sun, 19 Sep 2010 15:36:48 +0430 Subject: [coreboot] mkelfimage and coreboot.rom!! Message-ID: can i build an elf file from the final coreboot image means coreboot.rom by using mkelfimage tool? Or it is used for Linux kernel only? Thank you to read my message From frederic.stemmelin at alcatel-lucent.com Sun Sep 19 15:35:26 2010 From: frederic.stemmelin at alcatel-lucent.com (STEMMELIN, FREDERIC (FREDERIC)** CTR **) Date: Sun, 19 Sep 2010 15:35:26 +0200 Subject: [coreboot] RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <1284827034.3702.59.camel@bart> References: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> , <20100917215137.20969.qmail@stuge.se> <857948A3D868694688C70287BBC718140F28B6C8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>, <1284827034.3702.59.camel@bart> Message-ID: <857948A3D868694688C70287BBC718140F28B6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Thank you very much for your help, in the mean time i have very goods news, yes my Tyan s2895 is BOOTING now :) I found what was the origin of teh crashes after i was trying to boot a debian livecd with "noapic noapm" and such other things as kernel parameters (i didnt change the defaut settings). I saw a kerneloops on screen after kernel was trying to set a IRQ for the intel network card, with error -39 (or -38 i dont remember exactly). Now after remowing my Intel PRO1000MT server network card from PCI-X slot 6, i can boot without any problems :) Memtest86+ v 4.0 is still not working, but less important now that i am sure my problem was not RAM related :) I will anyway try your instructions with patchs and report back. By the way, i was not able to compile following with coreboot v4: - corinfo => compile errors - tint => same - memtest as payload => same I tried several things like changing Makefile, but it didnt work as i dont understand what it doest exactly. Thank's for your support. PS: If needed i can provide all informations what mayy necessary to find the PCI-X bug with teh network card, if you wish. ________________________________________ De : Juhana Helovuo [juhe at iki.fi] Date d'envoi : samedi 18 septembre 2010 18:23 ? : STEMMELIN, FREDERIC (FREDERIC)** CTR ** Cc : coreboot at coreboot.org Objet : [PATCH] Re: [coreboot] RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing On Sat, 2010-09-18 at 00:14 +0200, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > In the mean time i checked RAM with memtest86+ v4.0 provided with > Ubuntu 10.04, and it is not working at all, 0kb RAM detected with > coreboot+seabios. > On tyan bios all the RAM is detected properly (no errors on tests > too). > > I have 4*2GB ECC RAM from crucial, dont remember ref, can probably find it somewhere. Hello, My guess from your memtest86+ printouts is the following: With Tyan BIOS, memtest86+ uses BIOS call "e820" to find out the available RAM. With Coreboot + SeaBIOS, memtes86+ detects that there are Coreboot tables in memory ("LxBIOS"), but for some reason thinks that the table reports 0k memory. This may be because your memtest86+ version does not support Coreboot "high tables", and therefore detects the presence of Coreboot, but cannot read the contents of the table. Coreboot does not implement the e820 interface, but SeaBIOS should have it available. However, when memtest86+ detects that Coreboot is present, it ignores the e820 interface and tries to read the Coreboot tables. I have made a patch for memtest86+ v4.10, which adds better support for Coreboot and also multiboot tables. The patch is not my original work, but a combination of two patches, so the credit belongs to the original authors. Application instructions: * Download memtest86+ v 4.10 sources .tar.gz and untar * Apply patch, e.g. patch -p1 < ../coreboot-v4-and-multiboot-support-for-memtest86+-4.10.patch * Manually rename two files: % mv linuxbios.c coreboot.c % mv linuxbios_tables.h coreboot_tables.h * Build memtest86+ using "make" The build process creates two versions of the memtest86+ binary. "memtest" is multiboot-compatible ELF executable and "memtest.bin" is bootable image like a Linux kernel image. Choosing between these two depends on your boot method: BIOS, Coreboot only, Coreboot+SeaBIOS, or a bootloader. My success with memtest86+ has been rather limited, but maybe this works for you. Best regards, Juhana Helovuo From peter at stuge.se Sun Sep 19 16:32:05 2010 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Sep 2010 16:32:05 +0200 Subject: [coreboot] mkelfimage and coreboot.rom!! In-Reply-To: References: Message-ID: <20100919143205.24330.qmail@stuge.se> ali hagigat wrote: > can i build an elf file from the final coreboot image means > coreboot.rom by using mkelfimage tool? Maybe, but the elf file is useless. coreboot.rom is what you flash. > Or it is used for Linux kernel only? Maybe it has some other uses, but this is the primary use. Did you already read http://coreboot.org/Mkelfimage and search on coreboot.org after mkelfimage to see which other pages mention it? //Peter From frederic.stemmelin at alcatel-lucent.com Sun Sep 19 16:16:14 2010 From: frederic.stemmelin at alcatel-lucent.com (STEMMELIN, FREDERIC (FREDERIC)** CTR **) Date: Sun, 19 Sep 2010 16:16:14 +0200 Subject: [coreboot] RE : RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> , <20100917215137.20969.qmail@stuge.se> <857948A3D868694688C70287BBC718140F28B6C8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>, <1284827034.3702.59.camel@bart>, <857948A3D868694688C70287BBC718140F28B6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <857948A3D868694688C70287BBC718140F28B6CB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Now here are my results with the patched Memtest86+ version 4.1. Check the attached files. As you can see it is far way better, even if it is not working, at least i can see that the memory is recognized correctly, wich is pretty good. Memtest86+ is still crashing on test starting (after 3%), but really not important so far, as long as my computer does not crash in normal operation mode. Another question, what may the consequences be not supporting e820 in bios, for other OS like windows for example ? Does another OS use this feature e820 ? Cheers Fr?d?ric ________________________________________ De : coreboot-bounces at coreboot.org [coreboot-bounces at coreboot.org] de la part de STEMMELIN, FREDERIC (FREDERIC)** CTR ** [frederic.stemmelin at alcatel-lucent.com] Date d'envoi : dimanche 19 septembre 2010 15:35 ? : Juhana Helovuo Cc : coreboot at coreboot.org Objet : [coreboot] RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing Thank you very much for your help, in the mean time i have very goods news, yes my Tyan s2895 is BOOTING now :) I found what was the origin of teh crashes after i was trying to boot a debian livecd with "noapic noapm" and such other things as kernel parameters (i didnt change the defaut settings). I saw a kerneloops on screen after kernel was trying to set a IRQ for the intel network card, with error -39 (or -38 i dont remember exactly). Now after remowing my Intel PRO1000MT server network card from PCI-X slot 6, i can boot without any problems :) Memtest86+ v 4.0 is still not working, but less important now that i am sure my problem was not RAM related :) I will anyway try your instructions with patchs and report back. By the way, i was not able to compile following with coreboot v4: - corinfo => compile errors - tint => same - memtest as payload => same I tried several things like changing Makefile, but it didnt work as i dont understand what it doest exactly. Thank's for your support. PS: If needed i can provide all informations what mayy necessary to find the PCI-X bug with teh network card, if you wish. ________________________________________ De : Juhana Helovuo [juhe at iki.fi] Date d'envoi : samedi 18 septembre 2010 18:23 ? : STEMMELIN, FREDERIC (FREDERIC)** CTR ** Cc : coreboot at coreboot.org Objet : [PATCH] Re: [coreboot] RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing On Sat, 2010-09-18 at 00:14 +0200, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > In the mean time i checked RAM with memtest86+ v4.0 provided with > Ubuntu 10.04, and it is not working at all, 0kb RAM detected with > coreboot+seabios. > On tyan bios all the RAM is detected properly (no errors on tests > too). > > I have 4*2GB ECC RAM from crucial, dont remember ref, can probably find it somewhere. Hello, My guess from your memtest86+ printouts is the following: With Tyan BIOS, memtest86+ uses BIOS call "e820" to find out the available RAM. With Coreboot + SeaBIOS, memtes86+ detects that there are Coreboot tables in memory ("LxBIOS"), but for some reason thinks that the table reports 0k memory. This may be because your memtest86+ version does not support Coreboot "high tables", and therefore detects the presence of Coreboot, but cannot read the contents of the table. Coreboot does not implement the e820 interface, but SeaBIOS should have it available. However, when memtest86+ detects that Coreboot is present, it ignores the e820 interface and tries to read the Coreboot tables. I have made a patch for memtest86+ v4.10, which adds better support for Coreboot and also multiboot tables. The patch is not my original work, but a combination of two patches, so the credit belongs to the original authors. Application instructions: * Download memtest86+ v 4.10 sources .tar.gz and untar * Apply patch, e.g. patch -p1 < ../coreboot-v4-and-multiboot-support-for-memtest86+-4.10.patch * Manually rename two files: % mv linuxbios.c coreboot.c % mv linuxbios_tables.h coreboot_tables.h * Build memtest86+ using "make" The build process creates two versions of the memtest86+ binary. "memtest" is multiboot-compatible ELF executable and "memtest.bin" is bootable image like a Linux kernel image. Choosing between these two depends on your boot method: BIOS, Coreboot only, Coreboot+SeaBIOS, or a bootloader. My success with memtest86+ has been rather limited, but maybe this works for you. Best regards, Juhana Helovuo -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memtest_tyan_bios_106.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patched_memtest_v_4-1_coreboot_seabios_result.txt URL: From peter at stuge.se Sun Sep 19 16:48:43 2010 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Sep 2010 16:48:43 +0200 Subject: [coreboot] RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6CB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <857948A3D868694688C70287BBC718140F28B6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20100917215137.20969.qmail@stuge.se> <857948A3D868694688C70287BBC718140F28B6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <857948A3D868694688C70287BBC718140F28B6CB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20100917215137.20969.qmail@stuge.se> <1284827034.3702.59.camel@bart> <857948A3D868694688C70287BBC718140F28B6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: <20100919144843.26787.qmail@stuge.se> STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > Thank you very much for your help, in the mean time i have very > goods news, yes my Tyan s2895 is BOOTING now :) Nice, but.. > kerneloops on screen after kernel was trying to set a IRQ for the > intel network card, with error -39 (or -38 i dont remember > exactly). > > Now after remowing my Intel PRO1000MT server network card from > PCI-X slot 6, i can boot without any problems :) ..the PCI-X should also work. I think it may be good to investigate why it gets such a high bus number. > Now here are my results with the patched Memtest86+ version 4.1. > Check the attached files. > > As you can see it is far way better, even if it is not working, at > least i can see that the memory is recognized correctly, wich is > pretty good. > Memtest86+ is still crashing on test starting (after 3%), but > really not important so far, as long as my computer does not crash > in normal operation mode. I think it is important. memtest should not crash, if it does, then I don't think everything is right with the memory setup, and that will lead to your computer crashing, it will just take some time; until you have started filling the RAM with stuff that you don't want to lose. > Another question, what may the consequences be not supporting e820 > in bios, *Please* remember that coreboot is not a BIOS. e820 memory maps are a BIOS-specific interface, and coreboot does not provide this. coreboot still provides a memory map, within the coreboot tables. SeaBIOS provides BIOS interfaces, among other things it implements "e820" memory maps, based on the coreboot tables memory map. > for other OS like windows for example ? Does another OS use this > feature e820 ? Nearly every OS on the PC so far assumes that the 30-year old BIOS interface will be present. Because systems do not understand the coreboot memory map format they require legacy BIOS compatibility and can only start using SeaBIOS. In a way this is also true for Linux, but mkelfImage helps bridge the gap so that no BIOS is needed. Obviously everything that uses libpayload is also free of BIOS requirements. memtest86 understands both e820 and coreboot tables, but the coreboot support in memtest86 was not updated to interpret the latest version of coreboot tables, or rather the specific high tables feature. So an unpatched memtest86 will notice that coreboot is available even if you have SeaBIOS, it just does not know how to correctly interpret the coreboot tables. //Peter From svn at coreboot.org Sun Sep 19 23:12:06 2010 From: svn at coreboot.org (repository service) Date: Sun, 19 Sep 2010 23:12:06 +0200 Subject: [coreboot] [commit] r5819 - in trunk/src: mainboard/asus/p3b-f southbridge/intel/i82371eb Message-ID: Author: uwe Date: Sun Sep 19 23:12:05 2010 New Revision: 5819 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5819 Log: Make ASUS P3B-F RAM init actually work by enabling SPD access. On this board all reads from SPD return 0xff by default, there's a custom GPIO fiddling needed to enable access to the SPD SMBus offsets at 0x50-0x53. While coreboot actually sort of booted sometimes before r5193, that was just sheer luck as the RAM init was hardcoded in certain ways. Since the proper, more heavily SPD-based RAM init the brokenness of the ASUS P3B-F RAM init was becoming visible. This patch uses GPIOs to enable access to the SPD SMBus offsets, and resets the GPIOs again after RAM init (this is needed to allow for lm-sensors to work, for example). Tested successfully on hardware. Signed-off-by: Uwe Hermann Acked-by: Idwer Vollering Added: trunk/src/southbridge/intel/i82371eb/i82371eb_early_pm.c Modified: trunk/src/mainboard/asus/p3b-f/romstage.c trunk/src/southbridge/intel/i82371eb/i82371eb.h trunk/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c Modified: trunk/src/mainboard/asus/p3b-f/romstage.c ============================================================================== --- trunk/src/mainboard/asus/p3b-f/romstage.c Fri Sep 17 23:38:40 2010 (r5818) +++ trunk/src/mainboard/asus/p3b-f/romstage.c Sun Sep 19 23:12:05 2010 (r5819) @@ -29,6 +29,7 @@ #include "lib/ramtest.c" #include "southbridge/intel/i82371eb/i82371eb_enable_rom.c" #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c" +#include "southbridge/intel/i82371eb/i82371eb_early_pm.c" #include "northbridge/intel/i440bx/raminit.h" #include "lib/debug.c" #include "pc80/udelay_io.c" @@ -49,6 +50,37 @@ #include "northbridge/intel/i440bx/raminit.c" #include "northbridge/intel/i440bx/debug.c" +/* + * ASUS P3B-F specific SPD enable magic. + * + * Setting the byte at offset 0x37 in the PM I/O space to 0x6f will make the + * board DIMMs accessible at SMBus/SPD offsets 0x50-0x53. Per default the SPD + * offsets 0x50-0x53 are _not_ readable (all SPD reads will return 0xff) which + * will make RAM init fail. + * + * Tested values for PM I/O offset 0x37: + * 0x67: 11 00 111: Only SMBus/I2C offsets 0x48/0x49/0x2d accessible + * 0x6f: 11 01 111: Only SMBus/I2C offsets 0x50-0x53 (SPD) accessible + * 0x77: 11 10 111: Only SMBus/I2C offset 0x69 accessible + * + * PM I/O space offset 0x37 is GPOREG[31:24], i.e. it controls the GPIOs + * 24-30 of the PIIX4E (bit 31 is reserved). Thus, GPIOs 27 and 28 + * control which SMBus/I2C offsets can be accessed. + */ +static void enable_spd(void) +{ + outb(0x6f, PM_IO_BASE + 0x37); +} + +/* + * Disable SPD access after RAM init to allow access to SMBus/I2C offsets + * 0x48/0x49/0x2d, which is required e.g. by lm-sensors. + */ +static void disable_spd(void) +{ + outb(0x67, PM_IO_BASE + 0x37); +} + static void main(unsigned long bist) { if (bist == 0) @@ -64,10 +96,16 @@ i82371eb_enable_rom(PCI_DEV(0, 4, 0)); /* ISA bridge is 00:04.0. */ enable_smbus(); + enable_pm(); + + enable_spd(); + /* dump_spd_registers(); */ sdram_set_registers(); sdram_set_spd_registers(); sdram_enable(); /* ram_check(0, 640 * 1024); */ + + disable_spd(); } Modified: trunk/src/southbridge/intel/i82371eb/i82371eb.h ============================================================================== --- trunk/src/southbridge/intel/i82371eb/i82371eb.h Fri Sep 17 23:38:40 2010 (r5818) +++ trunk/src/southbridge/intel/i82371eb/i82371eb.h Sun Sep 19 23:12:05 2010 (r5819) @@ -72,5 +72,6 @@ #define SSDE1 (1 << 3) /* Secondary Drive 1 UDMA/33 */ #define ISA (1 << 0) /* Select ISA */ #define EIO (0 << 0) /* Select EIO */ +#define PMIOSE (1 << 0) /* PM I/O Space Enable */ #endif /* SOUTHBRIDGE_INTEL_I82371EB_I82371EB_H */ Added: trunk/src/southbridge/intel/i82371eb/i82371eb_early_pm.c ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/src/southbridge/intel/i82371eb/i82371eb_early_pm.c Sun Sep 19 23:12:05 2010 (r5819) @@ -0,0 +1,53 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2010 Uwe Hermann + * + * 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 + */ + +#include +#include +#include "i82371eb.h" + +#define PM_IO_BASE 0xe400 + +static void enable_pm(void) +{ + device_t dev; + u8 reg8; + u16 reg16; + + /* Check for SMBus/PM device PCI ID on the 82371AB/EB/MB. */ + dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_INTEL, + PCI_DEVICE_ID_INTEL_82371AB_SMB_ACPI), 0); + + if (dev == PCI_DEV_INVALID) + die("SMBus/PM controller not found\n"); + + /* Set the PM I/O base. */ + pci_write_config32(dev, PMBA, PM_IO_BASE | 1); + + /* Enable access to the PM I/O space. */ + reg16 = pci_read_config16(dev, PCI_COMMAND); + reg16 |= PCI_COMMAND_IO; + pci_write_config16(dev, PCI_COMMAND, reg16); + + /* PM I/O Space Enable (PMIOSE). */ + reg8 = pci_read_config8(dev, PMREGMISC); + reg8 |= PMIOSE; + pci_write_config8(dev, PMREGMISC, reg8); +} + Modified: trunk/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c ============================================================================== --- trunk/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c Fri Sep 17 23:38:40 2010 (r5818) +++ trunk/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c Sun Sep 19 23:12:05 2010 (r5819) @@ -33,14 +33,12 @@ u8 reg8; u16 reg16; - /* Check for SMBus device PCI ID on the 82371AB/EB/MB. */ + /* Check for SMBus/PM device PCI ID on the 82371AB/EB/MB. */ dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_SMB_ACPI), 0); if (dev == PCI_DEV_INVALID) - die("SMBus controller not found\n"); - - print_spew("SMBus controller enabled\n"); + die("SMBus/PM controller not found\n"); /* Set the SMBus I/O base. */ pci_write_config32(dev, SMBBA, SMBUS_IO_BASE | 1); From uwe at hermann-uwe.de Sun Sep 19 23:10:35 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 19 Sep 2010 23:10:35 +0200 Subject: [coreboot] [PATCH] Make ASUS P3B-F RAM init actually work by enabling SPD access In-Reply-To: References: <20100918190638.GE3256@greenwood> Message-ID: <20100919211035.GE6119@greenwood> On Sat, Sep 18, 2010 at 11:27:18PM +0200, Idwer Vollering wrote: > 2010/9/18 Uwe Hermann > > > See patch. > > > > This fix is brought to you by SerialICE(tm), thanks! > > > > Tested on hardware with an identical southbridge (ASUS P2B rev 1.04), > booting doesn't seem to be affected. > > Acked-by: Idwer Vollering Thanks, r5819. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From uwe at hermann-uwe.de Mon Sep 20 00:47:53 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 20 Sep 2010 00:47:53 +0200 Subject: [coreboot] Fwd: [patch] tint payload update In-Reply-To: References: <20100915185511.6788.qmail@stuge.se> <20100915210916.25244.qmail@stuge.se> Message-ID: <20100919224753.GF3256@greenwood> On Thu, Sep 16, 2010 at 03:37:24PM -0600, Marc Jones wrote: > On Wed, Sep 15, 2010 at 3:09 PM, Peter Stuge wrote: > > Marc Jones wrote: > >> > As for the build things, can we not get around stuffing all of that > >> > into each payload? > >> > >> What do you mean? It seems to me that we want each payload > >> responsible for building its own version of libpayload. > > > > I hadn't thought of that! Do we? Interesting. > > > > In a way it makes sense because different payloads need different > > parts of libpayload. But thinking of it as a replacement for glibc or > > at least crt0 then it isn't so nice to have more than one. This is > > how I've always thought of it until now. There are pros and cons to both variants, but I think we cannot make a fully generic libpayload build that gets installed somewhere and then used by multiple payloads directly. We could drop most "Add support for xyz" kconfig options from libpayload that simply add new functions to the API and just always compile them in directly, and let the linker do its magic to only link in those functions the respective payloads actually uses. This is possible (but not yet in the Makefiles I think). However, there are various options (and more will follow) that modify the _behavior_ of libpayload functions thus making it impossible to satisfy all possible payloads from one libpayload build. Example: There's a kconfig option which decides whether libpayload printf()/putchar() etc. should print to both serial and VGA or only one of them. The putchar() function is always compiled in, but it's behaviour is different. Another example: Some boards (VIA I think) need different CMOS/NVRAM config port locations (0x72/0x73 vs. 0x74/0x75). And there are others. So I think one libpayload build/checkout per payload will be indeed required usually. > > But ok, say we want local libpayload per payload, then I think we > > should still try to simplify things. Yes, definately. > Updating the wiki now. Marc, can you please add the full build instructions to the wiki page, including how and where libpayload should be checked out (or "svn export"ed) relative to tint, whether or not libpayload should use the "make install" step before building tint etc. etc. The current code in svn plus wiki instructions didn't work for me, various issues it seems. First the "libpayloadbin" is never found (if you do "make install" in the libpayload dir it installs into an "install" subdir of the libpayload dir currently. Also, in some situations lpgcc yields errors as $CC seems to be not set or similar (probably due to incorrect placement of the libpayload dir?) Maybe it's simpler to just assume a full coreboot checkout for building payloads per default? I.e. in payloads/external/tint, we assume a ../../libpayload to be there and contain a built libpayload per default? Of course, there should be an option to override this and build a payload by itself with only a libpayload checkout (without the full coreboot checkout). Thanks, Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org From buurin at gmail.com Mon Sep 20 02:52:51 2010 From: buurin at gmail.com (Keith Hui) Date: Sun, 19 Sep 2010 20:52:51 -0400 Subject: [coreboot] [PATCH] Make ASUS P3B-F RAM init actually work by enabling SPD access Message-ID: > > Message: 1 > Date: Sat, 18 Sep 2010 21:06:38 +0200 > From: Uwe Hermann > To: coreboot at coreboot.org > Subject: [coreboot] [PATCH] Make ASUS P3B-F RAM init actually work by > ? ? ? ?enabling SPD access > Message-ID: <20100918190638.GE3256 at greenwood> > Content-Type: text/plain; charset="us-ascii" > > See patch. > > This fix is brought to you by SerialICE(tm), thanks! > > > Uwe. > -- > http://hermann-uwe.de ? ? | http://sigrok.org > http://randomprojects.org | http://unmaintained-free-software.org > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: v4_asus_p3b_f_raminit_fix.patch > Type: text/x-diff > Size: 6044 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 2 > Date: Sat, 18 Sep 2010 23:27:18 +0200 > From: Idwer Vollering > To: Uwe Hermann > Cc: coreboot at coreboot.org > Subject: Re: [coreboot] [PATCH] Make ASUS P3B-F RAM init actually work > ? ? ? ?by enabling SPD access > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset="utf-8" > > 2010/9/18 Uwe Hermann > >> See patch. >> >> This fix is brought to you by SerialICE(tm), thanks! >> > > Tested on hardware with an identical southbridge (ASUS P2B rev 1.04), > booting doesn't seem to be affected. > > Acked-by: Idwer Vollering > Great. Finally some news I can use (besides someone getting M4A785-M supported which may give me a headstart on mine - M4A785TD-M) Great. So we have no P2B regression and with a 256MB stick on DIMM0 I managed to boot into the Slackware install I have been using to test coreboot, with 256MB recognized as usable. But. when I tried this patch, I don't know if it's something else, when I added an 128MB stick in DIMM2 the boot process hung at/after the vga bios of my ATI Rage 2C (POST shows 0xfe). Also I'm not getting any serial output. I'm sure I didn't change my Kconfig from before which has always had serial output enabled. From sahil at ohava.com Mon Sep 20 05:26:11 2010 From: sahil at ohava.com (Sahil Sinha) Date: Sun, 19 Sep 2010 23:26:11 -0400 Subject: [coreboot] ohava laptop coreboot Message-ID: I spoke with someone in the IRC to send this here, I offered free hardware for a port of coreboot to this machine. Sahil Sinha Ohava Computers (703) 887-1032 www.ohava.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ohavacoreboot.tar.gz Type: application/x-gzip Size: 28126 bytes Desc: not available URL: From benbarszcz at gmail.com Mon Sep 20 12:25:58 2010 From: benbarszcz at gmail.com (BeBa) Date: Mon, 20 Sep 2010 12:25:58 +0200 Subject: [coreboot] opinion on ATC-6220? Message-ID: <20100920122558.5ce87e7a@dhcppc0> I can buy an ATC-6220 motherboard at an auction. What is its status vs coreboot? Is it working very well? How many components work? thank you for any inforamation BeBA From stefan.reinauer at coresystems.de Mon Sep 20 12:41:40 2010 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Mon, 20 Sep 2010 12:41:40 +0200 Subject: [coreboot] ohava laptop coreboot In-Reply-To: References: Message-ID: <4C973A64.6@coresystems.de> On 9/20/10 5:26 AM, Sahil Sinha wrote: > I spoke with someone in the IRC to send this here, I offered free > hardware for a port of coreboot to this machine. Can you also provide the necessary RS-NDAed Intel data sheets for the chipset? (I.e. not the stuff on the public web page) Stefan From sahil at ohava.com Mon Sep 20 12:57:02 2010 From: sahil at ohava.com (Sahil Sinha) Date: Mon, 20 Sep 2010 06:57:02 -0400 Subject: [coreboot] ohava laptop coreboot In-Reply-To: <4C973A64.6@coresystems.de> References: <4C973A64.6@coresystems.de> Message-ID: Stefan, How would I go about doing that? Do I need to request it from the manufacturer? Sahil Sinha Ohava Computers (703) 887-1032 www.ohava.com On Mon, Sep 20, 2010 at 6:41 AM, Stefan Reinauer < stefan.reinauer at coresystems.de> wrote: > On 9/20/10 5:26 AM, Sahil Sinha wrote: > >> I spoke with someone in the IRC to send this here, I offered free hardware >> for a port of coreboot to this machine. >> > Can you also provide the necessary RS-NDAed Intel data sheets for the > chipset? (I.e. not the stuff on the public web page) > > Stefan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at coreboot.org Mon Sep 20 16:00:03 2010 From: svn at coreboot.org (coreboot tracker) Date: Mon, 20 Sep 2010 16:00:03 +0200 Subject: [coreboot] Trac reminder: list of new ticket(s) Message-ID: An HTML attachment was scrubbed... URL: From mylesgw at gmail.com Mon Sep 20 16:59:54 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 20 Sep 2010 08:59:54 -0600 Subject: [coreboot] RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <20100919144843.26787.qmail@stuge.se> References: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20100917215137.20969.qmail@stuge.se> <1284827034.3702.59.camel@bart> <857948A3D868694688C70287BBC718140F28B6CB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <857948A3D868694688C70287BBC718140F28B6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20100919144843.26787.qmail@stuge.se> Message-ID: >> Now after remowing my Intel PRO1000MT server network card from >> PCI-X slot 6, i can boot without any problems :) > > ..the PCI-X should also work. I think it may be good to investigate > why it gets such a high bus number. The K8 code assigns bus numbers that way. The primary southbridge link gets bus 0x0, the next HT link gets 0x40... That's just the way it was written. Thanks, Myles From mylesgw at gmail.com Mon Sep 20 17:11:03 2010 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 20 Sep 2010 09:11:03 -0600 Subject: [coreboot] RE : RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing In-Reply-To: <857948A3D868694688C70287BBC718140F28B6CB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <857948A3D868694688C70287BBC718140F28B6C7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20100917215137.20969.qmail@stuge.se> <857948A3D868694688C70287BBC718140F28B6C8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1284827034.3702.59.camel@bart> <857948A3D868694688C70287BBC718140F28B6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <857948A3D868694688C70287BBC718140F28B6CB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: On Sun, Sep 19, 2010 at 8:16 AM, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > Now here are my results with the patched Memtest86+ version 4.1. > Check the attached files. > > As you can see it is far way better, even if it is not working, at least i can see that the memory is recognized correctly, wich is pretty good. > Memtest86+ is still crashing on test starting (after 3%), but really not important so far, as long as my computer does not crash in normal operation mode. I like using the memtest that comes with my distro, so I add this simple patch to SeaBIOS when I want to test RAM. It makes memtest ignore the Coreboot tables. I think you'll want to be sure that RAM is working. Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: corrupt_header.diff Type: application/octet-stream Size: 442 bytes Desc: not available URL: From penyuan at hotmail.com Mon Sep 20 19:07:43 2010 From: penyuan at hotmail.com (Pen-Yuan Hsing) Date: Mon, 20 Sep 2010 13:07:43 -0400 Subject: [coreboot] Coreboot (and gNewSense) on VIA EPIA-P820? Message-ID: Hello, I have been referred here from the gNewSense list, with a question about Coreboot compatibility with VIA motherboards and chipsets. I am looking to set up a PIM server with Citadel or SOGo as the groupware server. On the hardware side, I am looking at the VIA ARTiGO A1100 (http://www.via.com.tw/en/products/embedded/artigo/a1100/index.jsp), with the following specifications: Default BIOS: AMI BIOS Mainboard: EPIA-P820 Processor: 1.2 GHz VIA Nano (64-bit) Chip