[U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0

[Florian Fainelli]

On 06/06/2018 01:39 PM, Thomas Fitzsimmons wrote:
> Florian Fainelli <f.fainelli at gmail.com> writes:
> 
>> On 05/10/2018 06:04 AM, Thomas Fitzsimmons wrote:
>>> Florian Fainelli <f.fainelli at gmail.com> 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