mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Rostislav Lisovy <lisovy@gmail.com>
Cc: barebox@lists.infradead.org, pisa@cmp.felk.cvut.cz
Subject: Re: [PATCH 3/3] ARM: i.mx53: Support for Voipac board. Device definition is read from Devicetree
Date: Mon, 11 Nov 2013 10:54:55 +0100	[thread overview]
Message-ID: <20131111095454.GF24559@pengutronix.de> (raw)
In-Reply-To: <1384035254.22589.19.camel@lolumad>

On Sat, Nov 09, 2013 at 11:14:14PM +0100, Rostislav Lisovy wrote:
> Hello Sascha;
> 
> On Fri, 2013-11-08 at 09:42 +0100, Sascha Hauer wrote: 
> > Hi Rostislav,
> > 
> > On Tue, Nov 05, 2013 at 03:42:07PM +0100, Rostislav Lisovy wrote:
> > > Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
> > > 
> > > diff --git a/arch/arm/boards/freescale-mx53-vmx53/env/config b/arch/arm/boards/freescale-mx53-vmx53/env/config
> > > new file mode 100644
> > > index 0000000..3d90172
> > > --- /dev/null
> > > +++ b/arch/arm/boards/freescale-mx53-vmx53/env/config
> > 
> > Why not use defenv-2?
> 
> Ok; I will use it;
> 
> > 
> > > diff --git a/arch/arm/boards/freescale-mx53-vmx53/flash_header.c b/arch/arm/boards/freescale-mx53-vmx53/flash_header.c
> > > new file mode 100644
> > > index 0000000..a6864a6
> > > --- /dev/null
> > > +++ b/arch/arm/boards/freescale-mx53-vmx53/flash_header.c
> > 
> > I'm currently generating the flash images for new boards using the
> > imx-image tool and also generate multi board images. This is a very
> > flexible, though maybe hard to understand mechanism. Is this the reason
> > you haven't used it or were you not aware of it?
> > I would rather see this board taking part in this new mechanism. Are you
> > willing to port this over? Otherwise I could try and convert this patch,
> > but I would depend on you testing the result.
> 
> I was investigating how the imx53-loco support is done, however I was
> not sure if the 'multiboard' is the preferred way.
> I found your patchset
> http://www.spinics.net/lists/u-boot-v2/msg15296.html shortly describing
> the functionality of the multiboard barebox -- I still do not understand
> the concept. The final binary has to hold just one particular
> 'flash_header', thus be able to boot just on one particular board.

The multi image support (I think multi image is more appropriate than
multi board) doesn't mean that the same image is being run on multiple
boards, it instead means that the same binary is used to generate
multiple images. Each of these images is for a particular board. The
advantage over the traditional mechanism is that you can have a single
config for multiple boards. Of course this could be used to have a
single config for completely different SoCs/Boards. This gives you
a better compile coverage with less compilation. A more real life
scenario might be that you have two boards which differ only in the
amount of SDRAM. Instead of maintaining two configs for it you could
use a single config and generate two images from it.

> I do
> understand the flexibility of the devicetree, however something like the
> SDRAM configuration can not be chosen 'on the fly' by the PBL?

The basic trick with the multi image support is that we compile multiple
entry points (ENTRY_FUNCTION()). Which one is used for a particular
image is later specified with the -e option to ld. So each image has
one entry function specified with ENTRY_FUNCTION(). What you then do
in this entry function is up to you. If your boards offer some
possibility to detect the SDRAM setup then you can use it to dynamically
detect and configure SDRAM. Then you would be able to use a single
binary image on multiple boards with different SDRAM configuration.

On i.MX with the DCD header format the DCD is normally used to setup
SDRAM. In this case it's not possible to have the same image for
multiple boards. However, you could remove the SDRAM setup from DCD
data and configure the flash header to load to the i.MX internal SRAM.
then when in SRAM you could determine your board and setup the SDRAM
from early code. This way a single image for multiple boards would
be possible on i.MX aswell.

With multi image support we shift away from "compiling for a single
board". Instead a board is simply an additional option. If this option
makes a new image necessary, then this image will be generated along
with images for other boards.
My vision is that we should not have defconfigs for particular boards.
Instead we should have defconfigs which enable a certain feature set,
for example:

- arm_full_defconfig: All features and all boards enabled, huge binary
  nobody uses in projects, but is useful for compile testing and
  development
- imx_defconfig: All i.MX boards enabled and all features necessary for
  i.MX. More practical in real life.
- noninteractive_defconfig: Do not prompt users, just boot.
- $VENDOR_defconfig: supports all boards from a vendor
- $PROJECT_defconfig: supports all boards for a particular project
  which uses different boards or variants of boards.

I hope this makes it a bit more clearer.

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:[~2013-11-11  9:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 14:42 [PATCH 0/3] Support for Voipac X53-DMM-668 module and Voipac Baseboard Rostislav Lisovy
2013-11-05 14:42 ` [PATCH 1/3] ARM: dts: i.mx53: Internal keyboard controller + i2c pinmux Rostislav Lisovy
2013-11-05 14:42 ` [PATCH 2/3] ARM: i.mx53: Parse Reset GPIO pin in FEC driver from Devicetree Rostislav Lisovy
2013-11-05 16:15   ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-05 19:11     ` Pavel Pisa
2013-11-06  8:39       ` Sascha Hauer
2013-11-05 14:42 ` [PATCH 3/3] ARM: i.mx53: Support for Voipac board. Device definition is read " Rostislav Lisovy
2013-11-08  8:42   ` Sascha Hauer
2013-11-09 22:14     ` Rostislav Lisovy
2013-11-11  9:54       ` Sascha Hauer [this message]
2013-11-12 22:57         ` Rostislav Lisovy

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=20131111095454.GF24559@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=lisovy@gmail.com \
    --cc=pisa@cmp.felk.cvut.cz \
    /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