[coreboot] KGPE-D16 coreboot support open call

[Piotr Król]

Hi all,
since Immunefi was so kind to put 15k EUR pledge for [1] we host open
call where we will discuss future of KGPE-D16 and its coreboot support.

If you interested about this hardware feel free to join at 15:00 UTC:
https://meet.3mdeb.com/kgpe-d16-refresh

We will post minutes on github.

[1] https://github.com/osresearch/heads/issues/719
-- 
Piotr Król
Founder and Chief Executive Officer
GPG: B2EE71E967AA9E4C
https://3mdeb.com | @3mdeb_com



OpenPGP_signature
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] KGPE-D16: Working single-CPU configuration with 96 GB of RAM

[Daniel Kulesz via coreboot]

Hi folks,

albeit the board has been deprecated in coreboot 4.11, I wanted to contribute a 
working RAM setup for all who still use it. I managed to run a KGPE-D16 with a 
single CPU (Opteron 6380) and 96 GB of RAM and the following LRDIMMs:

orange slots: 4x Samsung 16 GB DDR3L reg ECC (M393B2G70BH0-YK0)
black slots: 4x Samsung 8 GB DDR3L reg ECC (M393B1K70DH0-YK0)

Using full 128 GB with the 16 GB modules resulted in ECC errors during 
memtester runs (and under heavy load). Also, I was not able to get a 
configuration with 96 GB using only 16 GB modules running - neither by the 
configuration described as problematic in the Wiki (leaving the slots next to 
the CPU empty) nor using the configuration desribed in the user manual (leaving 
the slots B1 and D1 empty.

I tested the "working so far" configuration with memtester (running aprox 10 
minutes) and by compiling AOSP for about one hour with 80 GB allocated to the 
VM where the compilation is running. No entries about ECC-recovered hardware 
errors and such in syslog so far (unline the previous run when I had 128 GB in 
the machine).

Btw.: For me, it would make sense to have a section in the documentation about 
boards that were previously supported in coreboot such as the KGPE-D16 that is 
currently missing there.

Cheers, Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] KGPE-D16 maintainership

[Piotr Król]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,
we see a lot of attention around KGPE-D16 maintainership problems.
After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb
decided to help in maintaining that platform by organizing crowd
founding campaign or getting founds in other ways (direct sponsors).

Since we are based in Poland there is chance that even with small
contribution from community we would be able to cover the costs.

Ideal plan would be to have structure similar to what we maintain for
PC Engines:
https://pcengines.github.io/
Where we providing signed and reproducible binaries every month and
keep as close to mainline as possible. Of course if development will
be active, then there always would be delta of patches held in review.

Unfortunately we don't have hardware. During OSFC 2019 Stefan left one
board, but it was too late (and probably too expensive) for us to
organize any shipment to Poland. We looking to have 2 mainboards one
for development and one in our automated regression testing
environment. Of course we will start even with just one.

If anyone is willing to help in founding, sponsoring hardware or by
code development and testing we would be very grateful.

Please copy other people and share this post wherever is necessary to
keep this platform alive. Positive feedback will help things rolling.

Best Regards,
- -- 
Piotr Król
Embedded Systems Consultant
GPG: B2EE71E967AA9E4C
https://3mdeb.com | @3mdeb_com
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAl2ApSoACgkQsu5x6Weq
nkw0XQ//WeO+U6VFcr6wsfCkv5qXnKVHb6XDXyEknhu7Q82HZ9Hx+0IiZ0+ikzVZ
oLU36euPwlHoRFh3HPm34DHeeYAZYzzsdc41+0MZJao152CGZJQwe+pqD/JeymOU
Jky+PhULeGKXt22ftbxte1ac82tRDFt//0Yc07qxP9G/CboZ8sjckKjfyfoy5PFm
9jRFwdZUMbU42mU+NYLn/iXGWM/+mxC+ghncQBYwwGX1npr1r5gSiZS9ImoHFpgj
DQaaUQq2v8vS1uvYZ84vVEXeOljTkzFg7UyUZq3sSob8bA/a42rsgFMPVI6Bpc5R
lAEdhBZgMaD4jjO2GK+3zFSy32pBvK71tzwrdLjhb/bjjN1phHy2zbwTebFWlyiu
HQJ/+iu4uoTQj69GT9i7HLyngorh37GWFHKScDDzEASnSO868ELhlrt+yHwyY284
EAe7dTOhOtfdxJOKcfdyUez5nwPZON4AXEVSvLWLUv4r+f82CG89f+LLg7rbZH5n
C0HnUOJas89xEvRhXChTBHnM9NBKSWpch5uZ5SbZHb/JCWBb26yT6Ua46H0STFRh
y+pWHc8AN76FQnWvpYer5F3hyVEX1+wAsi+RJMROFUejCn3lCl5ogAnT4ZRCqzo3
61Ao6dYmtYhaQ3JjZ+5bv3926ZwRjvr7i5t9bHf9THXCn1UobjY=
=wYUt
-END PGP SIGNATURE-
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] KGPE-D16: using linux kernel with SLUB MEM_ALLOCATOR -> KERNEL SPINLOCK PANIC

[Kinky Nekoboi]

not sure if coreboot or kernel related.

vanila kernel 4.19.62 with SLAB allocater build works fine.

Debians Busters default kernel 4.19.x with SLUB panics.

see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930029

see Bootlog:

oading Linux 4.19.0-5-amd64 ...Loading Linux 4.19.0-5-amd64 ..
.
Loading initial ramdisk ...Loading initial ramdisk ..
.
[    0.00] Linux version 4.19.0-5-amd64
(debian-ker...@lists.debian.org) (g)
[    0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
root=UUID=0
[    0.00] random: get_random_u32 called from
bsp_init_amd+0x20b/0x2b0 with0
[    0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating
point reg'
[    0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.00] x86/fpu: Enabled xstate features 0x7, context size is 832
bytes,.
[    0.00] BIOS-provided physical RAM map:
[    0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[    0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
reserved
[    0.00] BIOS-e820: [mem 0x000f-0x000f]
reserved
[    0.00] BIOS-e820: [mem 0x0010-0xb7d97fff] usable
[    0.00] BIOS-e820: [mem 0xb7d98000-0xb7ff]
reserved
[    0.00] BIOS-e820: [mem 0xb800-0xbfffafff] usable
[    0.00] BIOS-e820: [mem 0xbfffb000-0xcfff]
reserved
[    0.00] BIOS-e820: [mem 0xfcf0-0xfcf03fff]
reserved
[    0.00] BIOS-e820: [mem 0xfeb0-0xfeb00fff]
reserved
[    0.00] BIOS-e820: [mem 0xfec0-0xfec00fff]
reserved
[    0.00] BIOS-e820: [mem 0xfed0-0xfed00fff]
reserved
[    0.00] BIOS-e820: [mem 0xfed4-0xfed44fff]
reserved
[    0.00] BIOS-e820: [mem 0x0001-0x000437ff] usable
[    0.00] BIOS-e820: [mem 0x00043800-0x00043fff]
reserved
[    0.00] bootconsole [earlyser0] enabled
[    0.00] NX (Execute Disable) protection: active
[    0.00] SMBIOS 2.7 present.
[    0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.9-1859-gf3510cbe36
05/31/2019
[    0.00] tsc: Fast TSC calibration using PIT
[    0.00] tsc: Detected 2500.121 MHz processor
[    0.010404] AGP: No AGP bridge found
[    0.013881] last_pfn = 0x438000 max_arch_pfn = 0x4
[    0.021404] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC-
WT 
Memory KASLR using RDTSC...
[    0.030856] last_pfn = 0xbfffb max_arch_pfn = 0x4
[    0.042030] Using GB pages for direct mapping
[    0.046429] RAMDISK: [mem 0x3476f000-0x363aefff]
[    0.050877] ACPI: Early table checksum verification disabled
[    0.056563] ACPI: RSDP 0x000F6250 24 (v02 COREv4)
[    0.062225] ACPI: XSDT 0xB7D990E0 74 (v01 COREv4 COREBOOT
00)
[    0.070720] ACPI: FACP 0xB7D9B9A0 F4 (v03 COREv4 COREBOOT
00)
[    0.079213] ACPI: DSDT 0xB7D99280 00271A (v02 COREv4 COREBOOT
00)
[    0.087704] ACPI: FACS 0xB7D99240 40
[    0.092298] ACPI: FACS 0xB7D99240 40
[    0.096890] ACPI: SSDT 0xB7D9BAA0 0020F2 (v02 COREv4 COREBOOT
00)
[    0.105383] ACPI: MCFG 0xB7D9DBA0 3C (v01 COREv4 COREBOOT
00)
[    0.113875] ACPI: APIC 0xB7D9DBE0 DE (v02 COREv4 COREBOOT
00)
[    0.122369] ACPI: SRAT 0xB7D9DCC0 0001A8 (v01 COREv4 COREBOOT
00)
[    0.130862] ACPI: SLIT 0xB7D9DE68 30 (v01 COREv4 COREBOOT
00)
[    0.139355] ACPI: SRAT 0xB7D9DEA0 0001A8 (v01 COREv4 COREBOOT
00)
[    0.147848] ACPI: SLIT 0xB7D9E048 30 (v01 COREv4 COREBOOT
00)
[    0.156341] ACPI: IVRS 0xB7D9E080 BC (v01 COREv4 COREBOOT
00)
[    0.164834] ACPI: HPET 0xB7D9E140 38 (v01 COREv4 COREBOOT
00)
[    0.173380] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[    0.177747] SRAT: PXM 0 -> APIC 0x01 -> Node 0
[    0.182167] SRAT: PXM 0 -> APIC 0x02 -> Node 0
[    0.186586] SRAT: PXM 0 -> APIC 0x03 -> Node 0
[    0.191006] SRAT: PXM 0 -> APIC 0x04 -> Node 0
[    0.195426] SRAT: PXM 0 -> APIC 0x05 -> Node 0
[    0.199845] SRAT: PXM 0 -> APIC 0x06 -> Node 0
[    0.204264] SRAT: PXM 0 -> APIC 0x07 -> Node 0
[    0.208685] SRAT: PXM 1 -> APIC 0x08 -> Node 1
[    0.213104] SRAT: PXM 1 -> APIC 0x09 -> Node 1
[    0.217525] SRAT: PXM 1 -> APIC 0x0a -> Node 1
[    0.221944] SRAT: PXM 1 -> APIC 0x0b -> Node 1
[    0.226364] SRAT: PXM 1 -> APIC 0x0c -> Node 1
[    0.230784] SRAT: PXM 1 -> APIC 0x0d -> Node 1
[    0.235204] SRAT: PXM 1 -> APIC 0x0e -> Node 1
[    0.239624] SRAT: PXM 1 -> APIC 0x0f -> Node 1
[    0.244046] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
[    0.250025] ACPI: SRAT: Node 1 PXM 1 [mem 0x0010-0xbfff]
[    0.256004] ACPI: SRAT: Node 1 PXM 1 [mem 

[coreboot] KGPE-D16: coreboot-4.5 stuck in boot loop. Help on getting the system to boot or flash newer version

[Pablo Correa Gómez]

Hello and thank you in advance for your time.

 I recently bought a KGPE-D16 motherboard with a single AMD Opeteron
8262SE and coreboot installed. I bought from another supplier 4 memory
sticks Samsung 8GB (M393B1K70DH0-YK0) that per this thread[1] should
work with coreboot. I am able to start the assembled system and to get
serial output. According to the logs, coreboot first does the
initialisation and training of the memory and then start working on the
PCIs. At one point in the boot sequence, I get the following message:

Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 80561 exit 0
POST: 0x7b
Jumping to boot code at 000ff06e(b7cc1000)
POST: 0xf8
CPU0: stack: 0015 - 00151000, lowest used address 001509e0, stack
used: 1568 bytes
entry= 0x000ff06e
lb_start = 0x0010
lb_size  = 0x00116270
buffer   = 0xbfdd3000

Then it stalls for like 20-30 seconds and the booting process restarts
from the beginning. I had considered different options in order to boot
and I would like to know if someone would have any recommendations.
Right now my priority is to get the system up and working. I can worry
about installing coreboot later, but having it now is for sure a plus:
  1) Buy a new chip with the original ASUS BIOS in order to boot the
system.
  2) Externally flash the chip I have right now with a newer version of
coreboot. I probably have enough things at home to flash it, but I have
not found information from ASUS. In coreboot there is some information
but very general and not enough for my knowledge. As far as I have read
from flashrom, I should be able to flash it using a Raspberry Pi or a
BeagleBone Black, but KGPE-D16 is not marked as supported and I don't
know which model is the BIOS chip to check if it is supported.
  3) The moderboard datasheet has a section called: "Force BIOS
recovery setting", which says that in order to flash the proprietary
BIOS, it is as simple as changing a jumper an inserting an USB stick. I
would have already done it if I would not be reluctant to believe that
it is that simple.

Which are your thoughts about this ideas? Any other one that would be
simpler and would let me boot the full system?

Thank you very much,
Pablo.


NOTE: I have tried with the 4 sticks in the orange slots, the 4 sticks
in the 4 further DIMMs from the CPU (2 orange, 2 black) and those
configurations both 1.35 and 1.5V. Logs are slightly different, in the
training section, but the problem while booting remains. A USB stick
with Debian Installer has been plugged-in during since boot process
begins.

[1] https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.h
tml
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] KGPE-D16/KCMA-D8 Tip: Force sensor module load order to avoid the improper changing of hwmon paths which breaks fancontrol

[Nico Huber]

Hi,

>> Side note: I still wish there was an easier way to do this; I never
>> bothered transferring documentation to GIT because of the added time /
>> complexity vs. the Wiki WYSIWYG editor.

we are writing documentation in markdown now. IMHO, a much better choice
than WYSIWYG because you can work much faster without caring how things
look (if you are not sure about the syntax you can use a modern editor
like Vim that highlights things accordingly). You should just try it,
since I got used to it, it's like writing code, you can finally concen-
trate on the contents. Having things in Git also makes it much easier
to track changes and to have reviewed documentation. The Wiki was full
of nonsense, so the review is really necessary.

> 
> Ditto
> 
> I edited and made a variety of very helpful wiki pages but even after
> the community voted to keep the wiki the powers that be got rid of it
> just the same.

You are confusing community with non-developer-only-active-on-the-
mailing-list-not-much-contributing part of the community. At least
that is how the votes against the switch were seen by the coreboot
community.

> 
> When I have some extra cash I am going to create my own coreboot wiki
> website with a copy of the previous one since whomever is in charge no
> longer wishes to host it and I am not willing to transfer everything
> especially without an easy editor and ability to add images/charts
> etc...the latest mediawiki version has a top notch WYSIWYG editor!

There was another reason to abandon the Wiki that you seem to have for-
gotten: Its contents aren't licensed. You can copy them but just be
warned that it might be illegal in your jurisdiction.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16/KCMA-D8 Tip: Force sensor module load order to avoid the improper changing of hwmon paths which breaks fancontrol

[taii...@gmx.com]

On 12/11/2018 05:34 PM, Timothy Pearson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 12/10/2018 07:48 PM, taii...@gmx.com wrote:
>> Applicable to:
>> SP5100 AMD C32/G34 systems such as the KCMA-D8 and KGPE-D16.
>>
>> Situation: If you don't have OpenBMC installed you need to run
>> pwmconfig/fancontrol to manage fan speeds.
>>
>> Problem:
>> Normally the hwmon paths will change almost every boot resulting in the
>> need to run pwmconfig repeatedly or fix them manually in /etc/fancontrol
>> - this was driving me nuts so I searched for and found a solution.
>>
>> Solution:
>> Create a .conf file in /etc/modprobe.d/ to set sensor module load order
>> with these contents then reboot and fix the hwmon paths in your
>> /etc/fancontrol, reboot again and all should be well :D
>>
>> softdep fam15h_power pre: k10temp
>> softdep k10temp pre: jc42
>> softdep jc42 pre: w83795g
>> softdep w83795g pre: radeon
>>
> 
> We should probably create a board documentation tips/tricks section in
> GIT since the Wiki is no longer available.

Or create a website with a copy of the wiki.

> 
> Side note: I still wish there was an easier way to do this; I never
> bothered transferring documentation to GIT because of the added time /
> complexity vs. the Wiki WYSIWYG editor.

Ditto

I edited and made a variety of very helpful wiki pages but even after
the community voted to keep the wiki the powers that be got rid of it
just the same.

When I have some extra cash I am going to create my own coreboot wiki
website with a copy of the previous one since whomever is in charge no
longer wishes to host it and I am not willing to transfer everything
especially without an easy editor and ability to add images/charts
etc...the latest mediawiki version has a top notch WYSIWYG editor!

I feel as though not many people really care about nurturing the
non-developer power-user part of the coreboot community, it is choices
like getting rid of the easy to edit wiki that discourage potential
users by making things seem more difficult and out of principal I simply
refuse to give my "real" name (like there is any way for them to check)
to obtain a git account.

Despite what people say it was quite easy for me to obtain a wiki
account I just followed the instructions and got one a week later
(although you might have had something to do with that :3]

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16/KCMA-D8 Tip: Force sensor module load order to avoid the improper changing of hwmon paths which breaks fancontrol

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/10/2018 07:48 PM, taii...@gmx.com wrote:
> Applicable to:
> SP5100 AMD C32/G34 systems such as the KCMA-D8 and KGPE-D16.
> 
> Situation: If you don't have OpenBMC installed you need to run
> pwmconfig/fancontrol to manage fan speeds.
> 
> Problem:
> Normally the hwmon paths will change almost every boot resulting in the
> need to run pwmconfig repeatedly or fix them manually in /etc/fancontrol
> - this was driving me nuts so I searched for and found a solution.
> 
> Solution:
> Create a .conf file in /etc/modprobe.d/ to set sensor module load order
> with these contents then reboot and fix the hwmon paths in your
> /etc/fancontrol, reboot again and all should be well :D
> 
> softdep fam15h_power pre: k10temp
> softdep k10temp pre: jc42
> softdep jc42 pre: w83795g
> softdep w83795g pre: radeon
> 

We should probably create a board documentation tips/tricks section in
GIT since the Wiki is no longer available.

Side note: I still wish there was an easier way to do this; I never
bothered transferring documentation to GIT because of the added time /
complexity vs. the Wiki WYSIWYG editor.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJcEDuAAAoJEK+E3vEXDOFbiFEH/jYYnja1p+ujqstkZezWbuPh
J6JUv3bgGFZwnexzE5MxDRbbUYfOBHDMSlBMu38pd66CHylQW5O4oQrgoWAEWDyT
UC2aboSfxwKm8A6NNYvtBlwYqKoyHDl886JudCBOlhnS9xayIQvE0tI8OIVq3ao1
WHfTfDflslZxIFJjogJ440gTdPhezZrSbbWmqVjpcWe2hj/KkAPdKgMY4R0WrqsV
L671iG+YB1b70+jt4fiESMgnr86XaFXvzpdXJY/COoj9bLuSRwgdCrwVEbkLc6Wd
ox4Y1NwT+k9UHXuAPHdiscwIJB1EPBJoBgOeawvK5x7kr/7hbxDctmiaJyffKgs=
=gGBK
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16/KCMA-D8 Tip: Force sensor module load order to avoid the improper changing of hwmon paths which breaks fancontrol

[taii...@gmx.com]

Applicable to:
SP5100 AMD C32/G34 systems such as the KCMA-D8 and KGPE-D16.

Situation: If you don't have OpenBMC installed you need to run
pwmconfig/fancontrol to manage fan speeds.

Problem:
Normally the hwmon paths will change almost every boot resulting in the
need to run pwmconfig repeatedly or fix them manually in /etc/fancontrol
- this was driving me nuts so I searched for and found a solution.

Solution:
Create a .conf file in /etc/modprobe.d/ to set sensor module load order
with these contents then reboot and fix the hwmon paths in your
/etc/fancontrol, reboot again and all should be well :D

softdep fam15h_power pre: k10temp
softdep k10temp pre: jc42
softdep jc42 pre: w83795g
softdep w83795g pre: radeon

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16/KCMA-D8 "PIKE" LSI SAS 2308 addon cards are going for $22 on fleabay

[taii...@gmx.com]

Thought y'all should know.

This is what installs in the weird reversed pci-e x4 slot at the bottom
of the motherboard.

Notes:
* It will obstruct the usage of the PCI slot and the use of a dual slot
card in the bottom most PCI-e slot (the white one not the blue
"graphics" slots)

* KCMA-D8 has a SR5670 instead of the better with more PCI-e lanes
SR5690 on the D16 according to the manual using a PIKE will shut off one
of your PCI-e slots (lame!) although this is still a better deal than
buying a more expensive regular LSI card.

* They have working FLR so they can be assigned to VM's easily.

If anyone knows how to get SR-IOV working on LSI controllers me know -
the 2008/2308 controllers were the first ones that according to the
advertising literature were meant to have the ability to assign drives
to virtual functions and then those virtual functions to VM's meaning
you could have some drives attached to one VM and some to another and so
on - with the ability to have a SAS expander one could have native pass
through physical drives for every VM this way.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[taii...@gmx.com]

Forgot to say - a theory is that the issue may be that you lack enough
lanes in the slot you are using.
As ASUS was cheap they didn't add a second northbridge to obtain more
PCI-e lanes as was done with the TYAN boards so while the slots are x16
physical you can't run all of them at that all the time - I would
consult the manual to see which is which I believe the configurations
are either x16 x8 x8 x4 or x16 x16 x4 (both also can use the PIKE slot
which part of it is a reversed PCI-e slot connected to the southbridge
rather than the northbridge)

Using an x8 slot with bifurcation and 4 x4 M2 cards could mean that you
lack enough lanes to bifurcate all 4 - as an experiment I suggest
hooking up the card to an x16 configured slot and putting your GPU in
the x8 slot instead (you won't notice a difference)

As you are able to hook up two M2 cards it appears that bifurcation is
working as I don't see any information that indicates you having a
switched card.

I suggest emailing my directly via your other email account as I am
moderated on the coreboot ML so replies take a long time - also I don't
like emailing gmail addresses.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[taii...@gmx.com]

Did you get my email? can you provide a:
dmesg
# lspci -t -v
# lspci -vv

Thanks

Most quad adapters use PCI-e bifurcation not a PCI-e switch and AFAIK
not many boards support bifurcation so you would need a switched model
which you might have (I am not sure) if you do have a switched card I
would also contact the OEM as there shouldn't be any reason as to why it
doesn't work.

Not having PCI-e 3.0 wouldn't make a difference at all in terms of the
card working with all 4 cards and if the cards uplink is PCI-e 2.0 x8 or
x16 you won't notice a difference in speed.

VROC is an optional wintel gimmick addon that shouldn't be required for
it to work - if you could link a .pdf manual I will find out if it is
switched or bifurcated.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[Daniel Kulesz via coreboot]

Thank you for your answers, Jason and Alberto.

While it's true that the hypercard is a PCIe 3.0 device, I did not see the 
reason yet why it would not operate in a PCIe 2.0 slot with lower throughput. 
And I am not sure but - is Intel VROC required to use all four M.2 slots?

Anyways, I am happy to report that I "resolved" the issue partially by getting 
rid of the GPU that occupies two slots, replacing it by one that occupies just 
1 slot. Then I installed the USB3 controller card next to it, resulting in the 
following setup:

1. (MIO): empty
2. GPU
3. USB3 controller card
4. Hypercard
5. Empty

This way, I have graphics, USB 3.0 and two M.2 slots working. In addition, I 
noticed that the system (without usb3) takes around 7-8W less in idle than with 
the previous gpu installed. That's a bit surprising as the old gpu was 
advertised to use only ~5.5W total while idle (but I wondered while it gets so 
hot, I thought this was due to it being installed so close to CPU0's huge 
heatsink). As I don't need that much GPU power anyways, the swap had at least a 
nice (unexpected) side-effect for me.

However, the fact that I still can use only two M.2 cards is somewhat 
disappointing. Since there are also other vendors of comparable PCIe quad-M.2 
cards, I welcome any reports (both positive and negative) from people who tried 
different m.2 quad card models in a KGPE-D16.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[Alberto Bursi]

On 02/06/2018 22:03, Daniel Kulesz via coreboot wrote:
> Hi folks,
>
> maybe this is not really coreboot-related, but I am experiencing an issue 
> with the KGPE-D16 that there seems to be no working constellation how the 
> following three cards can be put into service:
>
> - nvidia GPU (PCIe 3 x16, takes 1 slot but occupies two)
> - ASUS hypercard (PCIe 3 x16, takes 1 slot, has four M.2 slot with PCIe x4 
> each), see [1]
> - USB3 controller card (PCIe x4, takes 1 slot)
>
> No matter what I try, the hypercard is unable to detect more than two M.2 
> ssds. And only in the following config:
>
> 1 (MIO): empty
> 2: GPU
> 3: (GPU)
> 4: Hypercard
> 5: empty
>
> When I put the USB3 card in 5, only one of the M.2 ssds on the hypercard is 
> recognized. Therefore, I also tried swapping stuff in many combinations such 
> as the following:
>
> 1: empty
> 2: Hypercard
> 3: empty
> 4: USB3
> 5: GPU
>
> But no matter what I do, there seems to be now way to get all three cards 
> working simulaneously. Even with JUST the hypercard and nothing else it will 
> only detect two of the three M.2 cards inserted. :/
>
> Seems like the vendor bios has the same issue. My plan now is to get a GPU 
> that occupies only 1 slot and put the USB3 card next to it.
>
> Any help and clarifying explanations on this topic are warmly welcome.
>
> Cheers, Daniel
>
>
> [1] https://www.asus.com/Motherboard-Accessory/HYPER-M-2-X16-CARD/
>

It might need to be booted in UEFI mode to work, are you using tianocore 
payload (the UEFI payload) in your coreboot firmware on that board?

-Alberto
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[Jason Lenz]

Hi Daniel,

I also have a coreboot KGPE-D16 but am using different accessory cards.  I
took a look at the specs on your Hyper card and compared it to KGPE specs
and I think one or more of the following might be the issue:
* It looks like the Hyper card is a PCIE 3.0 device and the KGPE-D16 has
PCIE 2.0 slots.
* The Hyper card uses Intel VROC technology and I don't see that AMD cpus
have an equivalent/compatible technology.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[Daniel Kulesz via coreboot]

Hi folks,

maybe this is not really coreboot-related, but I am experiencing an issue with 
the KGPE-D16 that there seems to be no working constellation how the following 
three cards can be put into service:

- nvidia GPU (PCIe 3 x16, takes 1 slot but occupies two)
- ASUS hypercard (PCIe 3 x16, takes 1 slot, has four M.2 slot with PCIe x4 
each), see [1]
- USB3 controller card (PCIe x4, takes 1 slot)

No matter what I try, the hypercard is unable to detect more than two M.2 ssds. 
And only in the following config:

1 (MIO): empty
2: GPU
3: (GPU)
4: Hypercard
5: empty

When I put the USB3 card in 5, only one of the M.2 ssds on the hypercard is 
recognized. Therefore, I also tried swapping stuff in many combinations such as 
the following:

1: empty
2: Hypercard
3: empty
4: USB3
5: GPU

But no matter what I do, there seems to be now way to get all three cards 
working simulaneously. Even with JUST the hypercard and nothing else it will 
only detect two of the three M.2 cards inserted. :/

Seems like the vendor bios has the same issue. My plan now is to get a GPU that 
occupies only 1 slot and put the USB3 card next to it.

Any help and clarifying explanations on this topic are warmly welcome.

Cheers, Daniel


[1] https://www.asus.com/Motherboard-Accessory/HYPER-M-2-X16-CARD/

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Elisenda Cuadros]

Hi Kyösti,

I will try to boot again with 6276+6238 with the current build and I
will inform the result.

Regards,

- Eli



On 03/05/18 20:07, Kyösti Mälkki wrote:
> On Thu, May 3, 2018 at 8:57 PM, Elisenda Cuadros  wrote:
>> Finally I acquired another 6276 CPU (it was the fastest and cheapest
>> option).
>>
>> It works perfect.
>>
> Maybe not related, but KGPE-D16 was affected by a regression [1] on
> SMP init. That was present on master from Aug 2017 to Apr 2018.
>
> [1] https://review.coreboot.org/c/coreboot/+/25874
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Kyösti Mälkki]

On Thu, May 3, 2018 at 8:57 PM, Elisenda Cuadros  wrote:
> Finally I acquired another 6276 CPU (it was the fastest and cheapest
> option).
>
> It works perfect.
>

Maybe not related, but KGPE-D16 was affected by a regression [1] on
SMP init. That was present on master from Aug 2017 to Apr 2018.

[1] https://review.coreboot.org/c/coreboot/+/25874

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Elisenda Cuadros]

Finally I acquired another 6276 CPU (it was the fastest and cheapest
option).

It works perfect.

If I can try (in the future) another different 16-core CPU, I will
report the result.

Thank you for you kind support.

Regards,

- Eli

On 11/04/18 21:30, Timothy Pearson wrote:
> This may be a general coreboot limitation at the moment.  The
> compatibility sections for mixed CPUs in the BKDG are more concerned
> with total power delivery and proper P-state setup than anything else.
>
> If I recall correctly, coreboot assumes both CPUs have the same core
> count when setting up APICs and such.  There are a number of places that
> would need to be modified to remove this assumption; it's a leftover
> from the original K8 code and would take some significant work to fix.
> This also needs to be verified as I am going from memory here from a
> couple of years ago.
>
> On 04/11/2018 02:12 PM, Elisenda Cuadros wrote:
> > Thank you for your reply Timothy.
>
> > Vendor Bios doesn't print any special message regarding this.
>
> > In fact it shows a total of 28 cores (16+12).
>
> > I thought mixing CPUs from same families was supported.
>
> > Regards,
>
> > - Eli
>
> > On 11/04/18 20:44, Timothy Pearson wrote:
> >> I don't know if coreboot has support for differing CPUs in the same
> >> mainboard; it's not something I can recall testing at any point.
> >>
> >> The failure is occurring far before memory initialization, in CAR, in
> >> core setup.  I'd guess it has something to do with the two CPUs you
> have
> >> installed having different core counts.
> >>
> >> Does the vendor BIOS print a message about the core count being limited
> >> on one of the CPUs for compatibility reasons?
> >>
> >> On 04/11/2018 12:57 PM, Elisenda Cuadros wrote:
> >>> Hello,
> >>
> >>> After testing the board for some weeks I bought another CPU (6276). I
> >>> installed this into CPU1 slot and a 6238 in CPU2.
> >>
> >>> I checked that both CPUs are shining and also the memory (Micron
> >>> MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).
> >>
> >>> The problem is that Coreboot seems to hang at the beginning. I attach
> >>> console.log.
> >>
> >>> I reinstalled all the devices twice, checked the vendor manual,
> docs in
> >>> coreboot.org, messages in mailing list, but I don't know what is
> causing
> >>> the problem.
> >>
> >>> Last test I've done is booting with vendor bios, and it boots without
> >>> problem.
> >>
> >>> Any ideas?
> >>
> >>> Thank you for your help.
> >>
> >>> Regards,
> >>
> >>> - Eli
> >>
> >>
> >>
> >>
> >>
> >>
>
>
>
>
>



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

That should work, yes.  It's the very early init code that is getting
confused with the differing core counts, likely related to APIC setup or
similar.

On 04/11/2018 03:26 PM, taii...@gmx.com wrote:
> But it would be possible to have two CPU's with the same core count but
> differing frequencies?
> 
> Thanks
> 


- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaznCJAAoJEK+E3vEXDOFbfqsH+wegvs3Zu2ZNrM+W54LFXB7U
qVv4eAomKhPsf2UY5XzwhxVqzDn81PFI3HbMolfOwhNu/MfYeJIX7uxSdbMFReSH
3DF2808zOVaPQ5GdK3+dtNz7csM9pSTJUAIXPuDmRRYczrbDGEGYIP2OhMku+12x
b8X2iUVRDk0C9s/Rou+p9dEgJiH/xAf47X8L4BHzf8jna2IrY6WJgJiUvK2wxVx+
fahO6au24/yRsNfsdaG7Ax+1GXQF7imlcL7z1zM0JxQjt1OHExjClW/klaNEshjc
Wn+ebc77Blw6+klh7PdSkzs5nIQ3kCIoQuP9KvR0zbiWdmYKzj5NPk2awKAUTbg=
=P/vl
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[taii...@gmx.com]

But it would be possible to have two CPU's with the same core count but
differing frequencies?

Thanks


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This may be a general coreboot limitation at the moment.  The
compatibility sections for mixed CPUs in the BKDG are more concerned
with total power delivery and proper P-state setup than anything else.

If I recall correctly, coreboot assumes both CPUs have the same core
count when setting up APICs and such.  There are a number of places that
would need to be modified to remove this assumption; it's a leftover
from the original K8 code and would take some significant work to fix.
This also needs to be verified as I am going from memory here from a
couple of years ago.

On 04/11/2018 02:12 PM, Elisenda Cuadros wrote:
> Thank you for your reply Timothy.
> 
> Vendor Bios doesn't print any special message regarding this.
> 
> In fact it shows a total of 28 cores (16+12).
> 
> I thought mixing CPUs from same families was supported.
> 
> Regards,
> 
> - Eli
> 
> On 11/04/18 20:44, Timothy Pearson wrote:
>> I don't know if coreboot has support for differing CPUs in the same
>> mainboard; it's not something I can recall testing at any point.
>>
>> The failure is occurring far before memory initialization, in CAR, in
>> core setup.  I'd guess it has something to do with the two CPUs you have
>> installed having different core counts.
>>
>> Does the vendor BIOS print a message about the core count being limited
>> on one of the CPUs for compatibility reasons?
>>
>> On 04/11/2018 12:57 PM, Elisenda Cuadros wrote:
>>> Hello,
>>
>>> After testing the board for some weeks I bought another CPU (6276). I
>>> installed this into CPU1 slot and a 6238 in CPU2.
>>
>>> I checked that both CPUs are shining and also the memory (Micron
>>> MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).
>>
>>> The problem is that Coreboot seems to hang at the beginning. I attach
>>> console.log.
>>
>>> I reinstalled all the devices twice, checked the vendor manual, docs in
>>> coreboot.org, messages in mailing list, but I don't know what is causing
>>> the problem.
>>
>>> Last test I've done is booting with vendor bios, and it boots without
>>> problem.
>>
>>> Any ideas?
>>
>>> Thank you for your help.
>>
>>> Regards,
>>
>>> - Eli
>>
>>
>>
>>
>>
>>
> 
> 


- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJazmI3AAoJEK+E3vEXDOFbYtoH+wTs7rFYkkAq4niZcqSGEqaW
KMuhAUf3G5a86mcmpnhnJNCstFfDrc1+nWBMyF8xVmp6M/sV1mE869W2ppxHWbiD
iuK1jO16zNQGPOddDvLQuVNgn57qGC5D5HEstljNkfcOi2svQkbPF+Fzno46SF/2
skGkg3PPfi5kIYQNWPBWYUUI7gUEg5s5bnQ7lnqNxi4V8hBZaVS8zVjUzHn6RYEs
RpSLepk2iynwBcG5hGsKAPYvsE4WQZcWOz4talVnGVdv6m05KmPxh6MfIMvhnNji
ShGUDjPkLAsk80qDT5ZN4VBImEhcGG6Yg1297HiOI0cklRXhvufVKaG2vufb0XA=
=WGT+
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Elisenda Cuadros]

Thank you for your reply Timothy.

Vendor Bios doesn't print any special message regarding this.

In fact it shows a total of 28 cores (16+12).

I thought mixing CPUs from same families was supported.

Regards,

- Eli

On 11/04/18 20:44, Timothy Pearson wrote:
> I don't know if coreboot has support for differing CPUs in the same
> mainboard; it's not something I can recall testing at any point.
>
> The failure is occurring far before memory initialization, in CAR, in
> core setup.  I'd guess it has something to do with the two CPUs you have
> installed having different core counts.
>
> Does the vendor BIOS print a message about the core count being limited
> on one of the CPUs for compatibility reasons?
>
> On 04/11/2018 12:57 PM, Elisenda Cuadros wrote:
> > Hello,
>
> > After testing the board for some weeks I bought another CPU (6276). I
> > installed this into CPU1 slot and a 6238 in CPU2.
>
> > I checked that both CPUs are shining and also the memory (Micron
> > MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).
>
> > The problem is that Coreboot seems to hang at the beginning. I attach
> > console.log.
>
> > I reinstalled all the devices twice, checked the vendor manual, docs in
> > coreboot.org, messages in mailing list, but I don't know what is causing
> > the problem.
>
> > Last test I've done is booting with vendor bios, and it boots without
> > problem.
>
> > Any ideas?
>
> > Thank you for your help.
>
> > Regards,
>
> > - Eli
>
>
>
>
>
>



-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I don't know if coreboot has support for differing CPUs in the same
mainboard; it's not something I can recall testing at any point.

The failure is occurring far before memory initialization, in CAR, in
core setup.  I'd guess it has something to do with the two CPUs you have
installed having different core counts.

Does the vendor BIOS print a message about the core count being limited
on one of the CPUs for compatibility reasons?

On 04/11/2018 12:57 PM, Elisenda Cuadros wrote:
> Hello,
> 
> After testing the board for some weeks I bought another CPU (6276). I
> installed this into CPU1 slot and a 6238 in CPU2.
> 
> I checked that both CPUs are shining and also the memory (Micron
> MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).
> 
> The problem is that Coreboot seems to hang at the beginning. I attach
> console.log.
> 
> I reinstalled all the devices twice, checked the vendor manual, docs in
> coreboot.org, messages in mailing list, but I don't know what is causing
> the problem.
> 
> Last test I've done is booting with vendor bios, and it boots without
> problem.
> 
> Any ideas?
> 
> Thank you for your help.
> 
> Regards,
> 
> - Eli
> 
> 
> 
> 


- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJazleSAAoJEK+E3vEXDOFbrFcH/i6xBhUGli6lYBXFM4d29CW7
UH6Z1Ksr2bD5jNfoKd1bmLx61w0KdG6Fyt/AmFr4dNXmAxTzuudw1ZZxauZe21Sk
neJfuoMtctq/YQTaliMhPawO+6vARiVdNUYaMmDZO6cf4h9252WdpBU99JCJsbhC
BkcIApR+0resb6iO2XpbPelnMA4yjitpgonXqKbVI6OvdYz5b3NViytCKcHunyzc
7H/GzpS93K1hWs7kLdNCJ7J7M0BtUSh2pGu/uaqr1ZSXWZgwBeQGESMG7etpT1Ju
LP+e8C9dm0iLiTS8FIond8WUu4Q4bt7ebAqohrNQoMRpYlmyHWgEVSzecddqMJM=
=ke+3
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 / Problem booting with two CPUs

[Elisenda Cuadros]

Hello,

After testing the board for some weeks I bought another CPU (6276). I
installed this into CPU1 slot and a 6238 in CPU2.

I checked that both CPUs are shining and also the memory (Micron
MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).

The problem is that Coreboot seems to hang at the beginning. I attach
console.log.

I reinstalled all the devices twice, checked the vendor manual, docs in
coreboot.org, messages in mailing list, but I don't know what is causing
the problem.

Last test I've done is booting with vendor bios, and it boots without
problem.

Any ideas?

Thank you for your help.

Regards,

- Eli





coreboot-4.7-542-g39e1ab1d25-dirty Sun Mar 18 10:53:23 UTC 2018 romstage starting...
Initial stack pointer: 000dffb8
CPU APICID 00 start flag set
BSP Family_Model: 00600f12
*sysinfo range: [000c2d40,000cd2ac]
bsp_apicid = 00
cpu_init_detectedx = 
sb700 reset flags: 
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'microcode_amd.bin'
CBFS: Found @ offset 75400 size 318c
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'microcode_amd_fam15h.bin'
CBFS: Found @ offset 78600 size 1ec4
[microcode] patch id to apply = 0x0600063d
[microcode] updated to patch id = 0x0600063d success
cpuSetAMDMSR CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
 done
Enter amd_ht_init
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 2 new node: 1
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 0 new node: 2
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 3 new node: 3
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
Forcing HT links to isochronous mode due to enabled IOMMU
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
Exit amd_ht_init
amd_ht_fixup
amd_ht_fixup: node 0 (internal node ID 0): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 1 (internal node ID 1): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 2 (internal node ID 0): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 3 (internal node ID 1): disabling defective HT link (L3 connected: 1)
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
cpuSetAMDPCI 02 done
cpuSetAMDPCI 03 done
Prep FID/VID Node:00
  F3x80: e20be281
  F3x84: 01e200e2
  F3xD4: c3312f17
  F3xD8: 0316
  F3xDC: 05475632
Prep FID/VID Node:01
  F3x80: e20be281
  F3x84: 01e200e2
  F3xD4: c3312f17
  F3xD8: 0316
  F3xDC: 05475632
Prep FID/VID Node:02
  F3x80: e20be281
  F3x84: 01e200e2
  F3xD4: c3312f1a
  F3xD8: 0316
  F3xDC: 05475632
Prep FID/VID Node:03
  F3x80: e20be281
  F3x84: 01e200e2
  F3xD4: c3312f1a
  F3xD8: 0316
  F3xDC: 05475632
setup_remote_node: 01 done
Start node 01 done.
setup_remote_node: 02 done
Start node 02 done.
setup_remote_node: 03 done
Start node 03 done.
core0 started:  01 02

coreboot-4.7-542-g39e1ab1d25-dirty Sun Mar 18 10:53:23 UTC 2018 romstage starting...
Initial stack pointer: 000dffb8
CPU APICID 00 start flag set
BSP Family_Model: 00600f12
*sysinfo range: [000c2d40,000cd2ac]
bsp_apicid = 00
cpu_init_detectedx = 
sb700 reset flags: 
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'microcode_amd.bin'
CBFS: Found @ offset 75400 size 318c
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'microcode_amd_fam15h.bin'
CBFS: Found @ offset 78600 size 1ec4
[microcode] patch id to apply = 0x0600063d
[microcode] updated to patch id = 0x0600063d success
cpuSetAMDMSR CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
 done
Enter amd_ht_init
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 2 new node: 1
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 0 new node: 2
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 3 new node: 3
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
Forcing HT links to isochronous mode due to enabled IOMMU
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
Exit amd_ht_init
amd_ht_fixup
amd_ht_fixup: node 0 (internal node ID 0): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 1 (internal node ID 1): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 2 (internal node ID 0): 

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[taii...@gmx.com]

I am curious as to why the emulated combined IDE/SATA mode would be on 
in the first place if anyone knows, what is the use case for this?


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[taii...@gmx.com]

Hmm it works for me on Xen 4.10 (I don't normally use xen but I 
installed it to check for you)


(XEN) AMD-Vi: Disabled HAP memory map sharing with IOMMU
(XEN) AMD-Vi: IOMMU 0 Enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Strict
(XEN) Interrupt remapping enabled

Btw does anyone know what the difference is between strict and relaxed 
dom0 mode?


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[Thierry Laurion]

Thank you for the clarification. I'll try to figure this out later this
week.

Any help would be appreciated. I suppose I should file an issue. Will do.

Le ven. 3 nov. 2017 04:19, Patrick Georgi  a écrit :

> That's the bitfield item's size field, not its default value.
>
>
>
> Am Fr., 3. Nov. 2017 um 04:56 Uhr schrieb Thierry Laurion <
> thierry.laur...@gmail.com>:
>
>> As I understand the code, KGPE-d16 doesn't use AGESA part (nor any?).
>>
>> Any reason why this value would be defaulting to enabled for whole sb700
>> dependents?
>>
>> --- a/src/vendorcode/amd/cimx/sb700/SBTYPE.h
>> +++ b/src/vendorcode/amd/cimx/sb700/SBTYPE.h
>> @@ -133,7 +133,7 @@ typedef struct _AMDSBCFG
>>  UINT32  SataPortMultCap :1; //6, 0:OFF   1:ON
>>  UINT32  SataReserved:2; //8:7, Reserved
>>  UINT32  SataClkAutoOff  :1; //9,
>> AutoClockOff for IDE modes 0:Disabled, 1:Enabled
>> -UINT32  SataIdeCombinedMode :1; //10,
>> SataIDECombinedMode 0:Disabled, 1:Enabled
>> +UINT32  SataIdeCombinedMode :0; //10,
>> SataIDECombinedMode 0:Disabled, 1:Enabled
>>  UINT32  SataIdeCombMdPriSecOpt:1;   //11, Combined
>> Mode, SATA as primary or secondary 0:primary 1:secondary
>>  UINT32  SataReserved1   :6; //17:12, Not
>> used currently
>>  UINT32  SataEspPort :6; //23:18 SATA
>> port is external accessiable on a signal only connector (eSATA:)
>>
>>
>> Le jeu. 2 nov. 2017 à 09:33, Peter Stuge  a écrit :
>>
>>> Thierry Laurion wrote:
>>> > ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for
>>> ewhich
>>> > sp5100 is derived from:
>>> ..
>>> > Suggested Workaround
>>> > Disable combined mode by setting a platform BIOS callback option to
>>> CIMx
>>> > called "SataIdeCombinedMode" to 0.
>>> ..
>>> > Is there something i'm missing? Is it possible to disable combined
>>> > sata mode for sb700 from coreboot?
>>>
>>> SB700 mainboard support seems copypasted rather than engineered. The
>>> sustainable solution is to move sb700_cfg.c from src/mainboard/*/
>>> to src/southbridge/amd/cimx/sb700/ and hook the configuration in that
>>> file into Kconfig.
>>>
>>> Until someone does that, you could indeed change the assignment of
>>> that option by looking for
>>>
>>> SataIdeCombinedMode
>>>
>>> in the source code, if a sb700_cimx_config() function is called for
>>> this board - but that might not be the case if the board port chose
>>> not to use that part of AGESA.
>>>
>>>
>>> //Peter
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> 
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[Patrick Georgi via coreboot]

That's the bitfield item's size field, not its default value.


Am Fr., 3. Nov. 2017 um 04:56 Uhr schrieb Thierry Laurion <
thierry.laur...@gmail.com>:

> As I understand the code, KGPE-d16 doesn't use AGESA part (nor any?).
>
> Any reason why this value would be defaulting to enabled for whole sb700
> dependents?
>
> --- a/src/vendorcode/amd/cimx/sb700/SBTYPE.h
> +++ b/src/vendorcode/amd/cimx/sb700/SBTYPE.h
> @@ -133,7 +133,7 @@ typedef struct _AMDSBCFG
>  UINT32  SataPortMultCap :1; //6, 0:OFF   1:ON
>  UINT32  SataReserved:2; //8:7, Reserved
>  UINT32  SataClkAutoOff  :1; //9, AutoClockOff
> for IDE modes 0:Disabled, 1:Enabled
> -UINT32  SataIdeCombinedMode :1; //10,
> SataIDECombinedMode 0:Disabled, 1:Enabled
> +UINT32  SataIdeCombinedMode :0; //10,
> SataIDECombinedMode 0:Disabled, 1:Enabled
>  UINT32  SataIdeCombMdPriSecOpt:1;   //11, Combined
> Mode, SATA as primary or secondary 0:primary 1:secondary
>  UINT32  SataReserved1   :6; //17:12, Not used
> currently
>  UINT32  SataEspPort :6; //23:18 SATA port
> is external accessiable on a signal only connector (eSATA:)
>
>
> Le jeu. 2 nov. 2017 à 09:33, Peter Stuge  a écrit :
>
>> Thierry Laurion wrote:
>> > ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for
>> ewhich
>> > sp5100 is derived from:
>> ..
>> > Suggested Workaround
>> > Disable combined mode by setting a platform BIOS callback option to CIMx
>> > called "SataIdeCombinedMode" to 0.
>> ..
>> > Is there something i'm missing? Is it possible to disable combined
>> > sata mode for sb700 from coreboot?
>>
>> SB700 mainboard support seems copypasted rather than engineered. The
>> sustainable solution is to move sb700_cfg.c from src/mainboard/*/
>> to src/southbridge/amd/cimx/sb700/ and hook the configuration in that
>> file into Kconfig.
>>
>> Until someone does that, you could indeed change the assignment of
>> that option by looking for
>>
>> SataIdeCombinedMode
>>
>> in the source code, if a sb700_cimx_config() function is called for
>> this board - but that might not be the case if the board port chose
>> not to use that part of AGESA.
>>
>>
>> //Peter
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[Thierry Laurion]

As I understand the code, KGPE-d16 doesn't use AGESA part (nor any?).

Any reason why this value would be defaulting to enabled for whole sb700
dependents?

--- a/src/vendorcode/amd/cimx/sb700/SBTYPE.h
+++ b/src/vendorcode/amd/cimx/sb700/SBTYPE.h
@@ -133,7 +133,7 @@ typedef struct _AMDSBCFG
 UINT32  SataPortMultCap :1; //6, 0:OFF   1:ON
 UINT32  SataReserved:2; //8:7, Reserved
 UINT32  SataClkAutoOff  :1; //9, AutoClockOff
for IDE modes 0:Disabled, 1:Enabled
-UINT32  SataIdeCombinedMode :1; //10,
SataIDECombinedMode 0:Disabled, 1:Enabled
+UINT32  SataIdeCombinedMode :0; //10,
SataIDECombinedMode 0:Disabled, 1:Enabled
 UINT32  SataIdeCombMdPriSecOpt:1;   //11, Combined
Mode, SATA as primary or secondary 0:primary 1:secondary
 UINT32  SataReserved1   :6; //17:12, Not used
currently
 UINT32  SataEspPort :6; //23:18 SATA port
is external accessiable on a signal only connector (eSATA:)


Le jeu. 2 nov. 2017 à 09:33, Peter Stuge  a écrit :

> Thierry Laurion wrote:
> > ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for
> ewhich
> > sp5100 is derived from:
> ..
> > Suggested Workaround
> > Disable combined mode by setting a platform BIOS callback option to CIMx
> > called "SataIdeCombinedMode" to 0.
> ..
> > Is there something i'm missing? Is it possible to disable combined
> > sata mode for sb700 from coreboot?
>
> SB700 mainboard support seems copypasted rather than engineered. The
> sustainable solution is to move sb700_cfg.c from src/mainboard/*/
> to src/southbridge/amd/cimx/sb700/ and hook the configuration in that
> file into Kconfig.
>
> Until someone does that, you could indeed change the assignment of
> that option by looking for
>
> SataIdeCombinedMode
>
> in the source code, if a sb700_cimx_config() function is called for
> this board - but that might not be the case if the board port chose
> not to use that part of AGESA.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[Peter Stuge]

Thierry Laurion wrote:
> ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for ewhich
> sp5100 is derived from:
..
> Suggested Workaround
> Disable combined mode by setting a platform BIOS callback option to CIMx
> called "SataIdeCombinedMode" to 0.
..
> Is there something i'm missing? Is it possible to disable combined
> sata mode for sb700 from coreboot?

SB700 mainboard support seems copypasted rather than engineered. The
sustainable solution is to move sb700_cfg.c from src/mainboard/*/
to src/southbridge/amd/cimx/sb700/ and hook the configuration in that
file into Kconfig.

Until someone does that, you could indeed change the assignment of
that option by looking for

SataIdeCombinedMode

in the source code, if a sb700_cimx_config() function is called for
this board - but that might not be the case if the board port chose
not to use that part of AGESA.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[Thierry Laurion]

Xen error:
(XEN) AMD-Vi: SP5100 erratum 28 detected, disabling IOMMU.
(XEN) If possible, disable SATA Combined mode in BIOS or contact your vendor
for BIOS update.
(XEN) AMD-Vi: Error initialization
(XEN) I/O virtualisation disabled
-but HAP is working,
(XEN) HVM: SVM enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
Src:https://lists.gt.net/xen/users/371020


AMD's SP5100 chipset can be placed into SATA Combined mode
that may cause prevent dom0 from booting when IOMMU is
enabled and per-device interrupt remapping table is used.
While SP5100 erratum 28 requires BIOSes to disable this mode,
some may still use it.
src: https://lists.alpinelinux.org/alpine-devel/2724.html

ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for ewhich
sp5100 is derived from:
https://www.coreboot.org/Coreboot_Options


SP5100 Product Errata
46836 Rev. 3.00 June 2012 P.18
Product Errata 28
Incorrect IOMMU Table Accessed in SATA Combined Mode

Description
Systems with SP5100 SATA set to AHCI or IDE combined mode with SATA port 4
or 5 in use will use the SATA source ID for IDE DMA when consulting the
IOMMU tables.

Potential Effect on System
Operating systems where the IDE and SATA tables are separated will
experience I/O page faults.

Several warnings will be issued during kernel initialization, ultimately
leading to the inability to boot the operating system due to the boot disk
not being found.

Suggested Workaround
Disable combined mode by setting a platform BIOS callback option to CIMx
called "SataIdeCombinedMode" to 0.
This change will not have an impact on AHCI/RAID mode, however, in IDE
mode, the total number of available ports is reduced by two.

Fix Planned
No
src:https://support.amd.com/TechDocs/46836.pdf


Coreboot: Release 4.6
Xen: 4.8.x
Xen code responsible for detection:
https://github.com/xenserver/xen-4.3.pg/blob/master/tweak-iommu-errata-policy.patch

Is there something i'm missing? Is it possible to disable combined sata
mode for sb700 from coreboot?

Thanks,
Thierry
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [KGPE-D16] No video output with Ati x600se GPU

[aether]

Hello,

> No, afaik the VGA rom is only needed for native gfx init on (some) devices 
> with embedded graphics but not for add-on pci(e) cards.

Ok.

> It seems like you are not using SeaBIOS. Normally, Seabios initializes PCI 
> devices. 
> Are you sure you are using the same coreboot configuration that worked fine 
> for your GTX660 
> with this ATI card or did you rebuild/reflash coreboot inbetween?

It is the same rom I was using with the GTX660. No changes.
Seabios was starting fine, menu quickly appeared after coreboot init was done.

I don't have enough knowledge to interpret cbmem output but I was wondering 
if something was wrong before Seabios payload execution ? Is the Ati card 
detected ?
Only Aspeed VGA controller seems to be recognized.

Also, what is meaning of this :

"link_width=2, lane_mask=ffPcieLinkTraining port=c:lc current state=2030506" ?



Thank you,

aether





-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [KGPE-D16] No video output with Ati x600se GPU

[taii...@gmx.com]

On 10/15/2017 09:18 AM, Daniel Kulesz via coreboot wrote:


Hi,


I'm having issues to use an Ati x600se 128mb GPU (OEM DELL) with my KGPE-D16.
With ASUS BIOS, the card works fine (either in first or second pcie-x16 slot)
With coreboot, no video output. The board still boots but the card isn't 
detected at all. (either in first or second pcie-x16 slot)
I don't know what is the issue since I was using a GTX660 before without issue.

It seems like you are not using SeaBIOS. Normally, Seabios initializes PCI 
devices. Are you sure you are using the same coreboot configuration that worked 
fine for your GTX660 with this ATI card or did you rebuild/reflash coreboot 
inbetween?
If you don't use SeaBIOS you need to enable PCI-e Option ROM/VGA ROM 
execution.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [KGPE-D16] No video output with Ati x600se GPU

[Daniel Kulesz via coreboot]

Hi,

> I'm having issues to use an Ati x600se 128mb GPU (OEM DELL) with my KGPE-D16.
> With ASUS BIOS, the card works fine (either in first or second pcie-x16 slot)
> With coreboot, no video output. The board still boots but the card isn't 
> detected at all. (either in first or second pcie-x16 slot)
> I don't know what is the issue since I was using a GTX660 before without 
> issue.

It seems like you are not using SeaBIOS. Normally, Seabios initializes PCI 
devices. Are you sure you are using the same coreboot configuration that worked 
fine for your GTX660 with this ATI card or did you rebuild/reflash coreboot 
inbetween?

> Do I need to embed the VGA rom in cbfs for this card ?

No, afaik the VGA rom is only needed for native gfx init on (some) devices with 
embedded graphics but not for add-on pci(e) cards.


Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16/KCMA-D8 TPM support?

[taii...@gmx.com]

On 10/07/2017 11:14 AM, Thierry Laurion wrote:


Any input on TPM since that post? I am planning on beginning to work on
heads KGPE-D16 heads support, server/workstation on which Qubes v4 actually
works. Initialisation of TPM throws errors on from Qubes, but it isn't
owned yet, and haven't played with it yet.

I found this.
http://anzwix.com/a/Coreboot/Mbasuskgped16AddTPMSupport
So yeah it seems it works, with the appropriate module.

From the reviews on that it seems it doesn't work on older motherboards 
as it is a TPM 2.0 - I would ask asus as to which version the boards 
support.


Bought this .
Thierry
FYI there are a lot of independent small retailers that have better 
prices than amazon when it comes to this board family and accessories, 
next time you buy something input the model number in your favorite 
search engine. (ex: amazon has kcma-d8 for $280, other places have it 
for $250 - and you don't have to support AI research if you buy from them)


Also thanks for doing heads for this, it would be nice for it to support 
some actually libre boards - and it is good to promote these boards for 
qubes as well as they are truly great for it (lots of cores, ram and 
expansion slots)


Le mer. 23 août 2017 à 11:27, Peter Stuge  a écrit :


taii...@gmx.com wrote:

Does anyone know what TPM's are compatible?

Sorry, can't help with that.



I also want to know what coreboot's tpm support is like these days, such
as how can you perform an erase/reset like one could with a standard OEM
bios.

Is that in the realm of the BIOS? SeaBIOS does have some TPM support
upstream, and there have been one or two patchsets hanging around for
quite a while. They make a fairly complete impression - they may all
be upstream already..?


//Peter

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot






-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16/KCMA-D8 TPM support?

[Thierry Laurion]

Any input on TPM since that post? I am planning on beginning to work on
heads KGPE-D16 heads support, server/workstation on which Qubes v4 actually
works. Initialisation of TPM throws errors on from Qubes, but it isn't
owned yet, and haven't played with it yet.

Bought this .
Thierry

Le mer. 23 août 2017 à 11:27, Peter Stuge  a écrit :

> taii...@gmx.com wrote:
> > Does anyone know what TPM's are compatible?
>
> Sorry, can't help with that.
>
>
> > I also want to know what coreboot's tpm support is like these days, such
> > as how can you perform an erase/reset like one could with a standard OEM
> > bios.
>
> Is that in the realm of the BIOS? SeaBIOS does have some TPM support
> upstream, and there have been one or two patchsets hanging around for
> quite a while. They make a fairly complete impression - they may all
> be upstream already..?
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 PCI passthrough

[taii...@gmx.com]

On 09/12/2017 02:06 AM, Iru Cai wrote:


I seem to know what happened to me. Now I pass throught 00.12.{0,1,2} and
there's no problem now. But if I plug in my keyboard and mouse, then
because of the USB controller is passed to the VM, then I have no keyboard
or mouse to use, so the system seems to hang.
Yeah that's a software issue, I pass through the three bits of an in-use 
USB controller all the time and it works fine (with the keyboard and 
mouse attached)


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 PCI passthrough

[Iru Cai]

I seem to know what happened to me. Now I pass throught 00.12.{0,1,2} and
there's no problem now. But if I plug in my keyboard and mouse, then
because of the USB controller is passed to the VM, then I have no keyboard
or mouse to use, so the system seems to hang.

However, I still don't know why there exists some kernel oops in previous
tests.

On Fri, Sep 8, 2017 at 2:33 PM, taii...@gmx.com  wrote:

> On 09/08/2017 02:12 AM, Iru Cai wrote:
>
> On Fri, Sep 8, 2017 at 2:02 PM, taii...@gmx.com  wrote:
>>
>> On 09/08/2017 12:44 AM, Iru Cai wrote:
>>>
>>> On Fri, Sep 8, 2017 at 11:42 AM, taii...@gmx.com 
>>> wrote:
>>>
 On 09/07/2017 11:21 PM, Iru Cai wrote:

> Hi,
>
> I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI
>> to
>> USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed
>> video card and the LSI 1394a controller. I try to pass them all to a
>> VM,
>> but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10.
>>
>> Does anyone with KGPE-D16 have this problem?
>>
>> Iru
>>
>> You are attempting to pass the primary video device to a VM which
>> hardly
>>
> ever works, I tried the same thing and it didn't work (I wanted my PCI
> sound card in the VM, and as PCI doesn't support ACS and all the PCI
> devices on the D16 are behind the same bridge they are in the same
> IOMMU
> group so I had to do that - I ended up buying a USB sound adapter)
>
> Now I'm using GTX 650 as my primary video device and not using the on
>
 board
 ASpeed  video card.

 Also I tried to pass the onboard USB controller to the VM, and also
 crashed
 the kernel.

 Damn :[
>>> FYI you forgot to reply all - please re post this to the list :]
>>>
>>> Hmm can I have dmesg logs and your libvirt or w/e VM config files? for
>>> the
>>> new config you are trying.
>>> I am playing games right now with my pass thru usb ports.
>>>
>>> So are you using vfio-pci or pci-stub? I don't know if I can use pci-stub
>> in libvirt, but vfio-pci will require all devices
>> in an IOMMU group passed to a VM, and I don't use a modded kernel.
>>
> VFIO-PCI
> I pass thru my video card, an onboard nic and an onboard usb controller
> (all three usb subdevices) - works great and they're all in their own iommu
> group.
>



-- 
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 PCI passthrough

[taii...@gmx.com]

On 09/08/2017 02:12 AM, Iru Cai wrote:


On Fri, Sep 8, 2017 at 2:02 PM, taii...@gmx.com  wrote:


On 09/08/2017 12:44 AM, Iru Cai wrote:

On Fri, Sep 8, 2017 at 11:42 AM, taii...@gmx.com  wrote:

On 09/07/2017 11:21 PM, Iru Cai wrote:

Hi,


I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI
to
USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed
video card and the LSI 1394a controller. I try to pass them all to a VM,
but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10.

Does anyone with KGPE-D16 have this problem?

Iru

You are attempting to pass the primary video device to a VM which hardly

ever works, I tried the same thing and it didn't work (I wanted my PCI
sound card in the VM, and as PCI doesn't support ACS and all the PCI
devices on the D16 are behind the same bridge they are in the same IOMMU
group so I had to do that - I ended up buying a USB sound adapter)

Now I'm using GTX 650 as my primary video device and not using the on

board
ASpeed  video card.

Also I tried to pass the onboard USB controller to the VM, and also
crashed
the kernel.


Damn :[
FYI you forgot to reply all - please re post this to the list :]

Hmm can I have dmesg logs and your libvirt or w/e VM config files? for the
new config you are trying.
I am playing games right now with my pass thru usb ports.


So are you using vfio-pci or pci-stub? I don't know if I can use pci-stub
in libvirt, but vfio-pci will require all devices
in an IOMMU group passed to a VM, and I don't use a modded kernel.

VFIO-PCI
I pass thru my video card, an onboard nic and an onboard usb controller 
(all three usb subdevices) - works great and they're all in their own 
iommu group.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 PCI passthrough

[Iru Cai]

On Fri, Sep 8, 2017 at 2:02 PM, taii...@gmx.com  wrote:

> On 09/08/2017 12:44 AM, Iru Cai wrote:
>
> On Fri, Sep 8, 2017 at 11:42 AM, taii...@gmx.com  wrote:
>>
>> On 09/07/2017 11:21 PM, Iru Cai wrote:
>>>
>>> Hi,
>>>
 I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI
 to
 USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed
 video card and the LSI 1394a controller. I try to pass them all to a VM,
 but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10.

 Does anyone with KGPE-D16 have this problem?

 Iru

 You are attempting to pass the primary video device to a VM which hardly
>>> ever works, I tried the same thing and it didn't work (I wanted my PCI
>>> sound card in the VM, and as PCI doesn't support ACS and all the PCI
>>> devices on the D16 are behind the same bridge they are in the same IOMMU
>>> group so I had to do that - I ended up buying a USB sound adapter)
>>>
>>> Now I'm using GTX 650 as my primary video device and not using the on
>> board
>> ASpeed  video card.
>>
>> Also I tried to pass the onboard USB controller to the VM, and also
>> crashed
>> the kernel.
>>
> Damn :[
> FYI you forgot to reply all - please re post this to the list :]
>
> Hmm can I have dmesg logs and your libvirt or w/e VM config files? for the
> new config you are trying.
> I am playing games right now with my pass thru usb ports.
>

So are you using vfio-pci or pci-stub? I don't know if I can use pci-stub
in libvirt, but vfio-pci will require all devices
in an IOMMU group passed to a VM, and I don't use a modded kernel.


-- 
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 PCI passthrough

[taii...@gmx.com]

On 09/08/2017 12:44 AM, Iru Cai wrote:


On Fri, Sep 8, 2017 at 11:42 AM, taii...@gmx.com  wrote:


On 09/07/2017 11:21 PM, Iru Cai wrote:

Hi,

I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI to
USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed
video card and the LSI 1394a controller. I try to pass them all to a VM,
but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10.

Does anyone with KGPE-D16 have this problem?

Iru


You are attempting to pass the primary video device to a VM which hardly
ever works, I tried the same thing and it didn't work (I wanted my PCI
sound card in the VM, and as PCI doesn't support ACS and all the PCI
devices on the D16 are behind the same bridge they are in the same IOMMU
group so I had to do that - I ended up buying a USB sound adapter)


Now I'm using GTX 650 as my primary video device and not using the on board
ASpeed  video card.

Also I tried to pass the onboard USB controller to the VM, and also crashed
the kernel.

Damn :[
FYI you forgot to reply all - please re post this to the list :]

Hmm can I have dmesg logs and your libvirt or w/e VM config files? for 
the new config you are trying.

I am playing games right now with my pass thru usb ports.

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 PCI passthrough

[taii...@gmx.com]

On 09/07/2017 11:21 PM, Iru Cai wrote:


Hi,

I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI to
USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed
video card and the LSI 1394a controller. I try to pass them all to a VM,
but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10.

Does anyone with KGPE-D16 have this problem?

Iru
You are attempting to pass the primary video device to a VM which hardly 
ever works, I tried the same thing and it didn't work (I wanted my PCI 
sound card in the VM, and as PCI doesn't support ACS and all the PCI 
devices on the D16 are behind the same bridge they are in the same IOMMU 
group so I had to do that - I ended up buying a USB sound adapter)


I would advise buying PCI-e cards for your needs (they will all be in 
separate IOMMU groups - the boards SR56xx chipset is great for 
passthru), the Aspeed video isn't worth using anyways as it is terribly 
slow and only supports low resolutions.


I play games in a VM using one of the boards USB controllers (there are 
two, plus an extra one for the internal flash drive "Type A Female" usb 
port) you just have to get a USB header to attach to them and figure out 
which ports get assigned to what controller and as there are many 
headers you will have plenty of ports.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 PCI passthrough

[Iru Cai]

Hi,

I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI to
USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed
video card and the LSI 1394a controller. I try to pass them all to a VM,
but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10.

Does anyone with KGPE-D16 have this problem?

Iru

-- 
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890 Northbridge 
only dual slot (2x16) PCI-e GFX Hydra part (rev 02)
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O Memory 
Management Unit (IOMMU)
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 
PCI to PCI bridge (PCI Express GFX port 0)
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 
PCI to PCI bridge (PCI Express GPP Port 0)
00:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 
PCI to PCI bridge (PCI Express GPP Port 4)
00:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 
PCI to PCI bridge (PCI Express GPP Port 5)
00:0b.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD990 PCI to 
PCI bridge (PCI Express GFX2 port 0)
00:0c.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD990 PCI to 
PCI bridge (PCI Express GFX2 port 1)
00:0d.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 
PCI to PCI bridge (PCI Express GPP2 Port 0)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode]
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 
Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 
Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller 
(rev 3d)
00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 
IDE Controller
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia 
(Intel HDA)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 
LPC host controller
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI 
Bridge
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 5
00:19.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 0
00:19.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 1
00:19.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 2
00:19.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 3
00:19.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 4
00:19.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 5
00:1a.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 0
00:1a.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 1
00:1a.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 2
00:1a.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 3
00:1a.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 4
00:1a.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 5
00:1b.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 0
00:1b.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 1
00:1b.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 2
00:1b.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 3
00:1b.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 4
00:1b.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor 
Function 5
03:00.0 Ethernet controller: Intel Corporation 82574L 

Re: [coreboot] KGPE-D16 BMC port

[Rene Shuster]

Q Who has Self-hosting option?
A
https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities#Features

On Wed, Aug 30, 2017 at 1:18 AM, taii...@gmx.com  wrote:

> On 08/29/2017 02:24 PM, Timothy Pearson wrote:
>
>> Let me know what you think of the OpenBMC system.  We're considering
>> allowing bugs to be tracked on GitHub; is this something the community
>> wants to see or would a separate Bugzilla type install be preferred?  We
>> want to provide the infrastructure needed for the community to start
>> working with and enhancing this port, so suggestions and comments are
>> welcome!
>>
>> I don't like that nearly everything these days is on too-big-to-fail
> github so I always prefer a self hosted option.
> "Don't put all your eggs in one basket" was forgotten by the massive
> amounts of projects who think that git should = github - at least coreboot
> developers don't think that :D
>
> It is truly excellent to see the rare successful crowdfunding project
> bearing fruit, raptor is making history!
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 BMC port

[taii...@gmx.com]

On 08/29/2017 02:24 PM, Timothy Pearson wrote:

Let me know what you think of the OpenBMC system.  We're considering
allowing bugs to be tracked on GitHub; is this something the community
wants to see or would a separate Bugzilla type install be preferred?  We
want to provide the infrastructure needed for the community to start
working with and enhancing this port, so suggestions and comments are
welcome!

I don't like that nearly everything these days is on too-big-to-fail 
github so I always prefer a self hosted option.
"Don't put all your eggs in one basket" was forgotten by the massive 
amounts of projects who think that git should = github - at least 
coreboot developers don't think that :D


It is truly excellent to see the rare successful crowdfunding project 
bearing fruit, raptor is making history!


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 BMC port

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We are pleased to announce that the OpenBMC port for the KGPE-D16 has
reached the first release stage!

https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php

While it has inherited some of the rough edges of its Facebook
predecessor in terms of its external interfaces, this OpenBMC port is
fully functional for system control and thermal management.  We have
tested both ASMB4 and ASMB5 modules with the KGPE-D16 and both function
the same, so feel free to purchase whichever one is more readily
available in your location.

The weakest part of the port at this time is IPMI (provided by ipmid).
Only the chassis status command really works at this point, but all of
the "plumbing" is present that is required for both external
(network-based) and internal (LPC KCS-based) communication; the ipmitool
utility does have the ability to communicate with the BMC as of this
release.  You may need to modprobe ipmi_si and ipmi_devintf before
ipmitool will function, depending on your distribution's default settings.

One final note: if you enable OpenBMC, don't try to run fan-control
under Linux.  It will cause the hardware control chip on the shared I2C
bus to malfunction, and the BMC will detect this and shut the entire
system down to protect it from overtemperature.  No permanent harm will
be done, but data loss is possible.  The best thing to do is to make
sure the w83795 module is not loaded on the host.

Also, since I think this was buried in another Email thread, I'd like to
mention again that we are offering a 75% discount to the coreboot
community on the REACTS system [1] in an effort to get higher test
coverage.  Use this promotional code when checking out to apply the
discount: COREBOOTREACTS17

Let me know what you think of the OpenBMC system.  We're considering
allowing bugs to be tracked on GitHub; is this something the community
wants to see or would a separate Bugzilla type install be preferred?  We
want to provide the infrastructure needed for the community to start
working with and enhancing this port, so suggestions and comments are
welcome!

[1] https://www.raptorengineering.com/content/REACTS/intro.html

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJZpbFQAAoJEK+E3vEXDOFbWGsH/1WN4KMm1GCYUVdcj2wdD1XF
EkZ5H6Yu6p+8Fj+WkOaNsHb8xSFG5rqPPZC8ubT+tt4gcUqsgFzYLYDXACH6y4Yc
RFoSHd7rXYB9uBG1uzZIhQovfL65a6Y5+LTuhL9CYNXP7iR64L44NjgD1HFv8BS7
ryJ+K/LE941uOin8GQshoFwJ/i88uOMpKunF5Ef+SnGr4VhE5OvUrulpo5iJ/62J
Ia3v9zD9hTppGyi2MNydR7qy5kVrABHiq+6C2LiQtpfBx/GOwNevZbbvt+aswEnc
jEItl/I6YBTAMyT4eGdc5LW+0H83sw8mwynK1DTzZXGGTKw/xvkun5UcvrvU4Q8=
=dqp/
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16/KCMA-D8 TPM support?

[Peter Stuge]

taii...@gmx.com wrote:
> Does anyone know what TPM's are compatible?

Sorry, can't help with that.


> I also want to know what coreboot's tpm support is like these days, such 
> as how can you perform an erase/reset like one could with a standard OEM 
> bios.

Is that in the realm of the BIOS? SeaBIOS does have some TPM support
upstream, and there have been one or two patchsets hanging around for
quite a while. They make a fairly complete impression - they may all
be upstream already..?


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16/KCMA-D8 TPM support?

[taii...@gmx.com]

Does anyone know what TPM's are compatible?

I also want to know what coreboot's tpm support is like these days, such 
as how can you perform an erase/reset like one could with a standard OEM 
bios.


- Thanks in advance

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: More power drain experiments with coreboot vs. vendor bios

[Daniel Kulesz via coreboot]

Hi all,

I did some more testing with the Opteron CPUs, and it seems there is some 
defect in coreboot as it does not report the state P5. I attached the output of 
"cpupower frequency-info" which I obtained on a 1x6220/64G configuration 
running coreboot and running the vendor bios.

I also did some wattage measures using a new Brennenstuhl PM 231 watt meter for 
my whole system. It seems like coreboot still has some flaw in this regards, as 
I was able to reproduce the high power drain in idle with the 6220 processor as 
well.

With the vendor bios:

2x6276, 128G => 90W idle, ~350W load
1x6276, 64G => 66W idle, 165W load
1x6220, 64G => 70W idle, 157W

With coreboot:

1x6220, 64G => 101W idle, 165W load

One thing I noticed is that when running coreboot the power state P5 seems 
absent, while it's present when running the vendor bios. Could this be the 
cause for the high power drain in idle? (even if I am not sure if the system 
enters these states at all). Please see the logs attached.

If you compare the config of 1x6276 vs. 2x6276 it seems like there is just a 
difference of 24W in idle and I am sure the memory also draws some power. 
Therefore, I wonder how big the improvement could be by replacing the 
6200-series CPUs by one of the power-optimized "warsaw" modules (6338P or 
6370P). I could not find any figures about idle power consumption with these 
CPUs so I welcome any reports from others. I don't really need all that CPU 
power but I would really like to use all of my 128G memory - which is why I am 
looking for the most power efficient CPU for the KGPE-D16.

Cheers, Daniel
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 5.0 us
  hardware limits: 1.40 GHz - 3.00 GHz
  available frequency steps:  3.00 GHz, 2.60 GHz, 2.20 GHz, 1.80 GHz, 1.40 GHz
  available cpufreq governors: userspace powersave conservative ondemand 
performance schedutil
  current policy: frequency should be within 1.40 GHz and 3.00 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency: 1.40 GHz (asserted by call to hardware)
  boost state support:
Supported: yes
Active: yes
Boost States: 2
Total States: 7
Pstate-Pb0: 3600MHz (boost state)
Pstate-Pb1: 3300MHz (boost state)
Pstate-P0:  3000MHz
Pstate-P1:  2600MHz
Pstate-P2:  2200MHz
Pstate-P3:  1800MHz
Pstate-P4:  1400MHz

analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 5.0 us
  hardware limits: 1.40 GHz - 3.00 GHz
  available frequency steps:  3.00 GHz, 2.60 GHz, 2.20 GHz, 1.80 GHz, 1.40 GHz
  available cpufreq governors: userspace powersave conservative ondemand 
performance schedutil
  current policy: frequency should be within 1.40 GHz and 3.00 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency: 1.40 GHz (asserted by call to hardware)
  boost state support:
Supported: yes
Active: yes
Boost States: 2
Total States: 8
Pstate-Pb0: 3600MHz (boost state)
Pstate-Pb1: 3300MHz (boost state)
Pstate-P0:  3000MHz
Pstate-P1:  2600MHz
Pstate-P2:  2200MHz
Pstate-P3:  1800MHz
Pstate-P4:  1400MHz
Pstate-P5:  500MHz

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 - how to get PCI-e x16 on Slot 4?

[taii...@gmx.com]

According to the asus documentation it should be x16 if slot 2 is 
unoccupied, which it is.


I currently only have x8, I have tried changing the gpp config in 
devicetree.cb based on the SR5690 documentation but that results in a 
coreboot bootloop.


How many PCI-e slots can you use concurrently with PCI-e cards anyway? 
according to the manual it seems as though you can only do 4 although 
there are 5 physical slots.


- Thanks!

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Daniel Kulesz via coreboot]

On Thu, 13 Apr 2017 17:17:03 -0500
Timothy Pearson  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> > 
> > Unfortunately, I had the option already enabled when using the 
> > "config-unreliable" in my initial posting. So it looks like this setting is 
> > not effective in stopping the hangs.
> > 
> > Cheers, Daniel
> 
> After further external analysis once the KGPE-D16 was placed on our test
> stand for OpenBMC development, the intermittent hang resulting in hard
> system lockup (requiring a full standby power cycle) appears to be fixed
> in this patch series on Gerrit:
> 
> https://review.coreboot.org/#/c/19280/
> 
> Can you please test and confirm?
> 
> Thanks!
> 

Sure thing: I applied the patch on top of current coreboot-master and compiled 
the ROM using the "config-unreliable" from my initial posting.  Then I did a 
series of five warm reboots and watched the output on the serial console. 
Result: No more hangs! (Previously, it took like 20 attempts to get even one 
successful boot)

Great job, and many thanks!

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> 
> Unfortunately, I had the option already enabled when using the 
> "config-unreliable" in my initial posting. So it looks like this setting is 
> not effective in stopping the hangs.
> 
> Cheers, Daniel

After further external analysis once the KGPE-D16 was placed on our test
stand for OpenBMC development, the intermittent hang resulting in hard
system lockup (requiring a full standby power cycle) appears to be fixed
in this patch series on Gerrit:

https://review.coreboot.org/#/c/19280/

Can you please test and confirm?

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJY7/jdAAoJEK+E3vEXDOFbEBoH/0ph2gCcd66mFy/YfJ7zMDvJ
JetPGJKNbufoh8GUQkpwOpz7Pw36zrw+AZeH2fgbJkKl/LYV80smFj+dH5LYARZ9
qC1ojR9I9Ujg/xT1g4xzPedB/FIPL6CkJOdG7PIAXhDnMyLv2DV3TGIr8drwTRpT
yIPvZ+xWNzXIzevSxxrR5w7XENEmJDZDGZkAgjS1IUWG5cWMnn9sq14WeI8fFEVn
Q894DNz4gOW/cdKVgRxdR9kzSFZkqM0/Wv+FgwuDxo2RezGveAKtiajL9Y2Go0B/
QwYtfNOK7DBCwB2naxDw0S5X+BV1kQjir6wfCBe/wGWh1DurGBJ95MC0X9PFz+8=
=KA5F
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Daniel Kulesz via coreboot]

Hi Timothy,

On Tue, 21 Mar 2017 10:32:46 -0500
Timothy Pearson  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 03/12/2017 07:58 PM, Daniel Kulesz via coreboot wrote:
> > Hi folks,
> > 
> > as reported, the KGPE-D16 was mostly unusable for me in my 2x Opteron 6276 
> > + 128 GB RAM configuration as it simply did not boot reliably - even with 
> > serial console debugging disabled completely. After experimenting with 
> > various config options and comparing my best "known half-working" config 
> > from earlier attempts, I finally found out that the hangs were related to 
> > the configuration and not to a specific coreboot version.
> > 
> > I attached the configs showing my current "reliable" setup (that survived 
> > 10 cold and 10 warm reboots without a single hangup!) and one of the 
> > previous "unreliable" setups which often needed several cold boots to 
> > successfully boot up once. There are several options which might be 
> > reposible for these hangs. Personally, I believe what helps is to 
> > completely disable the serial console and not just disable debugging to 
> > serial console.
> > 
> > As asked for previously, I also took some boot time measures from pressing 
> > the power button to "grub beep" in my 128 GB RAM configuration. Here they 
> > are:
> > 
> > vendor bios, unoptimized with iPXE setup: 59s
> > coreboot, current with the "reliable" config: 73s
> > coreboot, Jan 17 2017, with the "reliable" config: 91s
> > coreboot, current with the "unreliable" config: 131s
> > 
> > I assume that further investigation of the root cause could help to locate 
> > the real bug (like e.g. the setup of the serial console). Yet, I hope that 
> > having a "working-good" config will be useful for people suffering from the 
> > same issue as I did. For me, this setup is still far from being what I 
> > expected (memory is clocked too low and idle power consumption is 170W 
> > instead of 90W), but at least the machine boots up reliably every time now.
> > 
> > Cheers, Daniel
> > 
> 
> Could you verify something for me?  In internal tests it looks like
> setting CONFIG_SQUELCH_EARLY_SMP resolves the hang with the serial
> console enabled, but I need secondary verification of this due to the
> intermittent nature of the problem.  You seem to be hardest hit by the
> bug so your system should make a good test case.
> 
> Thanks!
> 

Unfortunately, I had the option already enabled when using the 
"config-unreliable" in my initial posting. So it looks like this setting is not 
effective in stopping the hangs.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/12/2017 07:58 PM, Daniel Kulesz via coreboot wrote:
> Hi folks,
> 
> as reported, the KGPE-D16 was mostly unusable for me in my 2x Opteron 6276 + 
> 128 GB RAM configuration as it simply did not boot reliably - even with 
> serial console debugging disabled completely. After experimenting with 
> various config options and comparing my best "known half-working" config from 
> earlier attempts, I finally found out that the hangs were related to the 
> configuration and not to a specific coreboot version.
> 
> I attached the configs showing my current "reliable" setup (that survived 10 
> cold and 10 warm reboots without a single hangup!) and one of the previous 
> "unreliable" setups which often needed several cold boots to successfully 
> boot up once. There are several options which might be reposible for these 
> hangs. Personally, I believe what helps is to completely disable the serial 
> console and not just disable debugging to serial console.
> 
> As asked for previously, I also took some boot time measures from pressing 
> the power button to "grub beep" in my 128 GB RAM configuration. Here they are:
> 
> vendor bios, unoptimized with iPXE setup: 59s
> coreboot, current with the "reliable" config: 73s
> coreboot, Jan 17 2017, with the "reliable" config: 91s
> coreboot, current with the "unreliable" config: 131s
> 
> I assume that further investigation of the root cause could help to locate 
> the real bug (like e.g. the setup of the serial console). Yet, I hope that 
> having a "working-good" config will be useful for people suffering from the 
> same issue as I did. For me, this setup is still far from being what I 
> expected (memory is clocked too low and idle power consumption is 170W 
> instead of 90W), but at least the machine boots up reliably every time now.
> 
> Cheers, Daniel
> 

Could you verify something for me?  In internal tests it looks like
setting CONFIG_SQUELCH_EARLY_SMP resolves the hang with the serial
console enabled, but I need secondary verification of this due to the
intermittent nature of the problem.  You seem to be hardest hit by the
bug so your system should make a good test case.

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJY0UeaAAoJEK+E3vEXDOFb+jQH/3XyDMu1xeiXDxT2TA8/1Tl+
BSUk/gsplKL2LJBE54g/XdIl3jsP4oNAItvzJEUIY+dLzVZAXwgrRwK5TxPlXI3f
kFNYF5zfq8sJZkVsHthhlgda2OoSBzod4KTHgi8TcpdtvOun492zovDn8HfJpdl7
MGVjFr7s5Ap85hQ6x1gFD52mK5wJALStRmAIO+ViuTdp8xCMB2xa2h8umD3pEzSL
DV0tVBmw0oAnTJu1xogF1z5iXdREJz6TuvleUKOiE3jy/sQr/onMiML0PS+GTjIb
qeqRpSxL4pBNHDEbeB9Coe9V2uE7WJ9Zjt4aC0MvRrckeh/cl+tnwpr+MGSrYJ4=
=JEl+
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Daniel Kulesz via coreboot]

Hi folks,

as reported, the KGPE-D16 was mostly unusable for me in my 2x Opteron 6276 + 
128 GB RAM configuration as it simply did not boot reliably - even with serial 
console debugging disabled completely. After experimenting with various config 
options and comparing my best "known half-working" config from earlier 
attempts, I finally found out that the hangs were related to the configuration 
and not to a specific coreboot version.

I attached the configs showing my current "reliable" setup (that survived 10 
cold and 10 warm reboots without a single hangup!) and one of the previous 
"unreliable" setups which often needed several cold boots to successfully boot 
up once. There are several options which might be reposible for these hangs. 
Personally, I believe what helps is to completely disable the serial console 
and not just disable debugging to serial console.

As asked for previously, I also took some boot time measures from pressing the 
power button to "grub beep" in my 128 GB RAM configuration. Here they are:

vendor bios, unoptimized with iPXE setup: 59s
coreboot, current with the "reliable" config: 73s
coreboot, Jan 17 2017, with the "reliable" config: 91s
coreboot, current with the "unreliable" config: 131s

I assume that further investigation of the root cause could help to locate the 
real bug (like e.g. the setup of the serial console). Yet, I hope that having a 
"working-good" config will be useful for people suffering from the same issue 
as I did. For me, this setup is still far from being what I expected (memory is 
clocked too low and idle power consumption is 170W instead of 90W), but at 
least the machine boots up reliably every time now.

Cheers, Daniel


config-reliable
Description: Binary data


config-unreliable
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: More insights on the PCI hang failure

[Daniel Kulesz via coreboot]

Hi folks,

as we know, the KGPE-D16 is likely to hang during PCI init, especially if the 
serial console is enabled (Timothy mentioned that he did not observe failures 
with the debug level of the console lowered - however, for me this did not 
work). Typical symptoms look like the following:

ERROR: PNP: 002e.b 70 irq size: 0x01 not assigned

After discussing the issue with Timothy and doing a (huge) number of 
experiments in different settings I am of the opinion that the issue *does* 
seem to be memory/clock related. I tried various memory configurations and 
found some interesting correlations between memory configuration and the rate 
of failures. Also, I found another trigger which makes the hang *much* more 
likely.

For testing, I used the current coreboot master with the proposed revert which 
made the MC4 errors go away. After some experimenting, I found two settings 
which made the PCI-hangs go away:

1. Setting minimum memory voltage to 1.5V (probably unrelated)
2. Setting maximum memory clock down to 400 MHz (DDR3-800 instead of DDR3-1600)

With this setting, the number of PCI hangs went considerably down on a number 
of different configurations (all using two Opteron 6276 CPUs). The numbers are 
(#hangs / #boot attempts):

1xCK0 (in slot A2): warm (0/8), cold (0/3) => no failures!
1xYK0 (in slot A2): warm (0/6), cold (0/3) => no failures!
8xYK0 (in all orange slots): warm (1/8), cold (1/5) => rare
16xYK0 (in all slots): warm (3/8), cold (1/5) => more likely

Specs of the memory modules (all from Samsung):

CK0: 8GB DDR3-1600, 1.5V
YK0: 8GB DDR3L-1600, 1.35V

However, there is one more and quite severe issue: If I set the following 
option, I am get a hang in like 70% of the boot attempts:

Chipset => Enable PCI-E MMCONFIG Support

I wouldn't care too much about leaving this disabled. Unfortunately, I am 
getting a "force reboot" of the Kernel each time it tries to initialize the 
nouveau driver. Not sure if this is really related to this option or the fact 
that I'm running the RDIMMs at such low settings, but we'll have to find out.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi,

> > after a lengthy bisection run I was able to nail down the commit which is 
> > causing the MC4 errors in the configurations I tested. I reverted the 
> > commit on top of current master, and now my KGPE-D16 fully works without 
> > MC4 errors in both 1-CPU-package und 2-CPU-package configurations - that 
> > is, with all 16 memory slots populated with the 8GB DDR3L Samsung RDIMMs 
> > (PC12800 variant) mentioned in my initial post.
> 
> Thank you for working on that bisect, and for isolating the exact commit
> causing the problem!
> 
> However, we are going to need additional input from other owners of the
> KGPE-D16 to verify that a simple revert does not break support for the
> DIMMs installed in their machines.  In particular, I am interested in
> test reports from those with Kingston RDIMMs since they seemed to be
> among the most finicky.
> 

I have some more DIMMs I could test with if this would help:

- 2x Samsung 2GB 8500R
- 6x Crucial Ballistix Sport (non-RDIMMs, 4 of them have issues in another 
vendor bios running at the clock specified in the SPD)

> > However, the issue with memory clock (being reported at) 667MHz in 
> > dmidecode still remains.
> 
> Can you please send over a debug log at SPEW level showing the romstage
> boot process for 4 DIMMs?  The only log I have right now is for 8.
> 

Yep, will do so!

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/15/2017 08:07 AM, Daniel Kulesz via coreboot wrote:
> Hi folks,
> 
> after a lengthy bisection run I was able to nail down the commit which is 
> causing the MC4 errors in the configurations I tested. I reverted the commit 
> on top of current master, and now my KGPE-D16 fully works without MC4 errors 
> in both 1-CPU-package und 2-CPU-package configurations - that is, with all 16 
> memory slots populated with the 8GB DDR3L Samsung RDIMMs (PC12800 variant) 
> mentioned in my initial post.

Thank you for working on that bisect, and for isolating the exact commit
causing the problem!

However, we are going to need additional input from other owners of the
KGPE-D16 to verify that a simple revert does not break support for the
DIMMs installed in their machines.  In particular, I am interested in
test reports from those with Kingston RDIMMs since they seemed to be
among the most finicky.

> However, the issue with memory clock (being reported at) 667MHz in dmidecode 
> still remains.

Can you please send over a debug log at SPEW level showing the romstage
boot process for 4 DIMMs?  The only log I have right now is for 8.

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYpIBjAAoJEK+E3vEXDOFbCkcH/Rq4i+UD+Ow13LKPczZmwUAL
YXSPkCx4dJBRxBxB0BV9ikzsRpLC91hkxqg6T4RN+Bgla8hQF+Gj17PV9D/S9Kif
+O0b7F8NVcx1hY1RPSWztm7fcWCz40yrla0JCSSVNkkWEGQVrCx9KgxIcsS2YmIC
iKGuTxDUSN63WSBNqMxpYcwH88iJZQiPM3/cOp2EZ6dLCWgeGEhWyDlkbvwK+VFr
cyuibAU2zgCLU2wlQ/30uCnoFCbdNCQ4m+YfVCeeU0DlJDO18OOsC5azogG0MASr
7PnUIqqsmKa8TciJPPTsXi/LZmlsZry9Db2GXOvKRb72NXviIKhbxZ0UBZRtnxc=
=YsB1
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi folks,

after a lengthy bisection run I was able to nail down the commit which is 
causing the MC4 errors in the configurations I tested. I reverted the commit on 
top of current master, and now my KGPE-D16 fully works without MC4 errors in 
both 1-CPU-package und 2-CPU-package configurations - that is, with all 16 
memory slots populated with the 8GB DDR3L Samsung RDIMMs (PC12800 variant) 
mentioned in my initial post.

However, the issue with memory clock (being reported at) 667MHz in dmidecode 
still remains.

I submitted a request for reverting the causing commit [1].

Cheers, Daniel

[1] https://review.coreboot.org/#/c/18369/

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi folks,

here's a short update regarding the beforementioned DDR3L Samsung memory sticks 
on the KGPE-D16 running coreboot.

Thanks to help and hints from Timothy, I experimented with different cpu/memory 
configurations and have done some stress and memory testing. So far, I have a 
few interesting findings to report for a 1-CPU-package configuration (using 
Opteron 6276):

(1) When running coreboot master with 4 DIMMs (in orange slots), the DIMMs are 
reported in dmidecode to be running at 800MHz and no ECC errors show up in 
dmesg during memtester runs. Same goes for the vendor bios.
(2) When running coreboot master with 8 DIMMs, the DIMMs are reported in 
demidecode to be running at 667 MHz and MC4 errors show up in dmesg during 
memtester runs.
(3) When running the same as in (2) but with the *vendor BIOS*, dmidecode 
reports 800MHz and memtester runs without MC4 errors.
(4) When running the same as in (2) but with *Coreboot 4.3*, dmidecode reports 
667MHz but memtester runs *without* MC4 errors as well.

It is still on my list to validate (using benchmarks) whether dmidecode just 
reports non-sense or if the DIMMs really run at only 667MHz. However, the issue 
with the MC4 errors is much more severe and likely to be a regression between 
Coreboot 4.3 and the current master version. It will require further bisecting 
to identify the cause.

@Other KGPE-D16 users: Does dmidecode in coreboot report your memory sticks to 
be running at 800MHz (provided you have PC12800 ones)? And are seeing MC4 
failures when running memtester? (For me, it happens at stage 2 with the 
"random testing" - usually after less than 7 minutes after starting the test 
and even if I just use 10G of memory for testing).

I also tested using two cpu packages and other memory populations, but as 
Timothy has obligations regarding the proper dimension of my PSU, it makes more 
sense for me to test in 1-CPU-configuration first to find the cause of these 
MC4 errors in coreboot before proceeding further.

Cheers, Daniel



Btw.: I had some "false negative" kernel oopses when running stress-ng with all 
tests enabled on both vendor bios and coreboot. Seems to be a known software 
issue (Ubuntu bug 1654073).

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Paul Menzel via coreboot]

Dear Daniel,


Thank you for keeping us in the loop.


Am Samstag, den 11.02.2017, 16:14 +0100 schrieb Daniel Kulesz:
> To answer my question myself: It works partially.
> 
> > 1.) Samsung M393B1K70DH0-YK0
> > 
> > Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/Banks: dual rank, x4 • Modules: 1x 
> > 8GB • JEDEC: PC3L-12800R • Voltage: 1.35V
> 
> I got 8 of these working with one CPU package on the KGPE-D16 with
> one of the latest Coreboot master versions:

(Please note, that coreboot is officially spelled all lowercase.)

How much did you pay for these modules?

Just to be sure. You got 64 GB of RAM working. If you plug in more
modules, it fails, right?

> Version: 4.5-963-gf57a768

Please upload your logs to the board status repository. (This commit
has not been uploaded by REACTS, so it wouldn’t overwrite anything.)

> However, the experience was not very good because I did not fit all
> of them at once and started with testing "partical" configurations
> with just two or four modules inserted. In these cases, raminit
> succeeded but when detecting the PCI devices the system hang up -
> especially when placing 4 modules in the orange slots. Also, with
> coreboot-4.5, I only managed to get four modules working when placing
> them in the slots most far away from CPU0 (two orange, two black).
> 
> Apart from that, the configured clock speed seems too low to me (the
> vendor bios runs the modules at 800 MHz instead of 667 MHz):
> 
> Handle 0x0007, DMI type 17, 40 bytes
> Memory Device
> Array Handle: 0x0006
> Error Information Handle: Not Provided
> Total Width: 72 bits
> Data Width: 64 bits
> Size: 8192 MB
> Form Factor: DIMM
> Set: None
> Locator: NODE 0 DIMM_A1
> Bank Locator: Not Specified
> Type: DDR3
> Type Detail: Synchronous Registered (Buffered)
> Speed: 667 MHz
> Manufacturer: Samsung
> Serial Number: xxx
> Asset Tag: Not Specified
> Part Number: M393B1K70DH0-YK0  
> Rank: 2
> Configured Clock Speed: 667 MHz
> Minimum Voltage: 1.35 V
> Maximum Voltage: 1.5 V
> Configured Voltage: 1.35 V

Without the logs, it’s hard to debug anything. Verbose logs are one of
the biggest advantages of coreboot. So please upload them, or attach
them.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Excessive power consumption in idle

[Daniel Kulesz via coreboot]

On Fri, 10 Feb 2017 00:37:57 -0500
"taii...@gmx.com"  wrote:

> On 02/09/2017 06:46 PM, Daniel Kulesz via coreboot wrote:
> 
> > Hi,
> >
> > I just compiled and flashed the lastest master on my KGPE-D16 with pretty 
> > much the default config. My board has only one of the CPU sockets populated 
> > with an Opteron 6276. Things seem to work fine so far, except the power 
> > consumption. The "sensors" command reports a CPU power consumption of about 
> > ~85W (!) in idle:
> >
> > ---
> > k10temp-pci-00cb
> > Adapter: PCI adapter
> > temp1:+21.2°C  (high = +70.0°C)
> >
> > fam15h_power-pci-00c4
> > Adapter: PCI adapter
> > power1:   85.13 W  (crit = 115.11 W)
> >
> > nouveau-pci-0500
> > Adapter: PCI adapter
> > GPU core: +1.01 V  (min =  +0.60 V, max =  +1.20 V)
> > fan1:   0 RPM
> > temp1:+37.0°C  (high = +95.0°C, hyst =  +3.0°C)
> > (crit = +105.0°C, hyst =  +5.0°C)
> > (emerg = +135.0°C, hyst =  +5.0°C)
> >
> > k10temp-pci-00c3
> > Adapter: PCI adapter
> > temp1:+24.1°C  (high = +70.0°C)
> > ---
> >
> > With the vendor bios, the power consumption reported by "sensors" was just 
> > about the half - around 43W. I measured the consumption also on the power 
> > socket, and the whole systems seems to draw around 91W in idle (which is 
> > strange, since the GPU + hard drives + fans certainly don't take only 6W, 
> > but yeah...). Anyways, with the vendor bios, the power consumption of the 
> > whole system was around 60W (tested with a different power supply, but as a 
> > rough measure I guess this is representative).
> >
> > In coreboot's menuconfig, I can't select any power saving options or such 
> > as it was possible for other boards, which leaves me a bit puzzled.
> >
> > Anyone having simular issues?
> >
> > Cheers, Daniel
> >
> I am not.

Thanks. May I ask which CPU you are using?

> What does "cpufrequency monitor" report?

Here's the output of "cpufreq-info":

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpuf...@vger.kernel.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 5.0 us.
  hardware limits: 1.40 GHz - 2.30 GHz
  available frequency steps: 2.30 GHz, 2.10 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, 
performance, schedutil
  current policy: frequency should be within 1.40 GHz and 2.30 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.40 GHz.
  cpufreq stats: 2.30 GHz:0.80%, 2.10 GHz:0.46%, 1.80 GHz:0.70%, 1.60 
GHz:1.68%, 1.40 GHz:96.37%  (736)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 5.0 us.
  hardware limits: 1.40 GHz - 2.30 GHz
  available frequency steps: 2.30 GHz, 2.10 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, 
performance, schedutil
  current policy: frequency should be within 1.40 GHz and 2.30 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.40 GHz.
  cpufreq stats: 2.30 GHz:0.54%, 2.10 GHz:0.08%, 1.80 GHz:0.29%, 1.60 
GHz:3.19%, 1.40 GHz:95.91%  (223)
analyzing CPU 2:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 5.0 us.
  hardware limits: 1.40 GHz - 2.30 GHz
  available frequency steps: 2.30 GHz, 2.10 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, 
performance, schedutil
  current policy: frequency should be within 1.40 GHz and 2.30 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.40 GHz.
  cpufreq stats: 2.30 GHz:0.45%, 2.10 GHz:0.18%, 1.80 GHz:1.01%, 1.60 
GHz:2.10%, 1.40 GHz:96.25%  (445)
analyzing CPU 3:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 5.0 us.
  hardware limits: 1.40 GHz - 2.30 GHz
  available frequency steps: 2.30 GHz, 2.10 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, 
performance, schedutil
  current policy: frequency should be within 1.40 GHz and 2.30 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.40 GHz.
  cpufreq stats: 2.30 GHz:1.95%, 

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

To answer my question myself: It works partially.

> 1.) Samsung M393B1K70DH0-YK0
> 
> Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/​Banks: dual rank, x4 • Modules: 1x 
> 8GB • JEDEC: PC3L-12800R • Voltage: 1.35V
> 

I got 8 of these working with one CPU package on the KGPE-D16 with one of the 
latest Coreboot master versions:

Version: 4.5-963-gf57a768

However, the experience was not very good because I did not fit all of them at 
once and started with testing "partical" configurations with just two or four 
modules inserted. In these cases, raminit succeeded but when detecting the PCI 
devices the system hang up - especially when placing 4 modules in the orange 
slots. Also, with coreboot-4.5, I only managed to get four modules working when 
placing them in the slots most far away from CPU0 (two orange, two black).

Apart from that, the configured clock speed seems too low to me (the vendor 
bios runs the modules at 800 MHz instead of 667 MHz):

Handle 0x0007, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0006
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: NODE 0 DIMM_A1
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous Registered (Buffered)
Speed: 667 MHz
Manufacturer: Samsung
Serial Number: xxx
Asset Tag: Not Specified
Part Number: M393B1K70DH0-YK0  
Rank: 2
Configured Clock Speed: 667 MHz
Minimum Voltage: 1.35 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.35 V

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Excessive power consumption in idle

[taii...@gmx.com]

On 02/09/2017 06:46 PM, Daniel Kulesz via coreboot wrote:


Hi,

I just compiled and flashed the lastest master on my KGPE-D16 with pretty much the 
default config. My board has only one of the CPU sockets populated with an Opteron 6276. 
Things seem to work fine so far, except the power consumption. The "sensors" 
command reports a CPU power consumption of about ~85W (!) in idle:

---
k10temp-pci-00cb
Adapter: PCI adapter
temp1:+21.2°C  (high = +70.0°C)

fam15h_power-pci-00c4
Adapter: PCI adapter
power1:   85.13 W  (crit = 115.11 W)

nouveau-pci-0500
Adapter: PCI adapter
GPU core: +1.01 V  (min =  +0.60 V, max =  +1.20 V)
fan1:   0 RPM
temp1:+37.0°C  (high = +95.0°C, hyst =  +3.0°C)
(crit = +105.0°C, hyst =  +5.0°C)
(emerg = +135.0°C, hyst =  +5.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
temp1:+24.1°C  (high = +70.0°C)
---

With the vendor bios, the power consumption reported by "sensors" was just 
about the half - around 43W. I measured the consumption also on the power socket, and the 
whole systems seems to draw around 91W in idle (which is strange, since the GPU + hard 
drives + fans certainly don't take only 6W, but yeah...). Anyways, with the vendor bios, 
the power consumption of the whole system was around 60W (tested with a different power 
supply, but as a rough measure I guess this is representative).

In coreboot's menuconfig, I can't select any power saving options or such as it 
was possible for other boards, which leaves me a bit puzzled.

Anyone having simular issues?

Cheers, Daniel


I am not.
What does "cpufrequency monitor" report?

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: Excessive power consumption in idle

[Daniel Kulesz via coreboot]

Hi,

I just compiled and flashed the lastest master on my KGPE-D16 with pretty much 
the default config. My board has only one of the CPU sockets populated with an 
Opteron 6276. Things seem to work fine so far, except the power consumption. 
The "sensors" command reports a CPU power consumption of about ~85W (!) in idle:

---
k10temp-pci-00cb
Adapter: PCI adapter
temp1:+21.2°C  (high = +70.0°C)

fam15h_power-pci-00c4
Adapter: PCI adapter
power1:   85.13 W  (crit = 115.11 W)

nouveau-pci-0500
Adapter: PCI adapter
GPU core: +1.01 V  (min =  +0.60 V, max =  +1.20 V)
fan1:   0 RPM
temp1:+37.0°C  (high = +95.0°C, hyst =  +3.0°C)
   (crit = +105.0°C, hyst =  +5.0°C)
   (emerg = +135.0°C, hyst =  +5.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
temp1:+24.1°C  (high = +70.0°C)
---

With the vendor bios, the power consumption reported by "sensors" was just 
about the half - around 43W. I measured the consumption also on the power 
socket, and the whole systems seems to draw around 91W in idle (which is 
strange, since the GPU + hard drives + fans certainly don't take only 6W, but 
yeah...). Anyways, with the vendor bios, the power consumption of the whole 
system was around 60W (tested with a different power supply, but as a rough 
measure I guess this is representative).

In coreboot's menuconfig, I can't select any power saving options or such as it 
was possible for other boards, which leaves me a bit puzzled.

Anyone having simular issues?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi folks,

I spent some time checking the available RAM options for the KGPE-D16. The 
current list in the wiki is not very comprehensive and the models listed there 
are not easy to find on the market. After some research, I identified two 
"promising" candidates:

1.) Samsung M393B1K70DH0-YK0

Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/​Banks: dual rank, x4 • Modules: 1x 
8GB • JEDEC: PC3L-12800R • Voltage: 1.35V

2.) Samsung M393B1K70DH0-YH9

Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/​Banks: dual rank • Modules: 1x 8GB • 
JEDEC: PC3L-10667R • Voltage: 1.35V

Does one of you have experience with any of these (especially on this board)?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 with over 128GB RAM - works reliably yet?

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2017 09:38 AM, Peter Stuge wrote:
> Timothy Pearson wrote:
>> Populating all four slots closest to CPU1 with large ECC registered
>> DIMMs is a surefire way to recreate the instability -- note a
>> training failure is not common, the main issue is that the marginal
>> routing causes severe memory corruption when the BKDG-recommended
>> algorithms are used.
> 
> What does the vendor BIOS do?

Unknown.  I would imagine there is a hack in the vendor BIOS to work
around this board-specific issue, but that doesn't help coreboot very
much.  We had looked into it before, but decided it was not worth the
cost to research and implement a fix.

For what it's worth, there are several threads online about the KGPE-D16
and memory corruption with the vendor BIOS.  It seems to have taken ASUS
some time to iterate and work around the problem.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYjj6vAAoJEK+E3vEXDOFbbH8H/RarB/ky7zMKzZrWnYJgsieD
bEA7RXdCQyBU8w44QOswMbdaM61e4V4luwklJlCUSMgsCfuABHNgoR9v1C1u9E1b
Q5AKj0FJzUgET1Eb+dBfN7VAVG1ezhJkPHXqRJI9MPkKsmwlAXrYynaZqS6x8AZE
q4a0VYqWyckDTECti+kjgGwN5EyPEy+Mg+9ic1tSn8ItjIlV8ztpvmTUy2d56B+R
wr4RKDM8WBWOMQm2itPVKAoeM7KA3ewJ2ZkpLG1cGmUMOjIMPyjlEKPKchBbpmvk
zoPBhyJSDbbcMoAWp4h2813pVWWDxCufmcGlINZSwztmKkhXWgRDDnRlH7J6PRs=
=EcKb
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 with over 128GB RAM - works reliably yet?

[Peter Stuge]

Timothy Pearson wrote:
> Populating all four slots closest to CPU1 with large ECC registered
> DIMMs is a surefire way to recreate the instability -- note a
> training failure is not common, the main issue is that the marginal
> routing causes severe memory corruption when the BKDG-recommended
> algorithms are used.

What does the vendor BIOS do?


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 with over 128GB RAM - works reliably yet?

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/27/2017 03:27 PM, taii...@gmx.com wrote:
> Is anyone using this configuration? does it work reliably? I am asking
> as I don't know if this has been fixed yet.
> 
> For a real server platform this is a must have, the ram issues are the
> one valid point that leah made...
> 
> - Thanks in advance for any replies
> 

We use such a machine here in production, with the caveat that an older
coreboot revision is used.  That being said, keep the four slots closest
to CPU1 unpopulated (i.e. fill all 8 slots on CPU0, and the 4 farthest
from CPU1) and you should have no problems reaching 192GB.  Those
particular slots appear to have physical routing layer issues caused by
marginal design, and thus far we have had no reason to even attempt a
workaround given the high cost involved.

As always, if someone else would like to try to work around the
corruption issues, they are more than welcome.  Populating all four
slots closest to CPU1 with large ECC registered DIMMs is a surefire way
to recreate the instability -- note a training failure is not common,
the main issue is that the marginal routing causes severe memory
corruption when the BKDG-recommended algorithms are used.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYi7zeAAoJEK+E3vEXDOFbmOEH/itJEw/sz6Dq4LFSXQqMEKPS
cAY7/YoP8hEfsHBjP+buyKyRyj7Q9988dhrgd4db/cU4QWD5XACYTUTZJMKcnpav
/MwAWpjxOD9IPginTRCUKwvDhhdnt8IQIe2cNV4ujj57nvkOpgPhrM8eR//11HP+
qtqc7EXUR9RmxIP/cn2GJ7MWZ8+DqJbdmdeTqdF9xo6YkQ2RceYyFbofEoONBN9R
nQgz6wysrgH/jZkhTcwR23TZCcJcx6DV7gEuwHj5K/9iqXWqX+gAr8bMB8rii9HA
zqCYWp1Ihm+hHBfGvxZ4niy5yQyU2Dq+80CjtkN8qiG0c7ThHlk84ZRo5sQDgjM=
=L5ST
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 with over 128GB RAM - works reliably yet?

[taii...@gmx.com]

Is anyone using this configuration? does it work reliably? I am asking 
as I don't know if this has been fixed yet.


For a real server platform this is a must have, the ram issues are the 
one valid point that leah made...


- Thanks in advance for any replies

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 BMC Port Offer (was: Fund a TALOS Secure Workstation as coreboot build system)

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/19/2017 11:36 AM, Martin Roth wrote:
> Hey Merlin,
>   I was taking and keeping track of the pledges for Talos, so I'd be
> happy to continue.
> 
> Martin

I just wanted to bring this back up for discussion.  Raptor is chipping
in funding for over half of the development work, and Martin is matching
pledges, so if there's interest in this port your contributions will go
a long way, but it still depends on community interest.  Are you willing
to contribute to this development project?  It is a limited time offer,
so the quicker we can reach the relatively low goal to get this work
underway the better. :-)

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYijUnAAoJEK+E3vEXDOFbQKAIAKPqeHZylATs3aZXC2QeTmUG
p0bnwfU4G+0qkXEwApoYk+y8WRKEkhBsug5EvzEXw65fAAmwi4COVjUBvm2l9kUI
m3/51sfrZRpo+H8c1lXld0WiwomTGapm9FX3rqAjLZn354TOqnrfoGYoJQC+ovKm
0AYXCGN8fmWkr6nTj9Q1tWwxEXrRv48YudF8bDFZhbMjOswnagNzImQNTC6wLgnY
+7UyqBgpihc8vh3GoGuPQT1mNpAtUwv1PS8HFGnDO86zW9gWB7+xHEGBhMyy+Rys
CTNWkI15X4dy8pz6XIsqjuBNSUcgTnVVAelecdm1BfykpgSyPyOf/39JQc/O41M=
=HzeR
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 SR-IOV problems (iommu groups) - Anyone else tried this?

[taii...@gmx.com]

On 01/23/2017 09:23 AM, Timothy Pearson wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/21/2017 02:57 AM, taii...@gmx.com wrote:

It seems the PCI-e root ports on the KGPE-D16 have ARI which is needed
for SR-IOV, however it is not reported via # lspci -vv
I assume that is why the VF's are not assigned to IOMMU groups and thus
can't be assigned.

I am running coreboot v4.5 (I forgot to note this as it is another late
night)

Tim was the ARI feature implemented when you guys did the programming?
https://support.amd.com/TechDocs/44549.pdf

We did not explicitly enable nor verify the ARI feature as we did not
need it for our internal machines.  As always, this is something that we
could definitely work on under contract, and I am always happy to review
patches on Gerrit if you choose to tackle this on your own!

- -- 
Timothy Pearson

Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYhhHzAAoJEK+E3vEXDOFbwP0IAIbCI5HLMEYNmDOeYyO/IYQT
eVFMs+Bd2Q9bJA+x6e0D8MXL6LQzCOjxcg8qbeS4UuI6Kq6HszHqmKKH6rusmPqD
Ew2DCffmoQnvsshmL/YvqPSL1SZhYWjjNCdUrBNCAvJAZLEh9Tef4eKpVp9aHjt4
WBvrttU7uFyTf5zbWAPsOFfe2aQ0TNGlCgl+EOqJQWeIaHw+8gu6MPDOIc7aorJ/
2wC6ReI9iybAAlI0ZfYvsYFtuypqmJEOYmC/9uaU8xYtKOvrNumRPeJw1gB/m1yD
Z1joJMC9WQ/1b9+L9D9wRnhFrYp00e5GVZYXWbSM31v81zjg+GKThsAZYwpTnO4=
=haoQ
-END PGP SIGNATURE-

TY for info.

I finally found some real info on ARI.
https://us-east.manta.joyent.com/jmc/public/opensolaris/ARChive/FWARC/2010/063/Materials/ari-support.txt
Apparently SR-IOV doesn't actually require it, it is only needed for 
more than 8 total functions per device.
I will continue troubleshooting and get back to you, SR-IOV is an 
important feature for today's modern servers so I will try to figure it out.


I would DIY but hardware engineering is currently above my paygrade, but 
when I get a job I am definitely going to do some bankrollin'


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 SR-IOV problems (iommu groups) - Anyone else tried this?

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/21/2017 02:57 AM, taii...@gmx.com wrote:
> It seems the PCI-e root ports on the KGPE-D16 have ARI which is needed
> for SR-IOV, however it is not reported via # lspci -vv
> I assume that is why the VF's are not assigned to IOMMU groups and thus
> can't be assigned.
> 
> I am running coreboot v4.5 (I forgot to note this as it is another late
> night)
> 
> Tim was the ARI feature implemented when you guys did the programming?
> https://support.amd.com/TechDocs/44549.pdf

We did not explicitly enable nor verify the ARI feature as we did not
need it for our internal machines.  As always, this is something that we
could definitely work on under contract, and I am always happy to review
patches on Gerrit if you choose to tackle this on your own!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYhhHzAAoJEK+E3vEXDOFbwP0IAIbCI5HLMEYNmDOeYyO/IYQT
eVFMs+Bd2Q9bJA+x6e0D8MXL6LQzCOjxcg8qbeS4UuI6Kq6HszHqmKKH6rusmPqD
Ew2DCffmoQnvsshmL/YvqPSL1SZhYWjjNCdUrBNCAvJAZLEh9Tef4eKpVp9aHjt4
WBvrttU7uFyTf5zbWAPsOFfe2aQ0TNGlCgl+EOqJQWeIaHw+8gu6MPDOIc7aorJ/
2wC6ReI9iybAAlI0ZfYvsYFtuypqmJEOYmC/9uaU8xYtKOvrNumRPeJw1gB/m1yD
Z1joJMC9WQ/1b9+L9D9wRnhFrYp00e5GVZYXWbSM31v81zjg+GKThsAZYwpTnO4=
=haoQ
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 SR-IOV problems (iommu groups) - Anyone else tried this?

[taii...@gmx.com]

Logs (thought I would separate them)

ARI-fwd+ on the root port devcap and devctl but it doesn't have ARI 
listed in capabilities, I am not sure if lspci should report that on a 
root port as there is so little documentation for IOMMU/SR-IOV on the 
internet



07:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network 
Connection (rev 01)

Subsystem: Intel Corporation Ethernet Server Adapter I350-T4
Physical Slot: 13
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin D routed to IRQ 53
NUMA node: 0
Region 0: Memory at fa80 (32-bit, non-prefetchable) [size=1M]
Region 3: Memory at fa90c000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)

Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address:   Data: 
Masking:   Pending: 
Capabilities: [70] MSI-X: Enable+ Count=10 Masked-
Vector table: BAR=3 offset=
PBA: BAR=3 offset=2000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap:MaxPayload 512 bytes, PhantFunc 0, Latency L0s 
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ 
SlotPowerLimit 0.000W
DevCtl:Report errors: Correctable+ Non-Fatal+ Fatal+ 
Unsupported+

RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta:CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ 
TransPend-
LnkCap:Port #0, Speed 5GT/s, Width x4, ASPM L0s L1, Exit 
Latency L0s <4us, L1 <32us

ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta:Speed 5GT/s, Width x4, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, 
OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, 
OBFF Disabled
LnkSta2: Current De-emphasis Level: -6dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-

Capabilities: [100 v2] Advanced Error Reporting
UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt:DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-

CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap:First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number (removed)
Capabilities: [150 v1] Alternative Routing-ID Interpretation (ARI)
ARICap:MFVC- ACS-, Next Function: 0
ARICtl:MFVC- ACS-, Function Group: 0
Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
IOVCap:Migration-, Interrupt Message Number: 000
IOVCtl:Enable- Migration- Interrupt- MSE- ARIHierarchy-
IOVSta:Migration-
Initial VFs: 8, Total VFs: 8, Number of VFs: 0, Function 
Dependency Link: 03

VF offset: 128, stride: 4, Device ID: 1520
Supported Page Size: 0553, System Page Size: 0001
Region 0: Memory at fa9d (32-bit, non-prefetchable)
VF Migration: offset: , BIR: 0
Capabilities: [1a0 v1] Transaction Processing Hints
Device specific mode supported
Steering table in TPH capability structure
Capabilities: [1d0 v1] Access Control Services
ACSCap:SrcValid- TransBlk- ReqRedir- CmpltRedir- 
UpstreamFwd- EgressCtrl- DirectTrans-
ACSCtl:SrcValid- TransBlk- ReqRedir- CmpltRedir- 
UpstreamFwd- EgressCtrl- DirectTrans-

Kernel driver in use: igb
Kernel modules: igb

root port:

00:0d.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] 
RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP2 Port 0) (prog-if 
00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 35
NUMA node: 0
Bus: primary=00, secondary=07, subordinate=07, sec-latency=0
Memory behind bridge: fa50-fa9f
Prefetchable 

Re: [coreboot] KGPE-D16 SR-IOV problems (iommu groups) - Anyone else tried this?

[taii...@gmx.com]

It seems the PCI-e root ports on the KGPE-D16 have ARI which is needed 
for SR-IOV, however it is not reported via # lspci -vv
I assume that is why the VF's are not assigned to IOMMU groups and thus 
can't be assigned.


I am running coreboot v4.5 (I forgot to note this as it is another late 
night)


Tim was the ARI feature implemented when you guys did the programming?
https://support.amd.com/TechDocs/44549.pdf

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 SR-IOV problems (iommu groups) - Anyone else tried this?

[taii...@gmx.com]

Assigning regular devices such as a graphics card to a VM works just 
fine, but when I try to assign an intel i350 virtual function I receive 
the error


"error: internal error: Invalid device :07:10.0 iommu_group file 
/sys/bus/pci/devices/:07:10.0/iommu_group is not a symlink"


The PF's are split in to seperate IOMMU groups like every other pci-e 
device but for some while the VF's appear in lspci they aren't placed in 
IOMMU groups at all not even in the ones that the PF's are in.


Weird.

Note: PCI-e root ports all report ACS support and so does the NIC and I 
am using the /etc/modprobe.d/blahblah.conf max_vfs option to enable SR-IOV.



Help from intel is blood from a stone, so I am wondering if anyone else 
has this successfully working?
(I just bought a null modem cable and I now have free time to supply 
whichever logs are needed)



--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 Coreboot SR-IOV support?

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/16/2016 07:42 PM, taii...@gmx.com wrote:
> Hey does this have SR-IOV support? I want to know before I get a card.
> 
> - thanks

While I have not directly tested this functionality, there is no reason
it shouldn't work with the existing AMD IOMMU.  SR-IOV is a card-level
feature and, barring silicon or implementation bugs, should function
with the KGPE-D16 and AMD's IOMMU.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYWB/4AAoJEK+E3vEXDOFb2A4IAKJlGM3XhRH8YxGl/Q59kY0g
RQ/u4Z9+VjJFiyxkw2012ZWLTOe9ybx8rxsxLyMcc2cwPc909TEMeYay4z/pvgrH
FxldRQXRZwMyuh3t2ruXHR3QrLJ6YNaHd4eYbHw8BEROVmLyUsnneGIhH+qSWNL5
Yj6pbXFfnOKn4k2UQHSIRe/Drtz6Kj2EMDk6KHW3wXFB7iKaRhelnQqFNwCqQ8/U
1FQ1iYefKp4zG+u51rcyNzMUGv7Nva9DnvjUGt/LmPzkVKSUgtbxmeNEfRedB2xu
UXlqCcW8ukE+KrqVBtLGqwsGRNhjVdYYIHLIxTaL3Vkd+qBOC5xulcWQinW5bpc=
=GR/6
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 Coreboot SR-IOV support?

[taii...@gmx.com]

Hey does this have SR-IOV support? I want to know before I get a card.

- thanks


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kgpe-d16 and usb boot

[ron minnich]

never mind, pilot error, I did not realize it was a linux partition, not
fat32. oops.

On Tue, Dec 13, 2016 at 3:20 PM ron minnich  wrote:

> we have a kgpe-d16 with seabios as the payload and would like to usb boot.
> We have two sticks which work fine on other systems.
>
> seabios is not seeing the usb sticks. Anyone have configuration or other
> hints about what I might be doing wrong?
>
> thanks
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] kgpe-d16 and usb boot

[ron minnich]

we have a kgpe-d16 with seabios as the payload and would like to usb boot.
We have two sticks which work fine on other systems.

seabios is not seeing the usb sticks. Anyone have configuration or other
hints about what I might be doing wrong?

thanks
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 SR-IOV support?

[taii...@gmx.com]

Hello I am wondering if this motherboard supports with coreboot SR-IOV 
and PCI-e Access Control Services (needed for secure sr-iov apparently)


Information:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US=displayKC=1036811
http://www.intel.com/content/www/us/en/pci-express/pci-sig-sr-iov-primer-sr-iov-technology-paper.html

ACS Spec:
http://www.pcisig.com/specifications/pciexpress/specifications/ECN_access_control_061011.pdf

It would be nice if information like this was added to the supported 
motherboards page as these days sr-iov is a pretty basic server feature.


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 Black SATA2 ports do not work

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/09/2016 03:50 AM, aet...@openmailbox.org wrote:
> Hello,
> 
> I have a small issue with KGPE-D16.
> The two black sata2 ports do not work. (The SATA2 red ones work fine.
> All SAS/SATA3 work fine as well with Pike 2008 card.)
> 
> With Asus BIOS they work fine. I tried with several HDD just to make
> sure but they are not detected at all.
> 
> Please find my coreboot config and cbmem dump :
> 



> Thanks for your help.
> 

Please ensure that you have set the nvram variable
sata_ahci_mode=Enable, then reboot.  The default compatibility (PATA)
mode will not allow the black SATA ports to be used; in compatibility
mode, the chipset emulates an old-style PATA controller with a maximum
of four drives.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJXqg/cAAoJEK+E3vEXDOFbDlwH/33+rUqEhjnAeqqGKfVwKlJN
aTfd+sFfwuxrYjvHp3bkF2jXBW3ZV7UtwTVHczgoYNcozPWW6jd4C7ER2X3yuVZz
V/fcSOHxrShbL5EHov1/dv2NQAsWv2v/1EimNabBsSpvbQb/NM3TiB7VW1YXaBf5
oOo9Sp5qR+80fm+ZSFARSu5EoIlU/BPgNP/rRpXXwCiJwTs9auWTJQKc2vbhDqMH
V/TZoRvSczAe68PHS9iHvcY6QBWd8Tkr11RlamKl3P1SW3dqOekgnkHsc8Injok/
QD0k1V8fkHzrNn6yKGtKV4/411/YdbeERbv3oHvTpj5KyAkQzldzh4n+5mYqAAs=
=n5Lj
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 Black SATA2 ports do not work

[aether]

Hello,

I have a small issue with KGPE-D16.
The two black sata2 ports do not work. (The SATA2 red ones work fine. 
All SAS/SATA3 work fine as well with Pike 2008 card.)


With Asus BIOS they work fine. I tried with several HDD just to make 
sure but they are not detected at all.


Please find my coreboot config and cbmem dump :



coreboot config :

#
# Automatically generated file; DO NOT EDIT.
# coreboot configuration
#

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
# CONFIG_MULTIPLE_CBFS_INSTANCES is not set
CONFIG_COMPILER_GCC=y
# CONFIG_COMPILER_LLVM_CLANG is not set
# CONFIG_ANY_TOOLCHAIN is not set
# CONFIG_CCACHE is not set
# CONFIG_FMD_GENPARSER is not set
# CONFIG_SCONFIG_GENPARSER is not set
# CONFIG_USE_OPTION_TABLE is not set
# CONFIG_UNCOMPRESSED_RAMSTAGE is not set
CONFIG_COMPRESS_RAMSTAGE=y
CONFIG_INCLUDE_CONFIG_FILE=y
# CONFIG_NO_XIP_EARLY_STAGES is not set
CONFIG_EARLY_CBMEM_INIT=y
# CONFIG_EARLY_CBMEM_LIST is not set
# CONFIG_COLLECT_TIMESTAMPS is not set
# CONFIG_USE_BLOBS is not set
# CONFIG_COVERAGE is not set
# CONFIG_RELOCATABLE_MODULES is not set
# CONFIG_RELOCATABLE_RAMSTAGE is not set
# CONFIG_NO_STAGE_CACHE is not set
CONFIG_BOOTBLOCK_SIMPLE=y
# CONFIG_BOOTBLOCK_NORMAL is not set
CONFIG_BOOTBLOCK_CUSTOM=y
CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c"
# CONFIG_C_ENVIRONMENT_BOOTBLOCK is not set
# CONFIG_UPDATE_IMAGE is not set
# CONFIG_GENERIC_GPIO_LIB is not set
# CONFIG_BOARD_ID_AUTO is not set
# CONFIG_BOARD_ID_MANUAL is not set
CONFIG_DEVICETREE="devicetree.cb"
# CONFIG_RAM_CODE_SUPPORT is not set
# CONFIG_BOOTSPLASH_IMAGE is not set

#
# Mainboard
#
# CONFIG_VENDOR_A_TREND is not set
# CONFIG_VENDOR_AAEON is not set
# CONFIG_VENDOR_ABIT is not set
# CONFIG_VENDOR_ADI is not set
# CONFIG_VENDOR_ADLINK is not set
# CONFIG_VENDOR_ADVANSUS is not set
# CONFIG_VENDOR_AMD is not set
# CONFIG_VENDOR_AOPEN is not set
# CONFIG_VENDOR_APPLE is not set
# CONFIG_VENDOR_ARTECGROUP is not set
# CONFIG_VENDOR_ASROCK is not set
CONFIG_VENDOR_ASUS=y
# CONFIG_VENDOR_AVALUE is not set
# CONFIG_VENDOR_AZZA is not set
# CONFIG_VENDOR_BACHMANN is not set
# CONFIG_VENDOR_BAP is not set
# CONFIG_VENDOR_BCOM is not set
# CONFIG_VENDOR_BIFFEROS is not set
# CONFIG_VENDOR_BIOSTAR is not set
# CONFIG_VENDOR_BROADCOM is not set
# CONFIG_VENDOR_COMPAQ is not set
# CONFIG_VENDOR_CUBIETECH is not set
# CONFIG_VENDOR_DIGITALLOGIC is not set
# CONFIG_VENDOR_DMP is not set
# CONFIG_VENDOR_ECS is not set
# CONFIG_VENDOR_EMULATION is not set
# CONFIG_VENDOR_ESD is not set
# CONFIG_VENDOR_GETAC is not set
# CONFIG_VENDOR_GIGABYTE is not set
# CONFIG_VENDOR_GIZMOSPHERE is not set
# CONFIG_VENDOR_GOOGLE is not set
# CONFIG_VENDOR_HP is not set
# CONFIG_VENDOR_IBASE is not set
# CONFIG_VENDOR_IEI is not set
# CONFIG_VENDOR_INTEL is not set
# CONFIG_VENDOR_IWAVE is not set
# CONFIG_VENDOR_IWILL is not set
# CONFIG_VENDOR_JETWAY is not set
# CONFIG_VENDOR_KONTRON is not set
# CONFIG_VENDOR_LANNER is not set
# CONFIG_VENDOR_LENOVO is not set
# CONFIG_VENDOR_LINUTOP is not set
# CONFIG_VENDOR_LIPPERT is not set
# CONFIG_VENDOR_MITAC is not set
# CONFIG_VENDOR_MSI is not set
# CONFIG_VENDOR_NEC is not set
# CONFIG_VENDOR_NOKIA is not set
# CONFIG_VENDOR_NVIDIA is not set
# CONFIG_VENDOR_PACKARDBELL is not set
# CONFIG_VENDOR_PCENGINES is not set
# CONFIG_VENDOR_PURISM is not set
# CONFIG_VENDOR_RCA is not set
# CONFIG_VENDOR_RODA is not set
# CONFIG_VENDOR_SAMSUNG is not set
# CONFIG_VENDOR_SIEMENS is not set
# CONFIG_VENDOR_SOYO is not set
# CONFIG_VENDOR_SUNW is not set
# CONFIG_VENDOR_SUPERMICRO is not set
# CONFIG_VENDOR_TECHNEXION is not set
# CONFIG_VENDOR_THOMSON is not set
# CONFIG_VENDOR_TI is not set
# CONFIG_VENDOR_TRAVERSE is not set
# CONFIG_VENDOR_TYAN is not set
# CONFIG_VENDOR_VIA is not set
# CONFIG_VENDOR_WINENT is not set
# CONFIG_VENDOR_WYSE is not set
CONFIG_BOARD_SPECIFIC_OPTIONS=y
CONFIG_MAINBOARD_DIR="asus/kgpe-d16"
CONFIG_MAINBOARD_PART_NUMBER="KGPE-D16"
CONFIG_IRQ_SLOT_COUNT=13
CONFIG_MAINBOARD_VENDOR="ASUS"
CONFIG_MAX_CPUS=32
CONFIG_CACHE_ROM_SIZE_OVERRIDE=0
CONFIG_CBFS_SIZE=0x80
CONFIG_PAYLOAD_CONFIGFILE=""
CONFIG_APIC_ID_OFFSET=0
CONFIG_HW_MEM_HOLE_SIZEK=0x10
CONFIG_MAX_PHYSICAL_CPUS=4
# CONFIG_HW_MEM_HOLE_SIZE_AUTO_INC is not set
CONFIG_HT_CHAIN_END_UNITID_BASE=0x20
CONFIG_HT_CHAIN_UNITID_BASE=0x0
# CONFIG_ONBOARD_VGA_IS_PRIMARY is not set
# CONFIG_VGA_BIOS is not set
CONFIG_MAINBOARD_SERIAL_NUMBER="123456789"
CONFIG_DCACHE_RAM_BASE=0xc2000
CONFIG_DCACHE_RAM_SIZE=0x1e000
CONFIG_MMCONF_BASE_ADDRESS=0xc000
CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="ASUS"
# CONFIG_BOARD_ASUS_A8N_E is not set
# CONFIG_BOARD_ASUS_A8N_SLI is not set
# CONFIG_BOARD_ASUS_A8V_E_DELUXE is not set
# CONFIG_BOARD_ASUS_A8V_E_SE is not set
# CONFIG_BOARD_ASUS_DSBF is not set
# CONFIG_BOARD_ASUS_F2A85_M is not set
# CONFIG_BOARD_ASUS_F2A85_M_LE is not set
# CONFIG_BOARD_ASUS_K8V_X is not set
# CONFIG_BOARD_ASUS_KCMA_D8 is not set
# CONFIG_BOARD_ASUS_KFSN4_DRE is not set
# 

Re: [coreboot] kgpe-d16

[Stefan Reinauer]

* ron minnich  [160620 20:19]:
> I have a kgpe-d16 with coreboot and it *was* working with linux. I now have a
> linux kernel that won't boot on fuctory bios or coreboot. I can't recall
> changing anything ...
> 
> If somebody's got a known good .config for linux I could sure use it. I'm
> booting stock tinycore and it seems to hang a lot.

The Ubuntu 16.04 default config worked fine on the system.

Stefan



-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] kgpe-d16

[ron minnich]

I have a kgpe-d16 with coreboot and it *was* working with linux. I now have
a linux kernel that won't boot on fuctory bios or coreboot. I can't recall
changing anything ...

If somebody's got a known good .config for linux I could sure use it. I'm
booting stock tinycore and it seems to hang a lot.

thanks

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot