mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH RFC] ARM: dove: build multiple pbl images for DT based boards
Date: Sun, 9 Feb 2014 09:36:15 +0100	[thread overview]
Message-ID: <20140209083614.GA17250@pengutronix.de> (raw)
In-Reply-To: <1391866056-13133-1-git-send-email-sebastian.hesselbarth@gmail.com>

Hi Sebastian,

On Sat, Feb 08, 2014 at 02:27:36PM +0100, Sebastian Hesselbarth wrote:
> As my limited Makefile skills are now exhausted, I decided to put this
> on list instead. Maybe somebody can give valuable hints on how to make
> this idea into a smooth, beautiful patch instead.
> 
> What I want to achieve is to have a common pbl entry function for all
> DT based boards of one SoC. For now, let's just talk about Marvell Dove
> here, but on the long run, I'd like to have it also for the other MVEBU
> SoCs. Right now, I guess, each SoC will still have its own "DT board"
> but it could also end up in one board for all MVEBU SoCs..
> 
> Anyway, first of all, I'd summarize status quo from my current
> understanding of how it all works.
> 
> For pbl images, barebox picks up all that is in $(pbl-y) and links it
> up to one .pbl binary. At that point, the entry function and all symbols
> (e.g. __dtb_vendor_board_start) have to be known. The entry function is
> derived from the .pbl filename, e.g. start_my_board.pbl. The dtb symbol
> is generated in dts make process from the dts base name, e.g.
> vendor-board.dts for the symbol above.
> 
> From the .pbl binary then a .pblb is objcopy'd that strips all unused
> symbols. The .bplb is compressed to .pblx and finally passed over to the
> SoC specific image generation, e.g. kwbimage.

All correct.

> 
> Now, for having one board file for a set of selectable dtbs, you would
> need a single entry function name and also a single symbol to access
> the linked dtb at runtime. In the example for Dove below, I have chosen
> start_dove_dt for the entry function and __linked_dtb_start for the
> required dtb.

It's not quite clear to me what you want to archieve or maybe better why
you want to archieve it. Right now there are board specific entry
functions, with 'board' meaning everything that you can't detect during
runtime. So if want to support multiple boards and can detect during
runtime on which one you are on then you can use a single entry
function, detect the board and pass the correct dtb to
barebox_arm_entry. If you can't detect the board then you need different
images, one per board. An image is defined by its entry function. Why do
you want to make the entry function common per SoC? I mean if there's
some SoC specific setup that every board of a SoC type needs, then you
can factor it out to a common function and call mvebu_setup_something()
in each entry function or make a mvebu_barebox_entry like we already
have.
I think the entry functions are short and easy enough to duplicate them
per board. Also it gives you the chance to do board specific quirks very
early without having to #ifdef common code.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2014-02-09  8:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-08 13:27 Sebastian Hesselbarth
2014-02-09  8:36 ` Sascha Hauer [this message]
2014-02-09 10:31   ` Sebastian Hesselbarth
2014-02-09 21:30     ` Sascha Hauer

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=20140209083614.GA17250@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=sebastian.hesselbarth@gmail.com \
    /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