[PATCH] itco: Add support for newer intel chipsets

[Sjoerd Simons]

This adds support for Tiger lake LP, Jasper lake, Alder lake (various
variants), Raptor lake, Meteor lake (various variants) and Birch
Stream devices using the relevant pci-ids and chip namings from the
linux kernel.

Tested on Dell Optiplex 7000 and Optiplex E4 with Alder Lake-S chipsets.

Signed-off-by: Sjoerd Simons <sjo...@collabora.com>
---
drivers/watchdog/itco.c | 72 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/itco.c b/drivers/watchdog/itco.c
index 9252014..f268a35 100644
--- a/drivers/watchdog/itco.c
+++ b/drivers/watchdog/itco.c
@@ -40,6 +40,16 @@ enum iTCO_chipsets {
ITCO_INTEL_WBG,
ITCO_INTEL_EHL,
ITCO_INTEL_TLH,
+ ITCO_INTEL_TL_LP,
+ ITCO_INTEL_JL,
+ ITCO_INTEL_AL_S,
+ ITCO_INTEL_AL_P,
+ ITCO_INTEL_AL_M,
+ ITCO_INTEL_RL_S,
+ ITCO_INTEL_ML_P,
+ ITCO_INTEL_ML_SOC_S,
+ ITCO_INTEL_ML_PCH_S,
+ ITCO_INTEL_BS,
};

enum iTCO_versions {
@@ -62,7 +72,7 @@ typedef struct {
} iTCO_regs;

typedef struct {
- CHAR16 name[16];
+ CHAR16 name[32];
UINT32 pci_id;
UINT32 itco_version;
} iTCO_info;
@@ -163,6 +173,66 @@ static const iTCO_info iTCO_chipset_info[] = {
.pci_id = 0x43a3,
.itco_version = ITCO_V6,
},
+ [ITCO_INTEL_TL_LP] =
+ {
+ .name = L"Tiger Lake-LP",
+ .pci_id = 0xa0a3,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_JL] =
+ {
+ .name = L"Jasper Lake",
+ .pci_id = 0x4da3,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_AL_S] =
+ {
+ .name = L"Alder Lake-S",
+ .pci_id = 0x7aa3,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_AL_P] =
+ {
+ .name = L"Alder Lake-P",
+ .pci_id = 0x51a3,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_AL_M] =
+ {
+ .name = L"Alder Lake-M",
+ .pci_id = 0x54a3,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_RL_S] =
+ {
+ .name = L"Raptor Lake-S",
+ .pci_id = 0x7a23,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_ML_P] =
+ {
+ .name = L"Meteor Lake-P",
+ .pci_id = 0x7e22,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_ML_SOC_S] =
+ {
+ .name = L"Meteor Lake SoC-S",
+ .pci_id = 0xae22,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_ML_PCH_S] =
+ {
+ .name = L"Meteor Lake PCH-S",
+ .pci_id = 0x7f23,
+ .itco_version = ITCO_V6,
+ },
+ [ITCO_INTEL_BS] =
+ {
+ .name = L"Birch Stream",
+ .pci_id = 0x5796,
+ .itco_version = ITCO_V6,
+ },
};

static BOOLEAN itco_supported(UINT16 pci_device_id, UINT8 *index)
--
2.43.0

[Jan Kiszka]

On 16.05.24 11:52, 'Sjoerd Simons' via EFI Boot Guard wrote:
> This adds support for Tiger lake LP, Jasper lake, Alder lake (various
> variants), Raptor lake, Meteor lake (various variants) and Birch
> Stream devices using the relevant pci-ids and chip namings from the
> linux kernel.
>
> Tested on Dell Optiplex 7000 and Optiplex E4 with Alder Lake-S chipsets.
>

Thanks for the contribution! Just one concern: As we are not using the
exact same enabling logic in EBG compared to the kernel, I'm always a
bit reluctant to merge support for devices that were not tried in real
life. So, we have 2 of the 10 additions actually tested, right? Can you
explain why the other 8 are a "safe bet"? Or can we extend the on-device
test coverage?

Jan

Siemens AG, Technology
Linux Expert Center

[Sjoerd Simons]

Hey,

On Thu, 2024-05-16 at 12:00 +0200, Jan Kiszka wrote:
> On 16.05.24 11:52, 'Sjoerd Simons' via EFI Boot Guard wrote:
> > This adds support for Tiger lake LP, Jasper lake, Alder lake
> > (various
> > variants), Raptor lake, Meteor lake (various variants) and Birch
> > Stream devices using the relevant pci-ids and chip namings from the
> > linux kernel.
> >
> > Tested on Dell Optiplex 7000 and Optiplex E4 with Alder Lake-S
> > chipsets.
> >
>
> Thanks for the contribution! Just one concern: As we are not using
> the
> exact same enabling logic in EBG compared to the kernel, I'm always a
> bit reluctant to merge support for devices that were not tried in
> real
> life. So, we have 2 of the 10 additions actually tested, right? Can
> you
> explain why the other 8 are a "safe bet"? Or can we extend the on-
> device
> test coverage?

As they're all itco v6 watchdogs you'd hope it's a pretty safe bet,
assuming the EBG code does reasonable things. The kernel for sure
doesn't further differentiate between different instances/generations.

I'm happy to limit the patch to just chipsets/generations we've tested
on though if that's the preference. It just makes efibootguard a bit
more cumbersome to adopt for new hardware

Sjoerd Simons
Collabora Ltd.

[Jan Kiszka]

Looking at the much simpler specifics of v6 iTCO again, I agree that
these extension are low risk.

Thanks, applied.

Jan

[Christopher Obbard]

Hi,

I have been doing some testing with efibootguard, it seems like efibootguard
fails to enable the watchdog on some of my hardware. I am testing this with a
recent Linux build with all kernel watchdog drivers not built and the
efibootguard watchdog configuration option set to 30s.

For this test, I expect the system to reboot roughly 30s after efibootguard
initialises.

Test results from a few machines I have to hand are as follows:

- qemu x86_64 machine q35 (iTCO v2; wdt resets fine)

- generic mini pc (iTCO v4, Braswell; wdt resets fine)



And some machines which do not seem to reset after the wdt has been primed:

- Atari VCS (I believe this machine contains an amdfch_wdt, but I didn't
verify that as yet; wdt does not reset)

- Dell OptiPlex 7000 series mini PC (iTCO v6, Alder Lake-S; wdt does not
reset) I also have some other hardware which uses iTCO v6 which also do not
seem to reset.



Do you have any recommendations on how to debug/fix these issues? It'd be
great to get this fixed before the next efibootguard release. If someone can
also verify my claims, it'd be great.


ftr: I also think it'd probably make sense to redo my testing above, with an
UEFI shell as a target, just in case some watchdog driver really was feeding
the hardware.


Thanks!

Chris

[Jan Kiszka]

On 10.06.24 20:14, 'Christopher Obbard' via EFI Boot Guard wrote:
> Hi,
>
> I have been doing some testing with efibootguard, it seems like efibootguard
> fails to enable the watchdog on some of my hardware. I am testing this with a
> recent Linux build with all kernel watchdog drivers not built and the
> efibootguard watchdog configuration option set to 30s.
>
> For this test, I expect the system to reboot roughly 30s after efibootguard
> initialises.
>
> Test results from a few machines I have to hand are as follows:
>
> - qemu x86_64 machine q35 (iTCO v2; wdt resets fine)
>
> - generic mini pc (iTCO v4, Braswell; wdt resets fine)
>

Err, we do not support iTCO v4 yet, see the related driver. Do you have
patches on top?

>
>
> And some machines which do not seem to reset after the wdt has been primed:
>
> - Atari VCS (I believe this machine contains an amdfch_wdt, but I didn't
> verify that as yet; wdt does not reset)
>
> - Dell OptiPlex 7000 series mini PC (iTCO v6, Alder Lake-S; wdt does not
> reset) I also have some other hardware which uses iTCO v6 which also do not
> seem to reset.
>

There might be an issue with clearing the no-reboot flag on the
particular device. As its name says, that flag prevent any actual reboot
if the timer expires. You should cross-check if Linux works fine and
then dig deeper what exactly that driver does to ensure this.

>
>
> Do you have any recommendations on how to debug/fix these issues? It'd be
> great to get this fixed before the next efibootguard release. If someone can
> also verify my claims, it'd be great.
>
>
> ftr: I also think it'd probably make sense to redo my testing above, with an
> UEFI shell as a target, just in case some watchdog driver really was feeding
> the hardware.
>

BTW, you should be able to simulate a handing kernel fairly easily now
by setting --with-boot-delay during configure to a value above the
configured EBG timeout.

[Christopher Obbard]

Hi Jan,

On Mon, 2024-06-10 at 23:37 +0200, Jan Kiszka wrote:
> On 10.06.24 20:14, 'Christopher Obbard' via EFI Boot Guard wrote:
> > Hi,
> >
> > I have been doing some testing with efibootguard, it seems like
> > efibootguard
> > fails to enable the watchdog on some of my hardware. I am testing this
> > with a
> > recent Linux build with all kernel watchdog drivers not built and the
> > efibootguard watchdog configuration option set to 30s.
> >
> > For this test, I expect the system to reboot roughly 30s after
> > efibootguard
> > initialises.
> >
> > Test results from a few machines I have to hand are as follows:
> >
> > - qemu x86_64 machine q35 (iTCO v2; wdt resets fine)
> >
> > - generic mini pc (iTCO v4, Braswell; wdt resets fine)
> >
>
> Err, we do not support iTCO v4 yet, see the related driver. Do you have
> patches on top?

Sorry - I meant - generic mini pc (iTCO v3, Braswell; wdt resets fine)

I have some WIP patch from the mailing list to enable iTCO v4 but it doesn't
seem to work correctly, I will respond to the previous thread NACKing it.

> >
> >
> > And some machines which do not seem to reset after the wdt has been
> > primed:
> >
> > - Atari VCS (I believe this machine contains an amdfch_wdt, but I didn't
> > verify that as yet; wdt does not reset)
> >
> > - Dell OptiPlex 7000 series mini PC (iTCO v6, Alder Lake-S; wdt does not
> > reset) I also have some other hardware which uses iTCO v6 which also do
> > not
> > seem to reset.
> >
>
> There might be an issue with clearing the no-reboot flag on the
> particular device. As its name says, that flag prevent any actual reboot
> if the timer expires. You should cross-check if Linux works fine and
> then dig deeper what exactly that driver does to ensure this.

Thanks, I will test Linux as a next step and report back.

> >
> >
> > Do you have any recommendations on how to debug/fix these issues? It'd be
> > great to get this fixed before the next efibootguard release. If someone
> > can
> > also verify my claims, it'd be great.
> >
> >
> > ftr: I also think it'd probably make sense to redo my testing above, with
> > an
> > UEFI shell as a target, just in case some watchdog driver really was
> > feeding
> > the hardware.
> >
>
> BTW, you should be able to simulate a handing kernel fairly easily now
> by setting --with-boot-delay during configure to a value above the
> configured EBG timeout.

That's a useful suggestion, keeping everything self-contained.


Thanks!

[Jan Kiszka]

Any news on this?

[Jan Kiszka]

Second ping. Given all the fixes in master, I would like to release this
week.

[Christopher Obbard]

Hi Jan,

I will look at this on the hardware this afternoon/tomorrow and report back. I
was on leave for some of last week and didn't get to it before then.


Thanks!

[Christopher Obbard]

Hi Jan,

I managed to test efibootguard's iTCO V6 driver again with latest next branch
and have not yet found the root cause.

The same symptoms happen on two separate chipsets;
- Kontron COMe-mEL10 (E2) SOM containing Elkhart Lake chipset.
- Dell OptiPlex 7000 containing Alder Lake-S chipset.
- Dell OptiPlex E4 containing Alder Lake-S chipset.

I've tested two cases:
- Setting efibootguard boot delay set to 60s, with watchdog set to 30s.
- Setting efibootguard boot delay set to 5s, with watchdog set to 30s.

Both cases end up with the watchdog timer not resetting.

I then started the watchdog in Linux, and the watchdog doesn't reset there
either!

Everything above seems to work fine in qemu (and the Intel Braswell box). Any
hints on what to try next ?

I don't think this should block the release, since Linux also seems to suffer
from the same issue.



Thanks,

Chris

[Jan Kiszka]

OK, then this might be a topic for the respective vendors.

>
> Everything above seems to work fine in qemu (and the Intel Braswell box). Any
> hints on what to try next ?

Check that there is no WDAT description (or related BIOS option) on
these boards. That would take precedence if Linux has the feature
enabled - does it?

>
> I don't think this should block the release, since Linux also seems to suffer
> from the same issue.
>

Ack, I will move forward now.

Thanks,

[Christopher Obbard]

Hi Jan,

For my testing, I've been using linux 6.6.32 with CONFIG_WDAT_WDT disabled.

I have checked the NO_REBOOT flag in efibootguard (both before and after it is
cleared), the bit is originally set to 0 which means that the hardware strap
is not high (TCO1_CNT_REG reads as 0x1800 on both devices).

I'll continue poking at this, in the meantime is there any chance you could
test iTCO v6 on your side to see if there is any regression ?

> >
> > Everything above seems to work fine in qemu (and the Intel Braswell box).
> > Any
> > hints on what to try next ?
>
> Check that there is no WDAT description (or related BIOS option) on
> these boards. That would take precedence if Linux has the feature
> enabled - does it?

Yeah - I checked that WDAT is disabled.



Thanks,

Chris

[Jan Kiszka]

And that could be a problem if WDAT is actually working (and differently
operated than iTCO "native"). Standard Linux would then use WDAT and
skip iTCO, and if the former worked, all would be fine.

> I have checked the NO_REBOOT flag in efibootguard (both before and after it is
> cleared), the bit is originally set to 0 which means that the hardware strap
> is not high (TCO1_CNT_REG reads as 0x1800 on both devices).
>
> I'll continue poking at this, in the meantime is there any chance you could
> test iTCO v6 on your side to see if there is any regression ?
>

I need to dig out something, probably some EHL device.

>
>>>
>>> Everything above seems to work fine in qemu (and the Intel Braswell box).
>>> Any
>>> hints on what to try next ?
>>
>> Check that there is no WDAT description (or related BIOS option) on
>> these boards. That would take precedence if Linux has the feature
>> enabled - does it?
>
> Yeah - I checked that WDAT is disabled.
>

What does "disabled" now mean? In Linux or in the firmware (ACPI)?

[Sjoerd Simons]

Hey all,

On Fri, 2024-06-28 at 13:00 +0100, 'Christopher Obbard' via EFI Boot
Guard wrote:
> Hi Jan,
>

> On Thu, 2024-06-27 at 11:26 +0200, 'Jan Kiszka' via EFI Boot Guard
> wrote:
> > On 26.06.24 23:35, Christopher Obbard wrote:
> > >
> > > The same symptoms happen on two separate chipsets;
> > > - Kontron COMe-mEL10 (E2) SOM containing Elkhart Lake chipset.
> > > - Dell OptiPlex 7000 containing Alder Lake-S chipset.
> > > - Dell OptiPlex E4 containing Alder Lake-S chipset.
> > >
> > > I've tested two cases:
> > > - Setting efibootguard boot delay set to 60s, with watchdog set
> > > to 30s.
> > > - Setting efibootguard boot delay set to 5s, with watchdog set to
> > > 30s.
> > >
> > > Both cases end up with the watchdog timer not resetting.
> > >
> > > I then started the watchdog in Linux, and the watchdog doesn't
> > > reset there
> > > either!
> >
> > OK, then this might be a topic for the respective vendors.

Picking this up after the big summer holidays slump; 

It turns out that on the Kontron board configuring the watchdog as an
"acpi watchdog" makes it work correctly (as a wdat dog rather then
itco)

For the Dell machines, it seems it's an option that has to configured
when ordering the box (!?!). We're trying to find out if there is some
way to get it enabled afterwards (it's not a bios setting) or if the
only option is to get replacement machines.

In both cases it's a rather annoying error condition though as
everything seems to work as expected.. It just turns out the iTCO dogs
don't actually have any teeth :/

So clearly not something to be fixed in efibootguard (As i don't think
it can check for the watchdogs being functional rather then just
existing). Just fun with vendors..


--
Sjoerd Simons
Collabora

[Jan Kiszka]

Hehe, I feel your pain. Thanks for resolving the issue for everyone.