Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?
Hi Pete,
On 01.12.18 17:21, petecb via coreboot wrote:
I'm wondering if my problem is related to not having any SATA drives installed? (I just have a PCI-E SSD). It may be the case that the logic to disable combined mode is not getting triggered in my scenario, yet it would do if there was a SATA drive present.
it's a configuration issue. If you have nvram settings enabled (CONFIG_ USE_OPTION_TABLE), you can enable `sata_ahci_mode` with nvramtool.
No idea why combined mode is the default, it's only useful for OSes from the '90s. It's not about the type of drives (SATA vs PATA) connected but how the SATA controller identifies itself to the OS.
Hope that helps, Nico
On 12/01/2018 11:56 AM, Nico Huber wrote:
Hi Pete,
On 01.12.18 17:21, petecb via coreboot wrote:
I'm wondering if my problem is related to not having any SATA drives installed? (I just have a PCI-E SSD). It may be the case that the logic to disable combined mode is not getting triggered in my scenario, yet it would do if there was a SATA drive present.
it's a configuration issue. If you have nvram settings enabled (CONFIG_ USE_OPTION_TABLE), you can enable `sata_ahci_mode` with nvramtool.
Ah so that is why it works for me but not for him, since I always customize my CMOS options :D
No idea why combined mode is the default, it's only useful for OSes from the '90s. It's not about the type of drives (SATA vs PATA) connected but how the SATA controller identifies itself to the OS.
AHCI is faster and better as it supports NCQ, TRIM etc.
Conga-rats petey now you can fix it easy! just enable cmos settings in menuconfig then go to the kgpe-d16 coreboot board directory and change cmos.default, recompile/flash then reset your CMOS - OR if you already have use cmos enabled you can simply change it via the cmos tool with the required iomem=relaxed in the kernel command line.
I would also lower the log/debug level via menuconfig to speed boot times and maybe change some other things in cmos.default like me
I have experimental_memory_speed_boost enabled, my 1394 controller set to disabled and SATA ALPM to enabled.
Hi,
I never saw any documentation about those CMOS settings so didn't realize they were available to modify! :-)
Thank you for all those details. I've now compiled a version with the default CMOS settings apart from the following changes
Minimum memory voltage = 1.35v experimental_memory_speed_boost enabled 1394 controller disabled SATA ALPM enabled.
Unfortunately, this results in the Qubes installation on the SSD crashing before it gets to the password prompt and the Qubes installer crashing shortly after booting. They both produce a similar error message that has been too quick to catch so far but mentions "PCI" and "IRQ".
If I have no drives installed the system does get to the memtest payload but then hangs after 4 seconds. Could this be related to the minimum memory voltage I set?
I've also noticed ever since I put coreboot on this system a few weeks ago it intermittently hangs half way through the boot process at the following line:
PCI: 00:14.3 a0 <- [0x00f8710000 - 0x00f8710000] size 0x00000001 gran 0x00 mem
Is this indicative of anything?
Kind regards,
Pete
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, December 1, 2018 6:36 PM, Taiidan@gmx.com Taiidan@gmx.com wrote:
On 12/01/2018 11:56 AM, Nico Huber wrote:
Hi Pete, On 01.12.18 17:21, petecb via coreboot wrote:
I'm wondering if my problem is related to not having any SATA drives installed? (I just have a PCI-E SSD). It may be the case that the logic to disable combined mode is not getting triggered in my scenario, yet it would do if there was a SATA drive present.
it's a configuration issue. If you have nvram settings enabled (CONFIG_ USE_OPTION_TABLE), you can enable `sata_ahci_mode` with nvramtool.
Ah so that is why it works for me but not for him, since I always customize my CMOS options :D
No idea why combined mode is the default, it's only useful for OSes from the '90s. It's not about the type of drives (SATA vs PATA) connected but how the SATA controller identifies itself to the OS.
AHCI is faster and better as it supports NCQ, TRIM etc.
Conga-rats petey now you can fix it easy! just enable cmos settings in menuconfig then go to the kgpe-d16 coreboot board directory and change cmos.default, recompile/flash then reset your CMOS - OR if you already have use cmos enabled you can simply change it via the cmos tool with the required iomem=relaxed in the kernel command line.
I would also lower the log/debug level via menuconfig to speed boot times and maybe change some other things in cmos.default like me
I have experimental_memory_speed_boost enabled, my 1394 controller set to disabled and SATA ALPM to enabled.
coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Hi!
No idea why combined mode is the default, it's only useful for OSes from the '90s. It's not about the type of drives (SATA vs PATA) connected but how the SATA controller identifies itself to the OS.
I agree that the combined mode isn't the best default, but I can't say that it's totally useless. In combined mode you have the first 4(?) SATA ports connected to an AHCI controller and the last 2(?) to a legacy IDE/ATA controller. I had some SATA->PATA bridge to connect a PATA device to a mainboard and the adapter I had only worked on SATA ports that were connected to a legacy IDE/ATA controller, but not on SATA ports connected to an AHCI controller. I didn't further debug that issue though, so I can't say why it didn't work on an AHCI controller.
Speaking of the KGPE-D16: I still have this patch [0] in my review queue that is needed for coreboot to work on the board when the BMC firmware flash is installed, but it seems that neither Timothy nor owners of that board really care about that patch any more (I poked a few people about that patch a few times), which I find quite sad. Would be good if someone would address the last 3 comments and actually tests the patch on the real hardware, so it can be merged to fix that show-stopper.
Regards
Felix
On 03.12.18 11:35, Felix Held wrote:
No idea why combined mode is the default, it's only useful for OSes from the '90s. It's not about the type of drives (SATA vs PATA) connected but how the SATA controller identifies itself to the OS.>
I agree that the combined mode isn't the best default, but I can't say that it's totally useless. In combined mode you have the first 4(?) SATA ports connected to an AHCI controller and the last 2(?) to a legacy IDE/ATA controller. I had some SATA->PATA bridge to connect a PATA device to a mainboard and the adapter I had only worked on SATA ports that were connected to a legacy IDE/ATA controller, but not on SATA ports connected to an AHCI controller. I didn't further debug that issue though, so I can't say why it didn't work on an AHCI controller.
Interesting use case. I missed that the combined mode is also the only mode where you have SATA ports on AHCI and the legacy interface.
I also don't know if an IDE drive should work with AHCI. My guess would be yes, but OS drivers probably don't expect it.
Nico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 12/03/2018 04:35 AM, Felix Held wrote:
Hi!
No idea why combined mode is the default, it's only useful for OSes from the '90s. It's not about the type of drives (SATA vs PATA) connected but how the SATA controller identifies itself to the OS.
I agree that the combined mode isn't the best default, but I can't say that it's totally useless. In combined mode you have the first 4(?) SATA ports connected to an AHCI controller and the last 2(?) to a legacy IDE/ATA controller. I had some SATA->PATA bridge to connect a PATA device to a mainboard and the adapter I had only worked on SATA ports that were connected to a legacy IDE/ATA controller, but not on SATA ports connected to an AHCI controller. I didn't further debug that issue though, so I can't say why it didn't work on an AHCI controller.
Speaking of the KGPE-D16: I still have this patch [0] in my review queue that is needed for coreboot to work on the board when the BMC firmware flash is installed, but it seems that neither Timothy nor owners of that board really care about that patch any more (I poked a few people about that patch a few times), which I find quite sad. Would be good if someone would address the last 3 comments and actually tests the patch on the real hardware, so it can be merged to fix that show-stopper.
Regards
Felix
First, thanks for the patch and work on the KGPE-D16. I've been meaning to do a better job at helping maintain the platform, but right now life has gotten somewhat in the way in that I haven't had proper access to the KGPE-D16 development system in quite a while (space taken up with Talos / Blackbird boards for the most part).
Things should settle down some after Christmas, so I'll see what I can do to pull the old D16 dev platform back out at that time and start testing / merging patches. Are there any others that I should also help take a look at?
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
Hi!
Things should settle down some after Christmas, so I'll see what I can do to pull the old D16 dev platform back out at that time and start testing / merging patches. Are there any others that I should also help take a look at?
Arthur pushed a new version of your patch #19820 and since it does what your original patch does, I'd say that it should be safe for merging to have that problem fixed in the upcoming release. Of course unless someone else tests the patch and finds a (very unlikely) regression before tomorrow. There are two more patches from that series, but I haven't reviewed them, since they add features and don't just fix problems.
I'm not sure if Arthur has some other patches that are relevant to the KGPE-D16; IIRC he also looked into some improvements on the AMD side.
Regards
Felix
Felix Held felix-coreboot@felixheld.de writes:
Hi!
Things should settle down some after Christmas, so I'll see what I can do to pull the old D16 dev platform back out at that time and start testing / merging patches. Are there any others that I should also help take a look at?
Arthur pushed a new version of your patch #19820 and since it does what your original patch does, I'd say that it should be safe for merging to have that problem fixed in the upcoming release. Of course unless someone else tests the patch and finds a (very unlikely) regression before tomorrow. There are two more patches from that series, but I haven't reviewed them, since they add features and don't just fix problems.
I'm not sure if Arthur has some other patches that are relevant to the KGPE-D16; IIRC he also looked into some improvements on the AMD side.
https://review.coreboot.org/c/coreboot/+/30063 implement relocatable ramstage on AMDFAM10. Would be interesting to see whether it works on amdfam15 hardware and if S3 resume still works fine.
https://review.coreboot.org/c/coreboot/+/30064/4 Implements postcar stage on amdfam10 and drops the backup of RAMBASE..RAMTOP region. It would allow to drop a whole lot of legacy code used for S3 resume, so also definitely worth testing.
Both patches worked on a gigabyte m57-sli4 board with a amdfam10 CPU, so I expect that booting till the OS still works fine. S3 resume might be a little different. (review for board port is: https://review.coreboot.org/c/coreboot/+/27618)
Something thing that would seem nice and would make CAR setup more unified with how we do things on Intel hardware is to use variable MTRR's for CAR instead of the fixed ones. A difficulty is that the location needs to be carefully chosen as it needs to be below the TOP_MEM MTRR, while also not hindering the raminit (I suppose)...
Another thing I'm working on, is to use C_ENVIRONMENT_BOOTBLOCK on all x86 platforms (dropping use of romcc). Bringing that feature to amdfam10 won't be practical on my gigabyte m57sli board due to it using LPC flash (I expect tons of reflashes/testing cycles ;). If someone is willing to donate a supported board (not really interested in doing a board port due to the deplorable state of AMD code in general) featuring amdfam10 hardware, preferably with DDR3 (implements S3 resume) and a SPI boot medium, that would be fun.
It does not look this has anything to do with the original thread title so sorry for hijacking it a little...
Regards
Felix
Kind regards
-
Arthur Heymans -
Felix Held -
Nico Huber -
petecb -
Taiidan＠gmx.com -
Timothy Pearson