Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?
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.
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).
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.
Nico
Hi Nico
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 4, 2018 9:18 AM, Nico Huber nico.h@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
-
Nico Huber -
petecb