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
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
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
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
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
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
>
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
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
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
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
