From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2138CC636CD for ; Tue, 7 Feb 2023 15:00:15 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6A78B85DF1; Tue, 7 Feb 2023 16:00:11 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; secure) header.d=walle.cc header.i=@walle.cc header.b="RuXYk/v1"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A181D85DAF; Tue, 7 Feb 2023 16:00:08 +0100 (CET) Received: from mail.3ffe.de (0001.3ffe.de [159.69.201.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A44C38595F for ; Tue, 7 Feb 2023 16:00:05 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from mwalle01.kontron.local. (unknown [213.135.10.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 1A86187; Tue, 7 Feb 2023 16:00:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1675782005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zvXRQjh/NWwW742+c8vREViaUfg3zWdzU46vlwihMaQ=; b=RuXYk/v1udcfN/qFV5sGP9t/dW9hh1t8RyivggM5M2TI+r+5AmS0LcE4VVesPE+coo2A5u 7uCRXmapWuT2rFWnWFdEtbgmbbTBMDKCvNlmG6Pn5TigDw8n9r8iquQxvsZAqjru6WMug8 Fu4KkXy8xHYX+qDxB1BAhyRwFIleDrJ356qBKGtfbMjzAkhAe5/OcE+uxPwYw27NxanSrq BsoJ9AqTha2sPYsgr1iEmIt7Xdua9v4D9oLhA6KPdII5oO3t9D5pp1lPRZwG2Q7mHNT0Wv OI39NJoLKTNQbKaRj/h51HcZ0NbCAoW896SSu6L6RS93kI3+nuq3GklkmscKEQ== From: Michael Walle To: rasmus.villemoes@prevas.dk Cc: andre.przywara@arm.com, etienne.carriere@linaro.org, heinrich.schuchardt@canonical.com, ilias.apalodimas@linaro.org, sjg@chromium.org, trini@konsulko.com, u-boot@lists.denx.de, Michael Walle Subject: Re: [PATCH 1/1] efi_loader: stop watchdogs in ExitBootServices() Date: Tue, 7 Feb 2023 15:59:55 +0100 Message-Id: <20230207145955.2468379-1-michael@walle.cc> X-Mailer: git-send-email 2.30.2 In-Reply-To: <22478c7f-ffa0-0bf7-5473-0ba1ee7478c3@prevas.dk> References: <22478c7f-ffa0-0bf7-5473-0ba1ee7478c3@prevas.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean >>> Honestly, not really? Some good number of SoCs will start the watchdog >>> in ROM and these are also the ones that don't allow you to turn it off. >> >> I hope not, that sounds really risky. How would you debug such a platform? > > _Every single_ custom piece of industrial (as opposed to consumer-grade) > hardware I've worked on as a consultant has had an external, > always-running, gpio-petted watchdog. It's simply just something that > the hardware designers include, and in some cases that's even due to > certification requirements. So an always-running, cannot-be-turned-off, > watchdog is a real thing, in real hardware, and if specs don't account > for that, well, the spec is just paper, and we can ignore it. I agree. But on the other hand, you cannot assume or force the OS to have a watchdog driver in the general case - which is as I understand it - one goal of EFI. Obviously, there are watchdogs that can be disabled and some which cannot. I don't want to argue about the advantages and disadvantages. For watchdogs which cannot be turned off, we can't really do anything anyway after the handoff to the OS - except increasing its timeout if thats possible. For watchdogs that can be disabled (and are enabled in u-boot of course), there seems to be two use-cases: (1) embedded EFI boot, that is you know exactly what you are booting, i.e. self compiled kernel with a watchdog driver (2) booting a general OS via EFI, think of a debian boot CD for example. I agree, that for (1) the watchdog shouldn't be disabled. For (2) you cannot assume the booting OS has a driver for the watchdog, let it be an older version of a distribution which just haven't the SoC watchdog driver enabled or maybe because there is no driver for it at all (yet). Is there a way, to have the watchdog disabled for case (2) while also having the possibity to use bootm/booti/bootz and keep the watchdog enabled? Basically I want the following: (1) board boots with watchdog enabled (2) u-boot services watchdog (3a) booting embedded linux with booti (watchdog enabled) or (3b) booting generic OS with bootefi (watchdog disabled) The missing case is booting an embedded linux with bootefi, which would be nice to have. But I don't really see it as a use-case for our board. -michael