Re: [coreboot] coreboot is going to make kcma-d8 obsolete
On Sat, Apr 07, 2018 at 02:25:19PM +0100, Leah Rowe wrote: > If you've got a D16 to submit reports on, that'd also be great. I just pushed one on the D16. Thanks, Ward. -- Ward Vandewege GPG Key: 25F774AB Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] OpenBMC/iKVM4 on KGPE-D16: bmc doesn't power up automatically on cold boot
I have a KGPE-D16 that runs coreboot as of commit 64294eb5e241afe9d93b37b31d8a6310ec8d9279, with the three BMC related patches from https://review.coreboot.org/#/c/coreboot/+/19820/1 applied on top. On cold boot (no power to the machine), the BMC doesn't power up automatically. The host starts without problem. I can make the BMC boot by reading out its rom with the patched version of flashrom linked from https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php. I assume that is because flashrom resets the BMC cpu at the end of the read (the cpu=reset option). Is this a known issue? Thanks, Ward. -- Ward Vandewege GPG Key: 25F774AB Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] kexec of Xen hypervisor from a Linux payload
On Tue, Jul 26, 2016 at 12:09:18PM -0600, Trammell Hudson wrote: > On Tue, Jul 26, 2016 at 09:37:20AM -0600, Trammell Hudson wrote: > > [...] > > Unfortunately 3.1.3 is ancient; I'm going to build the more modern > > Xen 4.6.x to see if I can repeat these fixes to boot into Qubes. > > This required a few more hacks, but it works now. The problem is not > with Coreboot, but with Xen assuming that there is a BIOS it can call > to setup the video display and also assuming that there is an EBDA > that contains pointers to various structures. > > My 4.6.3 Xen tree is hacked up right now with stuff copied from old > versions of the tree, so I'll clean it up and see if they are interested > in accepting patches. Oh, wow, thank you! Sorry that I didn't spend time tracking that down properly back in 2008. I'd be interested to know if Xen takes the patch. Thanks, Ward. -- Ward Vandewege GPG Key: 25F774AB Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot ported to the ASUS KGPE-D16 (Libreboot: blobless, fully functional!)
On Wed, Apr 29, 2015 at 10:46:29PM +0100, The Gluglug wrote: You should crowd-fund the $35,000 figure, there are lots of people who will be interested in this. I personally will chip in, and I'd ask others to as well. I would chip in too. Thanks, Ward. -- Ward Vandewege GPG Key: 25F774AB Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Are any Chromebooks able to run fully libre?
On Thu, Jan 02, 2014 at 06:43:02PM -0500, mrnuke wrote: I don't think many people have tested without microcode updates. So far I've had relatively good luck with that. Lately, specifically, these CPUs seem to work fine without microcode update: AMD A8-5600K AMD A6-5400K I tested those on the Asus F2A85-M/CSM board. You can also omit the optional xhci blob (no usb3 support) as well as the VGA BIOS. Thanks, Ward. -- Ward Vandewege GPG Key: 25F774AB Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] DDR fails on F2A85-M
Hi Paul and David, We got an F2A85-M today. I haven't tried to boot coreboot yet but I can answer the question below: On Sat, May 11, 2013 at 10:20:31PM +0200, Paul Menzel wrote: Could you try to find out with `bios_extract` for example what AGESA version the vendor BIOS uses. bios_extract is not able to do anything with the image: $ ../bios_extract/bios_extract f2a85m-proprietary.rom Using file f2a85m-proprietary.rom (8192kB) Error: Unable to detect BIOS Image type. However, hd/strings suggest that the AGESA version is v1.1.0.7: 206209:007acd40 00 00 00 00 30 30 30 30 41 47 45 53 41 00 00 00 |AGESA...| 206210-007acd50 56 31 2e 31 2e 30 2e 37 20 20 20 20 00 00 00 00 |V1.1.0.7 | Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://status.fsf.org/ward http://fsf.org/blogs/RSS | http://identi.ca/cure Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] DDR fails on F2A85-M
On Wed, May 22, 2013 at 11:18:46AM -0400, Ward Vandewege wrote: However, hd/strings suggest that the AGESA version is v1.1.0.7: 206209:007acd40 00 00 00 00 30 30 30 30 41 47 45 53 41 00 00 00 |AGESA...| 206210-007acd50 56 31 2e 31 2e 30 2e 37 20 20 20 20 00 00 00 00 |V1.1.0.7 | The above is for proprietary bios revision 5202. Bizarrely, the most recent proprietary bios revision for this board (6102) appears to use an older Agesa version, v1.1.0.1: 213221:0079e760 00 00 00 00 30 30 30 30 41 47 45 53 41 00 00 00 |AGESA...| 213222-0079e770 56 31 2e 31 2e 30 2e 31 20 20 20 20 00 00 00 00 |V1.1.0.1 | Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://status.fsf.org/ward http://fsf.org/blogs/RSS | http://identi.ca/cure Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] server board support - Supermicro H8DGi-F ?
Hi, We're looking at selecting a server board for our next generation of servers. We tend to use 2-CPU AMD boards. The Supermicro H8DGi-F seems promising. I know Konstantin is working on the H8QGi+F which is very similar. Konstantin - how far along is your port? I read about the memory speed issue with AGESA 1.0.3. Anyone else interested in working on a port of H8DGi-F or a similar board? Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://identi.ca/cure | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gerrit problem: Not able to sign in
On Thu, Jan 31, 2013 at 09:58:47AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: The page you requested was not found, or you do not have permission to view this page. Do you have similar problems? Thanks, Paul I have the same problem This is now fixed. Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://identi.ca/cure | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SPAM] Re: Feedback On Coreboot: the Solution to the SecureBoot Fiasco
On Mon, Jan 07, 2013 at 03:29:01PM +0100, Xavi Drudis Ferran wrote: For now secure boot only restricts what we boot (and the booted OS restricts the rest of what we run). But in the end the purpuse is to stablish a DRM scheme so that if a server can't prove that we're running software trusted by them (not us) then we won't be able to access content or even we'll be refused connection to the internet or whatever has to do with equipment controlled by someone else. This. It's called 'remote attestation' (https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation). An obvious (first?) application will be your bank, which will refuse you access to their online banking system unless you run a 'trusted' software stack. And you can be sure that their idea of a 'trusted' stack will be proprietary software, only. Because we all know that Windows is the most secure operating system out there (/sarcasm). Thanks, Ward. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] tyan s2882-d not booting
On Mon, Dec 03, 2012 at 05:12:03PM -0800, Kui Zhang wrote: I got some old boxes: tyan s2882-d, dual opteron processors, 16G RAM. 512K bios flash. So far, I am not able to get it to boot. It appears to reboot during CPU init. If anyone got coreboot working on this board, which revision did it worked last ? That would have been me, I think. I'm not 100% sure we still have an s2882; we only had one if I recall correctly. I can check later this week. Some revision(s) it worked with are listed on http://www.coreboot.org/Tyan_S2882. Those are revisions from the old SVN tree; you can grep the git log for the svn revision number (it is listed); you'll see these are revisions from 2006. I do have an s2881 that I booted succesfully about 5 or 6 weeks ago, with coreboot head. It's a very similar board. Have you tried with less ram? Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://identi.ca/cure | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Moving gerrit to an separate mailing list
On Wed, Aug 08, 2012 at 04:28:45PM -0500, Alex G. wrote: All I've said and refuted above are arguments and rants we like to use to tease each other. I strongly believe that it makes sense, now more than ever, to separate development and discussion traffic into two separate lists. I hope you all agree. I very much agree. Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://identi.ca/cure | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, Jun 04, 2012 at 05:29:23PM +0100, Bob Ham wrote: On Mon, 2012-06-04 at 09:15 -0700, ron minnich wrote: On Mon, Jun 4, 2012 at 9:10 AM, Bob Ham r...@settrans.net wrote: Not PCI-E or PCI-X, just normal PCI. Wow. More than one? How many? Two; I have two identical M-Audio Delta 1010s. Finding a modern board with two 'old' PCI slots may be difficult, regardless of coreboot... Have you seen any at all? Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://identi.ca/cure | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] separate mailling list for gerrit mails?
On Sun, Mar 11, 2012 at 10:19:41PM -0400, Kevin O'Connor wrote: I'd prefer if they were on a separate email list. Me, too. Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://identi.ca/cure | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot meeting @ Google, Sunday Mar. 13
On Sat, Mar 12, 2011 at 12:32:52PM -0800, Stefan Reinauer wrote: If you find some fellow coreboot folks around NYC, you should go ahead and organize a meeting. If you can't find a conference room to use, any cafe will usually do fine. They might look weird at you when you bring too much hardware, but we've never had any (real) trouble with that approach when trying this in Brussels, Denver or Hamburg. :-) Well, in Hamburg they were a bit upset about this after about three consecutive evenings of hacking in the hotel lobby. Ah, well. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fam10 FIDVID in SVI : disabling microcode update
Hi Xavi, On Wed, Feb 16, 2011 at 02:45:02PM +0100, Xavi Drudis Ferran wrote: Should I send a patch making a Kconfig option to not upgrade microcode for fam10? Is there any interest in that ? Yes, please. I would test and ack that. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] enabling expert mode - build fails (warnings treated as errors) on fam10 boards
Hi all, If one enables expert mode in Kconfig and builds a fam10 board, this is what happens: $ make clean make ROMCC mainboard/supermicro/h8qme_fam10/bootblock.inc GENbootblock/bootblock.S CC mainboard/supermicro/h8qme_fam10/bootblock.s CC mainboard/supermicro/h8qme_fam10/bootblock.o GENbootblock/ldscript.ld LINK bootblock.elf OBJCOPYcoreboot.bootblock OPTION option_table.h GENbuild.h CC romstage.inc cc1: warnings being treated as errors In file included from src/northbridge/amd/amdht/ht_wrapper.c:52:0, from src/cpu/amd/quadcore/quadcore.c:22, from src/mainboard/supermicro/h8qme_fam10/romstage.c:72: src/northbridge/amd/amdht/h3finit.c: In function 'selectOptimalWidthAndFrequency': src/northbridge/amd/amdht/h3finit.c:1332:24: error: CONFIG_LIMIT_HT_SPEED_300 is not defined src/northbridge/amd/amdht/h3finit.c:1336:24: error: CONFIG_LIMIT_HT_SPEED_500 is not defined make: *** [build/mainboard/supermicro/h8qme_fam10/romstage.pre.inc] Error 1 I looked around a bit; those config variables do not appear to be used anywhere but in the checks in h3finit.c. What's the best way to fix this? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] don't print too early on mcp55-based boards
On Mon, Nov 01, 2010 at 11:01:41PM +0100, Peter Stuge wrote: Ward Vandewege wrote: See attached. Perhaps we should also print a post code if the SMBus controller can't be found - suggestions for a value? 0x5B ? Let's do that as part of the die modification. We can't print this early. This patch fixes a hang on supermicro/h8dme supermicro/h8dmr supermicro/h8dmr_fam10 and possibly on other mcp55-based boards. Signed-off-by: Ward Vandewege w...@gnu.org Acked-by: Peter Stuge pe...@stuge.se r6048. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig
On Fri, Nov 05, 2010 at 01:28:59PM -0500, Scott Duplichan wrote: I am no quad rank dimm expert, but I think few boards support them. One is Serengeti Cheetah. I remember asking why one processor socket has 4 dimm slots and another 8. I was told it was for quad rank dimm testing. The chip selects for two normal dimm sockets are combined and routed to a quad rank socket, if I remember correctly. I don't even have any quad ranked dimms to test with. I think they are rare. Actually, they are not *that* rare, since they are readily available: http://www.newegg.com/Product/ProductList.aspx?Submit=ENEDEPA=0Order=BESTMATCHDescription=ddr3+quad+rankx=0y=0 Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] don't print too early on mcp55-based boards
On Tue, Nov 02, 2010 at 11:20:43PM +0100, Uwe Hermann wrote: I don't object to the patch, and we should probably fix this in all other southbridges, I think the same problem applies there. But: the die() call itself also does a printk(), so that'll still hang if the error path is chosen (at that point it probably doesn't matter much, though, as we die anyway). Right, I think it does not matter. If the die happens when printk is already functional, great, if not it will hang there which is fine. I also agree that die() should have a POST code, preferrably something easy to remember. It already has a commented-out //post_code(0xff);. Not sure why it's disabled, but I think it should be something other than 0xff, that's a bit too special for my taste. We have 0xee: Not supposed to get here as per documentation/POSTCODES, so maybe we can use 0xdd (d as in die), if that's not already used elsewhere. So, thinking about this a little more, I'm not sure adding a post code to 'die' is a good idea. The problem with doing that is that it would clobber any previous post codes, which might be a better indicator for what's going wrong. Perhaps a good way to deal with fatal runtime error conditions would be a) set a unique post code b) call die in the assumption that die does not clobber the post code. What do you think? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] don't print too early on mcp55-based boards
See attached. Perhaps we should also print a post code if the SMBus
controller can't be found - suggestions for a value?
Thanks,
Ward.
--
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator
We can't print this early.
This patch fixes a hang on
supermicro/h8dme
supermicro/h8dmr
supermicro/h8dmr_fam10
and possibly on other mcp55-based boards.
Signed-off-by: Ward Vandewege w...@gnu.org
Index: src/southbridge/nvidia/mcp55/mcp55_early_smbus.c
===
--- src/southbridge/nvidia/mcp55/mcp55_early_smbus.c (revision 6011)
+++ src/southbridge/nvidia/mcp55/mcp55_early_smbus.c (working copy)
@@ -32,11 +32,8 @@
device_t dev;
dev = pci_locate_device(PCI_ID(0x10de, 0x0368), 0);
- if (dev == PCI_DEV_INVALID) {
- printk(BIOS_WARNING, SMBUS controller not found\n);
- } else {
- printk(BIOS_DEBUG, SMBus controller enabled\n);
- }
+ if (dev == PCI_DEV_INVALID)
+ die(SMBus controller not found\n);
/* set smbus iobase */
pci_write_config32(dev, 0x20, SMBUS0_IO_BASE | 1);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Gigabyte MA785GMT support
Hi Niels, On Sat, Aug 14, 2010 at 01:38:26AM +0800, Qing Pei Wang wrote: In my eyes, you can flash the M_BIOS with coreboot. It should not need any hardware modification. Although i did some of them, but they are just used to let me find out the problems of dual bios things Qing Pei is right, no hardware modification necessary. I started a page on the MA785GMT-UD2H that explains how to recover from an unbootable M_BIOS, by using the B_BIOS feature. It boils down to shorting pins 4 (GND) and 7 (#HOLD) on the M_BIOS chip for a few seconds on cold boot, and then releasing the short. See http://www.coreboot.org/GIGABYTE_GA-MA785GMT-UD2H Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Tue, Jun 22, 2010 at 01:30:45PM -0600, Myles Watson wrote: The ADM1027 doesn't expect to have children, so it has no scan_bus method. I had thought that the ADM1027 was some kind of a controller for the ADT4763, but it looks like the same type of device. Is there really an ADM1027 on your board? I don't see it in your sensors output. So... the first two patches are the same as before. The third patch adds a scan_bus method to the ADM1027 so that the ADT4763 can be initialized, and the fourth patch replaces the ADM1027 with the ADT4763 in the device tree, and removes the third patch. I'd be interested in head + 1 + 2 + 3, and head + 1 + 2 + 3 + 4. See http://ward.vandewege.net/coreboot/s2881/20100621-myles/ Thanks for testing Ward! As far as I can see, both worked, but 1+2+3+4 is cleaner. It doesn't look like there is an ADM1027 on your board. Is there something missing before an Ack commit? I think it's good. Thanks for writing the patches! Acked-by: Ward Vandewege w...@gnu.org Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 05:59:52AM -0600, Myles Watson wrote: It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, Ah, whoops, I was wondering if I was doing the right thing there... so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? All boots were cold. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 07:36:39AM -0600, Myles Watson wrote: On Mon, Jun 21, 2010 at 5:59 AM, Myles Watson myle...@gmail.com wrote: On Sun, Jun 20, 2010 at 8:11 PM, Ward Vandewege w...@gnu.org wrote: Hi Myles, Everything seems fine with either patch - but there are some differences in the boot output. I also ran the 'sensors' command. Output here: http://ward.vandewege.net/coreboot/s2881/20100617-myles/ I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this changeset), r5635 + patch 1 and r5635 + patch 2. Thanks for testing. It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? The ADM1027 doesn't expect to have children, so it has no scan_bus method. I had thought that the ADM1027 was some kind of a controller for the ADT4763, but it looks like the same type of device. Is there really an ADM1027 on your board? I don't see it in your sensors output. So... the first two patches are the same as before. The third patch adds a scan_bus method to the ADM1027 so that the ADT4763 can be initialized, and the fourth patch replaces the ADM1027 with the ADT4763 in the device tree, and removes the third patch. I'd be interested in head + 1 + 2 + 3, and head + 1 + 2 + 3 + 4. See http://ward.vandewege.net/coreboot/s2881/20100621-myles/ The temperature differences (higher readouts in head + 1 + 2 + 3 + 4 seem to be the consequence of less than optimal cooling of the board - and the fact that it was entirely cooled off before the first boot (head + 1 + 2 + 3) only. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
Hi Myles, Everything seems fine with either patch - but there are some differences in the boot output. I also ran the 'sensors' command. Output here: http://ward.vandewege.net/coreboot/s2881/20100617-myles/ I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this changeset), r5635 + patch 1 and r5635 + patch 2. Let me know if you need anything else... Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Wed, Jun 16, 2010 at 02:50:42PM -0600, Myles Watson wrote: This patch breaks the s2881, which was doing some odd acrobatics in order to get a device initialized after its parent. It should be an easy fix to do it correctly now, but I don't have an s2881 to test on. Ward? Yep, I've got (the guts) of an s2881 lying on my desk here, and can test any patches you throw at me :) Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch somewhat daunting
On Thu, Jun 10, 2010 at 11:10:28AM -0400, Joe Korty wrote: Ward and others have tried this board in the past. Yeah - I still have a test setup and need to get back to this soon. I'm just tied up with too much other stuff. Bleh. There seems to be something wrong with multi-core setup for K10. I think that why Ward had problems with this CPU family is for the same reason why I had problems with it on different boards, the resource map! I started using the one from the h8dme fam 10 board. So maybe you should try another resource map from another fam 10 board. If you search the mailing list for h8dme fam10, it might give you some help. I would disable all the other processors until you get the board working. Qemu and SimNOW are both helpful, too. SimNOW exhibits the same problems for fam10 as hardware (super slow initialization and problems with logical CPUs), so fixing it there would probably help. Myles and Knut, Thanks! I'll probe these ideas and see what happens. Another data point: It _does_ continue after the hang, but it takes about an hour. Oh! That's interesting. I never tried to leave the board alone for that long. I image each memory write is timing out so a bunch of writes via memset drags the total timeout to an hour. At that point we try to load the payload so it seems that I am really really close to the end here It does sound like it. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Indtast Bcc Indtast Bcc Wyse S10 and coreboot
On Fri, May 21, 2010 at 08:08:17AM +0200, Oliver Schinagl wrote: On 05/21/2010 07:50 AM, and...@jenbo.dk wrote: Also check out the required tool chain here coreboot.org/Development_Guidelines I checked those and I have everything on my Ubuntu laptop, except pciutils-dev package. Seems like it doesn't exist. I checked through the sources and there weren't many header files included; Which files from pciutils-dev are needed that wouldn't be in a pciutils package? Hmm, apparently the package has been renamed to libpci-dev since Intrepid, and they dropped the virtual pciutils-dev package that refers to libpci-dev in Lucid. I've put a note to that effect on the wiki, too. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FILO bug disk not seen at ata-0 (Doesn't try to detect on ATA only SIL3114)
Hi Rudolf, Awesome! This fixes booting from SATA on the s2881 for me with Seabios. Before, even with the sii3114 option rom, Seabios never showed the disk as a boot option in the boot menu. Now I don't even need that sii3114 option rom anymore. If you add a Signed-off-By line, this is Acked-by: Ward Vandewege w...@gnu.org Thanks! Ward. On Sun, May 09, 2010 at 12:33:50AM +0200, Rudolf Marek wrote: The sil3114 chip has a class code set to something else then IDE by strap resistor. It took me long time to figure out that this chip is otherwise IDE compatible ;) Try attached patch for coreboot which reprograms it back to IDE mode ;) It should start to work - booting from FILO and from Seabios. Rudolf -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8DME-2 woes, hints?
On Fri, May 07, 2010 at 07:30:08AM -0600, Myles Watson wrote: This looks like the bootup code for gen f Opterons. It doesn't look like the h8dme has a fam10 variant yet, which is what you need for the 2378 CPUs. Thanks Arne! I'll have to figure out how to proceed from here. On a side note, it _looks_ like the slowdown might be due to the udelay unification. Still bisecting. I'm surprised you found a revision that works, since it has never supported fam10. I think it would be more fruitful for you to look at one of the boards that has both fam10 and k8 support, and try to put together an h8dme_fam10 port. For the record, I've been trying to get that going for a while, but have not had much success - very early hangs in the fam10 code on this board. Cf. the problems Knut is having, I think... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Query, known-good CPUs to use in a H8DME-2 mb?
On Fri, May 07, 2010 at 01:59:12PM -0400, Joe Korty wrote: What AMD Processor model numbers have you folks been using on the SuperMicro H8DME-2 mainboards? I'd like to buy a pair of known-working CPUs. I currently have a pair of AMD model #2378 Processors, which are of the fam10 line, with a pair of model # CPUs, which are of the K8 line. The port for that board was done on a pair of 2216 HE CPUs. You may be hard pressed to find those for sale these days... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot doesn't boot on Arima HDAMA rev.G mainboard
On Tue, May 04, 2010 at 11:59:26PM +0200, Joop Boonen wrote: On Tue, May 4, 2010 8:16 pm, Myles Watson wrote: On Tue, May 4, 2010 at 11:54 AM, Myles Watson myle...@gmail.com wrote: rev 4920 works without a problem, also with the extracted VGA. I get the FILO screen. Great. You could check the values from Kconfig (build/config.h) and compare them to the values from 4920. That would be the easiest thing to fix. I think the most likely culprit is SB_HT_CHAIN_ON_BUS0. Could you change it to 1 in src/mainboard/arima/hdama/Kconfig, make oldconfig, and test? I've tested it. I get the filo screen now. When I do a probe I don't see any IDE device yet. Neither IDE nor SATA SIL3114 drive. This also didn't work for version 4920. Yeah, the Sil3114 needs special handling for its SATA ports. The Tyan S2881 board has the same problem. I'm not sure about the IDE ports. In the past I've used a linux kernel payload to get around that. Rudolf has had success with SeaBIOS (and the SiL3114 option rom, I believe) http://www.coreboot.org/pipermail/coreboot/2009-February/044781.htm but I have not been able to replicate that yet on my Tyan s2881. I wonder if we could make Coreboot do the necessary to initialize that controller, so that we don't need that binary blob or a full blown linux kernel anymore. There appear to be public datasheets for Sil3114, referenced here https://ata.wiki.kernel.org/index.php/Sata_sil And the kernel driver also knows how to bring it up, since using a linux kernel as a payload has worked for me in the past. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
Hi Knut, On Fri, Apr 30, 2010 at 10:29:59AM +0200, Knut Kujat wrote: I now know that I'm having the same trouble Ward had with his h8dme board: http://www.mail-archive.com/coreboot@coreboot.org/msg20923.html Could anyone tell if and how he solved his problem? I have not. Unfortunately, I have had very little time for coreboot in the past few months, but I do still need fam10 support for h8dme - we have bunch of those machines that I need to upgrade to coreboot. It's odd that you are seeing this only on some machines. I only have one h8dme test box; the others are in production. I have this problem 100% of the time on my test box. Perhaps figuring out why the problem occurs on only some of your machines would give a clue as to what could be going wrong? Does it consistently happen on the machines where you see the hangs? And never on the others? And the hardware is identical? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] warning days - m57sli/mcp55
On Tue, Apr 13, 2010 at 12:15:42AM +0200, Stefan Reinauer wrote:
Index: src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
===
--- src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c(revision 5411)
+++ src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c(working copy)
@@ -177,7 +177,7 @@
pci_write_config32(dev, 0xe4, dword);
// need to wait 100ms
- delayx(1000);
+ delayx(232);
}
it sounds a lot to do 0x8000 outb to wait 100us, but who knows...
I think it would be better to change the input type to something else
than uint8_t, supposedly unsigned as most other udelay functions.
That works, boot-tested.
Alternatively you could try if this works:
Index: src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
===
--- src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (revision 5411)
+++ src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (working copy)
@@ -131,15 +131,9 @@
}
-static void delayx(uint8_t value) {
-#if 1
- int i;
- for(i=0;i0x8000;i++) {
- outb(value, 0x80);
- }
-#endif
-}
+#include pc80/udelay_io.c
+
static void mcp55_early_pcie_setup(unsigned busnx, unsigned devnx,
unsigned anactrl_io_base, unsigned pci_e_x)
{
uint32_t tgio_ctrl;
@@ -170,14 +164,14 @@
outl(tgio_ctrl, anactrl_io_base + 0xcc);
// wait 100us
- delayx(1);
+ udelay(100);
dword = pci_read_config32(dev, 0xe4);
dword = ~(0x3f0); // enable
pci_write_config32(dev, 0xe4, dword);
// need to wait 100ms
- delayx(1000);
+ udelay(100 * 1000);
}
static void mcp55_early_setup(unsigned mcp55_num, unsigned *busn,
unsigned *devn, unsigned *io_base, unsigned *pci_e_x)
Hmm, that generates a conflict:
In file included from
src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c:143,
from src/mainboard/gigabyte/m57sli/romstage.c:133:
src/pc80/udelay_io.c:4: error: redefinition of 'udelay'
src/cpu/amd/model_fxx/apic_timer.c:19: note: previous definition of 'udelay'
was here
We do indeed have 2 different functions called udelay.
Ideas?
Index: src/mainboard/gigabyte/m57sli/fanctl.c
===
--- src/mainboard/gigabyte/m57sli/fanctl.c (revision 5411)
+++ src/mainboard/gigabyte/m57sli/fanctl.c (working copy)
@@ -71,6 +71,7 @@
/*
* Called from superio.c
*/
+extern void init_ec(uint16_t base);
void init_ec(uint16_t base)
{
int i;
init_ec() is the API between the superio drivers and the mainboard
drivers...
If this is a single hack, it's fine as it is.. If we're going to have an
API here, we should create a src/include/superio.h or some such
It's only used on this particular board. Myles expressed a preference for a
header file, so I moved the definition to fanctl.h, and I dropped the
'extern' as you suggested.
Index: src/northbridge/amd/amdk8/exit_from_self.c
===
--- src/northbridge/amd/amdk8/exit_from_self.c (revision 5411)
+++ src/northbridge/amd/amdk8/exit_from_self.c (working copy)
@@ -17,6 +17,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
USA
*/
+extern void exit_from_self(int controllers, const struct mem_controller
*ctrl,
+struct sys_info *sysinfo);
void exit_from_self(int controllers, const struct mem_controller *ctrl,
struct sys_info *sysinfo)
{
since this is a C file that is included in exactly one file,
raminit_f.c you could as well just mark the function static.
Done.
btw, for function prototypes the extern in not really needed. I keep
removing them from the tree, but if people think we should have them,
I'll try to be consistent and stop deleting them :-)
I'll not add any new ones then!
Updated patch attached. I see the ACPI warnings were already fixed in another
commit.
Thanks,
Ward.
--
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator
This fixes a number of warnings when building m57sli (and other boards with mcp55).
This patch is boot tested on m57sli.
Signed-off-by: Ward Vandewege w...@gnu.org
Index: src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
===
--- src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (revision 5437)
+++ src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (working copy)
@@ -131,7 +131,7 @@
}
-static void delayx(uint8_t value) {
+static void delayx(unsigned value) {
#if 1
int i;
for(i=0;i0x8000;i++) {
Index: src/mainboard/gigabyte/m57sli/fanctl.c
===
--- src/mainboard/gigabyte/m57sli/fanctl.c (revision 5437)
+++ src/mainboard/gigabyte/m57sli/fanctl.c (working copy)
@@ -1,5 +1,6 @@
#include arch/io.h
[coreboot] [PATCH] warning days - m57sli/mcp55
If there are better ways to kill the warnings, please let me know!
Thanks,
Ward.
--
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator
This fixes a number of warnings when building m57sli (and other boards with mcp55).
This patch is boot tested on m57sli.
What appears to be a shortening of the delay in
src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
is functionally exactly the same as before; the delayx function takes a uint8_t
argument, so the old value (1000 - 0x3E8) was truncated to 232 (0xE8).
Signed-off-by: Ward Vandewege w...@gnu.org
Index: src/southbridge/nvidia/mcp55/mcp55_fadt.c
===
--- src/southbridge/nvidia/mcp55/mcp55_fadt.c (revision 5411)
+++ src/southbridge/nvidia/mcp55/mcp55_fadt.c (working copy)
@@ -51,8 +51,8 @@
printk(BIOS_INFO, ACPI: pm_base: %u...\n, pm_base);
- fadt-firmware_ctrl = facs;
- fadt-dsdt = dsdt;
+ fadt-firmware_ctrl = (u32) facs;
+ fadt-dsdt = (u32) dsdt;
fadt-preferred_pm_profile = 1; //check
fadt-sci_int = 9;
/* disable system management mode by setting to 0 */
@@ -108,9 +108,9 @@
fadt-reset_reg.addrh = 0x0;
fadt-reset_value = 0;
- fadt-x_firmware_ctl_l = facs;
+ fadt-x_firmware_ctl_l = (u32) facs;
fadt-x_firmware_ctl_h = 0;
- fadt-x_dsdt_l = dsdt;
+ fadt-x_dsdt_l = (u32) dsdt;
fadt-x_dsdt_h = 0;
fadt-x_pm1a_evt_blk.space_id = 1;
Index: src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
===
--- src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (revision 5411)
+++ src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (working copy)
@@ -177,7 +177,7 @@
pci_write_config32(dev, 0xe4, dword);
// need to wait 100ms
- delayx(1000);
+ delayx(232);
}
static void mcp55_early_setup(unsigned mcp55_num, unsigned *busn, unsigned *devn, unsigned *io_base, unsigned *pci_e_x)
@@ -388,7 +388,7 @@
int mcp55_num = 0;
unsigned busnx;
unsigned devnx;
- int ht_c_index,j;
+ int ht_c_index;
/* FIXME: multi pci segment handling */
Index: src/mainboard/gigabyte/m57sli/fanctl.c
===
--- src/mainboard/gigabyte/m57sli/fanctl.c (revision 5411)
+++ src/mainboard/gigabyte/m57sli/fanctl.c (working copy)
@@ -71,6 +71,7 @@
/*
* Called from superio.c
*/
+extern void init_ec(uint16_t base);
void init_ec(uint16_t base)
{
int i;
Index: src/mainboard/gigabyte/m57sli/romstage.c
===
--- src/mainboard/gigabyte/m57sli/romstage.c (revision 5411)
+++ src/mainboard/gigabyte/m57sli/romstage.c (working copy)
@@ -146,7 +146,6 @@
static void sio_setup(void)
{
-unsigned value;
uint32_t dword;
uint8_t byte;
Index: src/northbridge/amd/amdk8/exit_from_self.c
===
--- src/northbridge/amd/amdk8/exit_from_self.c (revision 5411)
+++ src/northbridge/amd/amdk8/exit_from_self.c (working copy)
@@ -17,6 +17,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+extern void exit_from_self(int controllers, const struct mem_controller *ctrl,
+struct sys_info *sysinfo);
void exit_from_self(int controllers, const struct mem_controller *ctrl,
struct sys_info *sysinfo)
{
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: AMD RS780/SB700 support
On Wed, Mar 17, 2010 at 10:47:10PM +0100, Rudolf Marek wrote: Niels Ole Salscheider wrote: Hello, I own a GA-MA785GT-UD3H ( http://www.gigabyte.de/Products/Motherboard/Products_Overview.aspx?ProductID=4694 ) but unfortunately it uses 785G / SB710. SB710 seems to be supported by Zheng Bao's patch but I am unsure about 785G. It works, check my thread about the Asrock board. The SB700 code will work on any SB7xx fhe RS785 has same PCIids except the graphics chip, which is rv620 and not rv610. I just added the ID and it does work it seems. But that Gigabyte board is DDR3 - didn't Zheng say that was not supported with fam10 CPUs yet? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Join us in Cambridge for LibrePlanet, March 19th-21st! http://groups.fsf.org/wiki/LibrePlanet2010 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
On Wed, Mar 10, 2010 at 05:26:47PM +0100, Knut Kujat wrote: I finally know that my issue must be related with the smbus registers because on a vendor bios running machine and using i2cdetect and i2cdump I get several values for different i2c devices detected, I get the same values when I successfully start with coreboot. But when I start with coreboot and fail with mcr_d fatal exit those registers are blank, I know that because I found a nice piece of code dumping smbus registers on the h8dme board :D thx to the autor!! That would have been Marc Jones :) Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Join us in Cambridge for LibrePlanet, March 19th-21st! http://groups.fsf.org/wiki/LibrePlanet2010 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Un-brick a GAM57SLIS4
Hi Thorsten, On Thu, Mar 11, 2010 at 12:47:12AM +0100, tho@gmx.de wrote: [if this is off-topic here, please feel free to ignore/delete this message] I accidently flashed my Gigabyte GA-M57-SLI-S4 Rev. 1 with a corrupted BIOS file. The board does not boot anymore, just a black screen, no beeps, simply dead. I would be glad if I could save the money for a new board so I've got the following question: If I do the hardware-mod as shown in http://private.vlsi.informatik.tu-darmstadt.de/st/ and can obtain a programmed flash rom with a valid BIOS inside, would it be possible to reanimate the board again? Would it be neccessary to remove the original Flash-BIOS or can leave it (permanently switched off) on the board? If you do that modification, you'll have a switch or jumper to toggle between your 2 chips. If the second one has a good image, this should work. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Join us in Cambridge for LibrePlanet, March 19th-21st! http://groups.fsf.org/wiki/LibrePlanet2010 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi...all
On Sat, Mar 06, 2010 at 01:12:51AM +0100, Carl-Daniel Hailfinger wrote: On 05.03.2010 19:26, ron minnich wrote: What would coreboot need to do to support IPMI BMC? Depends on the IPMI BMC. If you're lucky, it works out of the box, and if you're unlucky, you have to implement undocumented BIOS interfaces. The easiest solution is to buy a card and try it, and if it doesn't work, reverse engineer it or try another card. Besides that, IPMI is a security nightmare (see the discussions on the linux-kernel mailing list about IPMI bypassing host network security). Even worse - I have yet to encounter a reliable IPMI card. The sorts of problems I've encountered are: * specific packets can 'kill' the IPMI controller. Once the thing is hung, the only fix is a *cold* boot of the entire machine. * I've seen machines crash, taking the IPMI controller with them. Makes the whole thing kind of pointless... * general reliability issues. IPMI controllers also seem to like to hang themselves occasionally I really tried to make IPMI work reliably; I have an 80 machine cluster full of these things. I wasted a ton of time on them (3 different generations from 2 vendors - Tyan and Supermicro). I think that those issues were largely caused by extremely crappy proprietary firmware. But there is a more fundamental issue; the IPMI BMC is pretty tightly connected into the mainboard, by design. That's bad - how can you guarantee that IPMI BMC will always be available, fully out of band, when it is not 100% independent of the mainboard? In the end I gave up; I now use serial console servers (opengear is highly recommended) and switched PDUs (I've tried various brands, so far I like Raritan's Dominion series the best). That works, 100% of the time. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] server hardware without IPMI / with coreboot
On Sat, Mar 06, 2010 at 08:03:40AM -0800, ron minnich wrote: So, if you're looking to buy 150 or so nodes, what's a reasonable coreboot-capable node *without* any sort of BMC/IPMI? I really need these IPMI-free boards and the vendors keep trying to shove this IPMI nonsense down our throats -- in spite of the fact that IPMI is such a failure. It's easy to see why, they get to charge a pretty nice premium for the presence of those BMCs. While the IPMI BMC is tightly integrated with the mainboard, it tends to be an optional module on Supermicro (and Tyan, I guess, I have not looked recently though) boards. So you can definitely order without the module. Coreboot would be a huge plus. A 45-second POST, in this day and age, is just simply ridiculous. Even were we to accept that 45-second post, the BIOS on this Nehalem new board is so defective that it's just unusuable for what we need -- it doesn't always come out of a reset. Ward, what's the latest thing you know of? I still like Opteron a lot. Here's the current list of Supermicro boards based on the latest SR56x0/SP5100 chipset: http://www.supermicro.com/Aplus/motherboard/Opteron2000/ I wonder if these boards will take the 8 and 12 core CPUs AMD is due to release at the end of this month. Silicon Mechanics has a few systems built on those boards, but so far only a 2U (nServ A346) and 3U (A362). They should be able to to tell you when they will have 1U systems (assuming that's what you are looking for here). There are also very nifty 'twin' systems (1U) and 2x2 twin systems (4 boards, hot swappable, in a 2U chassis with redundant power and 12 disk bays). Sadly, I've only seen the 2x2 with Intel boards, so far... My experience is that if you talk to a vendor like Silicon Mechanics or Aspen Systems and tell them you want to buy 150 systems, they will at least *try* to help with coreboot by talking to their suppliers. I guess the most important thing right now would be to get AMD to release docs (and code?) for the SR56x0/SP5100 chipset. With that, supporting any of the boards listed above might be possible. This chipset is likely to be around for a while (5 years?). Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] More lists
On Tue, Feb 23, 2010 at 10:47:21AM -0700, Myles Watson wrote: Could we have some tag to svn commit like: And then add: current-works And also the haha this is broken tag and maybe the will fry your mainboard tag. :) One problem is that commits that are board-specific hopefully result in a working board. The problem is that they break other boards that weren't tested (or other payloads on the same board). I don't think there's a way around that basic problem. Boot testing would. The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost: dedicating an artec dongle + plcc adapter runs about $350 per board... And then you still need a remote power toggle device (can be had for cheap-ish if you look around a bit) and some sort of serial capture device (or just another computer if it's one or a few boards). If I didn't have to sacrifice a dongle for each board, I'd set up a tyan S2881 and probably one or two alix boards for automated testing. Thanks, Ward. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tester hardware
On Wed, Feb 24, 2010 at 12:14:30AM +0100, Carl-Daniel Hailfinger wrote: On 23.02.2010 21:14, Peter Stuge wrote: Ward Vandewege wrote: The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost: You're not alone. I've wanted to create affordable tester hardware for quite some time now. I think it's the only way we'll get more boot testing. [...] I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port. Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of) of SPI flash chips right now and Oh. That sounds like a much more affordable solution! What kind of hardware would one use to hook the spi chip to the mini module? Some sort of top hat? of LPC/FWH chips in the near future. I guess for lpc/fwh (plcc), one of the plcc adapters Peter and Stepan make would do. Thanks, Ward. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] fix Tyan s2881 boot (Kconfig)
This fixes breakage introduced in r5051. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Revision 5051 broke Kconfig booting for the Tyan s2881 board. Up to 5050, there were two SB_HT_CHAIN_ON_BUS0 sections in the mainboard Kconfig file - one setting the parameter to 0, the other setting it to 2. Revision 5051 removed one of the two SB_HT_CHAIN_ON_BUS0 sections - the wrong one. This patch fixes that. Tested on real hardware. Signed-off-by: Ward Vandewege w...@gnu.org Index: src/mainboard/tyan/s2881/Kconfig === --- src/mainboard/tyan/s2881/Kconfig (revision 5076) +++ src/mainboard/tyan/s2881/Kconfig (working copy) @@ -24,7 +24,7 @@ config SB_HT_CHAIN_ON_BUS0 int - default 0 + default 2 depends on BOARD_TYAN_S2881 config LB_CKS_RANGE_END -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] fix Tyan s2881 boot (Kconfig)
On Wed, Feb 03, 2010 at 06:52:57PM +0100, Stefan Reinauer wrote: On 2/3/10 6:50 PM, Ward Vandewege wrote: This fixes breakage introduced in r5051. Thanks, Ward. Sorry for the inconvenience. Acked-by: Stefan Reinauer ste...@coresystems.de No worries - fixed in r5083 for both newconfig and Kconfig. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] dell server BIOS setting insanity
Hi all, I thought I'd point out this little gem from the linux-poweredge list http://lists.us.dell.com/pipermail/linux-poweredge/2010-January/041170.html Apparently several lines of Dell servers have a BIOS setting called Cores-per-processor. It seems they ship these machines with the setting configured to 'dual', regardless of what CPUs are in the system. The poor guy who reported this to the list just took delivery of 300 of those machines - with quad core CPUs. They show up as dual core until he goes into the BIOS and changes the setting. That's also the 'official' solution for the problem from the Dell rep. Seriously. Thanks, Ward. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memtest86+ failing on coreboot system.
On Fri, Jan 22, 2010 at 12:09:59AM +0100, Knut Kujat wrote: sorry, of course. I did the necessary changes on the alrady existing supermicro h8dmr_fam10 board to make it work on a h8qme_fam10. I'm interested in your port. It should go into the tree. Do you want to send a patch to the list? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang
On Tue, Dec 22, 2009 at 04:11:06PM -0700, Myles Watson wrote: This is broken, but I'm not sure if it's the dump or the register value. It shouldn't affect the IO, though. That register looked fine. It seems like IO is broken for you not to be able to start the other processors or complete the mcp55 init. You could print out PCI_DEV(0,0x18,0) @ 0x6C to make sure that the lower bits are what you expect. The ones I'd look at are the default link (bits 11,3,2), disable routing bit (bit 0). The default link should be 2. The disable routing bit can tell you if it's important that the routing registers are messed up. Hrm. If I'm reading that right with this code u32 xxx = pci_read_config32(PCI_DEV(0, 0x18, 0), 0x6c); printk_debug(0x%04x\n,xxx); then what comes out does not look very good: 0xf870 which is 1111 So the default link is 0, and the Routing Table Disable bit is set to zero. You mentioned bit 11 - that seems to be marked as 'reserved' in the BKDG for fam10? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Hi Knut, On Tue, Dec 22, 2009 at 10:25:06AM +0100, Knut Kujat wrote: stack_size = 0x4000 and seems to work fine. Sorry, I didn't explain myself, changing CONFIG_LOGICAL_CPUS to 0 made the compile process fail in northbridge.c so I had to change it back. Yeah, that's because of this in northbridge.c: #if CONFIG_LOGICAL_CPUS==1 #include cpu/amd/quadcore.h #include pc80/mc146818rtc.h #endif The read_nb_cfg_54() function is defined in quadcore.h, so if you set CONFIG_LOGICAL_CPUS to zero compilation fails with an implicit definition error for read_nb_cfg_54. The tree compiles for me if I comment out that if/endif lines and have CONFIG_LOGICAL_CPUS set to zero. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang
On Fri, Dec 18, 2009 at 11:38:46AM -0700, Myles Watson wrote: I would check the early startup code for the remote nodes. It looks like you hang right where it gets garbled for Knut. Hmm, yeah. So I tried enabling just one core by setting default CONFIG_MAX_PHYSICAL_CPUS=1 default CONFIG_MAX_CPUS=1 * CONFIG_MAX_PHYSICAL_CPUS default CONFIG_LOGICAL_CPUS=1 and by adding a return at the very beginning of start_other_cores in cpu/amd/quadcore/quadcore.c which gets me a bit further, but not much. It hangs in the mcp55_early_pcie_setup function in southbridge/nvidia/mcp55/mcp55_early_setup_car.c Log attached. Anything else I should try? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator minicom-20091222aa-all-ram-on-cpu1.cap Description: application/cap -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang
On Tue, Dec 22, 2009 at 02:30:21PM -0700, Myles Watson wrote: On Fri, Dec 18, 2009 at 11:38:46AM -0700, Myles Watson wrote: I would check the early startup code for the remote nodes. It looks like you hang right where it gets garbled for Knut. Hmm, yeah. So I tried enabling just one core by setting default CONFIG_MAX_PHYSICAL_CPUS=1 default CONFIG_MAX_CPUS=1 * CONFIG_MAX_PHYSICAL_CPUS default CONFIG_LOGICAL_CPUS=1 I think you need to set CONFIG_LOGICAL_CPUS=0 to disable the siblings. I got it to compile by moving the nb_ function it can't find into the #endif above it. * AP 02 didn't start timeout:0001 * AP 03 didn't start timeout:0001 Begin FIDVID MSR 0xc0010071 0x30ae00a3 0x40034c40 FIDVID on BSP, APIC_id: 00 BSP fid = 10600 Wait for AP stage 1: ap_apicid = 1 fidvid_bsp_stage1: time out while reading from ap 01 Wait for AP stage 1: ap_apicid = 2 fidvid_bsp_stage1: time out while reading from ap 02 Wait for AP stage 1: ap_apicid = 3 It's still trying to start the APs. Right. Setting CONFIG_LOGICAL_CPUS to zero and making sure that conditional on CONFIG_LOGICAL_CPUS at the top of northbridge.c does not apply fixed that. Should this go into the tree? --- northbridge/amd/amdfam10/northbridge.c (revision 4978) +++ northbridge/amd/amdfam10/northbridge.c (working copy) @@ -31,10 +31,10 @@ #include cpu/x86/lapic.h -#if CONFIG_LOGICAL_CPUS==1 #include cpu/amd/quadcore.h #include pc80/mc146818rtc.h -#endif #include chip.h #include root_complex/chip.h and by adding a return at the very beginning of start_other_cores in cpu/amd/quadcore/quadcore.c which gets me a bit further, but not much. It hangs in the mcp55_early_pcie_setup function in southbridge/nvidia/mcp55/mcp55_early_setup_car.c Log attached. Anything else I should try? If inl and outl are hanging, I would dump the routing registers and read the device's IDs to see what's going wrong. I'm not very familiar with how the fam10 code works, but dumping the routing registers should be mostly cut and paste from the k8/util.c code. Right. I've done that - log attached. I'm dumping with showallroutes(BIOS_DEBUG, PCI_DEV(0, 0x18, 1)); I'm not sure what to make of the dump though (attached). Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator minicom-20091222ad-ram-on-both-cpus.cap Description: application/cap -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang
On Tue, Dec 22, 2009 at 04:11:06PM -0700, Myles Watson wrote: Right. Setting CONFIG_LOGICAL_CPUS to zero and making sure that conditional on CONFIG_LOGICAL_CPUS at the top of northbridge.c does not apply fixed that. Should this go into the tree? --- northbridge/amd/amdfam10/northbridge.c (revision 4978) +++ northbridge/amd/amdfam10/northbridge.c (working copy) @@ -31,10 +31,10 @@ #include cpu/x86/lapic.h -#if CONFIG_LOGICAL_CPUS==1 #include cpu/amd/quadcore.h #include pc80/mc146818rtc.h -#endif #include chip.h #include root_complex/chip.h I like just moving the endif to protect nb_cfg_54, if it would work. It compiles for me. --- northbridge/amd/amdfam10/northbridge.c (revision 4978) +++ northbridge/amd/amdfam10/northbridge.c (working copy) @@ -1235,7 +1235,6 @@ disable_siblings = !CONFIG_LOGICAL_CPUS; #if CONFIG_LOGICAL_CPUS == 1 get_option(disable_siblings, quad_core); -#endif // for pre_e0, nb_cfg_54 can not be set, ( even set, when you read it //still be 0) @@ -1243,6 +1242,7 @@ //and differ d0 and e0 single core nb_cfg_54 = read_nb_cfg_54(); +#endif #if CONFIG_CBB dev_mc = dev_find_slot(0, PCI_DEVFN(CONFIG_CDB, 0)); //0x00 OK - with that patch it builds and boots, and the output looks similar (but not identical. See http://ward.vandewege.net/coreboot/h8dme/fam10/minicom-20091222af-ram-on-both-cpus.cap The only difference is this -MMIO(b8)00-31a4f2, -(0,1), , , CPU disable 0, Lock 0, Non posted 0 +MMIO(b8)00-31a6b2, -(0,1), , , CPU disable 0, Lock 0, Non posted 1 which may be entirely unrelated? I'll look at that other register tomorrow. Thanks! Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] fam10/newconfig on supermicro h8dme - early hang
Hi all, I'm trying to port the h8dme to fam10. My test hardware has two quad core CPUs and 32G of ram. I'm seeing a hang very early on during boot: --- coreboot-2.0.0-r4978:4979M_h8dme_fam10_Fallback Wed Dec 16 17:29:28 EST 2009 starting... BSP Family_Model: 00100f42 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = microcode: equivalent rev id = 0x1041, current patch id = 0x microcode: rev id (1062) does not match this patch. microcode: Not updated! Fix microcode_updates[] cpuSetAMDMSR done 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() cpuSetAMDPCI 00 done cpuSetAMDPCI 01 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f24 F3xD8: 03001615 F3xDC: 5322 Prep FID/VID Node:01 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f24 F3xD8: 03001615 F3xDC: 5322 setup_remote_node: 01 done Start node 01 done. bsp_apicid=00 pre wait_all_co --- It stops in the middle of the output there (hang). This is against svn head. I'm building with xgcc 4.4.1 (same problem with stock Ubuntu gcc 3.4). I'm not sure what I'm doing wrong; any pointers to things that I could try? I've uploaded the code I have so far here, in case you're interested: http://ward.vandewege.net/coreboot/h8dme/fam10/src-mainboard-supermicro-h8dme_fam10.tgz http://ward.vandewege.net/coreboot/h8dme/fam10/targets-supermicro-h8dme_fam10.tgz Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot hangs on my AMD fam10 board(updatedebugmessage).
On Mon, Nov 02, 2009 at 02:25:23PM +0800, Bao, Zheng wrote: Now I found that the system doesn't hang. It just decompresses the image. It is unbearably slow. Do you guys know why it does so slowly? Ah! I saw that too on Fam10. Mansoor suggested setting CONFIG_XIP_ROM_BASE to solve this. Does that help? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4886 - in trunk/coreboot-v2/util: . amdtools amdtools/example_input
Hi Carl-Daniel, On Wed, Oct 28, 2009 at 11:22:08PM +0100, Carl-Daniel Hailfinger wrote: was it intentional that you placed these tools below coreboot-v2/ in the tree? Hmm, not in so much other than that there are a whole bunch of subdirectories there, so I assumed that was the best place. What's our current thinking on that? I'd be happy to svn move them... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]
On Thu, Oct 22, 2009 at 09:16:14AM -0600, Myles Watson wrote: RAM end at 0x0020 kB Lower RAM end at 0x0020 kB Ram3 Before starting clocks: Before memreset: cpu is pre_c0 after first udelay OK. So the timer worked for the first udelay... Does it only freeze when you have both CPUs enabled? Have you tried it with the no_smp patch again? I'm grasping at straws. This is starting to sound like all the weirdness I was seeing when working on the h8dmr fam10 port a few months ago. Are you sure it hangs? I thought so at first as well, but it turned out that things were running extremely slowly when compiling with gcc 4.3 (32 bit). If I waited 5 minutes or so eventually the board would boot. Can you reproduce a hang when changing CONSOLE_LOGLEVEL ? In my case the board would just hang if I lowered the default loglevel to something less than 8. I never did figure out what was going on there. Ron thought perhaps there was a cache issue. I put a file in the tree with the issues I ran into src/mainboard/supermicro/h8dmr_fam10/README I haven't been able to revisit yet as that particular box is in production. What toolchain are you using? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Resend: [PATCH] add h8dmr fam10 target
On Tue, Sep 22, 2009 at 03:29:05PM +0200, Peter Stuge wrote: Ward Vandewege wrote: Add supermicro h8dmr fam10 target. This is largely a mashup of the tyan s2912 fam10 and h8dmr k8 targets. Many, many thanks to Marc, Myles, Patrick and Stepan for all their help with this, and to Arne for doing the s2912 fam10 port. Build and boot tested. Signed-off-by: Ward Vandewege w...@gnu.org Acked-by: Peter Stuge pe...@stuge.se r4693. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Resend: [PATCH] add h8dmr fam10 target
On Tue, Sep 22, 2009 at 06:43:10AM -0700, ron minnich wrote: On Tue, Sep 22, 2009 at 6:42 AM, ron minnich rminn...@gmail.com wrote: I think this description of problems with the port ought to be in the target file in a README. ^^directory, sorry I have done so. I need to do some more testing on this hardware, but it's in production so that's a little hard right now. I'm going to work on a supermicro h8dme fam10 port now, which is a very similar board, so hopefully I'll be able to try the suggestions in this thread on that. Thanks! Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 06:03:38AM +0200, Daniel Mack wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. Yeah, known issue. The linux kernel driver stupidly assumes that all firmware sets up the GPIOs at the same IO port. The kernel driver should look up the msr and then do the right thing, but it does not. I think Peter Stuge may have a patch for the LED driver... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 06:04:57PM +0200, Peter Stuge wrote: Myles Watson wrote: Also, when booting Linux, the LED driver does not work with coreboot for me. The issue is that the driver is using a hard coded base address rather than finding out what is actually programmed into the device, and because coreboot doesn't assign resources exactly like the factory BIOS, the driver can't find the hardware. Depending on the address, that could be easy to fix. If it is below 0x1000 it is almost trivial. It's at 6000 something, and I don't like to. I would much prefer the driver not make assumptions for no da^Wreason. I think the driver assumes CS5536_BASE = 0x06100 Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tyan s2881 Kconfig
On Wed, Sep 23, 2009 at 11:13:11AM -0600, Myles Watson wrote: On Wed, Sep 23, 2009 at 10:56 AM, ron minnich rminn...@gmail.com wrote: Currently, because they are so simple, we don't have makefile.inc files for i2c drivers. see serengeti_cheetah: driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o Should it be a driver? In the old config it was just an object. This is admittedly inconsistent, but it saves a lot of unnecessary makefile.inc stuff. No problem. I just missed it. $39 for those boards is pretty attractive, do you have a link? http://www.pacificgeek.com/product.asp?id=847374 Argh, can not resist. Ordered :) Good for spare parts, too - I've still got a couple of those out in the field... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unstable AMD Fam10h boot
On Sun, Sep 13, 2009 at 06:46:38PM -0600, Marc Jones wrote: Here is a patch that fixes the cf8 config access. Not complicated like I initially recalled. Thanks to Ralf for pointing out the bug. This needs testing. Anyone? We've got a couple H8DME/fam10 boxes coming this week, so I should be able to test this in a couple days. Will do as soon as we get the hardware. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unstable AMD Fam10h boot
On Sat, Sep 05, 2009 at 10:46:57AM -0700, ron minnich wrote: On Sat, Sep 5, 2009 at 10:36 AM, Stefan Reinauerste...@coresystems.de wrote: Another idea would be to get rid of SMP setup in CAR stage. It sounds highly funky to me anyways. - Why are we doing this anyways? o Is there a reason? o No other SMP system except K10 does this. * How many ms do we benefit from that? (Honest question). Any at all? This may fix one problem, but it does not fix the general problem: using cf8/cfc is not going to be safe on multiple cores, from my understanding. Not to complicate matters even further, but since we are talking about locking - will any of this improve the 'many cores talking to serial at once' problem? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PATCH: do not rely on tempfile being available
On Wed, Sep 02, 2009 at 04:12:21PM -0400, Bernie Innocenti wrote: Signed-off-by: Bernie Innocenti ber...@codewiz.org Build fix: add a fallback for systems where tempfile is missing Acked-by: Ward Vandewege w...@gnu.org Committed in r271. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] K8 machine with (a lot of) ram from 2 vendors keeps resetting
Hi Marc, On Wed, Sep 02, 2009 at 04:03:45PM -0600, Marc Jones wrote: With the proprietary BIOS, this setup works perfectly. That said, the manual for the board does say it's not recommended to mix memory types. Our system integrator mentions that when 16 banks are used, the memory runs at maximum 533MHz. As we talked about, it looks like the memory is sized correctly and the next thing to try forcing the memory speed slower. 8 dual rank dimms (16 banks) s[eed limitation might be spec'd or errata. A check might need to go into the main k8 mem init code. I've forced the speed down to 533MHz with this patch: --- src/northbridge/amd/amdk8/raminit_f.code(revision 4625) +++ src/northbridge/amd/amdk8/raminit_f.code(working copy) @@ -1811,6 +1811,10 @@ } min_latency = 3; + // Force minimum cycle time to 3.75ns (i.e. 266MHz) + min_cycle_time = 0x375; + + printk_raminit(1 bios_cycle_time: %08x\n, bios_cycle_time); printk_raminit(1 min_cycle_time: %08x\n, min_cycle_time); /* Compute the least latency with the fastest clock supported Which appears to do the right thing, but the behavior is unchanged. Here's a boot log prior to the patch: http://ward.vandewege.net/coreboot/h8dme/minicom-20090902-with-64G-samsung-on-cpu1-kingston-on-cpu2-before-533MHz-limit.cap and here's after the patch: http://ward.vandewege.net/coreboot/h8dme/minicom-20090902-with-64G-samsung-on-cpu1-kingston-on-cpu2-after-533MHz-limit.cap This is with all samsung ram on CPU1 and all kingston ram on CPU2, as you suggested on irc. Anything else I should try? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP dl145 g3
On Tue, Aug 25, 2009 at 09:13:38AM +0200, samuel wrote: I'm using the port of the HP DL145 G3 on two machines quite succesfully. There is one single problem with it. If I do not boot the kernel with 'clocksource=tsc' the time on the machine runs at double speed. Do you want me to file a bug for this? Or is adding a cmdline option considered a good solution? I think that should be considered a bug. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unstable AMD Fam10h boot
Hi Patrick, On Tue, Aug 25, 2009 at 02:53:19PM +0200, Patrick Georgi wrote: I have some issues with an Fam10h board here. Every once in a while, boot fails with FIXME! CPU Version unknown or not supported!. The CPU Version mask that is calculated at the location the patch changes is 0x10efff. This value appears if the result of the cpuid call (or NB probe) is 0xff (the highest 8 bits aren't counted in, it might be 0x, too)' I've seen this occasionally, too. I suspected compiler issues again... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memtest86
On Thu, Aug 13, 2009 at 10:08:00AM -0600, Myles Watson wrote: Has anyone used memtest86 as a payload recently? I can't get it to work with qemu or Serengeti. On Qemu it executes outside of RAM, and on Serengeti it writes garbage to the screen. I have gotten it to work 6 months or so ago iirc, but it highly depended on the version I tried. I think, maybe, that 3.4 was working for me but I'm not sure. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tyan S2912[Fam10] HTX problem
Hi Maximilian, On Tue, Aug 11, 2009 at 04:12:39PM +0200, Maximilian Thuermer wrote: I am trying to get an HTX plug in card running on a Tyan S2912 Fam10 System. I tried both Barcelona and Shanghai CPUs and both system setups ended booting during PCI scanning. Do you mean *re*booting? I've seen some of that. Are you using gcc 3.x or 4.x to compile, and on 32 or 64 bit? I've found there are issues with gcc 4.3 (even when built with the nice coresystems build-your-own-toolchain script). The most reliable compiler for coreboot in my experience is still gcc 3.4. Also, are you sure your CONFIG_HT_* settings are correct? I found that CONFIG_HT_CHAIN_UNITID_BASE really has to be 1 to get a bootable system with mcp55 on fam10. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
On Thu, Aug 06, 2009 at 10:26:38AM +0800, Bao, Zheng wrote: I am trying to port the ddr3 feature. I will submit a full patch to replace this one. Sounds good, thanks. I won't be able to test until the end of August though, but perhaps someone else can ack before then. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] seabios head breaking irqs?
Hi Kevin et al, I just tried seabios head on my h8dmr fam10 system, and got rather odd results - suddenly I am seeing irq problems. I was using a seabios checkout from 20090701 before, which shows no issues. Here are boot logs: Not OK: http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-gf.cap OK: http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-gg.cap I'm not sure if this could be caused by seabios, or if perhaps it's yet another toolchain problem. When reverting to the older seabios, the irq problems went away again. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] solved - Re: fam10/h8dmr: extreme slowness in CBFS memset /memcpy
On Tue, Jul 21, 2009 at 08:23:22AM -0600, Myles Watson wrote: It's actually just a plain byte-by-byte assignment in c, see src/lib/memset.c. It would be interesting to see if you make it 4 bytes at a time if it is 4x faster. We found out after adding an extra MTRR over the flash chip, which did not change anything. Did you disable and re-enable the cache so that the settings take effect? Hmm, we tried adding it here src/cpu/amd/car/clear_init_ram.c in function set_init_ram_access, which already sets an mtrr. I always wondered about that one. The thing that makes it hard to debug is that it will read back correctly even if it hasn't taken effect. Thanks - will see if I can try some of these things. Good luck, So - you're not going to believe this. Compiler issue. I was compiling with gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 on 32 bit. I noticed that about one in every 10 burn/boot cycles or so, the slowness would not be there. So I switched back to gcc-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-8ubuntu2) on 32 bit, and it's gone altogether, every time. Is anyone else using gcc 4.3 (32 bit) to compile coreboot? Thanks! Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot cbfs incorrect bootblock size
Hi Arnaud, On Thu, Jul 23, 2009 at 02:37:52PM +0200, Arnaud Maye wrote: I am trying to compile coreboot with cbfs support, everything goes well until it tries to create the cbfs image. ./cbfs/cbfstool ./coreboot.rom create 2097152 131072 ./coreboot.rom.bootlock (cbfstool) E: The bootblock size is not correct (2097152 vs 131072) 131072 is 128kB and 2097152 is 2MB. These are the settings I have in my target's confg.lb file. option CONFIG_ROM_IMAGE_SIZE = 128 * 1024 option CONFIG_ROM_SIZE = 2 * 1024 * 1024 Anyone knows what I am not doing or not doing correctly? See http://www.coreboot.org/pipermail/coreboot/2009-June/049363.html where Patrick explained how to convert a board to CBFS. I've used those instructions with success before. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/h8dmr: extreme slowness in CBFS memset / memcpy
On Tue, Jul 21, 2009 at 06:25:38AM -0600, Myles Watson wrote: Following up on this - Patrick helped in IRC this evening, and we came to the conclusion that it's probably *not* an MTRR issue, since we figured out the code seems to set MTRRs properly. I wonder what else could cause it to be so slow? It's especially surprising for the memset, which is pretty simple. Does it use movnti for that? It's actually just a plain byte-by-byte assignment in c, see src/lib/memset.c. We found out after adding an extra MTRR over the flash chip, which did not change anything. Did you disable and re-enable the cache so that the settings take effect? Hmm, we tried adding it here src/cpu/amd/car/clear_init_ram.c in function set_init_ram_access, which already sets an mtrr. This gets called just before CAR is disabled I think. And then we found the mtrr set in src/cpu/amd/car/cache_as_ram.inc which looks like it *should* do the right thing. But that's assembler of course. I don't suppose there's a way to print debug info from right there? I guess I would: 1. Add some little benchmark loops reading/writing different areas a. read ROM time it b. read from RAM (cached area) and time it c. read from RAM (non-cached area) d. write to RAM (cached area) ... 2. disable MTRRs to see if it would go even slower. Sorry that's not much help, but I don't have a fam10 box to try things on. Thanks - will see if I can try some of these things. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: This patch is about the DA-C2 and RB-C2. Chip with install processor Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied to them are almost the same. Issues: 1. I really dont know what their nicknames are (Shanghai C2 or something). 2. About the mc_patch_0186.h, I dont know if it is allowed to be released. If you really need it, please contact AMD Inc to see if it is public. 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is just half tested. I am not confident it is 100% correct. Zheng Signed-off-by: Zheng Bao zheng@amd.com With this patch, I can still boot my system with 00100F42h (RB-C2) CPUs - Opteron 2372HE. Acked-by: Ward Vandewege w...@gnu.org Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
On Mon, Jul 20, 2009 at 10:10:13AM +0800, Bao, Zheng wrote: According to the Revision Guide, I think there might be several kinds of 0x100F42 RB-C2. They are AM2r2, AM3, F1207. Yeah, I see that on page 10 of the Fam10h Revision guide. Note that the link on http://developer.amd.com/documentation/guides/Pages/default.aspx to the Fam10 revision guide is wrong, the correct link is http://support.amd.com/us/Processor_TechDocs/41322.pdf The actual socket type should be read from CPUID_8001_EBX. Right? I think so, according to the revision guide... Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/h8dmr: extreme slowness in CBFS memset / memcpy
Following up on this - Patrick helped in IRC this evening, and we came to the conclusion that it's probably *not* an MTRR issue, since we figured out the code seems to set MTRRs properly. We found out after adding an extra MTRR over the flash chip, which did not change anything. The system boots fairly normally after the slowdowns, and appears to work normally. It sets three MTRRs further in the bootup process: reg00: base=0x ( 0MB), size=32768MB: write-back, count=1 reg01: base=0x8 (32768MB), size= 512MB: write-back, count=1 reg02: base=0xe000 (3584MB), size= 512MB: uncachable, count=1 Any thoughts on something else I should look at to debug this? Thanks, Ward. On Sun, Jul 19, 2009 at 09:23:21PM -0400, Ward Vandewege wrote: Hi all, I'm working on a fam10 tree for supermicro h8dmr. I'm using CBFS. It boots, but I'm struggling with some extreme slowness during boot. In particular, the memset function in src/lib/memset.c takes *minutes* to clear 1.2MB of ram. A little further CBFS does a memcpy which takes another 20 or 30 seconds: Stage: load fallback/coreboot_ram @ 2097152/1245184 bytes, enter @ 20 LOONG pause Stage: after memset on-stack variables at 00ffbec8 and 00ffbed4 cbfs_decompress: algo: 0 cbfs_decompress: uncompressed another lengthy pause cbfs_decompress: memcpy from 0xffbecc to 0xffbed0 for 0x2d304 bytes done Stage: done loading. The first, lengthly pause is new; it is apparently caused by something introduced between r4368 and r4440. The second pause was there already in r4368. I understand this may have something to do with MTRRs - looking at the logs it seems MTRRs are not set up until well after CBFS has dealt with coreboot_ram. This box has 32GB of ram, in case that makes a difference. Any suggestions? Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] fam10/h8dmr: extreme slowness in CBFS memset / memcpy
Hi all, I'm working on a fam10 tree for supermicro h8dmr. I'm using CBFS. It boots, but I'm struggling with some extreme slowness during boot. In particular, the memset function in src/lib/memset.c takes *minutes* to clear 1.2MB of ram. A little further CBFS does a memcpy which takes another 20 or 30 seconds: Stage: load fallback/coreboot_ram @ 2097152/1245184 bytes, enter @ 20 LOONG pause Stage: after memset on-stack variables at 00ffbec8 and 00ffbed4 cbfs_decompress: algo: 0 cbfs_decompress: uncompressed another lengthy pause cbfs_decompress: memcpy from 0xffbecc to 0xffbed0 for 0x2d304 bytes done Stage: done loading. The first, lengthly pause is new; it is apparently caused by something introduced between r4368 and r4440. The second pause was there already in r4368. I understand this may have something to do with MTRRs - looking at the logs it seems MTRRs are not set up until well after CBFS has dealt with coreboot_ram. This box has 32GB of ram, in case that makes a difference. Any suggestions? Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] update AM2 CPU names as per AMD revision guide
See attached... Thanks, Ward. -- Ward Vandewege w...@gnu.org Bring AM2 cpu names up to date with the official Revision Guide for AMD NPT Family 0Fh Processors Rev. 3.42 March 2009, found at http://support.amd.com/us/Processor_TechDocs/33610_PUB_Rev3%2042v3.pdf This patch takes its data from Table 8. Build tested, and boot tested on a AMD Athlon(tm) Dual Core Processor 5050e. Signed-off-by: Ward Vandewege w...@gnu.org Index: src/cpu/amd/model_fxx/processor_name.c === --- src/cpu/amd/model_fxx/processor_name.c (revision 4407) +++ src/cpu/amd/model_fxx/processor_name.c (working copy) @@ -252,6 +253,7 @@ AMD Athlon(tm) 64 Processor FX-ZZ Processor; break; /* Socket AM2 */ + /* single core */ case 0x30015: processor_name_string = AMD Sempron(tm) Processor LE-1RR0; @@ -260,6 +262,10 @@ processor_name_string = AMD Athlon(tm) Processor LE-1ZZ0; break; + case 0x30036: + processor_name_string = + AMD Athlon(tm) Processor 1ZZ0B; + break; case 0x30041: case 0x30042: case 0x30043: @@ -269,11 +275,29 @@ processor_name_string = AMD Athlon(tm) 64 Processor TT00+; break; + case 0x30052: + processor_name_string = + AMD Sempron(tm) Processor RR50p; case 0x30064: case 0x30068: processor_name_string = AMD Sempron(tm) Processor TT00+; break; + case 0x30071: + case 0x30072: + processor_name_string = + AMD Sempron(tm) Processor TT0U; + break; + case 0x30082: + case 0x30083: + processor_name_string = + AMD Athlon(tm) Processor TT50e; + break; + case 0x30092: + processor_name_string = + AMD Athlon(tm) Neo Processor MV-TT; + break; + /* dual-core */ case 0x31016: processor_name_string = Dual-Core AMD Opteron(tm) Processor 12RR HE; @@ -290,6 +314,7 @@ processor_name_string = AMD Athlon(tm) X2 Dual Core Processor BE-2TT0; break; + case 0x31041: case 0x31042: case 0x31046: case 0x31048: @@ -301,6 +326,27 @@ processor_name_string = AMD Athlon(tm) 64 FX-ZZ Dual Core Processor; break; + case 0x31066: + processor_name_string = + AMD Sempron(tm) Dual Core Processor RR00; + break; + case 0x31073: + processor_name_string = + AMD Athlon(tm) Dual Core Processor TT50e; + break; + case 0x31076: + case 0x31077: + processor_name_string = + AMD Athlon(tm) Dual Core Processor TT00B; + break; + case 0x31083: + processor_name_string = + AMD Athlon(tm) Dual Core Processor TT50B; + break; + case 0x31091: + processor_name_string = + AMD Athlon(tm) X2 Dual Core Processor TT50e; + break; /* Socket S1g1 */ case 0x00012: processor_name_string = -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] update Socket F CPU names as per AMD revision guide
See attached...
Thanks,
Ward.
--
Ward Vandewege w...@gnu.org
Bring Socket F cpu names up to date with the official
Revision Guide for AMD NPT Family 0Fh Processors
Rev. 3.42 March 2009, found at
http://support.amd.com/us/Processor_TechDocs/33610_PUB_Rev3%2042v3.pdf
This patch takes its data from Table 7.
Build tested.
Signed-off-by: Ward Vandewege w...@gnu.org
Index: src/cpu/amd/model_fxx/processor_name.c
===
--- src/cpu/amd/model_fxx/processor_name.c (revision 4407)
+++ src/cpu/amd/model_fxx/processor_name.c (working copy)
@@ -207,6 +207,10 @@
switch ((Socket 16) | (CmpCap 12) | (BrandTableIndex 4)
| PwrLmt) {
/* Socket F */
+ case 0x10012:
+ processor_name_string =
+ AMD Opteron(tm) Processor 22RR EE;
+ break;
case 0x11002:
processor_name_string =
Dual-Core AMD Opteron(tm) Processor 12RR EE;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] update S1g1 CPU names as per AMD revision guide
See attached... Thanks, Ward. -- Ward Vandewege w...@gnu.org Bring S1g1 cpu names up to date with the official Revision Guide for AMD NPT Family 0Fh Processors Rev. 3.42 March 2009, found at http://support.amd.com/us/Processor_TechDocs/33610_PUB_Rev3%2042v3.pdf This patch takes its data from Table 9. Build tested. Signed-off-by: Ward Vandewege w...@gnu.org Index: src/cpu/amd/model_fxx/processor_name.c === --- src/cpu/amd/model_fxx/processor_name.c (revision 4407) +++ src/cpu/amd/model_fxx/processor_name.c (working copy) @@ -302,10 +330,15 @@ AMD Athlon(tm) 64 FX-ZZ Dual Core Processor; break; /* Socket S1g1 */ + /* single core */ case 0x00012: processor_name_string = AMD Athlon(tm) 64 Processor TT00+; break; + case 0x0002c: + processor_name_string = + AMD Turion(tm) 64 Mobile Technology MK-YY; + break; case 0x00031: processor_name_string = Mobile AMD Sempron(tm) Processor TT00+; @@ -314,14 +347,34 @@ processor_name_string = Mobile AMD Sempron(tm) Processor PP00+; break; + case 0x0003c: + processor_name_string = + Mobile AMD Sempron(tm) Processor PP00+; + break; case 0x00042: processor_name_string = AMD Sempron(tm) Processor TT00+; break; + case 0x00064: + case 0x00066: + case 0x0006c: + processor_name_string = + AMD Athlon(tm) Processor TF-TT; + break; + /* dual-core */ + case 0x0101c: + processor_name_string = + AMD Sempron(tm) Dual Core Processor TJ-YY; + break; case 0x0102c: processor_name_string = AMD Turion(tm) 64 X2 Mobile Technology TL-YY; break; + case 0x01034: + case 0x0103c: + processor_name_string = + AMD Athlon(tm) 64 X2 Dual-Core Processor TK-YY; + break; case 0x01054: processor_name_string = AMD Athlon(tm) 64 X2 Dual Core Processor TT00+; -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] update AM2 CPU names as per AMD revision guide
On Fri, Jul 17, 2009 at 05:07:31PM +0200, Stefan Reinauer wrote: Ward Vandewege wrote: See attached... Thanks, Ward. Acked-by: Stefan Reinauer ste...@coresystems.de r4432. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] update Socket F CPU names as per AMD revision guide
On Fri, Jul 17, 2009 at 05:08:16PM +0200, Stefan Reinauer wrote: Bring Socket F cpu names up to date with the official Revision Guide for AMD NPT Family 0Fh Processors Rev. 3.42 March 2009, found at http://support.amd.com/us/Processor_TechDocs/33610_PUB_Rev3%2042v3.pdf This patch takes its data from Table 7. Build tested. Signed-off-by: Ward Vandewege w...@gnu.org Acked-by: Stefan Reinauer ste...@coresystems.de r4433. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] update S1g1 CPU names as per AMD revision guide
On Fri, Jul 17, 2009 at 05:09:13PM +0200, Stefan Reinauer wrote: Bring S1g1 cpu names up to date with the official Revision Guide for AMD NPT Family 0Fh Processors Rev. 3.42 March 2009, found at http://support.amd.com/us/Processor_TechDocs/33610_PUB_Rev3%2042v3.pdf This patch takes its data from Table 9. Build tested. Signed-off-by: Ward Vandewege w...@gnu.org Acked-by: Stefan Reinauer ste...@coresystems.de r4434. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
On Fri, Jul 17, 2009 at 10:01:35AM +0800, Bao, Zheng wrote: RB-C2 probably uses socket type AM3, which is not supported in Coreboot currently. I wonder if your board can go through the whole image. Hmm, I think there is some confusion here. If RB-C2 is really 0x100F42, then we are most certainly talking about Socket F. I have a few Opteron 2372 HE CPUs that are 0x100F42. You can contact tim.per...@amd.com about the patch releasing. Thank you, I have done so. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
Hi Zheng, On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: This patch is about the DA-C2 and RB-C2. Chip with install processor Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied to them are almost the same. Aha. That would perhaps explain why my box with Quad-Core AMD Opteron(tm) Processor 2372 HE with revision id 0x100f42 really does not like ucode revision 92 (it resets itself constantly). Issues: 1. I really dont know what their nicknames are (Shanghai C2 or something). Don't know about that. 2. About the mc_patch_0186.h, I dont know if it is allowed to be released. If you really need it, please contact AMD Inc to see if it is public. Well, I have my box booting without any ucode update. It would be nice to have mc_patch_0186.h public if that's the revision for my cpus. Who do I ask? 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is just half tested. I now have a working tree for Supermicro h8dmr with RB-C2 but it needs a bit more tweaking and cleaning up. I hope to get that ready soon so I can submit the patch to the list. I am not confident it is 100% correct. I'll test tonight or tomorrow and let you know how it goes. Thanks! Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] add pretty cpu name for Athlon X2 5050e
See attached. I'm not sure if I could predict the IDs for the 4050e/4450e/4850e - anyone know? I only have a 5050e. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Add pretty name for AMD Athlon(tm) 64 X2 Dual Core Processor 5050e. Boot tested. Signed-off-by: Ward Vandewege w...@gnu.org Index: src/cpu/amd/model_fxx/processor_name.c === --- src/cpu/amd/model_fxx/processor_name.c (revision 4407) +++ src/cpu/amd/model_fxx/processor_name.c (working copy) @@ -301,6 +302,10 @@ processor_name_string = AMD Athlon(tm) 64 FX-ZZ Dual Core Processor; break; + case 0x31073: + processor_name_string = + AMD Athlon(tm) 64 X2 Dual Core Processor TT50e; + break; /* Socket S1g1 */ case 0x00012: processor_name_string = -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What is the way to add a VGA ROM space in target\xx\xx\Config.lb
Hi Zheng, On Wed, Jul 15, 2009 at 05:55:12PM +0800, Bao, Zheng wrote: We want to get a space about 50K for VGA ROM like dbm690t does. I tried CONFIG_ROM_SIZE, CONFIG_ROM_IMAGE_SIZE, but they both don't work. What can we do? Look at the example in pcengines/alix.1c: ## CONFIG_ROM_SIZE is the total number of bytes allocated for coreboot use ## (normal AND fallback images and payloads). Leave 36k for VSA. option CONFIG_ROM_SIZE = (512 * 1024) - (36 * 1024) So, CONFIG_ROM_SIZE is the place to do that. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI emulator
On Wed, Jul 15, 2009 at 05:07:23PM -0700, ron minnich wrote: any comments on this one? http://microcontrollershop.com/product_info.php?cPath=180products_id=3406 Meh, requires Windows... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] m57sli, seabios and gpxe - kernel booting issues (BUG: INT 14 etc)
On Tue, Jul 07, 2009 at 10:51:56PM -0400, Ward Vandewege wrote: On Wed, Jul 08, 2009 at 12:53:02AM +0200, Peter Stuge wrote: Ward Vandewege wrote: I'm trying to do a GPXE boot from seabios with coreboot on m57sli, .. With 2.6.30, I get absolutely nothing, the kernel just hangs without output. That's with the multi-segment patched mkelfImage or with the ordinary older mkelfImage. Are you sure mkelfImage is good also for GPXE? Oh, and did you try sending the plain vmlinux ELF? Hmmm, good question. I just assumed - these machines currently run an old version of coreboot with etherboot, which takes mkelfImage generated files. Will test and report back... OK. For the record, it works perfectly if you use wraplinux. I guess there is a bug somewhere in mkelfImage... http://git.etherboot.org/?p=wraplinux.git;a=summary Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] m57sli, seabios and gpxe - kernel booting issues (BUG: INT 14 etc)
Hi Kevin et al, I'm trying to do a GPXE boot from seabios with coreboot on m57sli, and I'm not getting very far. I'm using git/svn head for GPXE, seabios and coreboot. I've tried various kernels - 2.6.22, 2.6.24, 2.6.27, 2.6.28 and 2.6.30 (all ubuntu prebuilt kernels). With 2.6.30, I get absolutely nothing, the kernel just hangs without output. That's with the multi-segment patched mkelfImage or with the ordinary older mkelfImage. With 2.6.28-13-generic I get (manually copied, so there might be transcription errors in this...): BUG: Int 14: CR2 b0f0 EDI ESI EBP c072bf3c ESP c072bf1c EBX 0046 EDX 000e ECX EAX b0f0 err EIP c0119891 CS 0060 flg 00010046 Stack: c011a26e 0046 0046 c072bf48 c0118a66 00f3390c c072bf60 c04fcb2f c05f62e0 c07dba60 00f3390c c072bfb8 c073b44c c05eb8b0 0080 00f3390c c05f2c18 0010 008760ab With 2.6.27-14-generic I get PANIC: early exception 0e rip 10:8022d621 error 0 cr2 5fc0f0 I found some references online that that panic might be caused by a kernel bug, fixed in 2.6.27.2. However, the same kernel boots fine if booted directly from seabios (from disk). In fact, *all* the kernels I tried boot fine from disk. So is GPXE doing something funky here, or is there something else going on? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] convert h8dmr to CBFS
The patch comment says it all... Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Convert Supermicro H8DMR to CBFS. Also clean up some whitespace in targets/supermicro/h8dmr/Config.lb and Config-abuild.lb. Importantly, this also sets default CONFIG_AP_CODE_IN_CAR=0 in src/mainboard/supermicro/h8dmr/Options.lb which is required to make this box boot since the changes that went in in r4315. Build tested with abuild, boot tested on physical hardware. Signed-off-by: Ward Vandewege w...@gnu.org Index: src/mainboard/supermicro/h8dmr/Config.lb === --- src/mainboard/supermicro/h8dmr/Config.lb (revision 4392) +++ src/mainboard/supermicro/h8dmr/Config.lb (working copy) @@ -58,7 +58,6 @@ depends $(CONFIG_MAINBOARD)/apc_auto.c option_table.h action $(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/apc_auto.c -o $@ end -ldscript /arch/i386/init/ldscript_apc.lb end end Index: src/mainboard/supermicro/h8dmr/Options.lb === --- src/mainboard/supermicro/h8dmr/Options.lb (revision 4392) +++ src/mainboard/supermicro/h8dmr/Options.lb (working copy) @@ -126,13 +126,9 @@ default CONFIG_ROM_SIZE=0x10 ## -## CONFIG_FALLBACK_SIZE is the amount of the ROM the complete fallback image will use +## CONFIG_FALLBACK_SIZE is the amount of the ROM the ROM part of the fallback image will use ## -#default CONFIG_FALLBACK_SIZE=131072 -#default CONFIG_FALLBACK_SIZE=0x4 - -#FALLBACK: 256K-4K -default CONFIG_FALLBACK_SIZE=0x3f000 +default CONFIG_FALLBACK_SIZE=CONFIG_ROM_IMAGE_SIZE #FAILOVER: 4K default CONFIG_FAILOVER_SIZE=0x01000 @@ -234,7 +230,7 @@ default CONFIG_DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000 default CONFIG_USE_INIT=0 -default CONFIG_AP_CODE_IN_CAR=1 +default CONFIG_AP_CODE_IN_CAR=0 default CONFIG_MEM_TRAIN_SEQ=1 default CONFIG_WAIT_BEFORE_CPUS_INIT=1 @@ -256,8 +252,9 @@ ### ## CONFIG_ROM_IMAGE_SIZE is the amount of space to allow coreboot to occupy. -default CONFIG_ROM_IMAGE_SIZE = 65536 +default CONFIG_ROM_IMAGE_SIZE = 0xf000 + ## ## Use a small 8K stack ## @@ -352,5 +349,5 @@ # CBFS # # -default CONFIG_CBFS=0 +default CONFIG_CBFS=1 end Index: targets/supermicro/h8dmr/Config-abuild.lb === --- targets/supermicro/h8dmr/Config-abuild.lb (revision 4392) +++ targets/supermicro/h8dmr/Config-abuild.lb (working copy) @@ -11,27 +11,25 @@ __LOGLEVEL__ romimage normal -option CONFIG_USE_FAILOVER_IMAGE=0 + option CONFIG_USE_FAILOVER_IMAGE=0 option CONFIG_USE_FALLBACK_IMAGE=0 - option CONFIG_ROM_IMAGE_SIZE=0x2 option COREBOOT_EXTRA_VERSION=.0-normal payload __PAYLOAD__ end romimage fallback -option CONFIG_USE_FAILOVER_IMAGE=0 + option CONFIG_USE_FAILOVER_IMAGE=0 option CONFIG_USE_FALLBACK_IMAGE=1 - option CONFIG_ROM_IMAGE_SIZE=0x2 option COREBOOT_EXTRA_VERSION=.0-fallback payload __PAYLOAD__ end romimage failover -option CONFIG_USE_FAILOVER_IMAGE=1 -option CONFIG_USE_FALLBACK_IMAGE=0 -option CONFIG_ROM_IMAGE_SIZE=CONFIG_FAILOVER_SIZE -option CONFIG_XIP_ROM_SIZE=CONFIG_FAILOVER_SIZE -option COREBOOT_EXTRA_VERSION=.0-failover + option CONFIG_USE_FAILOVER_IMAGE=1 + option CONFIG_USE_FALLBACK_IMAGE=0 + option CONFIG_ROM_IMAGE_SIZE=CONFIG_FAILOVER_SIZE + option CONFIG_XIP_ROM_SIZE=CONFIG_FAILOVER_SIZE + option COREBOOT_EXTRA_VERSION=.0-failover end buildrom ./coreboot.rom CONFIG_ROM_SIZE normal fallback failover Index: targets/supermicro/h8dmr/Config.lb === --- targets/supermicro/h8dmr/Config.lb (revision 4392) +++ targets/supermicro/h8dmr/Config.lb (working copy) @@ -23,44 +23,25 @@ mainboard supermicro/h8dmr romimage normal -# 48K for SCSI FW -#option CONFIG_ROM_SIZE = 475136 -# 48K for SCSI FW and 48K for ATI ROM -# option CONFIG_ROM_SIZE = 425984 -# 64K for Etherboot -#option CONFIG_ROM_SIZE = 458752 -# 44k for atixx.rom -#option CONFIG_ROM_SIZE = 479232 -option CONFIG_USE_FAILOVER_IMAGE=0 - option CONFIG_USE_FALLBACK_IMAGE=0 -# option CONFIG_ROM_IMAGE_SIZE=0x13800 -# option CONFIG_ROM_IMAGE_SIZE=0x18800 - option CONFIG_ROM_IMAGE_SIZE=0x2 -# option CONFIG_ROM_IMAGE_SIZE=0x15800 - option CONFIG_XIP_ROM_SIZE=0x4 - option COREBOOT_EXTRA_VERSION=$(shell cat ../../VERSION)_Normal - payload ../payload.elf + option CONFIG_USE_FAILOVER_IMAGE=0 + option CONFIG_USE_FALLBACK_IMAGE=0 + option COREBOOT_EXTRA_VERSION=$(shell cat ../../VERSION)_Normal + payload ../payload.elf end romimage fallback - option CONFIG_USE_FAILOVER_IMAGE=0 - option CONFIG_USE_FALLBACK_IMAGE=1 -# option CONFIG_ROM_IMAGE_SIZE=0x13800 -# option
Re: [coreboot] [PATCH] Handle programmer init errors, fix IT87* SPI init
On Sat, Jun 27, 2009 at 02:54:30PM +0200, Carl-Daniel Hailfinger wrote: Handle programmer init errors and abort. If the programmer didn't initialize correctly, it is pointless to continue. Fix standalone IT87* SPI init to set flashbus to NONE if no IT87* SPI communication is possible. Print the I/O port detected by the IT87* SPI code. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Ward Vandewege w...@gnu.org Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] killing the old flashrom tree
On Sat, Jun 27, 2009 at 03:02:33PM +0200, Carl-Daniel Hailfinger wrote: it seems some people still try to check out the old flashrom repo. That That would be me, working from old flashrom checkouts :/ code is not only ancient, it also lacks some fixes we have in newer code. I have the following two suggested options for deletion: 1. Remove the whole directory. 2. Remove all files in the directory and just keep the file which says the repo moved. Option 1 is probably best - I'd prefer it to error out in an obvious way. Svn wouldn't be able to follow a http redirect would it? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Sat, Jun 20, 2009 at 02:08:08PM -0400, Ward Vandewege wrote: On Sat, Jun 20, 2009 at 10:13:04AM -0700, ron minnich wrote: That is fine. That's a simple and straightforward change. How about we start with that. But let's not do THAT change until we fix ward's problem, and this has nothing to do with Ward's problem. Sorry for opening this can of worms ;) So, Stepan thinks that perhaps the stack is too small for the lzma decompression. I'm going to test next week with a 32KB stack (right now its at the default 8KB). This might solve booting, but I'll still have APs and BSP talking all at once, which I'm also seeing on K10. I tried with a 32KB stack and a 64KB stack, no change, the machine still resets itself: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624e.cap So, something else is going on. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Wed, Jun 24, 2009 at 11:24:10AM -0600, Myles Watson wrote: I did it by hand. Not pleasant, but see below. Too bad we both did it. Yeah, sorry guys :/ I had written a little script to print every other character but it didn't come out as clean as you both did it. [...] 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 I think it's interesting that this is the first duplicated message: Jumping to image. Jumping to image. Have you looked at what happens there that might be releasing an AP? Also, didn't you say it was dual node, dual core? I wonder why there are only two copies of the messages. Do you think they're both on the same node, or both the first processor per node? Correct, this is a dual node, dual core system, so 4 cores in total, two per cpu. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. I think you are right. So, we really need to get some sort of printk locking in there so that we can diagnose what's going on with less guesswork. There's this comment in src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c: /* wait for all the APs core0 started by finalize_node_setup. */ /* FIXME: A bunch of cores are going to start output to serial at once. * It would be nice to fixup prink spinlocks for ROM XIP mode. * I think it could be done by putting the spinlock flag in the cache * of the BSP located right after sysinfo. */ wait_all_core0_started(); I got a little lost in the whole locking discussion; is the above a way to ungarble the output in this particular case? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. Ugh, I spoke too soon. Booting with CONFIG_AP_CODE_IN_CAR off reduced me to 1 core. Sigh. Patrick, I'm really interested in figuring out why you are seeing none of these problems with the K8 boards you tested 4315 on. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 03:05:26PM -0400, Ward Vandewege wrote: On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. Ugh, I spoke too soon. Booting with CONFIG_AP_CODE_IN_CAR off reduced me to 1 core. Sigh. Disregard that - caused by something else. All cores are visible. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Sat, Jun 20, 2009 at 10:13:04AM -0700, ron minnich wrote: That is fine. That's a simple and straightforward change. How about we start with that. But let's not do THAT change until we fix ward's problem, and this has nothing to do with Ward's problem. Sorry for opening this can of worms ;) So, Stepan thinks that perhaps the stack is too small for the lzma decompression. I'm going to test next week with a 32KB stack (right now its at the default 8KB). This might solve booting, but I'll still have APs and BSP talking all at once, which I'm also seeing on K10. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
