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, [email protected] <[email protected]> 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 -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
