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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 4BE0AC432BE for ; Fri, 27 Aug 2021 21:32:24 +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 11BD060F58 for ; Fri, 27 Aug 2021 21:32:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 11BD060F58 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 7F1CD82E03; Fri, 27 Aug 2021 23:32:20 +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="AY3nbFRp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4A1C282E03; Fri, 27 Aug 2021 23:32:19 +0200 (CEST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 ACAE182D92 for ; Fri, 27 Aug 2021 23:32:13 +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-pg1-x52d.google.com with SMTP id t1so7002084pgv.3 for ; Fri, 27 Aug 2021 14:32:13 -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=9B4ehGm3K2+N9axJlbjpm1rPdxLHXa2ztT4YFN5GQxg=; b=AY3nbFRppbjVYdy24XFN9GN4EcLGIBhvTrZjpYdBx23sWpMm6Dan5TXXdyO5MP16JQ CacFMEdpuiBQu2ShU1wK+4mHJrliYvq8gBUnWPyb0RaW9V+GeW6tYI0NHyyzs7f5HwnB o9i6ADf36RgXmyaR1Axx+80VVtkec2oW2KrhjFH3li8XWj8P/Jo7ckFti7lLlfT9u1Bp dZ/ymc2IWDtgQ5bxa4fJTke3c1WDHUHhHuSC3B96h0kDNWPzfGr11vVHaDcrKPm13LwM xTEUk/mqghoamC4GBHI+9q5Ji1NbMGi/tNtOqiVmO3eLh5+jiH1LhS1SL/kfv6dHnS7j Q8Aw== 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=9B4ehGm3K2+N9axJlbjpm1rPdxLHXa2ztT4YFN5GQxg=; b=nsUNCNJ5bOQ+sjE8reVZuh5zZS/Zt3bZDAL//c/fe0eum7AXayYXp+2nurSP50PJRm U+NcULM0ZuMqLbK2PPYHUeNTq3WdVxtLjy9CZMSv2SoosQhscPtGGmDS6o37JRPzUe+L 5Axay1SMKHMejF/Cq15f0hVc3bw1rvmFFmaJGQ/un1iszGlxr2j7xw4ub56AvvTrFZc/ +AFeNIggD4cBRwI8qq7gtA9dNOuFFHglE0JSTYbqetNf8mAhCfMshs72f58aPN3c9Pie YHnDVdoC2rfTcWVcESU2AwpY+rO+kgQWUQngjTWn8MCIjxki0aqs8UTQTVygWsRvP32j atJg== X-Gm-Message-State: AOAM5334XRZmBp+LeEeRUO6OaHGY0ga7eAIKHplyTBpD8svMLAUAZUxa dr1TzDsX4nELmmJWJ1Rw/Mo66VQYHzaF1TV2wGciNQ== X-Google-Smtp-Source: ABdhPJxuMr+6M8namm5jSYnRlQfloLrsw1xVngeQN+anPYQMHE7DgLm92LN/P4l40RAEYD5igjnSeANVg2wWWf790P0= X-Received: by 2002:a63:db4a:: with SMTP id x10mr9480347pgi.30.1630099931666; Fri, 27 Aug 2021 14:32:11 -0700 (PDT) MIME-Version: 1.0 References: <20210826194103.GO858@bill-the-cat> In-Reply-To: <20210826194103.GO858@bill-the-cat> From: Tim Harvey Date: Fri, 27 Aug 2021 14:32:00 -0700 Message-ID: Subject: Re: imx8mm memory env in U-Boot To: Tom Rini Cc: u-boot , Adam Ford , "Ying-Chun Liu (PaulLiu)" , Peng Fan , Jagan Teki , Matteo Lisi , Fabio Estevam , Stefano Babic , Teresa Remmet , Oleksandr Suvorov , Marcel Ziswiler , Igor Opaniuk , Atish Patra 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 Thu, Aug 26, 2021 at 12:41 PM Tom Rini wrote: > > On Thu, Aug 26, 2021 at 09:39:20AM -0700, Tim Harvey wrote: > > > Greetings, > > > > I'm trying to understand what the best memory usage is in U-Boot for > > IMX8M boards for generic distro configs such as: loadaddr, > > kernel_addr_r, fdt_addr_r, ramdisk_addr, scriptaddr. > > > > My understanding is that the following is a good rule of thumb: > > loadaddr = DDR start + 32MB (as FIT images may load kernel at DDR > > start; but this only allows for a 32MB kernel) > > kernel_addr_r = $loadaddr > > fdt_addr_r = $kernel_addr_r + 128MB (allows you up to 128MB for your > > kernel; handy if you want a kernel with internal ramdisk) > > ramdisk_addr = fdt_addr_r + 512KB (512KB should be plenty for a dt) > > scriptaddr = $loadaddr > Hi Tom, Thanks for the reply. > Missing from the list here is bootm_size, so that we make sure > everything that does need relocation is relocated within a specific size > range. I still don't quite understand bootm_size, you say it sets the limit to where things are relocated to. Shouldn't this just be the size of dram then? A few IMX8MM boards set this but most do not. > Where much of this comes from is (or should be) the huge comment > in ti_armv7_common.h that's based off of the Linux kernel arm "booting" > document (now converted to rST): > /* > * We setup defaults based on constraints from the Linux kernel, which should > * also be safe elsewhere. We have the default load at 32MB into DDR (for > * the kernel), FDT above 128MB (the maximum location for the end of the > * kernel), and the ramdisk 512KB above that (allowing for hopefully never > * seen large trees). We say all of this must be within the first 256MB > * as that will normally be within the kernel lowmem and thus visible via > * bootm_size and we only run on platforms with 256MB or more of memory. > * > * As a temporary storage for DTBO blobs (which should be applied into DTB > * blob), we use the location 15.5 MB above the ramdisk. If someone wants to > * use ramdisk bigger than 15.5 MB, then DTBO can be loaded and applied to DTB > * blob before loading the ramdisk, as DTBO location is only used as a temporary > * storage, and can be re-used after 'fdt apply' command is done. > */ Right, that's where I got my recommendations and I don't understand the reasoning behind the default loadaddr be 32MB into DDR. > > At this point, re-reading and referencing both: > https://www.kernel.org/doc/Documentation/arm64/booting.rst > https://www.kernel.org/doc/Documentation/arm/Booting > would be good, and note that there's not currently a similar document > for RISC-V, they often follow the same guidelines. And I know you're > talking about imx8 specifically right now but due to the copy/paste > nature of these kinds of values, I like to err on the side of maximal > safety. Which means that we should bump the DTB size to 2MB, per arm64. ok, good to know 2MB should be allotted for dtb. > > It also doesn't cover kernel_comp_addr_r / kernel_comp_size for > automatic decompression of Image files, but should. > interesting... I didn't even realize booti supported compressed images! I see now commit 414c34ed55: ("image: Add compressed Image parsing support in booti."). I'm not clear why the uncompressed kernel needs to be moved to kernel_addr_r after decompression... why can't it simply be decompressed directly to kernel_addr_r? I would think kernel_comp_size would typically be set to filesize as currently that is set by tftp as well as fs load commands. > Note that I believe (but would have to think on and re-read a bunch of > stuff to be sure), it's not that saying the kernel address is at 32MB > from the start of memory limits us to 32MB, but that it makes life > easier all around. > > > Looking at the various imx8mm boards upstream they are kind of all > > over the place but do follow some patterns likely due to some of us > > just going with what prior boards used. > > > > While I'm at it I've encountered a couple other questions: > > - why on IMX8MM is CONFIG_LOADADDR is 0x40480000 when DDR starts at > > 0x40000000. Why the 4608KB offset? any idea why IMX8MM boards are using DDR+4608KB for loadaddr vs just DDR? I am hoping some of the IMX8MM board maintainers I've cc'd here can answer that. > > - what is CONFIG_SYS_INIT_RAM_SIZE? Most boards are setting this to > > 2MB but a couple (cl-iot-gate/phycore) set it to 512KB > > I feel like it's pretty likely CONFIG_SYS_INIT_RAM_SIZE has been > copy-pasted around as part of setting CONFIG_SYS_INIT_SP_OFFSET which is > unused. A lot of unused (outside of m68k / PowerPC generally) options > in that area. > > > - what are people using for the load address for the kernel within FIT > > images? I expect start of DDR is appropriate (0x40000000) however for > > whatever reason I've been using 0x40200000. This plays into the env as > > you can't overlap where you loaded the FIT image with where you told > > the FIT image to relocate the kernel to. > > Getting some documentation under doc/ about both the environment > variables and optimal FIT layout would be good. Since we're talking > about arm64 here (but this is true for RISC-V too, same header). > Reading over booti_setup(), the entry point we set is (so long as 2MB > aligned) where we relocate to. So the 0x40200000 would be base + 2MB, > and there were points in history on arm64 where it had to be at that > offset, I believe. I did verify that using 0x40000000 for loadaddr in a FIT image booted a modern kernel just fine so yes I guess the reasoning must have been historical. Best regards, Tim