From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] What if ATF can be part of U-Boot source, like SPL?
Date: Sun, 30 Jun 2019 16:03:52 +0200 [thread overview]
Message-ID: <848513cc-1bb1-2a81-4a50-01bfa73b271d@gmail.com> (raw)
In-Reply-To: <20190630135703.GZ9388@bill-the-cat>
On 6/30/19 3:57 PM, Tom Rini wrote:
> On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:
>
>> In terms of code maintenance and development feasibility it is always
>> a better approach to have out-of-tree code or binary to be part of
>> in-house source tree.
>>
>> This is what exactly it was done for SPL, if I'm not wrong. So can we
>> do the same thing for ATF on ARM64 SoCs?
>>
>> We are using ATF (on Allwinner) to switch EL3 to EL2 for start loading
>> U-Boot proper and minimal PSCI, PMIC initialization. So assuming the
>> functionality of ATF (like here) is limited so the code it require can
>> be limited too, so why can't this code to be part of U-Boot tree?
>>
>> This would ultimately avoid out-off-tree ATF builds with associated
>> variable exporting during u-boot builds.
>>
>> More over this idea would also help to design a single-step bootloader
>> where it can't depends on out-of-tree sources.
>>
>> Code sync from ATF source to U-Boot can be possible in-terms licensing
>> point-of-view since ATF licensed under BSD-3-Clause.
>>
>> I'm thinking this can be a worth-idea to look at it and I'm sure It
>> may require some hard changes and other things to consider but just
>> posted to understand how hard or feasible or meaningful it is?
>>
>> Feel free for any comments?
>
> Given that we have "TPL" and "SPL", my "pie in the sky" wish would be
> for the ability to build different U-Boots to fill the different aspects
> of the aarch64 boot flow.
>
> That said, patches that would in turn allow for users to locally add ATF
> as a git submodule and then build that, if cleanly done, could be
> interesting. But must not impact the normal build flow.
So can we also add Linux as a submodule ? And glibc ? Maybe busybox too ?
--
Best regards,
Marek Vasut
next prev parent reply other threads:[~2019-06-30 14:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 15:02 [U-Boot] What if ATF can be part of U-Boot source, like SPL? Jagan Teki
2019-06-29 16:50 ` Mark Kettenis
2019-06-29 18:38 ` Marek Vasut
2019-06-29 18:49 ` André Przywara
2019-06-29 23:03 ` Marek Vasut
2019-06-30 1:38 ` André Przywara
2019-07-02 18:32 ` Marek Vasut
2019-09-04 2:17 ` Simon Glass
2019-09-04 17:32 ` Andre Przywara
2019-09-04 17:56 ` Marek Vasut
2019-09-05 0:54 ` André Przywara
2019-09-05 12:26 ` Marek Vasut
2019-09-05 23:14 ` André Przywara
2019-06-30 11:15 ` Wolfgang Denk
2019-06-30 13:57 ` Tom Rini
2019-06-30 14:03 ` Marek Vasut [this message]
2019-06-30 14:07 ` Michael Nazzareno Trimarchi
2019-06-30 14:17 ` Tom Rini
2019-06-30 14:20 ` Marek Vasut
2019-06-30 14:29 ` Tom Rini
2019-06-30 14:50 ` Marek Vasut
2019-09-04 2:51 ` Masahiro Yamada
2019-09-04 23:10 ` Tom Rini
[not found] <20190904134501.7980e45b@donnerap.cambridge.arm.com>
2019-09-05 1:17 ` Matteo Carlini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=848513cc-1bb1-2a81-4a50-01bfa73b271d@gmail.com \
--to=marek.vasut@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox