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. 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. > > 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] 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/61c240af-e485-1f20-2383-9b2d723d56c4%40siemens.com.
