From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Fri, 31 Dec 2010 11:03:31 +0100 Subject: [U-Boot] [PATCH v3 7/8] imximage: Add MX53 boot image support In-Reply-To: References: <1293626967-18740-1-git-send-email-r64343@freescale.com> <4D1C7F08.1010400@denx.de> <20101231081428.DE8404F1@gemini.denx.de> <20101231085021.100624F1@gemini.denx.de> Message-ID: <4D1DAA73.1030009@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12/31/2010 10:25 AM, Jason Liu wrote: > Hi, Wolfgang, > > 2010/12/31 Wolfgang Denk : >> Dear Jason Liu, >> >> In message you wrote: >>> >>>> This looks as if you added something to the standard 64 byte image >>>> header. You must not modify this. It is fixed for all architectures >>>> and cannot be extended. >>> >>> This change is specific for I.MX chip and will not affect other architectur> es. >> >> All architectures use exactly the same binary image header. This >> header has no version field, and such a field cannot be added. > > Here, the imx header is the data structure we defined in imximage.c > and it will be used to generate > the boot-able image u-boot.imx of i.mx soc together with u-boot.bin by > .set_header function call of struct > image_type_params according to FSLi.MX boot ROM requirement. Yes, the field is inside the imx header and not in the 64 byte structure. > > When run the command "mkimage -l u-boot.imx", the imx header will be > fetched from the u-boot.imx and > the version information will be decoded according to data structure > definition, and then it do the verify by > checking some magic number or tag according to different version, and > in the end, it will print the header > information if it pass the verification. > > So, I don't think it will affect other architectures. Yes, but we rely on a single undocumented byte when on the other hand Freescale has provided at least two well-documented magic numbers for each version to detect if an image is valid or not. Ans as I stated, introducing this version field generates an unneeded incompatibility with atual images. Best regards, Stefano Babic -- ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================