[U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0
Thomas Fitzsimmons
fitzsim at fitzsim.org
Wed Jun 6 20:39:39 UTC 2018
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?
Thomas
More information about the U-Boot
mailing list