On 13.07.21 16:33, Henning Schild wrote: > Am Mon, 12 Jul 2021 22:47:05 +0200 > schrieb Jan Kiszka <[email protected]>: > >> On 12.07.21 22:05, Henning Schild wrote: >>> 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. >>> >> >> Fair enough for Linux. Here we are in control, though. >> >>>>> >>>>> 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. >> >> How does the watchdog relate to any of those mentioned features? >> Conceptually, they are unrelated - unless there are hardware-induced >> internal dependencies. > > I would guess that when the iTCO cuts power, no power loss interrupt > will be sent. If the power really fails or if the Siemens watchdogs > cuts power ... you would get one such interrupt. > >> Just looking at the platform watchdog functionality, I don't spot any >> advantage over the iTCO. It lacks just like the latter no-way-out e.g. > > We should ask our guys in the next call. I am just guessing here as > well. > >>> >>> 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. >> >> As I said, here we are in control and need to decide which one to >> start. EBG only supports one watchdog, thus needs to pick the best >> one for a given device. On the 4x7E, the decision was simple because >> it was between working and non-working. Here we have two times >> working, and I would actually go for "standard first", specifically >> as long as there is no upstream support for the platform watchdog. >> >> [just reading your second reply, we are on the same page with this] > > Yes, take the iTCO and maybe switch if we ever find out why the other > one could be better. Even if the other one is better because it > supports the "power loss interrupt" ... Linux could use both or > transition from iTCO to Siemens in case it supports Siemens and wants > that interrupt or whatever else that Siemens watchdog would be better > at. >
OK, let's clarify the functionality without colleagues. If it turns out to be valuable, we would still need some control over which watchdog EBG selects in the end in order to support setups where the booted OS does not have support for the platform watchdog. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux -- 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/e2e669d6-7a0c-c710-61e1-6f272f537afb%40siemens.com.
