From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Date: Wed, 6 Jun 2018 15:06:16 -0700 Subject: [U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0 In-Reply-To: References: <20180506110922.32469-1-fitzsim@fitzsim.org> <20180506110922.32469-2-fitzsim@fitzsim.org> <8ebd1d9d-46dd-3879-c79b-f74b2fec8828@gmail.com> Message-ID: <3050e5a4-ff2e-5411-36ae-f7375534f6a3@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 06/06/2018 01:39 PM, Thomas Fitzsimmons wrote: > Florian Fainelli writes: > >> On 05/10/2018 06:04 AM, Thomas Fitzsimmons wrote: >>> Florian Fainelli writes: >>> >>>> On 05/06/2018 04:09 AM, Thomas Fitzsimmons wrote: > > [...] > >>>>> + >>>>> +config BCMSTB_ACCOMMODATE_STBLINUX >>>>> + bool "" >>>>> + default y >>>>> + help >>>>> + This prevents U-Boot from adding memory reservations for the >>>>> + lengths of initramfs and DTB. Without skipping these, >>>>> + stblinux's "contiguous memory allocator" (CMA) Linux driver >>>>> + (cma_driver) will allocate memory ranges smaller than what >>>>> + are actually available, because it only checks reservation >>>>> + sizes. It doesn't check if the reserved range overlaps the >>>>> + range it allocates. stblinux also tries to move the DTB to >>>>> + a lower memory location early in the Linux boot. If the FIT >>>>> + image specifies a load address for the initramfs then >>>>> + sometimes the DTB is moved into the range where the >>>>> + initramfs image is loaded. Defining this will mean that >>>>> + FIT-provided initramfs load addresses are ignored. >>>> >>>> What STB Linux kernel did you observe this with? I am afraid this is >>>> still true about the ranges vs. allocation even in newer kernels, but >>>> that is kind of intented to keep the logic KISS (because it's already >>>> too complicated IMHO). >>> >>> I investigated the allocation discrepancy and wrote the workaround while >>> we were still using stblinux-3.14. Since then we've updated to >>> stblinux-4.1 and I've left the workaround enabled, but I haven't >>> investigated its interactions with the newer bmem mechanism. I should >>> probably revisit this though, with stblinux-4.1 and stblinux-4.9, just >>> to make sure this macro is still useful. >> >> Sounds good, let me know if there is something that does not seem quite >> right, we could fix it. > > [...] > > In the v3 patch, I keep the FIT's RFS and DTB in-place. This approach > eliminates the bmem/cma allocation discrepancies. I compared bmem/cma > dmesg output for stblinux 3.14, 4.1 and 4.9, zImage and ITB builds, on > my eval board, and they're all the same for the same kernel version. > The only thing I noticed is that in 3.14 and 4.1 (zImage and ITB), the > first bmem region is: > > 768 MiB at 0x0000000010000000 > > whereas in 4.9 (zImage and ITB), it is: > > 760 MiB at 0x0000000010800000 > > This is booting with no kernel command line arguments, so I guess some > default may have changed between stblinux 4.1 and 4.9? This upstream commit is responsible for what you see: 6ff0966052c46efb53980b8a1add2e7b49c9f560 ("ARM: 8432/1: move VMALLOC_END from 0xff000000 to 0xff800000") we've backported that change to our 3.14 and 4.1 kernels since then. -- Florian