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=-12.2 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 B5793C4338F for ; Sat, 24 Jul 2021 22:02:03 +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 C572060E8B for ; Sat, 24 Jul 2021 22:02:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C572060E8B 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 4750D83215; Sun, 25 Jul 2021 00:01:59 +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="L/nQSuyK"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A9919831FC; Sun, 25 Jul 2021 00:01:43 +0200 (CEST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 1DA18831BD for ; Sun, 25 Jul 2021 00:01:31 +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-wr1-x434.google.com with SMTP id b9so5481573wrx.12 for ; Sat, 24 Jul 2021 15:01:31 -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=zM3YVRWHM+j8CV6TX2A/P1VZDKHEolRiy77q+CMXCkg=; b=L/nQSuyKPYzgkz183duUeOv+J/Hch3T1O91veM4uBHFb9d/j+M+Cy3EH2Qjo6o6olr aauSW+4Z4fzJxK09g5/x1m2UAaBpztaSZgPpBayu6xhlpvripb+aFy6Xp5Vs78OenWFH noVSXIfmDzBQcp2PzcrciyVB9QP+U4uacIFKM= 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=zM3YVRWHM+j8CV6TX2A/P1VZDKHEolRiy77q+CMXCkg=; b=Hxj3q5zCWdjCQimDjwXeRDZc3WWiCof9qAAKvZ851XnADRG4DQyFOaeqAcXlYgqbPz +IA/glPpN59pH7tZkg7ksqk9ljep7NEODKkhGt9zrURiI8s/ta8KQF7Zq4Iy9O80U4hq a/XfkrYFsgV9ouZJDX9xQRE9zfSJSnRoUYeER0gLUzUEyDAU9QNO2L1OqJTh7gvMyPx7 wUNLSUIm021/zsTUGRMqwb6P1I5wFNjY5rJNoNHpWSkrQvkpoycsLo1zDaZxgD8iq/SW TxkFVX9ercdMu8UDHOi/vTA6M/RT3plw4c2CJNV2/jnEklMug55z6nOEbHMTvA48+pFJ gyDQ== X-Gm-Message-State: AOAM5333ttulwIFxqCYu4HnpY2m5MqmUpZnrNRVolmW0TiXbo3WRBoYl WA6oSaPVQAFJXz73nV9hmKguA5ShIiMSrlmes+bl6Q== X-Google-Smtp-Source: ABdhPJxb3lQ2x0QBa7j+SYh4T+Q6ndP/OK9iLMNNkU9gUQFUEEpPfe1kUQZ5ATc9lsBdze9gdcpzclQQg/J35/gG3aU= X-Received: by 2002:adf:ce83:: with SMTP id r3mr11704399wrn.204.1627164090355; Sat, 24 Jul 2021 15:01:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon Glass Date: Sat, 24 Jul 2021 16:01:18 -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 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 > > 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. Regards, Simon