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 30EA9C4332F for ; Wed, 21 Dec 2022 09:29:42 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A15B285403; Wed, 21 Dec 2022 10:29:39 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1671614980; bh=vydxlWJsWRyajKuCYuiCB6YIjSq5SL76aqlGVuMi/4g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Q+BK61Tdfn6XiXkkqcvztOTot3GqpHnNHXoJTBbhiESVpLqpVp30/iiZO9hVcU5G2 7NnVM4S8wvurT5btjl8VQSqgOB5v9VercvVNwaDbsR8gu0HJRNoHyAQ3T4n4WE+1wf azucDoQpMK1IvyYEP+K30Oh2xSB//S+aoakvzJJeEPtYG9nacoAqp7pRsidXfnxYOb 6vVWvTFE43m0DdR843XqEYBby4QSu0m4IBgUYn3cggev7tH6bwdrs3RKcB/cpertty gqdob8TLXcWp7Cgy5pg5/WpnSVgYnFg7hK8MyF74XErxkJm/0gzRyZShxZzrQFOKl3 Nea96NYEkP72g== Received: by phobos.denx.de (Postfix, from userid 109) id 683FF8540C; Wed, 21 Dec 2022 10:29:38 +0100 (CET) Received: from mout-u-107.mailbox.org (mout-u-107.mailbox.org [80.241.59.207]) (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 E118A85335 for ; Wed, 21 Dec 2022 10:29:34 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=sr@denx.de Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-107.mailbox.org (Postfix) with ESMTPS id 4NcSnm3lfZz9sQb; Wed, 21 Dec 2022 10:29:32 +0100 (CET) Message-ID: Date: Wed, 21 Dec 2022 10:29:31 +0100 MIME-Version: 1.0 Subject: Re: Converting to DM SERIAL for Kirkwood boards To: =?UTF-8?Q?Pali_Roh=c3=a1r?= Cc: Tony Dinh , Michael Walle , sjg@chromium.org, u-boot@lists.denx.de References: <20221216075648.okampph2agvtqmaa@pali> <9a008549-1df0-69cb-b980-8bed84c4ae7a@denx.de> <1207b130-15dd-916e-92d8-b654a139e694@denx.de> <4b5d5a78-714d-5260-339b-c34ddcb00b5d@denx.de> <20221220080753.5bchy5ygv7lyroo7@pali> Content-Language: en-US From: Stefan Roese In-Reply-To: <20221220080753.5bchy5ygv7lyroo7@pali> Content-Type: text/plain; charset=UTF-8; format=flowed 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 Hi Pali, On 12/20/22 09:07, Pali Rohár wrote: > On Tuesday 20 December 2022 07:20:15 Stefan Roese wrote: >> Hi Tony, >> >> On 12/20/22 02:36, Tony Dinh wrote: >>> Hi Stefan, >>> >>> On Mon, Dec 19, 2022 at 4:06 PM Tony Dinh wrote: >>>> >>>> Hi Stefan, >>>> >>>> On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh wrote: >>>>> >>>>> Hi Stefan, >>>>> >>>>> On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese wrote: >>>>>> >>>>>> Hi Tony, >>>>>> >>>>>> On 12/19/22 07:17, Stefan Roese wrote: >>>>>> >>>>>> >>>>>> >>>>>>>> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 >>>>>>>> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for >>>>>>>> programming LD0 and LD1 eFuse >>>>>>>> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once >>>>>>>> >>>>>>>> This is where the Pogo V4 was frozen during boot. Among the Kirkwood >>>>>>>> boards that I have and used for testing, it is the only one that has >>>>>>>> CONFIG_BOOTSTAGE=y. >>>>>>> >>>>>>> Thanks for testing and git bi-secting. >>>>>>> >>>>>>>> Should I create a new post for would like to continue this topic here >>>>>>>> in this thread? >>>>>>> >>>>>>> Let me check, if I can find the root cause and this problem quickly. If >>>>>>> not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for >>>>>>> a short while until we've fixed this issue. >>>>>> >>>>>> I fail to spot the problem with this small commit 37bb396669b27a. I can >>>>>> also not reproduce this on my Armada XP board - it uses SPL though, this >>>>>> might make a difference. >>>>>> >>>>>> Could you perhaps apply this attached debug patch and make sure, that >>>>>> you have DEBUG_UART enabled in your Pogo v4 config. And boot into the >>>>>> resulting image. >>>>> >>>>> Here is the kwboot log with DEBUG_UART. Note that number 322322 below >>>>> is part of the log. >>>>> >>>>> 322322 >>>>> >>>>> U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) >>>>> Pogoplug V4 >>>>> >>>>> SoC: Kirkwood 88F6281_A1 >>>>> Model: Cloud Engines PogoPlug Series 4 >>>>> DRAM: 128 MiB >>>>> 322322322Core: 19 devices, 15 uclasses, devicetree: separate >>>>> NAND: 4 >>>>> >>>> >>>> Going a bit further with your debug patch, I've added more prints. >>>> >>>> static void orion_timer_init(void *base, enum input_clock_type type) >>>> { >>>> /* Only init the timer once */ >>>> - if (early_init_done) >>>> + if (early_init_done) { >>>> + printch('6'); // test-only >>>> return; >>>> + } >>>> >>>> And the boot log below shows somehow the early_init_done is already >>>> true by the time the orion_timer_init is called. Pretty weird, to say >>>> the least! >>>> >>>> --BEGIN LOG-- >>>> 3262632626 >>>> >>>> U-Boot 2023.01-rc4-dirty (Dec 19 2022 - 15:35:26 -0800) >>>> Pogoplug V4 >>>> >>>> SoC: Kirkwood 88F6281_A1 >>>> Model: Cloud Engines PogoPlug Series 4 >>>> DRAM: 128 MiB >>>> 326263262632626Core: 19 devices, 15 uclasses, devicetree: separate >>>> NAND: 456 >>>> --END LOG-- >>>> >>> >>> I tried this change in drivers/timer/orion-timer.c and it seems to >>> work consistently. >>> >>> -static bool early_init_done __section(".data") = false; >>> +static bool early_init_done = false; >>> >>> I still can't see why it would make a difference. Why does the >>> __section macro not work? does the reallocation timing have anything >>> to do with this variable being of the wrong value? >> >> Hmmm, so we might have a problem with memory being overwritten? You >> should perhaps where the sections (especially data) are located and >> where the stack etc is located. I suggest to also enable DEBUG in >> board_f/c.c to see a bit more of the addresses being used. >> >> Thanks, >> Stefan > > Maybe similar issue as with mbus or atsha? > https://lore.kernel.org/u-boot/20220810124609.5765-1-pali@kernel.org/ > https://lore.kernel.org/u-boot/20220408143015.23163-2-pali@kernel.org/ > > static variables do not work correctly _before_ u-boot relocation. You > should avoid usage global OR static variables in code which may be > called before relocation. And on some boards are all global, static and > bss variables read-only (those which use execute-in-place, e.g. ppc > flash). Thanks for the input. Frankly, I was always a bit hesitant when using early static variables. Also with moving them into the data segment. Even though this seems to work on some platforms AFAICT. I've prepared a patch getting rid of this variable by introducing a function instead. Tested successfully on my Armada XP platform. Tony, could you (and perhaps others as well?) test with this new patch, if everything still works as expected? Thanks, Stefan