coreboot January 2018

coreboot@coreboot.org

60 participants
155 discussions

Re: [coreboot] 16 GPUs on one board
by Adam Talbot 05 Jan '18

05 Jan '18

Yep, I am another crypto currencies miner. But in all truth, I find the hardware challenge more fun then the bitcoin stuff. Power is not the issue (any more). I have 2Kw worth of PSU. 2X HP Common slot 750W PSU + Thermaltake 500W PSU. Currently, with all 8 cards running full tilt, across two motherboards, and I am drawing 960~1000W. Those numbers are according to a Kill-A-Watt meter. Hardware wise, this is all x86_64. Arthur: Thanks for the details. I have a board that with give me a "missing memory" beep code with more then 6 GPUs. Now I understand why! How can I track down how much system DRAM a GPU is using? These are all the newest Nvidia Pascal based cards. Mostly GTX 1070's. On an interesting note, one of my oldest motherboards, a Gigabyte GA-970A-UD3 will boot with all 8 cards, but gives me the no VGA beep code. Serial console for the win! Is this just a BIOS level issue? Or is there some hardware component I should be aware of? Thanks for the help. -Adam On Thu, Jan 4, 2018 at 8:14 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > I am totally off the deep end and don't know where else to turn > > for help/advice. I am trying to get 16 GPU's on one motherboard. > > Hmmmm. Yet another crypto currencies miner. ;-) > > > Whenever I attach more then 3~5 GPU's to a single motherboard, > > it fails to post. To make matters worse, my post code reader(s) don't > > seem to give me any good error codes. Or at least nothing I can go on. > > You should have at minimum 1KW PSU for this job. At least... I guess, > even more (for 16 discrete GPUs) 2 x 1KW would be reasonable. > > Zoran > _______ > > On Thu, Jan 4, 2018 at 8:38 PM, Adam Talbot <ajtalbot1(a)gmail.com> wrote: > > -Coreboot > > I am totally off the deep end and don't know where else to turn for > > help/advice. I am trying to get 16 GPU's on one motherboard. Whenever I > > attach more then 3~5 GPU's to a single motherboard, it fails to post. To > > make matters worse, my post code reader(s) don't seem to give me any good > > error codes. Or at least nothing I can go on. > > > > I am using PLX PEX8614 chips (PCIe 12X switch) to take 4 lanes and pass > them > > to 8 GPU's, 1 lane per GPU. Bandwidth is not an issues as all my code > runs > > native on the GPUs. Depending on the motherboard, I can get up to 5 > GPU's to > > post. After many hours of debugging, googling, and trouble shooting, I > am > > out of ideas. > > > > At this point I have no clue. I think there is a hardware, and a BIOS > > component? Can you help me understand the post process and where the > hang up > > is occurring? Do you think Coreboot will get around this hangup and, if > so, > > can you advise a motherboard for me to test with? > > > > Its been a long time sense I last compiled linuxbios. ;-) > > > > Thanks > > -Adam > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] 16 GPUs on one board
by Zoran Stojsavljevic 05 Jan '18

05 Jan '18

> I am totally off the deep end and don't know where else to turn > for help/advice. I am trying to get 16 GPU's on one motherboard. Hmmmm. Yet another crypto currencies miner. ;-) > Whenever I attach more then 3~5 GPU's to a single motherboard, > it fails to post. To make matters worse, my post code reader(s) don't > seem to give me any good error codes. Or at least nothing I can go on. You should have at minimum 1KW PSU for this job. At least... I guess, even more (for 16 discrete GPUs) 2 x 1KW would be reasonable. Zoran _______ On Thu, Jan 4, 2018 at 8:38 PM, Adam Talbot <ajtalbot1(a)gmail.com> wrote: > -Coreboot > I am totally off the deep end and don't know where else to turn for > help/advice. I am trying to get 16 GPU's on one motherboard. Whenever I > attach more then 3~5 GPU's to a single motherboard, it fails to post. To > make matters worse, my post code reader(s) don't seem to give me any good > error codes. Or at least nothing I can go on. > > I am using PLX PEX8614 chips (PCIe 12X switch) to take 4 lanes and pass them > to 8 GPU's, 1 lane per GPU. Bandwidth is not an issues as all my code runs > native on the GPUs. Depending on the motherboard, I can get up to 5 GPU's to > post. After many hours of debugging, googling, and trouble shooting, I am > out of ideas. > > At this point I have no clue. I think there is a hardware, and a BIOS > component? Can you help me understand the post process and where the hang up > is occurring? Do you think Coreboot will get around this hangup and, if so, > can you advise a motherboard for me to test with? > > Its been a long time sense I last compiled linuxbios. ;-) > > Thanks > -Adam > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Doubt about SPD init in Skylake
by Nico Huber 04 Jan '18

04 Jan '18

Hi Merle, you should always keep the mailing list addressed. Otherwise you'll get less responses, obviously. Please tell us more about your project. Is it a hobby thing? or do you work on a professional product? it really matters, because in the latter case you should try to get a contact to Intel and ask them. On 04.01.2018 09:08, 王翔 wrote: > I found this array on https://github.com/IntelFsp/FSP/blob/Skylake/SkylakeFspBinPkg/Docs/SkylakeF… 4.1.2.1 section . > But , what's meaning? It's not documented. Some lucky people have access to the FSP source code and might be able to tell. > How get this value ? From board schematics and Intel's Platform Design Guide mostly. Nico

1 0

Re: [coreboot] 16 GPUs on one board
by Testerman, Brett 04 Jan '18

04 Jan '18

We use a PLX chip in our design and I will say they are incredibly sensitive to reset. Are you sure your voltages are holding up during startup? The fact that it works with a limited number of GPU’s would be indicative of voltage sag due to the higher inrush current. A slow rise time on the reset signal can cause a lot of devices to not come out of reset properly. Same with the reset line de-asserting before all the voltages were stable. Brett From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Adam Talbot Sent: Thursday, January 04, 2018 12:39 PM To: coreboot(a)coreboot.org Subject: [coreboot] 16 GPUs on one board ** The Sender is from outside the Cobham Commercial Datacentre organisation ** -Coreboot I am totally off the deep end and don't know where else to turn for help/advice. I am trying to get 16 GPU's on one motherboard. Whenever I attach more then 3~5 GPU's to a single motherboard, it fails to post. To make matters worse, my post code reader(s) don't seem to give me any good error codes. Or at least nothing I can go on. I am using PLX PEX8614 chips (PCIe 12X switch) to take 4 lanes and pass them to 8 GPU's, 1 lane per GPU. Bandwidth is not an issues as all my code runs native on the GPUs. Depending on the motherboard, I can get up to 5 GPU's to post. After many hours of debugging, googling, and trouble shooting, I am out of ideas. At this point I have no clue. I think there is a hardware, and a BIOS component? Can you help me understand the post process and where the hang up is occurring? Do you think Coreboot will get around this hangup and, if so, can you advise a motherboard for me to test with? Its been a long time sense I last compiled linuxbios. ;-) Thanks -Adam

1 0

Re: [coreboot] BDX-DE PCI init fail
by David Hendricks 04 Jan '18

04 Jan '18

Hi Hilbert, For what it's worth, I was able to boot Linux as the payload without any obvious problems. It might be good to try other payloads, or see if you can enable serial console earlier in u-boot to find exactly where it reboots. Here is my CPUID and microcode info printed by coreboot during ramstage: microcode: sig=0x50664 pf=0x10 revision=0xf00000c CPUID: 00050664 Cores: 32 Stepping: Y0 Revision ID: 05 So it appears I am using the production CPU and microcode that Zoran suggested. To obtain this, I downloaded SRV_P_203.exe from Intel's website and converted M1050664_0F00000C.TXT into a C-style header that can be included by coreboot's build system. On Thu, Jan 4, 2018 at 3:19 AM, Hilbert Tu(杜睿哲_Pegatron) < Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi Zoran, > > About this issue, I decide to follow David's suggestion to comment out the > SMBus clock gating and then it can continue booting until load my U-Boot > payload. But then it enters infinite reboot as previous attached log > "smbus_init_fail_max_dump2.txt". I am not sure if is a side effect or > just a new issue. Do you have any recommendation about the reboot? By the > way, we have our own BDX-DE board, not Camelback CRB. But just use similar > configuration. Thanks. > > -Hilbert > This e-mail and its attachment may contain information that is > confidential or privileged, and are solely for the use of the individual to > whom this e-mail is addressed. If you are not the intended recipient or > have received it accidentally, please immediately notify the sender by > reply e-mail and destroy all copies of this email and its attachment. > Please be advised that any unauthorized use, disclosure, distribution or > copying of this email or its attachment is strictly prohibited. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件， > 請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。 >

1 0

16 GPUs on one board
by Adam Talbot 04 Jan '18

04 Jan '18

-Coreboot I am totally off the deep end and don't know where else to turn for help/advice. I am trying to get 16 GPU's on one motherboard. Whenever I attach more then 3~5 GPU's to a single motherboard, it fails to post. To make matters worse, my post code reader(s) don't seem to give me any good error codes. Or at least nothing I can go on. I am using PLX PEX8614 chips (PCIe 12X switch) to take 4 lanes and pass them to 8 GPU's, 1 lane per GPU. Bandwidth is not an issues as all my code runs native on the GPUs. Depending on the motherboard, I can get up to 5 GPU's to post. After many hours of debugging, googling, and trouble shooting, I am out of ideas. At this point I have no clue. I think there is a hardware, and a BIOS component? Can you help me understand the post process and where the hang up is occurring? Do you think Coreboot will get around this hangup and, if so, can you advise a motherboard for me to test with? Its been a long time sense I last compiled linuxbios. ;-) Thanks -Adam

1 0

Re: [coreboot] Depthcharge License
by tturne＠codeaurora.org 04 Jan '18

04 Jan '18

On 2017-12-24 05:27, Ivan Ivanov wrote: > This commit got merged and the Depthcharge now should have the > requested license files > at its root directory. Dear friend, please let us learn about your > device once it is released, > maybe some of the coreboot developers would want to get your device - > to use, and possibly help > > Best regards, > Ivan Ivanov > Forgive my lack of list etiquette. With this commit, my legal department is satisfied and has given engineering the green light. Will share details on project as and when I can. Thanks all who responded and contributed to resolving issue raised by this thread. Cheers, T.mike > 2017-12-21 21:34 GMT+03:00 Aaron Durbin via coreboot > <coreboot(a)coreboot.org>: >> https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/… >> >> On Thu, Dec 21, 2017 at 11:14 AM, <tturne(a)codeaurora.org> wrote: >>> >>> On 2017-12-19 09:53, David Hendricks wrote: >>>> >>>> To be fair, it appears that many source files refer to a >>>> non-existent >>>> LICENSE file. Someone on the CrOS team should probably just add the >>>> LICENSE file for depthcharge and/or contact mal@ to see how the >>>> license info is being collected these days (e.g. for >>>> chrome://os-credits [3]). >>>> >>> >>> Thanks for the input on the DC licensing, and because lawyers are >>> involved >>> I need to ask a direct question. >>> Can a Depthcharge maintainer (anybody who has +2 gerrit authority >>> would >>> suffice) state on this thread >>> that the Depthcharge project license is GPLv2 (or later)? >>> >>> I know this feels redundant and that the question has been asked and >>> answered, I'm just trying >>> to satisfy our internal legal group. >>> >>> Per David's point above, this direct question would not be required >>> to >>> satisfy the lawyers >>> if a top-level COPYING or LICENSE file is added to Depthcharge. >>> Which I >>> will be happy to >>> add once I'm able to start contributing to the project. >>> Cheers, >>> T.mike >>> >>>> On Tue, Dec 19, 2017 at 9:19 AM, ron minnich <rminnich(a)gmail.com> >>>> wrote: >>>> >>>>> Is there even a question? Looks like aaron just answered the >>>>> original question, which boils down to Read The Source? >>>>> >>>>> On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot >>>>> <coreboot(a)coreboot.org> wrote: >>>>> >>>>> On Tue, Dec 19, 2017 at 8:03 AM, <tturne(a)codeaurora.org> wrote: >>>>> On 2017-12-15 13:39, tturne(a)codeaurora.org wrote: >>>>> Preparing to mirror the coreboot.org [1] requires us to vet the >>>>> various >>>>> licenses, etc. >>>>> >>>>> There doesn't appear to be a LICENSE or COPYING file in the >>>>> Depthcharge tree. >>>>> >>>>> My understanding is that Depthcharge is licensed GPLv2 (or later). >>>>> >>>>> How would I confirm this with an online source? >>>>> >>>>> Cheers, >>>>> T.mike >>>>> >>>>> Should this query be posted on Chromium list rather than Coreboot >>>>> list? >>>> >>>> >>>> Probably. The files in the depthcharge repository have licenses at >>>> the top of each file. They are GPLv2. >>>> >>>>> Cheers, >>>>> T.mike >>>>> >>>>> -- >>>>> coreboot mailing list: coreboot(a)coreboot.org >>>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2] >>>> >>>> -- >>>> coreboot mailing list: coreboot(a)coreboot.org >>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2] >>>> -- >>>> coreboot mailing list: coreboot(a)coreboot.org >>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2] >>>> >>>> >>>> >>>> Links: >>>> ------ >>>> [1] http://coreboot.org >>>> [2] https://mail.coreboot.org/mailman/listinfo/coreboot >>>> [3] https://www.chromium.org/chromium-os/licenses >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] BDX-DE PCI init fail
by Zoran Stojsavljevic 04 Jan '18

04 Jan '18

> ... I am not sure if is a side effect or just a new issue. Do you have any recommendation about the reboot? [1] The complete boot log is beneficial as far as you have progressed... Isn't it? But you can also try SeaBIOS as payload (let go with simple ones), and see how far you'll go with it? [2] Would be nice to try all of this on your own proprietary board (I hope you have there CPUID 0x50664), and see how it goes (with logs, as well)?! Bis Heute Abend, oder Morgen, Zoran _______ On Thu, Jan 4, 2018 at 12:19 PM, Hilbert Tu(杜睿哲_Pegatron) <Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi Zoran, > > About this issue, I decide to follow David's suggestion to comment out the SMBus clock gating and then it can continue booting until load my U-Boot payload. But then it enters infinite reboot as previous attached log "smbus_init_fail_max_dump2.txt". I am not sure if is a side effect or just a new issue. Do you have any recommendation about the reboot? By the way, we have our own BDX-DE board, not Camelback CRB. But just use similar configuration. Thanks. > > -Hilbert > This e-mail and its attachment may contain information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Re: [coreboot] BDX-DE PCI init fail
by Hilbert Tu(杜睿哲_Pegatron) 04 Jan '18

04 Jan '18

Hi Zoran, About this issue, I decide to follow David's suggestion to comment out the SMBus clock gating and then it can continue booting until load my U-Boot payload. But then it enters infinite reboot as previous attached log "smbus_init_fail_max_dump2.txt". I am not sure if is a side effect or just a new issue. Do you have any recommendation about the reboot? By the way, we have our own BDX-DE board, not Camelback CRB. But just use similar configuration. Thanks. -Hilbert This e-mail and its attachment may contain information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited. 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Re: [coreboot] BDX-DE PCI init fail
by Zoran Stojsavljevic 04 Jan '18

04 Jan '18

YES, U R correct. BDX-DE supoosed to be SoC, as I now recall. It was once upon a time/a long time back, about 2.5 to 3 years ago I played with this stuff. You supposed NOT to use anything beneath 0x50663 (forget 0x50661/2). I have no idea why you are using PPR 0x50663, the production part (PR) is actually 0x50664. My best guess, you are using some CRB (CamelBack Mountain CRB?!) as given, with FSP v 1.0. And I recall, this should work... Out of box, although I never tried it with FSP. I tried it with the internal AMI/INTEL UEFI and Fedora 23, IIRC?! I tried 0x50661 and 0x50662, but also with internal AMI/INTEL UEFI. Werner (if he recalls the stuff, since Werner most certainly played with FSP on CamelBack Mountain CRB) can help... If?! Zoran On Thu, Jan 4, 2018 at 10:06 AM, Hilbert Tu(杜睿哲_Pegatron) <Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi Zoran, > > I don't understand. We don't have extra MCU and, from following message, we also have correct microcode. Why you mean we should have " PPR 0x50663 PPR PCH "? My understanding is they are in/just the same chip...Please help to clarify. Thanks. > >>>microcode: sig=0x50663 pf=0x10 revision=0x700000e <<=========================== >>>CPUID: 00050663 > > -Hilbert > This e-mail and its attachment may contain information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2018