All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.