From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= Date: Thu, 25 Apr 2013 15:16:50 +0200 (CEST) Subject: [U-Boot] [PATCH V2 6/6] arm: mx5: Add support for DENX M53EVK In-Reply-To: <51792961.5000408@denx.de> References: <1366559547-9063-1-git-send-email-marex@denx.de> <5178DBD9.1060109@denx.de> <5178EB8B.7040600@denx.de> <201304251438.37200.marex@denx.de> <5179263B.9060601@denx.de> <1324293171.246945.1366894194606.JavaMail.root@advansee.com> <51792961.5000408@denx.de> Message-ID: <350869318.247717.1366895810909.JavaMail.root@advansee.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stefano, On Thursday, April 25, 2013 3:02:25 PM, Stefano Babic wrote: > On 25/04/2013 14:49, Beno?t Th?baudeau wrote: > > Hi Stefan, > > > > On Thursday, April 25, 2013 2:48:59 PM, Stefan Roese wrote: > >> Subject: Re: [U-Boot] [PATCH V2 6/6] arm: mx5: Add support for DENX M53EVK > >> > >> On 25.04.2013 14:38, Marek Vasut wrote: > >>>>> Right, this is also correct. Anyway, BOOT_FROM is used to get the > >>>>> offset > >>>>> inside the storage, and only to be as much flexible as possible, each > >>>>> storage has defined its own offset. However, Freescale uses the same > >>>>> offset (0x400) for most storages (NAND, SD..) and another one for NOR > >>>>> or > >>>>> OneNAND (0x1000). Maybe it is easier to have only this two cases. > >>>> > >>>> Yes, I would prefer that. > >>>> > >>>> And being at it, why don't we add the offset to the resulting image as > >>>> well? This would make programming the images to the destination (SD, > >>>> NAND, MMC etc) easier. We would not have to care for the correct offset > >>>> then (which is more error prone). And it is necessary btw, to have this > >>>> offset added, when using the FSL kobs-ng tool to program the image to > >>>> NAND flash. > >>> > >>> This would interfere with MBR on SD cards, the offset is there for a > >>> reason > >>> ;-) > >> > >> Yes, makes sense. But only for SD cards. On other mediums (e.g. SPI NOR, > >> NAND) this padded image would be easier (less error prone) to handle. > > > > For NAND, we already have u-boot-with-nand-spl.imx. > > Is it padded at the beginnig ? I have thought the pad is between SPL and > u-boot based on CONFIG_SPL_PAD_TO, but we need to flash always at the > right offset. Here are the image types that we currently have: - u-boot.imx: imx header + u-boot.bin, no padding to compensate for imx offset, generic usage, - SPL: imx header + u-boot-spl.bin, no padding to compensate for imx offset, generic SPL usage, - u-boot-with-spl.imx: SPL padded to CONFIG_SPL_PAD_TO + uImaged-u-boot.bin, no padding to compensate for imx offset, any non-NAND SPL + u-boot usage, - u-boot-with-nand-spl.imx: (FCB (filling normal imx offset) + SPL) padded to CONFIG_SPL_PAD_TO + uImaged-u-boot.bin, NAND SPL + u-boot usage. Best regards, Beno?t