coreboot December 2013

coreboot@coreboot.org

40 participants
108 discussions

Re: [coreboot] PCI MMCONF on amdfam10
by Kyösti Mälkki 17 Dec '13

17 Dec '13

On 12/16/2013 10:35 PM, ron minnich wrote: > On Fri, Dec 13, 2013 at 2:29 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > >> Yet we have had commit 032c23db for 5 months: > > which may mean, only, that the commit broke some things and nobody hit > those things until 5 months later? > > Which is not at all unusual with a change of this type. It's why we > prefer that commits that are this far-reaching come with some amount > of testing. > That patch changed 7 mainboards; which of them were tested? > Before merge, test on kontron/986-lcd-m as was recorded here: http://review.coreboot.org/#/c/3584/ Also lenovo x60 and t60 boards have been often built from master during the last 5 months. >> I remember a week or so after this was merged you made that comment about >> i945 on a related change. I requested literature reference or a test case to >> see if I should revert. I got neither and the revert never took place. > > It pays to listen to Stefan on matters such as these :-) > > There are at least two reasons that your request might not have been > satisfiable. > - the public docs and the hardware disagree (very common) > - the public docs and the NDA docs disagree (this is very common) > and the vendor knows it (also really common) > >> Until you are more specific on your statement, I am reading it as follows: >> >> Stefan added 'select MMCONF_SUPPORT_DEFAULT' on a mainboard with i945 >> and the board did not boot. > > And sometimes that's about as good a diagnosis as you can get. > > Expecting anything more is not always realistic. That's what makes > firmware so hard, sometimes. > > Meanwhile, we have a commit that broke some hardware. What do you want > to do about it? I agree with Aaron, things might need to be tweaked, > but ... > who's got that old hardware, and the time to do it? Do you have a > board of that ilk and the time to figure it out? > > How do you intend to resolve the problem caused by this commit? The process of deciding if i945 needs a fix has begun. As you may notice, the first thing was to try to find out if the original statement is reliable, backuped up by any documentation, or if the statement was made based on runs on some particular platform. So far no data from current and known codebase builds supports the statement that some PCI devices would not be accessible over MMCONF on platform with i945- From a fairly recent codebase we see PCI MMCONF setup for i945 had two flaws in design: a) There are PCI configuration access before MMCONF is enabled which need to be forced to use IO and b) With MMCONF_SUPPORT_DEFAULT, PCI configuration access in early ramstage would use IO instead and fail to access registers in range 0x100-0xfff. There is reason to believe i945 development platform had same problems, which questions the reliability of the made conclusions. Kyösti

2 1

Re: [coreboot] coreboot on amd A85 can't work
by Peter Stuge 17 Dec '13

17 Dec '13

David Hubbard wrote: > There is a #define that will turn on verbose output about the DDR3 > link training Holiday wishlist: Utility which makes all such #defines available and effective in an AGESA submenu in Kconfig. //Peter

1 0

Removing microcode updates from blobs
by mrnuke 17 Dec '13

17 Dec '13

Hi all, Following some recent discussions on IRC, we've see that some people just don't like us shipping microcode in the main repository. OK, microcode is a blob, so it belongs in blobs. Let's leave that at that. Kyösti and I are working on making all CPUs update microcode from CBFS. This is the first step in moving the microcode updates out of main. Our branches are already up on gerrit: Infrastructure (ready for review): http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+t… Intel branch (ready for review): http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+t… AMD branch (ready for review/needslove): http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+t… I've also started integrating the microcode updates for Intel CPUs in blobs. The branch is here (ready for review): http://review.coreboot.org/#/q/status:open+project:blobs+branch:master+topi… Once ALL that is done, we can start removing those updates from master (needslove): http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+t… This last branch is a WIP, but we should be able to have it build via Jenkins once all the other Intel stuff is done. And once ALL that is done, we'll be able to update Kconfig such that microcode is only included automatically when the blobs repository is enabled. This separation of blobs versus free code is only logical, and the end result is more options for the user. Reviews and testers highly appreciated. Let's get this done once and for all. Remember, this is a multi-step process with changes that are, sadly not trivial to keep track of. Alex

4 4

Re: [coreboot] coreboot on amd A85 can't work
by David Hubbard 16 Dec '13

16 Dec '13

I am also very familiar with that particular message. I had a failing CPU and I ended up replacing parts until it booted ok. Like Idwer said: it is not able to initialize any DDR3 RAM. There is a #define that will turn on verbose output about the DDR3 link training if the Vendor BIOS (from Asus) thinks the memory is ok. David

1 0

PCI MMCONF on amdfam10
by Kyösti Mälkki 16 Dec '13

16 Dec '13

Hi After commit 872c922 there is some trouble on PCI configuration access with Asus M4A785-M. This could apply to other amdfam10 too, although I have not yet received such reports. As the commit message stated, I had discovered that in the beginning of ramstage all PCI configuration access used the IO (0xcf8) method even though Kconfig specified MMCONF_SUPPORT_DEFAULT which should imply all PCI config access is done with MMCONF unless IO is explicitly requested. AFAICS, for all cores the MSR enabling MMCONF is programmed very early in the romstage. So second option for failure is there exists cases where IO must be used instead of MMCONF, but I could not find such documentation yet. I hope Dennis can reproduce the failure log and post it in the next few days. Kyösti

4 6

Re: [coreboot] [coreboot-gerrit] Patch set updated for coreboot: 26eaf9d Family14: Add support for solder-down DDR memory
by mrnuke 16 Dec '13

16 Dec '13

On 12/15/2013 08:41 PM, ron minnich wrote: > On Sun, Dec 15, 2013 at 3:52 PM, Paul Menzel > <paulepanter(a)users.sourceforge.net> wrote: > >> This implementation was pushed with the Chromebook Butterfly without any >> discussion or announcement, so the Google folks might be able to tell us >> why they went this route. > > Because the vendor required it. And, more vendors will require it in > future, so it's nice to see this discussion. > HP required that you read the SPD from CBFS, or that you store the SPD as a text file?

1 0

Re: [coreboot] [coreboot-gerrit] Patch set updated for coreboot: 26eaf9d Family14: Add support for solder-down DDR memory
by Paul Menzel 16 Dec '13

16 Dec '13

Dear Dave, Am Sonntag, den 15.12.2013, 09:27 -0700 schrieb Dave Frodin: > I'm still planning on reading the SPD values from a text file in the > mainboard directory. that is the same way, the Google boards are currently doing it [1], right? The SPD-hex-files in the board directory are listed in a Makefile. Can you use the same mechanism for AMD boards instead of your current library approach [5]? This implementation was pushed with the Chromebook Butterfly without any discussion or announcement, so the Google folks might be able to tell us why they went this route. I like Vladimir’s suggestion to put the SPD data into CBFS so it can easily be tuned [3]. No idea, what the downsides are. Why have a config for this? It would make more sense to look for a file and if it's there use it, otherwise go for smbus. This way you patch is also useful for oveclockers and boot-time speedupers. Do you also have the mainboard patch somewhere to look at, so the whole picture is clear how the current patch is used? Thanks, Paul PS: It would be awesome if you could avoid TOP posting and use interleaved style [3]. [1] http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/mainboard/sam… [2] http://review.coreboot.org/2359 [3] http://review.coreboot.org/#/c/4532/3/src/northbridge/amd/agesa/family14/di… [4] http://en.opensuse.org/openSUSE:Mailing_list_netiquette [5] http://review.coreboot.org/4533

3 2

#199: missing main prototype while compiling with clang
by coreboot 15 Dec '13

15 Dec '13

#199: missing main prototype while compiling with clang --------------------------+---------------------------------- Reporter: tfarina@… | Owner: stepan@… Type: defect | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: Dependencies: | Patch Status: there is no patch --------------------------+---------------------------------- $ make HOSTCC nvramtool/cli/nvramtool.o HOSTCC nvramtool/cli/opts.o HOSTCC nvramtool/cmos_lowlevel.o HOSTCC nvramtool/cmos_ops.o HOSTCC nvramtool/common.o HOSTCC nvramtool/compute_ip_checksum.o HOSTCC nvramtool/hexdump.o HOSTCC nvramtool/input_file.o HOSTCC nvramtool/layout.o HOSTCC nvramtool/accessors/layout-common.o HOSTCC nvramtool/accessors/layout-text.o HOSTCC nvramtool/accessors/layout-bin.o HOSTCC nvramtool/lbtable.o HOSTCC nvramtool/reg_expr.o HOSTCC nvramtool/cbfs.o HOSTCC nvramtool/accessors/cmos-mem.o HOSTCC nvramtool/nvramtool (link) OPTION option_table.h GEN build.h CC romstage.inc src/mainboard/intel/cougar_canyon2/romstage.c:173:6: error: no previous prototype for function 'main' [-Werror,-Wmissing-prototypes] void main(FSP_INFO_HEADER *fsp_info_header) ^ 1 error generated. make: *** [build/mainboard/intel/cougar_canyon2/romstage.pre.inc] Error 1 $ clang --version clang version 3.4 (trunk 193323) Target: x86_64-unknown-linux-gnu Thread model: posix $ uname -a Linux i3 3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/199> coreboot <http://www.coreboot.org/>

1 0

#198: missing main prototype while compiling with clang
by coreboot 15 Dec '13

15 Dec '13

#198: missing main prototype while compiling with clang --------------------------+---------------------------------- Reporter: tfarina@… | Owner: stepan@… Type: defect | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: Dependencies: | Patch Status: there is no patch --------------------------+---------------------------------- $ make HOSTCC nvramtool/cli/nvramtool.o HOSTCC nvramtool/cli/opts.o HOSTCC nvramtool/cmos_lowlevel.o HOSTCC nvramtool/cmos_ops.o HOSTCC nvramtool/common.o HOSTCC nvramtool/compute_ip_checksum.o HOSTCC nvramtool/hexdump.o HOSTCC nvramtool/input_file.o HOSTCC nvramtool/layout.o HOSTCC nvramtool/accessors/layout-common.o HOSTCC nvramtool/accessors/layout-text.o HOSTCC nvramtool/accessors/layout-bin.o HOSTCC nvramtool/lbtable.o HOSTCC nvramtool/reg_expr.o HOSTCC nvramtool/cbfs.o HOSTCC nvramtool/accessors/cmos-mem.o HOSTCC nvramtool/nvramtool (link) OPTION option_table.h GEN build.h CC romstage.inc src/mainboard/intel/cougar_canyon2/romstage.c:173:6: error: no previous prototype for function 'main' [-Werror,-Wmissing-prototypes] void main(FSP_INFO_HEADER *fsp_info_header) ^ 1 error generated. make: *** [build/mainboard/intel/cougar_canyon2/romstage.pre.inc] Error 1 $ clang --version clang version 3.4 (trunk 193323) Target: x86_64-unknown-linux-gnu Thread model: posix $ uname -a Linux i3 3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/198> coreboot <http://www.coreboot.org/>

1 0

#197: missing main prototype while compiling with clang
by coreboot 15 Dec '13

15 Dec '13

#197: missing main prototype while compiling with clang --------------------------+---------------------------------- Reporter: tfarina@… | Owner: stepan@… Type: defect | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: Dependencies: | Patch Status: there is no patch --------------------------+---------------------------------- $ make HOSTCC nvramtool/cli/nvramtool.o HOSTCC nvramtool/cli/opts.o HOSTCC nvramtool/cmos_lowlevel.o HOSTCC nvramtool/cmos_ops.o HOSTCC nvramtool/common.o HOSTCC nvramtool/compute_ip_checksum.o HOSTCC nvramtool/hexdump.o HOSTCC nvramtool/input_file.o HOSTCC nvramtool/layout.o HOSTCC nvramtool/accessors/layout-common.o HOSTCC nvramtool/accessors/layout-text.o HOSTCC nvramtool/accessors/layout-bin.o HOSTCC nvramtool/lbtable.o HOSTCC nvramtool/reg_expr.o HOSTCC nvramtool/cbfs.o HOSTCC nvramtool/accessors/cmos-mem.o HOSTCC nvramtool/nvramtool (link) OPTION option_table.h GEN build.h CC romstage.inc src/mainboard/intel/cougar_canyon2/romstage.c:173:6: error: no previous prototype for function 'main' [-Werror,-Wmissing-prototypes] void main(FSP_INFO_HEADER *fsp_info_header) ^ 1 error generated. make: *** [build/mainboard/intel/cougar_canyon2/romstage.pre.inc] Error 1 $ clang --version clang version 3.4 (trunk 193323) Target: x86_64-unknown-linux-gnu Thread model: posix $ uname -a Linux i3 3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/197> coreboot <http://www.coreboot.org/>

1 0

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2013