[RFC 0/4] drivers: footprint reduction proposal
Walter Lozano
walter.lozano at collabora.com
Fri Jun 26 21:17:30 CEST 2020
Hi Tom,
On 22/6/20 12:25, Walter Lozano wrote:
> Hi Tom,
>
> On 22/6/20 11:20, Tom Rini wrote:
>> On Mon, Jun 22, 2020 at 11:12:40AM -0300, Walter Lozano wrote:
>>> Hi Tom,
>>>
>>> On 19/6/20 18:48, Tom Rini wrote:
>>>> On Fri, Jun 19, 2020 at 06:11:36PM -0300, Walter Lozano wrote:
>>>>
>>>>> Based on several reports and discussions it is clear that U-Boot's
>>>>> footprint is always a concern, and any kind of reduction is an
>>>>> improvement.
>>>>>
>>>>> This series is a proposal to help reducing the footprint by parsing
>>>>> information provided in DT and drivers in different ways and adding
>>>>> additional intelligence to dtoc. The current version implements
>>>>> the basic
>>>>> functionality in dtoc but this is no fully integrated, however it
>>>>> will allow
>>>>> us to discuss this approach.
>>>>>
>>>>> Firstly, based on the compatible strings found in drivers, include
>>>>> only DT nodes
>>>>> which are supported by any driver present in U-Boot.
>>>>>
>>>>> Secondly, generate struct udevice_id entries only for nodes
>>>>> present in DT,
>>>>> which will allow to avoid including additional data.
>>>>>
>>>>> These are the first steps for further improvements as proposed in
>>>>> the specific
>>>>> patches in this series.
>>>>>
>>>>> This work is based on the work of Simon Glass present in [1] which
>>>>> adds
>>>>> support to dtoc for parsing compatible strings.
>>>>>
>>>>> [1]
>>>>> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working
>>>>>
>>>> I applied this series on top of the above tree, but there's no rule
>>>> for
>>>> <generated/compatible.h> so is something missing? Thanks!
>>>>
>>> Thanks for taking the time to check this RFC.
>>>
>>> As you pointed, the Makefile needs to be tweaked in order to be able
>>> to run
>>> a build, that is what I meant by "not fully integrated", also some
>>> additional stuff are missing. However, I thought that sending this RFC
>>> explaining the idea will be nice in order to confirm if the approaches
>>> proposed make sense for the community and at least the one to handle
>>> compatible strings is different from the linker list suggestion.
>> I think I like the idea, but I need to give a build a spin and poke
>> things harder. What do I need to do to manually have this build+link?
>> Thanks!
>>
> Well, I don't think this version will give you something to fully
> test, as there are several pieces missing, but the fact you think you
> like the idea is good starting point.
>
> Just to do some testing you can try
>
>
> Shrink a dtb with
>
> ./tools/dtoc/dtoc shrink -d u-boot.dtb
>
> this will shrink u-boot.dtb and create u-boot-shrink.dtb by only
> include nodes with compatible strings present in drivers
>
>
> Generate include/generated/compatible.h
>
> ./tools/dtoc/dtoc compatible -d u-boot.dtb -o
> include/generated/compatible.h
>
> this will generate compatible.h but the code does not yet support
> struct udevice_id with data in struct udevice_id and does not filter
> anything.
>
>
> I will continue working on these features but any early feedback is
> welcome.
>
To be able to test this a bit more I reworked and back ported the
patches and add a bit more of work on top, such as
- Add Makefile rules (need to be improved)
- Add support for checking enabled drivers for dtb shrink (need to be
improved as parsing probably does not take into account no common
situations)
- Add support for defining constants based on compatible strings enabled
This work can be found in
https://gitlab.collabora.com/wlozano/u-boot/-/tree/wip
The drawback is that this implementation doesn't take advantage of the
new abstractions found in the Simon's work, but I think it could still
be useful to test the idea, and discuss if it makes sense.
I have done some testing in my iMX6 Hummingboard but I have found some
issues not related to this work in MMC, which I need to debug.
Regards,
Walter
More information about the U-Boot
mailing list