December 2015 - coreboot - mail.coreboot.org

Re: [coreboot] Lenovo Carbon X1
by Gerhard Gappmeier Dec. 13, 2015

Dec. 13, 2015

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

1 0

Re: [coreboot] FSPInitiNot Returning
by David Crammer Dec. 9, 2015

Dec. 9, 2015

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

1 0

Re: [coreboot] FSPInitiNot Returning
by Jin, Huang Dec. 9, 2015

Dec. 9, 2015

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

1 0

Re: [coreboot] FSPInitiNot Returning
by David Crammer Dec. 9, 2015

Dec. 9, 2015

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 >

1 0

Re: [coreboot] FSPInitiNot Returning
by Jin, Huang Dec. 9, 2015

Dec. 9, 2015

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

1 0

FSPInitiNot Returning
by David Crammer Dec. 9, 2015

Dec. 9, 2015

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

1 0

Re: [coreboot] baytrail + fsp_baytrail
by Ben Gardner Dec. 8, 2015

Dec. 8, 2015

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

1 0

Re: [coreboot] baytrail + fsp_baytrail
by Peter Stuge Dec. 8, 2015

Dec. 8, 2015

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

2 1

Re: [coreboot] baytrail + fsp_baytrail
by Alex G. Dec. 8, 2015

Dec. 8, 2015

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

1 1

Re: [coreboot] baytrail + fsp_baytrail
by ron minnich Dec. 8, 2015

Dec. 8, 2015

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 >

1 0