[U-Boot] [RFC PATCH v2 00/12] Add support for applications of overlays in SPL

[Michal Simek]

On 17. 04. 19 14:29, Jean-Jacques Hiblot wrote:
> 
> On 17/04/2019 12:38, Michal Simek wrote:
>> On 17. 04. 19 11:34, Jean-Jacques Hiblot wrote:
>>> Hi Michal,
>>>
>>> On 28/03/2019 15:03, Michal Simek wrote:
>>>> On 27. 03. 19 16:38, Jean-Jacques Hiblot wrote:
>>>>> The purpose of this series is to provide the SPL with ability to apply
>>>>> overlays for u-boot. this is only a RFC so far, to get a feedback
>>>>> on the
>>>>> approach.
>>>>>
>>>>> Our use-case is the support of the daughter boards of the AM65x
>>>>> EVM. In
>>>>> Linux, each board is supported by a unique overlay. The presence of
>>>>> the
>>>>> boards is detected at runtime, and some useful features (like USB) are
>>>>> implemented on those daughter boards. Instead of providing multiple
>>>>> dtbs
>>>>> and fall in a combinatorial pit, we propose to use DT overlays.
>>>>>
>>>>> Patch #1 "spl: fit: Add support for applying DT overlay" has been
>>>>> posted
>>>>> a few weeks ago by Michal Simek.
>>>>> Patch #2 and #3 amend Michal's patch.
>>>>> Patch #4 and #5 are simple fixes for the Makefile
>>>>> Patch #6 is not required but relates to this series and will be
>>>>> required
>>>>> later by the AM6x platform
>>>>> Patch #7 may be a bit controversial. It basically replaces u-boot.img
>>>>> with
>>>>> a symlink to u-boot.itb in case we use a "complex" FIT (ie: if
>>>>> SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set). This breaks buildman for
>>>>> several platforms because not all the binaries embedded in the FIT are
>>>>> available.
>>>>> Patch #9 adds a way to dynamically select the DT overlays. That is
>>>>> were we
>>>>> would use HW detection to select the required overlays. In that case,
>>>>> the
>>>>> board-level code tells what overlay it needs (it gives the name of the
>>>>> node).
>>>>> Patch #10 disables advanced SPL FIT features to keep the size of the
>>>>> SPL of
>>>>> the am335x_evm in check
>>>>> Patch #11 is not required, but demonstrates on a DRA76-evm how this
>>>>> series
>>>>> can be used.
>>>>>
>>>>> On arm, if overlay are supported, this series increases the size of
>>>>> the SPL
>>>>> by 3-4 kB.
>>>>>
>>>>> Changes in v2:
>>>>> - reworked board_fit_get_additionnal_images() and how it used in
>>>>> spl_fit.c
>>>>> - removed dtbo generation from dtso files and use .dts extension
>>>>> for the
>>>>>     overlays
>>>>> - add dynamic allocation usage in a separate patch
>>>>> - defconfig change for the am335x_evm
>>>> This series looks better.
>>>> Is this able to also handle different images then just dtbs?
>>> Sorry I thought  had answered this.
>>>
>>> Yes this is able to handle different image types, not just dtbos.
>>>
>>> Have you been able to play with it ? any additional comment ?
>> I haven't had a time but series is going in a right direction.
>> I found 2 days ago that applying my patch is increasing size for some
>> platforms that travis is failing.
>> It means I would definitely suggest you to run travis on branch with all
>> patches applied to see if this passing or some changes need to happen.
> 
> Already done. https://travis-ci.org/jjhiblot/u-boot/builds/511617974
> 
> The failures (except dra7 which is unresolved) are all related to the
> generation of u-boot.itb (one patch replaces u-boot.img with a link to
> u-boot.itb, making travis build u-boot.itb)
> 
> Was the broken  platform the am335x_evm? In that case, the fix is in the
> series. I disabled advanced FIT features for this platform as this is
> definitely not needed.

https://travis-ci.org/michalsimek/u-boot/builds/518675021

This was the issue.

   aarch64:  +   orangepi_pc2
+aarch64-linux-ld.bfd: u-boot-spl section `.rodata' will not fit in
region `.sram'
+aarch64-linux-ld.bfd: region `.sram' overflowed by 3152 bytes

M