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.

1.  What is your configuration? How many processors, how much RAM?

2.  So, loading it from GNU/Linux (initramfs) as Tom asked, seems to
    work. I guess it’s the same with the vendor firmware?

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

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


[1]: https://lkml.org/lkml/2019/1/3/540
     "General protection fault in `switch_mm_irqs_off()`"


_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org