Hello Paul,
mein Configuration is:
1x Opteron 6380
processor : 15 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6380
and MEM:
root@lain:~# dmidecode -t 17 # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present.
Handle 0x000B, DMI type 17, 40 bytes Memory Device Array Handle: 0x000A 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_C2 Bank Locator: Not Specified Type: DDR3 Type Detail: Synchronous Registered (Buffered) Speed: 667 MT/s Manufacturer: Samsung Serial Number: 7926BB85 Asset Tag: Not Specified Part Number: M393B1K70DH0-CH9 Rank: 2 Configured Memory Speed: 667 MT/s Minimum Voltage: 1.5 V Maximum Voltage: 1.5 V Configured Voltage: 1.5 V
Handle 0x000C, DMI type 17, 40 bytes Memory Device Array Handle: 0x000A 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_D2 Bank Locator: Not Specified Type: DDR3 Type Detail: Synchronous Registered (Buffered) Speed: 667 MT/s Manufacturer: Hynix/Hyundai Serial Number: 393C405F Asset Tag: Not Specified Part Number: HMT31GR7BFR4C-H9 Rank: 2 Configured Memory Speed: 667 MT/s Minimum Voltage: 1.5 V Maximum Voltage: 1.5 V Configured Voltage: 1.5 V
I have currently an old microcode from 2016 (PreSpectre) included in coreboot ROM
and update it via Kernel to 0x6000852.
I did not test the vendor firmware at all with this board.
Also my system does not start with the shipped debian kernel (4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64) with used CONFIG_SLUB=y)
protection fault... i wrote an other email about this.
Instead i selfbuild a vanila kernel 4.19.62 with CONFIG_SLAB=y
So my wild guess is that coreboot does not initlize the new OPCODES coming with the new microcode in a correct way.
best regards
the nekoboi
Am 31.07.19 um 18:17 schrieb Paul Menzel:
Dear Kinky,
On 7/30/19 11:18 AM, Kinky Nekoboi wrote:
loading the microcode via Linux Kernel works.
including it via coreboot causes General Protection Faults.
See included bootlog.
We hit the same issue on our board, and reported it to the Linux kernel developers [1].
Unfortunately, we didn’t have more resources to pursue this further.
What is your configuration? How many processors, how much RAM?
So, loading it from GNU/Linux (initramfs) as Tom asked, seems to work. I guess it’s the same with the vendor firmware?
As Tom tested it on a similar custom AMD board (with supposedly microcode updates updated in the *vendor firmware*, and it worked for him, there might be something wrong with how microcode updates are applied in coreboot.
The user *sfs* in #coreboot@irc.freenode.net did not have the problems if I remember correctly.
Anyway, somebody with time and motivation would need to debug this. But it’d be great if you could check a few things and maybe chime in the LKML discussion.
Kind regards,
Paul
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org