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 BE1C0C4332F for ; Tue, 20 Dec 2022 08:08:06 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 27E3185177; Tue, 20 Dec 2022 09:08:04 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org 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=kernel.org header.i=@kernel.org header.b="BQKtPBty"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 89DAA85174; Tue, 20 Dec 2022 09:08:01 +0100 (CET) Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 804CC8431A for ; Tue, 20 Dec 2022 09:07:58 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 221E3B80B4A; Tue, 20 Dec 2022 08:07:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97DA9C433EF; Tue, 20 Dec 2022 08:07:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671523676; bh=dalEp8UyAXSlJSopXmngodP17X+GiBSOIehjeGl55lQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BQKtPBtyInmr+1s19uXgF/BxNPWNV2vChFOf0cnNOzJV9mo1X5gRyRNrwn+UZVp43 yuHB2hIO5wv+f+DYzPy+9ErZlTZyoGo1l0tagsGe2yN4e+trmbaw9aG9yix1NXrHLu F+7OBgPUH4M71Ny1f5DQ9kSH/J8EeF5ArInzdHpFxpO+AoRM8JDeOSCL4NeQ9Dws0m 6iKMTThp74ETzAqC4W3jVXqkmNl42Wgov17ei0vs76tp7r3LptZo+155jbfaWdE3om vmFZ631P8WGLrKfiuV6WUcNua77eGp57gr3kmOuu3tJ7rKNyW4su4oC5yMUgW+jsRb +bpy6A1/IvLZg== Received: by pali.im (Postfix) id 9A660963; Tue, 20 Dec 2022 09:07:53 +0100 (CET) Date: Tue, 20 Dec 2022 09:07:53 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Stefan Roese Cc: Tony Dinh , Michael Walle , sjg@chromium.org, u-boot@lists.denx.de Subject: Re: Converting to DM SERIAL for Kirkwood boards Message-ID: <20221220080753.5bchy5ygv7lyroo7@pali> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4b5d5a78-714d-5260-339b-c34ddcb00b5d@denx.de> User-Agent: NeoMutt/20180716 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 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).