Dear coreboot folks,
Arthur provided change-set *sb/amd/hudson: Skip setting up LPC decode for base < 0x20* [1] fixing a hang when doing `outb(0, DMA1_RESET_REG)` on the Asus F2A85-M PRO with Nuvoton NCT6779D:
In some board ports SuperIO chips in the devicetree are not properly set up with some IO ranges being unassigned which ends up being base= 0. It's not an issue as long as the LPC bridge does not end up decoding those IO ports. Doing so would conflict with ISA DMA registers (0-0x1f). Writing to those DMA registers then causes a hang.
I am moving the discussion to the mailing list. A big thank you to all reviewers:
Michał commented:
I wouldn't say it is not properly set up. Some LDNs on e.g. on Nuvoton chips have two IO register pairs and one does not always want to enable them both. Anyway this was a bug, glad that you found it.
Additionally the discussion below happened:
Nico/Arthur/Nico:
Isn't this just covering up bugs in the mainboard ports?
I don't think so. Are there mainboard ports where decoding LPC on port 0-0x1f is expected?
I expect all knows resources to be decoded.
Unassigned and unused io ports on SIO devices get port 0 assigned with the expectation that LPC won't be decoding that range.
Only by accident I guess?
It looks like a pretty implicit assumption though. This does not present itself on intel hardware as variable IO decode ranges are often set manually in the devicetree.
That's also just a way to work around bugs. IMO, any devicetree entry that says `on` and assigns `0` as i/o-port is inconsistent.
We also don't pick individual resources of PCI devices and then hack the bridge config to make things work. Why should LPC be treated differently?
I also wonder if the `0` setting is still necessary? i.e. can't the allocator do it now? if not, why?
Arthur:
What do you suggest? Adding a child 'DMA' to LPC (0-0xfff is for the LPC bridge iirc) that reserves 0-0x1F such that no conflicts occur?
IO0 is the HWM on nuvoton nct6779d For IO1: "These two registers select the SB-TSI base address <100h : FFEh> along a two-byte boundary." So I assume that if it's set < 0x100 this does not get decoded. How would you go about not enabling the SB-TSI range but enabling HWM?> Do you think https://review.coreboot.org/c/coreboot/+/54686 [2] is a better approach?
Nico:
We usually assign all resources of enabled devices. So I would simply not not enable SB-TSI. If the resource assignment triggers something special in this chip, this chip's driver should handle it, IMHO (and not the devicetree by assigning false resources).
Angel:
The coreboot code should not report the SB-TSI resource if its base is out of that <100h : FFEh> range. Optionally complain about an invalid base if it's not zero (what would possess anyone to assign a non-zero but invalid value?)
Michał:
Which Super I/O chip driver really checks allowed boundaries specified in its datasheet? None. Each mainboard's devicetree is created with an assumption that unassigned io/irq resource is just disabled resource.
- The Super I/O drivers should start checking the resources in terms
of boundaries (and maybe resource existence, i.e. whether devicetree sets it) 2. The PNP driver which assigns resources should also understand that zero resources are disabled resources if we don't do it in the point 1.
What do others think, and how can we move this forward? The alternative CB:54686 ([RFC]device/pnp_device: Disable IO resources if base == 0) does not work on the Asus F2A85-M PRO (yet).
Kind regards,
Paul
[1]: https://review.coreboot.org/c/coreboot/+/54669 "sb/amd/hudson: Skip setting up LPC decode for base < 0x20" [2]: https://review.coreboot.org/c/coreboot/+/54686 "[RFC]device/pnp_device: Disable IO resources if base == 0"