> Yep, I am another crypto currencies miner. But in all truth,
> I find the hardware challenge more fun then the bitcoin stuff.
Thank you for conforming. Nothing wrong with it, as far as I can tell. :-)
But for the sake of time, you should have this setup working ASAP.
This is the aim, isn't it?
Hi David,
After trying to use SeaBIOS as payload, I got more information about reboot
issue as attached file. While U-Boot just reboots directly and Grub hangs, the
SeaBIOS’s dump complains “No bootable device” at the end. Do you think is it
the cause of reboot? Can I say my U-Boot and Grub ver
> 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.
H. 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 pos
On 04.01.2018 15:31, mer...@aaathats3as.com wrote:
On 2018-01-02 20:49, Nico Huber wrote:
As you mentioned that you didn't change other settings, may I assume
that you run the same ME firmware with coreboot and vendor during your
tests? also, is your ME firmware in its original state?
I'm sorr
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 Int
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 rese
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
Hi
What target are you on?
Coreboot tries to locate all PCI BAR's below 4G in the PCI_MMIO region and
above the lower DRAM
limit (the rest of the DRAM is mapped above 4G). Typically a GPU takes
around 256M but I guess that could be more nowadays. If that doesn't fit
in the PCI MMIO region, it wi
-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
On 2018-01-02 20:49, Nico Huber wrote:
As you mentioned that you didn't change other settings, may I assume
that you run the same ME firmware with coreboot and vendor during your
tests? also, is your ME firmware in its original state?
I'm sorry, I missed that. Intel ME was neutralized with me_c
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 us
> ... 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?
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 o
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
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
15 matches
Mail list logo
