All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V4] ARM: mxs: tools: Add mkimage support for MXS bootstream
Date: Sun, 25 Aug 2013 18:33:26 +0200	[thread overview]
Message-ID: <201308251833.27075.marex@denx.de> (raw)
In-Reply-To: <52136BAD.6080903@denx.de>

Dear Stefano Babic,

> dcd_Hi Marek,
> 
> On 20/08/2013 01:45, Marek Vasut wrote:
> > Add mkimage support for generating and verifying MXS bootstream.
> > The implementation here is mostly a glue code between MXSSB v0.4
> > and mkimage, but the long-term goal is to rectify this and merge
> > MXSSB with mkimage more tightly. Once this code is properly in
> > U-Boot, MXSSB shall be deprecated in favor of mkimage-mxsimage
> > support.
> > 
> > Note that the mxsimage generator needs libcrypto from OpenSSL, I
> > therefore enabled the libcrypto/libssl unconditionally.
> > 
> > MXSSB: http://git.denx.de/?p=mxssb.git;a=summary
> > 
> > The code is based on research presented at:
> > http://www.rockbox.org/wiki/SbFileFormat
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Tom Rini <trini@ti.com>
> > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Otavio Salvador <otavio@ossystems.com.br>
> > ---
> > 
> >  arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg |    6 +
> >  arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg |    8 +
> >  common/image.c                               |    1 +
> >  config.mk                                    |    9 +
> >  doc/README.mxsimage                          |  165 ++
> >  include/image.h                              |    1 +
> >  tools/Makefile                               |    2 +
> >  tools/mkimage.c                              |    2 +
> >  tools/mkimage.h                              |    1 +
> >  tools/mxsimage.c                             | 2347
> >  ++++++++++++++++++++++++++ tools/mxsimage.h                            
> >  |  230 +++
> >  11 files changed, 2772 insertions(+)
> >  create mode 100644 arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
> >  create mode 100644 arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
> >  create mode 100644 doc/README.mxsimage
> >  create mode 100644 tools/mxsimage.c
> >  create mode 100644 tools/mxsimage.h
> > 
> > V2: Remove the time hack fixing timestamp at certain time
> > 
> >     Enable -lssl and -lcrypto only if CONFIG_MX23/CONFIG_MX28 is set
> > 
> > V3: Checkpatch fixes for all but openssl
> > V4: Conditionally compile mxsimage support into mkimage by defining
> > -DCONFIG_MXS
> > 
> >     in HOSTCFLAGS and then in turn checking for this in the mxsimage.c
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
> > b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg new file mode 100644
> > index 0000000..8118767
> 
> I get a compiler warning testing your patch:
> 
> mxsimage.c: In function ?mxsimage_generate?:
> mxsimage.c:1535:28: warning: ?ilen? may be used uninitialized in this
> function [-Wuninitialized]
> mxsimage.c:1496:12: note: ?ilen? was declared here
> 
> 
> Can you fix it ?

OK

> > --- /dev/null
> > +++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
> > @@ -0,0 +1,6 @@
> > +SECTION 0x0 BOOTABLE
> > + TAG LAST
> > + LOAD     0x0        spl/u-boot-spl.bin
> > + CALL     0x14       0x0
> > + LOAD     0x40000100 u-boot.bin
> > + CALL     0x40000100 0x0
> > diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
> > b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg new file mode 100644
> > index 0000000..ea772f0
> > --- /dev/null
> > +++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
> > @@ -0,0 +1,8 @@
> > +SECTION 0x0 BOOTABLE
> > + TAG LAST
> > + LOAD     0x0        spl/u-boot-spl.bin
> > + LOAD IVT 0x8000     0x14
> > + CALL HAB 0x8000     0x0
> > + LOAD     0x40000100 u-boot.bin
> > + LOAD IVT 0x8000     0x40000100
> > + CALL HAB 0x8000     0x0
> 
> You are talking about examples - to better understand, do we need some
> board specific files for them ? Or do these two files cover 99% of the
> cases ?

Covers the regular usage.

[...]

> > +      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?

> >   * 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.

> >  NOPED_OBJ_FILES-y += image-host.o
> >  NOPED_OBJ_FILES-y += omapimage.o
> >  NOPED_OBJ_FILES-y += mkenvimage.o
> > 
> > @@ -209,6 +210,7 @@ $(obj)mkimage$(SFX):	$(obj)aisimage.o \
> > 
> >  			$(obj)image-host.o \
> >  			$(FIT_SIG_OBJS) \
> >  			$(obj)imximage.o \
> > 
> > +			$(obj)mxsimage.o \
> 
> Ditto

Ditto, it's already out of order.

[...]

> > +
> > +/*
> > + * 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.

[...]

> > +	/*
> > +	 * Append the command to the last section.
> > +	 */
> > +	if (!sctx->cmd_head) {
> > +		sctx->cmd_head = cctx;
> > +		sctx->cmd_tail = cctx;
> > +	} else {
> > +		sctx->cmd_tail->cmd = cctx;
> > +		sctx->cmd_tail = cctx;
> > +	}
> > +
> 
> This append stuff can be factorized at least with a macro - it is
> repeated again and again in all commands.

This can (read : shall) be even replaced by include/linked_lists.h  , but not in 
this patch.

[...]

  reply	other threads:[~2013-08-25 16:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-19 23:45 [U-Boot] [PATCH V4] ARM: mxs: tools: Add mkimage support for MXS bootstream Marek Vasut
2013-08-20 13:14 ` Stefano Babic
2013-08-25 16:33   ` Marek Vasut [this message]
2013-08-26  7:14     ` Stefano Babic
2013-08-26 18:42       ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201308251833.27075.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.