Hi,
Upon booting, I get this:
[...]
you could try commit 0df0e14fb, that may or may not work, the commit after that broke fusion boards completely, apparently.
Florian
Thank you! I can confirm that 0df0e14fb works properly. -Marshall
Frank,
It looks like we have a regression. Is there some dependency on the other patches that have not yet been committed?
Marc
Unfortunately git bisect is no help here because the commit which caused the regression was a huge one.
It's important that large patches are broken down into a set of small comprehensible patches, each with an explanatory commit message.
<<quote from git-bisect-lk2009.html documentation>> ... sometimes "interesting" changes of behavior in the software are introduced in some commits.
In fact people are specially interested in commits that introduce a "bad" behavior, called a bug or a regression. They are interested in these commits because a commit (hopefully) contains a very small set of source code changes. And it's much easier to understand and properly fix a problem when you only need to check a very small set of changes, than when you don't know where look in the first place.
So to help people find commits that introduce a "bad" behavior, the "git bisect" set of commands was invented. ...
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot- bounces@coreboot.org] On Behalf Of perh52@runbox.com Sent: Friday, August 19, 2011 12:37 AM To: coreboot Subject: [coreboot] E350M1 does not POST
Hi,
Upon booting, I get this:
[...]
you could try commit 0df0e14fb, that may or may not work, the
commit
after
that broke fusion boards completely, apparently.
Florian
Thank you! I can confirm that 0df0e14fb works properly. -Marshall
Frank,
It looks like we have a regression. Is there some dependency on the other patches that have not yet been committed?
Marc
Unfortunately git bisect is no help here because the commit which
caused
the regression was a huge one.
It's important that large patches are broken down into a set of small comprehensible patches, each with an explanatory commit message.
<<quote from git-bisect-lk2009.html documentation>> ... sometimes "interesting" changes of behavior in the software are introduced in some commits.
In fact people are specially interested in commits that introduce a "bad" behavior, called a bug or a regression. They are interested in these commits because a commit (hopefully) contains a very small set of source code changes. And it's much easier to understand and properly fix a problem when you only need to check a very small set of changes, than when you don't know where look in the first place.
So to help people find commits that introduce a "bad" behavior, the "git bisect" set of commands was invented.
Hello, All
Since commit 84cbce2 cause E350M1 not POST, Following patches should resolve this regression problem, please see the attachment in detail. I have test it on a Persimmon mainboard, anybody can have a test on E350M1? Thanks -- Kerry sheh
I have access to an E350M1. I will test these patches tonight and report back with results.
Thank you! -Marshall Buschman
On 09/07/2011 02:53 AM, She, Kerry wrote:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot- bounces@coreboot.org] On Behalf Of perh52@runbox.com Sent: Friday, August 19, 2011 12:37 AM To: coreboot Subject: [coreboot] E350M1 does not POST
Hi,
Upon booting, I get this:
[...]
you could try commit 0df0e14fb, that may or may not work, the
commit
after
that broke fusion boards completely, apparently.
Florian
Thank you! I can confirm that 0df0e14fb works properly. -Marshall
Frank,
It looks like we have a regression. Is there some dependency on the other patches that have not yet been committed?
Marc
Unfortunately git bisect is no help here because the commit which
caused
the regression was a huge one.
It's important that large patches are broken down into a set of small comprehensible patches, each with an explanatory commit message.
<<quote from git-bisect-lk2009.html documentation>> ... sometimes "interesting" changes of behavior in the software are introduced in some commits.
In fact people are specially interested in commits that introduce a "bad" behavior, called a bug or a regression. They are interested in these commits because a commit (hopefully) contains a very small set of source code changes. And it's much easier to understand and properly fix a problem when you only need to check a very small set of changes, than when you don't know where look in the first place.
So to help people find commits that introduce a "bad" behavior, the "git bisect" set of commands was invented.
Hello, All
Since commit 84cbce2 cause E350M1 not POST, Following patches should resolve this regression problem, please see the attachment in detail. I have test it on a Persimmon mainboard, anybody can have a test on E350M1? Thanks -- Kerry sheh
On 09/07/2011 11:38 AM, Marshall Buschman wrote:
I have access to an E350M1. I will test these patches tonight and report back with results.
Thank you! -Marshall Buschman
On 09/07/2011 02:53 AM, She, Kerry wrote:
-----Original Message----- From:coreboot-bounces@coreboot.org [mailto:coreboot- bounces@coreboot.org] On Behalf Ofperh52@runbox.com Sent: Friday, August 19, 2011 12:37 AM To: coreboot Subject: [coreboot] E350M1 does not POST
Hi,
> Upon booting, I get this: [...]
you could try commit 0df0e14fb, that may or may not work, the
commit
after
that broke fusion boards completely, apparently.
Florian
Thank you! I can confirm that 0df0e14fb works properly. -Marshall
Frank,
It looks like we have a regression. Is there some dependency on the other patches that have not yet been committed?
Marc
Unfortunately git bisect is no help here because the commit which
caused
the regression was a huge one.
It's important that large patches are broken down into a set of small comprehensible patches, each with an explanatory commit message.
<<quote from git-bisect-lk2009.html documentation>> ... sometimes "interesting" changes of behavior in the software are introduced in some commits.
In fact people are specially interested in commits that introduce a "bad" behavior, called a bug or a regression. They are interested in these commits because a commit (hopefully) contains a very small set of source code changes. And it's much easier to understand and properly fix a problem when you only need to check a very small set of changes, than when you don't know where look in the first place.
So to help people find commits that introduce a "bad" behavior, the "git bisect" set of commands was invented.
Hello, All
Since commit 84cbce2 cause E350M1 not POST, Following patches should resolve this regression problem, please see the attachment in detail. I have test it on a Persimmon mainboard, anybody can have a test on E350M1? Thanks -- Kerry sheh
Hello Kerry:
I have tested your patch set, and it does make the E350M1 boot. The bad news is there is now a delay of approximately 5 minutes and 20 seconds before any serial output is displayed.
The coreboot log is available at http://www.lucidmachines.com/coreboot/kerrypatches20110907.txt
Please let me know if I can assist further.
Thank you! -Marshall Buschman
Hello, Marshall
From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Marshall Buschman Sent: Thursday, September 08, 2011 10:02 AM To: coreboot@coreboot.org Subject: Re: [coreboot] E350M1 does not POST
On 09/07/2011 11:38 AM, Marshall Buschman wrote:
I have access to an E350M1. I will test these patches tonight and report back with results.
Thank you! -Marshall Buschman
On 09/07/2011 02:53 AM, She, Kerry wrote:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot- bounces@coreboot.org] On Behalf Of perh52@runbox.com Sent: Friday, August 19, 2011 12:37 AM To: coreboot Subject: [coreboot] E350M1 does not POST
Hi,
Upon booting, I get this:
[...] you could try commit 0df0e14fb, that may or may not work, the
commit
after
that broke fusion boards completely, apparently. Florian
Thank you! I can confirm that 0df0e14fb works properly. -Marshall
Frank, It looks like we have a regression. Is there some dependency on the other patches that have not yet been committed? Marc
Unfortunately git bisect is no help here because the commit which
caused
the regression was a huge one. It's important that large patches are broken down into a set of small comprehensible patches, each with an explanatory commit message. <<quote from git-bisect-lk2009.html documentation>> ... sometimes "interesting" changes of behavior in the software are introduced in some commits. In fact people are specially interested in commits that introduce a "bad" behavior, called a bug or a regression. They are interested in these commits because a commit (hopefully) contains a very small set of source code changes. And it's much easier to understand and properly fix a problem when you only need to check a very small set of changes, than when you don't know where look in the first place. So to help people find commits that introduce a "bad" behavior, the "git bisect" set of commands was invented.
Hello, All
Since commit 84cbce2 cause E350M1 not POST, Following patches should resolve this regression problem, please see the attachment in detail. I have test it on a Persimmon mainboard, anybody can have a test on E350M1? Thanks -- Kerry sheh
Hello Kerry:
I have tested your patch set, and it does make the E350M1 boot. The bad news is there is now a delay of approximately 5 minutes and 20 seconds before any serial output is displayed.
The coreboot log is available at http://www.lucidmachines.com/coreboot/kerrypatches20110907.txt
Please let me know if I can assist further.
Thanks a lot,
I have a test based on commit 8679e52 with both F14 C0 and B0 processor on different persimmon mainboard,
But unfortunately I can't reproduce the problem you have met.
Family14 Revision C0 processor(BSP Family_Model:00500f20)
Family14 Revision B0 processor(BSP Family_Model: 00500f10) is same as the one you use.
There is not much difference between E350M1 and persimmon code,
so I'm not sure whether the root cause is commit 84cbce2 or other commit, such as sb800 update etc.
Can you have a test base on commit 84cbce2 ?
Many Thanks
Kerry Sheh
Thank you! -Marshall Buschman
On 09/07/2011 11:56 PM, She, Kerry wrote:
Hello, Marshall
*From:*coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] *On Behalf Of *Marshall Buschman *Sent:* Thursday, September 08, 2011 10:02 AM *To:* coreboot@coreboot.org *Subject:* Re: [coreboot] E350M1 does not POST
On 09/07/2011 11:38 AM, Marshall Buschman wrote:
I have access to an E350M1. I will test these patches tonight and report back with results.
Thank you! -Marshall Buschman
On 09/07/2011 02:53 AM, She, Kerry wrote:
-----Original Message----- From:coreboot-bounces@coreboot.org <mailto:coreboot-bounces@coreboot.org> [mailto:coreboot- bounces@coreboot.org <mailto:bounces@coreboot.org>] On Behalf Ofperh52@runbox.com <mailto:perh52@runbox.com> Sent: Friday, August 19, 2011 12:37 AM To: coreboot Subject: [coreboot] E350M1 does not POST Hi, Upon booting, I get this: [...] you could try commit 0df0e14fb, that may or may not work, thecommit
after that broke fusion boards completely, apparently. Florian Thank you! I can confirm that 0df0e14fb works properly. -Marshall Frank, It looks like we have a regression. Is there some dependency on the other patches that have not yet been committed? Marc Unfortunately git bisect is no help here because the commit whichcaused
the regression was a huge one. It's important that large patches are broken down into a set of small comprehensible patches, each with an explanatory commit message. <<quote from git-bisect-lk2009.html documentation>> ... sometimes "interesting" changes of behavior in the software are introduced in some commits. In fact people are specially interested in commits that introduce a "bad" behavior, called a bug or a regression. They are interested in these commits because a commit (hopefully) contains a very small set of source code changes. And it's much easier to understand and properly fix a problem when you only need to check a very small set of changes, than when you don't know where look in the first place. So to help people find commits that introduce a "bad" behavior, the "git bisect" set of commands was invented.Hello, All
Since commit 84cbce2 cause E350M1 not POST, Following patches should resolve this regression problem, please see the attachment in detail. I have test it on a Persimmon mainboard, anybody can have a test on E350M1? Thanks -- Kerry sheh
Hello Kerry:
I have tested your patch set, and it does make the E350M1 boot. The bad news is there is now a delay of approximately 5 minutes and 20 seconds before any serial output is displayed.
The coreboot log is available at http://www.lucidmachines.com/coreboot/kerrypatches20110907.txt
Please let me know if I can assist further.
Thanks a lot,
I have a test based on commit 8679e52 with both F14 C0 and B0 processor on different persimmon mainboard,
But unfortunately I can't reproduce the problem you have met.
Family14 Revision C0 processor(BSP Family_Model:00500f20)
Family14 Revision B0 processor(BSP Family_Model: 00500f10) is same as the one you use.
There is not much difference between E350M1 and persimmon code,
so I'm not sure whether the root cause is commit 84cbce2 or other commit, such as sb800 update etc.
Can you have a test base on commit 84cbce2 ?
Many Thanks
Kerry Sheh
Thank you! -Marshall Buschman
Hello Kerry: I'll test with your patches and 84cbce2 and report back.
Thank you! -Marshall
Marshall Buschman wrote:
...
]Hello Kerry: ] ]I have tested your patch set, and it does make the E350M1 boot. ]The bad news is there is now a delay of approximately 5 minutes and 20 ]seconds before any serial output is displayed. ] ]The coreboot log is available at ]http://www.lucidmachines.com/coreboot/kerrypatches20110907.txt ] ]Please let me know if I can assist further. ] ]Thank you! ]-Marshall Buschman
The problem of early serial output causing a large boot delay is not new. It is caused by serial port logging before the SB800 LPC clock is configured, and/or serial port logging before the SIO baud rate is setup. The original LPC clock fix was in romstage.c, then later moved to sb800 bootblock.c, function enable_clocks(). Marshall's log file is missing the following early serial output, which suggests a problem with the needed early SB800 LPC clock programming, or SIO baud rate programming:
POST: 0x30 SB800 - Cfg.c - sb800_cimx_config - Start. SB800 - Cfg.c - sb800_cimx_config - End. POST: 0x31
I am not in a position to try this on real hardware, but I did do a quick simnow test. It looks like function enable_clocks() is correctly executing before the first serial output. But the above lines of early serial output are logged before the SIO baud rate is programmed. Here is some discussion of this problem:
http://patchwork.coreboot.org/patch/3178/
That old patch should overcome the problem for the above post code logging. But the new SB800 logging in sb800_cimx_config() probably needs removing also.
Thanks, Scott
Hello, Scott
-----Original Message----- From: coreboot-bounces@coreboot.org
[mailto:coreboot-bounces@coreboot.org]
On Behalf Of Scott Duplichan Sent: Thursday, September 08, 2011 3:09 PM To: 'Marshall Buschman'; coreboot@coreboot.org Subject: Re: [coreboot] E350M1 does not POST
Marshall Buschman wrote:
...
]Hello Kerry: ] ]I have tested your patch set, and it does make the E350M1 boot. ]The bad news is there is now a delay of approximately 5 minutes and
20
]seconds before any serial output is displayed. ] ]The coreboot log is available at ]http://www.lucidmachines.com/coreboot/kerrypatches20110907.txt ] ]Please let me know if I can assist further. ] ]Thank you! ]-Marshall Buschman
The problem of early serial output causing a large boot delay is not
new.
It is caused by serial port logging before the SB800 LPC clock is
configured,
and/or serial port logging before the SIO baud rate is setup. The original LPC clock fix was in romstage.c, then later moved to sb800
bootblock.c,
function enable_clocks(). Marshall's log file is missing the following early serial output, which suggests a problem with the needed early SB800
LPC
clock programming, or SIO baud rate programming:
POST: 0x30 SB800 - Cfg.c - sb800_cimx_config - Start. SB800 - Cfg.c - sb800_cimx_config - End. POST: 0x31I am not in a position to try this on real hardware, but I did do a
quick
simnow test. It looks like function enable_clocks() is correctly executing before the first serial output. But the above lines of early serial output are logged before the SIO baud rate is programmed. Here is some discussion of this problem:
http://patchwork.coreboot.org/patch/3178/
That old patch should overcome the problem for the above post code logging.
This is quite helpful information, we should print after the console initialization was done.
But the new SB800 logging in sb800_cimx_config() probably needs
removing also.
I agree to remove the logging. Many Thanks -- Kerry sheh
Thanks, Scott
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Marshall Buschman -
perh52＠runbox.com -
Scott Duplichan -
She, Kerry