Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

On 11/27/2018 12:12 PM, petecb via coreboot wrote:
> Hi,
>
> Thanks for your reply.
>
> I have built a version of coreboot with the “use binary only repo” and “generate microcode updates from tree”. I presume by selecting “from tree” I do not need to fill in the “Mircrocode binary path and filename”.

Yeah you don't since it is done automatically with both of those options
selected.
> The output of the make command to build the rom provides the following at the end:
>
> FMAP REGION: COREBOOT
> Name                           Offset     Type           Size   Comp
> cbfs master header             0x0        cbfs header        32 none
> fallback/romstage              0x80       stage          171020 none
> config                         0x29d00    raw               281 none
> revision                       0x29e80    raw               576 none
> cmos_layout.bin                0x2a100    cmos_layout      3524 none
> fallback/dsdt.aml              0x2af00    raw              9895 none
> payload_config                 0x2d600    raw              1682 none
> payload_revision               0x2dd00    raw               236 none
> microcode_amd_fam15h.bin       0x2de40    microcode        7876 none
> (empty)                        0x2fd80    null               24 none
> s3nv                           0x2fdc0    raw             65536 none
> fallback/ramstage              0x3fe00    stage           88643 none
> vgaroms/seavgabios.bin         0x55880    raw             28160 none
> img/coreinfo                   0x5c700    simple elf      50606 none
> fallback/payload               0x68d00    simple elf      68119 none
> img/memtest                    0x79780    simple elf      47555 none
> microcode_amd.bin              0x85180    microcode       12684 none

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.
> (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
> 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.
> 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 :]
> 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.

Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[petecb]

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, [e-mail]  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