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

[petecb]

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;
#else
		dword &= ~(0x1 << 27);
#endif
		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,

Pete