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

petecb petecb at protonmail.com
Tue Dec 4 18:12:05 CET 2018

Hi Nico

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, December 4, 2018 9:18 AM, Nico Huber <nico.h at gmx.de> wrote:

> On 03.12.18 19:50, petecb via coreboot wrote:
> > I have attached a text file with an overview of all the options I have
> > selected with the nconfig utility, on the off-chance someone spots
> > something I have done wrong.
> Best way to find out is to disable USE_OPTION_TABLE again and leave
> everything else as is. If that doesn't result in a reliable image,
> the option table is not to blame. Actually, we try to discourage
> developers from adding options that may result in a failure, but
> you never know.

Thank you for this advice, I have followed it and can confirm it is the option table to blame.

I did discover this in src/southbridge/amd/sb700/sata.c :

	if (sata_ahci_mode) {
		/* FIXME
		* SeaBIOS does not know how to spin
		* up the drives and therefore hangs
		* in AHCI init if this is enabled...
		/* Enable staggered spin-up */
		dword = read32(sata_bar5 + 0x00);
#if 0
		dword |= 0x1 << 27;
		dword &= ~(0x1 << 27);
		write32(sata_bar5 + 0x00, dword);

		/* Reset the HBA to avoid stuck drives in SeaBIOS */
		dword = read32(sata_bar5 + 0x04);
		dword |= 0x1;
		write32(sata_bar5 + 0x04, dword);

As I am using SeaBIOS, could this be the problem? Part of me doubts it, as I would assume it would hang well before it started to boot Qubes or even get to memtest.

> You can use `make savedefconfig` to save the options that differ from
> their default. It writes into a file `defconfig`. That's probably better
> than your "screenshots" (unless the D16 requires non-default settings to
> work).

Thank you, that's good to know.

> Regarding the cmos.default, IMHO, somebody should go through all the
> options (from `interleave_chip_selects` to `maximum_p_state_limit` in
> cmos.layout), check where they are used in the code (e.g. `git grep \\"interleave_chip_selects\\"`) and document their defaults in absence
> of the option table (i.e. when get_option() returns a failure or
> doesn't do anything at all). Then we'd be able to discuss sane defaults.
> Though, we'd need to take all boards using the respective code paths
> into account.

I've had a quick look at this, but I am way out of my depth at the minute. It's been a long time since I've coded in C! :-)

If anyone has any input regarding which values are being changed in the option table from the defaults, it would be very much appreciated.

Kind regards,


More information about the coreboot mailing list