coreboot November 2008

coreboot@coreboot.org

76 participants
490 discussions

Re: [coreboot] r3762 - trunk/coreboot-v2/src/mainboard/tyan/s2895
by Myles Watson 20 Nov '08

20 Nov '08

> This error was introduced by a trivial self-acked indent patch and was > never detected (because of a missing Config-abuild.lb) So is the Config-abuild.lb there now? Thanks, Myles

1 0

r3762 build service
by coreboot information 20 Nov '08

20 Nov '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "stepan" checked in revision 3762 to the coreboot source repository and caused the following changes: Change Log: OK, people, watch this. This is a school book example of why trivial indent patches just suck big time. This error was introduced by a trivial self-acked indent patch and was never detected (because of a missing Config-abuild.lb) So, indenting the code for no reason can make it a lot worse (read: break it) instead of improving it. I ask everyone to keep this in mind when going on indent-frenzy again. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Build Log: Compilation of supermicro:x6dhe_g has been fixed If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

r3762 - trunk/coreboot-v2/src/mainboard/tyan/s2895
by svn＠coreboot.org 20 Nov '08

20 Nov '08

Author: stepan Date: 2008-11-20 20:26:16 +0100 (Thu, 20 Nov 2008) New Revision: 3762 Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c Log: OK, people, watch this. This is a school book example of why trivial indent patches just suck big time. This error was introduced by a trivial self-acked indent patch and was never detected (because of a missing Config-abuild.lb) So, indenting the code for no reason can make it a lot worse (read: break it) instead of improving it. I ask everyone to keep this in mind when going on indent-frenzy again. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c =================================================================== --- trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c 2008-11-19 13:42:14 UTC (rev 3761) +++ trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c 2008-11-20 19:26:16 UTC (rev 3762) @@ -222,9 +222,8 @@ #if USE_FALLBACK_IMAGE == 1 failover_process(bist, cpu_init_detectedx); #endif -#endif real_main(bist, cpu_init_detectedx); - +#endif } #if USE_FAILOVER_IMAGE==0

1 0

Fwd: HT chains fixup
by Marc Jones 20 Nov '08

20 Nov '08

....and Myles reply On Wed, Nov 19, 2008 at 9:16 PM, Myles Watson <mylesgw(a)gmail.com> wrote: > > >> -----Original Message----- >> From: Marc Jones [mailto:marcj303@gmail.com] >> Sent: Wednesday, November 19, 2008 4:11 PM >> To: Myles Watson >> Subject: Re: [coreboot] HT chains fixup >> >> Myles, >> Hi, sorry to take so long to look at this. I have some possibly dumb >> questions. > > No problem. I appreciate the review. > >> What is gained by knowing the ht path? > When a HT chain is powered on, all the devices have the same UnitID (0) > The subordinate busses get assigned bus numbers in the order that they are > found by PCI scan, but they are found in the order of the chain. As you > assign each a device number, another device is visible at device 0 until the > end of the chain is found. > Right, But I think that unitid setting happens before device scanning and the dts is available. Once they are set there is no reason to change them. The only thing is that the pci bridge code >> Every HT bridge/tunnel under a >> CPU acts like a PCI device. Linux doesn't know about HT and I am not >> sure that the dts needs to. > > That's why I made ht devices morph into pci devices at chain enumeration > time. Once they're assigned UnitIDs it doesn't matter where they are in the > chain. > >> The exception being that coreboot needs to >> know the CPU that the bus comes off of. I feel like I am missing >> something obvious that you, Ron, and others understand. > > I'm getting just as much push back from everyone else. I'm not sure anyone > understands the code that well. I feel silly for having to rewrite so much > of it. It probably points to my lack of understanding. > >> What are you describing with and ht@? For example: >> + ht@0,a { >> + > /config/("southbridge/amd/amd8132/pcix.dts"); >> + }; >> + pci_a@0,1{ >> + > /config/("southbridge/amd/amd8132/apic.dts"); > > ht@0,a is ht chain 0, UnitID a. I wanted it to be explicit where the chains > end and what the numbers are. The way the code works is that it takes the > HT device and all the PCI devices that it implements off the list at once. > Without knowing which devices are HT, that's hard to tell. The code before > used a heuristic and a lot of #if statements. > > The reason I put pci_a here is that otherwise device 0,1 of the 8132 > collides with 0,1 of the 8111 (their dts names are the same.) > > The reason for specifying the chain number is that devices could be inserted > in a lot of places, and it is nice to be able to specify which one you mean. > Think of an 8-way box where you could replace any of the processors with a > co-processor. It gets ugly in a hurry. > >> I would think that the dts and device code would work with this for >> the 8132 device: >> + pci_a@0,0 { >> + > /config/("southbridge/amd/amd8132/pcix.dts"); >> + }; >> + pci_a@0,1{ >> + > /config/("southbridge/amd/amd8132/apic.dts"); > > Hopefully the explanation above helps here. > >> The HT is just a bus link.There is no HT bridge or device. The >> bridge/device acts as a PCI bridge/device and should be treated as >> such. > > This is true once the chain is enumerated, but the 8111 isn't visible until > the 8132 is moved out of the way, so it isn't just a link before a UnitID is > assigned. > >> I also don't understand when something is under the ht@0,6 vs when it >> should just be pci_6@x,y. All the onboard devices are directly on HT >> and the bridges to PCI/e/X are also on HT. (There is a question about >> this in the output also) > > ht just means it's a HT device function 0. It means that it consumes the > UnitID from the HT capability. All the others are sub-devices. > >> Another nit I have is that pci_18_0 is the top device. Physically it >> is but logically it isn't. The dts doesn't make sense when you compare >> it with the lspci. I don't know if this is really better but maybe >> something like this: > > My next patches will move everything from being a child of 18.0 to being a > child of the domain. That's assuming I ever get agreement for what I'm > doing :) I plan to have it look like this: > > domain { > /k8/domain > ht@0,a > ht@0,6 > pci@18,0 > pci@18,1 > pci@18,2 > pci@18,3 > pci@19,0 > ... > }; > > Then the only difference between lspci and the dts will be the ht > enumeration ordering. I do think that needs to be explicit. > >> >> pci@0,0(18,0){ >> pci@x,y { >> config.... >> }; >> ... >> pci@18,0 {}; >> }; >> >> That way the top level bus resources are pointed at the CPU device but >> the logical PCI connections are easy to follow. > > Yes. > >> There are some more question in your output below. >> >> On Mon, Nov 17, 2008 at 11:21 AM, Myles Watson <mylesgw(a)gmail.com> wrote: >> ... >> > Show all devs in tree form...After phase 3. >> > root(Root Device): enabled 1 have_resources 0 >> > cpus(CPU: 00): enabled 1 have_resources 0 >> > apic_0(APIC: 00): enabled 1 have_resources 0 >> > domain_0(PCI_DOMAIN: 0000): enabled 1 have_resources 0 >> > domain_0_pci_18_0(PCI: 00:18.0): enabled 1 have_resources 0 >> >> This might be easier to read if you use the lspci colon and period on >> the device numbers. >> For example domain_0_pci_18.0_ht_0:6 > I could do that. I don't know why Carl-Daniel and Ron decided on > underscores everywhere. It seems like they went back and forth for a while > on dts names. > >> >> > domain_0_pci_18_0_ht_0_6(PCI: 00:06.0): enabled 1 have_resources 0 > > This will be domain_0_ht_0_6 if I get my way. > >> What if this were a real PCI to PCI bridge? Would it be >> domain_0_pci_18_0_pci_0_6? > > Yes, but there's no such thing with an Opteron, right? It would have to be > another level down in the hierarchy like domain_0_ht_0_6_pci_6_0 (remember > that HT UnitID and PCI dev are the same, so ht_0_6 becomes pci_6_0.) > >> > domain_0_pci_18_0_ht_0_6_pci_0_0(PCI: 01:00.0): enabled 1 >> have_resources >> > 0 >> >> Why isn't this domain_0_pci_18_0_ht_0_6_pci_1_0_0? > Bus numbers get assigned as they're discovered, so they aren't mentioned in > the dts. That's why the 8111 has to be at 0x6 and the 8132 has to be at > 0xa, otherwise the 8132's busses get numbered first, and the southbridge > ends up on bus 3. Actually the 8111 just has to have a lower number. 0x0 > and 0x2 also work. > >> > domain_0_pci_18_0_ht_0_6_pci_0_1(PCI: 01:00.1): enabled 1 >> have_resources >> > 0 >> ... >> > domain_0_pci_18_0_pci_6_1_0(PCI: 00:07.0): enabled 1 have_resources 0 >> >> I really don't understand this one. It is a device on bus 0 so what >> does 6_1_0 mean? > > It's device 1 function 0 of the pci_6 ht device. Remember I had to add the > _6 so that it wouldn't have the same name as pci_a_1_0. I agree it's > confusing. I couldn't think of a really great way to do it. Maybe just > taking out the extra underscore would help: > > domain_0_pci6_0_1 > or naming it explicitly > domain_0_pciht6_0_1 > > I'm open to suggestions. >> >> > domain_0_pci_18_0_pci_6_1_0_ioport_2e(IOPORT: 2e): enabled 1 >> > have_resources 0 >> > domain_0_pci_18_0_pci_6_1_0_ioport_2e_pnp_child_0(PNP: 002e.0): >> enabled >> > 0 have_resources 0 >> > domain_0_pci_18_0_pci_6_1_0_ioport_2e_pnp_child_1(PNP: 002e.1): >> enabled >> > 0 have_resources 0 >> >> Putting the io on the subtractive device is good. >> ... > I'm glad you approve. I like it that you can trace the path there. > >> > Here are some of the next steps: >> > - Get video working. >> >> Do you know where the breakage is? > I think it's in resource allocation. It's really hard to follow, though. > In the end the 8132 claims the address space that should be for the video > buffer, and it never gets to the card. > > I'm in the middle of reorganizing resource allocation so that resources > always get read and allocated in order of the tree. I also think the > devices should get enabled in that order. > > Thanks for the good questions. One of the hard things about coreboot is > that there are so many specialties required to get it working. Some of the > folks on the list are amazing programmers, some have soldering and rework > skills, SuperIO knowledge,... I don't think anyone has it all. > > I didn't copy the list since you just sent it to me, but at some point I > might want to forward the answers to others. > > Thanks, > Myles > > > -- http://marcjstuff.blogspot.com/

2 3

Re: [coreboot] Coreboot on Tyan S2892
by Myles Watson 20 Nov '08

20 Nov '08

> > > SATA devices should be in legacy mode and filo should be able to load > your > > > kernel. The only challenge is getting the drive numbering lined up. > > > in buildrom do a make filo-config. You also need a grub like menu.lst > on > > > the drive. > > > > I thought there was no legacy mode because it's Nvidia's CK804. If > there is > > I went through a lot of pain for nothing (except learning of course :) > > Ah, it would be a controller limitation not a filo one. Sorry. I didn't > mean to confuse the issue. No problem. I should have been clearer in the original response. You probably helped clarify it for everyone else. Myles

5 26

Fwd: HT chains fixup
by Marc Jones 20 Nov '08

20 Nov '08

Sorry all, I didn't mean to take this offlist. Marc ---------- Forwarded message ---------- From: Marc Jones <marcj303(a)gmail.com> Date: Wed, Nov 19, 2008 at 4:10 PM Subject: Re: [coreboot] HT chains fixup To: Myles Watson <mylesgw(a)gmail.com> Myles, Hi, sorry to take so long to look at this. I have some possibly dumb questions. What is gained by knowing the ht path? Every HT bridge/tunnel under a CPU acts like a PCI device. Linux doesn't know about HT and I am not sure that the dts needs to. The exception being that coreboot needs to know the CPU that the bus comes off of. I feel like I am missing something obvious that you, Ron, and others understand. What are you describing with and ht@? For example: + ht@0,a { + /config/("southbridge/amd/amd8132/pcix.dts"); + }; + pci_a@0,1{ + /config/("southbridge/amd/amd8132/apic.dts"); I would think that the dts and device code would work with this for the 8132 device: + pci_a@0,0 { + /config/("southbridge/amd/amd8132/pcix.dts"); + }; + pci_a@0,1{ + /config/("southbridge/amd/amd8132/apic.dts"); The HT is just a bus link.There is no HT bridge or device. The bridge/device acts as a PCI bridge/device and should be treated as such. I also don't understand when something is under the ht@0,6 vs when it should just be pci_6@x,y. All the onboard devices are directly on HT and the bridges to PCI/e/X are also on HT. (There is a question about this in the output also) Another nit I have is that pci_18_0 is the top device. Physically it is but logically it isn't. The dts doesn't make sense when you compare it with the lspci. I don't know if this is really better but maybe something like this: pci@0,0(18,0){ pci@x,y { config.... }; ... pci@18,0 {}; }; That way the top level bus resources are pointed at the CPU device but the logical PCI connections are easy to follow. There are some more question in your output below. On Mon, Nov 17, 2008 at 11:21 AM, Myles Watson <mylesgw(a)gmail.com> wrote: ... > Show all devs in tree form...After phase 3. > root(Root Device): enabled 1 have_resources 0 > cpus(CPU: 00): enabled 1 have_resources 0 > apic_0(APIC: 00): enabled 1 have_resources 0 > domain_0(PCI_DOMAIN: 0000): enabled 1 have_resources 0 > domain_0_pci_18_0(PCI: 00:18.0): enabled 1 have_resources 0 This might be easier to read if you use the lspci colon and period on the device numbers. For example domain_0_pci_18.0_ht_0:6 > domain_0_pci_18_0_ht_0_6(PCI: 00:06.0): enabled 1 have_resources 0 What if this were a real PCI to PCI bridge? Would it be domain_0_pci_18_0_pci_0_6? > domain_0_pci_18_0_ht_0_6_pci_0_0(PCI: 01:00.0): enabled 1 have_resources > 0 Why isn't this domain_0_pci_18_0_ht_0_6_pci_1_0_0? > domain_0_pci_18_0_ht_0_6_pci_0_1(PCI: 01:00.1): enabled 1 have_resources > 0 ... > domain_0_pci_18_0_pci_6_1_0(PCI: 00:07.0): enabled 1 have_resources 0 I really don't understand this one. It is a device on bus 0 so what does 6_1_0 mean? > domain_0_pci_18_0_pci_6_1_0_ioport_2e(IOPORT: 2e): enabled 1 > have_resources 0 > domain_0_pci_18_0_pci_6_1_0_ioport_2e_pnp_child_0(PNP: 002e.0): enabled > 0 have_resources 0 > domain_0_pci_18_0_pci_6_1_0_ioport_2e_pnp_child_1(PNP: 002e.1): enabled > 0 have_resources 0 Putting the io on the subtractive device is good. ... > Here are some of the next steps: > - Get video working. Do you know where the breakage is? Marc -- http://marcjstuff.blogspot.com/ -- http://marcjstuff.blogspot.com/

1 0

r1047 - coreboot-v3/lib
by svn＠coreboot.org 20 Nov '08

20 Nov '08

Author: mraudsepp Date: 2008-11-20 13:20:35 +0100 (Thu, 20 Nov 2008) New Revision: 1047 Modified: coreboot-v3/lib/ramtest.c Log: Be silent in ram_check in non-debug loglevels As DBE61 support now runs ram_check for non-debug purposes and has expected failures on DBE61A, downgrade the per-address looped fail notification printk and other messages from BIOS_ERR to BIOS_DEBUG. Document that if something is wanted to be reported in non-debug loglevels, one should do so in the caller based on the return value. Tweak a debug string in ram_verify to be more descriptive. Signed-off-by: Mart Raudsepp <mart.raudsepp(a)artecdesign.ee> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: coreboot-v3/lib/ramtest.c =================================================================== --- coreboot-v3/lib/ramtest.c 2008-11-19 03:11:52 UTC (rev 1046) +++ coreboot-v3/lib/ramtest.c 2008-11-20 12:20:35 UTC (rev 1047) @@ -97,11 +97,11 @@ value = ram_read_phys(addr); if (value != addr) { /* Display address with error. */ - printk(BIOS_ERR, "Fail @%lx Read value=%lx\n", + printk(BIOS_DEBUG, "Fail @%lx Read value=%lx\n", addr, value); /* Abort after 256 verify errors. */ if (++i > 256) { - printk(BIOS_ERR, "Aborting.\n"); + printk(BIOS_DEBUG, "256 errors seen, aborting.\n"); break; } } @@ -111,7 +111,7 @@ printk(BIOS_DEBUG, "%lx\r", addr); /* Print whether or not the verify failed. */ - printk(BIOS_DEBUG, "\nDRAM range %sverified.", i ? "_NOT_ " : ""); + printk(BIOS_DEBUG, "\nDRAM range %sverified.\n", i ? "_NOT_ " : ""); return i; } @@ -121,6 +121,8 @@ * * This is much more of a "Is my DRAM properly configured?" test than * a "Is my DRAM faulty?" test, though. + * If you want to show a message of the result in non-debug loglevels, be sure + * to do so yourself based on the return value. * * @param start The beginning of the RAM area. * @param stop The end of the RAM area.

1 0

[PATCH] v3: Add writeback_range() to K8 code
by Carl-Daniel Hailfinger 20 Nov '08

20 Nov '08

We will need writeback_range() to implement S3 suspend properly on K8, GeodeLX and Qemu. C7 and Core2 are not affected. Either way, writeback_range() is a good thing to have, so start implementing it on K8. I uncovered a bug in the AMD manuals. That bug is annotated in the code as well to make sure nobody wants to "fix" this code. Compile tested on DBM690T and Qemu. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: corebootv3-writeback_range/include/arch/x86/cpu.h =================================================================== --- corebootv3-writeback_range/include/arch/x86/cpu.h (Revision 1046) +++ corebootv3-writeback_range/include/arch/x86/cpu.h (Arbeitskopie) @@ -329,5 +329,6 @@ void setup_resource_map(const struct rmap *rm, u32 max); EXPORT_SYMBOL(setup_resource_map); +void writeback_range(unsigned long start, unsigned long len); #endif /* ARCH_X86_CPU_H */ Index: corebootv3-writeback_range/arch/x86/amd/k8/stage1.c =================================================================== --- corebootv3-writeback_range/arch/x86/amd/k8/stage1.c (Revision 1046) +++ corebootv3-writeback_range/arch/x86/amd/k8/stage1.c (Arbeitskopie) @@ -1,7 +1,7 @@ /* * This file is part of the coreboot project. * - * Copyright (C) 2007 Advanced Micro Devices, Inc. + * Copyright (C) 2008 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -39,6 +39,33 @@ } /** + * This function is processor specific. + */ +void writeback_range(unsigned long start, unsigned long len) +{ + unsigned long cachelinesize, i; + /* Number of quadwords flushed by CLFLUSH in bit 8..15 + * NOTE: The AMD64 Architecture Programmer's Manual Volume 3 rev 3.14 + * CLFLUSH section contradicts the AMD CPUID Specification rev 2.28 + * about where to find CLFLUSH size. + * I'm using the CPUID spec definition. + */ + cachelinesize = (cpuid_ebx(0x00000001) & 0xff00) >> 8; + /* Convert quadwords to bytes */ + cachelinesize <<= 3; + /* MFENCE before and after CLFLUSH is needed according to + * AMD64 Architecture Programmer's Manual Volume 3: CLFLUSH + */ + __asm__ volatile ("mfence"); + for (i = start; i < start + len; i += cachelinesize) { + __asm__ volatile ( + "clflush (%0) \n" + ::"a" (i)); + } + __asm__ volatile ("mfence"); +} + +/** * Disable Cache As RAM (CAR) after memory is setup. * * Unknown how to do this just yet. -- http://www.hailfinger.org/

1 0

[patch] i82810 WIP - fix for the BUFF_SC
by Elia Yehuda 20 Nov '08

20 Nov '08

this patch calculates BUFF_SC according to set of rules guessed out of some various results i came up with different DIMM setups. looking into this patch reveals it is just begging for optimization, so role up your sleeves, kick out those old optimization shoes, and see how you handle this better 8-) (uwe suggested using a table, and no argue there...) Signed-off-by: Elia Yehuda <z4ziggy(a)gmail.com>

1 0

[PATCH 5/5] Be less noisy in ram_check in non-debug loglevels
by Mart Raudsepp 19 Nov '08

19 Nov '08

Be less noisy in ram_check in non-debug loglevels As DBE61 support now runs ram_check for non-debug purposes and has expected failures, downgrade the per-address looped fail notification printk from BIOS_ERR to BIOS_DEBUG. To compensate promote the one-time result print from DEBUG to ERR if it was a failure. Signed-off-by: Mart Raudsepp <mart.raudsepp(a)artecdesign.ee> --- lib/ramtest.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/ramtest.c b/lib/ramtest.c index 02a4bdb..24af6b4 100644 --- a/lib/ramtest.c +++ b/lib/ramtest.c @@ -97,7 +97,7 @@ static int ram_verify(unsigned long start, unsigned long stop) value = ram_read_phys(addr); if (value != addr) { /* Display address with error. */ - printk(BIOS_ERR, "Fail @%lx Read value=%lx\n", + printk(BIOS_DEBUG, "Fail @%lx Read value=%lx\n", addr, value); /* Abort after 256 verify errors. */ if (++i > 256) { @@ -111,7 +111,7 @@ static int ram_verify(unsigned long start, unsigned long stop) printk(BIOS_DEBUG, "%lx\r", addr); /* Print whether or not the verify failed. */ - printk(BIOS_DEBUG, "\nDRAM range %sverified.", i ? "_NOT_ " : ""); + printk(i ? BIOS_ERR : BIOS_DEBUG, "\nDRAM range %sverified.\n", i ? "_NOT_ " : ""); return i; } -- 1.6.0.2

5 10

← Newer
1
...
13
14
15
16
17
18
19
...
49
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2008