Patch Set 1: Code-Review-1

Dug a little into the chipset support for historical Intel
in the tree: Older ICHs implement the bit r/w but mention
to ignore it anyway, because everything goes to PCI. So that
should be fine.

440BX doesn't seem to know it, though :-/ So this can't go
in as is. I'm open for suggestions. What should we do if
16-bit decode isn't possible? Restrict all i/o to 10 bits?
That could brick... Hmmmm, just warn about it? Instead of
skipping the device?

I really don't like to reserve the VGA resources 64 times,
could do that, though.

The code in device.c seems to attempt to avoid VGA IO and "legacy" PCI IO windows when allocating (dynamic) resources. I am not convinced that code always works, and those windows would appear to be unnecessary for platforms where we can have programming of CTL_VGA=1, CTL_VGA16=1 and CTL_(NO)_ISA=0 for PCI_BRIDGE_CONTROL.

I think we could first throw errors if assigned resources overlap some of those aliased (and enabled) IO address ranges. Should be easy to (manually) adjust the conflicting static resources when they appear.

View Change

3 comments:

To view, visit change 35516. To unsubscribe, or for help writing mail filters, visit settings.

Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Id7a07f069dd54331df79f605c6bcda37882a602d
Gerrit-Change-Number: 35516
Gerrit-PatchSet: 1
Gerrit-Owner: Nico Huber <nico.h@gmx.de>
Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki@gmail.com>
Gerrit-Reviewer: Michael Niewöhner
Gerrit-Reviewer: Nico Huber <nico.h@gmx.de>
Gerrit-Reviewer: Patrick Rudolph <siro@das-labor.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply@coreboot.org>
Gerrit-Comment-Date: Sat, 21 Sep 2019 20:40:33 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Kyösti Mälkki <kyosti.malkki@gmail.com>
Comment-In-Reply-To: Michael Niewöhner
Gerrit-MessageType: comment