From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 26 Aug 2013 20:42:52 +0200 Subject: [U-Boot] [PATCH V4] ARM: mxs: tools: Add mkimage support for MXS bootstream In-Reply-To: <521B006D.4040005@denx.de> References: <1376955905-6350-1-git-send-email-marex@denx.de> <201308251833.27075.marex@denx.de> <521B006D.4040005@denx.de> Message-ID: <201308262042.52790.marex@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 Dear Stefano Babic, > Hi Marek, > > On 25/08/2013 18:33, Marek Vasut wrote: > >>> + MODE string_mode > >>> + - Restart the CPU and start booting from device specified by the > >>> + "string_mode" argument. The "string_mode" differs for each CPU > >>> + and can be: > >>> + i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH > >>> + JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1 > >>> + i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH > >>> + JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1 > >>> + > >> > >> Is this equivalent to the "bmode" command on i.MX5/6 ? > > > > BMODE command? How does that one work? > > It sets for i.MX (MX5/MX6) from which source the BootROM must read the > image. We can say it is a soft way to overwrite the boot pin > configuration without having to write into fuses, useful to test > different boot conditions. Seems to be the same thing ... or similar at least. > >>> * Compression Types > >>> > >>> diff --git a/tools/Makefile b/tools/Makefile > >>> index 33fad6b..bbae5a2 100644 > >>> --- a/tools/Makefile > >>> +++ b/tools/Makefile > >>> @@ -83,6 +83,7 @@ NOPED_OBJ_FILES-y += aisimage.o > >>> > >>> NOPED_OBJ_FILES-y += kwbimage.o > >>> NOPED_OBJ_FILES-y += pblimage.o > >>> NOPED_OBJ_FILES-y += imximage.o > >>> > >>> +NOPED_OBJ_FILES-y += mxsimage.o > >> > >> Can you reorder the list ? > > > > How? It's out of order already. > > I know - it would be nice if the list was in order again, at least for > the components of mkimage (NOPED_OBJ_FILES-). I will do a separate patch. > >>> + * CRC32 > >>> + */ > >>> +static uint32_t crc32(uint8_t *data, uint32_t len) > >>> +{ > >>> + const uint32_t poly = 0x04c11db7; > >> > >> Comparing this polinomial with the one in lib/crc32.c, they are > >> identical. The crc32 function you define here should give the same > >> result as our old crc32 (global) in lib/crc32.c. Then, can you drop this > >> one and use the already implemented function ? > > > > As I do not want to diverge more than necessary, this can be done in > > subsequent patch. > > However this adds a duplication in the code, and using the global crc > should be quite straightforward. We cannot use the zlib crc32 function which is implemented in lib/crc32.c as the CRC32 used by MXS bootrom uses bit-flipped polynomial compared to the zlib implementation. [...] Best regards, Marek Vasut