From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package
Date: Thu, 12 Apr 2018 11:09:35 +0200 [thread overview]
Message-ID: <20180412110935.7366ab58@windsurf> (raw)
In-Reply-To: <538f8047-1a56-0335-9d3f-912ebc9914a0@lucaceresoli.net>
Hello Luca,
On Wed, 11 Apr 2018 23:03:17 +0200, Luca Ceresoli wrote:
> > So this hints at the fact that this firmware is board specific. Is that
> > correct ? If so, shouldn't we plan on making the Git repo and its
> > version configurable ?
>
> The firmware is board-specific and configuration-specific. The plan for
> that repo, however, is to have all supported board+config combinations
> supported in all versions, thus the lack of a version selection knob.
"all" ? I'm pretty sure a lot of people will be doing custom designs,
and will not be willing to push their firmware binary to your public
repository.
> > I mean, what are the chances that for some random ZynqMP board, your
> > Github repo will contain the appropriate firmware file ?
>
> Good point. My repo there is ready to hold any possible board+config
> combination that is interesting for known boards. I would love to host
> more boards there (contributilns would be welcome). However I don't
> think we'll ever see any custom board, which reduces its usefulness.
>
> Thus a simpler, but more flexible, option might be to nuke the
> zynqmp-pmufw-binaries BR package and let uboot fetch the pmufw.bin from
> a plain URL (https:// or file://). For standard devboards the URL could
> point to my repo, but it can be anywhere else (for custom boards).
Ah, this seems like a better option indeed, especially since the
firmware is a single file. It could be locally available, or downloaded
from HTTP. Sounds like a good plan.
> > Generally speaking, it's a bit annoying that we can't build this from
> > source. I understand it needs a Microblaze toolchain, so it's very
> > difficult to integrate in Buildroot :-/
>
> Indeed, and this is *the* big topic.
>
> There are several variations that could be considered, but none have
> been attempted AFAIK. Here they are, simplest to hardest:
>
> 1. Build the PMUFW in Buildroot (kind of)
>
> Add a script (e.g. board/zynqmp/build-pmufw.sh) that builds a microblaze
> toolchain and the PMUFW with a given config. The commands are already
> there: [0].
>
> The script would then be called manually before Buildroot runs, or it
> could be wrapped in a Buildroot package that uboot depends on. Takes ~8
> minutes on a modern quad core machine.
>
> * Simple to do, not well integrated, longer build time.
Yeah, the integration with Buildroot here is really not great, because
Crosstool-NG will do its own downloading, etc.
> 2. Let SPL install the PMUFW config
>
> This is what the Xilinx workflow does (in the Xilinx FSBL, which is more
> or less equivalent to U-Boot SPL). This allows The PMUFW can be a unique
> blob for all boards.
>
> This moves the configuration object from a piece of early firmware
> (PMUFW) to another piece of early firmware (SPL). Both pieces are
> residing in the same BOOT.BIN file, so there's no added flexibility for
> the "user": upon a config change, you still have to update the BOOT.BIN
> file in the boot medium.
>
> There are also licensing issues preventing this, since the configuration
> object file license is not compatible with the U-Boot license. Xilinx
> _might_ be willing to fix this, however.
>
> * Could be doable, perhaps tricky.
>
> 3. Don't have any config object...
>
> ...and change the PMUFW source code to assign dynamically peripherals to
> cores at runtime, based on requests from cores! :->
>
> * Maybe doable, potentially dangerous, definitely hard to do.
Not sure I understand enough of what the PMUFW is doing to understand
(2) and (3). And yes, I did attend your talk at FOSDEM about
ZynqMP ! :-)
> Any idea or suggestion is very welcome, although I think we cannot do
> much more than looking for the least evil solution...
I think for now the solution you propose to add an option in U-Boot to
indicate the path/URL to the PMUFW binary is the easiest one. It can
always be improved later if better solutions emerge.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-04-12 9:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-06 16:34 [Buildroot] [PATCH v2-RESEND 0/6] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 1/6] arm-trusted-firmware: simplify release dir path Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 2/6] arm-trusted-firmware: generate atf-uboot.ub for ZynqMP booting Luca Ceresoli
2018-04-09 21:08 ` Thomas Petazzoni
2018-04-11 21:12 ` Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package Luca Ceresoli
2018-04-09 21:13 ` Thomas Petazzoni
2018-04-11 21:03 ` Luca Ceresoli
2018-04-12 9:09 ` Thomas Petazzoni [this message]
2018-05-03 16:26 ` Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 4/6] uboot: zynqmp: generate SPL image with PMUFW binary Luca Ceresoli
2018-04-09 21:26 ` Thomas Petazzoni
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 5/6] uboot: zynqmp: allow to use custom psu_init files Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 6/6] configs: add Xilinx ZCU106 board (ZynqMP SoC) Luca Ceresoli
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=20180412110935.7366ab58@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/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