Thx, I thought you're kidding when I read this, but this tool realy exists
Awesome.
I'll give it a try an post the results here.
On Sunday, December 13, 2015 07:52:31 PM Iru Cai wrote:
> Try util/autoport and it can be easier.
>
--
mit freundlichen Grüßen / best regards
Gerhard Gappmeier
GPG-KeyId: 5AAC50C4
GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4
This is FSP 1.1. I’ll work on getting serial output. It shouldn’t be difficult assuming this dev board has it routed. I agree that it will make debug easier.
--David Crammer
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Jin, Huang
Sent: Wednesday, December 09, 2015 2:01 PM
To: David Crammer
Cc: coreboot(a)coreboot.org
Subject: Re: [coreboot] FSPInitiNot Returning
Hi David,
May I know which FSP version are you using? If it is not difficult, enabling early serial output in coreboot before calling FSP will be helpful for trouble shooting your problem, and your development in the long run.
Thanks,
Huang
From: David Crammer [mailto:dcrammer@gmail.com]
Sent: Wednesday, December 09, 2015 11:05 AM
To: Jin, Huang
Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] FSPInitiNot Returning
Yes. This is a broadwell platform. I removed the UPD settings and left them default (passed NULL for that pointer in the parameters to FspInit). It seems to get past that point now. I did notice that the SMBus addresses for the DIMMs were being set to different values than what is listed in the binary configuration tool. This and the PMBASE settings were really the only things changed in the coreboot source. Maybe this is the cause?
I don't really have any logs as I'm only debugging with port 0x80 values.
On Wed, Dec 9, 2015 at 11:19 AM, Jin, Huang <huang.jin(a)intel.com<mailto:huang.jin@intel.com>> wrote:
Hi David,
I am assuming you are using a Broadwell platform and Broadwell FSP. Could you please share some logs? I might be able to help you.
Thanks,
Huang
From: coreboot [mailto:coreboot-bounces@coreboot.org<mailto:coreboot-bounces@coreboot.org>] On Behalf Of David Crammer
Sent: Wednesday, December 09, 2015 8:19 AM
To: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
Subject: [coreboot] FSPInitiNot Returning
Hello All,
I’m running into a rather strange error and I’m hoping someone has had experience with this or may know about what I’m seeing.
I’m working with an Intel I5 5350U on an ADLINK platform. I’m getting to the part of the boot sequence where FspInit is called but it never returns to the specified return function. The system resets 3 times with a post code (codes inserted before and in return function) indicating that it got to the FspInit call and reset. After the third time, it settles on a post code of 0xBE. I can’t find reference to the post code anywhere.
Any help would be greatly appreciated. In case anyone is interested, I’ll reply with any updates.
--David Crammer
Hi David,
May I know which FSP version are you using? If it is not difficult, enabling early serial output in coreboot before calling FSP will be helpful for trouble shooting your problem, and your development in the long run.
Thanks,
Huang
From: David Crammer [mailto:dcrammer@gmail.com]
Sent: Wednesday, December 09, 2015 11:05 AM
To: Jin, Huang
Cc: coreboot(a)coreboot.org
Subject: Re: [coreboot] FSPInitiNot Returning
Yes. This is a broadwell platform. I removed the UPD settings and left them default (passed NULL for that pointer in the parameters to FspInit). It seems to get past that point now. I did notice that the SMBus addresses for the DIMMs were being set to different values than what is listed in the binary configuration tool. This and the PMBASE settings were really the only things changed in the coreboot source. Maybe this is the cause?
I don't really have any logs as I'm only debugging with port 0x80 values.
On Wed, Dec 9, 2015 at 11:19 AM, Jin, Huang <huang.jin(a)intel.com<mailto:huang.jin@intel.com>> wrote:
Hi David,
I am assuming you are using a Broadwell platform and Broadwell FSP. Could you please share some logs? I might be able to help you.
Thanks,
Huang
From: coreboot [mailto:coreboot-bounces@coreboot.org<mailto:coreboot-bounces@coreboot.org>] On Behalf Of David Crammer
Sent: Wednesday, December 09, 2015 8:19 AM
To: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
Subject: [coreboot] FSPInitiNot Returning
Hello All,
I’m running into a rather strange error and I’m hoping someone has had experience with this or may know about what I’m seeing.
I’m working with an Intel I5 5350U on an ADLINK platform. I’m getting to the part of the boot sequence where FspInit is called but it never returns to the specified return function. The system resets 3 times with a post code (codes inserted before and in return function) indicating that it got to the FspInit call and reset. After the third time, it settles on a post code of 0xBE. I can’t find reference to the post code anywhere.
Any help would be greatly appreciated. In case anyone is interested, I’ll reply with any updates.
--David Crammer
Yes. This is a broadwell platform. I removed the UPD settings and left
them default (passed NULL for that pointer in the parameters to FspInit).
It seems to get past that point now. I did notice that the SMBus addresses
for the DIMMs were being set to different values than what is listed in the
binary configuration tool. This and the PMBASE settings were really the
only things changed in the coreboot source. Maybe this is the cause?
I don't really have any logs as I'm only debugging with port 0x80 values.
On Wed, Dec 9, 2015 at 11:19 AM, Jin, Huang <huang.jin(a)intel.com> wrote:
> Hi David,
>
>
>
> I am assuming you are using a Broadwell platform and Broadwell FSP. Could
> you please share some logs? I might be able to help you.
>
>
>
> Thanks,
>
> Huang
>
>
>
> *From:* coreboot [mailto:coreboot-bounces@coreboot.org] *On Behalf Of *David
> Crammer
> *Sent:* Wednesday, December 09, 2015 8:19 AM
> *To:* coreboot(a)coreboot.org
> *Subject:* [coreboot] FSPInitiNot Returning
>
>
>
> Hello All,
>
> I’m running into a rather strange error and I’m hoping someone has had
> experience with this or may know about what I’m seeing.
>
>
>
> I’m working with an Intel I5 5350U on an ADLINK platform. I’m getting to
> the part of the boot sequence where FspInit is called but it never returns
> to the specified return function. The system resets 3 times with a post
> code (codes inserted before and in return function) indicating that it got
> to the FspInit call and reset. After the third time, it settles on a post
> code of 0xBE. I can’t find reference to the post code anywhere.
>
>
>
> Any help would be greatly appreciated. In case anyone is interested, I’ll
> reply with any updates.
>
>
>
> --David Crammer
>
Hi David,
I am assuming you are using a Broadwell platform and Broadwell FSP. Could you please share some logs? I might be able to help you.
Thanks,
Huang
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of David Crammer
Sent: Wednesday, December 09, 2015 8:19 AM
To: coreboot(a)coreboot.org
Subject: [coreboot] FSPInitiNot Returning
Hello All,
I’m running into a rather strange error and I’m hoping someone has had experience with this or may know about what I’m seeing.
I’m working with an Intel I5 5350U on an ADLINK platform. I’m getting to the part of the boot sequence where FspInit is called but it never returns to the specified return function. The system resets 3 times with a post code (codes inserted before and in return function) indicating that it got to the FspInit call and reset. After the third time, it settles on a post code of 0xBE. I can’t find reference to the post code anywhere.
Any help would be greatly appreciated. In case anyone is interested, I’ll reply with any updates.
--David Crammer
Hello All,
I’m running into a rather strange error and I’m hoping someone has had
experience with this or may know about what I’m seeing.
I’m working with an Intel I5 5350U on an ADLINK platform. I’m getting to
the part of the boot sequence where FspInit is called but it never returns
to the specified return function. The system resets 3 times with a post
code (codes inserted before and in return function) indicating that it got
to the FspInit call and reset. After the third time, it settles on a post
code of 0xBE. I can’t find reference to the post code anywhere.
Any help would be greatly appreciated. In case anyone is interested, I’ll
reply with any updates.
--David Crammer
>> 3) Make the baytrail directory structures look as similar again -
>> rename the soc/fsp_baytrail/baytrail include directory to
>> soc/fsp_baytrail/soc/include to match what was done with soc/baytrail.
>> Or we can rename them both to just soc/(fsp_)baytrail/include.
>> Something, so long as they match.
>
> I'm OK with reducing duplication and unnecessary differences.
> There seems to be plenty of duplicate header files.
> Without a similar tree structure and filenames, it is difficult to
> compare the trees, so I'd sync that first.
I submitted a patch to rename the fsp_baytrail/baytrail folder to
fsp_baytrail/include/soc.
https://review.coreboot.org/12686
It touched a lot of code that I don't normally compile, so I'm waiting
on the build results to see what may have broke.
It is all automated with grep and sed (commands in the commit
message), except for the Makefile.inc change to add the folder to the
include path.
Please take a look.
Thanks,
Ben
ron minnich wrote:
> nobody cared enough to really do the work
That's the problem - not the solution. Don't build infrastructure to
support complacency, build infrastructure to support desirable activity.
//Peter
On 12/07/2015 07:55 AM, Martin Roth wrote:
> Here are my suggested steps:
> 1) Look for commonalities between baytrail and other chipsets and move
> pieces things into soc/intel/common
A word of caution about soc/intel/common: it's a misnomer. It's very
specific to FSP 1.1.
Alex
there's another way to do this that few people use.
Back in the E7500 days, the 7505 came along. We experimented with this:
src/northbridge/intel/e750x
and put the common files in there.
Under e750x we had
e7500
e7505
for the different files.
so, src/northbridge/intel/e750x/{e7500,e7505}
worked fine. nobody cared enough to really do the work of putting it all
together, we were just happy that
the build system supported the naming in the files and so on.
Part of the trick is this: in the mainboard file, the part becomes
src/northbridge/intel/e750x/e7500
and in e7500 you include parts from src/northbridge/intel/e750x
So you don't make e750x the northbridge directory; rather you make
e750x/e7505 and e750x/e7500 the directory.
That way, no condition includes or anything. It's a pretty standard build
setup.
this is similar to what we did on the ARM parts a few years back.
ron
On Mon, Dec 7, 2015 at 4:08 PM Ben Gardner <gardner.ben(a)gmail.com> wrote:
> On Mon, Dec 7, 2015 at 9:55 AM, Martin Roth <gaumless(a)gmail.com> wrote:
> > I think we can cut down on some of the code redundancy, but as Alex
> > says, they are different chipsets, and we need to be careful about
> > trying to combine too much.
> >
> > Here are my suggested steps:
> > 1) Look for commonalities between baytrail and other chipsets and move
> > pieces things into soc/intel/common or southbridge/intel/common.
> > Let's not do a bunch of work just for baytrail that could help all the
> > intel chipsets. I think this should be done regardless of anything
> > that we decide about Bay Trail.
> >
> > 2) Figure out which changes in each directory should go to the other.
> > Each have gotten some fixes that should be shared with the other
> > directory.
> >
> > 3) Make the baytrail directory structures look as similar again -
> > rename the soc/fsp_baytrail/baytrail include directory to
> > soc/fsp_baytrail/soc/include to match what was done with soc/baytrail.
> > Or we can rename them both to just soc/(fsp_)baytrail/include.
> > Something, so long as they match.
> >
> > 4) Create a soc/intel/baytrail_common or soc/intel/baytrail/common
> > directory and move pieces that are the same for both chipsets into
> > those directories. Work on consolidation, and getting as much as is
> > reasonable into that directory. I'd prefer not to just leave files in
> > soc/intel/baytrail because then it's not obvious that the files are
> > shared between the two platforms.
> >
> >
> > Similar steps could be done for the other fsp/non-fsp directories:
> > cpu/(fsp_)model_206ax, northbridge/(fsp_)sandybridge, and
> > southbridge/intel/(fsp_)bd82x6x.
> >
> > Ben, Michael, Since you seem to be actively working in this code, how
> > do you feel about this?
>
> I'm OK with reducing duplication and unnecessary differences.
> There seems to be plenty of duplicate header files.
> Without a similar tree structure and filenames, it is difficult to
> compare the trees, so I'd sync that first.
>
> I'd prefer seeing common baytrail stuff in soc/intel/baytrail_common/
> vs under baytrail/common.
>
> Ben
>
> > Martin
> >
> > On Sun, Dec 6, 2015 at 11:54 PM, Alex G. <mr.nuke.me(a)gmail.com> wrote:
> >> On 12/06/2015 08:18 AM, Alexander Couzens wrote:
> >>> hi,
> >>>
> >>> baytrail and fsp_baytrail shares a lot of code.
> >>> Any ideas how we can merge these?
> >>
> >> That's not a very good idea. There are different sets of interest which
> >> use those two code paths, and trying to unify that will only get people
> >> stepping on each others toes.
> >>
> >> At most, you can make fsp_baytrail/ use the CPU part of baytrail/, but
> >> leave the northbridge and southbridge parts alone.
> >>
> >> My advice, just stash the fsp_baytrail/ in some dark basement and forget
> >> about it. If it gets in the way or gives you trouble, let me know, but
> >> otherwise, just pretend it doesn't exist
> >>
> >> Alex
> >>
> >> --
> >> coreboot mailing list: coreboot(a)coreboot.org
> >> http://www.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
