Am Mon, 12 Jul 2021 22:05:50 +0200 schrieb Henning Schild <[email protected]>:
> Am Mon, 12 Jul 2021 16:33:15 +0200 > schrieb Jan Kiszka <[email protected]>: > > > On 12.07.21 16:19, Cedric Hombourger wrote: > > > > > > On 7/12/2021 3:57 PM, Jan Kiszka wrote: > > >> On 12.07.21 15:37, Cedric Hombourger wrote: > > >>> SIMATIC IPCs 227E/277E share the same external watchdog > > >>> (SCH5347) than the IPC 4x7Es we already support. Initialization > > >>> of the SAFE_EN_N line differs a bit and was therefore moved to > > >>> separate setup functions. Programming and enabling of the > > >>> timeout is the same and is now handled in set_timeout(). With > > >>> this change, both Linux and efibootguard would use the same > > >>> chip and no longer depend on the built-in iTCO watchdog. > > >> The 4x7E had a hard requirement to use platform watchdog rather > > >> than iTCO - because the latter was unable to actually reset the > > >> device. This limitation does not exist on the 2x7E series. Your > > >> commit message is lacking a reasoning why a user should use that > > >> special watchdog, rather than the working and widely supported > > >> iTCO? > > > > > > Well I do not have a reason other than the Simatic IPC team > > > "insisting" on us using the external one via their simatic-ipc-wdt > > > driver. We have indeed found both watchdogs to be working just > > > fine. However having efibootguard initializing the built-in > > > watchdog (iTCO) and Linux blacklisting iTCO and using > > > simatic-ipc-wdt (as instructed) is simply asking for troubles > > > (IMO). > > > > That is true - but also not the problem of EBG but rather of the > > Linux configuration (no need to prioritize the platform watchdog > > there as well). > > I would turn that around. The HW does have two watchdogs and both > might be armed once Linux takes over, so it needs drivers to do so. > How to model that in userland would be another fun-question, but > watchdogd and systemd support multiple watchdogs. > > > > > > > If you believe we can push back and use the iTCO across the board, > > > I am all for it and both of us could talk to Florian S and maybe > > > have his team update the simatic-ipc-lsp documentation to make it > > > clear that the iTCO driver may safely be used on 227E (as we both > > > found) > > > > > > Let me know if you have other ideas or suggestions > > > > Already ping'ed Henning on this internally, now here as well, as he > > is managing the IPC driver upstreaming. We have to tell the Linux > > community the same story like here. If there is a technical reason > > to favor platform over standard, we share that in EBG, obviously. > > I think the second watchdog is somehow more powerful. Our Industy PCs > have an nvram (not yet proposed upstream) and an interrupt (power > going to fail in 10ms - also not yet proposed upstream). The > combination can make a feature to sync (fast ... 10ms) while > off-power. But the whole story ... watchdog-wise ... only works with > our watchdog. > > I am not sure if/when we will be able to put all the pieces together > in the kernel. But the main story seems to be ... there is another > watchdog and we rather have a driver for it ... if just in case a > bootloader or the BIOS armed it and we need to drive/disable it. But as long as Linux can not drive or disable that Siemens watchdog, any bootloader it probably better off arming the iTCO. Because that is known to work and can be taken over by any kernel that supports it. A bootloader arming a watchdog that is not Linux-upstream is asking for reboot-loops. Henning > Henning > > > Jan > > > -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/20210712221244.6f56b2d6%40md1za8fc.ad001.siemens.net.
