From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Mon, 13 Feb 2012 15:10:27 +0100 Subject: [U-Boot] imximage: Create i.MX6 NOR flash images (was: [PATCH v5 1/1] imximage: Add MX53 boot image support) In-Reply-To: <1295466026-19025-1-git-send-email-r64343@freescale.com> References: <1295466026-19025-1-git-send-email-r64343@freescale.com> Message-ID: <4F3919D3.4050907@de.bosch.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 Jason, On 19.01.2011 20:40, Jason Liu wrote: > This patch add the MX53 boot image support. > > This patch has been tested on Freescale MX53EVK board > and MX51EVK board. > > Signed-off-by: Jason Liu > ... > diff --git a/tools/imximage.c b/tools/imximage.c > index 39f89c2..8e81bdb 100644 > --- a/tools/imximage.c > +++ b/tools/imximage.c ... > +static void set_imx_hdr_v2(struct imx_header *imxhdr, uint32_t dcd_len, > + struct stat *sbuf, > + struct mkimage_params *params) > +{ ... > + /* Set default offset */ > + imxhdr->flash_offset = FLASH_OFFSET_STANDARD; I have some doubts that this hard coding (over writing) of imxhdr->flash_offset is correct here. For booting from i.MX6 parallel NOR or NAND, flash_offset is != 0x400 (FLASH_OFFSET_STANDARD). In parse_cfg_cmd() we read the correct flash offset valid for the selected boot device from the configuration: case CMD_BOOT_FROM: imxhdr->flash_offset = get_table_entry_id(imximage_bootops, "imximage boot option", token); But this correct flash offset is afterwards overwritten by imxhdr->flash_offset = FLASH_OFFSET_STANDARD; as mentioned above, which I think is wrong. It doesn't matter for all devices which use FLASH_OFFSET_STANDARD (e.g. SD/SPI NOR etc), but it doesn't seem to work for parallel NOR and NAND. What do you think? I will need some time to verify this with a != 0x400 boot device, but as soon as I have this working I will send a patch for the imximage tool. Best regards Dirk Btw.: I'm not sure if the same statement for the v1 header set_imx_hdr_v1() is wrong, too, though?