Hi,
Thank you for your reply. Please see below for my responses to some of your points.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, November 27, 2018 10:59 PM, Taiidan@gmx.com Taiidan@gmx.com wrote:
On 11/27/2018 12:12 PM, petecb via coreboot wrote:
Looks to be there now.
Here from your serial log:
CBFS: 'Master Header Locator' located CBFS at [200:200000) CBFS: Locating 'microcode_amd.bin' CBFS: Found @ offset 85180 size 318c CBFS: 'Master Header Locator' located CBFS at [200:200000) CBFS: Locating 'microcode_amd_fam15h.bin' CBFS: Found @ offset 2de40 size 1ec4 [microcode] patch id to apply = 0x06000852 [microcode] updated to patch id = 0x06000852 success
*852 is the latest version AFAIK so you are good.
Thank you for checking this.
(empty) 0x88380 null 1537368 none bootblock 0x1ff900 bootblock 1184 none From this it looks as though it is being built with the microcode. If I boot into a Fedora Live CD dmesg does show me that the AMD microcode is being applied. > However I presume this is Fedora doing this because when I boot into Qubes it does not detect IOMMU.
It looks like a xen issue.
Does this indicate an issue with how I have built coreboot?
No now it is fine.
It should be working hmm but next try the below solution.
Is there a way to get Qubes to apply microcode updates in the same way Fedora does?
Xen yes. Edit /etc/default/grub (ex: sudo nano /etc/default/grub) Add ucode=scan to GRUB_CMDLINE_XEN_DEFAULT inside the quotes Then run sudo grub2-mkconfig -o /boot/grub2/grub.cfg
I followed these instructions and found that "ucode=scan" was already present. I also noticed that it had "iommu=no-igfx" so I changed this to "iommu=on" and rebooted. Unfortunately this did not appear to have an effect and when I ran the "qubes-hcl-report" it still indicated IOMMU was not active :-(
Have you successfully got a 6386 on this board running with Qubes and all the microcode updates?
Yeah I have with various 63xx CPU's.
To clarify, have you been successful with Qubes 4? The rest of my systems are running this so I need to figure out a way to get version 4 running securely on this system.
Do you have any other suggestions? If this is a Xen issue do you expect it to be a while before it is fixed and merged in to Qubes? If a 62xx CPU definitely works and doesn't have these problems, it may be better for me to procure one of those so I can be up and running quicker.
I have attached a copy of my serial output booting the system with 2 sticks of 16Gb ECC RAM (32Gb total) in case this is of any help.
Put your RAM back in that would not effect anything :]
I noticed it tended to take longer to boot with more RAM, so I took some out whilst I was troubleshooting :-) Do you know if this system is likely to be more stable with a single CPU and 128Gb RAM in all its slots or whether it would be better to have 2 CPUs and split the 128Gb RAM between them (ie. all Orange slots populated)
Many thanks for your help, it is much appreciated.
Hell yeah bro I love helping fellow freedom lovers. I like to do the free tech support stuff the coreboot devs don't have time for.
Did you check out the sexy new raptor blackbird btw? OpenPOWER is the future of high performance computing freedom.
Yeah, I have been looking at those! :-) I really want one but unfortunately my workflow at the moment really depends on Qubes and I need some x86 compatibility. As soon as this changes I will be getting either a blackbird or the Talos.
Thanks once again for your help.
Kind regards,
Pete