[PATCH v2 1/1] RFC: Move Odroid-C2 to use binman to produce the image
neil.armstrong at linaro.org
neil.armstrong at linaro.org
Thu Apr 6 00:44:38 PDT 2023
On 05/04/2023 20:38, Simon Glass wrote:
> Hi Neil,
>
> On Mon, 3 Apr 2023 at 19:31, Neil Armstrong <neil.armstrong at linaro.org> wrote:
>>
>> Hi Simon !
>>
>> On 01/04/2023 20:54, Simon Glass wrote:
>>> This shows how binman can be used to replace the long and complicated
>>> instructions with an automated build. It is still complicated to read
>>> but users don't have to worry about the details.
>>>
>>> It needs some tidying up and only supports Odroid-C2 at present.
>>
>> Like the v1, the work is really nice, but the dependency on vendor binary-only
>> tools doesn't make feel confident about merging this.
>
> So long as we can download it from somewhere, that is OK, or at least
> better than nothing. Is there a standard download location for the
> tools?
There's no "official" location, historically the tools was shipped with the
buildroot fork in the u-boot sources, but it has been moved into different
repos now they do not ship buildroot anymore, and we can only find those tools
on the SBC vendor u-boot sources.
And the tools have the same name but only support different SoCs, there's no
versioning, licence nor documentation... so relying on those tools is a nightmare.
This is why we made a central repository with the tools + binaries for
each board with an easy script to generate the bootable binary:
https://github.com/LibreELEC/amlogic-boot-fip
and documented at:
https://u-boot.readthedocs.io/en/latest/board/amlogic/pre-generated-fip.html
>
>>
>> We have open source implementation for all boards, but still dependeing on
>> tools we must manually build isn't optimal.
>>
>> What would be optimal would be to re-implement those tools into python
>> libraries and merge them into the u-boot tree then use them from binman.
>
> Or C, perhaps? Then binman can call the tools.
Yes, but the open source tools aren't heavily maintained, have different ABIs...
Supporting GXBB and GXL/G12A is impossible, the binary format is totally different
for example so we should import 2 different tools.
>
>>
>> But this could be merged as first step, them the python libaray could be
>> modified to support the binary tools & a probable python re-implementation.
>
> Yes I think it would good to get this in, even if it only supports a
> few boards. It is easy to add more, when possible.
If this can rely on the amlogic-boot-fip repo, then why not, then we can find
a native solution to replace calling those tools.
Thanks,
Neil
>
> Regards,
> SImon
More information about the linux-amlogic
mailing list