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=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,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 B5D3EC4338F for ; Wed, 28 Jul 2021 02:46:46 +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 D249660EBB for ; Wed, 28 Jul 2021 02:46:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D249660EBB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8307B82C1B; Wed, 28 Jul 2021 04:46:38 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="Mhm+z9pM"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C4A8E82BFD; Wed, 28 Jul 2021 04:46:33 +0200 (CEST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 EDC00829C6 for ; Wed, 28 Jul 2021 04:46:27 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-wm1-x32a.google.com with SMTP id a192-20020a1c7fc90000b0290253b32e8796so2415590wmd.0 for ; Tue, 27 Jul 2021 19:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lqGCBoVlMbI3gLZq0ep+/nn7t7dE/hXJ88cu9W73N6A=; b=Mhm+z9pMWiwKZGaeKyxeNmS/8R8mredncLgvQBdQdz0RbkZCm4IHDS3lW2Va7kBBO1 KKLdYt5flJZoKEjedyDS2wwOziyXbpOkVlo/e2EJEuq5C1nyfzbPZHVkpZmOBWkZDqK9 ujlb/v4uXnAgh0gVtpcYFH9ws1E9iLnfrah5g= 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=lqGCBoVlMbI3gLZq0ep+/nn7t7dE/hXJ88cu9W73N6A=; b=oWD1BAvgASrnfhSMC0eNqK3DhF5BtmKhxxoXaoIDLplkOJz6b1BqACArN5x5ermjOR C5CW8NtVRL8AqSnDoZP8O4tYy968g7QQFU3Y1Iye5bAtDn6VjjKFCApV62CRkbkLMAVP ru5NJZVqzxeF3gJ4BKbVksDoCmQhzq4Ga3X+D6GdoxkzUlZiz+jpNVGvjCcww2F1c8xf pukAnfX72VpgWsDOSIh/G3U6QAcWEx9XsB7zJ3HOlK889OWJVjnoDmhT0lnxJImyoX3k SDRBd9WcvYuvie/DK0YxDCWPAAo8DXVl4uB1h7GHM7XKshkqGcxvLruKOQT0rN0ncOgI lbUg== X-Gm-Message-State: AOAM533BlTefOPFNtF8oJ7cnA1MKD3aLs7jsmGNyu56l7q3GCuJnXOT7 u/qjMqxjp6QepqKH0fpTBs38+CohD8eZKQuamz722cZK/XUf2g== X-Google-Smtp-Source: ABdhPJx3AhCSPCeKY1eyLqj68K3g5DUCw9jZHmiJE5dYHYIpJaN50mJTCoJCIsad+TbJ+e8lkrnj70l7sniUJiGoPDI= X-Received: by 2002:a1c:2b04:: with SMTP id r4mr22294776wmr.168.1627440387123; Tue, 27 Jul 2021 19:46:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon Glass Date: Tue, 27 Jul 2021 20:46:15 -0600 Message-ID: Subject: Re: using binman fails boot To: Tim Harvey Cc: u-boot 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 Hi Tim, On Mon, 26 Jul 2021 at 12:42, Tim Harvey wrote: > > On Sat, Jul 24, 2021 at 3:01 PM Simon Glass wrote: > > > > Hi Tim, > > > > On Fri, 23 Jul 2021 at 16:52, Tim Harvey wrote: > > > > > > On Fri, Jul 23, 2021 at 2:41 PM Simon Glass wrote: > > > > > > > > Hi Tim, > > > > > > > > On Fri, 23 Jul 2021 at 15:06, Tim Harvey wrote: > > > > > > > > > > On Thu, Jul 22, 2021 at 8:07 PM Simon Glass wrote: > > > > > > > > > > > > Hi Tim, > > > > > > > > > > > > On Mon, 19 Jul 2021 at 17:23, Tim Harvey wrote: > > > > > > > > > > > > > > On Sat, Jul 17, 2021 at 7:22 PM Simon Glass wrote: > > > > > > > > > > > > > > > > > > > > [..] > > > > > > > > > > > > > > > But isn't blob-ext@4 a correct name? I can't use 'blob-ext-4' as > > > > > > > > > that's an unknown entry type. > > > > > > > > > > > > > > > > Well you can use any name and specify the type: > > > > > > > > > > > > > > > > my-name { > > > > > > > > type = "blob-ext"; > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > Ok - I understand. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you can push your tree somewhere (with this problem) I'll see if I > > > > > > > > > > can figure out why. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sure, I pushed it to > > > > > > > > > https://github.com/Gateworks/uboot-venice/tree/WIP-venice-binman > > > > > > > > > make imx8mm_venice_defconfig > > > > > > > > > make > > > > > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > BINMAN_VERBOSE=4 indeed prints out a tone of stuff but I'm not seeing > > > > > > > > > > > anything for 'blob' below that would seem to indicate one node name vs > > > > > > > > > > > another: > > > > > > > > > > > > > > > > > > > > Oops you need BINMAN_VERBOSE=5 - see elf.py LookupAndWriteSymbols() > > > > > > > > > > which has tout.Debug() which is level 5. > > > > > > > > > > > > > > > > > > > > > > > > > > > > LookupAndWriteSymbols ends up doing nothing because > > > > > > > > > syms.get('__image_copy_start') returns None. > > > > > > > > > > > > > > > > Well that is likely the problem. > > > > > > > > > > > > I sent a patch to make binman report this as an error. > > > > > > > > > > > > I pushed the resulting tree to: > > > > > > > > > > > > https://github.com/sjg20/u-boot/tree/try-tim > > > > > > > > > > > > Now the error is: > > > > > > > > > > > > binman: Section '/binman/u-boot-spl-ddr': Symbol > > > > > > '_binman_u_boot_any_prop_image_pos' > > > > > > > > > > > > in entry '/binman/u-boot-spl-ddr/u-boot-spl/u-boot-spl-nodtb': > > > > > > Entry 'u-boot-any' not found in list > > > > > > (u-boot-spl-nodtb,u-boot-spl-dtb,u-boot-spl,blob-ext@1,blob-ext@2,blob-ext@3,blob-ext@4,main-section) > > > > > > > > > > > > The problem seems to be that you are asking binman to generate three > > > > > > independent images. U-Boot is in a FIT which is not in the same image > > > > > > as SPL. So it is not possible to locate the flash offset of U-Boot > > > > > > (with in the FIT). > > > > > > > > > > > > Can you give me a bit more info about your intent here? Is it to load > > > > > > U-Boot from the FIT? I so, I suppose it is possible to make binman > > > > > > access an independent image, if it is told where it starts. > > > > > > > > > > > > But why is everything not in one image? > > > > > > > > > > > > > > > > Simon, > > > > > > > > > > I would rather have 1 image. I was going off of the imx8mm_evk switch > > > > > to binman which creates the separate images. > > > > > > > > Well at present you are loading a FIT into RAM, I think? Is it coming > > > > from flash? > > > > > > > > If you load a FIT containing U-Boot then you don't need the binman > > > > symbol stuff, since SPL looks in the FIT for the location of U-Boot. > > > > There isn't much benefit in having binman point to U-Boot within the > > > > FIT, since we already have code to find it. It might save a few bytes > > > > of code, but it would be confusing...I'm not sure if that is worth the > > > > hassle. > > > > > > > > If you want a single image, then you might not want FIT at all...just > > > > use binman. > > > > > > > > It really depends what you want. > > > > > > Maybe my terminology is all wrong or I'm not making myself clear. I'm > > > trying to access data inside the SPL binary in board_init_f() 'before' > > > the SPL has done anything at all with FIT. > > > > > > I'm using FIT because I have multiple board models (ie multiple DTB's) > > > supported by a single U-Boot 'board'. > > > > OK I see. > > > > Well in that case the problem is the use of > > CONFIG_SPL_RAW_IMAGE_SUPPORT which causes spl_set_header_raw_uboot() > > to try to find U-Boot's binman symbol, which doesn't exist. > > > > Also the naming of your sections need a tweak, as mentioned. > > > > I've pushed a new trree to: > > > > https://github.com/sjg20/u-boot/tree/try-tim > > Simon, > > Thanks - this appears to give me some real offsets: > > U-Boot SPL 2021.07-00329-gb3d23cad33-dirty (Jul 26 2021 - 11:19:30 -0700) > board_init_f: blob_1:0x8038dc > board_init_f: blob_2:0x80b8dc > board_init_f: blob_3:0x80f8dc > board_init_f: blob_4:0x8178dc > > CONFIG_SPL_TEXT_BASE=0x7e1000 so subtracting that from above matches > the offsets of the blobs in u-boot-spl-ddr.map > > This should work nicely... I'll continue working on my end goal. OK good. > > > > > > > > > So my boot goes like this: > > > IMX8M BOOT ROM fetches flash.bin (SPL) from eMMC into OCRAM > > > SPL configures PMIC and DRAM based on runtime detection of board model > > > - at this point in time SPL is using a generic imx8mm-venice.dts > > > that just supports i2c/uart2/emmc which are common to all venice > > > boards > > > - pmic config is done without dm because we don't have the > > > board-specific dtb yet which defines the pmic > > > - DRAM config is done based on eeprom bytes that specify the DRAM > > > size/density/etc > > > - DRAM config includes loading the 'blobs' to the M4 CPU - these are > > > the blobs I want to locate in the SPL > > > SPL locates FIT and starts chugging through it (I don't claim to fully > > > understand this part) > > > - board_fit_config_name_match() is called for each DTB found and I > > > return a success if the DTB matches the board model found via I2C > > > EEPROM > > > SPL loads ATF and executes it > > > ATF executes? U-Boot (not super clear on all of this either) > > > U-Boot Proper runs with the board-specific dtb (not imx8mm-venice.dtb > > > but imx8mm-venice-gwxxxx.dtb) > > > > OK, got it. > > > > > > > > > > > > > > > > > > > > > The whole point of what I'm investigating here has to do with the SPL. > > > > > OCRAM is at a premium and the current way the IMX8M is handling DDR > > > > > firmware is to tack it on after the code in the SPL image and it gets > > > > > padded to make it easy to locate which is a huge waste of space. I > > > > > figured we can use binman to locate the blobs without the padding. > > > > > > > > > > So, if you take 'just' the spl image here: > > > > > spl: u-boot-spl-ddr { > > > > > filename = "u-boot-spl-ddr.bin"; > > > > > pad-byte = <0xff>; > > > > > align-size = <4>; > > > > > align = <4>; > > > > > > > > > > u-boot-spl { > > > > > align-end = <4>; > > > > > }; > > > > > > > > > > blob_1: blob-ext@1 { > > > > > filename = "lpddr4_pmu_train_1d_imem.bin"; > > > > > size = <0x8000>; > > > > > }; > > > > > > > > > > blob_2: blob-ext@2 { > > > > > filename = "lpddr4_pmu_train_1d_dmem.bin"; > > > > > size = <0x4000>; > > > > > }; > > > > > > > > > > blob_3: blob-ext@3 { > > > > > filename = "lpddr4_pmu_train_2d_imem.bin"; > > > > > size = <0x8000>; > > > > > }; > > > > > > > > > > blob_4: blob-ext@4 { > > > > > filename = "lpddr4_pmu_train_2d_dmem.bin"; > > > > > size = <0x4000>; > > > > > }; > > > > > }; > > > > > > > > > > My intention is to remove the size arguments above which are currently > > > > > forcing wasted padding and locate the blobs at runtime with binman. > > > > > > > > Well you can just remove them. > > > > > > Not right now because the imx8 dram config expects them to be > > > following the DDR code and specific sizes... its dumb code that ends > > > up wasiting 24K of SPL/OCRAM with padding which is why I want to > > > improve that. > > > > > > see ddr_load_train_firmware > > > https://elixir.bootlin.com/u-boot/latest/source/drivers/ddr/imx/imx8m/helper.c#L29 > > > > OK well if you can update that code to read the size from a binman > > symbol, perhaps that will help. > > > > > > > > > > > > > > > > > > > Based on your other patch it it would seem I'm missing something from > > > > > my lds to add __image_copy_start yet in > > > > > arch/arm/cpu/armv8/u-boot-spl.lds I see: > > > > > .text : { > > > > > . = ALIGN(8); > > > > > *(.__image_copy_start) > > > > > CPUDIR/start.o (.text*) > > > > > *(.text*) > > > > > } >.sram > > > > > > > > > > My understanding of linker files is pretty slim so perhaps there's > > > > > something missing above. > > > > > > > > Yes you need to define the value of the __image_copy_start symbol, so: > > > > > > > > .text: { > > > > __image_copy_start = .; > > > > > > > > See for example arch/arm/cpu/u-boot-spl.lds > > > > > > > > > > Honestly what I 'really' want to do is get the SPL to load all the > > > dram config/blobs from flash and completely move them out of the SPL > > > that gets loaded into OCRAM so that I don't overflow the OCRAM with > > > DRAM configs when we add new boards. So maybe I'll just start focusing > > > on that. > > > > > > I was thinking FIT would be a good approach for that but I haven't dug > > > into how the SPL processes the FIT yet...if it requires DRAM to do so > > > then I can't really go that route and maybe it's just too complex for > > > what I want anyway. > > > > FIT is fine, but I suppose it is also possible to use binman for > > everything. But we do encourage FIT since it is a standard boot > > method. > > The next step of what I was interested in was to move those blobs > outside of the spl binary completely and if I do that the binman > solution no longer works as the blobs would be outside of flash.bin so > I'm not sure how I could make use of binman there. Where are you planning to put them? Still in flash or on another medium altogether? If the latter, binman cannot help you at present, although I suppose we could add a way for it to point into other images. If the former, then can you put everything in one image? Regards, SImon