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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 0805EC07E95 for ; Sun, 4 Jul 2021 11:14:42 +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 A1E5661361 for ; Sun, 4 Jul 2021 11:14:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A1E5661361 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 90A6282B66; Sun, 4 Jul 2021 13:14:38 +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="Fw+6bUOe"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4D8F982BAA; Sun, 4 Jul 2021 13:14:36 +0200 (CEST) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.21]) (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 5A30B82B4E for ; Sun, 4 Jul 2021 13:14:33 +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=1625397272; 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=WcFGSeoHIPKdP17J5C5kieMgx98D8E8Fzp3xyQEBzvo=; b=Fw+6bUOelf1mgiQpxK1nwoGz33t81Bo+odl+PQ+2VN4Fj6XBtquh8tE637jWnYZG54 QS7hN66BVIvvWZ8CiQf5WVTwg1uDF4d2/fHPfy/ejzJaW/mNyLs3Bz1+pGHAtmqxNHjW 7Pl1Vve5g7ri4aJPwwZzKwyjIBqk777NgG1LSUTy4U6kN6l3SFkw4385jB493wCRoF5D Tm52LQ6pbJAwXgDubk4ggu56KFcRaR/PijOoBFDx7TD2tQ7MqXXCJ12/InrgAsYhr+3i aZgdrCZtvn5Oa7/IDUfwD96K7ziYR5FPZhG9cimnGWP6/1His90Ink32VKvbByw/HHnX Lv3A== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P3gBZUipdd93FF5ZZvYFPugejmSTVR2nRPhVOQ/OcYgojyw4j34+u26zEodhPgRDZ8j5Ic/HBg==" X-RZG-CLASS-ID: mo00 Received: from gerhold.net by smtp.strato.de (RZmta 47.28.1 DYNA|AUTH) with ESMTPSA id Y070ccx64BEWKU2 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 4 Jul 2021 13:14:32 +0200 (CEST) Date: Sun, 4 Jul 2021 13:14:20 +0200 From: Stephan Gerhold To: Ramon Fried Cc: U-Boot Mailing List , 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 Sun, Jul 04, 2021 at 02:08:39PM +0300, Ramon Fried wrote: > On Sun, Jul 4, 2021 at 12:42 AM Stephan Gerhold wrote: > > > > 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", > > > Hi. > If I recall correctly, the signing tool only used the ELF sections, so > the appended DTB was deleted. > That's why I kept the "embedded DTB". Yes, it doesn't make sense to append the DTB to the ELF file. That's why "CONFIG_REMAKE_ELF" is useful, it builds a new ELF file where U-Boot + appended DTB is put into a single, new ELF section. > In your signing tool, you probably sign the complete file without > parsing the ELF. The "signature" actually consists out of additional ELF headers. There is no way to "sign" without parsing the ELF file. So my tool parses the ELF file just like signlk. Thanks! Stephan