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=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 783B2C07E95 for ; Sun, 4 Jul 2021 13:35:34 +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 4D7BF6135E for ; Sun, 4 Jul 2021 13:35:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D7BF6135E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 14D2682A29; Sun, 4 Jul 2021 15:35:31 +0200 (CEST) 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="TcxY4b8V"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C3AEA82B20; Sun, 4 Jul 2021 15:35:28 +0200 (CEST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 B4FF28033E for ; Sun, 4 Jul 2021 15:35:25 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=rfried.dev@gmail.com Received: by mail-ot1-x32e.google.com with SMTP id d21-20020a9d72d50000b02904604cda7e66so15422774otk.7 for ; Sun, 04 Jul 2021 06:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JVC0uQXXzCqqOaewKeXUggZ8a3vSN5IqH3eAF4dtqk0=; b=TcxY4b8VNK9nOsezcB2udF88484Y6uzydlK0uknSLjFKytHd7LDE1PKI2nXmA49WZS p1dRYP7iyD4HvgpPMVMdV7rjx8dInxW6W3SUsD30SJP9zR6dHwNHtmKkaX3vsBHjemnn Z2Qmb1Y5WdpoUHHeMSI7JAChl+Hz1LzroSBj0eYoqwLFSAE03zptlvrWi4u0ykquOA2X 2XcgeI0N12uIIidU7/MFGLfzGZ0qpqWsttA6PwhdhfiA2w50Z0nIqbwIhkYe/f6ceHbX lwYIjhpryV6MI1WvHkgVQiGjSS4JWC35RTBNxDxbz7sZsdcp70/s1oS2REIW6DUttg9i EKKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JVC0uQXXzCqqOaewKeXUggZ8a3vSN5IqH3eAF4dtqk0=; b=KIq9tfbGY41J5fRd4pbQWDgebRrvW+OBrnBw1CeiMivXZOIB8GnOpK8qt7aIAl86o+ d4nAJeJwTD9SutmLZzF8Qztg2obHF+yHLPl14HHmCwjQ5PuoiXZrz+x2ktP1AYI3n9k1 1Gck7HOtPKr+AR9ROxqZx09lDwjGvgG6QRk2xtlvBWBXQarAc1KjWiDiUS6JmOtRcnRi wM1XRQ1RHd/M716RxJlL6+HEcdnDm+VPWuUWK8dMqhuHqkDUwg5NhrgCqpTdLPmbSp4l lQMvgrlLMizwYPzWLZxjpM6mK7KIQjtI9Aecs/n1/d0u0xcFviv1k3JO0SfMHfqsh2HJ qC1w== X-Gm-Message-State: AOAM530wGXmFbgz8uPqZw5z9mfzARTTIhiHJtT8YZoR08us/Geb/lzYu HHnNW6Ii0onx2Kfo3Wx9Eeybl0whmw6GSLB+Thc= X-Google-Smtp-Source: ABdhPJwG1eoYmbJa1ednqxQMPALJroNnkNIa6zDwmm2UBesRe5x4qCTYmSuckEoPF6ogUrx1BVFa2mn7jQLNySW4pno= X-Received: by 2002:a9d:7192:: with SMTP id o18mr7399621otj.370.1625405724042; Sun, 04 Jul 2021 06:35:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ramon Fried Date: Sun, 4 Jul 2021 16:35:12 +0300 Message-ID: Subject: Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?) To: Stephan Gerhold Cc: U-Boot Mailing List , Jorge Ramirez-Ortiz , Nicolas Dechesne Content-Type: text/plain; charset="UTF-8" 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 4, 2021 at 2:14 PM Stephan Gerhold wrote: > > 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 Cool, thanks!