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 X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDEEEC07E99 for ; Sat, 3 Jul 2021 21:42:53 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 09C2C613E2 for ; Sat, 3 Jul 2021 21:42:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 09C2C613E2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gerhold.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 03957829F9; Sat, 3 Jul 2021 23:42:51 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=gerhold.net Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gerhold.net header.i=@gerhold.net header.b="OjF+pGIr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2585E82A15; Sat, 3 Jul 2021 23:42:49 +0200 (CEST) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.163]) (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 7781B829E2 for ; Sat, 3 Jul 2021 23:42:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=gerhold.net Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=stephan@gerhold.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625348565; s=strato-dkim-0002; d=gerhold.net; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date:Cc:Date: From:Subject:Sender; bh=d3q1JQ7Tm8XggzmhAkavfCfWU/V6i5sbgTGJifWUtNA=; b=OjF+pGIrsvi1T18KOXPkHbdDyxCov06Bl0wK2UniIitDaKgJDCAgj4IPXWi43Af/Oy 6rOD0ORcDi/fZ2Dl2PZuyWfxHs7lmc9G3j5CQ9sZ1QZb0Dg6cEFRJAm8TlkyCC9lR80S fT2ga9LkUhtWdXp39UtTzyOJusHC/do+29gNOwfDX9PtTbNhqf686N1J41M+NXC+VuaY vajXStAlf1NiP6ziXpOYANgTESeH5WDs+MX65WTco9N6nG2bMpTn1Fle1XYDDW3g6qJO v3hrXVHZEfXf6XSjYsNgu15cSU+32pc8MnLXcCJ9Pa5PbWV7bUVPYhl67KWb3NKpMhh2 SNfw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P3gBZUipdd93FF5ZZvYFPugejmSTVR2nRPhVOQ/OcYgojyw4j34+u26zEodhPgRDZ8f4IczEa4o=" X-RZG-CLASS-ID: mo00 Received: from gerhold.net by smtp.strato.de (RZmta 47.28.1 DYNA|AUTH) with ESMTPSA id Y070ccx63LgiJ0A (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sat, 3 Jul 2021 23:42:44 +0200 (CEST) Date: Sat, 3 Jul 2021 23:42:34 +0200 From: Stephan Gerhold To: u-boot@lists.denx.de, Ramon Fried Cc: Jorge Ramirez-Ortiz , Nicolas Dechesne Subject: Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean On Thu, Jul 01, 2021 at 11:07:55AM +0200, Stephan Gerhold wrote: > Hi! > > at the moment the U-Boot ports for both DragonBoard 410c and 820c are > designed to be loaded as an Android boot image after Qualcomm's LK > bootloader. This is simple to set up but LK is redundant in this case, > since everything done by LK can be also done directly by U-Boot. > > Dropping LK entirely would have at least the following advantages: > - Easier installation/board code (no need for Android boot images) > - (Slightly) faster boot > - Boot directly in 64-bit without a round trip to 32-bit for LK > > [...] > > 3. Remaining open questions > =========================== > > [...] > > 3. CONFIG_OF_EMBED: There is a big warning about this in the build log: > "This option should only be used for debugging purposes. Please use > CONFIG_OF_SEPARATE for boards in mainline." > > The important part here is that we need an ELF image with both > U-Boot and the DTB. CONFIG_OF_EMBED is convenient for that because > we can just use the ELF image built by the linker and it already > contains the DTB. > > If CONFIG_OF_EMBED is really so bad it might be possible to build > a new boot image based on "u-boot-dtb.bin" (which is U-Boot with > DTB appended). I'm not sure if this is really much better though. > After looking some more I found "CONFIG_REMAKE_ELF" which seems to do exactly this (build a new ELF image based on "u-boot-dtb.bin" with appended DTB). So this avoids setting CONFIG_OF_EMBED and therefore the build warning. Sounds like the solution I was looking for. :) Unfortunately it looks like appending the DTB to U-Boot currently produces very strange behavior on DragonBoard 410c. It's either: - Working fine, or - Rebooting continously without serial output from U-Boot, or - The following serial output: Qualcomm-DragonBoard 410C DRAM: 986 MiB No serial driver found resetting ... It behaves consistently given a U-Boot binary but varies when adding/removing random features from the U-Boot binary. After a couple of hours of debugging, I realized that the appended DTB becomes corrupted. Specifically, there is a "GPIO_5" written into it, e.g. 8f6905b8: edfe0dd0 9f100000 4f495047 c000355f ........GPIO_5.. 8f6905c8: 28000000 11000000 10000000 00000000 ...(............ 8f6905d8: df010000 880e0000 00000000 00000000 ................ 8f6905e8: 00000000 00000000 01000000 00000000 ................ 8f6905f8: 03000000 04000000 00000000 02000000 ................ 8f690608: 03000000 04000000 0f000000 02000000 ................ 8f690618: 03000000 2d000000 1b000000 6c617551 .......-....Qual 8f690628: 6d6d6f63 63655420 6c6f6e68 6569676f comm Technologie Depending on enabled features in U-Boot the "GPIO_5" corrupts different parts of the DTB, that's why it works somewhat sometimes. After staring at some drivers and the U-Boot linker script for a while I realized that the BSS section overlaps with the appended DTB before relocation. And indeed, mach-snapdragon/pinctrl-apq8016.c writes "GPIO_5" into "static char pin_name[MAX_PIN_NAME_LEN];" (= BSS) before relocation. Actually, arch/arm/lib/crt0_64.S says that BSS should not be used at all before relocation, because it's uninitialized and might corrupt other memory. I found several other commits where similar problems happened and it was usually fixed by moving the variables into the data section. So, I fixed the problem with the diff below and will include it together with the changes to drop all the LK-related code. Now everything seems fine. (I just wish this would have somehow been more obvious instead of the strange behavior...) Stephan diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c b/arch/arm/mach-snapdragon/pinctrl-apq8016.c index 1042b564c3..7940c74287 100644 --- a/arch/arm/mach-snapdragon/pinctrl-apq8016.c +++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c @@ -10,7 +10,7 @@ #include #define MAX_PIN_NAME_LEN 32 -static char pin_name[MAX_PIN_NAME_LEN]; +static char pin_name[MAX_PIN_NAME_LEN] __section(".data"); static const char * const msm_pinctrl_pins[] = { "SDC1_CLK", "SDC1_CMD",