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 CFB40C636CD for ; Tue, 7 Feb 2023 15:29:22 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8006585E17; Tue, 7 Feb 2023 16:29:16 +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="lNjdrJ+e"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E05C285DF7; Tue, 7 Feb 2023 16:29:05 +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 9AE6885DFC for ; Tue, 7 Feb 2023 16:29:02 +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 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (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 2B377135F; Tue, 7 Feb 2023 16:29:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1675783742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aphOcqg5hCa15zUWWTQQL2QJjDgOvDOc1Svm8gsarvc=; b=lNjdrJ+epNa0z7HRrwaVjnYzEKS+98Kb3pUb9H2bgdtnut8Ft8833VWRYboQFhnt3kuioQ hkYEDBb2r+dqIUiUNcCRYLTEPB3qoauWXUU2mQi1s1ueIa8pns1fvIP52pxve4vCbcU0rL 0aH/mdDYloRJZ18nzbHI6NjmK0cCr4TJwGeTO66U1zuciPuyMrNm3bI4c8JdyVFZvvYj7o +gM7HXIkxUZJWz/NiDTt2z6vt5JJe1yFFioYIKc+33tbcbY85MTt59gE07DF6Lr6sWqCn4 SKKfQADnK57n2/HZSfo76ZXm1Yz3nHu6TOdCZYVLTH/Mnc4s/7AmW8uYJjpdYg== MIME-Version: 1.0 Date: Tue, 07 Feb 2023 16:29:01 +0100 From: Michael Walle To: Heinrich Schuchardt Cc: andre.przywara@arm.com, etienne.carriere@linaro.org, ilias.apalodimas@linaro.org, sjg@chromium.org, trini@konsulko.com, u-boot@lists.denx.de, rasmus.villemoes@prevas.dk Subject: Re: [PATCH 1/1] efi_loader: stop watchdogs in ExitBootServices() In-Reply-To: References: <22478c7f-ffa0-0bf7-5473-0ba1ee7478c3@prevas.dk> <20230207145955.2468379-1-michael@walle.cc> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <1cda1ca157aae7210f93bea7e9c3f3a1@walle.cc> X-Sender: michael@walle.cc Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit 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 > > For SUNXI boards disabling CONFIG_WATCHDOG_AUTOSTART solved the > problem with the very short maximum expiration time of the watchdog. I can't follow you here. What "very short maximum expiration time"? With CONFIG_WATCHDOG_AUTOSTART disabled, the watchdog won't be kicked by u-boot, right? wdt->running will never be set to true and wdt_cyclic() will be a noop. -michael