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 5967BC636CC for ; Tue, 7 Feb 2023 15:09:12 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1940C85860; Tue, 7 Feb 2023 16:09:10 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.com 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; unprotected) header.d=canonical.com header.i=@canonical.com header.b="gaH1Posk"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 08FD08573B; Tue, 7 Feb 2023 16:09:08 +0100 (CET) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) (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 1295D85865 for ; Tue, 7 Feb 2023 16:09:03 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=heinrich.schuchardt@canonical.com Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (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 smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 7716641AAF for ; Tue, 7 Feb 2023 15:09:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1675782540; bh=6q1xXaIrcYxpJgJeA8DNGtvIOVf4m9FuRe0nWdXhJWE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gaH1PoskJgjYgH1rqv6nQhlAw7xOrjGobwjGc0smO+aY5gdrbD0JR69S5G/X01qu0 0/fy920J8pruSXYTB3uQG2vTEo3R+PVb+Xfo2N3sZ7gpUHdvtPLSrjVhHZWH0uZlJ+ dJlvkD2x8KnjCrizhoimTZecZCKjJ55Fw0iQLT01AuAHcLs2Xm1WeFNvkO0DS/2qor IPnDmroyFD42hCuC45DSLOSs3qR19Wg8BLSWUhkaPtN5KBqYT6NOY/GmTURzpGmtTo 2ekCuXDppiGPn7pYJBkmcV016Y+niloIm873J8JXt1VG7oUyEStzVngLeYFeWS1hXz IN91WU0ahdtFw== Received: by mail-wm1-f72.google.com with SMTP id ay19-20020a05600c1e1300b003dc54daba42so7347570wmb.7 for ; Tue, 07 Feb 2023 07:09:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6q1xXaIrcYxpJgJeA8DNGtvIOVf4m9FuRe0nWdXhJWE=; b=LNP6ZNnbp7aDHhYyWVlyHopfYKdl6fBq4HAei6s+Zsbs12MHQEXGAdFzOyRKRqwwKw GZZrz+P4XuJ9R7XmFTZ6eZe0h4LQ3mrBlgdY16YuxdLT1hzmizO7iDOmmt6x4gY0Wmqb j3kmKWNc6LIWUIELMl/B3T/A+q9gGJAjq+SOkGkaCNKoZV0qAwwMxx/9R65ytdRq7NCd AyjzdnCE6BBH6JaDvJs5WgfkkF9LVn5xlJ6m9zQtTrUB1EI8ahzk/njmfW15JbROuG3B EGjEK43y3+hsDfUlkJwZ0HqaCD1lEZfdR40to82yekxVBXoBBJDgVyVxE1ErsFLL5mRy aTxA== X-Gm-Message-State: AO0yUKUcD5KirW9KooLjRHcc9nKmcrKNbYTA8wHIxnu+i4+m1V9eDULe TZDHAFb1f5xNertK3J0cCNFNFsuyQLGgo5uiiYFdlTagsyASjjviAzi0x9KSsQX2C8cBGcykPgI SaLiJbOCpSTXaOoRHR36Zn5ii2uyT/jw= X-Received: by 2002:a05:6000:188d:b0:2c3:be89:7c36 with SMTP id a13-20020a056000188d00b002c3be897c36mr15591768wri.25.1675782540045; Tue, 07 Feb 2023 07:09:00 -0800 (PST) X-Google-Smtp-Source: AK7set9fnUj5UDhD22ajyryuxdPc8gKADcw9LEP2rMm2NB5ESu4j9j+ymmZuKgFmS25kZdBhyuKTJQ== X-Received: by 2002:a05:6000:188d:b0:2c3:be89:7c36 with SMTP id a13-20020a056000188d00b002c3be897c36mr15591744wri.25.1675782539767; Tue, 07 Feb 2023 07:08:59 -0800 (PST) Received: from [192.168.123.67] (ip-088-152-145-137.um26.pools.vodafone-ip.de. [88.152.145.137]) by smtp.gmail.com with ESMTPSA id v7-20020adfebc7000000b002bc7e5a1171sm11647305wrn.116.2023.02.07.07.08.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Feb 2023 07:08:59 -0800 (PST) Message-ID: Date: Tue, 7 Feb 2023 16:08:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 1/1] efi_loader: stop watchdogs in ExitBootServices() Content-Language: en-US To: Michael Walle 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 References: <22478c7f-ffa0-0bf7-5473-0ba1ee7478c3@prevas.dk> <20230207145955.2468379-1-michael@walle.cc> From: Heinrich Schuchardt In-Reply-To: <20230207145955.2468379-1-michael@walle.cc> Content-Type: text/plain; charset=UTF-8; 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 On 2/7/23 15:59, Michael Walle wrote: >>>> 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. Best regards Heinrich