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 AFAA3C433EF for ; Wed, 9 Mar 2022 11:38:50 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 829558391E; Wed, 9 Mar 2022 12:38:48 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.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=gmail.com header.i=@gmail.com header.b="QJdv/sx5"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 40A6D83935; Wed, 9 Mar 2022 12:38:46 +0100 (CET) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E6AB383829 for ; Wed, 9 Mar 2022 12:38:40 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=krjdev@gmail.com Received: by mail-ej1-x62d.google.com with SMTP id hw13so4220204ejc.9 for ; Wed, 09 Mar 2022 03:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=HwscrF6F0ijhT+H3+24QUFEPdbdAB7kVbGbyC8vqwEk=; b=QJdv/sx5uiO40oXe0r/iekNKtUuemIRf8WEnd8NVUiNxkx74/V4LlMuvL6EDULU32v xscM56yYUS62FVN0iQbv1IKkD5HNiNJHSaG7gtLwzOoOwdOKjLK1Fcthx5KCpZijnwJz jbfDSNP1l/y9x30xwTvmKxZBH3og9FuYfp3obMIG5k6DjA7pbWy9urR5xfNrevB0HfbU 1qV3mkdXcn8ebqKxi8aHLO5dmP/KcpOmydMzYz7wcdWU4wIdB98WkHSPby107bcuVK40 mQL+nZk3g8C7/VpwHFGn8iwaaf0c/MQgBynNXPsZllMAEdgIXiJq3ahn4eyKgDOkhvLQ KQEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=HwscrF6F0ijhT+H3+24QUFEPdbdAB7kVbGbyC8vqwEk=; b=bMy9emzu4sjjzkzesl22/WSR82IR6sFiVOKFYCdSVMZBFQk3XR9NJgEamFO3daZqlX 3qsiOm2Huq6WJ7SjHymAa0HKrbeJzp1/6P7ujXeoUd4Ho1vK8n60ulgnF3UqWg+X9Dcf 6RvFmGzKvyqQxCp+Vf5kxgxFG9iH8dh49qTis2MUrX3LifCs2uXDwxNvDWnPL8B7iZY2 Ab3jDbgt8b55nLyFPPFwOsI43EUqk0GrRDxUE5JWuh1UvqpHoVhrVNwVKSvwO4l8v4al icIEKRN4X0AlRbitE0ljNLqK1TuAz9u1/rtMv74jQ5IsGT3Cj/U3f1i0m1T4MMSRO8eD HwVw== X-Gm-Message-State: AOAM533Wjau+xBYqtawtoF5AgSs9FFdRAEfSmUuqSw/a58wXoTccQgU6 vCOyn9qn6Jx//rBcTHvDdlzEmVGauAM= X-Google-Smtp-Source: ABdhPJxNirG1glF9vZTE2GbJxZ3SS9SAuoayfA1bEFC8/p2ILIOC/wxpe57Ice054HkYU7EzGheDNA== X-Received: by 2002:a17:906:5cb:b0:6cf:954:d84d with SMTP id t11-20020a17090605cb00b006cf0954d84dmr18159541ejt.560.1646825919733; Wed, 09 Mar 2022 03:38:39 -0800 (PST) Received: from [10.42.42.166] (212-197-176-189.adsl.highway.telekom.at. [212.197.176.189]) by smtp.gmail.com with ESMTPSA id kw5-20020a170907770500b006db075e5358sm629431ejc.66.2022.03.09.03.38.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Mar 2022 03:38:39 -0800 (PST) Message-ID: <7d794b93-6a7f-cdd1-9c73-26ac622f7d27@gmail.com> Date: Wed, 9 Mar 2022 12:38:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: drivers: clk: stm32h7: Endless loop of dead in driver probe function Content-Language: de-DE To: Patrice CHOTARD , Patrick DELAUNAY , u-boot@lists.denx.de, dillon.minfei@gmail.com References: <5affc0c0-f2e8-5dd7-54b1-cb7f30168ed5@foss.st.com> <6bab2e77-3827-dbc0-8592-39da1a51d187@gmail.com> From: "Johannes (krjdev) Krottmayer" In-Reply-To: Content-Type: text/plain; charset=UTF-8 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.5 at phobos.denx.de X-Virus-Status: Clean Hi Patrice! I have bricked my board. LOL. Hope I can recover it, when soldering BOOT0 to VDD. Solder Bridge 192 (SB192). Don't verified the power settings first in the clock driver. The current power configuration clears SCUEN. But on STM32H747, this disables the SMPS converter. Same bit position (SDEN) in PWR_CR3... On 09.03.22 09:08, Patrice CHOTARD wrote: > > > On 3/9/22 09:02, Johannes (krjdev) Krottmayer wrote: >> Hi Patrice! >> >> On 09.03.22 08:43, Patrice CHOTARD wrote: >>> Hi johannes >>> >>> On 3/9/22 08:24, Johannes (krjdev) Krottmayer wrote: >>>> Hi Patrick! >>>> >>>> Sorry, for my late response. :( >>>> >>>> On 08.03.22 10:00, Patrick DELAUNAY wrote:> Yes, the current clock >>>> driver for STM32 MCU is not perfect,> > as the all U-Boot and the >>>> Linux support on STM32 MCU.> >>>>> >>>>> For information, in the other driver based on a other version of RCC for >>>>> STM32 MPU >>>>> >>>>> STM32MP1 = clk_stm32mp1.c, it is correctly managed in >>>>> >>>>> stm32mp1_osc_wait(1, rcc, RCC_OCRDYR, RCC_OCRDYR_HSERDY); >>>>> >>>>> by using readl_poll_timeout() function. >>>>> >>>>> >>>>>> My possible fixes: >>>>>> At a timeout when reading the register and if the timeout is >>>>>> elapsed, print an error message and return with ETIMEDOUT, so >>>>>> the dm manger can call the hang() function. >>>>> >>>>> I agree, it is a correct management: at least indicate this hardware issue >>>>> >>>>> even if the rdy bit can't be stay at 0 in normal use case when HSE is >>>>> >>>>> present.> >>>>> => replace all while() in the RCC clock driver with readl_poll_timeout >>>>> >>>>> >>>>> but to call readl_poll_timeout(), the arch timer need to ready >>>>> >>>>> (timer_init() already called) when RCC clokc driver probe is executed. >>>>> >>>>> >>>>> An issue the I encounters on STM32MP need to be checked in MCU driver: >>>>> >>>>> the timer can't dependant of RCC probe when polling function is used. >>>>> >>>>> >>>>> This issue was solved in STM32MP by using the generic armv7 timer >>>>> >>>>> (only dependant of Cortex core) and call the initialization in >>>>> >>>>> arch/arm/mach-stm32mp/cpu.c: >>>>> >>>>> int arch_cpu_init(void) >>>>> { >>>>> .... >>>>> >>>>>     /* early armv7 timer init: needed for polling */ >>>>>     timer_init(); >>>>> >>>>>     return 0; >>>>> } >>>> >>>> Is there any reason why not use the ARMv7-M SysTick Timer? There >>>> exists an initialization routine in the U-Boot source tree: >>> >>> Simply because when i introduced stm32h7 board, i didn't need it ;-) >>> >>>> >>>> arch/arm/cpu/armv4m/systick-timer.c >>>> >>>> The routines should work for Cortex-M3/M4/M7. >>>> >>>> timer_init() and all required functions for mdelay() which are will >>>> be called by the polling functions are implemented. >>>> >>>> Don't looked into other TRM's, other than for STM32H745/STM32H747 and >>>> STM32H755/STM32H757 yet, but according the TRM, the SysTick timer for >>>> the core Cortex-M7 should run at 8MHz, after reset: >>>> >>>> - HSI should be selected as system clock (sys_ck), running at 64MHz >>>> - Domain 1 prescaler (D1CPRE) with scale 1 >>>> - SysTick timer at default configuration (external source) which >>>> has a fixed prescale from 8, according the block schematic in >>>> TRM. >>>> >>>> Correct me please, if I'm wrong. >>>> >>>>> The timer management on MCU need to be check before any patch. >>>> >>>> Yes, but I can currently only test the correct behavior on a >>>> STM32H747I-DISCO board. Currently creating the device-tree for >>>> the SoC. >>>> >>>>> Can you propose something ? >>>> >>>> I would use the SysTick Timer on the other devices from the STM32H7 >>>> series too, so I would change the current code. >>>> >>>> Before I release a patch series here in the official mailing list, >>>> I would suggest, if some other developers or users can verify my >>>> modification on their real hardware. >>>> >>>> My GitHub repo: >>>> https://github.com/krjdev/stm32_u-boot >>>> (branch stm32h747_disco) >>>> >>>> That I can offer. :) >>> >>> I have a stm21h7xxi-disco (MB1248) i can give it a try this week. >>> I will keep you in touch. >> >> Please can you give me some additional time for this? The device-tree >> needs some fixes. Missing clocks and resets for the required driver. >> >> I will create a git tag, when I'm ready and I have tested to run >> U-Boot on my board. :) >> >> Working since sunday on the device-trees...Maybe tommorrow. :) > > No problem, i will wait your green light :-D > > Patrice > >> >>> Thanks >>> Patrice >>> >>>> >>>> Kind regards, >>>> >>>> Johannes >> >> Kind regards >> >> Johannes