coreboot October 2013

coreboot@coreboot.org

32 participants
72 discussions

Re: [coreboot] The OS of open source solution
by Stojsavljevic, Zoran 16 Oct '13

16 Oct '13

Hello to everyone, On Monday I was racing with the time, so I just sent email to acknowledge that I was able to bring FSP concept to 3.0.13 kernel (and disappeared few minutes later). Day and a half I was busy with completely another job. First, I would like to thank to Patrick (Georgi) for unselfish help Patrick provided to me. Thank you, Patrick! Second, David, my answers are down below regarding Win7 and Win8. Today I have started testing more than kernel 3.0.13 (which I have adopted to Bare Metal OS, since I am embedded guy). I found that very few kernels so far are booting. But 3.0.13 without flaw, constantly coming up! I tried to do more impossible things, knowing that they will not work for now. These are to boot Win7 and Win8. I had Win7 HDD for IVB, and installed one HDD for Win8 using IVB CRB with EFI BIOS. Win8 seamlessly boots with IVB CRB with EFI BIOS. Knowing that Win7 requires EFI or UEFI BIOS (mandatory using EFI/UEFI BIOS drivers), I did not expect Win7 to boot. The pleasant surprise was that Win7 bootloader tried to boot Win7, concluded that Win7 is broken/damaged (NO EFI drivers), and safely redirected me back to Win7 bootloader VGA screen asking me for the options: Launch Startup Repair (recommended) Starts Windows Normally With Win8, I had different story in my mind. I assumed (exchanging some thoughts internally with some designers) that Win8 is "dual", so it'll go to discover EFI/UEFI, but if it fails, it has different mechanisms to boot without EFI/UEFI. I tried to boot 3 times. All three times the blue Win8 flag/logo appeared with the message: Preparing Automatic Repair. And froze. Log files attached for both cases. Any thoughts/ideas/theories? Thank you, Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". _______ From: David Hendricks [mailto:david.hendricks@gmail.com] Sent: Monday, October 14, 2013 10:39 PM To: Stojsavljevic, Zoran Cc: ron minnich; jstkf2012(a)126.com; David Hendricks; coreboot Subject: Re: [coreboot] The OS of open source solution On Mon, Oct 14, 2013 at 6:48 AM, Stojsavljevic, Zoran <zoran.stojsavljevic(a)intel.com> wrote: Well... Few minutes ago, I finally was able to do the impossible: To boot in this sequence: IVB FSP -> Coreboot -> SeaBIOS -> GRUB 0.97 (SuSE SLES 11 SP1) -> Linux 3.0.13 with Bare Metal capabilities. Congratulations! Do you have a copy of Windows 7 to try to install via CD-ROM? Maybe your method can help TankTang. Thank you for the great support! Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". -----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Wednesday, October 09, 2013 8:02 AM To: jstkf2012(a)126.com Cc: Stojsavljevic, Zoran; David Hendricks; coreboot Subject: Re: Re: [coreboot] The OS of open source solution well, we are all interested in how to incorporate fsp into coreboot. And you have an FSP binary. It seems to me we have a place to start. ron On Tue, Oct 8, 2013 at 10:02 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> wrote: > Hi Ron, > I am sorry , I am just a freshman in CoreBoot. > Do you interest in how to incorporate the Fsp into Coreboot?But the > source code and the mechanism is not writed and created by myself. > > Thanks, > Tank > From: ron minnich > Date: 2013-10-09 10:07 > To: jstkf2012(a)126.com > CC: Stojsavljevic, Zoran; David Hendricks; coreboot > Subject: Re: Re: [coreboot] The OS of open source solution On Tue, Oct > 8, 2013 at 6:20 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> wrote: >> Hi Ron >> >> I doesn't not drop fsp in to replace the mrc binary. > > We are very interested in what you are doing and if we can help in > some way, please let us know. > > Thanks! > > ron -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [coreboot] links in commit messages: don't do it.
by ron minnich 16 Oct '13

16 Oct '13

On Tue, Oct 15, 2013 at 7:28 PM, WANG Siyuan <wangsiyuanbuaa(a)gmail.com> wrote: > The driver download url has changed......It was not this page when I > push this patch. Thank you for that information! I think we may have now achieved a new record, in which the URL became obsolete *after* the commit was uploaded for review but *before* it was approved :-) I am used to web sites changing quickly. I think when a web site changes this quickly, it only makes the argument against putting URLs in commit messages even stronger. I also did a simple test. Just putting this search term in Ubuntu 13.04 with AMD Catalyst 13.4 Proprietary Linux Display Driver which was in the commit message, immediately got me to much more useful information than the URL. And, as the years go by, the search term will be more and more useful, and the URL less and less useful. Just While it is true that URLs were great in the early days of the web, they predate search engines and the data-centric internet we live in today. As a means of locating information they are frequently obsolete or misleading. Time moves on. So, I repeat: please don't put URLs in the commit message, and we won't have to go through the trouble of removing them. If you really want to leave URLs somewhere, put them in the review comments on gerrit, but just be aware that they may become obsolete surprisingly quickly. I must admit, in this case, I was surprised just how quickly. Thanks all ron

1 0

Re: [coreboot] links in commit messages: don't do it.
by WANG Siyuan 16 Oct '13

16 Oct '13

The driver download url has changed......It was not this page when I push this patch. On Wed, Oct 16, 2013 at 5:16 AM, ron minnich <rminnich(a)gmail.com> wrote: > Since I have to deal with bad URLs on a daily basis, and just hit > another one yesterday in a different repo, sorry, my opinion on this > isn't up for changing. I actually thought (a long time ago) as you do > now, but my experience with URLs is not that happy. Sorry. I expect > that URLs will continue to make it into the repo one way or another, > but I will continue to oppose such practice. > > Committ messages are archival. At some point, when the Web was new, > people would put URLs in citations (me included). That practice has > started to come under fire in the archival literature due to the stale > link problem. What we did when the Web was new is not necessarily what > we do today. Few people in the 1990s anticipated the scale of the web > as it is today. It's far more useful to put a searchable string > (rocket systems 1984 superio with platinum thrusters) than a URL which > will almost certainly be bad in a few years. > > But if you're going to dump a URL in a commit message, for goodness > sake, at least have it point at something other than a form! > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- Yours sincerely, WANG Siyuan

1 0

Re: [coreboot] links in commit messages: don't do it.
by Paul Menzel 15 Oct '13

15 Oct '13

Dear Ron, dear coreboot folks, Am Dienstag, den 15.10.2013, 10:52 -0700 schrieb ron minnich: > I see a commit went in with this text: > > "... have tested on Ubuntu 13.04 with AMD Catalyst 13.4 Proprietary > Linux Display Driver[1]. > > [1]. http://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx" > > OK, if you click on that link you find it contains very little useful > information: it's a web form with four fields. It doesn't actually > point to the driver and it's not clear on first looking at it just how > I *would* get that driver. come on, it is obvious to go through each step and to give more details in each step. But I agree that having a direct link to the file would have been better. > And, in time, it will become another dead link in our growing pool of > dead links. > > So what information was added by this link? None. The text was more > than sufficient. If the text was sufficient to you, just ignore the reference and don’t click on the link. It is that simple in my opinion. For me it is useful, because I know how to better reproduce Siyuan’s setup. With the reference I know he did not use the driver from the package repository, I know where to get it from and do not have to search for that myself. It saves precious time! > Please don't put links in commit messages. I would -2 this CL but it > already went in. Giving -2 because of an URL in the commit message is unjustified in my opinion as -2 blocks a commit from being merged even if other think it should go in. As seen from above, I strongly disagree with forbidding URLs in commit messages. Please start by noticing, that our current workflow violates that rule already. In every commit we have a line »Reviewed-on: http://review.coreboot.org/XXXX« containing an URL! Furthermore I see the following advantages. 1. Links made the WWW successful. The browser is used in our workflow. People read commit in Gerrit, Gitweb and the Web archive. So adding links adds to usability. We do not always think of the right keywords to put into search machines to find a datasheet. We do not always have a Git checkout to look up a referenced commit hash. (It would be easier for me to have the Gerrit review URL in commit [1] for example. At least the commit summary would be nice as it is common in the Linux kernel too. I haven’t met someone yet which memorizes commit hashes.) Links make your life easier. 2. Giving an URL to a Web page containing further information and background knowledge to better understand a commit is always good. It safes you time and acts also as a reference/backup for your explanation and reasoning of a change. Especially in Free Software projects were a lot of people work on stuff in their free time, URLs to datasheets or other information help a great deal to quickly read up on things they forgot or did not know yet. URLs to datasheets come to my mind. The commit author has already found that information and great page. Why not share it and save the reviewer time. 3. If the URL should become invalid, with high probability the commit is also pretty old by then and not looked at that often. During review, during which the most people are going to look at a commit, the URL is valid. Even if it became invalid, there are still ways to retrieve the content using some Web archive, caches or finding the changed URL with the help of the URL in the commit message. The advantage and time saving is way greater by just clicking on an URL and directly getting to the Web page than having to search for it yourself and wasting five seconds to see that the URL is invalid. In the second case you have to search for the information anyway spending much more time than these five seconds. Nobody stops using URLs on Web pages despite they might get invalid/outdated. Why should we? Ron, sometimes I have the impression, you miss the perspective of us (me) non-professionals not working full-time on coreboot. And in my experience, I spent a lot of time with searching for information, which a simple URL to a datasheet would have saved me. As you are the project founder you can of course set rules about development practices. But, as there are a lot of contributors and reviewers, I would prefer a public discussion on the list before making policy decisions. Furthermore, such decisions should be documented! Our current development guidelines live in the Wiki [1] and reference the Git Wiki page [2]. If a new policy is decided on, it should be documented there. It would be awesome, if you could change your opinion on that issue. Thanks, Paul [1] http://review.coreboot.org/3967 [2] http://www.coreboot.org/Development_Guidelines#Creating_Patches [3] http://www.coreboot.org/Git#Commit_messages

2 1

links in commit messages: don't do it.
by ron minnich 15 Oct '13

15 Oct '13

I see a commit went in with this text: "... have tested on Ubuntu 13.04 with AMD Catalyst 13.4 Proprietary Linux Display Driver[1]. [1]. http://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx" OK, if you click on that link you find it contains very little useful information: it's a web form with four fields. It doesn't actually point to the driver and it's not clear on first looking at it just how I *would* get that driver. And, in time, it will become another dead link in our growing pool of dead links. So what information was added by this link? None. The text was more than sufficient. Please don't put links in commit messages. I would -2 this CL but it already went in. ron

1 0

Re: [coreboot] The OS of open source solution
by David Hendricks 14 Oct '13

14 Oct '13

On Mon, Oct 14, 2013 at 6:48 AM, Stojsavljevic, Zoran < zoran.stojsavljevic(a)intel.com> wrote: > Well... > > Few minutes ago, I finally was able to do the impossible: To boot in this > sequence: IVB FSP -> Coreboot -> SeaBIOS -> GRUB 0.97 (SuSE SLES 11 SP1) -> > Linux 3.0.13 with Bare Metal capabilities. > Congratulations! Do you have a copy of Windows 7 to try to install via CD-ROM? Maybe your method can help TankTang. > Thank you for the great support! > Zoran > _______ > Most of The Time you should be "intel inside" to be capable to think "out > of the box". > > -----Original Message----- > From: ron minnich [mailto:rminnich@gmail.com] > Sent: Wednesday, October 09, 2013 8:02 AM > To: jstkf2012(a)126.com > Cc: Stojsavljevic, Zoran; David Hendricks; coreboot > Subject: Re: Re: [coreboot] The OS of open source solution > > well, we are all interested in how to incorporate fsp into coreboot. > And you have an FSP binary. It seems to me we have a place to start. > > ron > > On Tue, Oct 8, 2013 at 10:02 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> > wrote: > > Hi Ron, > > I am sorry , I am just a freshman in CoreBoot. > > Do you interest in how to incorporate the Fsp into Coreboot?But the > > source code and the mechanism is not writed and created by myself. > > > > Thanks, > > Tank > > From: ron minnich > > Date: 2013-10-09 10:07 > > To: jstkf2012(a)126.com > > CC: Stojsavljevic, Zoran; David Hendricks; coreboot > > Subject: Re: Re: [coreboot] The OS of open source solution On Tue, Oct > > 8, 2013 at 6:20 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> wrote: > >> Hi Ron > >> > >> I doesn't not drop fsp in to replace the mrc binary. > > > > We are very interested in what you are doing and if we can help in > > some way, please let us know. > > > > Thanks! > > > > ron > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Implementing or not implementing hacks for the OS (was: Change in coreboot[master]: ck804: hide IOAPIC base address in PCI_BASE_ADDRESS_1)
by ron minnich 14 Oct '13

14 Oct '13

ok, so let's talk about what this means and how we are interpreting it. Jonathan, can you start first with the relevant error messages from dmesg and what they mean. I'd like this discussion to be useful when this sort of problem comes up. Consider it archival. thanks ron

1 0

Re: [coreboot] Implementing or not implementing hacks for the OS (was: Change in coreboot[master]: ck804: hide IOAPIC base address in PCI_BASE_ADDRESS_1)
by ron minnich 14 Oct '13

14 Oct '13

digging a little deeper is always preferred to simply hiding the register, so, thanks David! ron On Mon, Oct 14, 2013 at 12:10 AM, David Hubbard <david.c.hubbard+coreboot(a)gmail.com> wrote: > Hi all, > > On Sun, Oct 13, 2013 at 2:03 PM, ron minnich <rminnich(a)gmail.com> wrote: >> >> Paul, you missed part of the picture. Suppose we have a different >> kernel, which does not have the same bug as Linux has,and that, >> further, depends on that register being visible? We can't know that >> such OSes exist, but we do not know that they do not. We'd have to at >> the very least test some of them. We've always tried to avoid being >> Linux-centric in coreboot and for the most part have succeeded. >> Further, hidden registers create their own problems. >> >> This problem has no clear solution. I've always felt that in all >> cases, we should err on the side of opening up the hardware, and not >> hiding registers. >> >> ron > > > I checked with Paul briefly on IRC, I think we may be missing something > obvious here. IOAPIC support is pretty fundamental; maybe the ck804 > brokenness is fixable? (I'm willing to dig in a little deeper and find out > what's going on here.) > > If so then there would be no need to make a special case for it in coreboot, > right? > > David

1 0

Re: [coreboot] The OS of open source solution
by Stojsavljevic, Zoran 14 Oct '13

14 Oct '13

Well... Few minutes ago, I finally was able to do the impossible: To boot in this sequence: IVB FSP -> Coreboot -> SeaBIOS -> GRUB 0.97 (SuSE SLES 11 SP1) -> Linux 3.0.13 with Bare Metal capabilities. Thank you for the great support! Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". -----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Wednesday, October 09, 2013 8:02 AM To: jstkf2012(a)126.com Cc: Stojsavljevic, Zoran; David Hendricks; coreboot Subject: Re: Re: [coreboot] The OS of open source solution well, we are all interested in how to incorporate fsp into coreboot. And you have an FSP binary. It seems to me we have a place to start. ron On Tue, Oct 8, 2013 at 10:02 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> wrote: > Hi Ron, > I am sorry , I am just a freshman in CoreBoot. > Do you interest in how to incorporate the Fsp into Coreboot?But the > source code and the mechanism is not writed and created by myself. > > Thanks, > Tank > From: ron minnich > Date: 2013-10-09 10:07 > To: jstkf2012(a)126.com > CC: Stojsavljevic, Zoran; David Hendricks; coreboot > Subject: Re: Re: [coreboot] The OS of open source solution On Tue, Oct > 8, 2013 at 6:20 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> wrote: >> Hi Ron >> >> I doesn't not drop fsp in to replace the mrc binary. > > We are very interested in what you are doing and if we can help in > some way, please let us know. > > Thanks! > > ron Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [coreboot] Implementing or not implementing hacks for the OS (was: Change in coreboot[master]: ck804: hide IOAPIC base address in PCI_BASE_ADDRESS_1)
by Jonathan A. Kollasch 14 Oct '13

14 Oct '13

Attached is a Linux dmesg that shows the problem. Jonathan Kollasch On Mon, Oct 14, 2013 at 01:10:40AM -0600, David Hubbard wrote: > Hi all, > > On Sun, Oct 13, 2013 at 2:03 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > Paul, you missed part of the picture. Suppose we have a different > > kernel, which does not have the same bug as Linux has,and that, > > further, depends on that register being visible? We can't know that > > such OSes exist, but we do not know that they do not. We'd have to at > > the very least test some of them. We've always tried to avoid being > > Linux-centric in coreboot and for the most part have succeeded. > > Further, hidden registers create their own problems. > > > > This problem has no clear solution. I've always felt that in all > > cases, we should err on the side of opening up the hardware, and not > > hiding registers. > > > > ron > > > > I checked with Paul briefly on IRC, I think we may be missing something > obvious here. IOAPIC support is pretty fundamental; maybe the ck804 > brokenness is fixable? (I'm willing to dig in a little deeper and find out > what's going on here.) > > If so then there would be no need to make a special case for it in > coreboot, right? > > David > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2013