From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VgMti-0006O7-7H for barebox@lists.infradead.org; Tue, 12 Nov 2013 22:57:27 +0000 Received: by mail-ea0-f174.google.com with SMTP id n15so3186750ead.33 for ; Tue, 12 Nov 2013 14:57:04 -0800 (PST) Message-ID: <1384297021.18882.6.camel@lolumad> From: Rostislav Lisovy Date: Tue, 12 Nov 2013 23:57:01 +0100 In-Reply-To: <20131111095454.GF24559@pengutronix.de> References: <1383662527-8538-1-git-send-email-lisovy@gmail.com> <1383662527-8538-4-git-send-email-lisovy@gmail.com> <20131108084215.GU24559@pengutronix.de> <1384035254.22589.19.camel@lolumad> <20131111095454.GF24559@pengutronix.de> Mime-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "barebox" Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: [PATCH 3/3] ARM: i.mx53: Support for Voipac board. Device definition is read from Devicetree To: Sascha Hauer Cc: barebox@lists.infradead.org, pisa@cmp.felk.cvut.cz On Mon, 2013-11-11 at 10:54 +0100, Sascha Hauer wrote: > 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 > > > > > > > > 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 > Thank you for the explanation. I just resent the patch-set for the 'multi-board/multi-image' support. Regards; Rostislav _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox