Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/2] uboot: add support for generating U-Boot boot scripts
Date: Thu, 22 Jun 2017 13:31:20 +0200	[thread overview]
Message-ID: <20170622133120.735b26c2@windsurf> (raw)
In-Reply-To: <87h8z8i8o5.fsf@dell.be.48ers.dk>

Hello,

On Thu, 22 Jun 2017 13:06:02 +0200, Peter Korsgaard wrote:

>  > More and more of our defconfigs need to generate a U-Boot boot
>  > script. It's a simple call to mkimage, but we already have 12
>  > instances of this logic in board/, and there are patch series waiting
>  > in patchwork adding 3 more boards that need this.  
> 
>  > So let's add an option in the U-Boot package to generate such a boot
>  > script image easily.  
> 
>  > Note that we assume a single script needs to be generated, and the
>  > output file name is boot.scr. The only platform for which it seems to
>  > not be the case are the Boundary Devices platforms: they generate two
>  > boot scripts, 6x_bootscript and 6x_upgrade, but they are anyway
>  > installed inside TARGET_DIR, not BINARIES_DIR.  
> 
>  > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>  
> 
> Makes sense to me. Committed, thanks.

Wow, that was fast. I was wondering if we should extend it to multiple
boot scripts, but then the syntax would be a bit horrible:

BR2_TARGET_UBOOT_BOOT_SCRIPT_SOURCE="script1src:script1dest script2src:script2dest"

We could still keep the compatibility by having:

BR2_TARGET_UBOOT_BOOT_SCRIPT_SOURCE="script1src"

just generate script1src and install it as boot.scr.

Or maybe it's something we can take care of later?

>  > Retrospectively, I believe the choice of adding such a helper script
>  > for genimage was wrong. Having a proper option would be much
>  > cleaner/nicer IMO.  
> 
> Yes, agreed. My idea was also to add a kconfig option for it. This could
> also have sub options like "support creating fat partitions" that would
> pull in the needed host packages.

Also my thinking.

> The reason we went with the script solution was afaik that some projects
> might want to extra processing before or after creating the image, so it
> wasn't clear if it should run before or after the post-image scripts.
> 
> You can argue though that for such "special" situations you should just
> manually call genimage from the post-image script instead though.

Absolutely. I don't think we should try in those options to cover *all*
cases, only the most common ones. As long as the more special cases can
be covered by custom logic in post-build/post-image scripts, we're good
IMO.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2017-06-22 11:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21 21:41 [Buildroot] [PATCH 1/2] uboot: add support for generating U-Boot boot scripts Thomas Petazzoni
2017-06-21 21:41 ` [Buildroot] [PATCH 2/2] configs/cubieboard2_defconfig: use U-Boot boot script generation logic Thomas Petazzoni
2017-06-22 11:06   ` Peter Korsgaard
2017-06-22 11:06 ` [Buildroot] [PATCH 1/2] uboot: add support for generating U-Boot boot scripts Peter Korsgaard
2017-06-22 11:31   ` Thomas Petazzoni [this message]
2017-06-22 14:18     ` Peter Korsgaard
2017-06-22 14:44       ` Thomas Petazzoni
2017-06-22 16:00         ` Peter Korsgaard

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=20170622133120.735b26c2@windsurf \
    --to=thomas.petazzoni@free-electrons.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