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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 BF8D6C4338F for ; Mon, 26 Jul 2021 18:42: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 C58E260F59 for ; Mon, 26 Jul 2021 18:42:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C58E260F59 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gateworks.com 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 07FD383350; Mon, 26 Jul 2021 20:42:39 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=gateworks.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=gateworks-com.20150623.gappssmtp.com header.i=@gateworks-com.20150623.gappssmtp.com header.b="SX8aX5qh"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B6401833B5; Mon, 26 Jul 2021 20:42:35 +0200 (CEST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 B8CFB8334F for ; Mon, 26 Jul 2021 20:42:30 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=gateworks.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=tharvey@gateworks.com Received: by mail-pj1-x102a.google.com with SMTP id k4-20020a17090a5144b02901731c776526so235269pjm.4 for ; Mon, 26 Jul 2021 11:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=31SmSCMxg+SU6K/eyQErsjQI18q/podO5bgT//qwavo=; b=SX8aX5qhYzoa+US2SnXrxfrxUrEuOni20tO+vydnkR6KkRIL8IRuV/fl42enXKHgc/ RlQ2TvfYWMfZz2p0huXRuRyPr1EksmdmVznxGn/K4PEO9ktCYGHlyu5cuAsY7q1ViyAg LG7oXftqi+NfdarzOYvVYZCaZhuVCvYxxawCKfiDKRMHOCo6AqohXmBS/7vg4E8oBqY4 dGp9IgmGBCE98VL64q5J5LBliEYC73z4RWtdQ1ouXNQoFs9bHC08g45D04AbjSb2Rloy Gs0rDBAAH256CPNcijt+gWdc1H7ygbz+FvXphi53Fno1ipGlZBl7Pto75NXCiApdlDT9 JLng== 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=31SmSCMxg+SU6K/eyQErsjQI18q/podO5bgT//qwavo=; b=btith9Qn0j3VF5a6yJy/zCsXoUsorkYXMovHEzA3n6nPvuNvRiQDKHYbHLFlI0BVLL MZb7uCra9h3E0d/X4pL6Uqd16M0K0lyLcrO3Ov+4R0Ps8kFpSPKxvHU/KPv5yTOZgCm3 hHJJ2PCPPi/56W7BHL0ff1hBBhKcKTXVVi2KDcjLWCWymVJNNb1V3lwHLpXJLXuU5fXY CXQikZjS2sJhIJo5XO+MGzORwBOarXFcJA/J2iPlQwPT8hKBlQnMvOAi+SPmnCG+s+jJ tUVSdnHFFd551197MQyp8gWXo0aACizSiN+hpeTeISHE6dCf9oRqishyFKe9LzN5+y0r grCg== X-Gm-Message-State: AOAM533WtBtwsSG58Bb7l1/WssVQcKFSdHwnrpDrTtLaL0yBN6crLXR5 0BcB5AH+DWh1HmBgIFUjCytiKp1QIHXTK/JG+3r59Q== X-Google-Smtp-Source: ABdhPJxWpiWdWJ4DvJSAqNB9/7Nsm4bboL4a9noh1g3+9861eTODpDNflZRSt0jMNijIcJ+bPTMFXiwa7AHifFptDQs= X-Received: by 2002:a17:90a:2ec3:: with SMTP id h3mr7658879pjs.125.1627324949034; Mon, 26 Jul 2021 11:42:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Harvey Date: Mon, 26 Jul 2021 11:42:17 -0700 Message-ID: Subject: Re: using binman fails boot To: Simon Glass 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 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. > > > > > 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. Tim